uml diagrams ( unified modeling language)

C.Thomas Wu.Introduction to O-O Programming

UML Diagrams (Unified Modeling Language)


UML Diagram IntroductionGraphical notations are useful and straight-

forward in displaying information about a system design.

Three gurus Booch, Rumbaugh, and Jacobson developed the UML diagrams


UML• Models various aspects of software

development for OO systems• Includes several types of diagrams

– Class– Use Case– Collaboration– Sequence– State– Activity


Class Diagrams (are static)• Are one of the most significant diagram of the

UML diagrams used by software developers

• Are used to create logical models of the computer-based systems

• Show data members, methods, and the static relationships between the classes that are used to build the system. The relationships are also called associations


Basic UML Class and Object Diagram

Person Explanations:Class Name

-firstName-lastName-age

Private Data Members (named property of a class usually a noun)(- symbol)

+Person()+Person( firstName, lastName, age) +getFirstName():String+setFirstName(firstName:String): void +getLastName():String+setLastName(lastName:String): void +getAge(): int+setAge(age:int): void#anyMethod():void +getNumberofObjects():int

Constructors default andnon-defaultPublic Methods (+symbol)(usually a verb)

Protected Methods (# symbol)Static Methods (+ symbol and underlined)


Class Diagrams - Data Types and Parameters • Sometimes the data type of attributes and

parameters, and return types are not shown on the class diagram.

• If you see just the aMethodName(), don’t assume that there is no parameters for the method. Sometimes they are omitted to save space.

Class Diagram for Premiere Products Database - Source: Adamski and Pratt

Class Diagram with ConstraintsSource: Pratt and Adamski

Class Diagram with a 1. Generalization (super class) and a 2. Specialization (subclass) with a

Constraint Source: Pratt and Adamski


Building a Specification Model• The OO way of modeling reality does not

try to organize all of reality• We usually try to model only the relevant

features of a specific application domain select a manageable domain • One way of bounding the domain is to

use Use Cases• The main purpose of use case modeling

is to understand the external behavior of the system. The later stages will be easier if up-front requirements are clear and unambiguous


One of the values of use cases is that they ease the discussions between stakeholders and analysts/developers.

They are usually written using business terms known to the majority of the stakeholders


Use Cases

• Uses cases capture the functional requirements and the business-value propositions of a proposed system -along with its high-level processes needed to achieve these specific value propositions

• A used case is a generic description of an entire transaction involving several objects (Lee and Tepfenhart)


Building a Specification Model• A use case:

– Specifies a sequence of actions, including variants, that a system performs and that yields an observable result of value to an actor (Jacobson, Booch, Rumbaugh)

– Is a description of all the possible sequences of interactions among the system and one or more actors in response to some initial stimulus by one of the actors (Rumbaugh)

– Is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal (Cockburn)


Use Cases• Uses cases are concerned with the actors and

the sequences of interactions between them• Some important concepts include:

– The goal - the business value to the user(s)– The system - the application with all the

hardware that will be used by the “users”– An actor – external entity that interacts with

the system -represented by a labeled stick figures

– Use case – describes an interaction that achieves a goal for an actor

– Use-case bundle – a collection of used cases that are highly correlated with some activity or organizing business element


Use Cases

Programmers use Use Cases to develop test plans

• The Goal– use cases describe in a formal way how a computer

system works from an external view– to capture a scenario that completes to some point

the business value of the user’s view– To model the system functional requirements

• The System– Usually viewed as a “black-box” system -the user

cannot see the system inner workings. The user verifies that the system behaves the way it is suppose to no matter how it is built.


Use Cases –Information Captured• The Actors

– Uses cases divide the world into two parts: the system and the users (actors)

– Actors are a way of classifying system users who share a set of common interactions to achieve a goal

– An actor represents an external entity that can initiate actions or receive requests from the system

– A specific user is an instance of an actor– The set of requests/responses from/to the actors

represents the system boundaries


Use Cases

• Use Case and Scenario– A use case describes a system in terms of

sequences of interactions between various actors and the system

– A scenario is a short narrative that outlines a sequence of requests and responses between a user and the system –what happens next

– A scenario describes how a user will use the system to achieve a goal

– A use case is the generalized form of a family of scenarios

– A scenario is a specific instance of a use case


Use Cases• The Use Case describes

– The pre-conditions that must exist for the used case to be successfully invoked

– The post-conditions that define the state of the system after the use case is concluded

– Detailed business logic that is performed (non-technology-dependent)

– Business exceptions that can occur required data not location, computations

aborted– Business constraints that apply to the system

when reacting to a specific user request –resource allocation not available

Richard C. Lee and William M. Tepfenhart

Use Cases• To effectively capture the functional aspects of

a system the description of the system must be kept at a consistent level of abstraction

• To successfully develop use cases we must know the dimension of the functional description we are trying to capture

• These dimensions include:– High-level and low-level– Primary and secondary– Essential and concrete


Use Cases• High-level functional descriptions

– Provide general and brief descriptions of the essence of the business values provided by the system- No concern of how to achieve the business values

• Low-level functional descriptions– Provide details showing the exact order of

activities, tasks, or alternatives


Use Cases• Primary functions

– Describe the essential functionality provided to the user – the reason the system exists

• Secondary functions– Deal with rare and exceptional cases –necessary to

deliver a robust system• Essential functions

– Describe business solutions that are independent of implementation (Hardware and software -black-box implementation is done in total ignorance of how the object was constructed)

• Concrete functions– Describe use cases that are design dependent

(clear-box)


Drop Course

Register

Add Course

Delete Course

Cancel Course

Course Registration System

Student

Admin Prof

High-level, primary, essential use case diagram


Description: A one or two sentence description of the use case – a descriptive name

Actors Identifies the actors participating in the use case

Includes Identifies the use cases included in it

Extends Identifies the use cases that it may extend

Pre-Conditions Identifies the conditions that must be met to invoke this use case

Template for Documenting Use Cases – Textual Description


Details Identifies the details of the use case

Post-Conditions Identifies the conditions that are assured to hold at the conclusion of the use case

Exceptions Identifies any exceptions that might arise in the execution of this use case

Constraints Identifies any constraints that might apply

Variants Identifies any variations that might hold for the use case

Comments Provides any additional info thatMight be important in this use case

Template for Documenting Use Cases – Textual Description


The Vending Machine Class Diagram

Merchant

moneyproduct

removeMoney()addProduct()

Coin Box

money

requestProduct()rejectCoin()

Customer

money

insertCoint()receiveProduct()

Dispenser

product

dispenseProduct()reject Request()

Coin

Product

AppleJuice

1 owns 1

1 buys *

1 1

Bad Coin

* *

11

1

supplier

1 0..*


The Vending Machine System Use Case Diagram

Addproduct

Merchant

Customer

RejectedCoin

Remove Coins

Requestproduct

Receiveproduct

<<extends>> A link that displays exactly how an optional actor interact with an exception


Sequence Diagrams

• Model system behavior (methods) for use cases by showing the necessary class interactions. Shows the time ordering of a sequence of method calls.

• They show how the user (actor) communicates with the system to complete the job.

• The events modeled in the diagram are external events started by an actor.

• The actors and objects are placed horizontally across the top of the diagram.

• The vertical lines called a lifeline is attached to each actor or object. The lifeline becomes an activation box to depict the live activation period of the object or actor.

• A message is represented using an arrow labeled with a message. The message may hold an argument list and a return type.

• Dashed arrows may be used to indicate object flow. If an object’s ends during the execution of the use case an X is placed at the bottom of its lifeline.


The Vending Machine System Sequence Diagram

Customer

Coin Box Dispenser

insertCoin()

requestProduct()

rejectCoin()rejectRequest()

Product


See the skeleton code to use for the Vending Machine System sequence diagram:

Vending Machine Sequence UML Diagram Skeleton Code.doc

Stored on the M: drive …in the UML folder.


Customer

Collaboration Diagrams

Show the message passing structure of the system. The emphasis is on the roles of the objects as they work together to complete a system function. They can be used to display parts of a design pattern and they are helpful for verifying class diagrams

:Coin Box :Dispenser

1. SendCoin

4. returnCoin

2. requestProduct

3. rejectRequest

Return coin collaboration diagram


Customer

Collaboration Diagrams

Product delivery collaboration diagram

:Coin Box

:Dispenser

1. SendCoin

3. deliverProduct

2. e

2. requestProduct


State DiagramDescribes the behavior (method) of a system, subsystem, or an individual object. The system state is determined by the values assigned to object’s data members. A system’s current state is only changed by a new event..

State diagrams display changes that affect the system behavior or its object data members when an external factor triggers an event..

Wait for Coin

Check Coin

Check Dispenser

Dispense Product

insert coin

Return Coinbad coin

good coin

no product

product available


Activity Diagram

Display the work flow of an object. They are similar to state diagrams

See Activity Diagram.doc

uml diagrams ( unified modeling language)

Documents

oo programmingbuilding

oo programmingone

oo programminguse cases

thomas wu

oo programmingbasic

pratt class diagram

adamskiclass diagram

significant diagram