Topics. Overview- The UML Functional Model. Structural Model. Behavioral Models. Use Case Diagram (essential and system)

Size: px

Start display at page:

Download "Topics. Overview- The UML Functional Model. Structural Model. Behavioral Models. Use Case Diagram (essential and system)"

Rolf Dorsey
5 years ago
Views:

1 Topics Overview- The UML Functional Model Use Case Diagram (essential and system) Structural Model Class/object, Component and Deployment Diagram Behavioral Models Activity, State chart, sequence /collaboration 1

2 Overview- The UML 11/23/2015 2

3 THE UNIFIED MODELLING LANGUAGE (UML) A language whose vocabulary and rules focus on the conceptual and physical representation of a system. UML defines structural and behavioral things and diagrams. UML is the language of blueprints for software.

4 UML It is a graphical language for Visualizing Specifying building models that are precise, unambiguous, and complete Constructing possible to map from a model in the UML to a programming language Documenting Intended for software-intensive systems

5 WHAT UML IS NOT UML is not a method or methodology (Method = Notation (e.g.,uml) + Process) UML does not dictate a particular process UML can be used to record the resulting domain and design models, independent of the process Choose an appropriate process for a particular project, independent of the modeling language

6 WHY USE UML Standardized notation without sacrificing specialized model data Common language that can be used from product conception to delivery, from system to detailed design levels Reduced learning curve across projects Increased domain and design model reuse Increased customer involvement /understanding of problem translation to product solution

7 UML STRUCTURE UML Building blocks Common mechanisms Architecture Building blocks things relationships Diagrams Common mechanisms specifications Adornments/ dicoration common divisions extensibility mechanisms Architecture use-case view logical view process view implementation view deployment view

8 The Unified Modeling Language (UML) UML has three building blocks: Things, the objects. Relationships, the glue that holds things together. Diagrams, categorized as either structure or behavioral.

9 UNDERSTANDING UML BUILDING BLOCKS OF UML 1. Things the abstractions 1. Structural things nouns, static, represent conceptual or physical elements: Class, interface, collaboration, use case, active class, component, and a node 2. Behavioural things verbs, dynamic, represent behaviour over time and space: Interaction and state machine 3. Grouping things organizational parts of UML: Packages 4. Annotational things explanatory parts of UML: Note

10 BUILDING BLOCKS OF UML 2. Relationships tie things together A. Dependency (uses) a semantic relationship between two things in which a change to one thing (the independent thing) may affect the semantics of the other thing (the dependent thing) A car uses a fuel B. Association a structural relationship that describes a set of links, a link being a connection among objects. association 0..1 employer role name * employee

11 BUILDING BLOCKS OF UML C. Generalization (is a) a specialization/generalization relationship in which objects of the specialized element (the child) are substitutable for objects of the generalized element (the parent)

12 BUILDING BLOCKS OF UML 3. Diagram The graphical representation of a set of elements Help to visualize a system from different perspectives May contain any combination of things and relationships.

13 UML DIAGRAMS Diagrams used to describe structure Class diagram Object diagram Component diagram Deployment diagram Diagrams used to describe behavior and Function Use Case diagram (functional) Sequence diagram Activity diagram Collaboration diagrams Statechart diagram

14 Commonly Used UML Diagrams The most commonly used UML diagrams are: Use case diagram, describing how the system is used. The starting point for UML modeling. Activity diagram. Each use case may create one activity diagram.

15 Commonly Used UML Diagrams Sequence diagram, showing the sequence of activities and class relationships. Each use case may create one or more sequence diagrams. A collaboration diagram is an alternative to a sequence diagram.

16 Commonly Used UML Diagrams Class diagram, showing classes and relationships. Sequence diagrams and CRC cards are used to determine classes. Statechart diagram. Each class may create a statechart diagram, useful for determining class methods.

17 Overview of UML Diagrams

18 RULES OF UML UML s building blocks should be put together to develop a well-formed model. A model that is semantically self-consistent and in harmony with all its related models. The UML has semantic rules for Names: What you can call things, relationships,and diagrams Scope:The context that gives specific meaning to a name. Visibility: How those names can be seen and used by others Integrity:How things properly and consistently relate to one another. Execution:What it means to run or simulate a dynamic model.

19 Requirement gathering Requirements gathering team The role of SMEs Fundamental requirements gathering techniques Brainstorming Interview Documents Observation 11/23/

20 Functional Model Use Case Diagram Essential System 11/23/

21 USE CASE MODEL Use Case analysis is one of the first and primary means of gathering requirements in the behavioral methodology. Use cases are a standard technique for gathering requirements in many modern software development methodologies. Used to capture the intended behaviour of the system under development (requirements of a system) The Use case diagram is used to identify the primary elements and processes that form the system. 21

22 Cont Represents the functional requirements of a system under development Captures the business processes carried out in the system A use case model may consists of Single use case diagram Further (nested) packages of use case diagrams The supreme package of the nested packages is the use case model

23 Cont.. Use case Modeling could be Essential Used at requirement elicitation stage Technology free Just to understand what users need to see on the system from functions point of view System Is a continuation of essential use case Adding implementation related details 11/23/

24 Use case Modeling The system use case talks more about more or less same concept like the essential use case with some details of the implementation. The modeling will be influenced by the technology to be used for the systems development. System use case model is composed of the system use case diagram and its corresponding documentation. The use case diagram and the documentation will have same components as the essential use case model with little technology influence.

25 Components Diagram with the following components Actors Use cases Boundary Relationship (Associations, include or use, Extend) Documentation For each use case using the standard template

26 USE CASE DIAGRAM Shows the relationship between actors and use cases in a system A use case diagram for a system consists of : The system boundary Actors Use cases Relationships (among use cases, among actors, and between actors and use cases) 26

27 On-line Bookstore System Register Customer Order books Sell used books Use Case Functional Requirements Diagram Review books 27

28 What is the difference with the previous use case? Sell Item Sales Clerk Reorder <<Includes>> Login Add to Stock <<Includes>> <<Includes>> Generate Report Manager

29 Cont The Use Case documentation needs information like: List of Actors List of Business Rules (BR) List of User Interfaces (UI) The template will be the same as the essential use case documentation except that the Include and Extend part will be exercised (included) at this level. The following example describes one of the use cases documentation from the previous use case diagram.

30 Use case documentation Name Identifier Description Actor Pre Condition Post Condition Sell Item UC-008 Sell available items in a store to a customer Sales Clerk none The sales clerk will sell the item if available in store Extends none Includes UC-001 Basic Course of Action 1.The Sales Clerk want to sell an item 2.The Sales Clerk logs into the systemusing UC-001: Login 3.The systemdisplays the main Window UI-002: Main Menu 4.The Sales Clerk selects Sell from the Main Menu 5.The systemdisplays the Sell interface UI-006: Sell Item 6.The Sales Clerk selects the items and quantity he want to sell 7.The systemcheck the availability of the items according to the business rule BR-012: check availability ofitem 8.The systemdisplays the total amount of money to be paid with the item list via UI-013: Payment Voucher 9.The Sales Clerk indicates he want toprint the payment voucher. 10.The systemprints the payment voucher 11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer. Alternative Course of Action A: The item is not available in store 8.The systemdetermines that the item is not available. 9.The systeminforms the Sales Clerk that the transaction can not be completed via UI-014: Item Quantity not Available 10.The use cases resumes at step 6 of the basic course of action

31 Cont Note Association between Actors and Use cases dictate the need for Interfaces (screen or Report) Use case description does not include unexpected interruption of the action either by the actor or by system failure The flow of events should be in actionresponse style.

32 General steps in Use case Modeling Identify actors from the SRS or problem definition Identify use cases Identify relationships Use symbols for representing use cases and actors with in a boundary Define use case description 11/23/

33 Actor An actor define roles that users can play. Actors model anything that needs to exchange information with the system The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. 33

34 Actor Actors are external to the system. Actors interact with the system. Actor classes have actors instances or objects that represent specific actors. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary. To identify an actor, search in the problem statement for business terms that portray roles in the system. Doctor Patient Student 34

USE CASES A use case is a specific way of using the system by performing some part of the functionality. A visual representation of a distinct business functionality in a system.

35 USE CASES A use case is a specific way of using the system by performing some part of the functionality. A visual representation of a distinct business functionality in a system. The business process is discrete in nature. A use case describes what a system does; not how. List the discrete business functions in your problem statement - potential use case. Remember that identifying use cases is a discovery rather than a creation. 35

36 USE CASES A use case is shown as an ellipse in a use case diagram Make Appointment Perform Medical Tests Use cases have the following characteristics: Use case are interactions or dialogs between a system and actors, including the messages exchanged and the actions performed by the system. Use cases may include variants of these sequences, including alternative and exception sequences. Use cases may be initiated by actors and may involve the participation of numerous other actors. Use cases may have extension points that define specific points within an interaction at which other use cases may be inserted Use cases classes have use case instances or objects called scenarios that represent specific interactions. 36

37 Use-Cases: describing how the user will use the system A use case is a typical sequence of actions that a user performs in order to complete a given task The objective of use case analysis is to model the system from the point of view of how users interact with this system when trying to achieve their objectives. It is one of the key activities in requirements elicitation and analysis 37

38 Use cases A use case should Cover the full sequence of steps from the beginning of a task until the end. Describe the user s interaction with the system... Not the computations the system performs. Be written so as to be as independent as possible from any particular user interface design. Only include actions in which the actor interacts with the computer. 11/23/

39 Scenarios A scenario is an instance of a use case A specific occurrence of the use case a specific actor... at a specific time... with specific data. 11/23/

40 RELATIONSHIPS Relationships between cases actors and use are represented by directional or nondirectional edges May be annotated by stereotypes May relate two use cases May relate two actors, or May relate a use case and an actor 40

41 RELATIONSHIPS Association denoted as solid lines or paths. Arrowheads may be used to indicate who initiates communication in the interaction. Includes Indicates that the base use case will contain the inclusion use case. A base use case defines the location at which the inclusion use case is included. Denoted as dashed lines with an open arrow-head pointing at the inclusion use case and are labelled with the <<include>> keyword (stereotype). 41

42 RELATIONSHIPS Extends Indicates that the base use case may be augmented by the extension use case; i.e., the inclusion use case will augment the base use case if an extension condition is satisfied. A base use case defines the extension point. Denoted as dashed lines or paths with an open arrow-head pointing an extension use case labelled with the extension condition in square brackets, the <<extend>> keyword (stereotype),and the extension point name in parentheses. 42

43 RELATIONSHIPS Generalization From specialization to generalized use case Indicate the specialization use cases are consistent with the generalized use case and may add additional information. A specialized use case may be used in place of a generalized use case and may use any portions of the interaction of the generalized use case. Denoted as solid lines or paths with a hollow arrow-head pointing at the generalized use case. From specialization to generalized Actor The specialized actor are consistent with the generalized actor and may add additional information. A specialized actor may be used in place of a generalized actor and receives the characteristics of the generalized actor. Denoted as solid lines or paths with a hollow arrow-head pointing at the generalized actor. 43

44 RELATIONSHIPS Place Order set priority «extends» Place rush oder <<includes>> Check password Track Order <<includes>> Validate User Retinal Scan 44

45 System Boundary The use case describes the functionality of a system from an outside point of view from the users point of view. Only the interaction between actors and system are shown, what happens inside the system is hidden. This boundary is clarified by the system boundary Defines the scope of what a system will be. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system 45

46 SYSTEM BOUNDARY A use case diagram depicting the system boundary of a clinic application Clinic Patient * * Make Appointment * * Perform Medical Tests Doctor 46

47 RELATIONSHIPS Library User (Patron) Faculty Members NonAcademic Staff Students External User 2ndYear 3rdYear 4thYear 5thYear Postgraduate 47

48 FLOW OF EVENTS Specify the behavior of a use case by describing the flow of events in text clearly enough for an outsider to understand it easily. Include How and when the use case starts and ends When the use case interacts with the actors What objects are exchanged The basic flow and alternative flows of the behavior 48

49 HINTS AND TIPS A well-structured use case diagram Is focused on communicating one aspect of a system s static use case view. Contains only those use cases that are essential to understanding that aspect. Provides detail content with its level of abstraction. Is not so minimalist as to misinform the reader about semantics that are important. 49

50 A Library System Online library system desired to keep record of new books, CD, and journal and track when they are borrowed and returned The system must support the librarian work to add delete and update library properties. The library is open to university staff and students. University staff can borrow up to 25 different items and students can borrow up to 15. The system shall allow users to search and borrow an item if available 50

51 Example: On-line Bookstore is a web application that can be accessed by the store s registered customer, whereby each customer can order books, review one or more books sold in the book store, and sell used books to other customers. Before performing any one of these transactions, the customer must first log-in into the system using their user id and password kept in their account. The customer can also take a book he/she ordered. Problems: Develop a use case model(system use case)-provide your reason to pick one as a component of your model Document one of the use cases you have identified sell used book

52 On-line Bookstore System Register Customer Order books <<extend>> (CustID) <<include>> Check out Sell used books <<include>> <<include>> Log-in Review books 52

53 Use case: Sell used books Main flow of events: - 1. The CUSTOMER clicks the Sell Used Books button on the Home Page. 2. The system displays the sell used books web page. 3. The CUSTOMER enters the required information on the used books that he/she wants to sell. 4. The CUSTOMER clicks the SEND button on the webpage. 5. The system displays a confirmation page listing the information that the CUSTOMER has entered. 6. The CUSTOMER checks that the information displayed are accurate. If yes, the CUSTOMER clicks the OK button on the web page. 7. The system updates the USED BOOKS table in the database. 53

54 The benefits of basing software development on use cases They can Help to define the scope of the system Be used to plan the development process Be used to both develop and validate the requirements Form the basis for the definition of test cases Be used to structure user manuals 11/23/

55 Use cases must not be seen as a solution The use cases themselves must be validated Using the requirements validation methods. Some aspects of software are not covered by use case analysis. Innovative solutions may not be considered. 11/23/

56 Exercise-one The clock shows the time of day. Using buttons, the user can set the hours and minutes fields individually, and choose between 12 and 24-hour display. It is possible to set one or two alarms. When an alarm fires, it will sound some noise. The user can turn it off, or choose to snooze. If the user does not respond at all, the alarm will turn off itself after 2 minutes. Snoozing means to turn off the sound, but the alarm will fire again after some minutes of delay. This snoozing time is pre-adjustable. Q: Identify the top-level functional requirement for the clock, and model it with a use case diagram. 11/23/

57 Exercise-two Open Road Insurance (ORI) is an independent agency that receives policy contracts from various insurance companies. The purpose of the ORI system is to provide automotive insurance to car owners. Initially, a customer applies for coverage via an application. The agency requests a driver s record report from the local police department. The agency also requests vehicle registration confirmation from the Department of Motor Vehicles. An agent determines the best policy for the type and level of coverage desired and sends the customer a copy of the insurance policy along with an insurance coverage card. The customer information is stored. Periodically, the system generates a fee statement, which along with addendums to the policy is sent to the customer, who responds by sending in a payment with the fee stub. 11/23/

58 Guide Lines Ask who, what, and where about the tasks and their inputs and outputs: What are the major tasks performed? What triggers this task? What tells you to perform this task? What information/forms/reports do you need to perform this task? Who gives you these information/forms/reports? What information/forms/reports does this produce and where do they go? 11/23/

Chapter 5: Structural Modeling

Chapter 5: Structural Modeling Objectives Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. Understand the processes used to create CRC cards, class