Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CSE360 Lecture 10

CSE360 Lecture 10

Introduction to Software Engineering
Use Cases
(201805)

More Decks by Javier Gonzalez-Sanchez

Other Decks in Programming

Transcript

  1. CSE360 Introduction to Software Engineering Lecture 10: Use Cases Javier

    Gonzalez-Sanchez [email protected] javiergs.engineering.asu.edu Office Hours: By appointment
  2. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 2 Where

    we are? Process Requirements Concepts functional non-functional Specification user stories natural language (agile) use cases diagrams (UML) * SRS Planning Modeling Coding Deployment
  3. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 4 Use

    Case Diagrams • Use case –put the title of one requirement inside. Use cases capture requirements. • Actor –put the name of an actor at the bottom side. An actor specifies a role played by an external entity requirement title actor name
  4. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 5 Inheritance

    • Generalization/Specialization (Inheritance) – used when there is common behavior between two use cases and also specialized behavior specific to each use case. • Generalization/Specialization (Inheritance) –of an actor means that one actor can inherit the role of the other actor
  5. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 6 Association

    • Association – between an actor and a use case indicates that the actor and the use case somehow interact or communicate with each other.
  6. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 7 Inclusion

    • Show that behavior of the included use case (addition) is inserted into the behavior of the including (base) use case. • A dashed line with an open arrowhead directed from the including use case (base) to the included (addition) use case. The arrow is labeled with the keyword «include». • The include relationship is used to (1) simplify large use case by splitting it into several use cases, (2) extract common parts of the behaviors of two or more use cases. base addition
  7. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 8 Extension

    • Extending use case defines optional behavior that is not necessarily meaningful by itself. • Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword «extend». base extension
  8. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 16 Example

    8 http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/uc_model_elaboration_phase_70035F60.html
  9. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 19 Rules

    for Use Cases • Titles begin with a verb – A use case models an action so the name should begin with a verb. • Make the name descriptive – This is to give more information for others who are looking at the diagram. For example “Print Invoice” is better than “Print”. • Highlight the logical order – For example if you’re analyzing a bank customer typical use cases include open account, deposit and withdraw. Showing them in the logical order makes more sense. • Place use cases to the right of the primary actor and to the left of secondary actors • Place inheriting use case below parent use case
  10. Javier Gonzalez-Sanchez | CSE360 | Summer 2017 | 20 Rules

    for Actors • Give meaningful business relevant names for actors • Actors model roles (not positions) • External systems are actors • Actors don’t interact with other actors • Place inheriting actors below the parent actor
  11. CSE360 – Introduction to Software Engineering Javier Gonzalez-Sanchez [email protected] Summer

    2017 Disclaimer. These slides can only be used as study material for the class CSE360 at ASU. They cannot be distributed or used for another purpose.