SE310 Analysis and Design of Software Systems

Transcription

1 SE310 Analysis and Design of Software Systems Lecture 4, Part-1 Architectural Design January 29, 2018 Sam Siewert

2 Architecture and Design Patterns Focus on What is Being Designed and Built OO Has Goal of Design and Software Re-Use Encapsulation of Data and Operations Class Hierarchy and Object Instances Well Understand Use Cases Well Understand Interaction Between Objects Study 4 Key System Types 1. Interactive E.g. GUI, CLI 2. Event Driven E.g. Anit-lock Breaking System Software 3. Transformational E.g. Image Processing, Encode/Decode [MPEG Digital Video, RAID] 4. Transaction Oriented E.g. DBMS Sam Siewert 2

3 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Four Common Types of Systems a b c a b a/x c/z b/y x y c z (a) Interactive subsystem (b) Event-driven subsystem (c) Transformational subsystem (d) Database subsystem 6-3

4 Architectural Design Transition from Requirements, Supports Requirements Analysis, Supports Design Activity Focus on Domain Analysis, Use Cases and Higher Levels of System Rather than Details UML Use Cases Interaction Diagrams Class Diagrams Basic Class Hierarchy (Draft of Class Definitions) SA/SD Dataflow, ER/EER Diagrams, High Level State Machines (Flowcharts are Typically Too Detailed) Sam Siewert 4

5 Traditional SA/SD Useful, But Not OO Data Flow Diagrams Data [Messages] Between Processes and is Transformed Stores, Flows, Processes, External Entities Entity Relationship Diagrams Lacks Operations, but Defines Entities [Objects] and Relationships State Machines [in Common, but Typically for Each Process in DFD] Flow-Charts Detailed Procedural Design [Interaction, Logic] Sam Siewert 5

6 Domain Models Use Case Details UML is Universal Modeling Language [OMG, UML.org] Use to Support Requirements Analysis Start Here! USE Modelio 3.7 SD as your DESIGN TOOL OMG UML 2.5 Standard Structural Diagrams Start with Class Diagram and CRC Then Object Diagram Package and Deployment Behavioral Diagrams Start with Use Case Diagram Interaction Sequence Diagram after Class and Object Done Add State Machine and Activity Diagrams for concurrency and statefulness Helpful Validation and Verification Features for Design Integrated Models Checklists Completeness CPP and Java Code Generation Sam Siewert 6

7 Tool-Based Activities Bring Up Modelio and Start Entering ATM Design Use Case and Class Diagram, Compare to UML Reference Versions of UML 2.5 Current, UML 2.5 Spec, UML General Minute Paper #2 Do Design Tools Really Assist with Software Quality Assurance? Sam Siewert 7

8 Key Takeaway Points Domain modeling is a conceptualization process to help the development team understand the application domain. Five easy steps: collecting information about the application domain; brainstorming; classifying brainstorming results; visualizing the domain model using a UML class diagram; and performing inspection and review. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 5-8

9 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Domain Modeling in the Methodology Context Business goals & needs Current situation Preliminary requirements Abstract & high level use cases, use case diagrams Acquiring Requirements (Domain Modeling) Deriving Use Cases from Requirements Allocating Use Cases & Subsystems to Iterations Use case-iteration allocation matrix Producing an Architecture Design Software architecture Accommodating Customer Requirements Change feedback Iteration use cases Domain model Domain Modeling Use case-iteration allocation matrix Actor-System Interaction Modeling Behavior Modeling & Responsibility Assignment Behavior models Deriving Design Class Diagram Expanded use cases & UI design Test Driven Development, Integration, & Deployment Domain model Design class diagram (a) Planning Phase (b) Iterative Phase activities during each iteration control flow data flow control flow & data flow 5-9

10 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Architectural Design Process Determine Design Objectives Architectural Styles Repository Apply an Architectural Style partial design design objectives Determine Type of System [architectural style available] [architectural style not available] Specify Subsystem Functions, Interfaces & Interaction Behavior Review the Architectural Design Types of System & Characteristics Perform Custom Architectural Design partial design feedback 6-10

11 Assignment #2 Domain Models Learning Objectives Value of UML for Requirements Analysis Completeness Design Walk-throughs Validation [Are We Building the Right Thing?] Verification [Are We Building it Right?] New Design, Client-Server [Cloud] Architectural Pattern Storage-as-a-Service The Competition, E.g. Drop-Box, Amazon S3, Google Cloud Storage The Concept Archive for Unstructured Files (Photos, Documents, Bits ), Not Code, Not DBMS Sam Siewert 11

12 The Requirements Capabilities Focus 1. Store Any Number of Files (name space) Up to N Gbytes in an Archive, Browse on Web or Windows, Mac, Linux File Explorer 2. Protect with RAID Against Single Erasure (Covered in CS317, SE420) 3. Submit and Retrieve Any File by Name, Time and Date Archived (In Case of Duplicate Names) Sam Siewert 12

13 Assignment #2 Goals Consistent and Complete UML Design Domain Model Focus -Ready for Validation and Verification Walkthrough Ideally Capable of C++ or Java Class Code Generation We Will Walk-through Design for Assignment #3 More In Depth Use of Modelio or ArgoUML Better Understanding of UML 2.4 Use Case, Component, Class, Interaction Diagrams [2 From Behavior Side, 2 From Structure Side of UML] Sam Siewert 13

14 CRC Class Responsibility Collaborator [SE300 Review] Create a Set of Index Cards with Proposed Classes, Responsbilities for the Class and Collaborators (has an Association Useful Step Prior to Class Diagram and Class Definitions Not Officially Part of UML, but Useful Supporting Method SE300 Week-5 slides #7 - #18 Sam Siewert 14

15 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Domain Modeling Steps 2. Brainstorming 1.Collecting application domain information 5. Reviewing the domain model. 3. Classifying brainstorming result 4. Visualizing the domain model 5-15

16 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Tip for Domain Modeling Do not do brainstorming and drawing at the same time. The result could be very poor. 1) Team brainstorming: List the concepts, and then classify them on a whiteboard. 2) Take a picture(s) of the whiteboard using a digital camera. 3) the digital images to team members. 4) Have a member or two to convert the result to a UML class diagram. 5) the UML class diagram to all members to review. 6) Modify the diagram to reflect corrections and comments. 5-16

17 RAID Archive Systems - Multiple Disk Drives Disk Drives Fail Like a Light-bulb MTBF of 100 s of Thousands of Hours [3 to 5 Years at Duty Cycle] Difficult to Determine When Failure Might Occur The Larger the Population, the More Often Failures will be Seen Disk Drives Have Low Random Access [100 to 200 I/Os per Second] Idea Write to them in Parallel and Mirror Data to Protect Against HDD Failures (Erasures) Sam Siewert 17

18 RAID-10 A1,A2,A3, A12 RAID-0 Striping Over RAID-1 Mirrors RAID-1 Mirror RAID-1 Mirror RAID-1 Mirror A1 A4 A7 A10 A1 A4 A7 A10 A2 A2 A3 A3 A5 A5 A6 A6 A8 A8 A9 A9 A11 A11 A12 A12 Sam Siewert 18

19 RAID Operates on LBAs/Sectors SAN/DAS RAID (Sometimes Files) NAS Filesystem on top of RAID RAID-10, RAID-50, RAID-60 Stripe Over Mirror Sets Stripe Over RAID-5 XOR Parity Sets Stripe Over RAID-6 Reed-Soloman or Double-Parity Encoded Sets EVEN/ODD Row Diagonal Parity Minimum Density Codes (Liberation) Reed-Solomon Codes Sam Siewert 19

20 RAID5,6 XOR Parity Encoding MDS Encoding, Can Achieve High Storage Efficiency with N+1: N/(N+1) and N+2: N/(N+2) 100.0% 90.0% 80.0% 70.0% Storage Efficiency 60.0% 50.0% 40.0% 30.0% RAID6 RAID5 20.0% 10.0% 0.0% Number of Data Devices for 1 XOR or 2 P,Q Encoded Devices Sam Siewert 20

21 RAID-50 A1,B1,C1,D1,A2,B2,C2,D2,E1,F1,G1,H1,, Q2,R2,S2,T2 RAID-0 Striping Over RAID-5 Sets RAID-5 Set RAID-5 Set A1 B1 C1 D1 P(ABCD) E1 F1 G1 P(EFGH) H1 I1 J1 P(IJKL) K1 L1 M1 P(MNOP) N1 O1 P1 P(QRST) Q1 R1 S1 T1 A2 B2 C2 D2 P(ABCD) E2 F2 G2 P(EFGH) H2 I2 J2 P(IJKL) K2 L2 M2 P(MNOP) N2 O2 P2 P(QRST) Q2 R2 S2 T2 Sam Siewert 21

22 RAID is an Erasure Code RAID-1 is an MDS EC (James Plank, U. of Tennessee) Sam Siewert 22

23 Read, Modify Write Penalty Any Update that is Less than the Full RAID5 or RAID6 Set, Requires 1. Read Old Data and Parity 2 Reads 2. Compute New Parity (From Old & New Data) 3. Write New Parity and New Data 2 Writes Only Way to Remove Penalty is a Write-Back Cache to Coalesce Updates and Perform Full-Set Writes Always Write A1,B1,C1,D1, E1,F1,G1,H1, RAID-5 Set A1 B1 C1 D1 P(ABCD) E1 F1 G1 P(EFGH) H1 I1 J1 P(IJKL) K1 L1 M1 P(MNOP) N1 O1 P1 P(QRST) Q1 R1 S1 T1 P(ABCD) new =A1 new xor A1 xor P(ABCD) A1 B1 C1 D1 P(ABCD) XOR parity Indicates Odd number Of 1 s Sam Siewert 23

24 What Is a Model? A conceptual representation of something. A schematic description of a system, theory, or phenomenon that accounts for its known or inferred properties and may be used for further study of its characteristics. (Dictionary Definition) Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 5-24

25 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Why Do We Need Model? No, you are all wrong. Elephant is like a fan. An ancient Chinese story. How four blind men perceive an elephant. Elephant is like a wall. No, elephant is like a rope. No, I think elephant is a cylinder. We perceive the world differently due to differences in backgrounds and viewpoints. Modeling facilitate collective understand of the application. 5-25

26 Represent Domain Model as UML Class Diagram UML class diagram is a structural diagram. It shows the classes, their attributes and operations, and relationships between the classes. Domain model is represented by a class diagram without showing the operations Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

27 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Representing Type in UML attribute name Employee SSN: char* name: char* checkin(time:float):void checkout(time:float):void attribute type return type function name parameter name parameter type general syntax name : type 5-27

28 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Example: Inheritance superclass, it is more general subclass, more specific User id: char* name: char* login(id, password) logout() triangle pointing to the super-class. Staff Student processapplication() applyonline() A staff is a user, a student is a user. Features (i.e., attributes and operations) defined for the super-class are automatically defined for the subclasses. subclass may have additional features 5-28

29 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Two Tests for Inheritance IS-A test: every instance of a subclass is also an instance of the superclass. Engine model# horse power manufactur er start() stop() Car drive() Conformance test: relationships of a superclass are also relationships of subclasses. Professor name phone teach(...) Visiting Professor signcontract() enroll Retirement Plan Visiting professors cannot enroll in a retirement plan at the host university. 5-29

30 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Aggregation Relationship It expresses the fact that one object is part of another object. Example: engine is part of a car. It is also called part-of relationship. part-of relationship Car Model # horse power Manufacturer start() stop() Engine Model # horse power Manufacturer start() stop() 5-30

31 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Association Relationship It expresses a general relationship other than inheritance and aggregation. These can be application specific relationships between two concepts. Example: "instructor teach course," "user has account." Professor name phone teach(...) enroll Retirement Plan Enroll is not an inheritance or aggregation relationship. 5-31

32 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Role and Association Direction association name Student enrolls in Course association direction Student enroll student course Faculty teaches Course Course teach Faculty course instructor role name 5-32

33 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Role and Multiplicity Another employee is the worker. worker * Employee Employee supervises other employees. supervise supervisor A supervisor supervises zero or more employees. An employee is the supervisor. 5-33

34 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Sample Domain Model User - Student 1..* 1 - Student 1 Submits Submits - Feedback Feedback 1..* + Description Performs - Application 1..* 0..* Online Application + Program Name + Student Name + Student ID + Address + Course 0..* For For 0..* Search + Program Type + Acedamic Subject + Region + Country + Language * 0..* On Staff User * + Name + Address + Phone No + e - mail ID + User Name + Password + Privilege 1..* 1..* Manages Manages 0..* Program + Program Type + Academic Subject + Term of Study + Language of Instruction + Country + Region + Application Deadline + Fees + Scholarships & Financial aid 1 Administrator 5-34

35 Key Takeaway Points The software architecture of a system or subsystem refers to the style of design of the structure of the system including the interfacing and interaction among its subsystems and components. Different types of systems require different design methods and architectural styles Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

36 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Architectural Design in Methodology Context Business goals & needs Current situation Preliminary requirements Acquiring Requirements Deriving Use Cases from Requirements Abstract & high level use cases, use case diagrams Allocating Use Cases & Subsystems to Iterations Use case-iteration allocation matrix Producing an Architectural Design Software architecture Accommodating Customer Requirements Change feedback Iteration use cases Domain Modeling Domain model Actor-System Interaction Modeling Use case-iteration allocation matrix Behavior Modeling & Responsibility Assignment Behavior models Deriving Design Class Diagram Test Driven Development, Integration, & Deployment Domain model Expanded use cases & UI design Design class diagram (a) Planning Phase (b) Iterative Phase activities during each iteration control flow data flow control flow & data flow 6-36

37 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. What Is Software Architectural Design The software architecture of a system or subsystem refers to the style of design of the structure of the system including the interfacing and interaction among its major components. Software architectural design is a decisionmaking process to determine the software architecture for the system under development. 6-37

38 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Characteristics of Interactive Systems The interaction between system and actor consists of a relatively fixed sequence of actor requests and system responses. The system has to process and respond to each request. Often, the system interacts with only one actor during the process of a use case. The actor is often a human being although it can also be a device or another subsystem. The interaction begins and ends with the actor. The actor and the system exhibit a client-server relationship. System state reflects the progress of the business process represented by the use case. 6-38

39 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Characteristics of Event-Driven Systems It receives events from, and controls external entities. It does not have a fixed sequence of incoming requests; requests arrive at the system randomly. It does not need to respond to every incoming event. Its response is state dependent the same event may result in different responses depending on system state. It interacts with more than one external entity at the same time. External entities are often hardware devices or software components rather than human beings. Its state may not reflect the progress of a computation. It may need to meet timing constraints, temporal constraints, and timed temporal constraints. 6-39

40 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Characteristics of Transformational Systems Transformational systems consist of a network of information-processing activities, transforming activity input to activity output. Activities may involve control flows that exhibit sequencing, conditional branching, parallel threads, synchronous and asynchronous behavior. During the transformation of the input into the output, there is little or no interaction between system and actor it is a batch process. Transformational systems are usually stateless. Transformational systems may perform number crunching or computation intensive algorithms. The actors can be human beings, devices, or other systems. 6-40

41 Characteristics of Object-Persistence Systems It provides object storage and retrieval capabilities to other subsystems. It hides the implementation from the rest of the system. It is responsible only for storing and retrieving objects, and does little or no business processing except performance considerations. It is capable of efficient storage, retrieval, and updating of a huge amount of structured and complex data. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 6-41