Lecture 5 Architecture

1. CS 540 – Quantitative Software Engineering Lecture 5 Architecture Architecture is synthesis Design is analysis

2. Systems Architecture P E R F O O A R & M M A ERROR RECOVERY N C E PROBLEM REQ REQ

3. What to 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.

4. What is Software Architecture? • The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. • The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.[Len Bass, Paul Clements, Rick Kazman 2003]

5. What are Software Architecture Views? • Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. (ANSI/IEEE 1471-2000) • Views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns. • Some possible views are: • Functional/logic view • Code view • Development/structural view • Concurrency/process/thread view • Physical/deployment view • User action/feedback view

6. Kruchten’s “4 + 1”Model for Developing a Software Architecture + 1 Business Scenario View 1 View 2 Process -- System Integrators Logical -- End Users + 1 Business Scenario View 4 View 3 Development -- Programmers Physical -- Engineers + 1 Business Scenario

7. Software Architecture (Garlan & Shaw) “Software architecture is a level of design that goes beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”

8. 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 feasible solution.

9. Components Interconnections Rules of Composition Rules of Behavior Software Architecture Elements

10. What is Software Architecture? • TSQTSE “software architecture is the body of instructions written in a specific coding language that controls the structure and interaction of software modules” • SWEBOK “software architectural design (top level design): describing the top-level structure and organization and identifying the various components” • Pressman: “architectural design represents the structure of data and program components that are required to build a computer-based system”

11. What are the steps to develop the Software Architecture? • Data Design: data modeling, data structures, databases, and data warehousing • Architectural Styles: components, connectors, constraints, and semantic models • Data Centered Architectures • Data Flow architectures • Call and return architectures (main and subprograms, remote procedure calls, etc.) • Object-oriented architectures • Layered architectures

12. What are the Methods? • Architecture Trade Off Analysis Method (ATAM from SEI) • Collect Scenarios (Use Cases) • Elicit Requirements • Describe styles and patterns: module view, process view, data flow view • Evaluate quality attributes (reliability, performance, portability, testability, etc.) • Identify sensitivity of quality attributes • Critique alternatives

13. Future Trends in Architectural Design: SOA, Web Services, EA • Service-Oriented Architecture (Gartner): “Service-oriented architecture is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces." • SOA Infrastructure components • Developer Suites: JAVA, J2EE, XML, HTML • Business Process Execution Languages • File Content Management • Business Process Management • Enterprise Service Bus integration

14. Future Trends in Architectural Design: SOA, Web Services, Enterprise Architectures • Enterprise Architectures • This partially layered architecture shows how composite services are aligned with business processes, while enterprise-scale (large-grained) components realize the services. The business processes can be supported by choreography of exposed services into composite applications. This architecture is supported by several vertical layers, including: • An infrastructure layer that's commonly referred to as the Enterprise Service Bus (ESB). • A monitoring and management layer to ensure the quality of service and to achieve nonfunctional requirements. • A data architecture layer. • A governance layer.

15. Interfaces • An interface is the external “connection point” on a component or connector that describes how other components/connectors interact with it • Provided and required interfaces are important • Spectrum of interface specification • Loosely specified (events go in, events go out) • API style (list of functions) • Very highly specified (event protocols across the interface in CSP) • Interfaces are the key to component interoperability (or lack thereof)

16. How Soon to Define Interfaces? -Loss due to rework with ill defined & validated architecture Many interface defects: high P(L) Critical IF defects: high S(L) RE = P(L) * S(L) Few IF defects: low P(L) Minor IF defects: low S(L) Time spent defining & validating architecture

17. How Soon to Define Interfaces? -Loss due to rework with ill defined & validated architecture-Loss due to implementation start Many interface defects: high P(L) Critical IF defects: high S(L) Many delays: high P(L) Long delays: high S(L) RE = P(L) * S(L) Few delays: low P(L) Short Delays: low S(L) Few IF defects: low P(L) Minor IF defects: low S(L) Time spent defining & validating architecture

18. How Soon to Define Interfaces? - Sum of Risk Exposures Many interface defects: high P(L) Critical IF defects: high S(L) Many delays: high P(L) Long delays: high S(L) RE = P(L) * S(L) Sweet Spot Few delays: low P(L) Short delays: low S(L) Few IF defects: low P(L) Minor IF defects: low S(L) Time spent defining & validating architecture

19. Components Not everybody agrees on this! • A component is a building block that is … • A unit of computation or a data store, with an interface specifying the services and performance it provides • A unit within a makefile • A unit of reuse • A unit totally isolated and encapsulated • A recoverable unit

20. Differences between Components & Connectors • Task Performed • Components focus on computational tasks • Connectors focus on communication tasks • Application Semantics • Components implement application semantics • Connectors do not (they may change the form of the message, but do not change its meaning) • “Awareness” • Components (should be) unaware of who is using them and for what purpose • Connectors are more aware of components connected to them so they can better facilitate communication

21. Connectors • A connector is a building block that enables interaction among components • Shared variables • Procedure calls (local or remote) • Messages and message buses • Events • Pipes • Client/server middleware • Connectors may be implicit or explicit • Implicit: procedure calls • Explicit: First-class message buses

22. Configurations • A configuration is … • The overall structure of a software architecture • The topological arrangement of components and connectors

23. Partitioned Architecture Software Component Software Component Software Component Software Component Fault Recovery, Execution Control, Mode Control, Timing Control, Data Synchronization, Interprocess Communication Middleware Executive Special Kernel Operating Environment Embedded Hardware Target • Strong Partitioning • Timing Protection • OS Call Restrictions • Memory Protection

24. Software Architecture Lessons • A good software architecture is essential • 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.

25. 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.

26. 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

27. Overview of an Architecture Review Project team meets with Review Team Chairperson. Defines review objective. Snow Cards of Issues Review Team studies project documents and holds discussions with Systems Engineers and Architects Project Contact arranges logistics and collects project documentation Final Report Review Findings Project team prepares Functional, System Requirements, and Architecture Spec Project Affecting Issues Preparation Phase Review Phase Report Phase

28. 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.

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

30. Architecture Review Payoff • Average review pays back 12 times its cost • Reduced development effort and interval - find defects early • Higher product quality • Lower product cost • Faster less costly product evolution (planned) • Company wide learning - annual report • Yes, projects were canceled after reviews and the attitude of the project team was often surprising

31. 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

32. Requirements Findings Approximate Occurrences

33. 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’)

34. Design Findings Approximate Occurrences

35. 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.

36. 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

37. Load Projections Example Total Users 50,000

38. Architecture Description Language Thanks to Ed Colbert, USC

39. 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

40. 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

41. 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

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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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.

49. 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

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