EE 446 EMBEDDED ARCHITECTURE Embedded System in UML

Transcription

1 EE 446 EMBEDDED ARCHITECTURE Embedded System in UML Airs Lin UML (UNIFIED MODELING LANGUAGE) 1

2 What is UML? Created and developed by Grady Booch, Ivar Jacobson, and James Rumbaugh at Rational Software (1994~1996) In 1997, it was adopted as a standard and managed by OMG (Object Management Group) In 2000, the UML was accepted by the ISO (International Organization for Standardization) as an approved ISO standard The UML is a graphical Object Oriented Modeling Language General purpose modeling language in the field of software engineering Provides a standard way to visualize the design of a system Widely used for business modeling and other non software systems UML is not a "process" It does not tell you how to do things, only what you should do Why Use UML? UML is a fusion of ideas from several precursor modeling languages We need a modeling language to: Help develop efficient, effective and correct designs, particularly Object Oriented Designs Communicate clearly with project stakeholders (concerned parties: developers, customers, etc.) Give us the big picture view of the project 2

3 Types of UML 2.x Diagrams Most Helpful UML Diagrams Use Case diagram: represents functions of a system from the user's point of view Class diagram: represents the static structure in terms of classes and relationships Sequence diagram: is a temporal representation of objects and their interactions Statechart diagram: represents the behavior of a class in terms of states Activity diagram: represents the behavior of an operation as a set of actions Deployment diagram: represents the deployment of components on particular pieces of hardware 3

4 USE CASE DIAGRAM What are the Requirements? In the world of business analysis, a requirement defines Feature: future solution has to enable Cloud access Function: future solution has to execute Calculate savings Fact: future solution has to enforce FCC regulation XYZ Quality: future solution has to exhibit Access to a file in 1 second IIBA (International Institute for Business Analysis) defines four fundamental types of requirements: Business requirements Stakeholder requirements Solution requirements Transition requirements 4

5 Requirement Analysis Functional requirements Describe a list of functions that the system must accomplish Quality (Nonfunctional) requirements Describe other constrains Performance expectations Technologies to be used Use Case Diagram Use Case diagrams model the behavior of a system and help to capture the requirements of the system Use Case diagrams describe the high level functions and scope of a system Use Case diagrams also identify the interactions between the system and its actors Use Case and actors describe what the system does and how the actors use it, but not how the system operates internally 5

6 When Use Case is Applicable? Before starting a project Create Use Case diagrams to model a business so that all participants in the project share an understanding of workers, customers, and activities of the business While gathering requirements Create Use Case diagrams to capture the system requirements and to present to others what the system should do During the analysis and design phases Apply the Use Case and actors to identify the classes that the system requires During the testing phase Apply Use Case diagrams to identify tests for the system Basic Use Case Syntax 6

7 A Use Case Diagram Use Case diagram Presents main components of the system Shows how the user interacts with those components Three main components Actor(s) Use Case(s) System boundary UML Use Case Diagram Example 7

8 Symbols of Use Case Diagram # Name 1 Actor A class of people or system that interact with a system 2 Association Indicates that instances of one model element are connected to instances of another model element 3 Directed Association Directed association relationships are associations that are navigable in only one direction 4 Generalization 5 Dependency 6 <<include>> Include 7 <<extend>> Extend 8 System A generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent) One element, or group of elements, acting as the client depends on another element or group of elements that act as the supplier An include relationship is a relationship in which one Use Case (the base Use Case) includes the functionality of another Use Case (the inclusion Use Case). Specifies that one Use Case (extension) extends the behavior of another Use Case (base). This type of relationship reveals details about a system or application that are typically hidden in a Use Case A System Boundary is a type of partition that represents the boundary between the item you are representing with the Use Cases (inside the boundary) and the actors (outside the boundary) Use Case Diagram Association (1) An association between an actor and a Use Case indicates that the actor and the Use Case communicate with each other An actor could be associated to one or several Use Cases Actor Customer associated with two Use Cases. 8

9 Use Case Diagram Association (2) Use Case may have one or several associated actors Use Case Manage Account associated with Customer and Bank actors. Use Case Diagram Directed Association Introduce an actor called Time to initiate scheduled events 9

10 Use Case Diagram Generalization (1) A parent Use Case may be specialized into one or more child Use Cases that represent more specific forms of the parent A child inherits all structure, behavior, and relationships of the parent Generalization is used when you find two or more Use Cases that have commonalities in behavior, structure, and purpose. When this happens, you can describe the shared parts in a new Use Case, that is then specialized by child use cases. Web Client actor is abstract superclass for Administrator, Editor and Customer Use Case Diagram Generalization (2) Generalization between Use Cases is similar to generalization between classes child Use Case inherits properties and behavior of the parent Use Case and may override the behavior of the parent Phone Order and Internet Order Use Cases are specializations of the abstract Use Case Place Order 10

11 Actor USE CASE DIAGRAM What is an Actor? All the actor items that live outside the system and interact with the system constitute the system s context The context defines the environment in which the system lives 11

12 Main Categories of Actors 1. Principal Actors People who use the main system functions 2. Secondary Actors People that perform administration or maintenance tasks 3. External Hardware The unavoidable hardware devices that are part of the application domain and must be used 4. Other Systems The other systems with which the system must interact How to Find the Actors 1. Who will use the system? 2. Who will install the system? 3. Who will activate the system? 4. Who will maintain the system? 5. Who will shutdown the system? 6. Any other systems will operate with this system? 7. Who will receive the data from the system? 8. Who will provide the data to the system? 9. What function will be automatically executed by the timer? 10. Any other systems will be connected with this system? 11. Any hardware devices will be connected with the system? 12. Any database will be connected with the system? 13. Anyone inside of the company will operate the system? 14. Anyone outside of the company will operate the system? 12

13 The Characters of Actor 1. If the actor is external and does not belong to any part of the system, then we do not need to include this actor 2. Only the actors who will use and interact with the system, and/or exchange the information with the system, are needed by the system 3. Only the actors can actively participate with Use Cases. Identify actors who will guide us to find the Use Case 4. Consider interfaces. The system needs to provide interfaces to actors, or uses the interfaces which are provided by the actor Actors Table Human System Type Detail Actors Hardware Devices People outside the company People inside the company Internal system External system Database Schedule Customers Employees, Managers Accounting system, Inventory system Yes Weekend Bar code scanner Online Bookstore System 13

14 Create the System Description System Name Online Bookstore System Description The system provides following functions for customers: 1. Online order 2. Online payment 3. Shipping service The system needs to integrate with current accounting and inventory systems Organized Key Points 1. Main functions: online order, online payment, shipping service 2. Integrate with current accounting and inventory systems USE CASE DIAGRAM 14

15 Why Consider Use Cases? In a traditional Software Requirements Specification (SRS), features are presented without context. For example: The system will have to do the following The system should do the following The system will end up doing the following It is of the utmost importance that It would be interesting to A traditional SRS are often expressed in an unstructured way Very difficult for the system s stakeholder to absorb Use Cases break requirements down into short scenarios More easily understood Benefits of Use Cases Good way to start identifying objects from scenarios Test plan can be immediately generated based on Use Cases Easier user validation Helps technical writers in structuring the overall work on the users manuals at the early stage Better traceability throughout the system development process Quality of the software is improved by identifying the exception scenarios earlier in the development process 15

16 Use Case Diagram How to Define the Use Case 1. What kind of functions will be provide to actors? 2. Does the system need to store any information? Who will create/read/update/delete this information? 3. If there are any internal state changes, does the system need to notify any actors? 4. Does the system need to handle any external event? When the event occurs, will the system need to notify any actors? 5. Does the system need to execute scheduled job? 6. When some important event occurs, does the system need to automatically execute any job? 7. Can we find any Use Case from the title of the Use Case Diagram? 8. Will this Use Case produce multiple results? Or are these results are generated at different times? Actor Use Case Associations Typically, an actor can be associated with one or more Use Cases The actor who initiates Use Cases is placed on the left side, the actor who receive Use Case results is placed on the right side 16

17 Use Case No Internal Behavior Does not represent any internal behavior that system may have, which is only used by other parts of the system Incorrect Correct Use Case No Interactions Between the Actors in the System Correct Incorrect 17

18 Use Case Using Extends/Includes to Add Detail Airline reservation system When passenger check in, the system can assign a seat to them Initial Design Sub Diagram Use Case Using Extends/Includes to Add Detail (2) To add detail (extension) 18

19 Use Case Diagram Library's Internet Portal Library members access the library's internet portal Log in View books Order books Use Case Diagram Inertial Measurement Unit (IMU) 19

20 Use Case Description Use Case Short description Who or what is using this Use Case? Is this used by Actors other Use Cases? Brief Description Detail description Pre conditions What needs to be done before the Use Case is executed? Supporting Actor Post conditions What is changed after the Use Case is executed? This can be used to verify if the Use Case has successfully been executed Basic Flow A list of steps that will normally occur Alternative Flows If something goes wrong or if the normal flow varies, then the alternative flow is described here Special Requirements Comments and requirements to the Use Case Use Case Relationships Some of the steps might be described in other use cases. These use cases are listed here Use Case Description Example Use Case UC2 View details for a Blu ray disc Actor Customer Supporting Actor Brief Description As a customer I would like to view the details for a specific Blu ray disc Pre conditions UC1 must have been done Post conditions Details shown Basic Flow of Events 1. Customer clicks on a Blu ray from the list 2. Web store sends a request about details for the given Blu ray disc to the DB 3. DB retrieves the requested data and sends it to the Web store 4. Web store displays product details Alternative Flows Special Requirements Use Case Relationships 20

21 Use Case Diagram A Residential Heating System Specification: Both the janitor and the resident can use the thermostat Only the resident can control the automatic timer Case Study 1: An Intersection Traffic Control System 21

22 Case Study 1: System Description Pedestrian pushes button, generating service request to software and receives, in time, the Walk signal In ACTUATED mode, vehicle enters the intersection, generating service request to software and receives, in time, the Okay to Proceed signal In ADAPTIVE mode, vehicle passes over the loop detector, increasing the vehicle count, which, in turn, causes an adjustment in intersection timings Emergency vehicle operator activates the emergency vehicle override signal, generating priority service request to software and receives, in a preemptive time, the Okay to proceed signal Traffic regulatory personnel will remove the manual override device from the control box and press buttons to control the intersection manually Remote operator uses a software control panel either to control the state of the intersection directly or to observe and manipulate the parameters and state of a specific intersection control system Maintainer accesses system through Ethernet port to perform maintenance Case Study 1: System Functions The Intersection Control System provides the following functions: 1. Control of the intersection vehicle traffic standards 2. Control of the intersection pedestrian traffic standards 3. Collection and processing of traffic history from all approaches 4. Adaptive control of intersection timings in response to traffic flow 5. Actuated control of intersection in response to vehicle presence 6. Timed control of intersection in response to a fixed scheme 7. Handling of pedestrian crossing requests 8. Handling of emergency vehicle pre emption 9. Intersection control in response to manual override commands 10. Intersection control in response to remote override commands 11. Management of traffic history and incident log databases 12. Handling of maintenance access requests from the maintenance port 13. Handling of maintenance access requests from the DOT WAN 22

23 Case Study 1: Actors 1. Vehicle Presence Detector User: Motor Vehicle 2. Pedestrian Presence Detector User: Pedestrian 3. Emergency Vehicle Override User: Emergency Vehicle 4. Manual Override User: Traffic Control Officer 5. Remote Override User: DOT Network 6. Maintenance Interface User: Maintainer Case Study 1: Top Level Use Case Diagram 23

24 Case Study 2: Medical Clinic Scenario for the medical clinic A patient calls the clinic to make an appointment for a yearly checkup The receptionist (scheduler) finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot Case Study 2: Use Case Diagram System Requirements The patient and scheduler are actors involved in making and cancelling appointments The patient can request medication from the doctor The tasks associated with paying the bill happen between the patient and the clerk 24

25 Case Study 2: Use Case Diagram System Requirements The patient and scheduler are actors involved in making and cancelling appointments The patient can request medication from the doctor The tasks associated with paying the bill happen between the patient and the clerk 25