Lecture 16: (Architecture IV)

Transcription

1 Lecture 16: (Architecture IV) Software System Design and Implementation ITCS/ITIS 6112/ Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct. 28,

2 Announcements D3 Original deadline: Nov. 11 Extended deadline: Nov. 18 Updated template will be provided tomorrow Team/instructor meetings Define emphasis on prototype vs. documentation for final deliverable 2

3 Software Architecture Definition Architecture defines major components component relationships (structures) component interactions Architecture encompasses the significant decisions about the organization of a system Architecture defines the rationale behind the components and the structure 3

4 More Architectural Design Decisions How will the architectural design be evaluated? How should the architecture be documented? 4

5 Quality Attributes Performance Availability Usability Security End User s view Time To Market Cost and Benefits Projected life time Targeted Market Integration with Legacy System Roll back Schedule Business Community view Maintainability Portability Reusability Developer s view Testability 5

6 Architecture and Quality Attributes Performance Localize critical operations and minimize communications Use large rather than fine-grain components Security Use a layered architecture with critical assets in the inner layers Safety Localize safety-critical features in a small number of sub-systems Availability Include redundant components and mechanisms for fault tolerance Maintainability Use fine-grain, replaceable components 6

7 Architectural Conflicts Large-grain components improves performance reduces maintainability Redundant data improves availability makes security more difficult. Localizing safety-related features simplifies security more communication so degraded performance. 7

8 Evaluating Architectural Design Two example approaches: Architectural Complexity Evaluation A general approach Architecture Tradeoff Analysis Method (ATAM) 8

9 Architectural Complexity Evaluation Consider dependencies between components Want architectural with minimal dependencies Types of dependencies Coupling-related dependencies Sharing dependencies Use the same resource Produce for same consumers Flow dependencies Relationships between consumers and producers of resources Component A must complete before control goes to B Component A communicates with B using parameters Constrained dependencies Constraints on relative flow of control among activities Component A and B cannot execute at the same time 9

10 Architecture Tradeoff Analysis Method (ATAM) A comprehensive approach to evaluating a software architecture Focuses on evaluating how well architecture satisfies quality goals Recognizes that architectural decisions often impact more than one quality attribute 10

11 ATAM Outputs Concise presentation of architecture Quality requirements captured in collection of scenarios Mapping of architectural decisions to quality requirements Set of identified sensitivity and tradeoff points Set of risks and non-risks Related to architecture Set of risk themes 11

12 Using ATAM A simplified version: 1. Collect scenarios and use cases Quality scenarios and change scenarios 2. Elicit requirements, constraints, environment description 3. Describe candidate architectures Describe architectural approaches (styles, etc.) 4. Evaluate quality attributes Consider each in isolation Identify sensitivity to various architectural attributes 5. Critique candidate architectures using sensitivity analysis Determine acceptable trade-offs 12

13 ATAM: Utility Tree A top-down vehicle for characterizing the driving quality attribute-specific requirements Used in ATAM to identify, prioritize, and refine the most important quality attribute goals Creating a utility tree Utility is always root node Expression of overall goodness of system Measured by composition of quality attributes Second tier nodes are quality attributes Select the most important quality goals Typically performance, modifiability, security, and availability These can be further refined Quality scenarios are the leaves of the utility tree 13

14 Example Utility Tree 14

15 ATAM: Quality Attribute Scenarios Scenarios are used to Represent stakeholders interests Understand quality attribute requirements Scenarios are captured as leaves of a utility tree Scenarios should cover a range of Anticipated uses of (use case scenarios), Anticipated changes to (growth scenarios), or Unanticipated stresses (exploratory scenarios) to the system. A good scenario makes clear what the stimulus is that causes it and what responses are of interest 15

16 ATAM: Scenario Examples Use case scenario Remote user requests a database report via the Web during peak period and receives it within 5 seconds Growth scenario Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week Exploratory scenario Half of the servers go down during normal operation without affecting overall system availability. 16

17 ATAM: Analyzing Candidate Architecture Architecture is evaluated in terms of quality attributes using utility tree Approaches are identified that pertain to the highest priority quality attribute requirements Identify and evaluate: Sensitivity points and tradeoffs Risks and non-risks 17

18 ATAM: Sensitivity & Tradeoffs Sensitivity A property of a component that is critical to success of system Examples: Performance sensitivity The number of simultaneous database clients will affect the number of transaction a database can process per second. Security sensitivity Number of bits of the encryption key Tradeoff point A property that affects more than one attribute or sensitivity point Examples Performance vs. Portability Use of assembly language Performance vs. Reliability Use of back-up database 18

19 Addressing Quality Attributes in Architecture Design So, now we know how to evaluate quality attributes How can we design for them in the first place? Use Attribute Driven Design (ADD) method Styles, patterns, and tactics! Tactics are strategies to address particular types of quality attributes Example To promote availability, embrace redundancy We ll discuss several tactics in an upcoming lecture 19

20 More Architectural Design Decisions How will the architectural design be evaluated? How should the architecture be documented? 20

21 Architectural Models Architecture is documented from many perspectives (views) Static structural model Shows the major system components Dynamic process model Shows the process structure of the system Interface model Defines component interfaces Relationships model Shows component relationships Distribution model Shows how components are physically distributed across computers 21

22 Notations for Architectural Specifications Type of Specification Static Structural Model Dynamic Process Model Interfaces model Relationship model Distribution model Useful Notations Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams State diagrams, sequence diagram, collaboration diagrams, activity diagrams, box-and-line diagrams, use case models Text, class diagrams Box-and-line diagrams, component diagrams, class diagrams, text Deployment diagrams 22

23 Package Diagrams A UML package diagram represents containment relationships for related modules Useful for primary containment symbol is package symbols Static models of modules, their parts, and their relationships 23

24 Package Diagram Example 24

25 UML Dependency Relations A dependency relation holds between two entities D and II when a change in in I I (the independent entity) may affect D (the dependent entity). Examples: D uses I, D depends for compilation on I, D imports I Represented by dependency arrows: stereotyped dashed arrows 25

26 Dependency Relation Example 26

27 Software Components A software component is a reusable, replaceable piece of software Component-based development Products are designed and built using commercially available or custom-built software components 27

28 UML Component Diagrams A UML component is a modular, replaceable unit with well-defined interfaces. Component symbols are rectangles containing names Stereotyped «component» or have component symbol in upper right-hand corner UML component diagram Shows components their relationships to their environment and their internal structure 28

29 UML Interfaces A UML interface is a named collection of public attributes and abstract operations Represented by a stereotyped class symbol (later) Represented by special ball and socket symbols Note: this use of the term interface is different from out previous use as a communications boundary More like interface = class without implementation 29

30 Provided and Required Interfaces A class or component realizes an interface when it includes its attributes and implements its operations Provided interface Realized by a class or component Represented by a ball or lollipop symbol Required interface Needed by a class or component Represented by a socket symbol The assembly connector wires interfaces together 30

31 Interface Symbols Example 31

32 Component Internal Structure Components can contain other components or classes showing how they are built A delegation connector ties a component interface to one or more internal classes or components that realize or use the interface Solid arrows Stereotyped with «delegate» 32

33 Component Internals Example 33

34 Component Diagram Uses Static models of software components (reusable and replaceable parts) Model program components Architectural models Detailed design models Relationship to environment Model internal structure of components 34

35 Deployment Diagrams A UML deployment diagram models computational resources, communication paths among them, and artifacts that reside and execute on them. Used to show Real and virtual machines used in a system Communication paths between machines Program and data files realizing the system Residence Execution 35

36 UML Nodes A UML node is a computational resource. Device physical processing unit, such as a computer Execution environment software system that implements a virtual machine, such as an operating system or language interpreter Represented in UML by box or slab symbols Stereotyped with «device» or «execution environment» Types and instances Types have names Instance have underlined labels of the form name : type Name or type may be suppressed, but not both 36

37 Node Symbols Example 37

38 Deployment Diagram Rules Computational resources are nodes Communication paths are solid lines between nodes May be labeled May have multiplicities and role names Artifact symbols may Appear within node symbols Be listed within node symbols Be connected to node symbols by dependency arrows stereotyped with «deploy» 38

39 Deployment Diagram Example «device» ServerPC «artifact» GameServer 1 * «device» ClientPC TCP/IP RMI «deploy» «device» GameDataServer «DB» GameData Rules BoardImage TokenImage «artifact» GameClient 39