SE310 Analysis and Design of Software Systems

Transcription

1 SE310 Analysis and Design of Software Systems Lecture 5 Transitioning from Use Cases and Class Diagrams to Architecture Level of Design February 12, 2018 Sam Siewert

2 Reminders Assignment #2 Grading in Progress Assignment #3 Posted Exam #1 - Tues, 2/27, Review on Thurs 2/22 Same day as SE420 Study for related exams should reinforce material Assignment #3 Due 2/23 (Graded), Late 2/26 (Ungraded) Sam Siewert 2

3 More than One Way to Proceed with UML No Absolutely Right or Wrong Approach Balance of Behavioral and Structural Analysis (Models) with Details Deferred for Design Class / Object Models Unique to UML Activity and Interaction Overview (Objects from Classes) are Useful for High Level Behavior Sam Siewert 3

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

5 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. SAMS/User Mgmt SAMS/Program Mgmt Create User Add Program SAMS Admin Software engineering principle applied: separation of concerns divide and conquer Delete User Update User Start Up Shutdown SAMS/Authentication SAMS Staff Delete Program Edit Program SAMS/End User Login Search for Programs SAMS End User SAMS Admin SAMS Staff Logout SAMS End User Display Program Detail Apply Online 7-5

6 Tying Use Case Back to Requirements Create Traceability R n is Described by Use-Case n Kung says Prioritize Requirements Desirements Help Distinguish Requirement Priority Based on Use and Use Case Based on Requirements Weight Drive Next Steps and Focus for Walk-throughs and Inspections based on Highest Column Scores or Perhaps Adjust Weightings Note on Requirements: Kung suggests prioritization Fits for want, but not need Could be market specific Alternatively weight UC Sam Siewert 6

7 Alternative UC Weighting If Requirement priorities are must only, weight UC instead E.g. to To sell our RAID system to enterprise customers, the product must have a disaster recovery feature However, the product can be sold to SMB (Small to Medium Business) without DR features Is DR a Use Case or a Requirement? R5 = asynchronous mirrored writes E.g. UC6 is DR, UC4 is Local Content Delivery Drop R5 Iff UC6 and UC4 irrelevant - i.e. UC1, 2, 3, 5 for SMB UC4, UC6 for enterprise UC1 UC2 UC3 UC4 UC5 UC6 score weight R1 X X 6 R2 X 2 R3 X 3 R4 X X 4 R5 X X 2 R6 X X 5 Sam Siewert 7

8 Agile with Use Cases Create Backlog Attack Highest Priority Use Cases First Schedule Scrums Around Use Cases Synchronize with SQA on Use Case Acceptance Testing Work with Customer Use Case Inspection or Walk-through Team Walk-throughs and Division of Labor, Planning and Backlog Refinement of Requirements Frequent Delivery of Small Increments (Use Case Design, Construction, Coding) What the System Includes and Does not (Boundary) Simple Easy to Share with Customer Sam Siewert 8

9 Minute Paper #3b Architecture Level Design is Specification and Design of Modules (Objects) and their Interfaces, So which UML Models might help most and why? Use Case? Class Diagram? Interaction Sequence Diagram (Object instances and method communication)? Sam Siewert 9

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

11 Architecture Patterns No Pattern is Perfect Fit and Real Applications May Have Aspects (and Requirements) from Multiple Patterns Hybrid Architectures Combine Capabilities Classify First Based on Primary Use and Capabilities and Refine Through Agile XP, Scrum or Spiral Process 1. Transformational E.g. Image Processing 2. Interactive E.g. User Interface 3. Service Oriented Architectures Transactional E.g. Database Services Client/Server E.g. Web Browser, Disk Drives (Storage), File Systems 4. Event Driven E.g. Robotics, , Digital Control Hard Real-Time Event Driven E.g. Anti-lock Braking System (Digital Control with Specific Deadlines for Response to Events) Soft Real-Time Event Driven E.g. Digital Video for Cable or Netflix Best Effort Event Driven Reminder System Sam Siewert 11

12 Canny Edge Finder Threshold Control Consider a Transformation Continuous Image Processing with a Simple Control Added Sam Siewert 12

13 Activity Canny Interactive Demo Slider What is Going on? Think, Pair, Share 1. Is this Transformational? (Yes, image data to language, to another and then back to graphics overlay) 2. Is this Interactive? (Yes, hold Smart-phone with Google Translate in front of transformed image on Lecture slide to translate, select target language) 3. Is this Something Else? (Cloud Client/Server for backend translation services, Appears Best Effort but Limits Use?) 4. What are Key Capabilities and Requirements? (Translate from Set of Natural Languages to Others, Image Input, Limited to Simple Signs Interactive Overlaid Translation) 5. What Sorts of Applications Could We Use Canny For? Google Goggles (OCR + Translation) Sam Siewert 13

14 License Plate or Sign OCR MATLAB Example Reading a Sign Canny is Fundamental Step Transformational Capability in a Larger Application (OCR) Correct Threshold for Intensity Gradient to Segment Image Sam Siewert 14

15 Architecture Patterns No Pattern is Perfect Fit and Real Applications May Have Aspects (and Requirements) from Multiple Patterns Hybrid Architectures Combine Capabilities Classify First Based on Primary Use and Capabilities and Refine Through Agile XP, Scrum or Spiral Process 1. Transformational E.g. Image Processing 2. Interactive E.g. User Interface 3. Service Oriented Architectures Transactional E.g. Database Services Client/Server E.g. Web Browser, Disk Drives (Storage), File Systems 4. Event Driven E.g. Robotics, , Digital Control Hard Real-Time Event Driven E.g. Anti-lock Braking System (Digital Control with Specific Deadlines for Response to Events) Soft Real-Time Event Driven E.g. Digital Video for Cable or Netflix Best Effort Event Driven Reminder System Sam Siewert 15

16 Canny Edge Finder Threshold Control Consider a Transformation Continuous Image Processing with a Simple Control Added Sam Siewert 16

17 Activity Canny Interactive Demo Slider What is Going on? Think, Pair, Share 1. Is this Transformational? 2. Is this Interactive? 3. Is this Something Else? 4. What are Key Capabilities and Requirements? 5. What Sorts of Applications Could We Use Canny For? Sam Siewert 17

18 License Plate or Sign OCR MATLAB Example Reading a Sign Canny is Fundamental Step Transformational Capability in a Larger Application (OCR) Correct Threshold for Intensity Gradient to Segment Image Sam Siewert 18

19 Minute Paper #3b Architecture and Application of YOUR Interest Think about Architecture Patterns and Applications Discussed so Far Choose an Application that Emphasizes one of the Architecture Patterns and Describe Why it Interests You? Turn in Your Minute Paper Sam Siewert 19

20 Goals for Object Interaction Models 1. Show Instantiation and Use of Classes (From Class Diagram) 2. Describe Behavior 3. Validate Class Interfaces Based on Use 4. Review with Stakeholders Sam Siewert 20

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

22 Actor-System Interaction & Object Interaction Actor-system interaction Foreground processing of use case. Acquiring actor input and actor action. Displaying system responses. Object interaction Background processing of use case by objects. Designing high-level algorithms to process actor requests. Producing system responses Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

23 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Object Interaction Modeling Steps scenario descriptions scenario tables (3) Constructing scenario tables domain model, design class diagram from last iteration expanded use cases for current iteration (2) Describing scenarios business processes info. (4) Constructing sequence diagrams (1) Collecting info about business processes feedback, if any sequence diagrams (5) Review and inspection design sequence diagrams to deriving a design class diagram (chapter 11) 9-23

24 Guidelines for Scenario Construction Specify the normal scenario first (i.e., assume everything will go as expected). If needed, augment the normal scenario with alternative flows. Keep it simple and stupid --- leave details to coding. Leave exception handling to coding. It is sometimes desirable to construct a prototype to validate design idea Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

25 Sequence Diagram Notions and Notations Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 9-25

26 Object Interaction Diagrams Object Interaction Model Object Interaction Diagrams (one or more) External Actors (from previously analyzed use cases) Instances of Classes from CRC or Domain Model Shows Message Sequences between Objects Useful for Capturing and Communicating Design (Design Patterns) See Kung examples which follow Sam Siewert 26

27 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Representing Various Object Instances Notation mycar: mycar: Car :Car :Car Notion and Meaning A named instance without a type, the type is not important, unknown, or to be determined at run time A named instance with a type, this is commonly used An unnamed instance with a type, the name is not important, or not used elsewhere in the sequence diagram Multiple instances or a collection of objects of a class 9-27

28 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Scenario Table to Sequence Diagram for each line of the scenario table: :object acted upon Case 1: subject is an Actor. Actor action + other objects/data object acted upon Example: card scanner: <<slide card>> Patron 9-28

29 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Scenario Table to Sequence Diagram object: Case 2: subject is an object and object acted upon is an actor. actor <<message>> Subject Subject Action Other Data / Objects Object Acted Upon system displays confirmation message Patron system: Patron <<confirmation message>> 9-29

30 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Scenario Table to Sequence Diagram Case 3: both subject and object acted upon are objects. Example : Subject :object acted upon action + other objects/data action performing cards canner: device control: send pid action performing 9-30

31 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Scenario Table to Sequence Diagram Case 4: both subject and object acted upon are the same (a special case of case 3). object1: action + data / objects return value if any Other Data/ Subject Subject Action Object Acted Objects Upon shipment compute base rate shipment shipment: compute base rate 9-31

32 Difference of Analysis and Design Analysis application problemoriented models application domain describes what the world is project-oriented decisions should allow design alternatives Design software solutionoriented models the software system prescribes a software solution system-oriented decisions usually reduces implementation choices 9-32 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved.

33 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Modeling a Manual Library System Patron presents id card to librarian. Patron <<id card>> :Librarian These are analysis sequence diagrams that model an existing system. Librarian pulls out patron s folder using id number. :Librain :PatronFolders <<uid, password>> get folder using patron id patron folder Patron 9-33

34 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. info exchange b/t actor and object Analysis/Informal Sequence Diagram :LoginGui an object of LoginGui class <<uid, password>> Patron the object is processing the request. Patron submits uid and password to LoginGui. :LoginGui :LoginController Patron <<uid, password>> <<msg>> verify uid and password <<msg>> LoginGui calls LoginController to verify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron. 9-34

35 From Analysis to Design :LoginGui :LoginController Patron <<uid, password>> <<msg>> verify uid and password <<msg>> LoginGui calls LoginController to verify the login. The controller returns a msg indicating result of verification. LoginGui shows msg to Patron. :LoginGui :LoginController Patron <<uid, password>> <<msg>> msg := verify (uid:string, password: Password) : String return value function call parameter & type return type 9-35 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. Sequence Diagram: Flow of Control :LoginGui :LoginController Patron 1 <<uid, password>> <<msg>> 3 2 msg := verify (uid:string, password: Password) : String (1) Patron submits uid and password to LoginGui object. (2) LoginGui object calls the verify function of a LoginController object. The called function returns msg of type String. (3) The LoginGui object shows msg to patron. 9-36

37 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. outside library system real world object within the library system patron An Analysis Sequence Diagram id card, book :Librarian [patron folder not found] error msg, id card get patron folder w/id patron folder f :Patron Folder [patron folder found] get book card book card collection book:book [patron folder found] insert book card into patron folder f:patron Folder [patron folder found] id card, book [patron folder found] return patron folder This an analysis sequence diagram models the current, manual operation, little design decision is made. 9-37

38 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. A Design Sequence Diagram :CheckoutGUI :DBMgr l:loan d:document Patron <<uid,call# list>> u:=getuser (uid):user <<msg>> Loop (for each cn in callnumlist) conditional call [u!=null] process(callnumlist) d:=get Document(cn): Document [d!=null]a:=isavailable():boolean [a]create(u,d) [a]saveloan(l) [a]save- Document(d) [a]setavailable(false) loop 9-38

39 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Sequence Diagram to Implementation :Checkout GUI :DBMgr l:loan d:document Patron <<uid,cnlist>> <<msg>> Loop (for each cn in cnlist) u:= getuser(uid): User [u!=null] process(cnlist) d:=get Document(cn): Document a:=isavailable():boolean public class CheckoutGUI { DBMgr dbm=new DBMgr (); public void process(string[] cnlist) { for(int i=0; i<cnlist.length; i++) { Document d=dbm.getdocument(cnlist[i]); if (d.isavailable()) { Loan l=new Loan(u, d); dbm.saveloan(l); d.setavailable(false); dbm.savedocument(d); } } [a]create(u,d) [a]saveloan(l) [a]setavailable(false) [a]save- Document(d) 9-39

40 From Sequence Diagram to Implementation :Checkout GUI :DBMgr l:loan d:document Patron <<uid,cnlist>> <<msg>> Loop (for each cn in cnlist) u:= getuser(uid): User [u!=null] process(cnlist) d:=get Document(cn): Document a:=isavailable():boolean public class CheckoutGUI { DBMgr dbm=new DBMgr (); public void process(string[] cnlist) { for(int i=0; i<cnlist.length; i++) { Document d=dbm.getdocument(cnlist[i]); if (d.isavailable()) { Loan l=new Loan(u, d); dbm.saveloan(l); d.setavailable(false); dbm.savedocument(d); } } [a]create(u,d) [a]saveloan(l) [a]save- Document(d) [a]setavailable(false) Note the color correspondence in SD and code. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 9-40

41 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. From Sequence Diagram to Implementation :Checkout GUI :DBMgr l:loan d:document Patron <<uid,cnlist>> <<msg>> Loop (for each cn in cnlist) u:= getuser(uid): User [u!=null] process(cnlist) public class DBMgr { public Document getdocument(string cn) {...} public User getuser(string uid) {...} public void saveloan(loan l) {... } public void savedocument(document d) {...} } d:=get Document(cn): Document a:=isavailable():boolean [a]create(u,d) [a]saveloan(l) [a]setavailable(false) [a]save- Document(d) 9-41

42 Commonly Seen Mistakes Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. :Checkout GUI :DBMgr :Checkout GUI :DBMgr u:=getuser(uid): User u:=getuser(uid): User [u!=null] process(cnlist) [u!=null] process(cnlist) d:=get Document(cn): Document d:=get Document(cn): Document WRONG WAY [a]saveloan(l) [a]saveloan(l) [a]save- Document(d) [a]save- Document(d) Correct: 4 function calls to DBMgr; the functions are executed during 4 time intervals. 9-42

43 Commonly Seen Mistakes :Checkout GUI :DBMgr :Checkout GUI :DBMgr u:=getuser(uid): User [u!=null] process(cnlist) The call to process(...) ends here. u:=getuser(uid): User [u!=null] process(cnlist) d:=get Document(cn): Document d:=get Document(cn): Document [a]saveloan(l) [a]saveloan(l) [a]save- Document(d) [a]save- Document(d) Correct: during execution of process(...), 3 function calls are made. The last two calls need to be initiated. But even though the semantics is still incorrect. Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. 9-43

44 Copyright {c} 2014 by the McGraw-Hill Companies, Inc. All rights Reserved. Commonly Seen Mistakes :Checkout GUI :DBMgr Patron <<uid,cnlist>> u:=getuser(uid): User Correct: the getuser(uid) call happens after the patron submits the uid and cnlist. :Checkout GUI :DBMgr Patron <<uid,cnlist>> Incorrect: the triggering event should happen before the getuser(uid) call. u:=getuser(uid): User 9-44