Why Document the Architecture? EEC 421/521: Software Engineering. Design Process. Thinking About Design. Stakeholder Communication.

Transcription

1 Why Document the Architecture? EEC 421/521: Software Engineering Architectural Design Stakeholder Communication High-level presentation of system System Analysis Big effect on performance, reliability, maintainability, and other -ilities Large-scale Reuse Similar requirements similar architecture 3/4/08 EEC 421/521: Software Engineering 1 3/4/08 EEC 421/521: Software Engineering 3 Design Process Large systems are decomposed into subsystems Sub-systems provide related services Initial design process includes Identifying sub-systems Establishing a framework for sub-system control and communication Thinking About Design Architectural design forces thought about key design aspects Software architecture used as: Design plan to negotiate requirements Means of structuring discussions with managers, clients, etc Complexity management hides detail; encourages abstraction 3/4/08 EEC 421/521: Software Engineering 2 3/4/08 EEC 421/521: Software Engineering 4

2 Subsystem Design Abstract decomposition of a system into large-grain components Block diagrams are especially useful Each box represents a sub-system Boxes within boxes shows decomposition of subsystems Arrows indicate flow of data or control Block Diagrams: Pros and Cons Box-and-line diagrams not communicative enough to show relationships among components to show externally-visible properties Great for effective communication stakeholders can understand abstract view managers can plan people and assignments 3/4/08 EEC 421/521: Software Engineering 5 3/4/08 EEC 421/521: Software Engineering 7 Subsystem Design Example: Robotic Packing system Architectural Design Languages ADLs, used to describe software architecture Basic elements: components, connectors Include rules and guidelines for well-formed architectures Problem: specialized; not generally applicable Informal models like UML remain popular 3/4/08 EEC 421/521: Software Engineering 6 3/4/08 EEC 421/521: Software Engineering 8

3 System Organization Client-Server Example Overall organizational model of entire system Three popular styles: Repository Shared services and servers Abstract machine (layered) 3/4/08 EEC 421/521: Software Engineering 9 3/4/08 EEC 421/521: Software Engineering 11 Repository Example Layered Model Example 3/4/08 EEC 421/521: Software Engineering 10 3/4/08 EEC 421/521: Software Engineering 12

4 Module vs. Sub-System Sub-system System in its own right Does not depend on other sub-systems Includes modules with defined interfaces Module System component; provides services Uses other modules services Not a complete system by itself Object-Oriented Decomposition 3/4/08 EEC 421/521: Software Engineering 13 3/4/08 EEC 421/521: Software Engineering 15 Decomposition Strategies Object-Oriented Decomposition. Set of communicating objects, with private state and operations defined on that state. Function-Oriented Pipelining. Functional modules that transform input data into output data Function-Oriented Pipelining Functional transformations process inputs and produce outputs Data flow model: Data flows from one transformer to next. Ordering of transformers is important Transformers may execute in sequence or in parallel May also include batch processing 3/4/08 EEC 421/521: Software Engineering 14 3/4/08 EEC 421/521: Software Engineering 16

5 Function-Oriented Pipelining Centralized Control Call-return Model. Top-down subroutine model. Control starts at top of hierarchy. Only applicable to sequential systems. 3/4/08 EEC 421/521: Software Engineering 17 3/4/08 EEC 421/521: Software Engineering 19 Control Styles Centralized Control. One sub-system has overall control Event-based Control. Each sub-system responds to external events Centralized Control Manager Model. System manager controls starting, stopping, and coordination of other processes. Also supports concurrent systems. 3/4/08 EEC 421/521: Software Engineering 18 3/4/08 EEC 421/521: Software Engineering 20

6 Event-Based Control Broadcast Models. Event is broadcast to all (or some) sub-systems; some will respond. Non-functional Requirements Performance. Localize critical operations; decrease communication; large-grain components Security. Layered structure Safety. Localize safety validation Availability. Redundancy; dynamic reconfigurability Maintainability. Fine-grain components; no shared data structures 3/4/08 EEC 421/521: Software Engineering 21 3/4/08 EEC 421/521: Software Engineering 23 Event-Based Control Interrupt-Driven Models. External interrupt seen by handler, and passed to some specific component(s) for processing. Overlapping -ilities Potential conflict between architectures Ex. fine-grain for maintainability vs. large-grain for performance. Possible solution: different styles for different sub-systems 3/4/08 EEC 421/521: Software Engineering 22 3/4/08 EEC 421/521: Software Engineering 24

7 Quality Attributes Business considerations determine quality attributes These are over and above functionality It s not enough to build just any functional system What systems do you Like? Think of all the software systems you use (mail programs, editors, compilers, etc). Make a list. Pick the one you like the most. 3/4/08 EEC 421/521: Software Engineering 25 3/4/08 EEC 421/521: Software Engineering 27 Functionality and Architecture Functionality and quality attributes are orthogonal I can build a horribly inefficient, correct program Functionality is independent of the structure of the system! I can build a monolithic program The whole idea behind software architecture is to see how functionality interacts with other qualities Why do you like it? Write down why you like your favorite system. What is it about this system that provides your desired attribute? 3/4/08 EEC 421/521: Software Engineering 26 3/4/08 EEC 421/521: Software Engineering 28

8 Some Example Qualities Usability Modifiability Performance Productivity Many of these cannot be quantified. So how to state them as requirements? Kinds of Qualities System qualities. e.g., Secure Business qualities. e.g., Time to market Architectural qualities e.g., Conceptual integrity 3/4/08 EEC 421/521: Software Engineering 29 3/4/08 EEC 421/521: Software Engineering 31 Some Observations Architecture is critical to achieving qualities Architecture by itself cannot achieve qualities In complex systems, qualities can never be achieved in isolation Example: Portability requires highly modular system, but that hurts performance Quality Attribute Scenario A scenario is a short story, a narrative. It may have a set format or be free form A Quality Attribute Scenario has six parts: Source of stimulus Stimulus Environment Artifact Response Response measure 3/4/08 EEC 421/521: Software Engineering 30 3/4/08 EEC 421/521: Software Engineering 32

9 Performance Quality Scenario 3/4/08 EEC 421/521: Software Engineering 33 Modifiability Quality Scenario 3/4/08 EEC 421/521: Software Engineering 34