Beruflich Dokumente
Kultur Dokumente
Prabhudeva S.
Assistant professor
Department of Computer Science and engineering.
J N N C E, Shimoga.
OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML
CONTENTS
5.0 Objectives
5.1 Introduction
5.2 UML and brief background
5.2.1 Architecture of UML
5.2.2 Why is UML powerful?
5.2.3 What is a process?
5.2.4 Phases and Iterations
5.3 Steps in UML
5.4 Modeling and UML
5.5 Goals of UML
5.6 Outside The Scope Of UML
5.7 An overview of UML
5.7.1 Views
5.7.2 Modeling elements
5.7.3 Relationships
5.7.4 UML diagrams
5.7.5 Extensibility mechanisms
6.0 Introduction
6.1 Objectives
6.2 Class
6.2.1 Attribute
6.2.1.1 Attribute Compartment
6.2.1.2 Attribute Scope
6.2.1.3 Derived Element
6.2.2 Operation
6.3 Object
6.4 Interface
6.5 Packages
8.0 Introduction
8.1 Objectives
8.2 Use Case model
8.3 Static view diagram
8.3.1 Class diagram
8.3.2 Object diagram
8.4 Dynamic view diagram
8.4.1 Statechart diagram
8.4.2 Interaction diagram
8.4.2.1 Sequence diagram
8.4.2.2 Collaboration diagram
8.5 Implementation diagram
8.5.1 Component diagram
8.5.2 Deployment diagram
8.6 Summary of Diagrams in UML
1.1 INTRODUCTION
Systems 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:
Define the software
Define the quality software
Understand the pitfalls of top-down design
Understand the Merits of object approach
1.3 What is software?
The study of computer can be broadly classified into hardware and software. Software is
the term associated with the programs that are written to manage the various resources of
a computer system and perform certain designated useful tasks. Software can be further
classified into system software and application software. Software that is embedded in
the hardware is called as firmware.
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.
Object-Orientation really can provide tools to produce software of higher quality.
1.4 High-Quality software
The software process transforms the users’ needs via the application domain to a
software solution that satisfies those needs. Once the system (programs) exists, we must
test it to see if it is free of bugs. High-quality products must meet users’ needs and
expectations.
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?).
Validation
verification
correctness
correspondence
Fig : 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.
Summary
• Algorithms + Data structures = Programs
– Correct
– Robust
– Extendible
– Reusable
-- Compatible
• Pitfalls of top-down design
- Functional viewpoint is difficult to evolve
- Real systems are hard to characterize functionally
- Functional approach loses focus of data
- Traditional approach produces less reusable code
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 _______.
Review Questions
1 What is software ?
2 What is computer programming?
3 What is quality software ? explain.
4. What are the external characteristics of good quality software ?
5. How object method succeeds ? explain.
6. Where does the traditional approach fail ? explain.
7. What are the Pitfalls of top-down design ? explain.
8. What are the merits of object approach? explain.
UNIT 2: The Object Model
2.0 Introduction
Object-Oriented technology is built upon a sound engineering foundation, whose
elements are collectively call 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 than 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:
Define the OOA, OOD, OOP
Define the Major elements of object model
Define the Minor elements of object model
Understand the concept of Abstraction, Encapsulation, Modularity, Hierarchy
Understand the concept of Typing, Concurrency, Persistence
Book
title
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.
Abstraction Modularity
OO Model
Encapsulation Hierarchy
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 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.
Interface and Implementation
- An interface is the outside view of a class, object, or module, which emphasizes its
abstraction while hiding its structure and its secrets of its behavior and it does not specify
internal structure.
- 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.
The interface of a class can be divide into three parts:
• Public A declaration that is accessible to all clients
The meaning of modularity as Myers observes is “the act of partitioning a program into
individual 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
Abstraction is a good thing, but in all except the work trivial applications, we may find
many more 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.
Ranking of abstraction helps. A set of abstractions often forms a hierarchy, and by
identifying these hierarchies in our design, we greatly simplify our understanding of the
problem.
The two most important hierarchies in a complex system are its class structure (the “is a”
hierarchy) and its object structure (the “part of” hierarchy).
CLASS OBJECT
STRUCTURE STRUCTURE
“is a” “part of “
hierarchy hierarchy
Bank
Account
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
• An Abstract Class is a class that is used only as a base class for other classes or
subclasses
• We do not (need not, or even cannot) Instantiate from an abstract class
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.
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.
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.
Examples of hierarchy : Aggregation
Aggregation as a “Part-Of” Hierarchy
Aggregation is not a concept unique to object-oriented programming languages. Indeed,
any language that supports record-like structures supports aggregation. However, the
combination of inheritance with aggregation is powerful: aggregation permits the
physical grouping of logically related structures, and inheritance allows these common
groups to be easily reused among different abstractions. Aggregation raises the issue of
owner ship.
Garden
“has a” “part of”
GardeningPlan Plant
Delegation
• 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.
• Typing
• Concurrency
• Persistence
2.5.1 Typing
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.
Static and Dynamic Binding
• Strong typing and static typing are entirely different
• Static typing refers the time when names are bound to types; also known as early
binding
• Static binding means that the types of all variables and expressions are fixed at
compile time
• 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).
• Power of polymorphism
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.
Overriding vs Overloading
• Overriding
An operation is redefined within a subclass
• 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 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
• Concurrency is that property that distinguishes an active object from one that is
not active
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.
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
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.
Why is Persistence Important?
• Unifying Persistence with Object Model, we get Object Oriented databases
• Offers the programmers of database systems the abstraction power of object
technology
• Smalltalk provides support for persistence
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.
Summary
Object-oriented system development consists of
Object-oriented analysis
Object-oriented information modeling
Object-oriented design
Prototyping and implementation
Testing, Iteration, and Documentation.
Four major Elements of Object Model :Abstraction, Encapsulation, Modularity,
Hierarchy.
Abstraction
• Abstraction is one of the fundamental elements of the object model.
Encapsulation
• 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
• Modularization consists of dividing a program into modules which can be
compiled separately, but which have connection with other modules
• The connections between modules are the assumptions which the modules make
about each other
• Cohesion is the interdependency within a module and coupling is the dependency
between modules
• Good design stipulates ‘high cohesion and low coupling’
Hierarchy
• Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify
the understanding of our problem
• Hierarchy is a ordering of abstractions
Inheritance
- Inheritance is an important “is-a” hierarchy and defines relationships among classes,
wherein one class shares the structure and behavior defined in another class
- Subclasses inherit from one or more superclasses
- A subclass typically redefines or augments the existing structure and behavior of its
superclasses
Abstract Class
• An Abstract Class is a class that is used only as a base class for other classes or
subclasses
• We do not (need not, or even cannot) Instantiate from an abstract class
- Overriding vs Overloading
• Overriding : An operation is redefined within a subclass.
• Overloading : An operation will have various unique signatures.
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).
Why is Persistence Important?
• Unifying Persistence with Object Model, we get Object Oriented databases
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.
Objective type questions:
1. Object oriented programming is a
a. Programming paradigm
b. An application generator
c. A case technique
d. A software system
e. None of the above.
Review Questions
1. Define object oriented analysis
2. Define object oriented design
3. Define object oriented programming
4.What is Object-oriented Analysis and Design ? explain.
5. What are the Major Elements of Object Model? explain.
6. What are the Minor Elements of Object Model? explain.
7. Explain how encapsulation violate with inheritance?
8. What is an abstract class? explain briefly.
9. With an example, explain (i) Single inheritance & (ii) multiple inheritance.
10. What is delegation? Explain with an example.
11. What Does Dynamic Binding Offer for Object Orientation?
12. Compare and contrast Overriding with Overloading.
13. Why is Persistence Important?
3.1 Objectives
At the end of this unit, You would be able to:
Define the terms: Object and class
Understand the concept of Relationships among Objects
Understand the concept of Relationships among Classes
3.2 Object
• Attributes (or properties) describe the state (or data) of an object and Methods
(or procedures) define its behavior.
• In Object Oriented method, 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
1. Remember things
2. Have well-defined responsibilities
3. To collaborate with other objects to achieve its goals
- 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.
In object-oriented programming, each element in a program must be an object. An object
is a lexical unit (or module) that encapsulates all of the memory and behavior needed to
perform a specified set of services. The memory and behavior associated with an object is
available through an interface that declares the operations that an object provides, the
parameters needed to perform each operation, and the results returned by each operation.
Conceptually, computation in an object-oriented program occurs through message
exchange among a collection of objects. Messages are sent between objects to request
operations and to return results. Each object in an object-oriented program has its own
individual state (typically represented in a run-time stack or other memory allocation) and
its own individual identity (typically represented through a unique number called an
object identifier, or OID). Beyond the variable state information and the unique context,
an object also shares some executable code (often called methods) to implement the
services that the object provides.
3.2.2 Relationships among objects
There are two kinds of relationships :
• Links
• Aggregation / Composition
Aggregation and composition are two related (and often confused) relationships that
associate a whole with its parts. For example, a team aggregates players. As another
example a car (the whole) might be constructed of an engine, some wheels, and a drive
train (its parts). As yet another example, a user process (the whole) within a computer
operating system might be constructed from a program memory, some stack space, and
an execution context (its parts). Both aggregation and composition enable modeling at
two-levels of abstraction: the whole or the part. The differences between aggregation and
composition are somewhat subtle (and probably even controversial).
Example: Aggregation
Example: Composition
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 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: 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
* Parts have existence and identity outside the whole
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.
* Parts are associated with only one whole
* Navigation from whole to parts is assured
* Whole owns its parts
* Parts have no existence or identity outside the whole
Trade Off between Links and Aggregation
• Aggregation is sometimes better because it encapsulates parts as secrets of its
whole
• Links are sometimes better because they permit looser coupling among objects
This is a tactical design decision
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
It contains the description or definition of attributes and methods an object will have
They have data structure and behavior and relationships to other elements
We say that we create or instantiate object(s) using a class
• The executable code for an object is typically associated with a class, rather than
with each individual object generated from the class
3.3.1 Definition : A class is a set of objects that share a common structure and a
common behavior.
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.
• Class Attributes
– The attribute value belongs to the class and objects do not maintain independent
values
• 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
Methods/Operations make it possible to connect algorithm (behavior) with an object
Whereas attributes describe static characteristics of objects, methods describe the
behavior of an object, that is, the services that an object can provide
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 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.
3.3.2 Relationships Among Classes
• Association
• Generalization
– Also called Inheritance or Specialization
• Dependencies
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
b. Client and Server may be aware of each others existence
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 N 1 Sale
ssSS
Product last Sale
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
Example for reflexive association
Association End
An association Role 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
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
* drives *
person car
Driver Company car
N-Ary Association
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
Multiplicity may be indicated
An n-ary association is shown as a large diamond with a path from the diamond to
each participant class
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.
Generalization
Is a relationship between a more general element and a more specific element
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
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
Indicates a semantic relationship between two (or more) classes
It indicates a situation in which a change to the target element may require a
change to the source element in the dependency
A dependency is shown as a dashed arrow between two model elements
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
• Attributes (or properties) describe the state (or data) of an object and Methods
(or procedures) define its behavior.
• 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
• Remember things
• Aggregation / Composition
Class
It contains the description or definition of attributes and methods, an object will have
They have data structure and behavior and relationships to other elements
We say that we create or instantiate object(s) using a class
The executable code for an object is typically associated with a class, rather than with
each individual object generated from the class
Attribute
• An attribute is a descriptor of an instance. It tells us something important and
significant about the nature of an instance
• Examples of attributes are length, height, weight, color, date of birth, cost etc.
Methods / Operations
Methods/Operations make it possible to connect algorithm (behavior) with an
object
Whereas attributes describe static characteristics of objects, methods describe the
behavior of an object, that is, the services that an object can provide
Each method has a name and a body
• Generalization
• Dependencies
Association
An Association is a set of relationships between or among classes
Client and Server may be aware of each others existence
Association End
An association role 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
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
N-Ary Association
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
Multiplicity may be indicated
An n-ary association is shown as a large diamond with a path from the diamond to
each participant class
The name of the association (if any) is shown near the diamond
Generalization
Is a relationship between a more general element and a more specific element
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
Generalization may be applied to associations as well as classes
Dependency
Indicates a semantic relationship between two (or more) classes
It indicates a situation in which a change to the target element may require a
change to the source element in the dependency
A dependency is shown as a dashed arrow between two model elements
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
3.5 Review Questions
1. Define the following terms
(a) Object (b) Class
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.
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
4.1 Objectives :
- Discussion on
• Object oriented analysis
• Object oriented design.
- At the end of this unit, You would be able to:
Understand the various activities of OOA Phase
Understand the various activities of OOD Phase
Understand the concept of CRC model
Understand the Software problems
Best practices of Software Engineering
OOD Phase
• Overall question is “How?”
• 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.
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.
4.2.1.1 Creating Classes
• The goal of the class creation activity is to come up with a list of all classes that
might possibly be part of your system, called candidate classes, and then determine
which classes that you really want in the system, and which classes are outside it.
• Where do candidate classes done from?
First and foremost, candidate classes come from brainstorming about the problem
domain. Write down as many possible classes as you can think of, as quickly as you can.
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.
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.
4.2.1.3 CRC Modeling
A CRC model is really a collection of standard index cards that represent classes.
classes
The cards are divided into three sections
• Along the top of the card: write the name of the class
The class name of an object creates a vocabulary for discussing a design. Indeed, many
people have remarked that object design has more in common with language design than
with procedural program design. We need to find just the right set of words to describe
our objects, a set that is internally consistent and evocative in the context of the larger
design environment.
Responsibilities identify problems to be solved. The solutions will exist in many versions
and refinements. A responsibility serves as a handle for discussing potential solutions.
The responsibilities of an object are expressed by a handful of short verb phrases, each
containing an active verb. The more that can be expressed by these phrases, the more
powerful and concise the design. Again, searching for just the right words is a valuable
use of time while designing.
An active responsibility starts with an active verb, such as "track", "compute" or "find".
Avoid the word "manage" where possible, and the passive verb, "hold". Also we have the
contact point responsibilities, the information the component mediates. Often these will
come from the attributes in a data or business model. If there is some question whether a
service belongs in the active or contact point responsibility section, choose arbitrarily
with a slight inclination toward the contact point section. It really does not matter a great
deal. In the end, all responsibilities will be treated equally. The purpose in having the
sections is so that attention can be focused on the summary and active responsibilities,
which are the primary vehicle for partitioning the system. The contact point
responsibilities are needed for component specification, and to demonstrate how the
components deliver the required function in a documented scenario.
Class name
Responsibilities Collaborators
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.
Where do responsibilities come from?
Most of the responsibilities in your system will initially come from you requirements
document which is, after all, a list of all of the requirements in the system. Frequently,
the combination of system requirements along with the classes in your system will imply
further responsibilities. For example, a system responsibility to "sum the prices of items"
might imply that an item class has the responsibility to "know my price".
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.
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.
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:
• It is general, and thus reusable.
• 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.)
• Responsibility, control, and communication is distributed. One object doesn't do
everything. Makes it easier to reuse, easier to develop and manage.
• Minimize assumptions of language or system. Try to describe the world, not a program.
• Define objects not functions or managers. Objects are nouns.
• Do not include things you do not need, even if it is part of the real world. Sure,
everything is made up of molecules, but you probably don't need a molecules class.
• Good hierarchy is always linked by IsA relationships.
• Attributes and services should be factored out as high in the hierarchy as possible.
• It should be easy to add on to, and thus reusable.
• There should be little or no redundancy.
• Again, objects are NOUNS.
4.2.2 OOD Phase
What to do during OOD?
The primary goal is to convert our OOA into something that we could actually
implement
OOD is concerned with how information flows through the system
There are two activities in the OOD phase
• Assigning attributes and services
• Assigning Responsibilities.
• Implementation - You can see how do you write code from here.
• 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.
• 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.)"
• 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.
• Removes unnecessary middlemen. If A needs to reach B, but can only do it through
C...think about allowing A to reach B directly.
• Requirements churn
• Hard to maintain
• Build-and-release issues
2. The design process is typically split into two distinct phases:_____ and _______.
4.6 Objective type questions
1. During OOA :
i. Determine the functionality of the system, usually called
requirements analysis.
ii. Create a list of what classes are part of the system, and (just as
important) what classes are not part of the system.
iii. Distribute the functionality of the system among the list of classes.
A piece of functionality assigned to a specific class is called a
responsibility.
iv. All the above.
v. None of the above.
2. During OOD :
a. The primary goal is to convert our OOA into something that we
could actually implement
b. OOD is concerned with how information flows through the system
c. There are two activities in the OOD phase- assigning attributes &
services and assigning Responsibilities.
d. All the above.
e. None of the above.
UML
UNIT 5: Unified Modeling Language
5.0 Objectives:
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:
Use-case model. The use-case model defines the outside (actors) and inside (use-
case) of the systems’s behavior.
Domain object model. Objects of “real” world are mapped into the domain
object model.
Analysis object model. The analysis object mode presents how the source code
should be carried out and written.
Implementation model. The implementation model represents the implementation
of the system.
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.
Goals of UML as stated by the designers are
1. To model systems using OO concepts
2. To establish an explicit coupling to conceptual as well as executable artifacts
3. To address the issues of scale inherent in complex, mission-critical systems
4. To create a modeling language usable by humans and machine
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.
• Defines WHO is doing WHAT, WHEN to do it and HOW to reach a certain goal
• RUP is
1. Iterative and incremental
2. Use case driven
3. Architecture centric
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.
Lifecycle phases
time
Inception: Define the scope of the project and develop business case
The above slide shows which diagram serves best for which phases in the process. Black
boxes indicate a very appropriate use for a diagram, while light gray boxes indicate a
secondary use for a diagram.
These stages, though described sequentially, are iterative and interrelated. This means,
among other things, that when operating in a particular stage, such as design, you can
bounce back to analysis stage, and maybe even conceptualization stage
5.4 Steps in UML
During requirements gathering we develop the
-- Use case diagram
-- Use case description
-- Supplementary specification
• Analysis artifacts
-- Analysis classes
-- Use case realization
-- Sequence and collaboration diagram
-- Class diagram (if required)
• End product of design
-- Design classes, packages and subsystems
-- Class diagram
-- State chart diagram
-- Object diagram
– Process diagram
– Activity diagram
• Describe distribution
– Deployment diagram
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 :
• The choice of what models to create has a profound influence on how a problem is
attached and how a solution is shaped.
• Every model may be expressed at different levels of precision.
• The best models are connected to reality..
• 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.
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.
• Programming Languages
• Tools
• Process
Programming Languages
The UML, a visual modeling language, is not intended to be a visual programming
language, in the 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.
• Views
-- They show different aspects of the system that are modeled. The views link the
modeling language to the method/process chosen for development.
• Modeling elements
-- Model elements represent common object-oriented concepts such as classes,
objects and messages.
• Relationships
-- These bind the modeling elements.
• Diagrams
-- These are graphs describing the contents in a view.
• Extensibility mechanisms
-- Provide extra comments, information or semantics about a model element; they
also provide extension mechanism to adapt or extend UML.
5.8.1 Views/Architecture of 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.
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.
5.8.2 Modeling elements
• Modeling elements/Things
They are abstractions that are first-class citizens in a model, examples of which are use
case, interface, class, package, component, node state etc.
• They 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
Class
State
Attributes
Operations()
Package Componenet
Note
UseCase
(from Use Case View)
– Generalization
– Dependency
– Realization
State
State
Class
Use
UseCase
Case Diagrams
Diagrams
Diagrams State
Use
UseCase
Case Use Case
Diagrams Object
State
Sequence
Diagrams Diagrams
Diagrams Diagrams
Diagrams
Diagrams
Diagrams
Diagrams
Scenario
Scenario State
State
Collaboration Component
Diagrams
Diagrams
Diagrams Diagrams
Diagrams
Diagrams
Models
Scenario
Scenario Component
Component
Statechart Deployment
Diagrams
Diagrams
Diagrams
Diagrams Activity
Diagrams
Diagrams
Diagrams
• Stereotype
• Tagged value
• Constraint
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.
6.0 INTRODUCTION
• 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.
• 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
• A class is drawn as a solid-outline rectangle with at most three compartments
separated by horizontal lines.
• The top name compartment holds the class name and other general properties of
the class (including stereotype)
• The middle compartment holds a list of attributes
Example:
Class – Representation
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
visibility name : type-expression = initial-value { property-string}
where visibility is one of:
+ public visibility
# protected visibility
- private visibility
Example:
+size: Area = (100,100) #visibility: Boolean = invisible
+default-size: Rectangle #maximum-size: Rectangle
-xptr: XWindowPtr
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
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.
Attribute names in plain face.
• Instance
• Class
• Some times included for design purposes even though it adds no semantic
information
• Shown by placing a slash (/) in front of an attribute
Example:
6.2.2 Operation
• An operation is shown as a text string that can be parsed into the various
properties of an operation model element
• An operation that does not modify the system state (one that has no side effects) is
specified by the property “{query}”
Example:
+ create ()
+ display (): Location
+ 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.
Operation Compartment
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.
A property list in braces follows the entire operation string.
6.3 Object
• The object notation is derived from the class notation by underlining instance-
level elements
• It is 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 second compartment shows the attributes for the object and their values as a
list
• Each value line has the syntax: attributename : type = value
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.
For example:
display_ Window: WindowingSystem::GraphicWindows::Window
A stereotype for the class may be shown textually (in guillemets above the name string)
or as an icon in the upper right corner. The stereotype for an object must match the
stereotype for its class. To show multiple classes that the object is an instance of, use a
comma-separated list of classnames. These classnames must be legal for multiple
classification (i.e., only one implementation class permitted but multiple roles permitted).
To show the presence of an object in a particular state of a class, use the syntax:
objectname : classname ‘[‘ statename-list ‘]’
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
6.4 Interface
• An interface is a classifier and may also be shown using the full rectangle symbol
with compartments and the keyword «interface»
• May also be displayed as a small circle with the name of the interface placed
below the symbol
- The circle may be attached by a solid line to classes that support it
- This indicates that the class provides all of the operations in the interface
6.5 Packages
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.
Package A
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.
• Association
• Aggregation
• Composition
• Generalization
• Dependency
• Realization
• Links
7.3 Association
Or Association
Course
Student Professor
Reflexive Association Association
• Navigability
• Role-name
• Aggregation indicator
• Visibility
• Ordering
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.
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
Whole
Company
aggregation
Department
part
7.6 Composition
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.
Single inheritance
Multiple
inheritance
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.
Realizes
a:DisplayItem
move()
aController
aView
isUnder()
b: DisplayItem
8.1 Objectives :
At the end of this unit, You would be able to:
– Use cases
– Actors
– System modeled
2. A use case model is described in UML as a use case diagram (UCD)and a use
case model can be divided into a number of use case diagrams.
Use Cases have become the starting point of many current Object Oriented (OO)
development methodologies. They generally serve as both a foundation and entry point
for the rest of the analysis and development process.
Use Cases aren't necessarily an OO discovery, they were just adopted by the OO industry
because they work.
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.
Withdrawmoney
Actors
generalization
Commercial
Customer
(from Use Case View)
System
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.
It need not necessarily be a software system; it can be a business system as well.
Insurance business
Example -Use case diagram
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
Supplementary specs. lists the requirements that are not readily captured in
the use cases of the sue case model.
It is a text document and has details about the following
a. Functionality
b. Usability
c. Reliability
d. Performance
e. Supportability
f. Security
g. Design constraints
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.
Realizing Use Cases
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
A class in a class diagram can be directly implemented in an OOP language that
has the construct for a class.
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
Class Diagram – Example
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.
c:company
An object diagram is a graph of instances, including objects and data values. A static
Link
object diagram is an instance of a class diagram.
object
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.”
Object Diagram – Example
d1:department
:Department
Name=“sales”
Name=“R&D”
Anonymous object
Attribute Value
8.4 Dynamic view diagram
Insurance business
Statechart diagram
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.
A change of state is called a transition.
They are not drawn for all classes, only for those that have a number of limited
states and where the behavior of the class is affected and changed by the different
states.
8.4.2 Interaction diagram
o Sequence diagram
o Collaboration diagram
Sequence Diagram
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 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
Within a sequence diagram the existence and duration of the object in a role is
shown
The relationships among the roles are not shown
An object role is shown as a vertical dashed line called the “lifeline”
The lifeline represents the existence of the object
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”
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
An activation (focus of control) shows the period during which an object is
performing an action either directly or through a subordinate procedure
It represents
i. The duration of the action in time
ii. The control relationship between the activation and its callers
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
- In the case of concurrent objects
- In the case of procedural code
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
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
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
A message may also be labeled with a guard condition
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
A collaboration shows the context in which interaction occurs
A collaboration is shown by a collaboration diagram without messages.
By adding messages, an interaction is shown
Different sets of messages may be applied to the same collaboration to yield
different interactions
Collaboration Diagram
A collaboration diagram represents
- A Collaboration,
- An Interaction
A collaboration diagram is a graph of references to objects and links with
message flows attached to its links
Show navigability using arrowheads on links
Individual attribute values are usually not shown explicitly
The internal messages that implement a method are numbered starting
with number 1
For a procedural flow of control the subsequent message numbers are
nested in accordance with call nesting
Component Diagrams
Component Diagrams
The diagram may also be used to show interfaces and calling dependencies among
components, using dashed arrows from components to interfaces on other
components.
The kinds of dependencies are language-specific and may be shown as
stereotypes of the dependencies.
A component diagram has only a type form, not an instance form
To show component instances, use a deployment diagram
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.
Component Diagrams – Examples
name
Interface
Iconic form
trans.dll
Realization
Extended components
System:dialog.dll
{version=4.1.3} Dependency
Components
Components
A component is shown as a rectangle with two small rectangles protruding from its side.
A component type has a type name:
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:
component-name ‘:’ component-type
A property may be used to indicate the life-cycle stage that the component describes
(source, binary, executable, or more than one of those). Components (including
programs, DLLs, run-time linkable images, etc.) may be located on nodes.
Compile-Time components
Components that contain the code produced in the projects.
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>> <<document>>
home.html animlogo.java animlogo.doc
<<document>> <<document>>
animator.java animator.doc
Run-Time components
o Represents a component used when executing the system
o Generated from the link-time components
o Only components that can have instances and are located on nodes
<<library>> <<library>>
<<library>>
graphics.dll dbhandler.dll
commhandler.dll
<<application>>
umlviewer.exe
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.
name
Component
Nodes
clientA:IB
M PC
<<TCP/IP>>
<<TCP/IP>> Application
ClientB:
Server:
IBM PC
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
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.
1. Functional diagram
- Use case diagram
1. Static view diagrams(Structural diagrams)
- Class diagram, Object diagram
2. Dynamic view diagram(Interaction diagrams)
- State diagram, Sequence diagram, collaboration diagram, activity diagram
3. Implementation diagram
- Component diagram, Deployment diagram
Unit 9: Extensibility Mechanisms
9.0 INTRODUCTION
• They are general purpose mechanisms that may be applied to any modeling
element
• They constitute an extensibility device for UML are could be
- Constraint and comment
- 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:
• The individual tools may provide one or more languages in which formal
constraints may be written.
• One predefined language for writing constraints is OCL
Note
Constraint placed
Formal constraint using OCL inside a note
9.3 Tagged values
• Users can define new element properties using the tagged value mechanism
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.
• Tagged values are an extensibility mechanism of UML permitting arbitrary
information to be attached to models
• A property is displayed as a comma-delimited sequence of property specifications
all inside a pair of braces ( { } )
A property specification has the form : keyword = value
Example:
{ author = “Joe Smith”, deadline = 31-March-1997, status = analysis }
{ abstract }
<<library>>
trans.dll
Server
{serverOnly}
{processors=3}
Value of Tag
Tagged Value
9.4 Stereotypes
• 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
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
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.
Stereotypes - Examples
Named
Stereotype Named
stereotype
with Icon
Stereotyped
element as
Icon
Stereotyped association
Review Questions
1. What is a model.
2. What is UML ? what is the importance of UML?
3. Describe the class diagram.
4. What is an association role?
5. What are some of the forms of association? Draw their UML representations.
6. How does the UML group model elements?
7. What are some of the UML dynamic diagrams? Explain.
8. Explain Interaction diagram with an example.
9. What is the difference between sequence diagrams and collaboration diagrams ?
10. What is the purpose of an activity model ?
11. What are implementation diagrams ? explain.
2. UML model is
(a) Iterative and incremental
(b) Architecture centric
(c) Use case driven
(d) None of the above
(e) All the above
3. RUP is
i. iterative and incremental
ii. use case driven
iii. architecture centric
iv. None of the above
v. All the above
6. Extensibility Mechanisms
a. Stereotype
b. Tagged value
c. Constraint
d. None of the above
e. All the above
7. Operation:
1. Used to show operations defined on classes
2. An operation is a service that an instance of the class may be requested to
perform
3. An operation is shown as a text string that can be parsed into the various
properties of an operation model element
4. None of the above
5. All the above