UML - ::: Welcome to fivedots.coe.psu.ac.th

UML - ::: Welcome to fivedots.coe.psu.ac.th

Chapter 8 UML Design Aree TEERAPARBSEREE, Ph.D. Department of Computer Engineering Faculty of Engineering, Prince of Songkla University 1 OO Analysis / Design / Programming Domain OOA OOP Definition of the problem OOD/ Model Program Construction of the solution Teaching material base on Prof.Koichiro Ochimizu,SOI: UML course

2 Modeling the Domain Problem h 1 h 2 a 1 a 2 The world view: We can represent the domain simply by A set of objects and their interaction Description of possibility hungry

person state of hunge ea r t : hungry person apple satisfy volum hunger e eaten Progra m public class hungry-person { int state-of-hunger void eat () { }

: apple volum e eaten() public class apple { int volume void eaten () Definition of static structure and dynamic behavior stateofhunge r eat() } volum e eaten() Reproduction

of the Domain in the main memory 3 UML Very popular now and help us make and analyze: Use-case Diagrams for defining functional requirements Collaboration Diagrams for finding analysis classes Class Diagrams for designing the static structure Sequence Diagrams for defining objects interaction State Diagrams for defining the behavior of each object

Deployment Diagrams for allocating objects to machines Component Diagrams for packaging 4 The Views in UML Deployment View Component View Use-Case View Logical View Concurrency View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc.

5 Relationships between views and diagrams Deployment diagram Component Component Deployment View View Use-Case View diagram State diagram Sequence diagram Collaboration diagram Logical View Concurrency

View Collaboration diagram Class diagram Activity diagram Object diagram State diagram Sequence diagram Use-case diagram 6 The Unified Software Development Process Use-Case Model Use-Case Diagram Analysis Model describe Realization of a Use-Case by a Collaboration Diagram and a Flow of Event Description Design Model Class Diagram, Sequence Diagram, and State Diagram Deployment Model

Deployment Diagram Implementation Model Component Diagram Test Model Test Case 7 Use-Case View Deployment View Component View Use-Case View Logical View Concurrency View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 8

Use Case Model Use Case Model: A use case model represents the functional requirements and consists of actors and use cases. A use case model helps the customer, users, and developers agree on how to use the system. Actor: An actor is someone or something that interacts with system. System: Black box provided with use cases Use Case: A use case specifies a sequence of actions that the system can perform and that yields an observable result of value to a particular actor. I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 9 Development of Use Case Model Defining the System Finding Actors and Uses Cases Use Case Descriptions Defining Relationships between Use Cases Verify and Validate the Model H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 10

What is an Actor ? An actor is someone or something that Interacts with the system. The actor is a type (a class), not an instance. The actor represents a role, not an individual user of the system. Actors can be ranked. A primary actor is one that uses the primary functions of the system. A secondary actor is one that uses secondary functions of the system, those functions that maintain the system, such as managing data bases, communication, backups, and other administration tasks. H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 11 Finding Actors Who will use the main functionality of the system ? Who will need support from the system to do their daily tasks ? Who will need to maintain, administrate, and keep the system working (secondary actor) ? Which hardware devices does the system need to handle ? With which system does the system need to interact ? Who or what has an interest in the result (the value) that the system produce ?

H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 12 What is a Use Case ? A use case represents a complete functionality as perceived by an actor. A use case is always initiated by an actor. A use case provides values to an actor. A use case is complete. Use cases are connected to actors through associations (communication association). A use case is a class, not an instance. A instantiation of a use case is called a scenario. Ex. Signing Insurance (Use Case) Ex. John Doe contacts the system by telephone and signs for car insurance for the car he just bought. (scenario) H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 13 Finding Use Cases Which functions does the actor require from the

system ? What does the actor need to do ? Does the actor need to read, create, destroy, modify, or store some kind of information in the system ? Does the actor have to be notified about events in the system, or does the actor need to notify the system about something ? What do those events represent in terms of functionality ? Could the actors daily work be simplified or made more efficient through new functions in the system ? H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 14 Example: A Use-Case diagram Withdraw Money UML Notation Use Case Bank Customer Deposit Money Actor

Transfer between Accounts I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 15 Logical View Deployment View Component View Use-Case View Collaboration diagram Class diagram Logical View Concurrency View

Object diagram State diagram Sequence diagram H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 16 Analysis of inside of the system Collaboration Use Case Collaboration Actor Collaboration 17 Analysis Model Use-Case Model Withdraw Money Analysis Model

<> Withdraw Money Dispenser Cashier WithdrawalAccount Interfac e I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 18 Collaboration << trace >> Dependency A collaboration gives a name to the mechanism of the system It also serve as the realization of a use case Three different stereotypes on classes Control Boundary Entity

It defines a group of objects and their interaction I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 19 Analysis Model: Collaboration 1: identify 2: request withdrawal : Cashier Interface : Bank 3: validate and withdraw : Withdrawal : Account Customer 5: dispense money 4: authorize dispense :Dispenser

I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 20 Flow of Events Description of a Use-Case Realization A Bank Customer chooses to withdraw money and activates the Cashier Interface object. The Bank Customer identifies himself or herself and specifies how much to withdraw and from which account (1). The Cashier Interface verifies the Bank Customers identity and asks a Withdrawal object to perform the transaction (2). If the Bank Customers identity is valid, the Withdrawal object is asked to confirm that the bank customer has the right to withdraw the specified amount from the Account. The Withdrawal object confirms this by asking the Account object to validate the request and, if the request is valid, withdraw the amount (3). Then the Withdrawal object authorizes the Dispenser to dispense the amount that the Bank Customer requested (4). The Bank Customer then receives the requested amount of money (5) 21 Analysis of inside of the system Collaboration

Use case Event Flow Description Actor Collaboration Collaboratio n Diagram Collaboration I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 22 A Class Participating in Several Use-Case Realizations in Analysis Model Analysis Model Use-Case Model Dispense r

Withdraw Money Bank Custome r Transfer between Accounts Deposit Money Bank Custome r Cashier Interfa ce Money receptor I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. Withdraw

al Transfe r Account Deposit 23 Analysis Class and Design Class Analysis Classes Cashier Interface < > Display Key Pad Card Reader Design Classes Dispense r

< > Dispenser Sensor Dispenser Feeder Cash Counter Withdrawal < > withdrawal Account <> Account Client Manager Transaction Manager Persistent Class Account

Manager 24 Group Classes into Subsystems <> Transaction Management <> ATM interface Card Reader Display Bank Custome r Key Pad Dispenser Feeder Withdraw al Client Manager Cash

Counter Dispensin g <> Account Management Transaction Manager <> Withdrawal Management Withdrawal Persistent Class Transfers Account Manager

Account Dispenser Sensor I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. 25 Components that implements Design Classes Client Manager <> < > <> Dispenser Feeder Dispenser Sensor client.exe client.c

<> < > Cash Counter I. Jacobson, G.Booch, J.Rumbaugh,The Unified Software Development Process, 1999. <> dispenser.c 26 Finding Classes Do we have information that should be stored or analyzed? It is a possible candidate for a class. The information might be concepts that must be always be registered in the system or events or transactions that occur at a specific moment. Do we have external system? If so, they are normally of interest when we model. Are there devices that system must handle ? Which roles do actors in the business play ? There roles can be seen as classes; for example, user, system operator, customer,

and so on. 27 UML notation Classname OR Class Name Client Manager Active Class Has a thread and can initiate a control activity Attributes Methods/ functions/ behaviors 28 Class Diagram Card Reader Display

Bank Customer Transaction Manager Client Manager Key Pad Persistent Class withdrawal Account Dispenser Feeder Dispenser Sensor Cash Counter Account Manager 29

Representation of Relationships between Classes Association Navigable Association Dependency Aggregation: whole-part association Composition: the same life span Generalization 30 Class Association We graphically illustrate the association (relationship) between two classes as a connecting line. Verb phrases describe the relationship. All relationships are implicitly bi-directional

Multiplicity defines the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Because all relationships are bi-directional, multiplicity must be defined in both directions for every relationship. 31 Multiplicity Example UML Notation 1 0..* 0..1 1..* Class name one and only one Class name

zero or more Class name zero or one Person 0..* Car owned by Person Class name 1..* owns owns 0..* Car

one or more H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 32 A class diagram: an Insurance business Insurance policy 0..1 1 Insurance Company 1 0..* Insurance contract 0..* 1..* Customer H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc.

33 Aggregation objects/classes can be made up of other objects/classes. This relationship is called aggregation. It is also sometimes known as whole-part or partof relationships. Ex., a BOOK object may contain several objects, including: COVER, TABLE OF CONTENTS, CHAPTER, and INDEX objects. The CHAPTER object contains PAGE objects, which in turn contain PARAGRAPH objects, which in turn contain WORD objects, and so forth. By identifying aggregation relationships we can partition a very complex object and assign behaviours and attributes to the individual objects within it. Multiplicity is also specified for aggregate relationships 34 Aggregate Relationship Book Cover

Table of Contents Chapter Index Page Paragraph Word 35 Composition The whole owns the instances of the parts. Those instances cannot belong to any other instance of the whole. Composition aggregation forms a tree structure. Aircraft 1+ Engine 2

Fuselage Wing 2+ A part cannot belong to more than one whole Door Landing Gear 36 Generalization Inheritance implies that methods and/or attributes defined in an class can be inherited or reused by another class. Generalization / specialization attributes and behaviours that are common to several types of an object classes are grouped into their own class, called a supertype. Supertypes are generalizations of subtypes. Subtypes are specializations of supertypes.

In the object class PERSON, STUDENT and PROFESSOR example, PERSON is referred to as a supertype (or generalization class) whereas STUDENT and PROFESSOR are referred to as subtypes (or specialization class). 37 Generalization Relationship Person last name first name walk sleep talk eat Student Classification Student ID enrol Supertype and Subtype relationship Between object classes

Professor rank lecture 38 Dont confuse aggregation and inheritance Aggregation relates to Instances Inheritance relates to Classes 1 Plane 1+ 2 Commercial Private Fuselage Engine Wing Military 39

Class Diagram (Analysis Class + Design Class) Use Case Actor 40 Dynamic Model State Diagram Describe which states an object can have during its life cycle Sequence Diagram Describe how objects interact and communicate with each other The primary focus in sequence diagrams is time Collaboration Diagram

Describe how objects interact But the focus in a collaboration diagram is space Activity Diagram Describe how objects interact But the focus in an activity diagram is work 41 State Model Represent the behavior of an object by a state transition diagram. State Diagrams chart the life-span of an object from creation to destruction and the discrete (finite) states in-between Event something that happens at a point in time. An event has no duration. For example, received messages, time-outs, error exceptions. State

an abstraction of the attribute values and links of an object Activity an operation that takes time to perform closely associated with a state Action an operation performed on a state change 42 State diagram: notation name of an action that is a pre-condition before event which performed when a transition occurs causes transition the event occurs State 1 do/activity 1 event [condition] /action State 2 Starting point H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc.

... Finish State 43 Example State Diagram Invoice created Unpaid Paying Invoice destroyed Paid 44 Relationship between State Diagram and Class Diagram A state diagram relates to ONE class within a class diagram. The received events are often messages that will have originated at one of the other classes with which the class in question has a relationship.

Events are basically received messages and are therefore handled by a receiving class operation. Actions - happening upon a state transition - are usually class operations that may result in a message being sent to another object. Activities - happening within a particular class state - are usually class operations. 45 A State Diagram Alarm System Passive access code typed in Monitor Intruder alert/ do/ check phone police detectors Detected do/ ring bell flash lights [30 seconds passed]

correct access code typed in 46 Another Example - Digital Watch A simple digital watch has a display and two buttons to set it, the A button and the B button. The watch has two modes of operation, display time and set time. In the display time mode, hours and minutes are displayed. The set time mode has two sub modes: set hours and set minutes. The A button is used to select modes. Each time it is pressed, it advances through the modes: display, set hours, set minutes, display ...etc. Within the sub modes, pressing B will advance the hours or minutes each time it is pressed. Buttons must be released before they generate another event. . Create a state diagram for the watch. 47 Possible solution - State Diagram Pressed B / increment hours Pressed A acquire displaying time

Pressed A setting hours Do:Flash hours Pressed A setting minutes Do:Flash minutes Pressed B / increment minutes 48 Events in the state diagram correspond with operations within the class Pressed B / increment hours Pressed A acquire displaying time Digital-watch Pressed A mode-button() inc()

setting hours Do:Flash hours Pressed A setting minutes Do:Flash minutes Pressed B / increment minutes inc/ minutes:=minutes+1 49 Sequence Diagram Sequence Diagrams illustrate how objects (and actors) interact with each other - used to describe scenarios Objects communicate using messages messages are communications between objects that convey information with the expectation that something will happen Sequence diagrams have 2 axes objects along the horizontal axis objects lifeline (time) down the vertical axis

messages represented by arrows message lifeline (time) 50 Sequence Diagram: notation object function() * function() object: class Object - we may also state this with its class name Arguments go in here Iteration - sent many times to multiple receiver objects function2() Self Delegation - an object sends a message to itself

[condition] function() A conditional message (only sent if condition is true) 51 Sequence Diagram : Card Reader : Bank Customer Insert card Show request Specify PIN code Show request Specify amount : Display : Key Pad

: Client Manager : Cash Counter : Transaction Manager Card inserted (ID) Ask for PIN code PIN code (PIN) Ask for amount to withdraw Amount (A) Request PIN validation (PIN) Request cash availability

Request amount withdrawal (A) 52 Sequence Diagram: another example Partial Class Diagram Order OrderLine orderNumber date etc itemnumber quantity etc prepare() check(): boolean remove() StockItem

orderNumber minQuantity date etc is_for ReOrderItem itemnumber quantity etc DeliveryItem deliveryadress quantity etc needsToReorder(): boolean 53 Sequence Diagram anOrder Entry anOrder window prepare()

anOrder Line *prepare( ) aStock Item check() [check=tru e] remove() needsToReorder () [needsToReorder=tru e] new AReorder Item [check=true] new aDelivery Item 54

Collaboration Diagram Collaboration diagrams focus on the interaction and the links between a set of collaborating objects. The sequence diagram focuses on time but the collaboration diagram focuses on space. 55 An example of a collaboration diagram Print(ps-file) :Computer 1: Print(psfile) :Printer :PrinterServer [printer free] 1.1: Print(psfile) H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 56 Activity Diagram An activity diagram is essentially a flowchart, showing flow of control from activity to activity

Actions and Transitions Show messageBox Printing on screen Create postscript file Remove MessageBox Send postscript file to printer H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 57 Transitions are protected by guardedconditions [disk full] CustomerWindow.PrintAllCustom er() Remove MessageBox

Show messageBox Disk full on screen Show messageBox Printingl on screen ^Printer.Print(fil Create postscript e) file H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 58 Parallel Actions .Sampler.Run(channel,freque ncy) Initiate Updating display

H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. Measuring 59 Swim lanes Sampler Displaye r .Sampler.Run(channel,frequen Initiate Updating display H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. cy) Measuring 60

Object Flow Sampler Displaye r .Sampler.Run(channel,frequen Initiate Updating display Measured value H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. cy) Measuring 61 Final Step of Modeling Definition of Static Structure and Dynamic

Behavior Use case Acto r 62 Concurrency View Deployment View Component View State diagram Use-Case View Sequence diagram Collaboration Logical View

Concurrency View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. diagram Activity diagram 63 Class diagram System Handler Log 1 1.. Cell Handler * Supervisor 1.. * Sensor

1.. * Alarm 1 1 LCD Display Wrapper Sound Alarm Keyboard Handler Wrapper 1 1.. * 1 1 H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc.

<> Cell Configuration Information <> System Configuration Information 64 Collaboration diagram :System Handler : Sound Alarm :Phone Alarm 2b. Trigger 2c.2 Trigger : Supervisor : Log

2c.1 Store (Date, Time, Cell, Sensor) :Sound Alarm 2a. Trigger :Cell Handler 2c. Alarm H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 1. Alarm :Photo Cell Sensor 65 Sequence diagram :System Handler A :Cell Handler

:Sensor Activate SelfTest Repeat for each installe d alarm and sensor B ACK Activate :Alarm :Cell Configuration Information Read Configuration Config info

returned SelfTest ACK ACK ACK B - A < 5 sec H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 66 State diagram Activation Phase Alarms SelfTes t Performing Alarm SelfTest / send ACK System

Activated NAK Sensors Activate Comman SelfTes Performing d /Send Sensor SelfTest t Cell Handler creat e Creating device list ACK NAK List

built Activating /send ACK sensor device NAK Initiating success Thread loop H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. Activation Failure 67 Control Flows Control flows are divided into concurrent threads that run in parallel and later become synchronized again. Activate System command System Inactive

Activating Sensors Activating Alarms Initiating Cell Handler H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. / Green light on System Activated Activation Failure 68 Component View Component Deployment View Component

View diagram Use-Case View Logical View Concurrency View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 69 Example of a component diagram Window Handler (whnd.cpp) Comm Handler (comhnd.cpp) Main Class

(main.cpp) Window Handler (whnd.obj) Comm Handler (comhnd.obj) Main Class (main.obj) H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. Graphic lib (graphic.dll) Client Program (client.exe) Source component Binary component Executable component 70 Deployment View

Deployment diagram Deployment View Component View Use-Case View Logical View H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. Concurrency View 71 Deployment diagram User Panel 1

1 <> Alarm System Handler <> Cell Handler <> Sensor <> Alarm H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 1 1 1..* 1..* Sensor

Alarm 72 Node Device nodes and possible stereotype Dell Pentium 466 MMX Bills Machine: Dell Pentium 466 MMX node type <> HP LaserJet 5MP an instance <> Cisco Router X2000

H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. <> SAAB 9-5 Navigator 73 Communication Association between nodes ClientA: Compaq Pro PC TCP/IP Application Server: Silicon Graphics O2 ClientB: Compaq Pro PC < Database >

Server: VAX TCP/IP H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 74 Component Allocation A node type supporting a run-time component type, and a run-time component instance executing in a node instance UNIX Transaction Server Program Executable component instances may be contained within node instance symbols, showing that they reside and execute on the node instance

Bills Machine: Dell Pentium MMX PC <> Transaction Client Library <> Silicon Graphics O2 Client Program Use the services of another compone nt 75 Object Allocation

Objects are allocated to nodes. The transobj object that originally exists in the Main Server node can be distributed to the Dell PC node shown with the stereotype <> Main Server: Quad Pentium PC Bills Machine: Transaction Server Program Dell Pentium MMX PC Client Program transobj < > H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. t1:updatethre ad transobj dlbobj

callobj 76 Complex Modeling Client PC NetDrv 1..* 1..2 Server connected to ApplClient Window95 Admin PC AdminPgm 1 backupMediu

m H.E. Eriksson and M. Penker, UML Toolkit John Wiley & Sons, Inc. 1 Backup Station 77

Recently Viewed Presentations

  • Unit 4 Sensation and Perception Learning Targets Module

    Unit 4 Sensation and Perception Learning Targets Module

    become a hill. AP® Exam Tip 2. ... This distorted room, designed by Adelbert Ames, appears to have a normal rectangular shape when viewed through a peephole with one eye. ... there was simply no way to fit the information...
  • Atmospheric Data Recovery and Biases in Observations Russell

    Atmospheric Data Recovery and Biases in Observations Russell

    dew point depression. wind direction/speed. IGRA v1. IGRA v1. IGRA v2. Other data sets from NCDC archive. MIT and C-CARDS from NCAR (pre-1963) Bronnimannacquisitions (primarily Europe) British Antarctic Survey, Historical Arctic Radiosonde Archive. ... russell.vose Company: NCDC ...
  • Data Management

    Data Management

    Case Study: The Bhopal Plant Disaster • Massive toxic gas leak from Union Carbide India Limited (UCIL) chemical plant at Bhopal in December, 1984.
  • On Some Aspects of Praguian Functionalism

    On Some Aspects of Praguian Functionalism

    Praguian Functionalism and Its Challenges for Linguistic Theory Eva Hajičová Charles University, Prague
  • Getting a nonacademic job with your graduate degree

    Getting a nonacademic job with your graduate degree

    Recipients of the award are engaged in a research and development activity under the supervision of a professor holding an NSERC grant. It is an opportunity to gain research experience in an academic setting, while receiving financial support for summer...
  • Short Story Unit A: &quot;How to Tell a True War Story&quot; &quot;Battle ...

    Short Story Unit A: "How to Tell a True War Story" "Battle ...

    Concepts to be Learned: Main focus-- 1.Genre and Text Structure- What elements make up an effective short story?What is the structure used within the short story? How does diction and syntax play an integral part in creating atmosphere, mood, and/or...
  • Chapter 6

    Chapter 6

    Fully dressed. Steps. Choose system boundary. Identify primary actors. Identify goals of primary actors. Define use cases that satisfy the goals. Use case names should start with a verb! Tests. Boss test - is the boss happy? Elementary Business Process...
  • A Mathematical Model for Idiopathic Intracranial Hypertension

    A Mathematical Model for Idiopathic Intracranial Hypertension

    Arial Default Design Modeling Idiopathic Intracranial Hypertension with a semi-collapsible sinus Idiopathic Intracranial Hypertension (IIH) Slide 3 Prevalence Slide 5 Slide 6 Slide 7 Slide 8 Slide 9 Model Assumptions Model Assumptions Governing Equations: CSF/Brain Compartment Governing Equations: Cerebral Veins...