Uml Course Unit Ii

Presented by N.Prathyush a

a l c

s s

s e

Classes contents:Ø 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.

name

attributes operations

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. Customer

simple names

Java::awt::Rectangle 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 walisted in a compartment just below the class name. Height: llfloat Width: float Thickness: float IsLoadBearing : Boolean = false

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. Rectangl e add() grow() move() Is Empty()

Operation by stating its signature, covering the name, type, and default value of all parameters and a return type. TemperatureSen sor Reset() setAlarm(t : Temperature) Value() : Temperature

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 customerspecific criteria for fraud

Com mon Model ing Tec hni ques :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 system Modeling the responsibilities of the system Modeling non-software things Modeling 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() wasSuccessf ul()

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

Modeling non-software things:stereo type.

Model the non-software thing as a class If we want to distinguish the modeled class from the existing UML classes use a

If the non-software thing which we want to model is in hardware, try to model a using a “ node “.

Accounts Receivable Agent

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.

<<enumeration> > Boolean False true

p i h s n

o i t a l e s R

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 dependenc y

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-AKIND of relationship. Graphically, generalization is rendered as a solid directed line with a large open arrow head, pointing to the parent. Shape base class origin Move() Resize() Display()

generalizatio n

Rectangl e Corner: point

Square

Circle Radius : float

Polygon Points: List display

Leaf class

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. Name direction

name Person

Works for associatio n

Company

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. Person

Company

employe e

employer association

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.

1... Person

Company

associatio n

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

aggregati on

whole

part

Department

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

Modeling Simple Inheritance:classes.

To model inheritance between a set of classes, Identify the responsibilities, attributes and operations that are common to two or more

Create a class with the above mentioned common responsibilities, attributes and operations. Lastly show the relationships from the specialized classes to generalized class. Security presentValu e() History()

CashAccount interestRat e presentValu e()

Stock

Bond

Property assessments

presentValu e()

SmallCapSto ck

presentValue presentValu () e()

LargeCapSto ck

Common Structural Relationships:A relationships are classified into two types, they are one-side, two-sided dependency 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. 0… ha Departme 1 School s nt 1. 1 1. 1. 1. . . . . member

Student

attends

1. . Course

Assigned To 0 1. ..1 chairpers teach . on Instruct es 1. or .

n o m s m ism o C n a h c e m

Common mechanisms 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…. q

Specifications

q

Adornments

q

Common divisions

q

Extensibility

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.

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..

publi c private

#

protected note

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 dogeared corner. In uml a note can be rendered in three ways. They are…..

A note may contain some plain Simple text text

put an url inside a note

An embedded url

We may link to or embed another document Link to 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

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 <<metaclass>

Named stereotype

ModelElement

define an icon for the stereotype and render that icon to the right of the name

<<exception>> underflow

!

Named stereo type with icon

Render an icon as a basic symbol for the stereo typed item Stereotyped element as icon

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). Server {processor s=3}

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 corporation

portfolio

Bank Account

Constraint across multiple constraints

{secur e} { or}

person Gender :{f,m}

Formal constraint Using ocl

{self.wife.gender=fem ale and

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

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

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>> AccountsPayable {version=3.2.1 Status=checkedin }

---

--

---

---

<<subsystem>> Billing {version=3.2 Status=checkout By=edg}

<<subsystem>> WorldCurrency {version=7.5 Status=checedin}

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

department

member {subset 1..* }

person

1

manager

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

The following diagrams are used to view the dynamic parts of a system 1. 2. 3. 4. 5.

use case diagram sequence diagram collaboration diagram state chart diagram activity diagram

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 eventordered behavior of an object

Activity diagram Component diagram Deployment diagram

A behavioral diagram that shows a state machine, emphazing the flow from activity to activity A structural diagram that shows a set of components and their relationships A structural diagram that shows a set of nodes and their relationships

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.

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.. quse case view

use case diagrams

qdesign view

class diagrams ( for structural

modeling) interaction diagrams ( for behavioral modeling) q process view qimplementation view qdeployment

none required none required none required

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… q use case view

use case diagrams activity diagrams( for behavioral

modeling) q design view

class diagrams ( for structural

modeling) Interaction diagrams ( for behavioral diagram) State chart diagrams( for behavioral

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 lowlevel abstraction i.e. the complete set of artifacts, relations and specifications. irrespective of the abstractions selected the reader should

1 . Building blocks or relationships 3. Adornments 5. Flow 4. Stereo types 5. 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 reader 8. Adornments reveal only the adornments of these building blocks and relationships that are essential to understanding your intent. 11. Flow in the context of behavioral diagrams, expand only those messages or transactions that are essential to understanding your intent. 14. 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

High level of abstraction

Order taker

submitord er

orderfullfillme nt

placeorder

acknowledgeOrde

Low level of abstraction

orderfullfillme nt

Order taker process card submitord er

placeorder

acknowledgeOrder

triggerBill

Billing agent

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

d e c n l a a v r d A uctu g r n t i S del o M

d e c n a v s d e A s s a l C

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. Shape origin move()

Interface:-

Resize() Display()

A collection of operations that are used to specify a service of a class or a component.

IUnknown

Datatype:-

A type whose values have no identify, including primitive built-in types, as well as enumeration types. <> Int {values range from -2**31-1 to Signal:+2**31} The specification of an asynchronous stimulus communicated between instances.

Component:-

<<signal >> OffHook

A physical and replaceable part of a system that conforms to and provides the realization of a interfaces.

Kernel32. dll

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:-

egb_serv er

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.

Process loan A grouping of elements of which some constitute a specification of the behavior offered by the other contained elements.

Subsystem:-

<<subsystem >> Customer Service subsystem

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 Protected Private

Any outside classifier with visibility to the given classifier can use the feature, specified by prepending the symbol ( + ) Any descendent of the classifier can use the feature, specified by Prepending the symbol ( # ) Only the classifier itself can use the feature, specified by prepending the symbol ( - )

Toolbar # currentSelection : Tool # toolCount : + pickItem(I : Integer) + addTool(t : Tool) + removeTool(I : integer) + getTool() : Tool # checkOrphans()

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 : FrameHeader uniqueID : Long Class scope

Instance scope

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.

Icon {root} Abstract class

Origin : point display() getID() : Integer {leaf} RectangularIc on height : Integer width : Button Display()

OKButton {leaf} display()

ArbitraryIcon edge : LineCollection isInside(p : Point) : Boolean

Concrete class Leaf class

Polymorph ic operation

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. NetworkController consolePort [2..*] : Port

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}]

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 may be added, but once created, a value may not be removed or altered.

frozen

The attributes value may not be changed after the object is Initialized.

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}]

The classifiers for the operations of the class are of two types.

3) Classifiers for the arguments of an operation. 4) 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

vin vout vinout in out the

An input parameter, may not be modified. An output parameter, may be modified to communicate information to caller.

inout

An input parameter, may be modified.

Classifiers for the operations it self:There are four classifiers available in UML for the operations of a class, they are

visQuery vsequential vguarded vconcurrent isQuery unchanged.

sequential in

guarded

Execution of the operation leaves the state of the system In other words, the operation is a pure function that has no side effects. Callers must coordinate outside the object so that only one flow is the object at a time. In the presence of multiple flows of control, the semantics and integrity of the object cannot be guaranteed. The semantics and integrity of the object is guaranteed in the presence of multiple flows of control by sequentializing all calls to all of the objects guarded operations.

Concurrent

The semantics and integrity of the object is guaranteed in the presence of multiple flows of control by treating the operation as atomic.

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. Template class Map

Item Value Buckets : int

Template parameters

+ bind(in I : Item; in v : value) : Boolean + isBound(in I :item) : Boolean

Implicit binding Map

<> (Customer, Order, 3) explicit binding OrderMa p

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 parentthat the classifier is a stereotype that maybe applied to

utility

Specifies a class whose attributes and operations are all class other elements. scoped.

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.

d e c n s a p i v h d s A ion t a l e R

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.

bind Specifies that the source instantiates the target template using the given actual parameters. derive the target.

Specifies that the source may be computed from

friend into the target.

Specifies that the source is given special visibility

instanceOf Specifies that the source object is an instance of the target classifier. instantiate target.

Specifies that the source creates instances of the

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

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.

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 stereotype i.e., implementation which models the “ private inheritance “. The generalization relationship is having 4 standard constraints, they are

qcomplete qincomplete qdisjoint qoverlapping 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.

disjoint overlapping

Specifies that objects of the parent may have no more than one of the children as a type. 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.

vNavigation vVisibility vQualification vInterface Specifies vComposition vAssociation Class

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 user

password

Visibility:In UML, we can specify three levels of visibility for the association ends, Generally applied to the role names, public(+),private(-),protected(#).

UserGroup

1

*

user

1

*

Password

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.

WorkDesk

jobID : Int

0… 1

*

ReturnedIte m

Interface Specifier:Using interface specifies we mentioned the names of the interfaces implements by each role names of an association relationships.

Worker : IEmployee Person Supervisor : IManager

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. window 1

* Frame

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. 1 ..*

Compan * y Job descriptio n dateHired salary

Person

Constraints:These simple and advanced properties of associations are sufficient for most of the structural relationships.UML defines five constraints they are

implicit ordered

Specifies that the relationship is not manifest but, rather, is only conceptual. 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. A link, once added from an object an the opposite end of the association, may not be modified or deleted.

frozen

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. < > IRuleAgent addRule() changeRule( ) explainActio

Realizatio n

-----------------

AccountBusinessR ules

Realization of an interface

Common Modeling Technique:Modeling Webs of Relationships:v v v v v v

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.

c a p

s e g ka

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.

client +OrderForm + TrackingFor Simple names m

Sensors::visi on Path names

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. Clien t + Orderform + TrackingFor m - Order

Clien t + OrderForm Order + TrackingFor m

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.

Client + Orderform + TrackingFor m

Server + Database + LoggingServi ce expor ts

GUI + Window + Form # EventHandle r

Policie s + OrderRules GUI::Window

< >

Importing and exporting

<>

import

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

GUI + Window + Form # eventHandler

WindowsG UI + GUI::Window + Form # GUI:EventHandl er + VBForm

MacGUI

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 framework stub subsystem system

Specifies a package that is only a view on some other package Specifies a package consisting mainly of pattern Specifies a package that serves as a proxy for the public contents of another package Specifies a package representing an independent part of the entire system being modeled Specifies a package representing the entire system being modeled

Common Modeling Techniques:Modeling Groups of Elements:v Scan the modeling elements in a particular architectural view. v Surround each of these clumps into a package. v After forming the package mention the visibility of various elements present in the package. v If necessary specify the generalization among the packages.

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. v Identify the architectural views that are significant for the problem. v Place the elements(diagrams) that are necessary and sufficient to visualize, specify, construct & document the semantics of the package. v If necessary group the elements further into way own package.

Interfaces v 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. v 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. v A well-structured interface provides a clear separation between the outside view and the inside view of an abstraction, making it

Terms and concepts of interface Names

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.

Networking::IRouter

Iunknown

simple names names

Ispell Sensors::ITarget

Isensor

path

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

<> url StreamHandler openConnectio n()parse URL() setURL() toExternalForm ()

operations

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.

dependency Tracker

TargetTracker

--------observ er

Java::Util::Observa ble

Realization(simple form)

interfa ce Target Id currentPosition setPosition() setVelocity() expectedPositi on()

dependency

--------

<> Observer

TargetTracker

Update() Realization(exapanded form)

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 Employee getEmploymtHisto ry() getCompensation( ) getBenefits() class role

person

Company e:Employee class

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.

<> Iunknown QueryInterface():HRE SULT AddRef():ULONG Release():ULONG

<> ITransaction Start() PerformAction() Commit() Rollback() Exceptions failure

ILedger Ledger.dll

IReports Modeling the seams in a system

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. 7. First, in a class diagram, explicitly type each role that the class plays in its association with other classes. 8. 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

< > Canditate

<> Employee

<> Retiree

person

Modeling static types

P:person [Canditate] Hire( )

< >

P:person [employee ]

HRDepartme nt

Modeling dynamic