1

TopicsTopics

• The Unified Modeling Language

• UML Extension Mechanisms

• Advanced Modeling with OCL

• Hands-on: Writing the Constraint using OCL

• UML Modeling Techniques for Component System• Business Concept Model

• Use Case Model

• Business Type Model

• Interface Specification

• Component Specification

• Component Architecture

• Module Summary

• Hands-on: UML Game

2

What is UML?What is UML?

• Integrate diagrams of many methodologies:• Booch, OMT, OOSE, Fusion, Coad/Yourdon

• Added to the list of OMG adopted technologies in 1997 as UML 1.1

• The UML is a language of software development• Specifying

• Visualizing

• Constructing

• Documenting

the artifacts of software system.

• Object Modeling, Component Packaging

• be used to describe just the Component Specification

3

What Does UML Do? What Does UML Do? ++

• Use case diagram• Describes a system's functional requirements in terms of use cases.

• Class diagram• Shows a collection of declarative static model elements.

• Behavior diagram• Statechart Diagram

• Shows behavior that specifies the sequences of states that an object or an interaction goes through during its life in response to events, together with its responses and actions.

• Activity Diagram• Shows behavior with control structure.

• Interaction Diagram• Sequence Diagram

• Shows object interactions arranged in time sequence.• Collaboration Diagram

• Shows interactions organized around the structure of a model.

• Implementation diagram• Component Diagram

• Shows the organizations and dependencies among components.

• Deployment Diagram• Shows the configuration of run-time processing models and the components, processes, and

objects that live on them.

4

Why We Need to Extend UML?Why We Need to Extend UML?

• UML was originally designed for OOA/D and based on the assumption of an OO implementation.

• Our focus is on the external aspects of components and not internals, irrespective of whether they are coded using an OO language.

• Component emphasize the need for clear and precise interface definition.• Although our views on interface specification fit within UML, they cause us to

use it in new ways.

• We are interested in techniques rather then diagrams.• The same UML diagram can be used for a variety of purposes (to support

Component concepts).• Business modeling• Data modeling• Object modeling• Component modeling

• UML is designed to be extended.

5

UML Extension MechanismUML Extension Mechanism

• Extensibility Mechanisms• Allow Modelers to refine the semantics of UML for a specific domain.

• Extensions cannot violate the standard UML semantics• Enforces a consistent core of concepts and semantics for every variation.• Prevents meta-model explosion (Using UML to model everything and anything).

• Extensibility Method• Refinements are specified at the Model (M1) level but apply to the Meta-Model level

(M2).

Class Association

<<interface type>>

ICustomerMgt

<<interface type>> CustomerOrder

item

quantity

Customer

id

M2

M1

6

Basic Extension Mechanisms and Profiles Basic Extension Mechanisms and Profiles ++

• Stereotypes• used to define specialized model elements

based on a core UML model element.

• Constraint• used to represent semantic information

attached to a model element.

• Tagged Value• used to attach new properties into model

element.

• UML Profile• A package of related extensibility elements

that capture domain-specific variations and usage patterns.

• UML for CORBA, UML for RealTime, etc.

<<entity>>

Account

balance

getBalance( )

CorporationPerson

{or}

{author = “NKCho”}

{status = draft}

7

Extending UML with StereotypesExtending UML with Stereotypes

Component Specification Concept UML Construct Stereotype

Component Specification Class <<comp spec>>

Interface Type Type(Class <<type>>) <<interface type>>

Comp. Spec. offers Interface Type Dependency <<offer>>

Business Concept Class <<concept>>1

Business Type Type(Class <<type>>) <<type>>

Structured Data Type Type(Class <<type>>) <<data type>>

Interface Information Type Type(Class <<type>>) <<info type>>2

Parameterized Attribute Operation <<att>>

Operation requiring a new transaction Operation <<transaction>>

1. optional

2. often omitted

8

Precision, Accuracy, and CompletenessPrecision, Accuracy, and Completeness

• Q: “How much did you pay for these apples?”

• We need to model more precise, accurate, and complete.

A: “Big money” Imprecise

A: “Over $10” Precise, but not Accurate

A: “$11” Precise and Accurate, but not Complete

A: “$11 per one” Precise, Accurate, and also Complete

9

What is Object Constraint Language(OCLWhat is Object Constraint Language(OCL)? )? ++

• Constraint • is a restriction on one or more values of (part of) an object-oriented model or

system.

• UML defines three standard stereotypes for constraints:• Class invariant

• a constraint that must always be met by all instances of the class.

• Pre-condition of an operation • a constraint that must always be true BEFORE the execution of the operation.

• Post-condition of an operation • a constraint that must always be true AFTER the execution of the operation.

• OCL is• a textual language to describe constraints.

• the constraint language used in UML models.

• formal, but easy to use.

10

What Does OCL Do? What Does OCL Do?

• OCL invariants allow you to• Model more precisely.

• Remain implementation independent.

• OCL pre- and post-conditions allow you to• Specify contracts (design by contract).

• Specify interfaces of components more precisely.

11

Basic OCL Keywords and SyntaxBasic OCL Keywords and Syntax

• Basic keywords• context – introduce context for the expression.

• self – a reserved word that indicate constraint context. similar to “this” in C++.• inv – denote the <<invariant>> stereotype.• pre – denote the <<precondition>> stereotype.• post – denote the <<postcondition>> stereotype.• package & endpackage - specify explicitly in which package constraints

belong.• if, then, else, endif, not, let, or, and, xor, implies, def, in

• Syntax:package Package::SubPackage

context X inv:-- some invariant

context X::operationName(..)pre: -- some pre-conditionpost: -- some post-condition

endpackage

12

Example: Specifying an InvariantExample: Specifying an Invariant

• Constraint: • “In the context of the Company type, the number of employees must always exceed 50.”

• OCL expression:package UML_OCL

context Company inv:self.numberOfEmployees > 50

endpackage

manager

managedCompanies

employee employer

0..* 0..*

0..*

Person

isMarried: Boolean

isUnemployed: Boolena

birthDate: Date

age: Integer

firstName: String

lastName: String

sex: Sex

income(Date): Integer

Company

name:String

numberOfEmployee: Integer

stockPrice(): Real

Job

title: String

startDate: Date

salary: Integer

13

Elements of OCL ExpressionElements of OCL Expression

• Predefined OCL Types• Basic Types

• Boolean, Integer, Real, String

• Collection Types

• Classifiers from the UML model, their Features and Associations.

Example: Basic Type

context Person inv:

self.lastName = ‘CHO’

Example: Model Class and Attribute

context Person inv:

self.age > 0

Example: Query Operation

context Person::income(d: Date): Integer

pre: -- none

post: result = age * 1000

context Company inv:

self.stockPrice() > 0

Example: Association and Navigation

context Company

inv: self.manager.isUnemployed = false

inv: self.employee->notEmpty()

14

Collection TypeCollection Type

• Most navigations return collections rather than single elements.context Company inv:self.employee

• Collection type• Collection type is predefined in OCL to manipulate collections.• Collection is an abstract type, with the concrete types as its subtypes:

• Set – is the mathematical set. It does not contain duplicate elements.• Bag – is like a Set, which may contain duplicates.• Sequence – is like a Bag in which the elements are ordered.

Person

isMarried: Boolean

isUnemployed: Boolena

birthDate: Date

age: Integer

firstName: String

lastName: String

sex: Sex

income(Date): Integer

Company

name:String

numberOfEmployee: Integer

stockPrice(): Real

manager

managedCompanies

employee employer

0..*

0..*

0..*

employee

0..*

Job

title: String

startDate: Date

salary: Integer

15

Collection OperationsCollection Operations

• OCL predefines many operations on the collection types.

• Syntax:collection->operation(v : Type | boolean-expression-with-v)

• Collection operations• select – results in a Collection that contains all elements for which boolean-

expression is true.• forAll – results in a Boolean that is true if the boolean-expression is true for

all elements of collection.• exist – results in a Boolean that is ture if the boolean-expression is true for

at least one element of collection.• isEmpty – results in a Boolean that is true if collection has no elements.• notEmpty – results in a Boolean that is true if collection has at least one

element.• size – results in a Integer that is the number of elements in collection.

16

Example: Collection OperationsExample: Collection Operations

context Company inv:self.employee->select(p : Person | p.age < 20)->isEmpty()

context Company inv:self.employee->forAll(p : Person | p.age >= 20 and p.age < 60)

context Company inv:self.employee->exists( p : Person | p.lastName = 'CHO' )

:Person

age = 32

lastName = ‘CHO’

:Person

age = 29

lastName = ‘KIM’

:Person

age = 34

lastName = ‘LEE’

:Person

age = 34

lastName = ‘MIN’

:Company

name = ‘Mananim’

:Company

name = ‘SolutionLink’

legend:

— manage

— employee

17

More OCL ConceptsMore OCL Concepts

• Local variables• The let expression allows one to define an attribute or operation which can be

used in the constraint.

• Syntax:Let var : Type = <expression1> in <expression2>

• Result in post-condition• result indicates the return value from the operation. In this case, “result” is of

type Integer.

• Examplecontext Person::income (d: Date) : Integer

pre: -- nonepost:

Let income : Integer = self.job.salary->sum() inresult = self.income

18

Modeling Tips Modeling Tips

• Keep constraints simple.

• Always combine natural language with OCL.

• Use a tool to check your OCL. +

19

Hands-on: Writing the Constraint using OCLHands-on: Writing the Constraint using OCL

• Stack is a storage structure. All storage locations are initially empty. An item of data is added to top of the stack by a “push” instruction, which pushes any previously stored items further down in the stack. Only the topmost item on the stack is accessible at any moment, and it is fetched and removed from the stack by a “pop” instruction.

1. Consider the above constraints, write the pre/post-condition pairs for following operations.

IStackstack[]: Stack

size: Integer

MAX = 5

push(item: Data)push(item: Data)

pop(): Datapop(): Data

isEmpty(): BooleanisEmpty(): Boolean

isFull(): BooleanisFull(): Boolean

context IStack inv:

self.size >= 0

self.size < MAX

initial: self.size = 0

context IStack::push(item: Data)

pre: self.size < MAX

post: self.size = self.size@pre + 1

self.stack[size] = item

context IStack::pop(): Data

pre: self.size > 0

post: result = self.stack[size]

self.size = self.size@pre - 1

context IStack::isEmpty(): Boolean

pre: -- none

post: result = ( self.size = 0 )

context IStack::isFull(): Boolean

pre: -- none

post: result = ( self.size = MAX )??

20

Sample SolutionSample Solution

context IStack::push(item: Data)

pre: self.size < MAX

post: self.size = self.size@pre + 1

self.stack[size] = item

context IStack::pop(): Data

pre: self.size > 0

post: result = self.stack[size]

self.size = self.size@pre - 1

context IStack::isEmpty(): Boolean

pre: -- none

post: result = ( self.size = 0 )

context IStack::isFull(): Boolean

pre: -- none

post: result = ( self.size = MAX )

21

UML Modeling TechniquesUML Modeling Techniques

• Term• In UML, Model is an abstraction of physical system with a certain purpose.• In this Course, Model is a self-contained set of model element.

• General Techniques• Use case Diagram

• to capture the business concepts in the domain being studied.• to understand the interaction between the users and the system.

• Class Diagram• to capture the structural or static aspects of the specification model.

• Interaction Diagram• to capture the behavioral or dynamic aspects of the specification model.

• Package Diagram• to group the related model elements.

• Activity Diagram (for special purpose)• to describe business processes.• to describe the algorithms of operations.

• Not use• component and deployment diagram• statechart diagram

22

Diagrams for Component ModelingDiagrams for Component Modeling

Requirements

Business Concept Model

Use Case Model

Specification

Business Type Model

Interface Specifications

Component Specifications

Component Architecture

Interactions

InterfaceResponsibility

Model

InterfaceSpecification

Model

BusinessType Model

ComponentArchitecture

Model

ComponentInteraction

Model

ComponentSpecification

Model

Use CaseModel

BusinessConcept Model

ClassDiagram

CollaborationDiagram

Use CaseDiagram

PackageDiagram

ClassDiagram

23

Business Concept ModelBusiness Concept Model

• Term• Business concept is not software, but the information that exists in the

problem domain.

• Purpose• Capture business concepts and identify its relationships.

• Representation• Class diagram with <<concept>> stereotype.

• Modeling techniques• Capture conceptual classes and their associations.

• Association roles may or may not have their multiplicities specified.

• May contain attributes, if they are significant.

• Operation would not be used.

• Normalization, generalization and dependency relationship would typically not used.

• Emphasize capturing domain knowledge.

24

Example: Business Concept DiagramExample: Business Concept Diagram

Account

number

Customer

Order

Outlet

Product

Price

1

25

Use Case ModelUse Case Model

• Terms• Use case is a projection of the requirements of a system, expressed in terms

of the interactions that must occur across the system boundary.• Actor is a coherent set of roles that interacts with system.

• Purpose• Describe the desired user-system interactions that occur at the system

boundary.

• Representation• Use case diagram.

• Modeling Techniques• One actor is always identified as the actor who initiates the use case.• Use case shouldn’t be concerned with the communication mechanism, only

with the business meaning of the stimuli and responses.• Use case is smaller than a business process, but larger than a single

operation on a single component.• Use case is to meet the immediate goal of actor.

26

Example: Use Case DiagramExample: Use Case Diagram

Reservation system

ReservationMaker

Guest

BillingSystem

ReservationAdministrator

Cancel a reservation

Make a reservation

Update a reservation

Take up a reservation

Process no shows

Add, amend, remove

hotel, room, customer, ...

27

Use Case DescriptionsUse Case Descriptions

• UML does not specify the way in which use case content is described.

• Content of Use Case Description (from Alistair Cockburn) +• An identifying name and/or number

• The name of the initiating actor

• A short description of the goal of the use case

• A single numbered sequence of steps that describe the main success scenario

• Specifying Techniques• Each step takes the form “A does X”.

• The first step must indicate the stimulus that initiates the use case.

• The main success scenario describes what happens in the most common case and nothing goes wrong.

• Each step acts as a UML use case extension point.

• Use case steps are always written in natural language.

28

Example: Textual Description of a Use CaseExample: Textual Description of a Use Case

Name: Make a Reservation

Initiator: Reservation Maker

Goal: Reserve a room at a hotel

Main success scenario:

1. Reservation Maker asks to make a reservation.

2. Reservation Maker selects hotel, dates and room type.

3. System provides availability and price.

4. Reservation Maker agrees to proceed.

5. Reservation Maker provides name and post/zipcode.

6. Reservation Maker provides contact email address.

7. System makes reservation and gives it a tag.

8. System reveals tag to Reservation Maker.

9. System creates and sends confirmation by email.

Extensions:

3. Room Not Availablea. System offers alternative dates and room types.b. Reservation Maker selects from alternatives.

6. Customer already on filea. Resume 7.

Stepsor

ExtensionPoints

ReservationMaker

Make a reservation

Room Not Available

<<extend>>

29

Inclusions, Extensions, and VariationsInclusions, Extensions, and Variations

• Inclusion• Indicates one use case include another use case.

• Extension• A mechanism for semiformal specification of alternatives or additions to the

main success scenario.

• Content of extension• the step number in the main success scenario at which the extension applies.• a condition that must be tested before that step.• a numbered sequence of steps that contributes the extension.

• Last step in an extension can take one of the following forms:• Fail –use case is terminated with the goal unsatisfied.• Stop –use case is terminated with the goal satisfied.• Resume N –next step to be performed in the main success scenario.

• Variation• Indicates variations of the flow of a use case that we don’t want to specify

them as extensions.

30

Business Type ModelBusiness Type Model

• Term• Business Type represent the system’s understanding of the business concept,

which is typically scoped down and more precisely defined.

• Purpose• Represent precisely the business information that is relevant to the scope of

the envisaged system.

• Representation• Class diagram with built-in stereotype <<type>>.

• Modeling techniques• Complete association with multiplicity, optionality, and association roles.

• Recording attributes that you know about.

• scope back to data that the business needs to keep track of within the scope of this project.

• Remove redundancy.

• Use generalization concept.

31

Example: Business Type DiagramExample: Business Type Diagram

<<type>>Account

number: StringstartDate: Date

<<type>>Customer

name: Stringaddress: Address

<<type>>Order

number: Integer

<<type>>OrderLine

number: Integer

<<type>>Product

price: Currencycode: Stringdescription: String

<<data type>>Address

billing: Stringdelivery: String

1

*

1

*

1

1..* 1

*

32

Other Concepts in the Business Type ModelOther Concepts in the Business Type Model

• (Business) Types• Intended to represent precisely the information about the business with which

the system will need to be concerned.

• But it is not database design.

• Can’t have operations because they describe only information, not software.

• Give <<type>> stereotype.

• Structured Data Types• A descriptor of a set of values that lack identity.

• May not have associations, or operations.

• Give <<data type>> stereotype.

• Interface Type• An interface at the specification level.

• UML interface is a realization of an interface type.

• Give <<interface type>> stereotype.

33

Adding Invariants into Business Type ModelAdding Invariants into Business Type Model

• A constraint that applies to all instances of a type.

• Write invariants using the OCL.

• Correspond to business rules.

• Example:

<<interface type>>

IOrderMgt

orderNo: Integer

addItem(p: IProductMgt, quantity: Integer)

orderNo(): Integer

context IOrderMgt inv:

self.orderNo > 0

context IOrderMgt::orderNo(): Integer

pre: -- none

post: result = self.orderNo

34

Interface SpecificationInterface Specification

• Term• An interface together with all the other specification paraphernalia needed to

define precisely what a component that offers that interface must do, and what a client of that interface can expect.

• Content of Interface Specification• The interface type itself.

• Its Information Model.

• Its Operation Specifications.

• Any additional Invariants on the information model.

• Interface Specification Package• Group all specification information into a single package.

• each interface specification has its own package.

• A package may import specification information from other packages.

35

Example: Interface Specification DiagramExample: Interface Specification Diagram

<<interface type>>

ICustomerMgr

addCustomer(c: CustDetails)

deleteCustomer(name: String)

<<info type>>

Customer

name: String

address: Address

<<data type>>

CustDetails

name: String

address[0..1]: Address

*

ICustomerMgt

<<data type>>

Address

billing: String

delivery: String

Shared Data Types

<<import>>

36

Information Model and Operation SpecificationInformation Model and Operation Specification

• Information Model• Whereas in business type model we had a single integrated type model, interface

information model define a number of type models, one for each interface.• Consists of an interface and an exclusive set of information type.• Represented by interface specification diagram with <<info type>> stereotype.

• Operation Specification• Operation name• Intent of the operation in free text• Signature, which define its parameters• Pre/postcondition pair

• <<precondition>>: Boolean expression that is evaluated before the operation executes.• <<postcondition>>: Boolean expression that is evaluated after the operation finishes.

• Transaction behavior• operation starts its own transaction.

• <<transaction>>• or runs in an existing transaction.

37

Component SpecificationComponent Specification

• Term• A component specification describe the behavior of a component. It may be

given to an implementer to tell them what to implement, or may be given to a customer, to tell them what has been implemented.

• Purpose• Represent the functional specification of the component plus certain aspects

of the component’s delivery information.

• Representation• Class diagram with <<comp spec>> stereotype, <<offers>> relationship, and

<<usage>> dependency.

• Modeling techniques• Component specification defines the set of interfaces it must use as well as

the set of interfaces it offers.• Focuses on a single component specification and details its individual

dependencies.• Also defines any constraints that it requires between interfaces, and any

constraints on the implementation of its operations.

38

Example: Component Specification DiagramExample: Component Specification Diagram

<<comp spec>>

CustomerMgr

<<interface type>>

ICustomerMgt

<<interface type>>

IAddressMgt

<<offers>>

<<usage>>

CustomerMgr

<<realize>>

<<interface>>

ICustomerMgt

<<realize>>

39

Component Object InteractionComponent Object Interaction

• Term• Interaction is a specification of how stimuli are sent between instances to

perform a specific task.

• Purpose• Show how component object uses the interfaces of other component objects.

• Representation• Collaboration diagram (or Sequence diagram.)

• Modeling techniques• Follow the object naming rule, ObjectName/RoleName:ClassifierName

• Only component object can send messages.

• Only show direct interactions between objects of the type being specified and objects supporting the interfaces it uses.

• Every interaction diagram should show the stimulus that causes the interaction.

40

Example: Component Interaction DiagramsExample: Component Interaction Diagrams

/ICustomerMgt:CustomerMgr

/IAddressMgt

1: getAddress(cid, ad)

1.1: getAddress(aid, ad)/Client:Client

/Client:Client

/ICustomerMgt:CustomerMgr /IAddressMgt

1: getAddress(cid, ad)1.1: getAddress(aid, ad)

41

Component ArchitectureComponent Architecture

• Term• A set of application-level software components, their structural relationships,

and their behavioral dependencies.

• Purpose• Show the organizations and dependencies among components.

• Representation• Class diagram with <<comp spec>> stereotype.

• Modeling techniques• Integrate individual components into a single component architecture.

• Can draw component architecture diagrams without the interfaces to give a coarser-grain view.

42

Example: Component Architecture DiagramExample: Component Architecture Diagram

<<comp spec>>

CustomerMgr

<<comp spec>>

AddressMgrIAddressMgt

ICustomerMgt

<<comp spec>>

CustomerMgr

<<comp spec>>

AddressMgr

43

Module SummaryModule Summary

• We can use UML to represent the component specifications and model artifacts.

• We need to extend the UML.

• We can make our model more precisely by using OCL.

• UML Modeling Techniques

Component Models UML Diagrams

Package structures Package diagram

Business process model Activity diagram

Business concept model Class diagram with <<concept>>

Use case model Use case diagram

Business type model Class diagram with <<type>>

Interface specifications Class diagram with <<interface type>>

Component specifications Class diagram with <<comp spec>>

Component object interactions Collaboration or sequence diagram

Component architecture Class diagram with <<comp spec>>

44

Hands-on: UML Game – Use caseHands-on: UML Game – Use case

• Microwave Sharp 1000

1. Think about the functionalities of Microwave Sharp 1000.

2. Identify actors and use cases of the Microwave Sharp 1000:a. Define the actor.

b. Think about the functionalities you need to support those two high level functionalities.

c. Define the use cases and the kind of relationships.

d. Model them in use case diagram.

start

door

timer

45

Sample Solution – Use caseSample Solution – Use case

Cook

Open door

Close door

Set timer

Start cooking

Stop cooking

Timer off

Heating

Microwave Sharp 1000

<<extend>>

<<include>>

<<include>>

46

Hands-on: UML Game – Object and ClassHands-on: UML Game – Object and Class

• Conference Management System• To create a conference you may need a conference subject and a

conference start and end date.• A conference consists of several conference events.• A conference event must have a speaker.• A conference event may not start before the conference has started.• You may ask a conference how many persons may attend.• A person registers to a conference by using a specific registration

types(attendee, employee, guest, VIP, ...)

1. Identify objects and classes:a. Find possible classes based on the description above.b. Find and define attributes for those classes.c. Identify relationships between those classes.d. Think about the behavior of those objects.e. Define methods for the classes you found.f. Model them in class diagram.

47

Sample Solution – Object and ClassSample Solution – Object and Class

Conference

subject

startDate

endDate

cost

start()

close()

entryDate

paymentDate

registrationType

Registration

Event

title

startDate

duration

room

seat

areSeatAvailable()

Participant

name

companyName

address

Attendee

Speaker

* *

*

*

*

presenter

PaymentInformation

1

method

1

registrationType = {attendee,

employee,guest, VIP}

Event.startDate >= Conference.startDate