uml course unit ii
DESCRIPTION
This presentation contains slides for the entire II unit of the course OOAD for jntu studentsTRANSCRIPT
![Page 1: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/1.jpg)
![Page 2: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/2.jpg)
Basic
structural
modeling
Presented byN.Prathyush
aV. Tejaswi
P. Usha
![Page 3: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/3.jpg)
classes
![Page 4: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/4.jpg)
Classescontents:- Definition of the class Names Attributes Operations Responsibilities
Definition:- A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class is implemented one or more interfaces.
Graphically, a class is rendered as a rectangle.
attributes
name
operations
![Page 5: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/5.jpg)
Names:- Every class must have a name that distinguishes it from other classes. A name is a textual string with a simple path or path name which consists of the details of the packages of class.
simple names path names
Attributes:- An attribute is a named property of a class that describes a range of values that instances hold. An attribute represents some property of the thing you are modeling that is shared by all objects of that class. Graphically, attributes are listed in a compartment just below the class name.
Customer Java::awt::Rectangle
Height: floatWidth: floatThickness: floatIsLoadBearing : Boolean = false
wall
![Page 6: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/6.jpg)
Operations:- An operation is the implementation of a service that can be requested from any object of a particular class. A may have any number of operations based on the responsibilities mentioned the class. Graphically, the operations are listed in a compartment just below the attributes.
Operation by stating its signature, covering the name, type, and default value of all parameters and a return type.
add()grow()move()Is Empty()
Rectangle
Reset()setAlarm(t : Temperature)Value() : Temperature
TemperatureSensor
![Page 7: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/7.jpg)
Responsibilities:- A responsibility is a contract or an obligation of a class. When we create a class, we make a statement that all the objects of that class should have the same kind of state and the same kind of behavior. Graphically, responsibilities can be drawn in a separate compartment at the bottom of the class.
FraudAgent
Responsibilities--Determine the risk of a customer order--handle customer-specific criteria for fraud
![Page 8: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/8.jpg)
Common Modeling Techniques:- A class is a structural thing which provides the abstraction of various properties and operations shared by different objects, by using classes we can model the following.
Modeling to vocabulary of the systemModeling the responsibilities of the systemModeling non-software thingsModeling primitive types
Modeling to vocabulary of the system:- Identify the things (nouns) that users or implements use to describe the problem or solution. For each thing identify a set of responsibilities that the class should implement. Provide the necessary attributes and operations that are needed to carryout the above responsibilities. Transaction
actions
Commit()rollback()wasSuccessful()
![Page 9: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/9.jpg)
Modeling the responsibilities of the system:- Identify a set of classes that work together to carry out some behavior. Identify a set of responsibilities for each of this classes. Look at the set of classes as a whole, split the classes with more number of responsibilities. If the number of responsibilities are less rejoin the classes into generated the classes and reallocate the responsibilities.
Model
Responsibilities--manage the state of the model
![Page 10: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/10.jpg)
Modeling non-software things:- Model the non-software thing as a class If we want to distinguish the modeled class from the existing UML classes use a stereo type. If the non-software thing which we want to model is in hardware, try to model a using a “ node “.
Modeling Primitive Types:- Model the thing you are abstracting as a type or an enumeration, which is rendered using class notation with the appropriate stereotype. If you need to specify the range of values associated with this type, use constraints.
Accounts Receivable Agent
<<enumeration>>Boolean
Falsetrue
![Page 11: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/11.jpg)
Relationship
s
![Page 12: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/12.jpg)
Definition:- A relationship is a connection among things. In UML a relationship is rendered as a path, with different kinds of lines use to distinguish the kinds of relationships. In object-oriented modeling, the three most important relationships.
Contents:- Dependency Generalization Association
Dependency:- A dependency is a “ using “ relationship that states that a change in specification of one thing may effect another thing that uses it. Graphically, a dependency is rendered to the thing being depended on.
------------------->
--------
FilmClip
name
playOn(c : Channel)Start()Stop()Reset()
Channel
dependency
![Page 13: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/13.jpg)
Generalization:- A Generalization is a relationship between a general thing(super class) and a more specific kind of that thing(sub class). Generalization is sometimes also known as IS-A-KIND of relationship. Graphically, generalization is rendered as a solid directed line with a large open arrow head, pointing to the parent.
Shapeorigin
Move()Resize()Display()
Rectangle
Corner: point
Circle
Radius : float
Polygon
Points: List
display
Square Leaf class
generalization
base class
![Page 14: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/14.jpg)
Association:- An association is a structural relationship that specifies that the objects of one thing are connected to objects of another. An association will be generally between two classes. Graphically, an association is rendered as a solid line connection the same class or different classes. An association will generally in have the following four adornments Name Role Names Multiplicity Aggregation
Name:- This is the name given for the relationship between two or more classes.
Person CompanyWorks for
nameName direction
association
![Page 15: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/15.jpg)
Role Names:- These are the names given for the participating classes in a relationships. A person playing the role of employee is associated with a company playing the role of employer.
Multiplicity:- Multiplicity represent how many objects are involved across an instance of association from the different classes. The stating of “ how many “ is known as Multiplicity.
Person Companyemployee employer
association
Person Company1...
association
![Page 16: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/16.jpg)
Aggregation:- If we want to model a” whole/part “ relationship in which one class to represents a larger thing consisting of these smaller things, this kind of relationship is often known as aggregation and implements strictly the relationship “ Has-A “. An aggregation is a special kind of association rendered with an open or hallow diamond at the end of “ whole “ class.
Company
Department
aggregationwhole
part
![Page 17: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/17.jpg)
Common Modeling Techniques:- using UML’s relationships we can model the following. Modeling Simple Dependency Modeling Single Inheritance Modeling Structural relationships
Modeling Simple Dependency:- The most common kind of dependency relationship is the connection between a class that only uses another class as a parameter to an operation. To model the “ using “ relationship. Create a dependency pointing from the class with the operation to the class use as a parameter in the operation.
---------------->
CourseSchedule
Add(c : Course)Remove(c : Course)
Iterator
Course
<<friend>>
![Page 18: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/18.jpg)
Modeling Simple Inheritance:- To model inheritance between a set of classes, Identify the responsibilities, attributes and operations that are common to two or more classes. Create a class with the above mentioned common responsibilities, attributes and operations. Lastly show the relationships from the specialized classes to generalized class.
Security
presentValue()History()
CashAccount
interestRate
presentValue()
Stock
presentValue()
Bond
presentValue()
Property
assessments
presentValue()
SmallCapStock LargeCapStock
![Page 19: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/19.jpg)
Common Structural Relationships:- A relationships are classified into two types, they are one-side, two-sideddependency and generalization/specification. For a given set of two classes identify whether objects of one class can navigate to the other class and vice-versa. Identify a set of two classes with the relationship dependency and find out whether there exist a two-sided relationship other than dependency. For each of the associations specify the adornments such as role names, multiplicity, aggregation etc.
School Department
Student Course Instructor
1 1..1..
member
1..
attends teaches
1..
1..
0…1
0..1chairperson
1..
1..
Assigned To
has
![Page 20: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/20.jpg)
Common
mechanisms
![Page 21: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/21.jpg)
Uml is made similar by the presence of four common mechanisms
that apply consistently throughout the language. After constructing or developing
the architecture and different views of a software intensive system, the developer
should go for common mechanisms. We have four types of common mechanisms.
They are….
Specifications
Adornments
Common divisions
Extensibility
Common mechanisms
![Page 22: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/22.jpg)
Adornments
Adornments are generally added to an element’s basic notation and are
used to visualize details from the element’s specification .They are used to decorate
a particular thing to specify some artifacts.
Adornments are classified into two types. They are…..
1. Textual adornments
2. Graphical or symbolic adornments.
Textual adornments
most adornments are rendered by placing text near the element. Textual
adornments are the strings which delineate the artifacts of a particular thing or
relationship or a diagram. Some of the common textual adornments are name, role
names, multiplicity, isaggregation or not.
![Page 23: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/23.jpg)
Graphical adornments
most adornments are rendered by adding a graphic symbol to the basic
elements. These are the adornments used to specify the artifacts such as relationships,
access specifiers etc. some of the symbolic adornments are..
public
private
# protected
note
![Page 24: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/24.jpg)
A note is a special kind of adornment, which is a graphical symbol for
rendering comments or constraints attached to an element or collection of
elements. These are used to specify things like requirements, observations, reviews
and explanations, in addition to rendering constraints.
A note is rendered in uml using a rectangle with a dog-eared corner. In uml a
note can be rendered in three ways. They are…..
A note may contain some plain text
put an url inside a note
Simple text
An embedded url
![Page 25: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/25.jpg)
We may link to or embed another document
Extensibility mechanisms
uml has the capability of extending its vocabulary, properties, and
semantics using one of the mechanisms known as extensibility mechanisms. This
mechanisms permit us to extend the language in controlled ways.
these mechanisms include…
1. stereo types
2. tagged values
3. constraints
Link to document
![Page 26: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/26.jpg)
constraints
Tagged values
Stereo
types
![Page 27: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/27.jpg)
Stereo types
a stereo type extends the vocabulary of the uml, allowing you to
create new kinds of building blocks that are derived from existing ones but with its
own properties, semantics and notation.
in simplest form a stereo type is rendered as a name enclosed by
guillements
define an icon for the stereotype and render that icon to the right of
the name
<<metaclass>ModelElement Named stereotype
<<exception>>underflow ! Named stereo type
with icon
![Page 28: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/28.jpg)
Render an icon as a basic symbol for the stereo typed item
Tagged values A tagged value extends the properties of a uml building block, allowing to create new information in that element’s specific function. A tagged value is rendered as a string enclosed by brackets and placed below the name of another element. That string includes a name(tag), a separator(=) and a value( of the tag).
Stereotyped element as icon
Server{processors=3}
![Page 29: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/29.jpg)
Constraints A constraint is a condition which is used to add or modify the existing rules or semantics for a well-formed model we need to have certain constraints established. a constraint is generally rendered as a simple statement or a mathematical equation in a pair of curly braces, and is placed by side of the thing to which it belongs. simple constraint portfolio
Bank Account
corporation
Gender :{f,m}
person
{secure}
{or}
Constraint across multiple constraints
{self.wife.gender=female andSelf.husband.gender=male}
Formal constraint Using ocl
![Page 30: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/30.jpg)
Comm
on
modeli
ng
techni
ques
![Page 31: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/31.jpg)
based on the common mechanisms we can model the following
modeling comments modeling new building blocks modeling new properties modeling new semantics
Modeling comments
write the comment in the symbol provided and place the note by side of the element to which it refers.
the note can be elided or it can be made visible if the note is lengthy, then write down the complete description in a document
and place a link in the note referring the document as the model evolves keep those comments that are significant , otherwise
remove
![Page 32: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/32.jpg)
Modeling new building blocks Make sure that the thing which we want to model doesn’t have a graphical
representation in uml
After conforming the above select any one of the eleven things and stereotype
it. Stereo typing can be done in two ways
1. Selecting a stereo type which already exists.
2. Creating our own stereo type.
Specify new properties and semantics for the new thing.
If necessary place a icon for the above stereo type
![Page 33: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/33.jpg)
Modeling new properties make sure that there is no way to express a value using the attributes of a class
in the above situation create a new tag and assign it a value which we want to
model
<<subsystem>>FieldAccess{version=2.5
Status=checkdin}
<<subsystem>>Billing
{version=3.2Status=checkout
By=edg}
<<subsystem>>AccountsPayable
{version=3.2.1Status=checkedin}
<<subsystem>>WorldCurrency
{version=7.5Status=checedin}
----------------
--------
![Page 34: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/34.jpg)
Modeling new semantics make sure there is no way to model the rules of constraints. write down the constraints and new semantics for the element which we want to model and place adjacent to it if we want to express the constraints in a more precise way use ocl as apart of mentioning the constraints
member 1..* 1 manager
department
person
{subset} <-----------
![Page 35: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/35.jpg)
diagram
s
![Page 36: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/36.jpg)
A diagram is one of the basic building blocks of uml which group together elements with internal relationships. According to version 2.0 there are a set of thirteen diagrams which are used to model a software intensive system in different views. The diagrams are classified into two types, they are…. 1. Static diagrams
2. Dynamic diagrams
The static diagrams model the static behavior of system where as the dynamic
diagrams model the dynamic aspects of a system.
The static parts of a system uses one of the following diagrams
1. Class diagrams
2. Object diagram
3. Component diagram
4. Deployment diagram
![Page 37: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/37.jpg)
The following diagrams are used to view the dynamic parts of a system
1. use case diagram 2. sequence diagram 3. collaboration diagram 4. state chart diagram 5. activity diagram
![Page 38: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/38.jpg)
Class diagram
Object diagram
Usecase diagram
Sequence diagram
Collaboration diagram
State chart diagram
A structural diagram that shows a set of classes, interfaces, collaborations and their relationships
A structural diagram that shows a set of objects and relationships
A behavioral diagram that shows a set of use cases and actors and their relationships
A behavioral diagram that shows an interaction , emphasizing the time ordering of messages
A behavioral diagram that shows an interaction, emphazing the structural organizations of the objects that send an d receive messages
A behavioral diagram that shows a state machine, emphazing the event-ordered behavior of an object
![Page 39: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/39.jpg)
A behavioral diagram that shows a state machine, emphazing the flow from activity to activity
Activity diagram
Component diagram
Deployment diagram
A structural diagram that shows a set of components and their relationships
A structural diagram that shows a set of nodes and their relationships
![Page 40: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/40.jpg)
Common
modeling
techniques
![Page 41: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/41.jpg)
Using the diagrams of uml the following be modeled.
1. modeling different views of a system
2. modeling different levels of abstraction.
3. modeling complex views
Modeling different views make sure which view best expresses the architecture of our system
after selecting the view decide the various sets of artifacts which must be
captured with that view.
decide the types of diagrams which best support the artifacts which we have
captured.
the view which we have selected should allow a transitonary diagram for
exploring certain decisions and changes in the project.
![Page 42: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/42.jpg)
Any system which is going to be developed , may be of two types…..
1. monolithic projects
2. enterprise projects
For a monolithic application that runs on single machine, you might need only the
following diagrams..
use case view use case diagrams
design view class diagrams ( for structural modeling)
interaction diagrams ( for behavioral modeling)
process view none required
implementation view none required
deployment none required
![Page 43: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/43.jpg)
if it is a client/server system, we have to include component diagrams
and deployment diagrams to model the physical details of your system.
if we are modeling a complex, distributed system, we need to full range of
the uml’s diagrams in order to express the architecture of your system and technical
risks to your project , as in following…
use case view use case diagrams
activity diagrams( for behavioral modeling)
design view class diagrams ( for structural modeling)
Interaction diagrams ( for behavioral diagram)
State chart diagrams( for behavioral modeling)
process view class diagrams ( for structural modeling)
interaction diagrams (for behavioral modeling)
implementation view component diagram
Deployment view deployment diagram
![Page 44: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/44.jpg)
Modeling abstraction
an abstraction is one of the object-oriented principles which gives the specification by concealing the implementation. any system which is under implementation can have two levels of abstraction.
1. high level abstraction 2. low-level abstraction to model a system with different levels of abstraction by using the diagrams consider the following details.
the reader should understand the system and he has to select a model
if the reader is going to implement or construct the implementation of a system then he must be provided with a low-level abstraction i.e. the complete set of artifacts, relations and specifications.
irrespective of the abstractions selected the reader should present or conceal
various things of the model, they are..
![Page 45: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/45.jpg)
1 . Building blocks or relationships
2. Adornments
3. Flow
4. Stereo types
4. Building blocks hide those that are not relevant to the intent of your diagram or the
needs of your diagram or the needs of your reader2. Adornments reveal only the adornments of these building blocks and relationships
that are essential to understanding your intent.3. Flow in the context of behavioral diagrams, expand only those messages or
transactions that are essential to understanding your intent.4. Stereotypes in the context of stereotypes used to classify lists of things, such as
attributes and operations, reveal only those stereotyped items that are essential to understanding your intent.
![Page 46: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/46.jpg)
High level of abstraction
Order taker orderfullfillment
submitorderplaceorder
acknowledgeOrde
![Page 47: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/47.jpg)
Low level of abstraction
Order taker orderfullfillment
submitorderplaceorder
acknowledgeOrder
process card
Billing agent
triggerBill
![Page 48: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/48.jpg)
Modeling complex views
To model a system with a high level of abstraction by eliding some details,
you’d lose the information necessary to make these insights.To model complex views….
If there is no meaningful information present in a high-level abstraction ,elide
some parts of the diagram and retaining the details in other part.
After eliding if still the diagram is complex , group some of the elements in
packages or in high-level of abstractions, then render those packages or
collaborations in your diagram.
If still diagram is complex, use notes and color as visual cues to draw the
readers attention to the points you want to make.
If it is still complex , print it in its entirely and hang it on a convenient large
wall. You lose the interactivity an online version of the diagram brings, but you
can step back from the diagram and study it for common patterns
![Page 49: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/49.jpg)
Advanced
Structural
Modeling
![Page 50: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/50.jpg)
Advanced
Classes
![Page 51: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/51.jpg)
classifier:- A classifier is a mechanism that describes structural and behavioral features. The UML provides a number of other kinds of classifiers.
Classes:- Classes are the most important building block of any object-oriented system. A class is a description of set of objects that share the same attributes, operations, relationships, and semantics.
Interface:- A collection of operations that are used to specify a service of a class or a component.
IUnknown
Shape
origin
move()Resize()Display()
![Page 52: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/52.jpg)
Datatype:- A type whose values have no identify, including primitive built-in types, as well as enumeration types.
Signal:- The specification of an asynchronous stimulus communicated between instances.
Component:- A physical and replaceable part of a system that conforms to and provides the realization of a interfaces.
<<type>>Int
{values range from-2**31-1 to +2**31}
<<signal>>OffHook
Kernel32.dll
![Page 53: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/53.jpg)
Node:- A physical element that exists at time and that represents a computational resource. Generally having at least some memory and often processing capability.
Use case:- A description of a set of a sequence of actions, including variants, that a system performs that yields an observable result of value to a particular actor.
Subsystem:- A grouping of elements of which some constitute a specification of the behavior offered by the other contained elements.
egb_server
Process loan
<<subsystem>>Customer Service
subsystem
![Page 54: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/54.jpg)
Visibility:- Visibility is one of the most important details that we can specify using some symbolic notation the visibility of a feature specifies whether it can be used by other classifies UML specifies three levels of visible. Public Any outside classifier with visibility to the given classifier can
Protected Any descendent of the classifier can use the feature, specified by
Private Only the classifier itself can use the feature, specified by prepending
use the feature, specified by prepending the symbol ( + )
Prepending the symbol ( # )
the symbol ( - ) Toolbar
# currentSelection : Tool# toolCount : Integer
+ pickItem(I : Integer)+ addTool(t : Tool)+ removeTool(I : integer)+ getTool() : Tool# checkOrphans()- compact()
![Page 55: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/55.jpg)
Scope:- Scope is an another detail which can be specified for a classifiers ownership. UML has two keywords which specify the “ scope “ , they are
instance Each instance of the classifier holds its own value for the feature classifier There is just one value of the feature for all instance of the classifier
it shows a feature that is classifier scoped is rendered by underlining the feature’s name. No adornment means that the feature is instance scoped.
Frame
header : FrameHeaderuniqueID : Long
Instance scope
Class scope
![Page 56: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/56.jpg)
Abstract, Root, leaf, and Polymorphic Elements:-
UML uses the notation of writing the names of classes and operations in
Italics to show that they are abstraction.
Root is a keyword which is associated with the name of a class to ensure
that this class does not have any more parents that is, this is the super class.
Leaf is one more keyword which is also associated the name of the class
to ensure that this class cannot be for that extended.
When a message is dispatched at run time, the operation in the hierarchy
that is invoked is chosen polymorphically that is, a match is determined at run time
according to the type of the object. For example, display and isInside are both
polymorphic operations.
![Page 57: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/57.jpg)
Icon{root}
Origin : point
display()getID() : Integer {leaf}
RectangularIcon
height : Integerwidth : Integer
Button
Display()
OKButton{leaf}
display()
ArbitraryIcon
edge : LineCollection
isInside(p : Point) : Boolean
Concrete class
Abstract class
Leaf class
Polymorphic operation
![Page 58: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/58.jpg)
Multiplicity:- The number of instances a class may have is called its multiplicity. In UML we can specify the multiplicity of a class is specify by writing a multiplicity expression in the upper right corner of the class. For example, NetworkController is a singleton class. There are exactly three instances of the class ControlRod in the system.
Attribute:- It can specify the visibility, scope, and multiplicity of each attribute and also the type, initial value, and changeability of each attribute. The syntax of an attribute in the UML is
[visibility] name [multiplicity] [: type] [= initial-value] [{property-string}]
NetworkController
consolePort [2..*] : Port
![Page 59: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/59.jpg)
There are three defined properties that you can use with attributes.
changeable There are no restrictions on modifying the attributes value.
addOnly Attributes with a multiplicity greater than one, additional values
frozen The attributes value may not be changed after the object is
Operations:- It can specify the parameters, return type, concurrency semantics, and other properties of each operation. The name of an operation plus its parameters is called the operations signature. The syntax of an operation in the UML is [visibility] name [(parameter-list)] [ : return-type] [{property-string}]
may be added, but once created, a value may not be removed or altered.
Initialized.
![Page 60: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/60.jpg)
The classifiers for the operations of the class are of two types.
1) Classifiers for the arguments of an operation.2) Classifiers for the operations it self.
Classifiers for the arguments of an operation:- The classifiers for the arguments of an operation are also known as directions. There are three directions available, they are in out inout
in An input parameter, may not be modified. out An output parameter, may be modified to communicate information to the
inout An input parameter, may be modified.
caller.
![Page 61: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/61.jpg)
Classifiers for the operations it self:- There are four classifiers available in UML for the operations of a class, they are isQuery sequential guarded concurrent
isQuery Execution of the operation leaves the state of the system unchanged.
sequential Callers must coordinate outside the object so that only one flow is in
guarded The semantics and integrity of the object is guaranteed in the
In other words, the operation is a pure function that has no side effects.
the object at a time. In the presence of multiple flows of control, the semantics and integrity of the object cannot be guaranteed.
presence of multiple flows of control by sequentializing all calls to all of the objects guarded operations.
![Page 62: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/62.jpg)
Concurrent The semantics and integrity of the object is guaranteed in the
Template Classes:- A template is a parameterized element. We can write template classes, each of which defines a family of classes. A template includes slots for classes, objects, and values. The result is a concrete class that can be used just like any ordinary class.
presence of multiple flows of control by treating the operation as atomic.
Map
+ bind(in I : Item; in v : value) : Boolean+ isBound(in I :item) : Boolean {isQuery}
OrderMap
<<bind>> (Customer, Order, 3) explicit binding
Map<Customer, Order, 3>
Implicit binding
Template class ItemValueBuckets : int
Template parameters
![Page 63: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/63.jpg)
Standard Elements:- In UML’s extensibility mechanisms apply to classes. Most often, we will use tagged values to extend class properties and stereotypes to specify new kinds of components. There are four standard stereotypes that are used, they are
Metaclass Powertype Stereotype Utility
metaclass Specifies a classifier whose objects are all classes.
powertype Specifies a classifier whose objects are the children of a given
stereotype Specifies that the classifier is a stereotype that maybe applied to
utility Specifies a class whose attributes and operations are all class
parent
other elements.
scoped.
![Page 64: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/64.jpg)
Common Modeling Techniques:-Modeling the semantics of class:-
In the advanced structural modeling for a class the following are the set of common modeling techniques available.
Specify the responsibility of the class. Specify the semantics of the class. Specify the source code of each and every operation in the class. Specify the preconditions & post conditions of each operation in the class. Specify the state machines. Specify the collaborations.
![Page 65: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/65.jpg)
Advanced
Relationships
![Page 66: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/66.jpg)
A relationship is a connection among things. In object-oriented modeling, the four most important relationships are dependencies, generalizations, associations, and realizations. Graphically, a relationship is a rendered as a path, with different kinds of lines used to distinguish the different relationships.
Dependency:- A dependency is a using relationship, specifying that a change in the specification of one thing may effect another thing, but not necessarily the reverse. Graphically, a dependency is rendered as a dashed line, directed to the thing. UML defines a number of stereotypes that may be applied to dependency relationships. There are 17 such stereotypes, all of which can be organized into six groups.
There are 8 stereotypes that apply to dependency relationships among classes and objects in class diagram.
![Page 67: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/67.jpg)
bind Specifies that the source instantiates the target template using the given actual parameters. derive Specifies that the source may be computed from the target.
friend Specifies that the source is given special visibility into the target.
instanceOf Specifies that the source object is an instance of the target classifier.
instantiate Specifies that the source creates instances of the target. powertype Specifies that the target is a powertype of the source i.e., whose objects are all the children of a given parent.
refine Specifies that the source is at a finer degree of abstraction than the target.
use Specifies that the semantics of the source element depends on the semantics of the public part of the target.
![Page 68: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/68.jpg)
Stereotypes for packages:- access Specifies that the source package is granted the right to reference the elements of the target package. import Specifies that the public contents of the target package enter the flag namespace of the source.
Stereotypes for use cases:- extend Specifies that the target use case extends the behavior of the source.
include Specifies that the source use case explicitly incorporates the behavior of another use case.
Stereotypes for Interaction:- become Specifies that the target is the same object as the source but at a later point in time wit different values states & roles.
call Specifies that the source operation invokes the target operation.
copy Specifies that the target object design exact, but independent, copy of the source.
![Page 69: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/69.jpg)
Stereotypes for state machine:- send Specifies that the source operation sends the target event.
trace Specifies that the target is an historical ancestor of the source.
Generalization:- A Generalization is a relationship between a general thing and a more specific kind of that thing. The relationship generalization is having only one stereotypei.e., implementation which models the “ private inheritance “. The generalization relationship is having 4 standard constraints, they are complete incomplete disjoint overlapping
complete Specifies that all children in the generalization have been specified in the model and that no additional children are permitted.
incomplete Specifies that not all children in the generalization have been specified and that additional children are permitted.
![Page 70: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/70.jpg)
disjoint Specifies that objects of the parent may have no more than one of the children as a type.
overlapping Specifies that objects of the parent may have more than one of the children as a type.
Association:- An association is a structural relationship, specifying that objects of one thing are connected to objects of another. Graphically, an association is rendered as a solid line connecting the same or different classes. Association is bi-directional relationship. In UML which is having the following stereotypes.
Navigation Visibility Qualification Interface Specifies Composition Association Class
![Page 71: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/71.jpg)
Navigation:- At times the navigation between the two entities participating than association is unidirectional in order to implement this UML provides a concept known as navigation using a directed arrow or a filled triangle.
1 *
Visibility:- In UML, we can specify three levels of visibility for the association ends, Generally applied to the role names, public(+),private(-),protected(#).
user password
UserGroup user Password1 * 1 *
![Page 72: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/72.jpg)
Qualification:- The stereotype qualification implements the concept of “ relationship attributes “. UML uses at different concept known as qualification by which a qualifier is mentioned at any of the ends of the relation. Using a small rectangle.
Interface Specifier:- Using interface specifies we mentioned the names of the interfaces implements by each role names of an association relationships.
WorkDesk jobID : Int ReturnedItem* 0…1
Person
Worker : IEmployee
Supervisor : IManager
![Page 73: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/73.jpg)
Composition:- A composition is one of the forms of association which implements the relationship whole / part, such relationship are often known as aggregation but an aggregation with a multiplicity of exactly one at any of the ends is known as composition.
Association Classes:- In an association between two classes, the association if self may have some properties, UML provides 4 standard properties or adornments they are name, role names, multiplicity & aggregation.
window
Frame
1
*
Company Person
Jobdescription dateHired salary
* 1..*
![Page 74: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/74.jpg)
Constraints:- These simple and advanced properties of associations are sufficient for most of the structural relationships.UML defines five constraints they are implicit Specifies that the relationship is not manifest but, rather, is only conceptual.
ordered Specifies that the set of objects at one end of an association are
in an explicit order.
changeable Links between may be added, removed, and changed freely. addOnly New links may be added from an object on the opposite end of the association. frozen A link, once added from an object an the opposite end of the
association, may not be modified or deleted.
![Page 75: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/75.jpg)
Realization:- A realization is a semantic relationship between classifies in which one classifier guarantees to carry out. Graphically, a realization is rendered as a dashed directed line with a open hallow head.
-----------------
<<interface>>IRuleAgent
addRule()changeRule()explainAction()
AccountBusinessRules
Realization
Realization of an interface
![Page 76: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/76.jpg)
Common Modeling Technique:-Modeling Webs of Relationships:-
Identify the use cases & synonyms. Start by modeling the structural relationships. Identify for any generalization or specialization relationships. After the above steps completion only proceed for looking dependencies. Identify each kind of relationship and if necessary apply the advanced features. Don’t try for modeling all kinds of relationships in a single diagram or view.
![Page 77: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/77.jpg)
packages
![Page 78: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/78.jpg)
A package is a general –purpose mechanism for organizing elements into rules. Graphically, a package rendered as a tabbed folder.
Concepts:- Names Owned Elements Visibility Importing and Exporting
Names:- A name is a textual string. That name alone is known as a simple name. A package is typically drawn showing only its name.
Simple names Path names
client+OrderForm+ TrackingForm- Order
Sensors::vision
![Page 79: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/79.jpg)
Owned Elements:- A package may contain classes, interfaces, components, nodes, collaborations. A package forms a namespace in which duplication of the names of same elements is not possible. Elements of different kinds may have same name with in a package. Packages may own other packages.
+ Orderform+ TrackingForm- Order
Client
+ OrderForm
- Order
+ TrackingForm
Client
![Page 80: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/80.jpg)
Visibility:- visibility of an element owned by a package by prefixing the elements name with an
appropriate visibility symbol. Public elements are rendered by prefixing their name with a +
symbol, as for OrderForm. Collectively, the public parts of a package constitute the package’s
interface. It is rendered by prefix in the elements name with a# symbol and a – symbol
respectively.
Importing and Exporting:-
In the UML, we model an import relationship as a dependency adorned with the
stereotype import. By packaging we abstractions into meaningful chunks and then controlling
their access by importing.
The parts that one package exports are visible only to the contents of those packages
That explicitly import the package.
![Page 81: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/81.jpg)
+ Database+ LoggingService
Server+ Orderform+ TrackingForm - Order
Client
+ OrderRules- GUI::Window
Policies
+ Window+ Form# EventHandler
GUI
exports
<<import>>
<<import>>
import
Importing and exporting
![Page 82: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/82.jpg)
Generalization:- Generalization among packages is very much like generalization among classes. The package GUI is shown to export two classes. Packages involved in generalization relationships follow te same principle of substitutability as do classes
+ Window+ Form# eventHandler
GUI
+ GUI::Window+ Form# GUI:EventHandler+ VBForm
MacGUI
WindowsGUI
![Page 83: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/83.jpg)
Standard Elements:- All the UML’s extensibility mechanisms for also applicable to package.UML defines a set of 5 standard stereo types which are applicable only two packages, they are
Facade Framework Stub Subsystem System
facade Specifies a package that is only a view on some other package framework Specifies a package consisting mainly of pattern stub Specifies a package that serves as a proxy for the public contents of another package subsystem Specifies a package representing an independent part of the entire system being modeled system Specifies a package representing the entire system being modeled
![Page 84: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/84.jpg)
Common Modeling Techniques:-
Modeling Groups of Elements:-
Scan the modeling elements in a particular architectural view.
Surround each of these clumps into a package.
After forming the package mention the visibility of various elements present in the
package.
If necessary specify the generalization among the packages.
![Page 85: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/85.jpg)
Modeling Architectural Views:-
Packages are generally used to model the different views of an architectural
a view is a projection into any organization & structure of the system.
Identify the architectural views that are significant for the problem.
Place the elements(diagrams) that are necessary and sufficient to visualize, specify,
construct & document the semantics of the package.
If necessary group the elements further into way own package.
![Page 86: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/86.jpg)
Interface
s, roles
and
names
![Page 87: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/87.jpg)
Interfaces Interfaces define a line between the specification of what an abstraction does and the implementation of how that abstraction does it. An interface is a collection of operations that are used to specify a service of a class or a component.
We use interfaces to visualize, specify, construct and document the seams within your system. Types and roles provide a mechanism for you to model the static and dynamic conformance of an abstraction to an interface in a specific context.
A well-structured interface provides a clear separation between the outside view and the inside view of an abstraction, making it possible to understand and approach without having to dive into the details of its implementation
![Page 88: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/88.jpg)
Terms and concepts of interfaceNames every interface must have a name that distinguishes it from other interfaces. A name is a
textual string. That name alone is known as a simple name; a path name is the interface name prefixed by the name of the package in which that interface lives, an interface may be drawn showing only its name.
Iunknown Networking::IRouter
simple names path names
Ispell Isensor Sensors::ITarget
![Page 89: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/89.jpg)
Operations an interface is a named collection of operations used to specify a service of a class or of a component. Like a class, an interface may have any number of operations. These operations may be adorned with visibility properties , concurrency properties, stereotypes, tagged values, and constraints. when we visualize an interface in its normal form as a circle, w suppress the display of these operations. We can render an interface as a stereotyped class, listing its operations in the appropriate compartment. Operations may be drawn showing only their name, or they may be augmented to show their full signature and other properties.
stereotype
operations
operations
<<interface>>url StreamHandler
openConnection()parse URL()setURL()
toExternalForm()
![Page 90: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/90.jpg)
Relationships like a class an interface may participate in generalization, association and dependency relationships. In addition , an interface may participate in realization relationships . realization is a semantic relationship between two classifiers in which one classifier specifies a contract that classifier guarantees to carry out. We can show that an element realizes an interface in two ways.
simple form in which the interface and its realization relationship are rendered as a lollipop sticking off to one side of a class or component. This is useful when you simply want to expose the seams in your system.
second, you can use the expanded form in which you render an interface as a stereotyped class, which allows you to visualize its operations and their properties, and then draw a realization relationship from the classifier or component to the interface. in UML a realization is rendered as a dashed directed line with a large open arrow head pointing to the interface. This notation is cross between generalization and dependency. in both cases, you attach the class or component that builds on an interface with a dependency relationship from the element to the interface.
![Page 91: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/91.jpg)
Tracker
TargetTracker
<<interface>>Observer
Update()
TargetId
currentPosition
setPosition()setVelocity()
expectedPosition()
TargetTracker
Java::Util::Observable
---------
--------
dependency
dependency
interface
Realization(exapanded form)
observerRealization(simple form)
![Page 92: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/92.jpg)
Types and roles Types and roles provide a mechanism for you to model the static and dynamic
conformance of an abstraction to an interface in a specific context. A type is a stereotype of a class used to specify a domain of objects, together with operations applicable to the object. A role is the behavior of an entity participating in a particular context. interface association
e:Employee
class class role
<<interface>>Employee
getEmploymtHistory()getCompensation()getBenefits()
person Company
![Page 93: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/93.jpg)
Common modeling techniques There are two common modeling techniques
modeling the seams in a system modeling static and dynamic types
Modeling the seams in a system To model the seams in a system
Within the collection of classes and components, draw a line around those that tend to be tightly coupled relative to other sets of classes and components.
Classes or components that tend to change together should be grouped together as collaborations.
Consider the operations and the signals that cross these boundaries, from instances of one set of classes or components to instances of other sets of classes and components.
Package logically related sets of these operations and signals as interfaces For such collaboration identify the interfaces it relies on those it provides to others. Model
importing interfaces by relationships, and exporting by realization relationships. for each interface document its dynamics by using pre-and post conditions for each
operation , and use cases and state machines for the interface as a whole.
![Page 94: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/94.jpg)
<<interface>>Iunknown
QueryInterface():HRESULTAddRef():ULONGRelease():ULONG
<<interface>>ITransaction
Start()PerformAction()Commit()Rollback()Exceptions failure
Ledger.dllILedger
IReports
Modeling the seams in a system
![Page 95: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/95.jpg)
Modeling static and dynamic types
Modeling the static nature of an object can be visualized in a class diagram.To model a dynamic type…
Specify the different possible types of that object by rendering each type as a class stereotyped as type or as interface.
Model all the roles the class of the object may take on at point in time. We can do in two ways.
1. First, in a class diagram, explicitly type each role that the class plays in its association with other classes.
2. Second, also in class diagram, specify the class-to-type relationships using generalization.
In an interaction diagram, properly render each instance of the dynamically typed class. Display the role of the instance in brackets below the object’s name.To show the change in role of an object, render the object once for each role it plays in the interaction , and connect these objects with a message stereotyped as become.
![Page 96: UML COURSE UNIT II](https://reader034.vdocument.in/reader034/viewer/2022051411/54686711af795969338b5d34/html5/thumbnails/96.jpg)
<<type>>Canditate
<<type>>Employee
<<type>>Retiree
person
P:person[employee]
P:person[Canditate]
HRDepartment
Modeling static types
Modeling dynamic types
<<become>>
Hire()