Notesale: Turn your study into money

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

---

OOAD

III YEAR II SEM CSE

UNIT – I
The UML is a graphical language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive system
...

Model
A model is a simplification of reality
...

A model may be structural, emphasizing the organization of the system, or it may
be behavioral, emphasizing the dynamics of the system
...

Through modeling, we achieve four aims
...
Models help us to visualize a system as it is or as we want it to be
...
Models permit us to specify the structure or behavior of a system
...
Models give us a template that guides us in constructing a system
...
Models document the decisions we have made
...

Principles of Modeling
There are four basic principles of model
1
...

2
...

3
...

4
...
Every nontrivial system is best approached
through a small set of nearly independent models
...
The two most common
ways are
1
...
Object-oriented perspective
Algorithmic Perspective
The traditional view of software development takes an algorithmic
perspective
...

This view leads developers to focus on issues of control and the
decomposition of larger algorithms into smaller ones
...

1

OOAD

III YEAR II SEM CSE

Object-oriented perspective
The contemporary view of software development takes an object-oriented
perspective
...

A class is a description of a set of common objects
...

Object-oriented development provides the conceptual foundation for
assembling systems out of components using technology such as Java Beans or
COM+
...
The UML may be used to visualize, specify, construct, and
document the artifacts of a software-intensive system
...
It is a very expressive language,
addressing all the views needed to develop and then deploy such systems
...
Rather,
behind each symbol in the UML notation is a well-defined semantics
...

Constructing the UML is not a visual programming language, but its models
can be directly connected to a variety of programming languages
Documenting a healthy software organization produces all sorts of artifacts in
addition to raw executable code
...
Things
2
...
Diagrams
Things in the UML
There are four kinds of things in the UML:
Structural things
Behavioral things
Grouping things
Annotational things
Structural things are the nouns of UML models
...
In
all, there are seven kinds of structural things
...
Classes
2
...
Collaborations
4
...
Active classes
6
...
Nodes
Class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics
...
Graphically, a class is rendered as a rectangle, usually including its
name, attributes, and operations
...

An interface therefore describes the externally visible behavior of that
element
...

An interface is rendered as a circle together with its name
...
Rather, it is typically attached to the class or component that
realizes the interface

Collaboration defines an interaction and is a society of roles and other elements
that work together to provide some cooperative behavior that's bigger than the
sum of all the elements
...
A given class might participate in several collaborations
...

 A use case is realized by a collaboration
...
Graphically, an active class is
rendered just like a class, but with heavy lines, usually including its name,
attributes, and operations

Component is a physical and replaceable part of a system that conforms to and
provides the realization of a set of interfaces
...
Graphically, a node is rendered as a cube, usually
including only its name

4

OOAD

III YEAR II SEM CSE

Behavioral Things are the dynamic parts of UML models
...
In all, there are two primary
kinds of behavioral things
Interaction
state machine
Interaction
Interaction is a behavior that comprises a set of messages exchanged
among a set of objects within a particular context to accomplish a specific
purpose
An interaction involves a number of other elements, including messages,
action sequences and links
Graphically a message is rendered as a directed line, almost always
including the name of its operation

State Machine
State machine is a behavior that specifies the sequences of states an object
or an interaction goes through during its lifetime in response to events, together
with its responses to those events
State machine involves a number of other elements, including states,
transitions, events and activities
Graphically, a state is rendered as a rounded rectangle, usually including
its name and its substates

Grouping Things:1
...
These are the boxes into which
a model can be decomposed
2
...

Package: A package is a general-purpose mechanism for organizing elements into
groups
...
These are the
comments you may apply to describe about any element in a model
...

Graphically, a note is rendered as a rectangle with a dog-eared corner,
together with a textual or graphical comment

Relationships in the UML: There are four kinds of relationships in the UML:
1
...
Association
3
...
Realization
Dependency:Dependency is a semantic relationship between two things in which a
change to one thing may affect the semantics of the other thing
Graphically a dependency is rendered as a dashed line, possibly directed,
and occasionally including a label

Association is a structural relationship that describes a set of links, a link being
a connection among objects
...
Graphically, a generalization
relationship is rendered as a solid line with a hollow arrowhead pointing to the
parent
Realization is a semantic relationship between classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out
...

In theory, a diagram may contain any combination of things and relationships
...

Class diagrams that include active classes address the static process view
of a system
...

 These diagrams are especially important in organizing and modeling the
behaviors of a system
...

 Component diagrams address the static implementation view of a system
 They are related to class diagrams in that a component typically maps to
one or more classes, interfaces, or collaborations
Deployment diagram
 A deployment diagram shows the configuration of run-time processing
nodes and the components that live on them
 Deployment diagrams address the static deployment view of an
architecture
Rules of the UML
The UML has semantic rules for
1
...
Scope
The context that gives specific meaning to a name
3
...
Integrity
How things properly and consistently relate to one
another
5
...

For this reason, it is common for the development team to not only build models
that are well-formed, but also to build models that are
1
...
Incomplete Certain elements may be missing
3
...

1
...
Adornments
3
...
Extensibility mechanisms
Specification that provides a textual statement of the syntax and semantics of
that building block
...
A class's specification may include other details, such as whether it
is abstract or the visibility of its attributes and operations
...


Extensibility Mechanisms
The UML's extensibility mechanisms include
1
...
Tagged values
3
...

Architecture is the set of significant decisions about
The organization of a software system
The selection of the structural elements and their interfaces by which the
system is composed
Their behavior, as specified in the collaborations among those elements
The composition of these structural and behavioral elements into
progressively larger subsystems
The architectural style that guides this organization: the static and
dynamic elements and their interfaces, their collaborations, and their
composition
...


9

OOAD

III YEAR II SEM CSE

Vocabulary
AssemblyFunctionality
Design View
Configuration Mgmt

System
Implementation
View

Use case
view

Behavior

Performance
Scalability
delivery
Throughput

Process View

Deployment view

System topology
distribution
Modeling a System's Architecture

Use case view

10

installation

OOAD
III YEAR II SEM CSE
The use case view of a system encompasses the use cases that describe the
behavior of the system as seen by its end users, analysts, and testers
...

Design View
 The design view of a system encompasses the classes, interfaces, and
collaborations that form the vocabulary of the problem and its solution
...

Process View
 The process view of a system encompasses the threads and processes that
form the system's concurrency and synchronization mechanisms
...

This view primarily addresses the configuration management of the
system's releases, made up of somewhat independent components and files that
can be assembled in various ways to produce a running system
...

This view primarily addresses the distribution, delivery, and installation
of the parts that make up the physical system
...
However, to get the most benefit from
the UML, it should consider a process that is
·

Use case driven

·

Architecture-centric

·

Iterative and incremental
Use case driven means that use cases are used as a primary artifact for
establishing the desired behavior of the system, for verifying and validating the
system's architecture, for testing, and for communicating among the stakeholders
of the project
...

11

OOAD
III YEAR II SEM CSE
An iterative process is one that involves managing a stream of executable
releases
...
Together, an iterative and incremental
process is risk-driven, meaning that each new release is focused on attacking and
reducing the most significant risks to the success of the project
...
A phase is the span of time between two major milestones
of the process, when a welldefined set of objectives are met, artifacts are
completed, and decisions are made whether to move into the next phase
...


Inception is the first phase of the process, when the seed idea for the
development is brought up to the point of being at least internally sufficiently
well-founded to warrant entering into the elaboration phase
...
In this phase, the system's requirements are articulated,
prioritized, and baselined
...

Construction is the third phase of the process, when the software is brought
from an executable architectural baseline to being ready to be transitioned to the
user community
...

Transition is the fourth phase of the process, when the software is turned into
the hands of the user community
...

12

OOAD

III YEAR II SEM CSE

13

OOAD

III YEAR II SEM CSE

I-UNIT
DESCREPTIVE QUESTIONS
1
...
Compare and Contrast between Object Oriented Modeling and Conceptual
Modeling?
3
...
What does the word Unified in UML mean?
5
...
What is the use of Model Driven Architecture (MDA)?
7
...
What are the three categories of UML diagrams?
9
...


How do you show packages in a UML diagram? When working with

multiple packages, what type of relationship is most commonly shown?
11
...


How can the accessibility of the contents inside a package be

determined?
13
...
Draw the Architecture of UML ?
2
...
List the principles of UML?
4
...
Draw the notations for Classes , Interface and Packages?
6
...
Which one of the following is not principal of modeling ?

[

]

a)Choose your models well
b)Every model may not be expressed at different at different levels of
decision
c)The best models are connected to reality
...

2
...

3
...

a)general-purpose

[

b)object-purpose

]

c)architecture – purpose d)

code-purpose
4
...

a)misunderstand

b)understand

c) guide

d)misguide
...
_____ is a central past of all the activities that lead up to the deployment of
good software
...
Models tells us to _________ a system as it is (or) as we want it to be
...

7
...

a)Modular

b)object

[

]

c)procedural

d)Component
8
...
A ________ is a generic template for objects
...

[

b)Class

c)Procedure

The best models are connected to ________
...


11
...
An ______ is a class which objects own one or more processes or
threads and therefore can initiate control activity
...
An interface is rendered as ________
14
...

15
...

16
...

17
...

18
...

19
...

20
...

UNIT-1 ANSWERS
Multiple Choice
1
...
( A) 3(A) 4(B) 5( A) 6(c) 7(d) 8(A) 9(B 10(A)
Fill in the Blanks
11
...
Active class 13
...
Interface 15
...


Structural 17
...
Aggregation 19
...
has-a

16

OOAD

III YEAR II SEM CSE

UNIT – II

Class
 A class is a description of a set of objects that share the same attributes,
operations, relationships, and semantics
...

 The UML provides a graphical representation of class

Graphical Representation of Class in UML
Terms and Concepts
Names

Every class must have a name that distinguishes it from other classes
...


Simple Name

Path Name

Attributes
 An attribute is a named property of a class that describes a range of values
that instances of the property may hold
...

 An attribute represents some property of thing you are modeling that is shared
by all objects of that class
 You can further specify an attribute by stating its class and possibly a default
initial value


17

OOAD

III YEAR II SEM CSE

Attributes and Their Class
Operations
 An operation is the implementation of a service that can be requested from any
object of the class to affect behavior
...

 A class may have any number of responsibilities, although, in practice, every
well-structured class has at least one responsibility and at most just a
handful
...

 They represent the things that are important to users and to implementers

19

OOAD
III YEAR II SEM CSE
 To model the vocabulary of a system
o Identify those things that users or implementers use to describe the
problem or solution
...

o For each abstraction, identify a set of responsibilities
...

Modeling the Distribution of Responsibilities in a System



Once you start modeling more than just a handful of classes, you will want to
be sure that your abstractions provide a balanced set of responsibilities
...

o Identify a set of responsibilities for each of these classes
...

o Consider the ways in which those classes collaborate with one another,
and redistribute their
responsibilities accordingly so that no class within a collaboration does
too much or too little
...

o If you want to distinguish these things from the UML's defined building
blocks, create a new
building block by using stereotypes to specify these new semantics and
to give a distinctive
visual cue
...


Modeling Primitive Types

20

OOAD

III YEAR II SEM CSE
At the other extreme, the things you model may be drawn directly from
the programming language you are using to implement a solution
...

If you need to specify the range of values associated with this type, use
constraints
...

Graphically, a relationship is rendered as a path, with different kinds of
lines used to distinguish the kinds of relationships
In object-oriented modeling, there are three kinds of relationships that
are most important:
Dependencies
Generalizations
Associations
Dependency
A dependency is a using relationship that states that a change in
specification of one thing may affect another thing that uses it but not necessarily
the reverse
...

Most often, you will use dependencies in the context of classes to show
that one class uses another class as an argument in the signature of an operation

Dependencies

Generalization
o A generalization is a relationship between a general thing (called the super
class or parent)and a more specific kind of that thing (called the subclass or
child)
...
A child
inherits the properties of its parents, especially their attributes and operations
21

OOAD
III YEAR II SEM CSE
o An operation of a child that has the same signature as an operation in a
parent overrides the operation of the parent; this is known as polymorphism
...

o Graphically, an association is rendered as a solid line connecting the same or
different classes
...

o An instance of an association is called a link

Role Names
Multiplicity
o In many modeling situations, it's important for you to state how many objects
may be connected across an instance of an association
o This "how many" is called the multiplicity of an association's role
o You can show a multiplicity of exactly one (1), zero or one (0
...
*), or
one or more (1
...


Multiplicity
Aggregation
o Sometimes, you will want to model a "whole/part" relationship, in which one
class represents a larger thing (the "whole"), which consists of smaller things
(the "parts")
...

To model this using relationship
Create a dependency pointing from the class with the operation to the
class used as a parameter
in the operation
...

This figure shows a dependency from CourseSchedule to Course,
because Course is used in both the add and remove operations of
CourseSchedule
...
The
dependency is marked with a stereotype, which specifies that this is not a plain
dependency, but, rather, it represents a friend, as in C++
...

Elevate these common responsibilities, attributes, and operations to a more
general class
...


24

OOAD

III YEAR II SEM CSE

Inheritance Relationships
Modeling Structural Relationships







When you model with dependencies or generalization relationships, you are
modeling classes that represent different levels of importance or different
levels of abstraction
Given a generalization relationship between two classes, the child inherits
from its parent but the parent has no specific knowledge of its children
...

Associations are, by default, bidirectional; you can limit their direction
Given an association between two classes, both rely on the other in some way,
and you can navigate in either direction
An association specifies a structural path across which objects of the classes
interact
...
This is a data-driven view
of associations
...
This is more of a behavior-driven view of
associations
...




If one of the classes in an association is structurally or organizationally a
whole compared with the classes at the other end that look like parts, mark
this as an aggregation by adorning the association at the end near the whole

25

OOAD

III YEAR II SEM CSE

Common Mechanisms

Structural Relationships

Note

A note is a graphical symbol for rendering constraints or comments
attached to an element or a collection of elements
Graphically, a note is rendered as a rectangle with a dog-eared corner,
together with a textual or graphical comment
...

Graphically, a stereotype is rendered as a name enclosed by guillemets
and placed above the name of another element

26

OOAD

III YEAR II SEM CSE

Stereotypes
Tagged Values
 Every thing in the UML has its own set of properties: classes have names,
attributes, and operations; associations have names and two or more ends
(each with its own properties); and so on
...

 A tagged value is not the same as a class attribute
...

 A tagged value is an extension of the properties of a UML element, allowing
you to create new information in that element's specification
...

 In its simplest form, a tagged value is rendered as a string enclosed by
brackets and placed below the name of another element
...


27

OOAD

III YEAR II SEM CSE

Constraints
A constraint specifies conditions that must be held true for the model to be
well-formed
...


Common Modeling Techniques
Modeling Comments
The most common purpose for which you'll use notes is to write down
free-form observations, reviews, or explanations
...

To model a comment,
Put your comment as text in a note and place it adjacent to the element
to which it refers
Remember that you can hide or make visible the elements of your model
as you see fit
...

 However, if you want to extend your modeling vocabulary or give distinctive
visual cues to certain kinds of abstractions that often appear in your
domain, you need to use stereotypes
 To model new building blocks,
o Make sure there's not already a way to express what you want by
using basic UML
o If you're convinced there's no other way to express these semantics,
identify the primitive thing in the UML that's most like what you
want to model and define a new stereotype for that thing
o Specify the common properties and semantics that go beyond the
basic element being stereotyped by defining a set of tagged values
and constraints for the stereotype
...

However, if you want to extend the properties of these basic building
blocks, you need to use tagged values
...


Modeling New Properties
Modeling New Semantics
When you create a model using the UML, you work within the rules the
UML lays down
However, if you find yourself needing to express new semantics about
which the UML is silent or that you need to modify the UML's rules, then you
need to write a constraint
...


30

OOAD

III YEAR II SEM CSE

Diagrams

Modeling New Semantics



When you view a software system from any perspective using the UML, you
use diagrams to organize the elements of interest
...

 Of course, you are not limited to these nine diagrams
...
To fit the needs of your project or organization, you can
create your own kinds of diagrams to view UML elements in different ways
...

System
 A system is a collection of subsystems organized to accomplish a purpose
and described by a set of models, possibly from different viewpoints
SubSystem
 A subsystem is a grouping of elements, of which some constitute a
specification of the behavior offered by the other contained elements
...
In the context of architecture
View
 view is a projection into the organization and structure of a system's model,
focused on one aspect of that system
Diagram
 A diagram is the graphical presentation of a set of elements, most often
rendered as a connected graph of vertices (things) and arcs (relationships)
...

Class diagram
Object diagram
Component diagram
31

OOAD

III YEAR II SEM CSE
Deployment diagram
You'll often use five additional diagrams to view the dynamic parts of a system
...





Every diagram you create will most likely be one of these nine or
occasionally of another kind
Every diagram must have a name that's unique in its context so that you
can refer to a specific diagram and distinguish one from another
You can project any combination of elements in the UML in the same
diagram
...

 The UML's structural diagrams are roughly organized around the major
groups of things you'll find when modeling a system
...

 Class diagrams are the most common diagram found in modeling objectoriented systems
...

 Class diagrams that include active classes are used to address the static
process view of a system
...

 An object diagram shows a set of objects and their relationships
...

Component Diagram
 We use component diagrams to illustrate the static implementation view of
a system
...

 Component diagrams are related to class diagrams in that a component
typically maps to one or more classes, interfaces, or collaborations
...

32

OOAD
III YEAR II SEM CSE
 A deployment diagram shows a set of nodes and their relationships
...

Behavioral Diagrams

















The UML's five behavioral diagrams are used to visualize, specify,
construct, and document the dynamic aspects of a system
...

 Use case diagram
:
Organizes the behaviors of the system
 Sequence diagram
:
Focused on the time ordering of
messages
 Collaboration diagram :
Focused on the structural organization
of objects that
send and receive messages
 Statechart diagram
:
Focused on the changing state of a
system driven by
events
 Activity diagram
:
Focused on the flow of control from
activity to activity
Use Case Diagram
A use case diagram shows a set of use cases and actors and their
relationships
...

Use case diagrams are especially important in organizing and modeling the
behaviors of a system
...

A sequence diagram is an interaction diagram that emphasizes the time
ordering of messages
...

The objects are typically named or anonymous instances of classes, but
may also represent instances of other things, such as collaborations,
components, and nodes
...

A collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages
...

The objects are typically named or anonymous instances of classes, but
may also represent instances of other things, such as collaborations,
components, and nodes
...

Statechart Diagram
We use statechart diagrams to illustrate the dynamic view of a system
...

A statechart diagram shows a state machine, consisting of states,
transitions, events, and activities
...

Activity Diagram
We use activity diagrams to illustrate the dynamic view of a system
...

Activity diagrams emphasize the flow of control among objects
...

An activity shows a set of activities, the sequential or branching flow from
activity to activity, and objects that act and are acted upon
...

o As part of your process planning, decide which of these diagrams
you'll want to put under some sort of formal or semi-formal control
...


o Similarly, if yours is a client/server system, you'll probably want to
include component diagrams and deployment diagrams to model the
physical details of your system
...

34

OOAD

III YEAR II SEM CSE

• Use case view
• Design view

:
:

Use case diagrams Activity diagrams (for behavioral modeling)
* Class diagrams (for structural modeling)
* Interaction diagrams (for behavioral modeling)
* Statechart diagrams (for behavioral modeling)

• Process view

:

• Implementation view
• Deployment view

:
:

* Class diagrams (for structural modeling)
* Interaction diagrams (for behavioral modeling)
Component diagram
Deployment diagrams

Modeling Different Levels of Abstraction
 Not only do you need to view a system from several angles, you'll also find
people involved in development who need the same view of the system but
at different levels of abstraction
 Basically, there are two ways to model a system at different levels of
abstraction:
o By presenting diagrams with different levels of detail against the
same model
o By creating models at different levels of abstraction with diagrams
that trace from one model to another
...

Adornments:
 Reveal only the adornments of these building blocks and
relationships that are essential to understanding your intent
...

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



The main disadvantage of this approach is that changes from diagrams at one
level of abstraction may make obsolete diagrams at a different level of
abstraction
...

In general, populate your models that are at a high level of abstraction with
simple abstractions and your models that are at a low level of abstraction with
detailed abstractions
...

In practice, if you follow the five views of an architecture, there are four
common situations you'll encounter when modeling a system at different levels
of abstraction:

Use cases and their realization:
Use cases in a use case model will trace to collaborations in a design
model
...

Components and their design:
Components in an implementation model will trace to the elements in a
design model
...

The main advantage of the approach is that diagrams at different levels of
abstraction remain more loosely coupled
...

The main disadvantage of this approach is that you must spend resources
to keep these models and their diagrams synchronized

36

OOAD

III YEAR II SEM CSE

Interaction Diagram at a High Level of Abstraction

Interaction at a Low Level of Abstraction
* Both of these diagrams work against the same model, but at different levels of
detail
...

o If you've hidden as much detail as you can and your diagram is still
complex, consider grouping some of the elements in packages or in higher
level collaborations, then render only those packages or collaborations in
your diagram
...

o If your diagram is still complex, print it in its entirety and hang it on a
convenient large wall
...

Advanced Structural Modeling
37

OOAD

III YEAR II SEM CSE



A relationship is a connection among things
...

 Graphically, a relationship is rendered as a path, with different kinds of lines
used to distinguish the different relationships
...
Graphically, a dependency is rendered as a dashed
line
 A plain, unadorned dependency relationship is sufficient for most of the using
relationships you'll encounter
...

 There are 17 such stereotypes, all of which can be organized into six groups
...


1

bind

2

derive

3

friend

4 instanceOf

Specifies that the source instantiates the target template
using the given actual parameters
Specifies that the source may be computed from the
target
Specifies that the source is given special visibility into
the target
Specifies that the source object is an instance of the
target classifier

5 instantiate Specifies that the source creates instances of the target
Specifies that the target is a powertype of the source; a
powertype is a classifier whose objects are all the
6 powertype children of a given parent
Specifies that the source is at a finer degree of
7 refine
abstraction than the target
Specifies that the semantics of the source element
8 use
depends on the semantics of the public part of the target
bind:

bind includes a list of actual arguments that map to the formal arguments
of the template
...

friend
When you want to model relationships such as found with C++ friend
classes
...

instantiate
when you want to specify which element creates objects of another
...

use
when you want to explicitly mark a dependency as a using relationship
* There are two stereotypes that apply to dependency relationships among
packages
...


13 become
14 call
15 copy

Specifies that the target is the same object as the source
but at a later point in time and with possibly different
values, state, or roles
Specifies that the source operation invokes the target
operation
Specifies that the target object is an exact, but
independent, copy of the source

* We'll use become and copy when you want to show the role, state, or attribute
value of one object at
different points in time or space
*
You'll use call when you want to model the calling dependencies among
operations
...

* The send dependency in effect lets you tie independent state machines together
...

In a generalization relationship, instances of the child may be used
anywhere instances of the parent apply—meaning that the child is substitutable
for the parent
...
However, if you want to specify a
shade of meaning,
The UML defines one stereotype and four constraints that may be applied
to generalization relationships
...

Next, there are four standard constraints that apply to generalization
relationships

1
2
3
4

Specifies that all children in the generalization have
been specified in the model and that no additional
complete
children are permitted
Specifies that not all children in the generalization have
been specified (even if some are elided) and that
incomplete additional children are permitted
Specifies that objects of the parent may have no more
disjoint
than one of the children as a type
overlapping Specifies that objects of the parent may have more than
40

OOAD

III YEAR II SEM CSE
one of the children as a type

complete
 We'll use the complete constraint when you want to show explicitly that
you've fully specified a hierarchy in the model (although no one diagram
may show that hierarchy);
incomplete
 We'll use incomplete to show explicitly that you have not stated the full
specification of the hierarchy in the model (although one diagram may
show everything in the model)
...

 We'll use disjoint and overlapping when you want to distinguish between
static classification (disjoint) and dynamic classification (overlapping)
...

We use associations when you want to show structural relationships
...

For advanced uses, there are a number of other properties you can use
to model subtle details, such as
Navigation
Vision
Qualification
various flavors of aggregation
...

Unless otherwise specified, navigation across an association is bidirectional
...


Visibility

Navigation

41

OOAD
III YEAR II SEM CSE
 Given an association between two classes, objects of one class can see and
navigate to objects of the other, unless otherwise restricted by an explicit
statement of navigation
...

 In the UML, you can specify three levels of visibility for an association end,
just as you can for a class's features by appending a visibility symbol to a
role name the visibility of a role is public
...

 Protected visibility indicates that objects at that end are not accessible to
any objects outside the association, except for children of the other end
...
Given an object at one end of an
association, how do you identify an object or set of objects at the other end?
In the UML, you'd model this idiom using a qualifier, which is an
association attribute whose values partition the set of objects related to an object
across an association
...

42

OOAD

III YEAR II SEM CSE
However, in the context of an association with another target class, a
source class may choose to present only part of its face to the world

a Person class may realize many interfaces: IManager, IEmployee, IOfficer,
and so on
you can model the relationship between a supervisor and her workers with
a one-to-many
association, explicitly labeling the roles of this association as supervisor
and worker
 In the context of this association, a Person in the role of supervisor
presents only the IManager face to the worker; a Person in the role of
worker presents only the IEmployee face to the supervisor
...

Composition
* Simple aggregation is entirely conceptual and does nothing more than
distinguish a "whole" from a "part
...

* Parts with non-fixed multiplicity may be created after the composite itself, but
once created they live and
die with it
...

* This means that, in a composite aggregation, an object may be a part of only
one composite at a time
* In addition, in a composite aggregation, the whole is responsible for the
disposition of its parts, which
means that the composite must manage the creation and destruction of its
parts

43

OOAD

III YEAR II SEM CSE
Composition

Association Classes
* In an association between two classes, the association itself might have
properties
...

* We render an association class as a class symbol attached by a dashed line to
an association

Association Classes
Constraints
* UML defines five constraints that may be applied to association relationships
...

ordered
44

OOAD
III YEAR II SEM CSE
* For example, in a User/Password association, the Passwords associated with
the User might be kept in a
least-recently used order, and would be marked as ordered
...
Realization is sufficiently different from dependency, generalization, and
association relationships that it is treated as a separate kind of relationship
...
A realizationis a semantic relationship between classifiers in which one
classifier specifies a contract that another classifier guarantees to carry out
...
Graphically, a realization is rendered as a dashed directed line with a large
open arrowhead pointing to the classifier that specifies the contract
...
You'll use realization in two circumstances: in the context of interfaces and in
the context of collaborations
5
...
You'll also use realization to specify the relationship between a use case and
the collaboration that realizes that use case

Realization of an Interface

45

OOAD

III YEAR II SEM CSE

Realization of a Use Case
Common Modeling Techniques
Modeling Webs of Relationships
1
...

2
...
This requires you to form a balanced distribution of responsibilities in the
system as a whole, with individual abstractions that are tightly cohesive and
with relationships that are expressive, yet loosely coupled
4
...
Apply use cases and scenarios to drive your
discovery of the relationships among a set of abstractions
...
These reflect the static view of the system and are therefore
fairly tangible
...

 Only after completing the preceding steps should you look for
dependencies; they generally represent more-subtle forms of semantic
connection
...

 Remember that it is both undesirable and unnecessary to model all
relationships among a set of abstractions in a single diagram or view
...
Highlight interesting sets of relationships in
individual diagrams
...

role
 A role is the behavior of an entity participating in a particular context
...

Names
 Every interface must have a name that distinguishes it from other interfaces
...
That name alone is known as a simple name;
 A path name is the interface name prefixed by the name of the package

Simple and Path Names

Operations
 An interface is a named collection of operations used to specify a service of a
class or of a component
...

 you can render an interface as a stereotyped class, listing its operations in the
appropriate compartment
...
In addition, an interface may participate in
realization relationships
...
A class or component may realize many interfaces
 We can show that an element realizes an interface in two ways
...

o 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 other properties, and then
draw a realization
relationship from the classifier or component to the interface
...



First, you may attach pre- and postconditions to each operation and
invariants to the class or component as a whole
...




We can attach a state machine to the interface
...




We can attach collaborations to the interface
...


48

OOAD

III YEAR II SEM CSE

Types and Roles
A role names a behavior of an entity participating in a particular context
...

For example, consider an instance of the class Person
...
When an
object plays a particular role, it presents a face to the world, and clients that
interact with it expect a certain behavior depending on the role that it plays at the
time
...

In the UML, you can specify a role an abstraction presents to another
abstraction by adorning the name of an association end with a specific interface
...
You can model the dynamic binding of an
abstraction to its interface by using the become stereotype in an interaction
diagram, showing an object changing from one role to another
...
The concept of type is closely related to that of interface, except that
a type's definition may include attributes while an interface may not
...


49

OOAD
III YEAR II SEM CSE
 Identifying the seams in a system involves identifying clear lines of
demarcation in your architecture
...
dll) drawn from a financial system
...
In this diagram, IUnknown is
shown in its expanded form; the other two are shown in their simple form, as
lollipops
...
dll and are exported to
other components for them to build on
...
dll imports two interfaces, IStreaming and
ITransaction, the latter of which is shown in its expanded form
...
dll component for its proper operation
...

By identifying interfaces such as ITransaction, you've effectively decoupled the
components on either side of the interface, permitting you to employ any
component that conforms to that interface
...

Even so, that object will likely play different roles over time
...

However, when you are modeling things like business objects, which naturally
change their roles throughout a workflow,
To model a dynamic type

50

OOAD
III YEAR II SEM CSE
o Specify the different possible types of that object by rendering each type
as a class stereotyped as
type (if the abstraction requires structure and behavior) or as interface
(if the abstraction requires
only behavior)
...
You
can do so in two ways:
1
...
Doing this specifies the face instances of that class
put on in the context of the
associated object
...
) Second, also in a class diagram, specify the class-to-type
relationships using generalization
...
Display
the role of the instance in brackets below the object's name
...


Modeling Static Types

Modeling Dynamic Types

Package
“A package is a general-purpose mechanism for organizing elements into groups
...

Names
51

OOAD




III YEAR II SEM CSE

Every package must have a name that distinguishes it from other packages
...

That name alone is known as a simple name; a path name is the package
name prefixed by the name of the package in which that package lives
We may draw packages adorned with tagged values or with additional
compartments to expose their details
...

Owning is a composite relationship, which means that the element is
declared in the package
...

Every element is uniquely owned by exactly one package
...

Thus, you can have a class named Timer, as well as a component named Timer,
within the same package
...
This means that it's possible to
decompose your models hierarchically
...


52

OOAD

III YEAR II SEM CSE
Owned Elements

Visibility
You can control the visibility of the elements owned by a package just as
you can control the visibility of the attributes and operations owned by a class
...

Conversely, protected elements can only be seen by children, and private
elements cannot be seen outside the package in which they are declared
...

Importing and Exporting
In the UML, you model an import relationship as a dependency adorned
with the stereotype import
Actually, two stereotypes apply here—import and access— and both
specify that the source package has access to the contents of the target
...

The parts that one package exports are visible only to the contents of
those packages that explicitly import the package
...
A specialized package (such as
WindowsGUI) can be used anywhere a more general package (such as GUI) is
used

Generalization Among Packages

Standard Elements
o All of the UML's extensibility mechanisms apply to packages
...

o The UML defines five standard stereotypes that apply to packages
1
...

framework
3
...

subsystem
5
...

54

OOAD

III YEAR II SEM CSE
There is one important distinction between classes and packages:
Packages have no identity (meaning that you can't have instances of
packages, so they are invisible in the running system);
classes do have identity (classes have instances, which are elements of a
running system)
...

Surround each of these clumps in a package
...
Mark them public, and all others protected or private
...

Explicitly connect packages that build on others via import dependencies
In the case of families of packages, connect specialized packages to their
more general part via generalizations
Modeling Architectural Views
o We can use packages to model the views of an architecture
...

o This definition has two implications
...
( design view, a process view, an implementation view, a
deployment view, and a use case view)
o Second, these packages own all the abstractions germane to that
view
...
In
practice, this typically includes a design view, a process view, an
implementation view, a
deployment view, and a use case view
...

o As necessary, further group these elements into their own packages
...
So, in general, let each
view at the top of a system be open to all others at that level
...

Graphically, an instance is rendered by underlining its name
...
To
indicate an instance, you underline its name
...


56

OOAD

III YEAR II SEM CSE
Named, Anonymous, Multiple, and Orphan Instances

Names




Every instance must have a name that distinguishes it from other instances
within its context
...

A name is a textual string
...
or it
may be a path name

Operations



The operations you can perform on an object are declared in the object's
abstraction
For example, if the class Transaction defines the operation commit, then given
the instance t : Transaction, you can write expressions such as t
...
An object's state is therefore dynamic
...

It's possible to show the changing state of an object by showing it
multiple times in the same interaction diagram, but with each occurrence
representing a different state
...

57

OOAD

III YEAR II SEM CSE
You can declare active classes that reify a process or thread, and in turn
you can distinguish an instance of an active class

Active Objects




There are two other elements in the UML that may have instances
The first is a link
...
An instance
of an association is therefore a link
...
A class-scoped feature is
in effect an object in the class that is shared by all instances of the class
...
Usually, however,
you don't stereotype an instance directly, nor do you give it its own tagged
values
...


Stereotyped Objects
The UML defines two standard stereotypes that apply to the dependency
relationships among objects and among classes:
1
...

instantiate

Specifies that the client object is an instance of the
supplier classifier
Specifies that the client class creates instances of the
supplier class

There are also two stereotypes related to objects that apply to messages and
transitions:

58

OOAD
III YEAR II SEM CSE
1
...
copy
Specifies that the client object is an exact but independent
copy of the supplier
The UML defines a standard constraint that applies to objects:
transient
Specifies that an instance of the role is created during
execution of the enclosing interaction but is destroyed
before completion of execution
Common Modeling Techniques
Modeling Concrete Instances




When you model concrete instances, you are in effect visualizing things that
live in the real world
One of the things for which you'll use objects is to model concrete instances
that exist in the real world
To model concrete instances,


Identify those instances necessary and sufficient to visualize, specify,
construct, or document the problem you are modeling
...
Where possible, give each
object a name
...




Expose the stereotype, tagged values, and attributes (with their values) of
each instance necessary and sufficient to model your problem
...


59

OOAD

III YEAR II SEM CSE

Modeling Concrete Instances
Modeling Prototypical Instances
 Perhaps the most important thing for which you'll use instances is to model
the dynamic interactions among objects
...

 These are prototypical objects and, therefore, are roles to which concrete
instances conform
...

 Prototypical objects appear in such places as interaction diagrams and
activity diagrams
...

 Render these objects in the UML as instances
...
If there is no meaningful name for the object, render it as
an anonymous object
...

 Render these instances and their relationships in an interaction diagram
or an activity diagram
...


60

OOAD

III YEAR II SEM CSE

Classes and Object Diagrams



Class Diagrams
A class diagram shows a set of classes, interfaces, and collaborations and
their relationships
...


Common Properties
Contents
 Class
o
o
o
o



diagrams commonly contain the following things:
Classes
Interfaces
Collaborations
Dependency, generalization, and association relationships

Like all other diagrams, class diagrams may contain notes and constraints
Class diagrams may also contain packages or subsystems

Note: Component diagrams and deployment diagrams are similar to class
diagrams, except that instead of containing classes, they contain components
and nodes
Common Uses
o You use class diagrams to model the static design view of a system
...
To model the vocabulary of a system
2
...
To model a logical database schema
Modeling the vocabulary of a system
o Modeling the vocabulary of a system involves making a decision about which
abstractions are a part of the system under consideration and which fall
outside its boundaries
Modeling simple collaborations

61

OOAD
III YEAR II SEM CSE
o A collaboration is a society of classes, interfaces, and other elements that work
together to provide some cooperative behavior that's bigger than the sum of all
the elements
...

Common Modeling Techniques
Modeling Simple Collaborations
o When you create a class diagram, you just model a part of the things and
relationships that make up your system's design view
...

o To model a collaboration
o Identify the mechanism you'd like to model
...

o For each mechanism, identify the classes, interfaces, and other
collaborations that participate in this collaboration
...

o Use scenarios to walk through these things
...

o Be sure to populate these elements with their contents
...
Then, over time, turn these
into concrete attributes and operations
...

o The UML's class diagrams are a superset of entity-relationship (E-R) diagrams,
Whereas classical E-R diagrams focus only on data, class diagrams go a step
further by permitting the modeling of behavior, as well
...

o To model a schema,
o Identify those classes in your model whose state must transcend the
lifetime of their applications
...
You can define your own set of tagged
values to address database-specific details
...
In general, this means
specifying the details of their attributes and focusing on the associations
and their cardinalities that structure these classes
...

Where necessary, create intermediate abstractions to simplify your logical
structure
...
In general, to provide a
better separation of concerns, business rules concerned with the
manipulation of sets of these objects should be encapsulated in a layer
above these persistent classes
...


63

OOAD

III YEAR II SEM CSE

Modeling a Schema
Forward and Reverse Engineering
o Forward engineering is the process of transforming a model into code
through a mapping to an implementation language
o Forward engineering results in a loss of information, because models written
in the UML are semantically richer than any current object-oriented
programming language
...
This is something you'll want to do for your project or
your organization as a whole
...
For example, the UML permits
you to model multiple inheritance, but Smalltalk permits only single
inheritance
...

o Use tagged values to specify your target language
...
You can also do so at
a higher level, such as with collaborations or packages
...


64

OOAD

III YEAR II SEM CSE

Forward Engineering






Reverse engineering is the process of transforming code into a model through
a mapping from a specific implementation language
...

Reverse engineering is incomplete
...

To reverse engineer a class diagram,
o Identify the rules for mapping from your implementation language or
languages of choice
...

o Using a tool, point to the code you'd like to reverse engineer
...

o Using your tool, create a class diagram by querying the model
...

Expose or hide details of the contents of this class diagram as necessary
to communicate your intent
...

Graphically, an object diagram is a collection of vertices and arcs
65

OOAD
III YEAR II SEM CSE
 An object diagram is a special kind of diagram and shares the same common
properties as all other diagrams—that is, a name and graphical contents that
are a projection into a model
Contents
 Object diagrams commonly contain
 Objects
 Links
 Like all other diagrams, object diagrams may contain notes and constraints
...

 An object diagram represents one static frame in the dynamic storyboard
represented by an interaction diagram
Common Modeling Techniques
Modeling Object Structures
 An object diagram shows one set of objects in relation to one another at one
moment in time
...
A mechanism represents some
function or behavior of the part of the system you are modeling that results
from the interaction of a society of classes, interfaces, and other things
...




Consider one scenario that walks through this mechanism
...




Expose the state and attribute values of each such object, as necessary, to
understand the scenario
...

66

OOAD

III YEAR II SEM CSE

Modeling Object Structures
Forward and Reverse Engineering
 Forward engineering an object diagram is theoretically possible but
pragmatically of limited value
 In an object-oriented system, instances are things that are created and
destroyed by the application during run time
...

 Component instances and node instances are things that live outside the
running system and are amenable to some degree of forward engineering
...
Typically, you'll set your
context inside an operation or relative to an instance of one particular
class
...




Identify the set of interesting objects that collaborate in that context and
render them in an object diagram
...


67

OOAD
III YEAR II SEM CSE
 As necessary to understand their semantics, identify the links that exist
among these objects
...
If your diagram is too simplistic, expand the neighbors of certain
interesting objects and expose each object's state more deeply
...
Define the terms:
a) Classes
b) Interface
c) Packages
2
...
List various types of relationships?
4
...
How do you show packages in a UML diagram?
6
...
What are the two elements that are most commonly collected into packages?
8
...
What is the standard notation for specifying the diagrams inside a package?
10
...

12
...

14
...


Short Questions

1
...
What are associations?
3
...
What is an interface?
5
...
Draw the notations for Classes , Interface and Packages?
7
...
List various types of relationships?
9
...
What is an Object diagram?
11
...
Define the terms:
A) Classes
B) Interface
C) Packages
2
...
When working with multiple packages, what type of relationship is most
commonly shown?
4
...
How can the accessibility of the contents inside a package be determined?
6
...
How do you document inheritance in UML?
8
...
Which on of the following is grouping thing?
[
]
a) Class
b)Package
c)Use Case
d) Collaboration
2
...

[
]
a)Active class
b)Abstract class c)Alternate class d)Interface
class
3
...
An ______ is a collection of operations that specify a service of a class or
component
...
___________ helps us in protecting privacy of Objects
...
______ things are the names of UML models
...
__________ things are the dynamic parts of UML models
...
________ is a special kind of association, representing a structural
relationship between a whole and its parts
...
A _________ relationship is rendered as a solid line with a hollow arrow
head pointing to the parent
...
Aggregation is a __________ kind of relationship
...
A _________ is a contract or an obligation of a class
...
A __________ is just the face the class at the neor end of the association
presents to the other end of the association
...
An _________ is a named property of a class that describes a range of values
that instance of the property may held
...
A _________ is a description of a set of objects that store the same
attributes , operations ,relationships & semantics
...
An _________ is a named property of a class that describes a range of
values that instance of the property may held
...
You use ________ diagrams to illustrate data structures , the static
snapshots of instances of the things found in class diagrams
...
Name:string_________________
...
C)head:*item
...
1J : string
...
Notes may be attached to more than one element by using _____
[
]
A)associations
B)dependences
C) generalizations
D) aggregations
19
...

A)+

B)#

C)-

[

]

D)I

20
...
A _____________is a semantic relationship between two things in which a
change to one thing
22
...

23
...

24
...

25
...

26
...

27
...
_______diagrams do a better job of visualizing complex iteration and
branching and of
visualizing multiple concurrent flow of control than
do sequence diagrams
...
___________ is defined as that you can take one and transform it into the
other without loss
of information
30
...
GENERALIZATION, 21
...
REALIZATION, 23) NINE,
24) MULTIPLICITY, 25) SELF , 26)
...


71



---