Software Architecture and CBSE

1. Software Architecture and CBSE CEN6502, Spring 1998, (c) Yi Deng

2. Software Architecture The software architecture of a program or system is the structure or structures of the system, which comprise software components, the externally visible properties of these components, and the relationships among them. CEN6502, Spring 1998, (c) Yi Deng

3. Where Do Architectures Come From • Architectures are influenced by system stakeholders (fig.1.2) • Influenced by technical and organizational factors • Customers and end users (cost, performance, platform compatibility, security, modifiability, interoperability with other systems, etc.) • Developing organization. (immediate business, long term business, and organizational structure.) • Background and experience of the architects. • Technical environment (industry standard practices, prevalent SE techniques at the time of development.) • Architecture issues are orthogonal to system functionality or functional requirements. CEN6502, Spring 1998, (c) Yi Deng

4. Architecture Business Cycle • Organizational goals influence requirements • Requirements lead to an architecture • Architecture yield systems • Systems suggest future new organizational capabilities and requirements. CEN6502, Spring 1998, (c) Yi Deng

5. The Feedback Cycle • Architecture can affect the structure and enterprise goals of the developing organization. • Can affect the customer requirements for the next system • Will affect the architects’ experience and perception • Some systems will influence and actually change the SE culture and practice, e.g. CORBA, Java, WWW CEN6502, Spring 1998, (c) Yi Deng

6. What Is and Is Not Software Architecture • Typical, but uninformative, presentation of a top-level architecture (fig. 2.1.) • Information not conveyed by the structure: • The nature of the components • Significance of the links • Significance of the layout • How does the architecture operate at runtime. CEN6502, Spring 1998, (c) Yi Deng

7. Software Architecture The software architecture of a program or system is the structure or structures of the system, which comprise software components, the externally visible properties of these components, and the relationships among them. CEN6502, Spring 1998, (c) Yi Deng

8. What an Architecture Should Convey • Architecture defines components • Systems can comprise more than one structure and no one structure is the architecture • The behavior of each component is part of the architecture CEN6502, Spring 1998, (c) Yi Deng

9. Styles, Reference Models and Reference Architectures • An architecture style is a description of component types and a pattern of their runtime control and/or data structure, a set of constraints on an architecture. E.g. client-server • A reference model is a division of functionality together with data flow between components, a standard decomposition of a known problem into parts that cooperatively solve the problem • A reference architecture is a reference model mapped onto software components (that will cooperatively implement the functionality defined in the reference model) and data flows between the components • (Reference Model + Architectural Style)  Reference Architecture  Software Architecture  System Architecture CEN6502, Spring 1998, (c) Yi Deng

10. Why is Software Architecture Important • Communication among stakeholders • Represents common high-level abstraction of a system • Early design decisions • Earliest point at which the system to be built can be analyzed • Carry weight that is essential to the cost and success of project • Transferable abstraction of a system • Key to extension, migration and evolution • Basis for large-scale reuse CEN6502, Spring 1998, (c) Yi Deng

11. Architecture Manifests Early Design Decisions • Defines constraints on an implementation • Implementation must be divided into prescribed components, which interact with each other in the prescribed fashion, and each component must fulfill its responsibility to the other components as dictated by the architecture • Dictates organizational structure • As the basis for work-breakdown structure • WBS in turn dictates unit planning, budget, scheduling, inter-team comm channels, configuration control, integration/testing procedures, etc. CEN6502, Spring 1998, (c) Yi Deng

12. Early Design Decisions • Inhabits a system’s quality attributes • For large systems, quality attributes are increasingly satisfied in system structure and division of functionality, rather than in its algorithms and data structures • E.g., modifiability depends heavily on modularization, performance on volume and nature of communication between components, reusability on nature of coupling • Architecture alone cannot guarantee the functionality and quality required of the system CEN6502, Spring 1998, (c) Yi Deng

13. Early Design Decisions • Predicting system qualities by studying its architecture • Makes it easier to reason about and manage change • Helps in evolutionary prototyping • Potential performance problems can be identified early in the product’s life cycle • The system is executable early on • Helps to reduce potential risk in the project early on CEN6502, Spring 1998, (c) Yi Deng

14. Architecture as a Transferable, reusable model • Product lines share a common architecture -- domain specific software architecture • Systems can be built by using large, externally developed components • Focussing on composing or assembling components, as opposed to programming • Not in mature stage of practice, problem of architectural mismatch • Make explicit of architectural context, build wrappers to bridge the gap • Less is more: it pays to restrict the vocabulary of design alternatives CEN6502, Spring 1998, (c) Yi Deng

15. Architectural Structures • Table 2.1., p38. CEN6502, Spring 1998, (c) Yi Deng

16. Air Traffic Control - A Case Study • Purpose: to get a sense of what’s involved in architectural level design • Among the most demanding of all software applications • Hard real-time: timing deadlines must be met absolutely • Safety-critical: human life is at stake if the system does not perform correctly • Highly distributed: requiring dozens of controllers to work together to guide aircraft through the airways system • ATC is a multibillion-dollar undertaking CEN6502, Spring 1998, (c) Yi Deng

17. ATC • Controlled by FAA • Typical flight process (fig. 11.1,2) • Ground control coordinates the movement of aircraft on the ground at an airport • Towers control aircraft flying within an airport’s terminal control area • En route centers divide the skies over the country into 22 large sections of responsibilities CEN6502, Spring 1998, (c) Yi Deng

18. Initial Sector Suite System (ISSS) • Intended to be an upgraded hardware/software system for the 22 en route centers • One part of a planned, much larger, government procurement for next generation ATC system for US (AAS) • This fact has profound impact on its architecture - great incentive to adopt common designs and components where possible, e.g. interfaces to radio systems, to flight plan DBs, to each other, interpreting radar data, requirements for reliability and performance, etc. CEN6502, Spring 1998, (c) Yi Deng

19. Sense of Scale • Support up to 210 consoles per en route center. Each console contains a workstation-class processor (IBM RS/6000) • Each center controls 400-2440 separate aircraft tracks simultaneously • 16-40 radars to support a single facility • A center can have 60-90 control positions each with one or several devoted consoles. CEN6502, Spring 1998, (c) Yi Deng

20. Requirements and Qualities • Ultrahigh availability: system is absolutely prohibited from being inoperative for longer than very short periods of time (99.999%) • High performance: system has to be able to process large number of aircraft without “losing” any of them • Openness - can be integrated with other (software/hardware) systems • Ability to field subsets of the system in case of budget cut • Ability to make changes to functionality and handle upgrades • Ability to operate with and interface to a bewildering set of external systems, some decades old and others not yet implemented • Must satisfy a great number of stakeholders, particularly the controllers CEN6502, Spring 1998, (c) Yi Deng

21. Requirements • Acquire radar target reports that are stored in an existing ATC system (HCS) • Convert the radar reports for display and broadcast to all consoles • Handle conflicting alerts or other data transmitted by HCS • Interface to HCS for input and retrieval of flight plans • Provide extensive monitoring and control information, e.g. network management, to allow site administrators to reconfigure the installation in realtime. • Providing recording capability to later playback • Providing general GUO facilities • Provide reduced backup capability in the event of HCS, primary networks or primary radar sensors failures CEN6502, Spring 1998, (c) Yi Deng

22. Architectural Approach • Distributed multiprocessor systems, and a front-end effort for schedulability analysis • Message-based systems serving as a unifying paradigm under which each unit can determine its processing requirements based on set of messages it is allowed to receive • Client-server architectures meant to promote modularity, strong cohesion and loose coupling • Built-in redundancy. Both software and hardware • Table-driven start-up configuration providing the capability to configure the ISSS for different sites without changing the code. • Patterns of software to promote reuse, to minimize necessary creativity and to improve maintainability and easier extension CEN6502, Spring 1998, (c) Yi Deng

23. ISSS System Architecture • Fig. 11.5. • HCS heart of the en route automation system. Two host computers with primary/backup setup. • Common consoles are controllers’ workstations • Connected via LCN - four parallel token rings connected by bridges for redundancy and to balance load • The Enhanced Direct Access Radar Channel (EDARC) provides backup display of aircraft position and limited flight data (raw radar data) • Backup Comm Network (BCN) - Ethernet using TCP/IP, used for other functions besides EDARC, and backup for LCN • Both LCN and BCN have associated Monitor & Control (M&C) consoles for monitoring and maintenance • Test and Training subsystem for testing new hardware/software and for training personnel without interfering with ATC mission CEN6502, Spring 1998, (c) Yi Deng

24. ISSS Software Architecture • Architecture affects behavior, performance, fault-tolerance, and maintainability • Architecture is shaped by stringent requirements in any of these areas • Dominant factor: ultrahigh system availability requirement • Two classes of software: • Operational software facilitates ATC • Support software helps to generate, develop, install and initialize operational software • Roughly same size CEN6502, Spring 1998, (c) Yi Deng

25. ISSS Components • Computer Software configuration items (CSCI), defined by government software development standard, largest components, primarily for work assignments • Display management (350K lines) • Common system services (345K), general utilities • Recording, analysis and playback (31K) for capturing ATC sessions for later analysis • National Airspace System Modification entailing a modification of software resides on HCS • The IBM AIX OS CEN6502, Spring 1998, (c) Yi Deng

26. ISSS Components • Applications. Each corresponds to a process in the sense of Dijkstra’s CSP, and is at the core of the approach the ISSS designers adopted for fault tolerance. (fig.11.6) • ISSS constructed to operate on a process group • Each process group hosts a separate copy of one or more applications, one executing copy is primary (primary address space(PAS)), the others are secondary (standby address space(SAS)), together called an operational unit • Functional group (FG) non-fault-tolerant applications, run independently on different processors • Applications interact with each other in a client-server fashion • Switch over between PAS and SAS CEN6502, Spring 1998, (c) Yi Deng

27. ISSS Components • Programming Language Entities • Applications (operational units and functional groups) are decomposed into Ada packages. • Packaging is a design activity intended to embody abstraction and information hiding, and carried out by an operational unit’s chief designer • Threads • Consists of software, executing as one or more CSP, that fulfills a logically related piece of functionality • Form the basis for test plan, and in fact formed the basis for defining major deliverable versions of ISSS software CEN6502, Spring 1998, (c) Yi Deng

28. ISSS Connections • Message based • Almost no Ada rendezvous or other synchronization operations for meeting hard deadlines • Fig. 11.8 CEN6502, Spring 1998, (c) Yi Deng

29. ISSS As A Layered Architecture • Fig. 11.10 CEN6502, Spring 1998, (c) Yi Deng

30. Fault Tolerance • Cold restart of the system is out of question • Immediate switch-over seemed best approach • Fault tolerant hierarchy architecture (Fig. 11.11) - describes how faults are detected and isolated and how the system recovers • PAS/SAS scheme traps and recovers errors in a single application • Fault tolerant hierarchy traps and recovers from cross application errors • Each level is meant to produce another increment in system availability above that produced by lower levels. Each level asynchronously • Detects errors in self, peers, lower levels • Handles exceptions from lower levels • Diagnoses, recovers, reports and raises exceptions CEN6502, Spring 1998, (c) Yi Deng

31. Fault Tolerance • FT Levels • Physical (network, processor, and I/O devices • OS • Runtime environment • Application • Local Availability • Group Availability • Global Availability • System monitor and control CEN6502, Spring 1998, (c) Yi Deng

32. Fault Tolerance • At each level • Fault detection (and isolation) is performed by built in tests, event timeouts, network circuit tests, group membership protocol, and as a last resort, human reaction to alarms and indicators • Fault recovery is performed, and can be manual or automatic. For local, group, and global availability managers, the recovery methods are table-driven • Four types of recovery: • In a switchover, the SAS takes over almost immediately from its PAS • A warm restart uses checkpoint data • A cold restart uses default data and loses state history • A cutover is used to transition to new (or old) logic or adaptation data CEN6502, Spring 1998, (c) Yi Deng

33. Exploiting Patterns in Software Architecture • A pattern is a small collection of atomic units and a description of their relationships • In OO design, a pattern is a collection of object classes and the inheritance and uses relationship among them • A pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it. • Patterns document existing, well-proven design experience • Patterns allow us to understand complex systems in larger conceptual chunks • E.x. Windows GUI, and more generally Model-View-Controller pattern of GUI design (p.5Buschmann). CEN6502, Spring 1998, (c) Yi Deng

34. What Makes A Pattern • Context - specification of situations in which the problem occurs. Critical to the usability of patterns • Problem - describe the problem that arises repeatedly in the given context • Requirements the solution must fulfill, e.g. that peer-to-peer IPC must be efficient to certain extent • Constraints you must consider, e.g. IPC must follow certain protocol • Desired properties that the solution should have, e.g. support extensibility CEN6502, Spring 1998, (c) Yi Deng

35. What Makes A Pattern (cont’d) • Solution - shows how to solve the recurring problem, or better, how to balance the forces associated with it. • Pattern structure, a spatial configuration of elements, stress static aspects of the solution • Runtime behavior, addresses dynamic aspects of the solution. • E.g. Model-View-Controller patterns includes the following statement: “Controllers receives input, usually as events that denote mouse movement, activation of mouse buttons, or keyboard input. Events are translated to service requests, which are sent either to the model or to the view”. CEN6502, Spring 1998, (c) Yi Deng

36. Component-Based Development and Architecture • Develop systems from existing components • Buy, don’t build. Shift emphasis from programming software to composing software systems • Benefits • Being able to take faster advantage of new products and new technology • Significantly reduced time-to-market because of off-the-shelf components are ready to use • Higher employee productivity, with emphasis not on coding but on reusing and integrating • More reliable components because the components more likely be used, tested and validated in multiple systems • More changeable and extensible systems because more attention will be paid on component interface and independence, and system architecture • More benefits will be yielded if the components conform to community wide standards CEN6502, Spring 1998, (c) Yi Deng

37. Issues in CBSD • Increasing component size and complexity. Wide range of COTS components available: OS, DBMS, network managers, CASE tools, ORBs, or domain specific middlewares. • “Buying” means less control on every aspect of a system’s development. • How can this loss of control be reconciled with our desire for quality? • Part of answer lies in the assertion that, for larger systems, quality lives primarily in the architecture • The other part of answer: One must take care to integrate components so that they don’t compromise the architecture and the qualities it helps to manifest CEN6502, Spring 1998, (c) Yi Deng

38. Issues in CBSD • Architecture Mismatch, a special case of interface mismatch. Not all components work together - even if they claim to • Components are often “almost” compatible, where “almost” is a euphemism for not • More insidious: components appear to work together - the assembled code compiles and even executes - but the system produces the wrong answer because the components don’t work together as expected • Components that were not developed specifically for your system may not meet all of your requirements • Worse, you may not know if they are suitable or not until your buy them and try them, because component interfaces are notoriously poor at specifying their quality attributes CEN6502, Spring 1998, (c) Yi Deng

39. Issues in CBSD • Interface - assumptions that the components can make about each other • Interface = Provides + Requires (+ side affects) , or Syntax + Semantics • Unfortunately, this definition goes beyond what has become the normal concept of interface in current practice. • What can you do? • Avoid it by carefully specifying and inspecting the components for your system • Detect those cases you have not avoided by carefully qualification of the components • Repair those cases you’ve detected by adapting the components CEN6502, Spring 1998, (c) Yi Deng

40. Techniques for Repairing Interface Mismatch • Change the code: often not possible and desirable • Wrappers. • A form of encapsulation whereby some component is encased within an alternative abstraction • Clients access wrapped component services only through an alternative interface provided by the wrapper • Interface translation include: • Translating an element of a component interface into an alternative element • Hiding an element of a component interface • Preserving without change of an element of a component’s interface • CORBA IDL can be used to specify the new interface CEN6502, Spring 1998, (c) Yi Deng

41. Techniques for Repairing Interface Mismatch • Bridges • Will translate between some requires assumptions of an arbitrary component to some provides assumptions of some other arbitrary component • Key difference with wrapper: the repair code is independent of any particular component, must be explicitly invoked by some external agent, and is typically a transient process • Typically focus on narrower range of translation than wrappers do • E.g. bridge from postscript generator to PDF display CEN6502, Spring 1998, (c) Yi Deng

42. Techniques to Avoid Interface Mismatch • Disciplined approach to specifying as many assumptions about a component’s interface as is feasible • Assertions about the sufficiency of services • Assumptions about environment behavior • Assertions about implementability or resource requirements CEN6502, Spring 1998, (c) Yi Deng