1 / 63

Software Design Models UML

Software Design Models UML. Software Engineering. Structural : element of spec. irrespective of time Class Component Deployment Object Composite structure Package. Behavioral : behavioral features of a system / business process Activity State machine Use case Interaction.

williamsondorothy
Download Presentation

Software Design Models UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Design ModelsUML Software Engineering

  2. Structural : element of spec. irrespective of time Class Component Deployment Object Composite structure Package Behavioral : behavioral features of a system / business process Activity State machine Use case Interaction Overview of UML Diagrams • Interaction • : emphasize object interaction • Communication(collaberation) • Sequence • Interaction overview • Timing

  3. Use Case Diagram • Used for describing a set of user scenarios • Mainly used for capturing user requirements • Work like a contractbetween end user and software developers

  4. Use Cases • Used for Functional Requirements Analysis and Specification • A use caseis a step-by-step description of how a user will use the system-to-be to accomplish business goals • Detailed use cases are usually written as usage scenarios or scripts, showing an envisioned sequence of actions and interactions between the external actors and the system-to-be

  5. Use case modeling • Use cases were developed originally to support requirements elicitation and now incorporated into the UML. • Each use case represents a discrete task that involves external interaction with a system. • Actors in a use case may be people or other systems. • Represented diagramatically to provide an overview of the use case and in a more detailed textual form.

  6. Use cases diagram UML 2 Use cases diagrams • Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. • Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. • Associations. Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.

  7. Use Case Diagram (core components) Actors:A role that a user plays with respect to the system, including human users and other systems. e.g.,inanimate physical objects (e.g. robot); an external system that needs some information from the current system. Use case:A set of scenarios that describing an interaction between a user and a system, including alternatives. System boundary: rectangle diagram representing the boundary between the actors and the system.

  8. Types of Actors • Initiating actor(also called primary actor or simply “user”): initiates the use case to achieve a goal • Participating actor(also called secondary actor): participates in the use case but does not initiate it. Subtypes of participating actors: • Supporting actor: helps the system-to-be to complete the use case • Offstage actor: passively participates in the use case, i.e., neither initiates nor helps complete the use case, but may be notified about some aspect of it (e.g., for keeping records)

  9. Use Case Diagram(core relationship) Association: communication between an actor and a use case; Represented by a solid line. Generalization: relationship between one general use case and a special use case (used for defining special alternatives) Represented by a line with a triangular arrow head toward the parent use case.

  10. Authorized Person UC9: ManageUsers Tenant Landlord UC3: AddUser UC4: RemoveUser Use Case Generalizations UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login • More abstract representations can be derived from particular representations Actor Generalization Use Case Generalization

  11. Use-Case Diagram A use case diagram is a collection of actors, use cases, and their communications.

  12. Use cases diagram

  13. Billing System Register for Courses Registrar Student Use Case (Cont’d) Here we have a Student interacting with the Registrar and the Billing System via a “Register for Courses” use case.

  14. Key differences between «include» and «extend» relationships Included use case Extending use case No Yes Is this use case optional? Is the base use case complete without this use case? Yes No No Yes Is the execution of this use case conditional? Does this use case change the behavior of the base use case? No Yes Optional Use Cases: «extend» UC1: Unlock UC2: Lock UC3: AddUser UC4: RemoveUser UC5: InspectAccessHistory UC6: SetDevicePrefs UC7: AuthenticateUser UC8: Login Example optional use cases: UC5: InspectAccessHistory «extend» ManageAccount «extend» UC6: SetDevicePrefs [ Source: Robert Maksimchuk & Eric Naiburg: UML for Mere Mortals, Addison-Wesley, 2005. ]

  15. Login «include» AddUser AddUser Login Landlord SetDevicePrefs SetDevicePrefs Landlord «include» Login Use Case? BAD: GOOD:

  16. registration updating grades student faculty output generating Example of Use Case Diagram

  17. Transfer-data use case • A use case in the MHC-PMS

  18. Use-Case Diagram A use case diagram is a collection of actors, use cases, and their communications.

  19. Example of Relationships

  20. Example Use-case Diagram for a student database

  21. Order Food Customer Service Person Hire Employee Applicant <<uses>> Reorder supplies Manager Supplier <<uses>> Track sales and inv. data Produce mgt. reports Example use case diagram

  22. Control System Scan Set limits Liason Physicist Take profile Experimental Physicist Calibrate Hardware Specialist Example use case diagram

  23. Example use case diagram

  24. Use cases in the MHC-PMS involving the role ‘Medical Receptionist’

  25. Use Case : Add User

  26. Tabular description of the ‘Transfer data’ use-case

  27. Use case tables • formal use cases can also be written as a table:

  28. One method to do use cases Now that we know the syntax for doing use cases, what 4 steps does Cockburn recommend when actually brainstorming and writing our use cases? Let's look at each step in detail... • identify actors and their goals • write the main success scenario • identify and list possible failure extensions • describe how the system handles each failure

  29. Use cases diagram

  30. student Use Case Diagram - University System URS add member del member system user academic add subject del subject assg subject unass subject enrol subject unenrol subject

  31. Use Case Diagram for Student Assessment Management System Grade system Record grades Student View grades Teacher Distribute Report cards Create report cards Printing administrator

  32. Example: video store systemActor: Customer - What tasks does the actor want the system to perform? • Find movie to rent, rent tape, return tape, reserve tape • What information must the actor provide to the system? • Name, address, membership#, film name • Are there events that the actor must tell system about? • Change of address • Does actor need to be informed when something happens? • Reserved tape is ready to be rented • Does actor help initialize or shut down the system • no

  33. Example: video store system Resulting use cases: • Customer joins and provides contact information including name, address, phone#, credit information, spouse and kids • Customer browses system looking for a tape to rent • Customer comes to store looking for a specific tape to rent • Customer rents a tape • Customer returns a tape • Customer reserves a tape • Customer is contacted when a reserved tape is ready Note: simple phrases, without much details initially.

  34. Example use case Use Case. Buy stocks over the web Primary Actor: Purchaser (user) Scope: PAF Level: user goal Precondition: User already has PAF open. Guarantees: sufficient log information exists that PAF can detect what went wrong. Success Guarantees: remote web site acknowledged purchase, user's portfolio updated. Main success scenario: 1. User selects to buy stocks over the web. 2. PAF gets name of web site to use (E*Trade, Schwabb, etc.) 3. PAF opens web connection to the site, retaining control. 4. User browses and buys stock from the web site. 5. PAF intercepts responses from the web site, and updates the user's portfolio. 6. PAF shows the user the new portfolio standing. Extensions: 2a. User wants a web site PAF does not support: 2a1. System gets new suggestion from user, with option to cancel use case. 3a. ...

  35. Example • International Alexandria University wants to install a new student self-service system for student enrollment, registration and payment.    • A local bank called YMOM (Your Money is Our Money) Bank Corp. will join Alexandria to create a flexible bank account that can be used to conveniently pay for courses as well as other on-campus expenses.   • Alexandria will issue a new campus-wide Id card that combines all the features of a bank ATM card as well as a University ID card.

  36. The course registration system is available as a web-based application.  It is part of the joint application maintained by ALEXU and YMOM. The following are some of the business rules: • Every course has a cost. • Every course has an optional list of prerequisites, in the form a list of courses. • A student must have an established Alexu student enrollment record in the system, with an ID card and YMOM account before registering for a course. • A student will have a list of courses, described with the quarter they took the course, payment status and their grade, if appropriate.

  37.   A student can register for a course without having the money to pay for it in their YMOM account, as long as all prior courses have been paid for. • Registration for a specific course is only possible during a defined window of time, 3 week before the end of the current quarter and 2 weeks into the beginning of the next quarter. • A student will not see a grade for a course unless they have registered for the course and have paid for it in full. • A professor can submit a grade for a course for a student. • A student may declare a Major and a Minor, each one implying a list of required and optional courses. • A student can drop a course they have registered for and the money will be automatically made available in their YMOM account. • The students can access the system via their own PC accessing the web or via a network of YMOM ATMs

  38. The number on their student id/ATM  card is the user id for the application and the ATM PIN number is the password for the site. • They can: • 1.     See their current transcripts, • 2.     Register for a course in the next quarter. • When they register for a course, they will be presented with the set of courses that match their Major or Minor selections, the current courses offered and the courses with which they have fulfilled the prerequisites. • 3.     Transfer funds from the YMOM account to pay for a course.

  39. The University is a progressive IT customer.  They want to roll out system functionality as fast as it can be made available. • They want to engage student-lead focus groups to assess the quality and acceptance of the application. • They are concerned with the security and integration of the application with the YMOM systems. • The system development is not with out risks however, as CS305 has very limited experience with the kind of networking complexity and distributed computing involved in this project.

  40. Sequence Diagrams

  41. Sequence diagrams • Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. • A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. • The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. • Interactions between objects are indicated by annotated arrows.

  42. : System User «initiating actor» Timer «offstage actor» select function(“unlock") prompt for the key enter key verify key signal: valid key, lock open open the lock, turn on the light start ("duration“) System Sequence Diagrams We already worked with interaction diagrams: System Sequence Diagrams System Sequence Diagrams considered interactions between the actors

  43. Sequence diagram for View patient information

  44. Sequence diagram for Transfer Data

  45. A generalization hierarchy

  46. Classes and associations in the MHC-PMS

  47. A generalization hierarchy with added detail

  48. Example for Sequence Diagram[Fowler] • We have an order and are going to invoke a command on it to calculate its price. To do that, the order needs to look at all the line items on the order and determine their prices, which are based on the pricing rules of the order line’s products. Having done that for all the line items, the order then needs to compute an overall discount, which is based on rules tied to the customer.

  49. State machine models • These model the behaviour of the system in response to external and internal events. • They show the system’s responses to stimuli so are often used for modelling real-time systems. • State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another. • Statecharts are an integral part of the UML and are used to represent state machine models.

More Related