SYS466: Analysis and Design Using OO Models

1. SYS466: Analysis and Design Using OO Models Lecture 1

2. Agenda • Overview of SYS466 website • Introduction to Analysis and Design of OO Models • Review of Use Cases

3. Agenda • Overview of SYS466 website • Introduction to Analysis and Design of OO Models • Review of Use Cases

4. Where have we come from? • SYS366 – Requirements Gathering using OO Models • Business Modeling • User Requirements • Identify Actors/Stakeholders • Identify Use Cases • Use Case Diagrams • Use Case Descriptions

5. Where are we going? • Use Case Analysis: • Analyze Requirements for each use case in the Use Case Diagram • Produce: • Scenarios • System Sequence Diagrams • Domain Model (Conceptual Class Diagram) • Interaction (Sequence) Diagrams • Design Class Diagram

6. SYS366 SYS466 Requirements Gathering (Specification) 1. Model object interaction & definition of operations using Sequence Diagrams 2. Design Class Diagram – show final relationships (associations, composition, inheritance) Use Case Analysis 1. Business and System Use Case Diagrams 2. Business and System Use Case Descriptions Interaction Modeling • 1. Refine Use Case Description – Scenarios • 2. Model system input and output events (Systems Sequence Diagram - SSD) • 3. Noun filtering - Domain Class Diagram (conceptual classes) • - Identify attributes of conceptual classes • - Identify relationships between conceptual classes (associations and composition) Coding Testing PRJ666 ** PRJ566 – encompasses SYS366, SYS466, DBS201 and DBS301

7. In SYS466 we will first • Review requirements gathering by developing a use case model in Rational Rose • use case diagrams and scenarios

8. Sample Use Case Diagram: Online Auction

9. In SYS466 we will first Sample Scenario: Preconditions: At the moment when the scenario begins, the system is displaying the Online Auction Main Page. HD Browse Catalog

10. In SYS466 we will then • Create a systems sequence diagram (SSD) • Model the input and output events related to the system under discussion • An SSD for each scenario

11. System Sequence Diagram

12. In SYS466 we will then • Identify conceptual classes in the use case model and initial relationships between them • Using Noun Filters • Create a Domain Class Diagram showing preliminary relationships - focuses on the persistent data required by the system under development

13. . Sale Payment 1 1 Pays - for date amount time Domain Class Diagram

14. In SYS466 we will then • Identify object interaction and class responsibilities (for classes in domain layer) • Sequence diagrams • Refine domain class diagram  create Design Class Diagram

15. Sequence Diagram

16. Register Sale time ... 1 isComplete : Boolean endSale () currentSale / total enterItem (...) makeLineItem (...) makePayment (...) Design Class Diagram

17. Agenda • Overview of SYS466 website • Introduction to Analysis and Design of OO Models • Review of Use Cases

18. What is a Use Case? • Describes the chronologically continuous interaction of one or more actors with a system • Reflects the goals of the actors • Choose a name that represents this goal – starting with a verb

19. Use Case Diagram • Visual representation of the dialog between the actor and the system – shows all use cases • Shows which actors are involved with which use cases • Primary actors are on left, support actors are on right

20. Use Case Diagram Use Case—describes interactions with actor Actor—external to system Association

21. What is a Stakeholder? • Anyone who is affected by the system • They have a vested interest in the success of the system • They may or may not use the system directly • Executive, Senior Management, Middle Management, Supervisory Management • Other Departments • Customers

22. What is an Actor? • Anything or anyone that interacts with the system • Another system (e.g. Accounting System, Bank Credit Card system) • Person (e.g. Customer) • Hardware (e.g. Scanner, Printer) • Network (e.g. Intranet, Internet, Phone Network)

23. What is System Behavior? • Anything the system must do to achieve its purpose • Happens only inside the automated system boundary • Does not include anything done by an actor (because an actor is outside of the system!)

24. Example:Actors,Use Cases,System Behavior System Boundary

25. In Summary • In Use Case Modeling we need to: • Identify actors • Define system behavior • Identify use cases • Document use cases