SE310 Analysis and Design of Software Systems

Transcription

1 SE310 Analysis and Design of Software Systems Lecture 3 Systems Requirements January 21, 2015 Sam Siewert

2 Learning Objective Software Engineering Process? Lifecycle Phases feedback SPIRAL WATERFALL XP - Extreme Agile Manifesto that Hosts Spiral, XP, Scrum, Feature- Driven or any Iterative Process [Waterfall with Feedback] Requirements? Architecture? First Phase Sam Siewert 2

3 CH2 - Rational Unified Process (RUP) Inception consists of the first 1-2 iterations. It produces a simplified use case model, a tentative architecture, and a project plan. Elaboration consists of the next N iterations. It produces the architectural design and implements the most critical use cases. Construction, during which remaining use cases are iteratively implemented and integrated into the system. Transition, during which the system is deployed, users are trained, and defects are corrected. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 2-3

4 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. CH2 - Rational Unified Process (RUP) 2-4

5 phases in an iteration Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Agile Process Models Iterations 2-5

6 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 6

7 Domain Models with UML - CASE UML is Universal Modeling Language Use to Support Requirements Analysis Start Here! USE Modelio as your DESIGN TOOL WARNING: ArgoUML has bugs, so use only to review Argo design examples Helpful Validation and Verification Features for Design Integrated Models Checklists Completeness CPP and Java Code Generation Sam Siewert 7

8 Architecture and Design Patterns 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 8

9 Software Paradigm A software paradigm is a style of software development that constitutes a way of viewing the reality. Examples: procedural paradigm OO paradigm, and data-oriented paradigm Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 2-9

10 Three Paradigms in History Procedural paradigm views the world and system as: a network of processes a process is refined by lower level processes basic building blocks and starting point are processes OO paradigm views the world and system as: interrelated and interacting objects basic building blocks are objects Data-oriented paradigm views the world and system as: interrelated data entities, processed by transactions basic building blocks are data entities and relationships Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 2-10

11 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Paradigm and Methodology Books Class - 1 attrib 1 attrib 2 Student sn sname orders Customer invoices (w/books) Process Orders credit status Customers Class - 2 attrib 1 attrib 2 Class - 3 attrib x enroll Student cn cname Structured Analysis Domain model Object-Oriented Analysis Data-Oriented Analysis A Top Manager Top Decider Obj : class b : Bclass m1 ( ) m2 ( ) m3 ( ) BE CF DG info m5 ( ) m4 ( ) B E C F D G m6 ( ) m7 ( ) m8 ( ) H Structured Design Structured Programming Procedural Paradigm m10 ( ) Object-Oriented Design Object-Oriented Programming OO Paradigm m9 ( ) Sequence diagram Data-Oriented Design Programming in 4GL (e.g., SQL) Data-Oriented Paradigm 2-11

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

13 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Methodology Overview Planning Phase Business goals & needs Current situation Acquiring Requirements & Domain Modeling Requirements Deriving Use Cases from Requirements Abstract & high level use cases, use case diagrams Allocating Use Cases & to Iterations Use case-iteration allocation matrix Producing an Software architecture Architecture Design 2-13

14 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Methodology Overview Iterative Phase Software architecture Use case-iteration allocation matrix Accommodating Requirements Change Iteration use cases Domain Modeling Actor-System Interaction Modeling & UI Design Behavioral Design Domain model Deriving Design Class Diagram Expanded use cases & UI design Behavior diagrams Design class diagram Domain model TDD, Integration, & Deployment 2-14

15 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 15

16 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 16

17 Assignment #2 Goals Consistent and Complete UML Design 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 17

18 Key Takeaway Points System engineering is a multidisciplinary approach to systems development. System engineering defines the system requirements and constraints, allocates the requirements to the hardware, software, and human subsystems, and integrates these subsystems to form the system. Software engineering is a part of system engineering Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

19 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. System Architectural Design Decomposing the System Allocating System Requirements Decomposing the system into a hierarchy of functional cohesive, loosely coupled subsystems, which partition the system requirements and facilitate reuse of COTS components. System requirements are assigned to the subsystems. Visualizing System Architecture The system architecture is depicted using a certain diagramming technique. 3-19

20 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Requirements Allocation 3-20

21 Architectural Design Diagrams Block diagram UML component diagram SysML diagrams Data flow diagram and more Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

22 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 22

23 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 23

24 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 24

25 Storage Efficiency 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% 60.0% 50.0% 40.0% RAID6 RAID5 30.0% 20.0% 10.0% 0.0% Number of Data Devices for 1 XOR or 2 P,Q Encoded Devices Sam Siewert 25

26 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 26

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

28 Read, Modify Write Penalty Write A1 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 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) Sam Siewert 28

29 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. UML Component Diagram <<subsystem>> Mobile Units <<subsystem>> Base Station events <<subsystem>> Mobile Hardware air link <<subsystem>> Base Station Antenna instructions <<subsystem>> Controller Software call data <<subsystem>> Account Management <<subsystem>> Mobile Software instructions <<subsystem>> High-Power Transceivers <<subsystem>> Controller Hardware events Legend: component port <<subsystem>> stereotype for introducing new modeling constructs 3-29

30 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Data Flow Diagram with Material Flows shipmen t slip Publishe r raw shipment 1 Verify Shipment Content Purchasin g Receiving Dock valid shipmen t slip publications 2 Classify Publication s Received Catalogin g Catalogin g Room new titles available publications w/call numbers 3 Handle Documents Check- In/Out Circulatio n Book Shelves Legend: ID Functio n Subsyste m information flow material flow External Entity Internal Entity 3-30