Quiz

1. Quiz • 1. Who is the guru of Extreme Programming? • 2. who are the gurus of UML? • 3. Do we want highly or lowly cohesive modules? • 4. Do we want strongly or loosely coupled modules? • What is the principle of Encapsulation? • 6. Show the UML diagram for a class

2. Quiz Answers • 1. Kent Beck • 2. Jacobson, Booch, Rumbaugh (Three Amigos) • 3. Highly cohesive • 4. Loosely coupled • 5. The implementation of a module should be separated from its contractual interface and hidden from clients. • 6. Point X Y move(dx, dy)

3. Unified Modeling Language

4. UML • Set of graphic notation techniques to create visual models of software intensive systems • Architectural blueprint of a software system • Capture details about a system such that • the problem is clearly understood • (design) solution architecture is developed • a chosen implementation is clearly identified and constructed • Provides for ways to express complex relationships among the basic building blocks • Those relationships can be static or dynamic • Easier to communicate with non-professionals

5. Introduction • Class diagrams • Shows the static relationships that exist among a group of classes and interfaces • Common relationships include inheritance (is-a), aggregation (part-of ), dependency and composition

6. Introduction • Interaction diagrams • Used for modeling the dynamic behavior of a system • Two kinds of diagrams one of which are sequence diagrams (others fall under collaboration diagrams) • Used for modeling the message exchange between objects in a system (what do I mean message?) • Capture the relative time ordering of messages exchanges

7. /cond Introduction • Other • State chart diagrams • Similar to finite state machines • Activity diagrams • Components diagrams • Deployment diagrams • More than12 now

8. Use Cases • Interactions between system and external entities • Users • Other Systems • What the system does, not how things happen • Specifies a sequence of actions, including variants, that a system performs and that yields an observable result of value to a particular actor (Jacobson, Booch, Rumbaugh)

9. Use Cases • Set of scenarios (likely/possible occurrences) • Main Scenario • Alternative scenarios • Exceptional scenarios • Sequence of interactions between actors/system • A little story that outlines some expected sequence of request and responses between actors and the system • Writing one is a like a game of “what happens next?”

10. Use Case • Main Scenario – Normal flow of events and outcomes • “what will happen if all the preconditions are met” • Alternatives – also normal • Exceptions – what if preconditions are not met? • Paragraph description of what happens • “A student registers in a class by logging in (if not logged in), selecting and open class, and saving the new schedule”

11. Use Case • User: A student • Goal: registers in a class • Scenario: by logging in, (if not logged in), selecting and open class, and saving the new schedule

12. Online Shopping Example • Name: Validate credit card • Actors: Customer, Credit card company • Main Scenario: • 1. Customer enters credit card number and expiration date • 2. System verifies card with credit card company • 3. System sends authorization message to customer

13. Online Shopping Example • Alternative 2a: If the credit card company rejects the card, system sends a rejection notice • Alternative 2b: If credit card company does not respond in 10 seconds, • Tell the user of delay • Repeat verifying the card • Alternative …

14. General Guidelines • Use case must define a goal for its user • Must be a “sunny day” scenario • Make at an appropriate level • not too detailed (trivial, tedious - e.g. login as a separate use case) • not too high (vague) • Don’t get technical (e.g. reference to specific DB)

15. Use Case Diagrams • Show use cases, actors and their relationships • Capture the precise requirements for the system from a user’s perspective (not internal system)

16. Use Case Diagrams (UML) • Consists of • Actors • A person, organization, or external system that plays a role in one or more interactions with your system • Can make a service request to the system or be requested to provide a service • Drawn as stick figures • Use cases (each includes main scenario, alternatives, and exceptions) • Scenario • Drawn as ovals

17. Use Case Diagrams (UML) • Relationships among actors and use cases • Generalization relationships among actors • Extends in Visio (change type to inherits) --- could be done in a separate diagram • Associationrelationships between actors and use cases • Communication in Visio • Dependencyrelationships among use cases • Include (Uses in Visio) • Access account includes login • Extends (i.e. special case of) (Extends in Visio) • Open a dual account vs. open an account • Last two should be within the System boundary diagram

19. Sometimes “uses” instead “includes”

21. University System • Students, faculty and admins • Students: Login and get grades • Faculty: Login, view student roster, & enter grades for a student roster • Admins: Login and verify grades

25. Use Cases • Every use case in the system must be explicitly described • Name • Actors involved • Preconditions • Related Use Cases (Uses/Extends) • Main Scenario • Alternative Scenarios • Exceptional Scenarios • Withdraw money from bank via ATM • Wrong pin • Balance not enough • Money not removed in 60 seconds

26. Use Cases • Steps • Extract actors and use cases • Nouns that perform actions or respond to actions are actors • Verbs or action nouns (registration, enrollment, etc …) are usually use cases • Draw use case diagram • Main uses cases and actors • Don’t worry about completeness … will refine later on • Describe every use case • Main scenarios • Refine use case diagram • Add more relationships, secondary uses cases, secondary actors • Complete • Refine use cases • Alternative scenarios • Complete • Iterative development process

27. E-Book Store • Allows customers to search and shop for books, music CDs, and computer software on the Web • Provides information about the titles it carries to help customers make purchases • Other functionalities • Customer registration (needed for shopping only) – first time only, login henceforth (needed for shopping only) • Support management of the system such as adding, deleting and updating titles (Catalog manager) • Updating customer account information & processing orders (Customer manager) • Manage inventory (Inventory manager) – e.g., order products

28. E-Book Store • Actors: • Customer • Manager • Inventory • Catalog • Customer • Use Cases: • Register • Login • Search/Browse • Shop • Manage Inventory • Manage Catalog • Manage Accounts • Manage Orders

30. Use Case: Shop • Name: Shop • Primary Actor: Customer • Uses/Extends: Uses Browse & Login • Precondition: Customer already registered

31. Use Case: Shop • Alternative Scenario 1 • Customer authentication fails  repeat login procedure (warn user and go back to step 6) • Alternative Scenario 2 • Payment validation fails  prompt the customer for new payment information (warn user and go back to step 11) • Exceptional Scenario • Customer leaves without checking out • Save shopping cart for 48 hours