1 / 65

CS 551 - Architecture

CS 551 - Architecture. P. E. R. F. O. O. A. R. &. M. M. A. ERROR RECOVERY. N. C. E. PROBLEM. REQUIRE. REQUIRE. MENTS. MENTS. Systems Architecture. CS 551 Lecture 5. Software Architecture Lessons.

bella
Download Presentation

CS 551 - Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 551 - Architecture

  2. P E R F O O A R & M M A ERROR RECOVERY N C E PROBLEM REQUIRE REQUIRE MENTS MENTS Systems Architecture CS 551 Lecture 5

  3. Software Architecture Lessons • A good software architecture may be the single most important characteristic for a successful software development. • It is the key framework for all technical decisions. • It has a profound influence on the organization of the project. • The architecture of the system should be documented in a clear and concise way and communicated to everyone on the project. • Use architecture reviews to make sure that the integrity of the architecture is preserved as new features and functions are added. • Periodically renew the architecture.

  4. What is Software Architecture? • The framework for all technical decisions. • A coherent, justified collection of design decisions. • Technology and platform selection to match the problem. • A vehicle for communication among stakeholders. • A balance between features, cost and schedule. • A reusable and transferable abstraction of a system. • The basis for a product line or product family. • A mechanism to insure that the system meets the reliability, capacity, response time and throughput requirements. • Simplest satisfactory solution.

  5. Benefits of Good Software Architectures • Helps identify and isolatereusable components that can speed implementation and improve system quality. • Assists in measuring project impacts of inevitable ongoing technical and business decisions and compromises. • Leads to clearly defined organizations with inherent project efficiencies, good communications and decision making.

  6. It encompasses the requirements, architecture and high level design phases of the typical waterfall diagram. It also continues throughout the life of the project (someone continues to wear the architect’s hat). Prospectus Iterative process until consensus is reached Requirements Carries through the life of the project Architecture High Level Design Architecture in a Project’s Life Cycle Planning and Architecture Phase Discovery Review Low Level Architecture Design Review

  7. What we look for in an Architecture • The purpose the system is intended to satisfy. • The major functional components and/or platforms. • The relationship between the components. • The fit to function. • The dynamic interplay of control and communication between these components. • The system’s ease of use. • The data storage and flow of data among these components. • The resources which are consumed by each component in the performance of its task.

  8. Kruchten’s “4 + 1”Model for Developing Software Architecture + 1 Business Scenario View 1 View 2 Process -- System Integrators Logical -- End Users + 1 Business Scenario View 4 View 3 Execution -- Programmers Physical -- Engineers This is an innovative and comprehensive integration of the abstractions needed to design the structure for writing system requirements. + 1 Business Scenario

  9. Cost of Modifying Modules for Reuse -- NASA Data for 2954 Modules Relative Cost Amount Modified

  10. Open Systems Interconnection Model The Foundation for Distributed Software Systems

  11. Other Project Management Tech OA&M ErrRcvy Requirements Performance ARCHITECTURE REVIEWS Found:Problem Areas

  12. Project Management Findings 1. Aggressive schedule forcing inadequate time and focus on fundamental architecture issues • Attempts at working issues in parallel with development often leads to major rework or complete failure 2. Lack of central management or architecture consistency for projects attempting to integrate multiple systems 3. No clear success criteria - multiple, subjective views of customer expectations 4. No clear problem statement - multiple, or conflicting goals 5. No architect (or architecture effort); no central coordination and record of system wide technical decisions 6. Lack of buy-in from all stakeholders on requirements or architecture issues

  13. Requirements Findings Approximate Occurrences

  14. Requirements Findings 1.Lack of Functional Requirements • No requirements have been written in key areas • Usage scenarios not understood and documented • Functionality of the system incomplete • Customer unknown or not contacted • No acceptance criteria for the system 2. Lack of Performance & Capacity Requirements • Number and/or types of users undocumented • Transaction and data volumes unknown • Night or batch processing unknown 3. Lack of OA&M Requirements • No OA&M requirements documented • No availability requirements documented • Availability requirements not tied to customer needs (e.g. ‘7 X 24’)

  15. Design Findings Approximate Occurrences

  16. Design Findings 1. Performance Engineering • Often the performance requirements are not fully understood. • “Build it now, tune it later” • Processing, memory, disk utilization (such as database transactions) needs are not well understood by the architects. • Assumption that the system will scale linearly as the load grows • No performance budgets 2. Operations, Administration, Maintenance and Provisioning (OAM&P) • These components include installing the system, booting/rebooting, backup and recovery, remote maintenance and diagnostics, initializing the data needed for the system to operate, and tools to provision the growth of the system. • Design and implementation often underestimated. • Design done late in cycle and inconsistent with remainder of system features. 3. Error Handling and Recovery • Lack of a system error strategy for catching, reporting and recovering from both hardware and software failures. • Error strategy design is the process to examine error scenarios.

  17. Service Capacity Planning

  18. Goals • To support and drive service scalability targets. • To identify early architecture and network issues. • To communicate between business management and the technical community.

  19. Scalability Overview • Capacity modeling before service deployment • Periodic usage reporting as service deployed • Capacity management as service deployed • Monitoring • Growth Planning and Implementation

  20. Before and During Deployment During Deployment Customer Behavior Marketing Data Service Quality Objectives Analytical Model (Spreadsheet) Customer Profiles Usage Data System Performance Network Architecture Predicted Capacity and Hot Spots Network Upgrades Capacity Modeling

  21. Load Projections Example Total Users 50,000

  22. Acknowledgement Thanks to Joe Maranzano, he is the class of software architects.

  23. Architecture Description Language Thanks to Ed Colbert, USC

  24. Problems Developing Embedded Real-Time Systems • Reliability, safety, & performance are vital concerns • Wrong or late answer can be deadly • Hardware dependent integration and migration • Few means of assessing impact of decisions • Upgrades throughout an extended deployment

  25. Problems Developing Embedded Real-Time Systems (cont.) • Current development process • Manual, paper intensive, error prone, resistant to change • Disjoint models • Models not kept up Requirements Analysis Design Implementation Integration

  26. Problems Developing Embedded Real-Time Systems (cont.) • A well–designed architecture is essential, but • architectural descriptions are • Informal documents • Usually centered on box-and-line diagrams, with explanatory prose • Visual conventions are idiosyncratic & project-specific

  27. What is an Architecture Description Language? • Describe high-level designs • Treats systems as collections of connected modules • Module layout defines structure • Connectors define communication • Iinterfaces are modules • Does NOT describe algorithms, data structures or control flows

  28. Avionics ADL • Specification of • Real-time • Embedded • Fault-tolerant • Securely partitioned • Dynamically configurable • Software task and communication architectures • Bound to distributed multiple processor hardware architectures

  29. Model-Based AADL Process Architecture-based Requirements Analysis Architecture-based System Integration Rapid Integration Predictable System Upgradeability Explicit Architecture Engineering Model Architecture-based Design and Implementation

  30. Software Engineer Guidance & Control Communi- cation & Protocol Automatic Target Recognition Navigation Sensor & Signal Processing Generated Components Generated Components Generated Components Warhead Fusing Telemetry Model-Based AADL Engineering • Analyses • Schedulability • Reliability • Fault Tolerance • System Build • Executive Generation • Module Integration • Nmake Real-Time Architecture Model Software Hardware Architectural Abstraction Processor Architecture Bus Design Memory Configuration Hand Coded Components Hand Coded Components Domain Specific Languages Domain Specific Hardware

  31. design feed-back formal modeling and analysis methods and tools verification discipline-specific design notations and editing and visualization tools implementation methods and tools code generation An Engineering Paradigm • Formal specification of architecture & properties • Early detection: repeated system analyses • Error elimination: automatic generation & integration • Rapid evolution: refinement of models & components • Managed change impact: Separation of concerns

  32. Generated Partitioned Architecture Software Component Software Component Software Component Software Component Fault Recovery, Execution Control, Mode Control, Timing Control, Data Synchronization, Interprocess Communication MetaH Executive MetaH Kernel Operating Environment Embedded Hardware Target • Strong Partitioning • Timing Protection • OS Call Restrictions • Memory Protection • Portability • Application Components • Tailored MetaH Executive • MetaH Kernel

  33. Automatically generated MetaH executive components MetaH executive library components target-specific library components Run-time or RTOS Multi-Processor Structure Applicationprocess Applicationprocess Applicationprocess Applicationprocess Applicationprocess Processor A Processor B One downloadable image file is generated for each processor.

  34. Process Analysis • Given • Process/processor & message/channel bindings • Process periods, deadlines, criticalities • Sequence of modules executed by a process • Module nominal & worst-case compute times • Processor & channel overheads • Compute • Processor & channel schedulability • Processor, channel, process, module utilizations • Parametric compute time sensitivity analysis

  35. System Type & Implementation systemtype Nav is end Nav; systemimplementation Nav.Blended is A: system GPS; B: system INS; Both: initialmode (A, B); A_Only: mode (A); B_Only: mode (B); behaviors Both -[ A.Failure ]-> B_Only; Both -[B.Failure ]-> A_Only; end Nav.Blended;

  36. Thread Example thread Collect_Samples is Input_Sample : in data Sampling’Sample; requires SampleSet : data Sampling’Sample_Set ; end Collect_Samples ; thread implementation Collect_Samples.Batch_Update is refines Input_Sample: in data Sampling’Sample {Source_Data_Size => 16 B} ; end Collect_Samples.Batch_Update ;

  37. Process Example process Sample_Manager is Input_Sample: in data Sampling’Sample; end Sample_Manager ; process implementation Sample_Manager.Slow_Update is Samples: data Sampling’Samples; Collect_Samples: thread Collect_Samples(SampleSet => Samples).Batch_Update ; end Sample_Manager.Slow_Update ; process implementation Sample_Manager.Fast_Update extends Sample_Manager.Slow_Update is refines Samples: data Sampling’Dynamic_Sample_Set ; end Sample_Manager.Fast_Update ;

  38. Process with Subprograms Example process File_Server is Open, Close: subprogram (filename:string); end File_Server; process Resizeable_File_Server extends File_Server is requires Reserve_Resource: subprogram (diskname: string, disksize: size); end Resizeable_File_Server; process implementation File_Server.Basic is File_System_Directory : data FSLib’directory; end File_Server.Basic;

  39. Package Type & Implementation Example package Shared_Data is Set_State, Set_State: subprogram; end Shared_Data; packageimplementationShared_Data.PowerPC is Get_State : subprogram{Compute_Time => 15us..20us}; Set_State:subprogram{Compute_Time => 20us..30us}; properties Source_Text => “shared_data_powerpc.ads”, “shared_data_powerpc.adb”; end Shared_Data.PowerPC;

  40. UML Limits • UML provides modeling concepts & notations for typical software modeling projects • Real-time requirmes • Additional features and/or notations • Non-semantic information attached to models

  41. UML Extensions • UML core concepts can be extended or specialized by users • 3 built-in extension mechanisms • Stereotype • Constraint • Tagged Value

  42. Benefits of Extending UML • Architects can represent system architecture graphically using commonly available UML tools • UML tool developers can add advance support for AADL to existing tools rather than developing new tools • e.g. safety analysis • Software designers can take defined architecture & refine software components • rather than common practice of re–creating architecture in software development tools • System integrators should have easier time integrating • Software components generated by UML tools, or hand–code based on UML specification • Executive and architectural glue code that is generated by AADL tool • Target hardware.

  43. UML Model of AADL v0.7 (draft)Overview

  44. UML Model of AADL v0.7 (draft)Core Concepts

  45. UML Model of AADL v0.7 (draft)System

  46. UML Model of AADL v0.7 (draft)Components

  47. UML Model of AADL v0.7 (draft)Component Types

  48. UML Model of AADL v0.7 (draft)Software Types

  49. UML Model of AADL v0.7 (draft)Ports

  50. Component_Classifier inv: -- parent & child of Extends relation must be same subclass Component_Type inv: -- only package, bus, or memory sub-components are allowed Component_Implementation inv: -- category must equal type’s category Component_Instance inv: -- if has a type, category must equal type’s category inv: -- if has a implementation, category must equal implementation’s category Package_Type -- Inherits from Component_Type inv: -- category must be Package self.category = package inv: -- Only package components allowed self.components->forAll ( category = package ) UML Model of AADL v0.7 (draft)Sample Constraints

More Related