Академический Документы
Профессиональный Документы
Культура Документы
Chapter 1
1.1 INTRODUCTION
S
ystems development refers to all activities that go into producing an information systems solution.
Systems development activities consist of systems analysis, modeling, design, implementation, testing
and maintenance.
A software development methodology is a series of processes that, if followed, can lead to the
development of application . This software processes describe how the work is to be carried out to
achieve the original goal based on the system requirements. furthermore, each process consists of a
number of steps and rules that should be performed during development. This software development
process will continue to exist as long as the development system is in operation.
1.2 OBJECTIVES
At the end of this unit, You would be able to:
Object oriented system development methods differ from traditional development techniques in that
the traditional techniques view software as a collection of programs or functions and isolated data.
What is computer programming? Niklas Wirth sums it up eloquently in the title of his book : Algorithms
+ Data = Programs. To put it another way, “A Software system is a set of mechanisms for performing
certain actions on certain data.” This means that there are two orthogonal (yet complementary) ways to
view software construction: we can focus primarily on the functions or primarily on the data. The heart of
the distinction between traditional structured design methodologies and newer object-oriented methodologies
lies in this primary focus. Structured Design techniques center on the functions of the system: “What is it
doing”; Object-oriented techniques centers on the object, which combines data and functionality of the
system: “What is being done to”. As we will see, this seemingly simple shift in focus radically changes the
process of software design, analysis and construction.
An object orientation produces systems that are easier to evolve, more flexible, more robust, and more
reusable than a top-down structure approach.
High-quality software provides users with an application that meets their needs and expectations.
Four quality measures : correspondence, correctness, verification , and validation. Correspondence
measures how well the delivered system corresponds to the needs of the problem. Correctness determines
whether or not the system correctly computes the results based on the rules created during the system
analysis and design , measuring the consistency of product requirements with respect to the design
specification. Verification is the task of determining correctness (am I building the product right?).
Validation is the task of predicting correspondence (am I building the right product?).
MSIT 41 OOAD with UML 3
Validation
verification
correctness
correspondence
Fig.1.1: Four quality measures for software evaluation
Quality in software can be measured by external characteristics (e.g. easy to use, runs fast) or internal
characteristics (e.g. modular design, readable code). The external metrics are the only ones that really
matter in the end. No one really cares if you used a good modular design to construct your software, they
just care that it runs well. However, since the internal (hidden) metrics are key to producing the external
ones, both must be taken into account during the course of software design and construction.
Reusable Can be used in systems other than the one for which was created
Compatible Can be used easily with other software
The above attributes are the ones which benefit most when switching from structured to object
oriented approach. Also software needs to be easy-to-use, portable and verifiable.
software model for the initial requirements of a system. But as that system changes and new requirements
are added, the functional architecture becomes more and more unwieldy. Because the software is designed
around a relatively fixed tree structure, changes usually require extensive pruning and grafting.
1.7 SUMMARY
l Algorithms + Data structures = Programs
m Correct
6 Chapter 1 - Structured Approach Vs. Object Oriented Approach
m Robust
m Extendible
m Reusable
m Compatible
2. Software is the term associated with the _________ that are written to manage the various _______ of a
computer system and perform certain designated useful tasks. Software can be further classified into ________
and _______.
3. Two orthogonal (yet complementary) ways to view software construction: we can focus primarily on the
_________ or primarily on _____.
a. Functions
b. Algorithms
c. Objects
b. Reusable, Compatible
Chapter 2
2.0 INTRODUCTION
O
bject-Oriented technology is built upon a sound engineering foundation, whose elements are
collectively called the object model. The object model encompasses the principles of abstraction,
encapsulation, modularity, hierarchy , typing , concurrency, and persistence. The Object-Oriented
analysis and design is fundamentally different from traditional structured design approaches; it requires a
different method of thinking about decomposition, and it produces software architectures that are largely
outside the realm of the structured design culture. These differences arise from the fact that structured
design methods build upon structured programming whereas object-oriented design builds upon object-
oriented programming.
2.1 OBJECTIVES
At the end of this unit, You would be able to:
l Define the OOA, OOD, OOP
Object-oriented programming can be called as a new programming paradigm that will help us develop
software that is more reliable, easily maintainable and reusable. The three fundamental units of Object-
oriented programming are objects, methods and messages.
The essence of Object-oriented Analysis and Design is to emphasize considering a problem domain
and logical solution from the perspective of objects (things, concepts, or entities) as shown in figure below.
During Object-oriented Analysis ,there is an emphasis on finding and describing the objects-or
concepts-in the problem domain. For example ,in the case of the library information system, some of the
concepts include books ,library and patron.
MSIT 41 OOAD with UML 11
During Object-oriented design ,there is an emphasis on defining logical software Objects that will
ultimately be implemented in an Object-oriented programming language. These software objects have
attributes and methods. To illustrate, in a library system , a book software object may have a title attribute
and a print method (see figure below).
Book
title
- Lower-level objects are identified during design reusing existing object descriptions where
appropriate.
- Objects are implemented as software structures (e.g., C++ or Java classes) during coding.
l Encapsulation
l Modularity
l Hierarchy
2.4.1 Abstraction
An abstraction denotes the essential characteristics of an object that distinguishes it from all other
kinds of objects and thus provide crisply-defined, conceptual boundaries, relative to the perspective of the
viewer; the process of focusing upon the essential characteristics of an object. Abstraction is one of the
fundamental elements of the object model.
Three types of abstraction are
- Entity abstraction - an object that represents a useful model of a problem or solution domain
- Virtual machine abstraction - an object that groups together operations that are used by some
superior/junior level of control
- Coincidental abstraction - an object that packages a set of operations that have no relation to
each other.
O O M odel
E n c a p su la tio n H ie ra rc h y
Fig.2.3
Abstraction is one of the fundamental ways that we as humans cope with complexity. A good abstraction
is one that emphasizes details that are significant to the reader or user and suppresses details that are,
at least for the moment, immaterial or diversionary.
A abstraction focuses on the outside view of an object, and so serves to separate an object’s essential
MSIT 41 OOAD with UML 13
behavior from its implementation. Deciding upon the right set of abstractions for a given domain is the
central problem in object-oriented design. There is a spectrum of abstraction, from objects which closely
model problem domain entities to objects which really have no reason for existence
2.4.2 Encapsulation
Abstraction focuses on the observable behavior of an object ,whereas encapsulation focuses on the
implementation that gives rise to that behavior and this is achieved through information hiding
Encapsulation is the process of compartmentalizing the elements of an abstraction that constitutes its
structure and behavior and serves to separate the contractual interface of an abstraction and its
implementation
Abstraction and encapsulation are complementary concepts. Abstractions focus upon the observable
behavior of an object, whereas encapsulation is most often achieved through information hiding, which is
the process of hiding all the secrets of an object that do not contribute to its essential characteristics.
Typically, the structure of an object is hidden, as well as the implementation of its methods.
Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation
of concerns. In designing database applications, it is a standard practice to write programs so that they
don’t care about the physical representation of data, but only depend upon a schema that denotes the
data’s logical view. In this sense, the objects at one level of abstraction are shielded from implementation
details at lower levels of abstraction.
For abstraction to work, implementation must be encapsulated. In practice, this means that each class
must have two parts: an interface and an implementation. The interface of a class captures only its
outside view, encompassing abstraction of the behavior common to all instances of the class. The
implementation of a class comprises the representation of the abstraction as well as the mechanisms that
achieve the desired behavior.
Intelligent encapsulation localizes design decisions that are likely to change. As a system evolves, its
developers might discover that in actual practice, certain operations take longer than acceptable or that
some objects consume more space than is available. In such situations, the representation of an object is
often changed so that more efficient algorithms can be applied or so that one can optimize for space by
calculating rather than storing certain data. This ability to change the representation of an abstraction
without distributing any of its clients is the essential benefit of encapsulation.
- Each interface often specifies only a limited part of the behavior and they do not have implementation;
they lack attributes, states, or associations; they only have operations
- The implementation of a class is its inside view , which encompasses the secrets of its behavior. The
implementation of a class primarily consists of the implementation of all of the operations defined in the
interface of the class.
Interface specify the externally-visible operations of a class, component, or other entity (including
summarization units such as packages) without specification of internal structure. Each interface often
specifies only a limited part of the behavior of an actual class. Interfaces do not have implementation;
they lack attributes, states, or associations; they only have operations. Interfaces may have generalization
relationships. An interface is formally equivalent to an abstract class with no attributes and no methods
and only abstract operations, but interface is a peer of class.
l Protected A declaration that is accessible only to the class itself, its subclasses, and its
friends
l Private A declaration that is accessible only to the class itself and its friends
2.4.3 Modularity
l Modularization consists of dividing a program into modules which can be compiled separately,
but which have connection with other modules
l The connections between modules are the assumptions which the modules make about each
other
l Cohesion is the interdependency within a module and coupling is the dependency between
modules
components” and this can reduce its complexity to some degree. Although partitioning a program is that
it creates a number of well-defined, documented boundaries within the program some languages do not
provide modules and class is the only physical unit for decomposition.
Modules serve as the physical containers in which we declare the classes and objects of our logical
design. This is no different than the situation faced by the electrical engineer designing a board-level
computer. NAND, NOR, and NOT gates might be used to construct the necessary logic, but these gates
must be physically packaged in standard integrated circuits, such as a 7400, 7402, or 7404.
The principles of abstraction, encapsulation, and modularity are synergistic. An object provides a crisp
boundary around this abstraction.
Two additional technical issues can affect modularization decisions. First, since modules usually serve
as the elementary and indivisible units of software that can be reused across applications, a developer
might choose to package classes and objects into modules in a way that makes their reuse convenient.
Second, many compilers generate object code in segments, one for each modules. Therefore, there may
be practical limits on the size of individual modules.
2.4.4 Hierarchy
l Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the understanding
of our problem
CLASS OBJECT
STRUCTURE STRUCTURE
“is a” “part of “
hierarchy hierarchy
16 Chapter 2 - The Object Model
l Inheritance is an important “is-a” hierarchy and defines relationships among classes, wherein
one class shares the structure and behavior defined in another class
l A subclass typically redefines or augments the existing structure and behavior of its superclasses
Bank
Account
Fig.2.4
Inheritance is a relationship among classes, wherein one class shares the structure or behavior defined
in one (single inheritance) or more (multiple inheritance) other classes.
There is a healthy tension among the principles of abstraction, encapsulation, and hierarchy. Data
abstraction attempts to provide an opaque barrier behind which methods and state are hidden; inheritance
requires opening this interface to some extent and may allow state as well as methods to be accessed
without abstraction. For a given class there are usually two kinds of clients: objects that invoke operations
upon instances of the class, and subclasses that inherit from the class.
With Inheritance encapsulation can be violated in three ways as in the slide. Different languages trade
off support for encapsulation and inheritance in different ways. For example, the interface of a C++ class
may have three parts: private parts, which declare members that are accessible only to the class itself,
protected parts, which declare members that are accessible only to the class and its subclasses, and
public parts, which are accessible to all clients.
Abstract Class
l An Abstract Class is a class that is used only as a base class for other classes or subclasses
l We do not (need not, or even cannot) Instantiate from an abstract class
l Abstract class is introduced to make it possible to store a set of attributes and methods common
to several classes in one place
l Typically defined to provide interfaces for significant operations
It might be the case that a superclass defines some operations without providing the methods for the
operations. Operations without methods are called abstract operations. A Class that has at least one
abstract operation is called an abstract class. An abstract class cannot be instantiated, but may only be
inherited. A specialization of an abstract class is expected to provide the methods necessary for abstract
operations in its superclass.
For example, if the operations toss and catch in the class ball come without methods, then a subclass,
such as football must provide the methods for those operations.
18 Chapter 2 - The Object Model
A class without abstract operations is called a concrete class. Concrete classes may be instantiated
or inherited. The lowest level subclasses in an inheritance hierarchy (called leaf classes) must be concrete.
In some cases, the designer of a class might not want that class to be inherited, even though the class is
concrete. In such cases, the class may be designated a final class by the designer. Final classes are leaf
classes that can be instantiated but that cannot be inherited.
Motor vehicle
Utility Vehicle
Multiple inheitance
Utilityvehical inherits from the car and
truck classes.
Fig. 2.5
Many, but not all languages support multiple inheritance. Multiple inheritance enables a subclass to
specialize (or inherit the properties) from more than one superclass. For example, Java does not support
multiple inheritance (except through the inheritance of interfaces), while Smalltalk does.
GardeningPlan Plant
• GardeningPlan is “part of” Garden
• Plant is “part of” Garden
• Garden “has a” GardeningPlan
• Garden “has a” Plant Question of
Ownership?
Fig. 2.6
Delegation
l Inheritance leads to a strong dependency of the subclass on the superclass
Inheritance leads to a strong dependency of the subclass on the superclass. Changes in the superclass
(or in some superclass within the inheritance path) can require changes in the subclass; and yet, the
designer of a subclass might not have visibility into changes being made higher in the inheritance hierarchy.
Delegation provides an alternative to inheritance. In delegation, an object might respond to an operation
on itself by invoking a service in another object.
l Concurrency
l Persistence
20 Chapter 2 - The Object Model
2.5.1 Typing
l A type is a precise characterization of structural or behavioral properties which a collection of
entities share
1. Smalltalk is untyped
2. C++ is a bit of hybrid; it is strongly typed, but one can ignore or suppress typing rules
l Strong typing has its advantages in enforcing design decisions relevant when complexity grows
but has its weaknesses also
Typing is the enforcement of the class of an object, such that objects of different types may not be
interchanged, or at the most, they may be interchanged only in very restricted ways.
The concept of a type derives primarily from the theories of abstract data types. A type is a precise
characterization of structural of behavioral properties which a collection of entities all share. Although the
concept of a type and a class are similar, we include typing as a separate element of the object model
because the concept of type places a very different emphasis upon the meaning of abstraction.
Typing lets us express our abstraction so that the programming language in which we implement them
can be made to enforce design decisions.
The idea of conformance is central to the notion of typing. For example, consider units of measurement
in physics. When we divide distance to time, we expect some value denoting speed, not weight. Similarly,
multiplying temperature by a unit of force doesn’t make sense, but multiplying mass by force does. These
are both examples of strong typing where the rules of our domain prescribe and enforce certain legal
combinations of abstractions.
A given programming language may be strongly typed, weakly typed, or even untyped, yet still be
called object-oriented.
Strong typing lets us use our programming language to enforce certain design decision, and so is
particularly relevant as the complexity of our system grows. However, there is a dark side to strong
typing. Particularly, strong typing introduces semantic dependencies such that even small changes in the
interface of a base class require recompilation of all subclasses.
l Static typing refers the time when names are bound to types; also known as early binding
l Static binding means that the types of all variables and expressions are fixed at compile time
l Dynamic binding means that the types of all variables and expressions are not known until
runtime; also known as late binding
The concepts of strong typing and static typing are entirely different. Strong typing refers to type
consistency. Whereas static typing- also known as static binding or early binding - refers to the time
when names are bound to types. Static binding means that the types of all variables and expressions are
fixed at the time of compilation; dynamic binding (also called late binding ) means that the types of all
types of all variables and expressions are not known until runtime. Because strong typing and binding are
independent concepts a language may be both strongly and statically typed (Ada), strongly typed yet
support dynamic binding (Object Pascal and C++), or untyped yet support dynamic binding (Smalltalk).
l Power of polymorphism
Polymorphism represents a concept in type theory in which a single name (such as variable declaration)
may denote objects of many different classes that are related by some common superclass. Any object
denoted by this name is therefore able to respond to some common set of operations.
Polymorphism exists when the features of inheritance and dynamic binding interact. It is perhaps the
most powerful feature of object-oriented programming languages next to their support for abstraction.
Polymorphism is also a central concept in object-oriented design.
Polymorphism (or many forms) enables a class within an inheritance hierarchy to be represented
simultaneously as itself and as any superclass within its inheritance hierarchy. For example, a Square is
also a Rectangle, which is also a Polygon.
In general, even when an object is associated with a type that is one of its superclasses, an object-
oriented language can still determine the leaf-level class of the object. For example, consider the case
where a Square is a Rectangle is a Polygon. Whenever a Square is assigned to a type that is a Polygon,
the run-time system will still be able to recognize that the object is a Square. The same is true for an object
of class Rectangle.
22 Chapter 2 - The Object Model
Overriding vs Overloading
l Overriding
l Overloading
An operation will have various unique signatures
Whenever an operation is redefined with a method within a subclass, the method of the redefined
operation is said to override the method in the superclass. For example, a class Polygon might have a
default method to compute its perimeter. In the subclass Rectangle, a new method can be provided for the
operation perimeter because a Rectangle exhibits certain constraints that enable the perimeter to be
determined more efficiently.
When a subclass does not override the method for an operation, the method is inherited. For example,
if a class, Square, is a subclass of Rectangle, then the Square class could inherit the method provided by
Rectangle for the operation perimeter (since Square contains the same constraints as the Rectangle).
Whenever a Polygon is neither a Rectangle nor a Square, then the default method for computing the
perimeter is used.
The run-time system in an object-oriented language will sort out the various methods so that the most
refined (that is, the lowest level) method will be used when available. This occurs because, when an
operation is invoked on an object, the run-time system begins searching for a method that implements the
operation at a leaf object and moves up one level at a time when no method is found, until a method is
found. When no method can be found for an operation, then a run-time error is declared. In order to
override an operation, the subclass declares the operation with an signature identical to that defined in the
superclass.
In addition to being overridden, operations can also be overloaded. Most languages allow constructors
to be implemented using overloading. For example, a constructor for a class Rectangle might be defined
MSIT 41 OOAD with UML 23
as a set of six methods, where each method is named Rectangle. What sets these methods apart is the
fact that each method has a unique signature (that is, a different number and/or type of parameters and/
or a different return type). For example, one constructor might contain no parameters; thus, instantiating
a Rectangle with a default set of parameters. Other constructors might allow a Rectangle to be created
with various parameters specified. In such a case, the constructor operation, Rectangle, is said to be
overloaded.
Overloading can occur within a single class, as well as among subclasses within an inheritance hierarchy.
Because the various signatures for an overloaded operation are unique, the proper method can be determined
at compile-time.
2.5.2 Concurrency
l Are concurrency and simultaneity the same?
For certain kinds of problems, an automated system may have to handle many different events
simultaneously, Other problems may involve so much computation that they exceed the capacity of any
single processor. In each of this cases, it is natural to consider using a distributed set of computer for the
target implementation or to use processing capable of multitasking. A single process-also known as thread
of control is capable of multitasking. A single process - also known as a thread of control is the root
from which independent dynamic action occurs within a system. Every program has at least one thread of
control, but a system involving concurrency may have many such threads: Some that are transitory , and
others that last the entire lifetime of the system’s execution. Systems executing across multiple CPUs
allow for truly concurrent threads of control, whereas systems running on a single CPU can only achieve
the illusion of concurrent threads of control, usually by means of some time-slicing algorithm.
24 Chapter 2 - The Object Model
We also distinguish between heavy weight and light weight concurrency. A heavy weight process is
one that is typically independently managed by the target operating system, and so encompasses its own
address space. A light weight process usually lives within a single operating system process along with
other lightweight processes, which share the same address space. Communication among heavyweight
processes is generally expensive, lightweight processes is less expensive, and often involves shared data.
Whereas object-oriented programming focuses upon data abstraction, encapsulation, and inheritance,
concurrency focuses upon process abstraction and synchronization. An object is a concept that unifies
these two different perspectives and such objects are called active. In a system based on an object-
oriented design, we can conceptualize the world as consisting of a set of a co-operative objects, some of
which are active and thus serve as centers of independent activity.
2.5.3 Persistence
l Lifetimes of objects range from “transitory” to “semi-permanent” beyond execution of a program
An object in software takes up some amount of space and exists for a particular amount of time.
There is a continuum of object existence, ranging from transitory objects that arise within the evaluation
of an expression, to objects in a database that outlive the execution of a single program.
Traditional programming languages usually address only the first three kinds of object persistence;
persistence of the last two kinds is typically the domain of database technology.
This leads to a clash of cultures that sometimes results in very strange architectures. The programmer
ends up crafting ad hoc schemes for storing objects whose state must be preserved between program
executions, and database designers misapply their technology to cope with transient objects.
l Offers the programmers of database systems the abstraction power of object technology
MSIT 41 OOAD with UML 25
Unifying the concepts of concurrency and objects gives rise to concurrent object-oriented programming
languages. In a similar fashion, introducing the concept of persistence to the object model gives rise to
object-oriented databases. In practice, such databases build upon proven technology, such as sequential,
indexed, hierarchical, network, or relational database models, but then offer to the programmer the
abstraction of an object-oriented interface, through which database queries and other operations of an
object-oriented interface, are completed in terms of objects whose lifetime transcends the lifetime of an
individual program.
Very few object-oriented programming languages provide direct support for persistence. Smalltalk is
one notable exception, wherein there are protocols for streaming objects to and from disk (which must be
redefined by subclasses). However, streaming objects to flat files is a naive solution to persistence that
does not scale well. More commonly, persistence is achieved trough a modest number of commercially
available object-oriented databases. Another reasonable approach to persistence is to provide an object-
oriented skin over a relational database.
Recap
Abstraction is a good thing, but in all except the work trivial applications, we may find many more
different abstractions than we can comprehend at one time.
Encapsulation helps manage this complexity by hiding the inside view of our abstractions.
Modularity helps also, by giving us a way to cluster logically related abstractions. Still, this is not
enough.
A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, we
greatly simplify our understanding of the problem.
2.6 SUMMARY
l Object-oriented system development consists of
Object-oriented analysis
Object-oriented design
26 Chapter 2 - The Object Model
Abstraction
Encapsulation
l Encapsulation is the process of compartmentalizing the elements of an abstraction that
constitutes its structure and behavior and serves to separate the contractual interface of an
abstraction and its implementation
Modularity
l Modularization consists of dividing a program into modules which can be compiled separately,
but which have connection with other modules
l The connections between modules are the assumptions which the modules make about each
other
l Cohesion is the interdependency within a module and coupling is the dependency between
modules
l Good design stipulates ‘high cohesion and low coupling’
- C++ has separately compiled files like .h,.cpp with dependencies through #include
- Java supports packages
Hierarchy
l Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the understanding
of our problem
Inheritance
l Inheritance is an important “is-a” hierarchy and defines relationships among classes, wherein
one class shares the structure and behavior defined in another class
- A subclass typically redefines or augments the existing structure and behavior of its
superclasses
Abstract Class
l An Abstract Class is a class that is used only as a base class for other classes or subclasses
l We do not (need not, or even cannot) Instantiate from an abstract class
l Abstract classes can only be inherited
l It has one or more Abstract operations
- Abstract Operation is an operation for which no method is given
l Abstract class is introduced to make it possible to store a set of attributes and methods common
to several classes in one place
l Typically defined to provide interfaces for significant operations
l Also to provide implementations for common methods
Typing is the enforcement of the class of an object ,such that objects of different types may not be
interchanged, or at the most, they may be interchanged only in very restricted ways.
l Static typing refers the time when names are bound to types; also known as early binding
l Static binding means that the types of all variables and expressions are fixed at compile time
l Dynamic binding means that the types of all variables and expressions are not known until
runtime; also known as late binding
l Power of polymorphism
- Overriding vs Overloading
l Overriding : An operation is redefined within a subclass.
Concurrency
The property that distinguishes an active object from one that is not active.
Persistence
The property of an object by which its existence transcends time(i.e., the object continues to exist
after its creator ceases to exist) and /or space ( i.e., the object’s location moves from the address space
in which it was created).
l Offers the programmers of database systems the abstraction power of object technology
4. Encapsulation is the process of compartmentalizing the elements of an abstraction that constitutes its
_________ and __________and serves to separate the contractual interface of an abstraction and its
implementation.
5. Modularization consists of dividing a ___________ into modules which can be compiled separately, but
which have connection with other modules.
6. Cohesion is the interdependency within a module and __________ is the dependency between modules.
9. Inheritance is a relationship among classes, wherein one class shares the structure or behavior defined in
_______ or _________ other classes.
10. An Abstract Class is a class that is used only as a _______ for other classes or subclasses.
13. Typing is the _________ of the class of an object, such that objects of different types may not be interchanged,
or at the most, they may be interchanged only in very __________ ways.
14. Static binding means that the types of all variables and expressions are fixed at __________ time.
15. Dynamic binding means that the types of all variables and expressions are not known until runtime; also
known as __________.
16. Polymorphism exists when the features of inheritance and ________ binding interact. It is perhaps the most
powerful feature of object-oriented programming languages next to their support for abstraction.
17. Concurrency is that ____________ that distinguishes an active object from one that is not active.
30 Chapter 2 - The Object Model
a. Programming paradigm
b. An application generator
c. A case technique
d. A software system
a. Template
b. Specialized template
c. Classes
a. Encapsulation
c. Class identification
a. Two objects
a. Global classes
b. Abstract classes
c. Base classes
a. Strongly typed
b. Weakly typed
c. Even un typed
9. With an example, explain (i) Single inheritance & (ii) multiple inheritance.
Chapter 3
3.0 INTRODUCTION
W
hen we use object-oriented methods to analyze or design a complex software system, our
basic building blocks are classes and objects. In this unit, we shall study the nature of classes,
objects, and their relationships.
3.1 OBJECTIVES
At the end of this unit, You would be able to:
l Define the terms: Object and class
3.2 OBJECT
l Attributes (or properties) describe the state (or data) of an object and Methods (or procedures)
define its behavior.
- An object can be viewed as an encapsulated program operating on its own local data
(attributes)
1. Remember things
2. Have well-defined responsibilities
- Objects have an unique identity and they represent a particular instance of a class
3.2.1 Definition
An object has state, behavior, and identity; the structure and behavior of similar objects are defined in
their common class; the terms instance and object are interchangeable.
The State of an object encompasses all of the (usually static) properties of the object plus the current
(usually dynamic) values of each of these properties. On the other hand the State of an object represents
the cumulative results of its behavior.
Behavior is how an object acts and reacts, in terms of its state changes and message passing .
Identity is that property of an object which distinguishes it from all other objects.
l Links
l Aggregation / Composition
MSIT 41 OOAD with UML 35
l A link is a specific form of an association through which an object (the client) takes the services
of another object (the supplier)
l Where ambiguity appears, a directional arrow can be added to clarify an Association or Link
name.
An object by itself is intensely uninteresting. Objects contribute to the behavior of a system by
collaborating with one another.
The relationship between any two objects encompasses the assumptions that each makes about the
other, including what operations can be performed and what behavior results.
The term link derives from Rumbaugh, who defines it as a “physical or conceptual connection between
objects”. An object collaborates with other objects through its link to these objects. Stated another way, a
link denotes the specific association through which one object (the client) applies the services of another
object (the supplier), or through which one object may navigate to another.
Message passing between two objects is typically unidirectional, although may occasionally be bi-
directional.
l it is possible for an object to navigate to its container only if this knowledge is part of the object’s
state
2. Composition
l a form of aggregation with strong ownership and coincident lifetime of part with the whole
36 Chapter 3 - Classes and Objects
Example: Aggregation
Fig. 3.1
Example: Composition
Fig. 3.2
In an aggregation association, parts can be associated with multiple wholes (often at the same time).
For example, a wheel can be removed from a car and can be moved to a heap of tires or mounted on
another car. Elements in an aggregation have existence and identify outside of the whole. The wheel, for
example, has an existence and identity outside of the car. In addition, the parts and the whole within an
aggregation can have different lifetimes. For example, after the wheel is removed from the car, the car
MSIT 41 OOAD with UML 37
could be destroyed, yet the wheel would continue to exist. The whole within an aggregation does not own
its parts. For example, the car doesn’t own the wheel; the wheel could be removed and replaced with
another wheel. In an aggregation, there can be multiple paths (independent of the whole) for navigating to
the parts. For example, a tire vendor could probably identify the make and model of a tire, based solely on
the tire’s inventory number without having to first locate the car. There is no guarantee, however, that you
can necessarily navigate to a part from the whole, because the parts have an independent existence and
can have an independent lifetime.
In contrast, in a composition association, parts are associated only with one whole. In fact, a part
within a composition has no existence outside the whole. For example, a particular stack space does not
exist without being contained within a specific user process. The lifetime of the parts in a composition is
bound to the lifetime of the whole.
When a user process is created, the program memory, stack space and execution context are also
created. When a user process is destroyed, the program memory, stack space, and execution context die
too. If you can navigate to the whole in a composition, then you are guaranteed to be able to navigate to
the parts. This is because the lifetimes of the whole and parts correspond.
Aggregation is a relatively weaker form of the whole-part relationship, while composition is a relatively
stronger form.
Aggregation: Weaker
* Aggregation is a kind of association used to model whole-part relationships between things. A
hollow diamond is attached to the end of the path to indicate aggregation. However, the diamond
may not be attached to both ends of a line.
* Parts can be associated with multiple wholes (often at the same time)
* Issues of navigation, ownership, and lifetimes of the whole vs. the part are ignored
Composition: Stronger
* Composition, also known as the a-part-of , is a form of aggregation with strong ownership to
represent the component of a complex object. Composition also is referred to as a part-whole
relationship. The UML notation for composition is a solid diamond at the end of a path.
There are clear trade-off between links and aggregation. Aggregation is sometimes better because it
encapsulates parts as secrets of the whole. Links are sometimes better because they permit looser coupling
among objects. Intelligent engineering decisions that is an attribute of another has a link to its aggregate.
Across the link, the aggregate may send messages to its parts.
3.3 CLASS
l It contains the description or definition of attributes and methods an object will have
l They have data structure and behavior and relationships to other elements
3.3.1 Definitions
Attribute
l An attribute is a descriptor of an instance. It tells us something important and significant about
the nature of an instance
l Examples of attributes are length, height, weight, color, date of birth, cost etc.
A class can possess variables that contain state information relevant to users of instances of the class.
Such variables are often called attributes. In some programming languages, such as C++, attributes can
be accessed directly using language constructs, such as assignment. In other languages, access to attributes
is mediated via operations, often called get (to retrieve the value of an attribute) and set (to change the
value of an attribute). In the typical case, attributes associated with a class are copied into the state of an
object when the object is created. From that point, the values of the attributes can be changed independently
by different instances of the class and, thus, different values can be seen by class instances for the same
attribute.
l Class Attributes
– The attribute value belongs to the class and objects do not maintain independent values
l Derived Attributes
– The attribute value are dependent upon the values of other attributes
In some cases, attributes can be designated as class attributes. The values of class attributes are kept
with the executable code for a class and cannot be changed independently by different class instances.
When an object changes a class attribute, all other instances of the class will see the same new value of
the attribute. Some languages, such as C++, allow a programmer to designate a static variable. Such a
variable would be a class attribute that cannot be changed by instances of the class.
Some attributes, called derived attributes possess values that are dependent upon the values of other
attributes. For example, an attribute representing a person’s age depends upon the person’s birth date and
the current date. Once the two dates are known, the person’s age can be computed.
Methods/Operations
l Methods/Operations make it possible to connect algorithm (behavior) with an object
l Whereas attributes describe static characteristics of objects, methods describe the behavior of
an object, that is, the services that an object can provide
l Each method has a name and a body
Each class provides a set of services to client objects and such services are specified through named
operations that also indicate the parameters input to and returned from the operation. The specification of
the operation name and its related parameters, including the classes of each parameter, are known as the
40 Chapter 3 - Classes and Objects
signature of the operation. Operations with the same name and the same parameter names and classes
are said to have the same signature. Two operations with the same name but with differing parameter
names and classes are said to have different signatures.
Even when an operation has the same signature, alternative methods of implementing the operation
can be found. The actual software that implements the procedure or behavior associated with an operation
and its signature is known as a method for the operation.
We establish relationships between two classes for one of two reasons. First, a class relationship might
indicate some sort of sharing. For example, daisies and roses are both kinds of flowers, meaning that both
have brightly colored petals, both emit a fragrance, and so on. Second, a class relationship might indicate
some kind of semantic connection. Thus, we say that red roses and yellow roses are more alike than are
daisies and roses, and daisies and roses are more closely related that are petals and flowers. Similarly,
there is symbiotic connection between ladybugs and flowers: ladybugs protect flowers for certain pests,
which in turn serve as a food source for the ladybug.
In all, there are three basic kinds of class relationships. The first of these is generalization/specialization,
denoting an “is a” relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized
subclass of the more general class, flower. The second is whole/part, which denotes a “part of” relationship.
Thus, a petal is not a kind of a flower; it is a part of flower. The third is association, which denotes some
semantic flowers. As another example, roses and candles are largely independent classes, but they both
represent things that we might use to decorate a dinner table.
Association
a. An Association is a set of relationships between or among classes
Example In an automated system for retail point of sale, two of our key abstraction include products
and sales. As shown above, we may show a simple association between these two classes: the class
Product denotes the products sold as part of a sale, and the class Sale denotes the transaction through
which several products were last sold. By implication, this association suggests bi-directional navigation:
given an instance of Product, we should be able to locate the object denoting its sale, and given an
instance of Sale, we should be able to locate all the products sold during the transaction.
Here we show a one-to-many association: each instance of Product may have a pointer to its last
sale, and each instance of Sale may have a collection of pointers denoting the products sold.
Product Sale
N 1 ssSS
Product last Sale
Fig. 3.3
As this example suggests an association only denotes a semantic dependency and does not state the
direction of this dependency (unless otherwise stated, an association implies bi-directional navigation, as
in our example), nor does it state the exact way in which one class relates to another (we can only imply
these semantics by naming the role each class plays in relationship with the other). However, these
semantics are sufficient during the analysis of a problem, at which time we need only to identify such
dependencies. Through the creation of associations, we come to capture the participants in a semantic
relationship, their roles, and, as we will discuss, their cardinality.
In a binary association both ends may attach to the same class. The links of such an association may
connect to two different objects from the same class or one object to itself. The latter case is a Recursive
or reflexive association; it may be forbidden by a constraint if necessary
Fig. 3.4
Association End
l An association Role is simply an end of an association where it connects to a class
l The path may have graphical adornments at each end where the path connects to the class
symbol
An association end is simply an end of an association where it connects to a class. It is part of the
association, not part of the class. Each association has two or more ends. Most of the interesting details
about an association are attached to its ends. An association end is not a separable element; it is just a
mechanical part of an association.
The path may have graphical adornments at each end where the path connects to the class symbol.
These adornments indicate properties of the association related to the class. The adornments are part of
the association symbol, not part of the class symbol. The end adornments are attached to the end of the
line.
* drives *
person car
Driver Company car
Fig. 3.5
N-Ary Association
l An association among 3 or more classes (a single class may appear more than once)
l Each instance of the association is an n-tuple of values from the respective classes
l An n-ary association is shown as a large diamond with a path from the diamond to each
participant class
l The name of the association (if any) is shown near the diamond
An n-ary association is an association among 3 or more classes (a single class may appear more than
once). Each instance of the association is an n-tuple of values from the respective classes. A binary
association is a special case with its own notation.
Multiplicity for n-ary associations may be specified but is less obvious than binary multiplicity. The
multiplicity on a role represents the potential number of instance tuples in the association when the other
N-1 values are fixed.
An n-ary association may not contain the aggregation marker on any role.
MSIT 41 OOAD with UML 43
Generalization
l Is a relationship between a more general element and a more specific element
l Generalization is shown as a solid-line path from the more specific element (such as a subclass)
to the more general element (such as a superclass), with a large hollow triangle at the end of the
path where it meets the more general element
l Generalization may be applied to associations as well as classes
Generalization is the taxonomic relationship between a more general element and a more specific
element that is fully consistent with the first element and that adds additional information.
Dependency
l Indicates a semantic relationship between two (or more) classes
l It indicates a situation in which a change to the target element may require a change to the
source element in the dependency
l A dependency is shown as a dashed arrow between two model elements
l The model element at the tail of the arrow depends on the model element at the arrowhead. The
arrow may be labeled with an optional stereotype and an optional name
A dependency indicates a semantic relationship between two (or more) model elements. It relates the
model elements themselves and does not require a set of instances for its meaning. It indicates a situation
in which a change to the target element may require a change to the source element in the dependency.
3.4 SUMMARY
Object
l Attributes (or properties) describe the state (or data) of an object and Methods (or procedures)
define its behavior.
l In OO each element/unit in a program must be an object
- An object can be viewed as an encapsulated program operating on its own local data
(attributes)
- A good metaphor is to think of an object as a micro-world with ability to
l Remember things
l Have well-defined responsibilities
44 Chapter 3 - Classes and Objects
- Objects have an unique identity and they represent a particular instance of a class
l Aggregation / Composition
l A link is a specific form of an association through which an object (the client) takes the services
of another object (the supplier)
l A Link is an instance of an association and both are bi-directional. (e.g., employs and employed
by)
l Where ambiguity appears, a directional arrow can be added to clarify an Association or Link
name.
l It is possible for an object to navigate to its container only if this knowledge is part of the object’s
state
- Composition
l A form of aggregation with strong ownership and coincident lifetime of part with the whole
Class
l It contains the description or definition of attributes and methods, an object will have
l They have data structure and behavior and relationships to other elements
l We say that we create or instantiate object(s) using a class
l The executable code for an object is typically associated with a class, rather than with each
individual object generated from the class
Attribute
l An attribute is a descriptor of an instance. It tells us something important and significant about
the nature of an instance
l Examples of attributes are length, height, weight, color, date of birth, cost etc.
Methods / Operations
l Methods/Operations make it possible to connect algorithm (behavior) with an object
l Whereas attributes describe static characteristics of objects, methods describe the behavior of
an object, that is, the services that an object can provide
l Each method has a name and a body
l Dependencies
Association
l An Association is a set of relationships between or among classes
Association End
l An association role is simply an end of an association where it connects to a class
N-Ary Association
l An association among 3 or more classes (a single class may appear more than once)
l Each instance of the association is an n-tuple of values from the respective classes
l The name of the association (if any) is shown near the diamond
Generalization
l Is a relationship between a more general element and a more specific element
l Generalization is shown as a solid-line path from the more specific element (such as a subclass)
to the more general element (such as a superclass), with a large hollow triangle at the end of the
path where it meets the more general element
l Generalization may be applied to associations as well as classes
Dependency
l Indicates a semantic relationship between two (or more) classes
MSIT 41 OOAD with UML 47
l It indicates a situation in which a change to the target element may require a change to the
source element in the dependency
l A dependency is shown as a dashed arrow between two model elements
l The model element at the tail of the arrow depends on the model element at the arrowhead. The
arrow may be labeled with an optional stereotype and an optional name
(a) Object
(b) Class
(a) Association
(d) Generalization
(e) Dependency
a. By command languages
b. By passing messages
48 Chapter 3 - Classes and Objects
c. By invoking methods
d. By function calls
a. Template
b. Specialized template
c. Classes
b. Generalization
c. Dependency
b. Association alone
c. Classes alone
2. The State of an object encompasses all of the (usually static) properties of the object plus the __________
values of each of these properties.
3. Behavior is how an object acts and reacts, in terms of its ____ changes and ____ passing .
4. Identity is that ________ of an object which distinguishes it from all other objects.
5. Messages are sent between objects to request operations and to return _________.
6. Each object in an object-oriented program has its own individual______ and its own ___________.
7. The attribute value belongs to the class and objects do not maintain independent values, such attribute is
called _____________.
8. The attribute values are dependent upon the values of other attributes are called _______
9. The executable code for an object is typically associated with a _______, rather than with each individual
object generated from the class.
11. Attributes describe ____________of objects, methods describe the _________ of an object, i.e., the services
that an object can provide.
15. ___________ Indicates a semantic relationship between two (or more) classes.
16. Attributes (or properties) describe the _______ of an object and Methods (or procedures) define its ________.
17. Objects have an unique __________and they represent a particular instance of a class.
50 Chapter 4 - Road Map for OOA and OOD
Chapter 4
4.1 OBJECTIVES
- Discussion on
OOD Phase
l Overall question is “How?”
l You are worried about some implementation details but not all
The design process is typically split into two distinct phases: Object-Oriented Analysis (OOA) and
Object Oriented Design (OOD).
We will call these things “activities” rather than “steps” to emphasize that they do not have to be done
in any particular order — you can switch to another activity whenever it makes sense to do so. When you
are actually doing this, you will find that you want to go back and forth between OOA and OOD repeatedly.
May be you will start at one part of your program, and do OOA and OOD on that part before doing OOA
and OOD on another part. Or may be you will do a preliminary OOA, and then decide while working on
the OOD that you need more classes, so you jump back to OOA. That’s great. Moving back and forth
between OOA and OOD is the best way to create a good design — if you only go through each step
once, you will be stuck with your first mistakes all the way through. It is important, though, to always be
clear what activity you are currently doing — keeping a sharp distinction between activities will make it
easier for you to make design decisions without getting tied up in knots.
In the OOA phase, the overall questions is “What?”. As in, “What will my program need to do?”,
“What will the classes in my program be?”, and “What will each class be responsible for?”. You do not
worry about implementation details in the OOA phase — there will be plenty of time to worry about them
later, and at this point they only get in the way. The focus here is on the real world — what are the objects,
tasks and responsibilities of the real system?
In the OOD phase, the overall question is “How?”. As in, “How will this class handle it’s
responsibilities?”, “How can I ensure that this class knows all the information it needs?”, “How will
classes in my design communicate?”. At this point, you are worried about some implementation details,
but not all — what the attributes and methods of a class will be, but not down to the level of whether things
are integers or real or ordered collections or dictionaries or whatnot — those are programming decisions.
l Create a list of what classes are part of the system, and (just as important) what classes are not
part of the system.
l Distribute the functionality of the system among the list of classes. A piece of functionality
assigned to a specific class is called a responsibility
In the real world, however, this is often the trickiest part of the software engineering process, as it is
not always clear what the program is going to need to do. Typically what is done in an object-oriented
requirements analysis is to create a list of use cases, small interactions that the system will have to
support.
l Do not throw anything out. Two reasons. First, you never know when some crazy idea is going
to wind up saving your project. Second, the classes that you don’t include in the system are just
as important for defining the bounds of your system as the ones that are inside.
l Are some of the things you have listed specific instances of a more general concept, or vice
versa?
l Each class in the system has its own CRC card, which contains a list of all the responsibilities of
that class, along with the other classes which collaborate in carrying out those responsibilities.
The other activity of OOA is assigning responsibilities to the classes that will carry them out. The tool
for managing this activity is called a CRC card. CRC stands for Class, Responsibility, Collaborator, and
describes the information on the card. Each class in the system has its own CRC card, which contains a
list of all the responsibilities of that class, along with the other classes which collaborate in carrying out
those responsibilities.
Ward Cunningham invented CRC cards in response to a need to document collaborative design
decisions. The cards started as a HyperCard stack which provided automatic indexing to collaborators,
but were moved to their current form to address problems of portability and system independence.
CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing
the details of a collaboration in the form of message sending, CRC cards place the designer’s focus on the
motivation for collaboration by representing (potentially) many messages as a phrase of English text.
As it is currently used, all the information for an object is written on a 4" x 6" index card. These have
the advantages that they are cheap, portable, readily available, and familiar.
Design with the cards tends to progress from known to unknowns, as opposed to top-down or bottom
up. Two teams could arrive at essentially the same design through nearly opposite sequences, one starting
with device drivers, the other with high-level models. The problem demanded a certain set of capabilities
which both teams discovered in the course of fulfilling the requirements of the design.
54 Chapter 4 - Road Map for OOA and OOD
n Along the top of the card: write the name of the class
n In the body: list of class responsibilities on the left and collaborators on the right
l Responsibilities
n Are the attributes and operations that are relevant for the classes
n Those classes that are required to provide a class with the information needed to complete
a responsibility
C lass n am e
One of the distinguishing features of object design is that no object is an island. All objects stand in
relationship to others, on whom they rely for services and control. The last dimension we use in characterizing
object designs is the collaborators of an object. We name as collaborators objects which will send or be
sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric
relation.
Sometimes it is helpful to “role-play” — pretending that you are each object in the system in turn, try
to trace out interaction patterns to determine what each class will need to know and do.
l This is still a brainstorm activity, so the main goal is to just get things down on paper.
l Focus on what, not how implementation is still not your problem yet.
l Look for commonalties among classes you may be able to factor them out using inheritance.
Either you have a list of responsibilities and you are trying to assign them to classes, or you have a
class and you are trying to define its responsibilities. Keep the following principles in mind:
l The anthropomorphic principle: an object is responsible for all the things that would be done to it
in the real world.
56 Chapter 4 - Road Map for OOA and OOD
l The expert principle: assign a responsibility to the class or classes that have the knowledge to
perform it.
l If more than one object has the knowledge, then the two classes should collaborate on the
responsibility.
l Distribute responsibility — no one class should have most of the responsibilities. You shouldn’t
be able to point to one class as the “center” of your design.
l Each class should have some responsibility, if not, question whether it belongs there at all.
l If a class seems to have too much responsibility, or if its responsibilities seem unrelated, look for
ways to split it into smaller classes.
l Rarely, a responsibility may become a class all by itself. Look for this if the responsibility is quite
large, and potentially applies to a number of classes in your system that are not otherwise
related.
- If the requirements were extended to include more things, the existing parts of the design
would only change minimally.
- If the input or output methods of the program were to change radically, the existing design
would only change minimally.
Whenever you come out of an OOA phase, you should have a list of classes in your design, a list of
rejected classes, and possibly a list of classes still under consideration.
MSIT 41 OOAD with UML 57
Each class in your design should have a list of responsibilities and collaborators that describe what the
class does within the system. And some more:
n It is general, and thus reusable.
n Information access is enough. Objects that do not need information can’t get to it. Objects that
do need information can get to it (i.e., either they have it, or they have an instance variable that
points to an object that has it.)
n Responsibility, control, and communication is distributed. One object doesn’t do everything.
Makes it easier to reuse, easier to develop and manage.
n Minimize assumptions of language or system. Try to describe the world, not a program.
n Assigning Responsibilities.
n Implementation - You can see how do you write code from here.
n Complete - It is obvious that the OOA is right because everything you need to do is (1) covered
in the OOD and (2) matches the OOA.
n We do not just repeat the OOA in the OOD. For example, one might have defined a class
named TempSensor that has a part-of relationship with a Refrigerator and has an attribute
named DesiredTemp. In the OOD, we’re seeing the script “I am a TempSensor. I know my
DesiredTemp. I am part of a Refrigerator.” Period. That’s not the idea. The OOD is where you
ALSO spell out what the TempSensor does and HOW it does it. Below is an example, with my
notes in parentheses about what you should be thinking about when you are writing these out:
“I am a TempSensor. I know how to alert the Refrigerator when to turn on. (Which implies that
I’d better have an instance variable for my Refrigerator.) When I get a tick message (Which
implies that something is going to send the Tick message. Who? How do they track those of us
who care about ticks?), I compare the current temperature (maybe there is a message which
reads the device?) to the DesiredTemp, and if it is out of range (where is the acceptable range
stored?), I send a message to the Refrigerator. (What message? Refrigerators better know how
to respond to that message.)”
n The idea is that the OOD is where you patch the pieces together, where you make sure that
messages are caught, important information is known at the right places, that all the important
services are accounted for.
n Removes unnecessary middlemen. If A needs to reach B, but can only do it through C...think
about allowing A to reach B directly.
- Objects connect to other objects only if they need information from them.
- Grady Booch
n Requirements churn
n Hard to maintain
n Build-and-release issues
l A technique that is used to deliver the functionality of a system in a successive series of releases
of increasing completeness. Each iteration is focused on defining, analyzing, designing, building
and testing some set of requirements.
Object-oriented design
UML
MSIT 41 OOAD with UML 63
Chapter 5
5.0 OBJECTIVES
At the end of this unit, You would be able to:
5.1 INTRODUCTION
A model is an abstract representation of a system, constructed to understand the system prior to
building or modifying it. A model is simplified representation of reality, because reality is too complex or
large. A model provides a means for conceptualization and communication of ideas in a precise and
unambiguous form. The characteristics of simplification and representation are difficult to achieve in the
real world, since they frequently contradict each other. Thus modeling enables us to cope with the complexity
of a system.
Most modeling techniques used for analysis and design involve graphic languages. These graphic
languages are sets of symbols. The symbols are used according to certain rules of methodology for
communicating the complex relationships of information more clearly than descriptive text. The main
goal of most CASE tools is to aid us in using these graphic languages, along with their associated
methodologies.
Modeling is frequently used during many of the phases of the software lifecycle, such as analysis,
design, and implementation. For example, objectory is built around several different models:
l Use-case model. The use-case model defines the outside (actors) and inside (use-case) of the
systems’s behavior.
l Domain object model. Objects of “real” world are mapped into the domain object model.
l Analysis object model. The analysis object mode presents how the source code should be
carried out and written.
l Implementation model. The implementation model represents the implementation of the system.
l Test model. The Test model constitutes the test plans, specifications, and reports.
Modeling, like any other object-oriented development, is an iterative process. As the model progresses
from analysis to implementation, more detail is added, but it remains essentially the same. In this unit, we
look at Unified Modeling Language(UML) notations and the main idea is to exposure to the UML syntax,
semantics, and modeling constructs.
Grady Booch and James Rumbaugh started work to unite the Booch method and the OMT-2 method.
Later Ivar Jacobson the man behind the Objectory method joined them.
MSIT 41 OOAD with UML 65
(b) Metamodel layer - consists of the elements that constitute the UML, including concepts
from OO domain and component-oriented paradigms.
(c) Model layer - consists of UML models. It is at this level that the modeling of problems,
solutions or systems occur.
(d) User model layer - consists of those elements that exemplify UML models. Each concept
within this level is an instance of a concept within the model layer.
To understand the architecture of the UML, consider how computer programs and programming
languages are related. All programming languages support various declarative constructs for declaring
data and defining the logic that manipulates the data. Because a model is an abstraction, each of these
concepts may be captured in a set of related models. Programming language concepts are defined in a
model called the metamodel. Each particular programming language is defined in a model that uses and
specializes the concepts within the metamodel. Each program implemented in a programming language
may be defined in a model called the user model that uses and instantiates the concepts within the model
of the appropriate language. This scheme of a metamodel representing computer programming constructs,
models representing computer programming languages and user models representing computer programs
exemplifies the architecture of UML. Distinct layers of the metamodel architecture are as given in the
slides.
This model is
1. Iterative and incremental
2. Architecture centric
l UML can also be used in the different phases of software development, from requirements
specification to test of a finished system
l RUP is
3. Architecture centric
MSIT 41 OOAD with UML 67
An iterative process is one that involves managing a stream of executable releases. An incremental
process is one that involves the continuous integration of the system’s architecture to produce these
releases, with each new release embodying incremental improvements over the other. Together, an
interactive and incremental process is risk-driven, meaning that each new release is focused on attaching
and reducing the most significant risks to the success of the project.
Use-Case driven means that the use cases are used as a 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.
Architecture-centric means that a system’s architecture is used as a primary artifact for
conceptualizing, constructing, managing, and evolving the system under development.
l An iteration is a sequence of activities with an established plan and evaluation criteria, resulting
in an executable release.
Lifecycle Phases
Inception
Inception Eloboration
Elaboration Construction
Construction Transition
Transition
time
Fig. 5.1
Inception: Define the scope of the project and develop business case
Elaboration: Plan project, specify features, and baseline the architecture.
— Supplementary specification
l Analysis artifacts
— Analysis classes
— Class diagram
– Activity diagram
l Describe distribution
– Deployment diagram
— It is a simplification of reality and we build models so that we can better understand the
system we are developing
l The Unified Modeling Language (UML) is a language for
l UML represents a collection of best engineering practices that have proven successful
in the modeling of large and complex systems
The use of modeling has a rich history in all the engineering disciplines. That experience suggests four
basic principles of modeling which are as follows :
l The choice of what models to create has a profound influence on how a problem is attached and
how a solution is shaped.
l No single model is sufficient. Every nontrivial system is best approached through a small set of
nearly independent models.
UML is more than just a bunch of graphical symbols. Rather behind each symbol in the UML notation
is well defined semantics. In this manner, one developer can write a model in the UML and another
developer, or even other tools, can interpret that model unambiguously.
In the context of specifying, building models are precise, unambiguous and complete. In particular, the
UML addresses the specification of all the important analysis, design and implementation decisions that
must be made in developing and deploying a software-intense system.
The UML is not a visual programming language, but its models can be directly connected to a variety
of programming language. This mapping permits forward, reverse, and round-trip engineering.
A healthy software organization produces all sorts of artifacts in addition to raw executable code.
These artifacts include requirements, architecture, design, source code, project plans, rests, prototypes,
and releases.
l Provide users a ready-to-use, expressive visual modeling language so they can develop and
exchange meaningful models.
It is important that the OOAD standard support a modeling language that can be used “out of the box”
to do normal general-purpose modeling tasks. . The UML consolidates a set of core modeling concepts
that are generally accepted across many current methods and modeling tools.
We expect that the UML will be tailored as new needs are discovered and for specific domains. At the
same time, we do not want to force the common core concepts to be redefined or re-implemented for
each tailored area. Users need to be able to 1) build models using core concepts without using extension
mechanisms for most normal applications; 2) add new concepts and notations for issues not covered by
the core; 3) choose among variant interpretations of existing concepts, when there is no clear consensus;
and 4) specialize the concepts, notations, and constraints for particular application domains.
The UML must and can support all reasonable programming languages. It also must and can support
various methods and processes of building models. The UML can support multiple programming languages
and development methods without excessive difficulty.
Clearly defined semantics of these concepts is essential to reap the full benefit of OO and reuse.
Defining these within the holistic context of a modeling language is a unique contribution of the UML.
A key motivation behind the development of the UML has been to integrate the best practices in the
industry, encompassing widely varying views based on levels of abstraction, domains, architectures, life
cycle stages, implementation technologies, etc. The UML is indeed such an integration of best practices.
l Tools
l Process
Programming Languages
The UML, a visual modeling language, is not intended to be a visual programming language, in the
72 Chapter 5 - Unified Modeling Language
sense of having all the necessary visual and semantic support to replace programming languages.
Some things, like complex branches and joins, are better expressed in a textual programming language.
The UML does have a tight mapping to a family of OO languages, so that you can get the best of both
worlds.
Tools
Standardizing a language is necessarily the foundation for tools and process. The UML defines a
semantic metamodel, not an tool interface, storage, or run-time model, although these should be fairly
close to one another. The UML documents do include some tips to tool vendors on implementation choices,
but do not address everything needed. For example, they don’t address topics like diagram coloring, user
navigation, animation, storage/implementation models, or other features.
Process
Many organizations will use the UML as a common language for its project artifacts, but will use the
same UML diagram types in the context of different processes. The UML is intentionally process
independent, and defining a standard process was not a goal of the UML or OMG’s RFP. Processes by
their very nature must be tailored to the organization, culture, and problem domain at hand. The selection
of a particular process will vary greatly, depending on such things like problem domain, implementation
technology, and skills of the team. Although the UML does not mandate a process, its developers have
recognized the value of a use-case driven, architecture-centric, iterative, and incremental process.
— They show different aspects of the system that are modeled. The views link the modeling
language to the method/process chosen for development.
l Modeling elements
— Model elements represent common object-oriented concepts such as classes, objects and
messages.
l Relationships
l Diagrams
MSIT 41 OOAD with UML 73
l Extensibility mechanisms
— Provide extra comments, information or semantics about a model element; they also
provide extension mechanism to adapt or extend UML.
The use case view describes the functionality the system should deliver, as perceived by external
actors. This view is central since its contents drive the development of the other views. The final goal is
to provide the functionality described in this view - along with some nonfunctional properties.
The logical view describes how the system functionality is provided. It looks inside the system and
describes both the static structure and the dynamic collaborations that occur when objects send messages
to each other to provide a given function.
74 Chapter 5 - Unified Modeling Language
Component view is a description of the implementation modules and their dependencies. The code
modules are shown with their structure and dependencies.
The concurrency view deals with the division of the system into processes and processors. This
aspect which is a non-functional property of the system deals with efficient resource usage, parallel
execution and the handling of asynchronous events from the environment.
Finally, the deployment view shows the physical deployment of the system, such as the computers and
devices and how they connect to each other.
- Behavioral elements
Interaction, state, activity
- Grouping elements
Package, subsystem
- Annotations
Note
MSIT 41 OOAD with UML 75
P a cka g e
Fig. 5.4
– Generalization
– Dependency
– Realization
Fig. 5.5
76 Chapter 5 - Unified Modeling Language
Realization is a semantic relationship between classifiers, wherein one classifier specifies a contract
that another classifier guarantees to carry out.
Fig. 5.6
l Tagged value
l Constraint
MSIT 41 OOAD with UML 77
Fig. 5.7
UML is open-ended, making it possible for us to extend the language in controlled ways.
A stereotype extends the vocabulary of UML, allowing us to create new kinds of building blocks that
are derived from existing ones but are specific to our problem.
A tagged value extends the properties of a UML building block, allowing us to create new information
in that elements specification.
A constraint extends the semantics of the UML building block, allowing us to add new rules or modify
existing ones.
78 Chapter 6 - UML Modeling Elements
Chapter 6
6.0 INTRODUCTION
l Modeling elements/Things - are abstractions that are first-class citizens in a model, examples
of which are use case, interface, class, package, component, node state etc.
l Modeling elements are of four types
- Structural elements
Class, interface, use case, active class, component, node
- Behavioral elements
Interaction, state, activity
- Grouping elements
Package, subsystem
- Annotations
Note
6.1 OBJECTIVES
At the end of this unit, You would be able to:
6.2 CLASS
m A class is drawn as a solid-outline rectangle with at most three compartments separated by
horizontal lines.
m The top name compartment holds the class name and other general properties of the class
(including stereotype)
m The middle compartment holds a list of attributes
Example:
Class Representation
80 Chapter 6 - UML Modeling Elements
6.2.1 Attribute
• An attribute is shown as a text string that can be parsed into the various properties of an
attribute model element.
• The default syntax is
# protected visibility
- private visibility
• Visibility may also be specified by keywords public, protected or private
• Multiplicity may be indicated by placing a multiplicity indicator in brackets after the attribute
name, for example:
Example:
+size: Area = (100,100) #visibility: Boolean = invisible
-xptr: XWindowPtr
In the absence of a multiplicity indicator an attribute holds exactly 1 value. Multiplicity may be indicated
by placing a multiplicity indicator in brackets after the attribute name, for example:
Note that a multiplicity of 0..1 provides for the possibility of null values: the absence of a value, as
opposed to a particular value from the range. For example, the following declaration permits a distinction
between the null value and the empty string:
name [0..1]: String
MSIT 41 OOAD with UML 81
A stereotype keyword in guillemets precedes the entire attribute string, including any visibility indicators.
A property list in braces follows the entire attribute string.
Style guidelines Attribute names typically begin with a lowercase letter.
l Instance
l Each Instance holds its own value
l Class
82 Chapter 6 - UML Modeling Elements
Header : FrameHeader
Class scope uniqueID : Long
Fig. 6.1
Example:
Fig. 6.2
6.2.2 Operation
l Used to show operations defined on classes
• An operation that does not modify the system state (one that has no side effects) is specified by
the property “{query}”
• The concurrency semantics of an operation are specified by a property string with one of the
names: sequential, guarded, concurrent
Example:
+ create ()
+ hide ()
- attachXWindow(xwin:Xwindow*)
An operation that does not modify the system state (one that has no side effects) is specified by the
property “{query}”; otherwise the operation may alter the system state, although there is no guarantee
that it will do so.
The concurrency semantics of an operation are specified by a property string with one of the names:
sequential, guarded, concurrent. In the absence of a specification the concurrency semantics are undefined
and must be assumed to be sequential in the worst case.
The top-most appearance of an operation signature declares the operation on the class (and therefore
inherited by all of its descendents). If this class does not implement the operation (i.e., does not supply a
method) then the operation may be marked as “{abstract}” or the operation signature may be italicized to
indicate that it is abstract. Any subordinate appearances of the operation signature indicate that the
subordinate class implements a method on the operation.
The actual text or algorithm of a method may be indicated in a note attached to the operation entry.
84 Chapter 6 - UML Modeling Elements
Operation Compartment
Fig. 6.3
An operation entry with the stereotype «signal» indicates that the class accepts the given signal. The
syntax is identical to that of an operation.
The specification of operation behavior is given as a note attached to the operation. The text of the
specification should be enclosed in braces if it is a formal specification in some language (a semantic
Constraint), otherwise it should be plain text if it is just a natural-language description of the behavior (a
Comment).
A stereotype keyword in guillemets precedes the entire operation string, including any visibility indicators.
6.3 OBJECT
l The object notation is derived from the class notation by underlining instance-level elements
l It is shown as a rectangle with two compartments.
l The top compartment shows the name of the object and its class, all underlined, using the syntax
: objectname : classname
l The second compartment shows the attributes for the object and their values as a list
l Each value line has the syntax: attributename : type = value
MSIT 41 OOAD with UML 85
The object notation is derived from the class notation by underlining instance-level elements. An object
shown as a rectangle with two compartments. The top compartment shows the name of the object and its
class, all underlined, using the syntax:
objectname : classname
The classname can include a full pathname of enclosing package, if necessary. The package names
precede the classname and are separated by double colons.
The list must be a comma-separated list of names of states that can legally occur concurrently. The
second compartment shows the attributes for the object and their values as a list. Each value line has the
syntax: attributename : type = value
Object- Representation
Fig. 6.4
86 Chapter 6 - UML Modeling Elements
6.4 INTERFACE
An interface is a classifier and may also be shown using the full rectangle symbol with compartments
and the keyword «interface»
Fig. 6.5
l May also be displayed as a small circle with the name of the interface placed below the symbol
6.5 PACKAGES
l Packages and Model Organization
- It is a grouping of model elements that may be nested and all kinds of UML model elements and
diagrams can be organized into packages.
- Packages own model elements and model fragments and are the basis for configuration control,
storage, and access control .
MSIT 41 OOAD with UML 87
- Each element can be directly owned by a single package, so the package hierarchy is a strict
tree.
- Packages can reference other packages, so the usage network is a graph.
A package is a grouping of model elements. Packages themselves may be nested within other packages.
A package may contain both subordinate packages and ordinary model elements.
Some packages may be Subsystems or Models. The entire system description can be thought of as a
single high-level subsystem package with everything else in it. All kinds of UML model elements and
diagrams can be organized into packages.
Fig. 6.6
Note that packages own model elements and model fragments and is the basis for configuration
control, storage, and access control.
Each element can be directly owned by a single package, so the package hierarchy is a strict tree.
However, packages can reference other packages, so the usage network is a graph.
88 Chapter 7 - Relationships Connect Modeling Elements
Chapter 7
7.0 INTRODUCTION
T
hese bind the modeling elements.
7.1 OBJECTIVES
At the end of this unit, You would be able to:
l Aggregation
l Composition
l Generalization
l Dependency
l Realization
Among objects
l Links
Fig. 7.1
7.3 ASSOCIATION
l It is an structural, static relationship between two or more classes
l May be a reflexive association from a class to itself
l A binary association is drawn as a solid path connecting two class symbols
l Or-association specifies that objects of a class may participate in at most one of the associations
at time.
Or Association
C o u rse
S tu d e n t P r o fe s s o r
Fig. 7.2
90 Chapter 7 - Relationships Connect Modeling Elements
l Navigability
l Role-name
l Aggregation indicator
l Visibility
l Ordering
Fig. 7.3
Multiplicity is a range that tells us how many objects are linked. It is shown near the end of the
association, at the class where it is applicable.
It is possible to have navigable associations by adding an arrow at the end of the association. The
arrow indicates the association can be used in only one direction.
The direction of a association name is shown by a small solid triangle either preceding or following the
name.
Role name is a string placed near the end of the association next to the class to which it applies and it
indicate the role played by the class in terms of the association.
The aggregation diamond is attached to the class which is a aggregate. If the diamond is filled it
indicates composition.
MSIT 41 OOAD with UML 91
Visibility is specified in front of the rolename and it indicates the visibility of the association traversing
in the direction towards the given name.
If the multiplicity is greater than one, then the set of related elements can be ordered or unordered. If
the constraint ordered is imposed it means that the elements of the set are ordered into a list.
7.5 AGGREGATION
l Represents a “has-a” (whole-part) relationship
Whole
Company
aggregation
Department
part
Fig. 7.4
92 Chapter 7 - Relationships Connect Modeling Elements
7.6 COMPOSITION
l Shown by a solid filled diamond as an association role adornment
Fig. 7.5
7.7 GENERALIZATION
It is a relationship between a more general element and a more specific element. It is used for use
cases, classes and packages. A constraint given on a generalization specifies further information about
how it could be used and extended in future. The constraints could be.
Overlapping/disjoint - overlapping inheritance means that any further subclasses inheriting from the
subclasses in the inheritance relationship can inherit more than one of the subclass.(multiple inheritance
allowed). Disjoint means that subclasses are not allowed to be specialized into a common subclass. It is
the default.
Complete/incomplete - a complete generalization means that all subclasses have been specified
and no further subclasses can be done and an incomplete constraint specifies that subclasses may be
added later on.
MSIT 41 OOAD with UML 93
7.8 DEPENDENCY
Dependency relationship is a semantic connection between two model elements, one dependent and
another independent. A change in the independent element will affect the dependent element.
7.9 REALIZATION
Realization is a semantic relationship between classifiers in which one classifier specifies a contract
and another specifies guarantees to carry out. It is somewhat a cross between dependency and
generalization. We realize this in two contexts in the context of interfaces and in the context of collaborations.
A n a ly s is D e s ig n c la s s
c la s s
R e a l iz e s
V a l id a t e V a l id a tio n
u ser
Fig. 7.8
MSIT 41 OOAD with UML 95
a:DisplayItem
move()
aController
aView
isUnder()
b: DisplayItem
Fig. 7.9
96 Chapter 8 - Diagrams in UML
Chapter 8
Diagrams in UML
8.0 INTRODUCTION
The UML defines nine graphical diagrams:
1. Functional diagram
- Use case diagram
- Object diagram
- Interaction diagram
o Sequence diagram
o collaboration diagram
- Activity diagram
4. Implementation diagram
- Component diagram
- Deployment diagram
8.1 OBJECTIVES
At the end of this unit, You would be able to:
l Understand the Functional diagram: - Use case diagram
l Understand these Dynamic view diagrams:- State diagram, Interaction diagram, Activity diagram
l Understand these Implementation diagrams:- Component diagram, Deployment diagram.
– Actors
– System modeled
The classic definition of Use Cases comes from Ivar Jacobson’s ‘Object-Oriented Software Engineering’
(OOSE) which states: “A Use Case is a sequence of transactions in a system, whose task is to yield a
measurable value to an individual actor of the system.”
A Use Case Diagram shows a set of external Actors and their Use Cases connected with
communication associations. The communication associations between the Actors and their Use Cases
define the boundary between the system and its external environment. The communication associations
may be augmented to show the messages and events exchanged between Actors and Use Cases. Messages
and events may be shown through relevant notes attached to specific communication associations.
A Use Case Description documents the detailed behavior and assumptions about a particular Use
Case. Sometimes this is accomplished using natural language descriptions. Often, some form of template
is used, accompanied by natural language descriptions of the various execution paths through the Use
Case. Natural language descriptions of the Use Case behavior can be augmented or replaced by
diagrammatic notations, such as UML Activity Diagrams or flow charts.
Supplementary specification normally captures the non-functional requirements of the system like
performance, response time, scalability and design constraints.
Use case
- A use case is a sequence of actions a system performs that yield an observable result of value to
an particular actor.
Withdrawmoney
o To give a clear and consistent description of what the system should do. This allows the model
to be used throughout the development process
o To provide a basis for performing system tests that verify the system
MSIT 41 OOAD with UML 99
o To provide the ability to trace functional requirements into actual classes and operations in the
system
o Extends relationship - it is a generalization relationship where one use case extends another
by adding actions to a general use case. The extending use case may include behavior from the
use case being extended, depending on conditions of extension.
o Uses relationship - it is a generalization relationship where one use case uses another use
case, indicating that as part of the specialized use case, the behavior of the general use case will
also be included.
o Grouping - when a number of use cases handle similar functionality or are related they can be
bundled in a UML package.
Actors
l An actor is someone/something that interacts with the system.
l Actors can be ranked and they can be primary actors(they use systems main functionality ) or
secondary actors(they use secondary functions of the system like managing Dbs, backups etc.)
l Actors can be active in which case they initiate an use case or they can be passive in which
case they participate in an use case.
l They are classes in UML with stereotype <<actor>> and hence can have the same relationship
as classes. In UCD only generalization relationship is used to describe common behavior among
a number of actors.
100 Chapter 8 - Diagrams in UML
Customer
(from Use Case View)
generalization
Commercial
Customer
(from Use Case View)
Fig. 8.1
System
l In use case modeling a system is looked upon as a black box that provides the use cases. How
the system does this, how the use cases are implemented, and how they work internally are not
important.
l It need not necessarily be a software system; it can be a business system as well.
Insurance business
MSIT 41 OOAD with UML 101
Fig. 8.2
(c) Preconditions
some sort of template so that useful information is not overlooked. Every template includes a place for
describing the main processing path of a successful execution of the Use Case, as well as places for
describing the alternative paths contained within the Use Case. See Slide UC-16 for one example of a
Use Case template. As an alternative to, or an augmentation of, the natural language description of
behavior, diagrammatic notations, such as flow charts or activity diagrams can be used. We will discuss
activity diagrams in the next lecture.
Describing Actors
Each Actor (including all devices, timers, external systems, and user roles) should be described, too.
Of main concern are: the specific Stereotype of each Actor, relevant performance data that can affect
the system design, and a description of the interface presented by the Actor, including any error states
that might occur. Slide UC-17 gives a simple, example template for describing Actors.
Supplementary specification
l Supplementary specs. lists the requirements that are not readily captured in the use cases of the
sue case model.
a. Functionality
b. Usability
c. Reliability
d. Performance
e. Supportability
f. Security
g. Design constraints
- Cannot be carried out until there are working parts of the system
l Validation: assures that the system under development is one that the user really needs
MSIT 41 OOAD with UML 103
Combining the Use Cases with implementation details and architecture strategy is often the first step
in planning the testing life cycle. High-level test scenarios are often directly derived from the Use Case
itself [primary course through the Use Case].
Decomposing these test scenarios into individual test scripts is often done by looking for exception
processing conditions [alternate course(s) through the Use Case]. At a minimum, the Use Cases can
directly drive the high level-testing plan.
Another way to describe test cases (since we’re talking about OO here) is that a testing scenario is
simply the instantiation of a Use Case.
Use Cases are implementation-independent descriptions of system functionality of the system. This
means that the use cases are realized in the system, that the responsibilities to perform the actions
described in the use-case descriptions are allocated to collaborating objects that implement the functionality.
- Object diagram
104 Chapter 8 - Diagrams in UML
l A class in a class diagram can be directly implemented in an OOP language that has the construct
for a class.
l To create a class diagram, the classes have to be identified and described and when a number
of classes exist, they can be related to each other using a number of relationships.
Class diagrams show the static structure of the model, in particular, the things that exist (such as
classes and types), their internal structure, and their relationships to other things. Class diagrams do not
show temporal information, although they may contain reified occurrences of things that have or things
that describe temporal behavior. An object diagram shows instances compatible with a particular class
diagram.
Fig. 8.3
MSIT 41 OOAD with UML 105
l Is not so minimalist
l A object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of
a system at a point in time
l The same notations as for class diagrams is sued, with two exceptions : objects are written with
their names underlined and all instances in a relationship are shown.
l They are not as important as class diagrams but can be used to exemplify a complex class
diagram by showing what the actual instances and the relationships could look like.
An object diagram shows the existence of objects and their relationships in the logical design of a
system. An object diagram may represent all or part of the object structure of a system, and primarily
illustrates the semantics of mechanisms in the logical design. A single object diagram represents a snapshot
in time of an otherwise transitory event or configuration of objects.
An object diagram is a graph of instances, including objects and data values. A static object diagram is
an instance of a class diagram.
The use of object diagrams is fairly limited, mainly to show examples of data structures.
Tools need not support a separate format for object diagrams. Class diagrams can contain objects, so
a class diagram with objects and no classes is an “object diagram.”
106 Chapter 8 - Diagrams in UML
c:company
Link
object
d1:department
:Department
Name=“sales”
Name=“R&D”
Anonymous object
Attribute Value
Fig. 8.4
In v o i c e
In v o ic e D e s tro y e d
C re a ted P a y in g
U n p a id P a id
I n s u ra n c e b u s in e s s
Fig. 8.5 A state diagram for invoices
Statechart diagram
l A state can have three compartments. The first shows the state name, the second shows the
state variables and the third is the activity compartment where activity and events maybe listed.
m Collaboration diagram
Sequence Diagram
A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the
objects participating in the interaction by their “lifelines” and the messages that they exchange arranged
in time sequence. It does not show the associations among the objects. Sequence diagrams come in
several slightly different formats intended for different purposes. A sequence diagram can exist in a
generic form (describes all the possible sequences) and in an instance form (describes one actual sequence
consistent with the generic form). In cases without loops or branches, the two forms are isomorphic.
Sequence Diagram
Fig. 8.7 Sequence diagram with focus of control, conditional, recursion, creation, destruction
On a procedural sequence diagram (one with focus of control and calls) subsequent arrows on the
same lifeline map into Messages obeying the predecessor association. An arrow to the head of a focus
of control region establishes a nested activation; it maps into a Message (synchronous, activation) with
associated CallAction (holding the arguments and referencing the target Operation) between the
ClassifierRoles corresponding to the lifelines. All arrows departing the nested activation map into Messages
with an activation Association to the Message corresponding to the arrow at the head of the activation.
A return arrow departing the end of the activation maps into a Message (synchronous, reply) with an
activation Association to the Message corresponding to the arrow at the head of the activation and a
110 Chapter 8 - Diagrams in UML
predecessor association to the previous message within the same activation. A return must be the
final message within a predecessor chain; it is not the predecessor of any message. Any guard conditions
or iteration conditions attached to a message arrow become recurrence values of the Message. The
operation name is used to select the target Operation with the given name. The operation arguments
become argument Expressions on the Action.
Object Lifeline
l Within a sequence diagram the existence and duration of the object in a role is shown
l If the object is created during the diagram, then the message that creates it is drawn with its
arrowhead on the object symbol
l If the object is destroyed during the diagram, then its destruction is marked by a large “X”
A Role is a slot for an object within a collaboration that describes the type of object that may play the
role and describes its relationships to other Roles. Within a sequence diagram the existence and duration
of the object in a role is shown, but the relationships among the roles is not shown. There are ClassifierRoles
and AssociationRoles.
An object role is shown as a vertical dashed line called the “lifeline”. The lifeline represents the
existence of the object at a particular time. If the object is created or destroyed during the period of time
shown on the diagram, then its lifeline starts or stops at the appropriate point; otherwise it goes from the
top to the bottom of the diagram. An object symbol is drawn at the head of the lifeline; if the object is
created during the diagram, then the message that creates it is drawn with its arrowhead on the object
symbol. If the object is destroyed during the diagram, then its destruction is marked by a large “X”, either
at the message that causes the destruction or (in the case of self-destruction) at the final return message
from the destroyed object. An object that exists when the transaction starts is shown at the top of the
diagram (above the first arrow). An object that exists when the transaction finishes has its lifeline continue
beyond the final arrow.
The lifeline may split into two or more concurrent lifelines to show conditionality. Each separate track
corresponds to a conditional branch in the message flow. The lifelines may merge together at some
subsequent point.
Activation
MSIT 41 OOAD with UML 111
l An activation (focus of control) shows the period during which an object is performing an action
either directly or through a subordinate procedure
l It represents
ii. The control relationship between the activation and its callers
l An activation is shown as a tall thin rectangle whose top is aligned with its initiation time and
whose bottom is aligned with its completion time
An activation is shown as a tall thin rectangle whose top is aligned with its initiation time and whose
bottom is aligned with its completion time. The action being performed may be labeled in text next to the
activation symbol or in the left margin, depending on style; alternately the incoming message may indicate
the action, in which case it may be omitted on the activation itself. In procedural flow of control, the top of
the activation symbol is at the tip of an incoming message (the one that initiates the action) and the base
of the symbol is at the tail of a return message.
In the case of concurrent objects each with their own threads of control, an activation shows the
duration when each object is performing an operation; operations by other objects are not relevant. If the
distinction between direct computation and indirect computation (by a nested procedure) is unimportant,
the entire lifeline may be shown as an activation. In the case of procedural code, an activation shows the
duration during which a procedure is active in the object or a subordinate procedure is active, possibly in
some other object. In other words, all of the active nested procedure activations may be seen at a given
time. In the case of a recursive call to an object with an existing activation, the second activation symbol
is drawn slightly to the right of the first one, so that they appear to “stack up” visually. (Recursive calls
may be nested to an arbitrary depth.)
Message
l A message is a communication between objects that conveys information with the expectation
that action will ensue
l A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of
another object
112 Chapter 8 - Diagrams in UML
l The arrow is labeled with the name of the message (operation or signal) and its argument values
l The arrow may also be labeled with a sequence number to show the sequence of the message
in the overall interaction
A message is a communication between objects that conveys information with the expectation that
action will ensue. The receipt of a message is one kind of event.
A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another
object. In case of a message from an object to itself, the arrow may start and finish on the same object
symbol. The arrow is labeled with the name of the message (operation or signal) and its argument values.
The arrow may also be labeled with a sequence number to show the sequence of the message in the
overall interaction. Sequence numbers are often omitted in sequence diagrams, in which the physical
location of the arrow shows the relative sequences, but they are necessary in collaboration diagrams.
Sequence numbers are useful on both kinds of diagrams for identifying concurrent threads of control. A
message may also be labeled with a guard condition.
Transition Times
l A message may have a sending time and a receiving time
i. The two may be the same (if the message is considered atomic)
l These are formal names that may be used within constraint expressions
l In cases where the delivery of the message in not instantaneous, the time at which the message
is received is indicated by the transition name with a prime sign appended
l Constraints may be specified by placing Boolean expressions in braces on the sequence diagram
A message may have a sending time and a receiving time. These are formal names that may be used
within constraint expressions. The two may be the same (if the message is considered atomic) or different
(if its delivery is nonatomic).
name may be shown in the left margin aligned with the arrow (on a sequence diagram) or near the tail of
the message flow arrow (on a collaboration diagram). This name may be used in constraint expressions to
designate the time the message was sent. If the message line is slanted, then the primed-name indicates
the time at which the message is received.
Constraints may be specified by placing Boolean expressions in braces on the sequence diagram.
· Unlike a sequence diagram, a collaboration diagram shows the relationships among the object
roles
· On the other hand, a collaboration diagram does not show time as a separate dimension
· the sequence of messages and the concurrent threads must be determined using sequence
numbers
A collaboration diagram shows an interaction organized around the objects in the interaction and their
links to each other. Unlike a sequence diagram, a collaboration diagram shows the relation-ships among
the object roles. On the other hand, a collaboration diagram does not show time as a separate dimension,
so the sequence of messages and the concurrent threads must be determined using sequence numbers.
Collaboration
l The structure of objects playing roles in a behavior and their relationships is called a collaboration
l A collaboration may be attached to an operation or a use case to describe the context in which
their behavior occurs
In a collaboration behavior is implemented by sets of objects that exchange messages within an overall
114 Chapter 8 - Diagrams in UML
A collaboration is a set of participants and relationships that are meaningful for a given set of purposes.
The identification of participants and their relationships does not have global meaning. A collaboration
may be attached to an operation or a use case to describe the context in which their behavior occurs. The
actual behavior may be specified in interactions, such as sequence diagrams or collaboration diagrams. A
collaboration may also be attached to a class to define the class’s static structure.
Collaboration
l A collaboration shows the context in which interaction occurs
l Different sets of messages may be applied to the same collaboration to yield different interactions
Collaboration Diagram
l A collaboration diagram represents
- A Collaboration,
- An Interaction
l A collaboration diagram is a graph of references to objects and links with message flows attached
to its links
l The internal messages that implement a method are numbered starting with number 1
l For a procedural flow of control the subsequent message numbers are nested in accordance
with call nesting
context, and an Interaction, which is a set of messages exchanged among the objects within a collaboration
to effect a desired operation or result.
Collaboration Diagram
Fig. 8.8
A collaboration diagram is a graph of references to objects and links with message flows attached to
its links. The diagram shows the objects relevant to the performance of an operation, including objects
indirectly affected or accessed during the operation. The collaboration used to describe an operation
includes its arguments and local variables created during its execution as well as ordinary associations.
Objects created during the execution may be designated as {new}; objects destroyed during the execution
maybe designated as {destroyed}; objects created during the execution and then destroyed may be
designated as {transient}. These changes in life state are derivable from the detailed messages sent
among the objects; the are provided as notational conveniences.
- Deployment diagram
116 Chapter 8 - Diagrams in UML
l Dependencies, are shown as dashed arrows from a client component to a supplier component
that it depends on in some way
Component Diagrams
Fig. 8.9
A component diagram shows the dependencies among software components, including source code
components, binary code components, and executable components. A software module may be rep-
resented as a component type. Some components exist at compile time, some exist at link time, and some
exist at run time; some exist at more than one time. A compile-only component is one that is only meaningful
at compile time; the run-time component in this case would be an executable program.
The components are the implementation in the physical architecture of the concepts and the functionality
defined in the logical architecture ( classes, objects, their relationships, and collaborations).
Source Components is meaningful at compile time. It is typically a source code file implementing one
or more classes.
Binary component is typically object ocde that is the result of compiling a sourse component. It could be
an object code file, a static library file, or a dynamic library file. A binary component is meaningful at link
MSIT 41 OOAD with UML 117
Executable component is an executable program file that is the result of linking all binary components.
An executable component represents the executable unit that is run by a processor (computer).
Component Diagrams
l The diagram may also be used to show interfaces and calling dependencies among components,
using dashed arrows from components to interfaces on other components.
l The kinds of dependencies are language-specific and may be shown as stereotypes of the
dependencies.
The dependency connection between components, means that one component needs another to be
able to have a complete definition.
A component can define interfaces that are visible to other components. The interfaces can be both
interfaces defined at the source-code level or binary interfaces used at run time.
A dependency from one source code component A to another component B means that there is a
language-specific dependency from A to B. In a compiled language, it could mean that a change in B will
require a recompilation of A, because definitions from component B are used when compiling A. If the
components are executable, dependency connections are used to identify which dynamic libraries an
executable program needs to be able to run.
Components are types, but only executable components may have instances ( which they have when
the program they represent is executing in a processor). A component diagram shoes only components
as types. To show instances of components, a deployment diagram must be used, where instances of
executable components are allocated to node instances in which they execute.
118 Chapter 8 - Diagrams in UML
Realization
Extended components
Dependency
System:dialog.dll
{version=4.1.3}
Fig. 8.10
Components
l A component type represents a distributable piece of implementation of a system, including
software code (source, binary, or executable)
l Components may be used to show dependencies, such as compiler and run-time dependencies
- Used to show implementation units that have identity at run time, including their location on
nodes
MSIT 41 OOAD with UML 119
l A component is shown as a rectangle with two small rectangles protruding from its side.
Components
Fig. 8.11
A component is shown as a rectangle with two small rectangles protruding from its side.
component-type
A component instance has a name and a type. The name of the component and its type may be
shown as an underlined string either within the component symbol or above or below it, with the
syntax:
Compile-Time components
l Components that contain the code produced in the projects.
l Stereotypes that can be used
< <file>> representation of a source file
<<page>> representation of a web page
<<document>> representation of document( documentation)
Compile-Time components
<< page>> < < file > > < < d o c u m e n t> >
h o m e .h tm l a n im lo g o .ja v a a n im lo g o .d o c
Fig. 8.12
A dependency from one compile-time component to other compile-time components reveal which
components are needed to make its definition complete; for instance, which other compile-time components
does it include in its definition.
The result of compilation of one or more compile-time components is to produce link-time components.
Run-Time components
l Represents a component used when executing the system
Fig. 8.13
MSIT 41 OOAD with UML 121
A run-time instance of a component indicates that, from the component type, several processes are
instantiated to run the application represented in the component file. The dependencies from a run-time
component are other components needed for its execution: dynamic link libraries, image files, or database
tables.
m This indicates that one component uses the services of another component; a stereotype may be
used to indicate the precise dependency if needed.
m Stereotypes supported
The deployment type diagram may also be used to show which components may run on which nodes,
by using dashed arrows with the stereotype «supports».
Migration of components from node to node or objects from component to component may be shown
using the «becomes» stereotype of the dependency relationship. In this case the component or object is
resident on its node or component only part of the entire time. Note that a process is just a special kind of
object
Deployment Diagrams
clientA:IB
M PC
<<TCP/IP>>
<<TCP/IP>> Application
ClientB: Server:
IBM PC
Fig. 8.14
MSIT 41 OOAD with UML 123
Connections are shown as normal associations, indicating that there is some sort of communications
path between them, and that the nodes exchange objects or send messages through that communication
path. The communication type is represented by a stereotype that identifies the communication protocol
or the network used.
An object is placed inside a node instance to indicate where it resides on that instance. The object can
either be active ( with stereotype <<process>> or <<thread>> and drawn with a thick line), which executes
on the node, or passive. The object is contained within another object or within a component.
Nodes
m A node is a run-time physical object that represents a processing resource, generally having at
least a memory and often processing capability
m Nodes include computing devices but also human resources or mechanical processing resources
m Run time computational instances, both objects and component instances, may reside on node
instances
m A node is shown as a figure that looks like a 3-dimensional view of a cube. A node type has a
type name: node-type
A node is a run-time physical object that represents a processing resource, generally having at least a
memory and often processing capability as well. Nodes include computing devices but also human resources
or mechanical processing resources.
Nodes may be represented as type and as instances. A type describes the characteristics of a processor
or device type and an instance represents actual occurrences of the type. The detailed definition of the
capability of the system can be defined either as attributes or as properties defined for nodes.
Devices in the system are also represented as nodes, typically with a stereotype that specifies the
device type, or at least with a name that clearly defines it as a device node and not a processor node.
Run time computational instances, both objects and component instances, may reside on node instances.
Two nodes containing an object (cluster) that migrates from one node to another and also an object
that remains in place.
node-type
A node instance has a name and a type name. The node may have an underlined name string in it or
below it. The name string has the syntax:
Nodes
Fig. 8.15
The name is the name of the individual node (if any). The node-type says what kind of a node it is.
Either or both elements are optional. Dashed-arrow dependency arrows show the capability of a node
type to support a component type. A stereotype may be used to state the precise kind of dependency.
Component instances and objects may be contained within node instance symbols. This indicates that the
items reside on the node instances.
Nodes may be connected by associations to other nodes. An association between nodes indicates a
communication path between the nodes. The association may have a stereotype to indicate the nature of
the communication path (for example, the kind of channel or network).
MSIT 41 OOAD with UML 125
3. Implementation diagram
- Component diagram, Deployment diagram
126 Chapter 9 - Extensibility Mechanisms
Chapter 9
Extensibility Mechanisms
9.0 INTRODUCTION
l They are general purpose mechanisms that may be applied to any modeling element
- Tagged values
- Stereotypes
General-purpose mechanisms are elements that may be applied to any modeling element. The semantics
of a particular use depends on a convention of the user or an interpretation by a particular constraint
language or programming language, therefore they constitute an extensibility device for UML.
9.1 OBJECTIVES :
At the end of this unit, You would be able to:
l Understand these Dynamic view diagrams:- State diagram, Interaction diagram, Activity diagram
A constraint is a semantic relationship among model elements that specifies conditions and propositions
that must be maintained as true (otherwise the system described by the model is invalid, with consequences
that are outside the scope of UML). Certain kinds of constraints (such as an association “or” constraint)
are predefined in UML, others may be user-defined. A user-defined constraint is described in words in a
given language, whose syntax and interpretation is a tool responsibility. A constraint represents semantic
information attached to a model element, not just to a view of it.
l The individual tools may provide one or more languages in which formal constraints may be
written.
l Constraint may be a “comment”: it that case it is written in text for “interpretation” by a human.
l A comment is shown by a text string placed within a note symbol that is attached to a model
element. The braces are omitted to show that this is purely a textual comment.
Fig. 9.1
MSIT 41 OOAD with UML 129
l Property is used in a general sense to mean any value attached to a model element, including
attributes, associations, and tagged values
l A tagged value is a keyword-value pair that may be attached to any kind of model element
Many kinds of elements have detailed properties that do not have a visual notation. In addition, users
can define new element properties using the tagged value mechanism. A string may be used to display
properties attached to a model element.
Note that we use property in a general sense to mean any value attached to a model element, including
attributes, associations, and tagged values.
A tagged value is a keyword-value pair that may be attached to any kind of model element (including
diagram elements as well as semantic model elements). The keyword is called a tag. Each tag represents
a particular kind of property applicable to one or many kinds of model elements. Both the tag and the
value are encoded as strings. Tagged values are an extensibility mechanism of UML permitting arbitrary
information to be attached to models. It is expected that most model editors will provide basic facilities for
defining, displaying, and searching tagged values as strings but will not otherwise use them to extend the
UML semantics. It is expected, however, that back-end tools such as code generators, report writers, and
the like will read tagged values to alter their semantics in flexible ways.
Example:
{ author = “Joe Smith”, deadline = 31-March-1997, status = analysis }
{ abstract }
130 Chapter 9 - Extensibility Mechanisms
Fig. 9.2
9.4 STEREOTYPES
l A stereotype is, in effect, a new class of modeling element that is introduced at modeling time
l It represents a subclass of an existing modeling element with the same form (attributes and
relationships) but with a different intent
l A stereotyped element may have additional constraints on it from the base class
A stereotype is, in effect, a new class of modeling element that is introduced at modeling time. It
represents a subclass of an existing modeling element with the same form (attributes and relationships)
but with a different intent. Generally a stereotype represents a usage distinction. A stereotyped element
may have additional constraints on it from the base class. It is expected that code generators and other
tools will treat stereotyped elements specially. Stereotypes represent one of the built-in extensibility
mechanisms of UML.
The general presentation of a stereotype is to use the symbol for the base element but to place a key-
word string above the name of the element (if any); the keyword string is the name of the stereotype
within matched guillemets, which are the quotation mark symbols used in French and certain other
languages, as for example: «foo». (Note that a guillemet looks like a double angle-bracket but it is a single
character in most extended fonts. Most computers have a Character Map utility. Double angle-brackets
MSIT 41 OOAD with UML 131
may be used as a substitute by the typographically challenged.) The keyword string is generally placed
above or in front of the name of the model element being described. The keyword string may also be used
as an element in a list, in which case it applies to subsequent list elements until another stereotype string
replaces it, or an empty stereotype string («») nullifies it. Note that a stereotype name should not be
identical to a predefined keyword applicable to the same element type.
l The general presentation of a stereotype is to use the symbol for the base element but to place
a keyword string above the name of the element (if any)
l The keyword string is the name of the stereotype within matched guillemets, as for example:
«extends»
l The classification hierarchy of the stereotypes themselves could be displayed on a class diagram
To permit limited graphical extension of the UML notation as well, a graphic icon or a graphic marker
(such as texture or color) can be associated with a stereotype. The UML does not specify the form of the
graphic specification, but many bitmap and stroked formats exist (and their portability is a difficult problem).
The icon can be used in one of two ways: it may be used instead of or in addition to the stereotype
keyword string as part of the symbol for the base model element that the stereotype is based on; for
example, in a class rectangle it is placed in the upper right corner of the name compartment. In this form,
the normal contents of the item can be seen. Alternately, the entire base model element symbol may be
“collapsed” into an icon containing the element name or with the name above or below the icon. Other
information contained by the base model element symbol is suppressed. More general forms of icon
specification and substitution are conceivable but we leave these to the ingenuity of tool builders, with the
warning that excessive use of extensibility capabilities may lead to loss of portability among tools.
UML avoids the use of graphic markers, such as color, that present challenges for certain persons (the
color blind) and for important kinds of equipment (such as printers, copiers, and fax machines). None of
the UML symbols require the use of such graphic markers.
Users may use graphic markers freely in their personal work for their own purposes (such as for
highlighting within a tool) but should be aware of their limitations for interchange and be prepared to use
the canonical forms when necessary.
132 Chapter 9 - Extensibility Mechanisms
Stereotypes - Examples
Fig. 9.3
5. What are some of the forms of association? Draw their UML representations.
2. UML can be used to model a broad range of systems, a few of which are information systems, technical
systems, ______systems, _____ systems and ____ systems.
3. UML represents a collection of best engineering practices that have proven successful in the modeling of
_____ and ____ systems.
4. A Use Case Diagram shows a set of external Actors and their Use Cases connected with communication
associations. The communication associations between the ______ and their _______ define the boundary
between the system and its external environment.
5. An object diagram is a graph of instances, including objects and data values. A static object diagram is an
instance of a ________diagram.
6. Class diagrams show the static structure of the model, in particular, the things that exist (such as classes
and types), their internal ________, and their __________ to other things
7. A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the objects
participating in the interaction by their _______ and the __________ that they exchange arranged in time
sequence
8. A collaboration diagram shows an interaction organized around the objects in the ______ and their
_______ to each other. Unlike a sequence diagram, a collaboration diagram shows the relation-ships
among the object roles.
10. Deployment diagrams show the configuration of run-time processing elements and the software components,
processes, and ______ that live on them. Software component instances represent _________ manifestations
of code units
134 Chapter 9 - Extensibility Mechanisms
(a) To model systems using OO concepts, and To establish an explicit coupling to conceptual as well as
executable artifacts
2. UML model is
3. RUP is
i. dependency
MSIT 41 OOAD with UML 135
ii. association
iii. generalization
iv. realization
6. Extensibility Mechanisms
a. Stereotype
b. Tagged value
c. Constraint
7. Operation:
3. An operation is shown as a text string that can be parsed into the various properties of an operation
model element
a. Component diagram
b. Deployment diagram
(b) Actors
(c) Grouping