Lecture 17 Engineering Design Resolution: Generating and Evaluating Architectures

Transcription

1 Lecture 17 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte November 4, 2008

2 Announcements D1 individual grades are posted H2 grades will be posted soon We re still grading D2 No quiz today Feel free to leave and go vote if you want But don t ask me for a recap by Ask your classmates Check the website 2

3 Lecture Overview Last time Chapter 9 Specifying Software Architectures Today Finishing up specification models Impact of quality attributes on architectural design Chapter 10 How to Generate Software Architectures 3

4 Representing Software Architecture: The 4+1 View Approach Logical View Implementation View End-user Functionality Use Case View Programmers Configuration management System integrators Performance Scalability Throughput Process View Deployment View System engineering System topology Communication Provisioning 4

5 Software Architecture Document: Architectural Models Specification of DeSCRIPTR concepts Using various models to represent different aspects or views Both static and dynamic models May be represented using text, tables, UML diagrams, box-andline diagrams We ll hear more about these coming up Section must be descriptive enough to understand how models relate to problem Essential, since will be used as basis for detailed design 5

6 Modeling Software Architectures Type of Specification Decomposition States Collaborations Responsibilities Interfaces Properties Transitions Relationships Useful Notations Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams State diagrams Sequence and communication diagrams, activity diagrams, box-and-line diagrams, use case models Text, box-and-line diagrams, class diagrams Text, class diagrams Text State diagrams Box-and-line diagrams, component diagrams, class diagrams, deployment diagrams, text 6

7 Package Diagrams UML package diagram Primary symbols are package symbols Folders with tabs Package members shown in folder, or using a containment symbol (circled plus sign) Packages and contents are related by UML dependency relations 7

8 Package Diagram Example ATM Use Cases Withdraw Money Transfer Funds Check Balance Classes? (rough sketch) Packages of related classes? 8

9 Interface Specifications Defines the mechanism that is used to communicate with environment Consist of Syntax Elements of communication and how they are combined to form messages Semantics Meaning of messages Pragmatics How messages are used to accomplish tasks Captured in part by class diagrams (syntax) Supplemented with textual descriptions 9

10 Textual Interface Specification Template 1. Services Provided For each service provided specify its a) Syntax b) Semantics c) Pragmatics 2. Services Required Specify each required service by name. A service description may be included. 3. Usage Guide 4. Design Rationale 10

11 Semantic Specification Can describe with pre- and post-conditions Together specify change in state semantics Precondition an assertion that must be true at the start of an operation Postcondition an assertion that must be true at the completion of an operation Pre- and post-conditions can together specify what happens when an operation executes 11

12 Example Device Layer Interface ValveDevice Syntax: turnon(duration d) turnon() turnoff() Semantics: turnon() Pre-condition: None Post-condition: The valve is in the on position. 12

13 UML Component Diagrams A UML component is a modular, replaceable unit 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 their internal structure ImageRenderer <<component>> ImageRenderer 13

14 UML Interfaces A UML interface is a named collection of Public attributes Abstract operations Just the operation signature name, parameters, return values Unimplemented Must be REALIZED by a class or component Note: this use of the term interface is different from our previous use More like a class that won t have a physical implementation Represented by a stereotyped class symbol Represented by special ball and socket symbols 14

15 Provided and Required Interfaces A class or component realizes an interface when it: includes its attributes 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 Combination of ball and socket symbol 15

16 Interface Symbols Example 16

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

18 Component Internals Example 18

19 Another Component Example Ordering System Use Cases Check Inventory Look up Customer Submit Order Enter Order 19

20 Component Diagram Uses Static models of software components Reusable and replaceable parts If you decide to make some parts of your design reusable, use component diagrams Model program components Architectural models Detailed design models Relationship to environment Model internal structure of components 20

21 Deployment Diagrams A UML deployment diagram models Computational resources Devices Execution environments Communication paths among them Artifacts that reside and execute on them Physical representation of data used or produced during development or operation 21

22 Use of Deployment Diagrams Used to capture Real and virtual machines used in a system Communication paths between machines Program and data files realizing the system Residence Execution 22

23 Deployment Diagram Example 23

24 Deployment Diagram Rules Computational resources are modeled as UML nodes UML symbol is stereotyped 3D box Node symbols for devices and environments Communication paths are solid lines between nodes May be labeled May have multiplicities and role names Artifact symbols are represented as stereotyped box May appear within node symbols May be listed within node symbols May be connected to node symbols by dependency arrows stereotyped with «deploy» 24

25 Summary Software Architecture Modeling software architecture (DeSCRIPTR) concepts UML component diagrams UML deployment diagrams Impact of quality attributes on architectural design Next time How to generate and evaluate software architectures Focusing on function Focusing on quality attributes 25