Basic

structural

modeling

Presented byN.Prathyush

aV. Tejaswi

P. Usha

classes

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

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

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

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

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()

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

Relationship

s

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

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

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

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

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

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

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

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

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

Specifications

Adornments

Common divisions

Extensibility

Common mechanisms

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

public

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

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

constraints

Tagged values

Stereo

types

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

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}

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

Comm

on

modeli

ng

techni

ques

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

{version=3.2Status=checkout

By=edg}

<<subsystem>>AccountsPayable

{version=3.2.1Status=checkedin}

<<subsystem>>WorldCurrency

{version=7.5Status=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

member 1..* 1 manager

department

person

{subset} <-----------

diagram

s

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. use case diagram 2. sequence diagram 3. collaboration diagram 4. state chart diagram 5. 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 event-ordered behavior of an object

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

Common

modeling

techniques

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

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

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

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

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.

High level of abstraction

Order taker orderfullfillment

submitorderplaceorder

acknowledgeOrde

Low level of abstraction

Order taker orderfullfillment

submitorderplaceorder

acknowledgeOrder

process card

Billing agent

triggerBill

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

Advanced

Structural

Modeling

Advanced

Classes

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()

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

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

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()

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

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}

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

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

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.

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.

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.

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

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.

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.

Advanced

Relationships

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

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

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

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 *

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

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

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.

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

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.

packages

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

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

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.

+ Database+ LoggingService

Server+ Orderform+ TrackingForm - Order

Client

+ OrderRules- GUI::Window

Policies

+ Window+ Form# EventHandler

GUI

exports

<<import>>

<<import>>

import

Importing and exporting

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

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

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.

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.

Interface

s, roles

and

names

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

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

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()

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.

Tracker

TargetTracker

<<interface>>Observer

Update()

TargetId

currentPosition

setPosition()setVelocity()

expectedPosition()

TargetTracker

Java::Util::Observable

---------

--------

dependency

dependency

interface

Realization(exapanded form)

observerRealization(simple 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

e:Employee

class class role

<<interface>>Employee

getEmploymtHistory()getCompensation()getBenefits()

person Company

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.

<<interface>>Iunknown

QueryInterface():HRESULTAddRef():ULONGRelease():ULONG

<<interface>>ITransaction

Start()PerformAction()Commit()Rollback()Exceptions failure

Ledger.dllILedger

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.

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.

<<type>>Canditate

<<type>>Employee

<<type>>Retiree

person

P:person[employee]

P:person[Canditate]

HRDepartment

Modeling static types

Modeling dynamic types

<<become>>

Hire()