OOAD and UML - Penciljipencilji.com/download/30147121.pdf · OOAD and UML Prabhudeva S. Assistant...

Downloaded from www.pencilji.com


OOAD and UML

Prabhudeva S. Assistant professor Department of Computer Science and engineering.

J N N C E, Shimoga.



OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML

CONTENTS

UNIT 1: Structured approach vs. object oriented approach

1.1 Introduction

1.2 Objectives

1.3 What is software?

1.4 High-Quality software

1.5 Where does the traditional approach fail?

1.5.1 Pitfalls of top down design

1.5.2 How object method succeeds?

1.6 Merits of object approach.

1.7 Summary

1.8 Review questions

1.9 Objective type questions.

UNIT 2: The Object Model

2.1 Objectives

2.2 Foundations of the object Model

2.3 Definitions: OOA , OOD and OOP

2.4 Major elements of Object Model:

2.4.1 Abstraction

2.4.2 Encapsulation

2.4.3 Modularity

2.4.4 Hierarchy

2.5 Minor elements of the object model:

2.5.1 Typing

2.5.2 Concurrency

2.5.3 Persistence

2.6 Summary





UNIT 3: CLASSES AND OBJECTS

3.0 Introduction

3.1 Objectives

3.2 Object

3.2.1 Definition

3.2.2 Relationships among objects

3.3 Class

3.3.1 Definition

3.3.2 Relationships among Classes

3.4 Summary



3.7 Fill in the blanks

UUNNIITT44 :: RRooaa dd MMaapp ffoorr OOOOAA aanndd OOOODD

4.1 Objectives

4.2 Various Activities in a Design

4.2.1 OOA Phase

4.2.1 Creating Classes

4.2.2 Assigning Responsibilities

4.2.3 CRC Modeling

4.2.4 OOA Checkpoint

4.2.2 OOD Phase

4.2.2.1 OOD Checkpoint

4.3 Software problems

4.4 Best practices of software engineering





4.7 Objective type questions

UNIT 5: Unified Modeling Language

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

UNIT 6: UML Modeling elements

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

UUNNIITT 77:: RRee llaattiioo nnsshhiippss connect modeling elements

7.0 Introduction

7.1 Objectives

7.2 Relationships Notations

7.3 Association

7.4 Association End

7.5 Aggregation

7.6 Composition

7.7 Generalization

7.8 Dependency

7.9 Realization

7.10 Relationship between Objects

UNIT 8 : Diagrams in UML

8.0 Introduction

8.1 Objectives

8.2 Use Case model

8.3 Static view diagram

8.3.1 Class diagram

88..33..22 OObbjjeecctt dd iiaaggrraamm

8.4 Dynamic view diagram

88..44..11 SSttaatteecchhaa rrtt dd iiaaggrraamm

8.4.2 Interaction diagram



88..44..22..11 SSeeqquueennccee dd iiaaggrraamm

88..44..22..22 CCoollllaabboorraa tt iioonn dd iiaaggrraamm

8.5 Implementation diagram

8.5.1 Component diagram

8.5.2 Deployment diagram

8.6 Summary of Diagrams in UML

UUnniitt 99 :: EExxtteennss iibbiill iittyy MMeecchhaanniiss mmss

9.0 Introduction

9.1 Objectives

9.2 Constraint and Comment

9.3 Tagged values

9.4 Stereotypes

9.5 Summary



OBJECT -ORIENTED ANALYSIS

AND DESIGN



UNIT 1: Structured approach vs. object oriented approach

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.

External characteristics of good quality software are as follows :

Factor Meaning Correct Does the right thing on normal data

Robust Fails "gracefully"

Extendible Can adapt easily to changing requirements

Reusable Can be used in systems other than the one for which was created

Compatible Can be used easily with other software

The above attributes are the ones which benefit most when switching from structured

to object oriented approach. Also software needs to be easy-to-use, portable and

verifiable.

1.5 Where does the traditional approach fail ?

1.5.1 Pitfalls of top-down design

The functional viewpoint is difficult to evolve



Every real-world system undergoes change and evolution. The top-down approach

creates a good software model for the initial requirements of a system. But as that system

changes and new requirements are added, the functional architecture becomes more and

more unwieldy. Because the software is designed around a relatively fixed tree structure,

changes usually require extensive pruning and grafting.

Real systems are hard to characterize functionally

Most large systems do not have a top. For example, a database system involves tools for

querying data, changing data, keeping data consistent, etc… There is no one function

central to these diverse concerns..

The functional approach loses sight of the data

As you can see from the example above, the top-down design does not capture anything

about the data involved in the program. Functions always do something to data. Usually,

the same data is shared among a number of functions (for example, updating, deleting,

inserting and querying a database table). Since the decomposition only highlights the

functional aspects of the problem, the influence of the data structures on the problem is

lost.

Functional orientation produces less reusable code

Each program element is designed with only a limited set of requirements in mind. Since

it is unlikely that this exact set of requirements will return in the next problem, the

program's design and code is not general and reusable. Top-down design does not

preclude the creation of general routines that are shared among many programs; but it

does not encourage it. Indeed, the idea of combining reusable programs into a system is a

bottom-up approach quite the opposite of the top-down style. Structured approach does

not scale up to sizeable practical systems. Subroutine libraries are useful in certain

domains but do not solve the general problems inherent in structured, top-down design.

1.5.2 How object method succeeds ?

Object-oriented methods enable us to create set of objects that work together

synergistically to produce software that better model their problem domains than similar

systems produced by traditional techniques. The systems are easier to adapt to changing

requirements ,easier to maintain, more robust, and promote greater design and code reuse.



1.6 Merits of object approach

- Object orientation works at a higher level of abstraction

One of our most powerful techniques is the form of selective amnesia called

'Abstraction'. Abstraction allows us to ignore the details of a problem and concentrate on

the whole picture.

- Software life cycle requires no vaulting

The object-oriented approach uses essentially the same language to talk about analysis,

design, programming and (if using an Object-oriented DBMS) database design. This

streamlines the entire software development process, reduces the level of complexity and

redundancy, and makes for a cleaner system architecture and design.

- Data is more stable than functions

Functions are not the most stable part of a system, the data is. Over a period of time, the

requirements of a system undergo radical change. New uses and needs for the software

are discovered; new features are added and old features are removed. During the course

of all this change, the underlying heart of the system remains comparatively constant.

This heart is the data

- Encourages good programming techniques

A class in an object oriented design carefully delineates between it's interface

(specifications of what it can do) and the implementation of that interface (how it does

what it does). The routines and attributes within a class are held together cohesively by

the object which they are modeling. In a properly designed model, the classes will be

grouped neatly into sub-systems but remain independent; therefore, changing one class

has no impact on other classes, and so , the impact is minimized.

- Promotes code reuse

The code and designs in object-oriented software development are reusable because they

are modeled directly out of the real-world problem-domain.

Summary

• Algorithms + Data structures = Programs



• Two orthogonal ways to view software

– Focus on functions - what does the system do ?

– Focus on the object ,which combines data and

Function.

• Structured approach focuses on functions

• Object approach focuses on Object. (data)

• Good quality software is

– 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

• Merits of object approach

1. Works at a higher level of abstraction

2. Software life cycle requires no vaulting

3. Focus is on data which is more stable than functions

4. Encourages good programming techniques

5. Promotes code reusability.

Fill in the blanks

1. Systems development activities consist of systems _____________ and maintenance.



2. Software is the term associated with the _________ that are written to manage the

various _______ of a computer system and perform certain designated useful tasks.

Software can be further classified into ________ and _______.

3. Two orthogonal (yet complementary) ways to view software construction: we can

focus primarily on the _________ or primarily on _____.

4. Four quality measures are : _________, ______, ______ , and validation.

5. The systems are easier to adapt _________,________,___________, and

_____________.

Objective type questions.

1.The software quality

a. Decrease because of reinventing

b. Depends on the tests performed

c. Increases because of thorough debugging.

d. Both (a) & (b)

e. None of the above

2. Structured approach focuses on

a. Functions

b. Algorithms

c. Objects

d. None of the above

3. Good quality software is

a. Correct, Robust, Extendible

b. Reusable, Compatible

c. Both (a) & (b)




4.Object-Oriented Systems are easier to

a. Adapt to changing requirements

b. Easier to maintain and more robust

c. Promote greater design and code reuse

d. All the above (a), (b), (c)


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


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

2.2 Foundations of the object Model

Structured design methods evolved to guide developers who were trying to build

complex systems using algorithms as their fundamental building blocks.

Object-oriented design methods evolved to help developers exploit the expressive

power of object-based and object-oriented programming languages, using the class and

object as basic building blocks.

Object-oriented analysis and design represents an evolutionary development, not a

revolutionary one; it does not break with advances from the past, but builds upon proven

ones.



2.3 Definitions: OOA, OOD and OOP

Object-oriented analysis (OOA) is a method of analysis that examines requirements

from the perspective of the classes and objects found in the vocabulary of the problem

domain.

Object-oriented design (OOD) is a method of design encompassing the process of

Object-oriented decomposition and a notation for depicting both logical and physical as

well as static and dynamic models of the system under design.

Object-oriented programming (OOP) is a method of implementation in which

programs are organized as cooperative collection of objects each of which represents an

instance of some classes are all members of a hierarchy of classes united via inheritance

relationships.

Object-oriented programming can be called as a new programming parad igm that will

help us develop software that is more reliable, easily maintainable and reusable. The

three fundamental units of Object-oriented programming are objects, methods and

messages.

The essence of Object-oriented Analysis and Design is to emphasize considering a

problem domain and logical solution from the perspective of objects (things, concepts, or

entities) as shown in figure below.

Analysis Design construction

Figure : Meaning of development activities

Investigation of the problem

Logical solution

Code



During Object-oriented Analysis ,there is an emphasis on finding and describing the

objects-or concepts- in the problem domain. For example ,in the case of the library

information system, some of the concepts include books ,library and patron.

During Object-oriented design ,there is an emphasis on defining logical software

Objects that will ultimately be implemented in an Object-oriented programming

language. These software objects have attributes and methods. To illustrate, in a library

system , a book software object may have a title attribute and a print method (see figure

below).

Public class Book

{

public void print();

private string title;

}

figure : object-orientation emphasizes representation of objects

Finally, during construction or object-oriented programming, design components are

implemented, such as a book class in C++, java, smalltalk, or visual basic.

Object-oriented approach use the same basic entities (i.e., objects) throughout the

lifecycle and

Domain concept Representation in

analysis of concepts

title

Representation in an

Object-oriented

programming language

Book



- Basic objects are identified during analysis.

- Lower- level objects are identified during design reusing existing object

descriptions where appropriate.

- Objects are implemented as software structures (e.g., C++ or Java classes)

during coding.

2.4 Major elements of Object Model:

Abstraction

Encapsulation

Modularity

Hierarchy

2.4.1 Abstraction

An abstraction denotes the essential characteristics of an object that distinguishes it from

all other kinds of objects and thus provide crisply-defined, conceptual boundaries,

relative to the perspective of the viewer; the process of focusing upon the essential

characteristics of an object. Abstraction is one of the fundamental elements of the object

model.

Three types of abstraction are

- Entity abstraction - an object that represents a useful model of a problem or

solution domain

- Virtual machine abstraction - an object that groups together operations that are

used by some superior/junior level of control

- Coincidental abstraction - an object that packages a set of operations that have no

relation to each other.



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.

Abstraction

Hierarch

y

Modularity

Encapsulation

OO Model



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

• Protected A declaration that is accessible only to the class itself, its

subclasses,

and its friends

• Private A declaration that is accessible only to the class itself and its friends

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

• Languages and modules

-- C++ has separately compiled files like .h, .cpp with dependencies through #include.

-- Java supports packages.

-- Object Pascal has the formal syntax for units.

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

• Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the

understanding of our problem

• Hierarchy is a ranking or ordering of abstractions

Abstraction is a good thing, but in all except the work trivial applicat ions, 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

Examples of hierarchy: Single 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

BBaannkk

AAccccoouunntt

SSaavviinnggss BBaannkk

AAccccoouunntt FFiixxeedd DDeeppooss iitt

AAccccoouunntt RReeccuurrrriinngg DDeeppooss iitt

AAccccoo uunntt



Inheritance is a relationship among classes, wherein one class shares the structure or

behavior defined in one (single inheritance) or more (multiple inheritance) other classes.

Examples of hierarchy: Single Inheritance

Single Inheritance is the most important “is a” hierarchy, and as noted earlier, it is an

essential element of object oriented systems. Basically, inheritance defines a relationship

among classes and thus represents a hierarchy of abstractions, in which a subclass inherits

from one or more generalized superclasses. Typically, a subclass augments or redefines

the existing structure and behavior of its superclasses.

Semantically, inheritance denotes an “is a” relationship. For example; a bear “is a” kind

of mammal, a house “is a” kind of tangible asset, and a quick sort “is a” kind of sorting

algorithm. Inheritance thus implies a generalization/specialization hierarchy, wherein a

subclass specializes the more general structure or behavior of its superclasses. Indeed,

this is the litmus test for inheritance: if B “is not a” kind of A, then B should not inherit

from A.

As we evolve our inheritance hierarchy, the structure and behavior that are common for

different classes will tend to migrate to common superclasses. This is why we often speak

of inheritance as bring a generalization/specialization hierarchy. Superclasses represent

generalized abstractions, and subclasses represent specialization‟s in which fields and

methods from the superclass are added, modified, or even hidden. In this manner,

inheritance lets us state our abstractions with an economy of expression.

With Inheritance Encapsulation can be Violated in Three Ways

• The subclass might access an instance variable of its superclass

• The subclass might call a private operation of its superclass

• The subclass might refer directly to superclasses of its superclass



There is a healthy tension among the principles of abstraction, encapsulation, and

hierarchy. Data abstraction attempts to provide an opaque barrier behind which methods

and state are hidden; inheritance requires opening this interface to some extent and may

allow state as well as methods to be accessed without abstraction. For a given class there

are usually two kinds of clients: objects that invoke operations upon instances of the

class, and subclasses that inherit from the class.

With Inheritance encapsulation can be violated in three ways as in the slide. Different

languages trade off support for encapsulation and inheritance in different ways. For

example, the interface of a C++ class may have three parts: private parts, which declare

members that are accessible only to the class itself, protected parts, which declare

members that are accessible only to the class and its subclasses, and public parts, which

are accessible to all clients.

Abstract Class

• 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

• Abstract classes can only be inherited

• It has one or more Abstract operations

-Abstract Operation is an operation for which no method is given

• Abstract class is introduced to make it possible to store a set of attributes and methods

common to several classes in one place

• Typically defined to provide interfaces for significant operations

• Also to provide implementations for common methods

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.

Examples of hierarchy : Multiple Inheritance

• A class inherits from more than one superclass

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

Motor vehicle

Truck Car Bus

Utility Vehicle



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.

Aggregation as a “Part-Of” Hierarchy

Garden

GardeningPlan Plant

• GardeningPlan is “part of” Garden

• Plant is “part of” Garden

• Garden “has a” GardeningPlan

• Garden “has a” Plant

“has a” “part of”



Delegation

• Inheritance leads to a strong dependency of the subclass on the superclass

• Delegation provides an alternative to inheritance

• By delegation, an object responds to an operation on itself by invoking a service in

another object

Example: A Stack class might handle a push operation by forwarding it to an add

operation on List class

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.

2.5 Minor elements of the object model :

• Typing

• Concurrency

• Persistence

Question of Ownership?



2.5.1 Typing

• A type is a precise characterization of structural or behavioral properties which a

collection of entities share

• A class implements a type

• Programming languages can be strongly typed, weakly typed or even untyped

1. Smalltalk is untyped

2. C++ is a bit of hybrid; it is strongly typed, but one can ignore or suppress typing rules

• Strong typing has its advantages in enforcing design decisions relevant when

complexity grows but has its weaknesses also

Typing is the enforcement of the class of an object, such that objects of different types

may not be interchanged, or at the most, they may be interchanged only in very restricted

ways.

The concept of a type derives primarily from the theories of abstract data types. A type is

a precise characterization of structural of behavioral properties which a collection of

entities all share. Although the concept of a type and a class are similar, we include

typing as a separate element of the object model because the concept of type places a

very different emphasis upon the meaning of abstraction.

Typing lets us express our abstraction so that the programming language in which we

implement them can be made to enforce design decisions.

The idea of conformance is central to the notion of typing. For example, consider units of

measurement in physics. When we divide distance to time, we expect some value

denoting speed, not weight. Similarly, multiplying temperature by a unit of force doesn‟t

make sense, but multiplying mass by force does. These are both examples of strong

typing where the rules of our domain prescribe and enforce certain legal combinations of

abstractions.

A given programming language may be strongly typed, weakly typed, or even untyped,

yet still be called object-oriented.

Strong typing lets us use our programming language to enforce certain design decision,

and so is particularly relevant as the complexity of our system grows. However, there is a



dark side to strong typing. Particularly, strong typing introduces semantic dependencies

such that even small changes in the interface of a base class require recompilation of all

subclasses.

Static and Dynamic Binding

• Strong typing and static typing are entirely different

• Strong typing refers to type consistency

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

What Does Dynamic Binding Offer for Object Orientation?

• Polymorphism

• When inheritance and dynamic binding interact, polymorphism exists

• Power of polymorphism



Polymorphism represents a concept in type theory in which a single name (such as

variable declaration) may denote objects of many different classes that are related by

some common superclass. Any object denoted by this name is therefore able to respond

to some common set of operations.

Polymorphism exists when the features of inheritance and dynamic binding interact. It is

perhaps the most powerful feature of object-oriented programming languages next to

their support for abstraction. Polymorphism is also a central concept in object-oriented

design.

Polymorphism (or many forms) enables a class within an inheritance hierarchy to be

represented simultaneously as itself and as any superclass within its inheritance

hierarchy. For example, a Square is also a Rectangle, which is also a Polygon.

In general, even when an object is associated with a type that is one of its superclasses, an

object-oriented language can still determine the leaf- level class of the object. For

example, consider the case where a Square is a Rectangle is a Polygon. Whenever a

Square is assigned to a type that is a Polygon, the run-time system will still be able to

recognize that the object is a Square. The same is true for an object of class Rectangle.



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

• Are concurrency and simultaneity the same?

• Concurrency focuses on process abstraction and synchronization



• 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

• Lifetimes of objects range from “transitory” to “semi-permanent” beyond execution of

a program



• Spectrum of object persistence

- Transient results in expression evaluation

- Local variables in procedures

- Data that exists between executions of a program

- Data that exists between versions of a program

- Data that outlives the program

An object in software takes up some amount of space and exists for a particular amount

of time. There is a continuum of object existence, ranging from transitory objects that

arise within the evaluation of an expression, to objects in a database that outlive the

execution of a single program.

Traditional programming languages usually address only the first three kinds of object

persistence; persistence of the last two kinds is typically the domain of database

technology.

This leads to a clash of cultures that sometimes results in very strange architectures. The

programmer ends up crafting ad hoc schemes for storing objects whose state must be

preserved between program executions, and database designers misapply their technology

to cope with transient objects.

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

• Most OOPL do not support persistence directly

• Many systems provide an OO Skin over a RDBMS

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.

• Three types of abstraction are - Entity abstraction, Virtual machine abstraction,

Coincidental abstraction.

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’

• Languages and modules

- C++ has separately compiled files like .h,.cpp with dependencies through #include

- Java supports packages

- Object Pascal has the formal syntax for units

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

• Abstract classes can only be inherited

• It has one or more Abstract operations

- Abstract Operation is an operation for which no method is given

• Abstract class is introduced to make it possible to store a set of attributes and methods

common to several classes in one place

• Typically defined to provide interfaces for significant operations

• Also to provide implementations for common methods

With Inheritance Encapsulation can be Violated in Three Ways

• The subclass might access an instance variable of its superclass

• The subclass might call a private operation of its superclass

• The subclass might refer directly to superclasses of its superclass

Minor elements of the object model : Typing, Concurrency, Persistence.

Typing is the enforcement of the class of an object ,such that objects of different types

may not be interchanged, or at the most, they may be interchanged only in very restricted

ways.

- Static and Dynamic Binding

• Strong typing and static typing are entirely different

• Strong typing refers to type consistency



• 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

- What does Dynamic Binding offer for Object Orientation?

• Polymorphism

• When inheritance and dynamic binding interact, polymorphism exists

• Power of polymorphism

- 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

• Offers the programmers of database systems the abstraction power of object

technology

• Smalltalk provides support for persistence

• Most OOPL do not support persistence directly

• Many systems provide an OO Skin over a RDBMS



*******************************************************************

Fill in the blanks

1. Object-oriented design methods evolved to help developers exploit the expressive

power of __________ and ___________ programming languages, using the class and

object as basic building blocks.

2. Major Elements of Object Model are (1)______,(2)______, (3)_______,(4)_______.

3. Three types of abstraction are - ____________, ___________, _________.

4. Encapsulation is the process of compartmentalizing the elements of an abstraction that

constitutes its _________ and __________and serves to separate the contractual interface

of an abstraction and its implementation.

5. Modularization consists of dividing a ___________ into modules which can be

compiled separately, but which have connection with other modules.

6. Cohesion is the interdependency within a module and __________ is the dependency

between modules.

7. Good design stipulates „high ______ and low ________.

8. Hierarchy is a ordering of _________.

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.

11. Abstract classes can only be ___________.



12. Delegation provides an alternative to _________, By delegation, an object responds

to an operation on itself by invoking a service in another object.

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.

2. The fundamental units of object oriented programming are

a. Objects, Methods, Messages & Classes.

b. Objects, Member functions, Messages



c. Objects, Methods, Messages

d. Both (a) & (b).


3. Objects are instances of

a. Template

b. Specialized template

c. Classes

d. Both (a) & (b)


4. The method of placing code and the data together is

a. Encapsulation

b. Object oriented programming

c. Class identification

d. All the above


5. Inheritance involves at least

a. Two objects

b. Only one object

c. At least two objects

d. All the above


6. A subclass inherits features from

a. Global classes

b. Abstract classes

c. Base classes

d. Only (a) and (b)




7. Programming languages can be

a. Strongly typed

b. Weakly typed

c. Even un typed

d. All the above


8. Object-oriented system development consists of

i. Object-oriented Analysis, Design and Implementation

ii. Object-oriented information modeling only

iii. Prototyping and implementation only

iv. Testing, Iteration , and Documentation

v. Both (a) and (d)

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



UNIT 3: CLASSES AND OBJECTS

3.0 Introduction

When we use object-oriented methods to analyze or design a complex software system,

our basic building blocks are classes and objects. In this unit, we shall study the nature of classes, objects, and their relationships.

3.1 Objectives


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

What are Links?

Rumbaugh defines a link as a physical or conceptual connection between objects

An object collaborates with other objects through its links

A link is a specific form of an association through which an object (the client)

takes the services of another object (the supplier)

During implementation Links will become pointers or references to objects.



A Link is an instance of an association and both are bi-directional. (e.g., employs

and employed by)

Where ambiguity appears, a directional arrow can be added to clarify an

Association or Link name.

An object by itself is intensely uninteresting. Objects contribute to the behavior of a

system by collaborating with one another.

The relationship between any two objects encompasses the assumptions that each makes

about the other, including what operations can be performed and what behavior results.

The term link derives from Rumbaugh, who defines it as a “physical or conceptual

connection between objects”. An object collaborates with other objects through its link to

these objects. Stated another way, a link denotes the specific association through which

one object (the client) applies the services of another object (the supplier), or through

which one object may navigate to another.

Message passing between two objects is typically unidirectional, although may

occasionally be bi-directional.

Aggregation and Composition

1. Aggregation

• it is a association which denotes a whole/part relationship among objects with the

ability to navigate from the whole (aggregate) to its parts (attributes)

• it is possible for an object to navigate to its container only if this knowledge is part

of the object‟s state

• aggregation may or may not denote physical containment

2. Composition

• a form of aggregation with strong ownership and coincident lifetime of part with

the whole

• the multiplicity of the aggregate end may not exceed one

• the parts of a composition may include classes and associations



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

Aggregation vs. Composition

Both denote whole-part relationships

Both enable modeling at multiple levels of abstraction: whole or part

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 is a relatively weaker form of the whole-part relationship, while

composition is a relatively stronger form.

Aggregation: Weaker

* Aggregation is a kind of association used to model whole-part relationships between

things. A hollow diamond is attached to the end of the path to indicate aggregation.

However, the diamond may not be attached to both ends of a line.

* Parts can be associated with multiple wholes (often at the same time)

* Issues of navigation, ownership, and lifetimes of the whole vs. the part are ignored

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

Every object in an object-oriented program is also an instance of a class, where a class

can be thought of as a template ( or cookie cutter ) for the creation of an object

(alternatively, a set of objects ). Each class also has its own unique identifier (typically

represented through a class name ). Each class also provides an interface for every

operation that an instance of the class must provide, as well as a method that implements

the operation. A given instance of a class, that is an object, will have an OID and a class

name. Taken together, the OID and the class name associated with an object can be used

to locate the state of the object, as well as the executable code associated with the object.

In general, the state will be repeated and different for each instance of a class, while the

executable code will be identical for each instance of 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

•• AAnn aatt ttrr iibbuuttee iiss aa ddeessccrr iippttoo rr oo ff aann iinnssttaannccee.. IItt ttee llllss uuss ssoommee tthhiinngg iimmppoorr ttaanntt aanndd

ss iiggnniiffiiccaanntt aabboo uutt tthhee nnaattuurree oo ff aann iinnssttaannccee

• Examples of attributes are length, height, weight, color, date of birth, cost etc.

A class can possess variables that contain state information relevant to users of instances

of the class. Such variables are often called attributes. In some programming languages,

such as C++, attributes can be accessed directly using language constructs, such as

assignment. In other languages, access to attributes is mediated via operations, often

called get (to retrieve the value of an attribute) and set (to change the value of an

attribute). In the typical case, attributes associated with a class are copied into the state of

an object when the object is created. From that point, the values of the attributes can be

changed independently by different instances of the class and, thus, different values can

be seen by class instances for the same attribute.



• 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

– Is a set of structural relationships among classes

• Generalization

– Also called Inheritance or Specialization

– Connects generalized classes to more specialized classes

• Dependencies

– Are using relationships

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.

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

Product Sale



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

An association end is simply an end of an association where it connects to a class. It is

part of the association, not part of the class. Each association has two or more ends. Most

of the interesting details about an association are attached to its ends. An association end

is not a separable element; it is just a mechanical part of an association.

The path may have graphical adornments at each end where the path connects to the class

symbol. These adornments indicate properties of the association related to the class. The



adornments are part of the association symbol, not part of the class symbol. The end

adornments are attached to the end of the line.

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

car person Driver Company car

** drives **



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

• Have well-defined responsibilities



• To collaborate with other objects to achieve its goals

- Objects have an unique identity and they represent a particular instance of a

class

Two Interesting Object Hierarchies

• Links

• Aggregation / Composition

What are Links?

Rumbaugh defines a link as a physical or conceptual connection between objects

An object collaborates with other objects through its links

A link is a specific form of an association through which an object (the client)

takes the services of another object (the supplier)

During implementation Links will become pointers or references to objects.

A Link is an instance of an association and both are bi-directional. (e.g., employs

and employed by)

Where ambiguity appears, a directional arrow can be added to clarify an

Association or Link name.

Aggregation and Composition

- Aggregation

• It is a association which denotes a whole/part relationship among objects with the

ability to navigate from the whole (aggregate) to its parts (attributes)

• It is possible for an object to navigate to its container only if this knowledge is part

of the object‟s state

• Aggregation may or may not denote physical containment

- Composition

• A form of aggregation with strong ownership and coincident lifetime of part with

the whole

• The multiplicity of the aggregate end may not exceed one



• The parts of a composition may include classes and associations

Aggregation vs. Composition

Both denote whole-part relationships

Both enable modeling at multiple levels of abstraction: whole or part

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

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

•• AAnn aatt ttrr iibbuuttee iiss aa ddeessccrr iippttoo rr oo ff aann iinnssttaannccee.. IItt ttee llllss uuss ssoommee tthhiinngg iimmppoorr ttaanntt aanndd

ss iiggnniiffiiccaanntt aabboo uutt tthhee nnaattuurree oo ff aann iinnssttaannccee

• 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



Relationships Among Classes

• Association

– is a set of structural relationships among classes

• Generalization

– Also called Inheritance or Specialization

– Connects generalized classes to more specialized classes

• Dependencies

– Are using relationships

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

2. State and explain following

(a) Association (b) Association End (c) N-ary Association

(d) Generalization (e) Dependency

3. Explain the different kinds of relationship among objects.

4.What are Links? Explain.



5. Compare and contrast aggregation with composition

6. Explain the different kinds of relationship among Classes.


1. Objects communicate with each other

a. By command languages

b. By passing messages

c. By invoking methods

d. By function calls


2. The fundamental units of object oriented programming are

a. Objects, Methods, Messages & Classes

b. Objects, Member functions, Messages

c. Objects, Methods, Messages

d. Both (a) & (b).


3. Objects are instances of

a. Template

b. Specialized template

c. Classes

d. Both (a) & (b)




4. Two kinds of Object Hierarchies are

a. Links and Aggregation / Composition

b. Generalization

c. Dependency

d. Both (b) and (c)


5. Generalization may be applied to

a. Associations as well as Classes

b. Association alone

c. Classes alone



1. An object has _____, _______, and ____; the structure and behavior

of similar objects are defined in their common class; the terms instance and object are

interchangeable.

2. The State of an object encompasses all of the (usually static) properties of the object

plus the __________ values of each of these properties.

3. Behavior is how an object acts and reacts, in terms of its _____ changes and ____

passing .

4. Identity is that ________ of an object which distinguishes it from all other objects.

5.Messages are sent between objects to request operations and to return _________.

6.Each object in an object-oriented program has its own individual______ and its own

___________.



7. The attribute value belongs to the class and objects do not maintain independent

values, such attribute is called _____________.

8. The attribute values are dependent upon the values of other attributes are called

_______

9. The executable code for an object is typically associated with a _______,

rather than with each individual object generated from the class.

10. AAnn aa tttt rr iibbuuttee iiss aa ddeessccrr iippttoorr oo ff aann ________________..

11. Attributes describe ____________of objects, methods describe the _________ of an

object, i.e., the services that an object can provide.

12. _______is a set of structural relationships among classes

13. __________is a set of structural relationships among classes

14. An Association is a set of ____________ between or among classes

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



UUNNIITT44:: RRooaadd MMaapp ffoorr OOOOAA aanndd OOOODD

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

4.2 Various Activities of a Design during:

OOA Phase

• Overall question is „What?‟

• Do not worry about the implementation details

• The focus is on the real world

• What are the objects?

• What the responsibilities?

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.

4.2.1 OOA Phase

What to do during OOA?

Determine the functionality of the system, usually called requirements

analysis.

Create a list of what classes are part of the system, and (just as important)

what classes are not part of the system.

Distribute the functionality of the system among the list of classes. A piece of

functionality assigned to a specific class is called a responsibility

In the real world, however, this is often the trickiest part of the software engineering

process, as it is not always clear what the program is going to need to do. Typically what

is done in an object-oriented requirements analysis is to create a list of use cases, small

interactions that the system will have to support.

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?

• Choosing from candidate classes?

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.



Two things to keep in mind while brainstorming are:

This is the beginning of your process, not the end – do not worry about how any of this

is going to be implemented yet. If it helps, pretend at this point that implementation is

somebody else's problem

Do not throw anything out. Two reasons. First, you never know when some crazy idea

is going to wind up saving your project. Second, the classes that you don't include in the

system are just as important for defining the bounds of your system as the ones that are

inside.

Here are some good places to look for candidate classes:

Go through your requirements document, and circle all the nouns.

Think about the system. An object is a person, place or thing (usually).

Who are the people in the system? What roles do they play?

In what places does the system occur?

What tangible things are used in the system?

What transactions or sessions might need to be remembered?

Are some of the things you have listed specific instances of a more general concept, or

vice versa?

Will some objects contain or be contained by other objects?

4.2.1.2 Assigning Responsibilities

CRC stands for Class, Responsibility, Collaborator

Classes will carry responsibilities assigned to them.

The tool for managing this activity is called a CRC card

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.



The other activity of OOA is assigning responsibilities to the classes that will carry them

out. The tool for managing this activity is called a CRC card. CRC stands for Class,

Responsibility, Collaborator, and describes the information on the card. Each class in the

system has its own CRC card, which contains a list of all the responsibilities of that class,

along with the other classes which collaborate in carrying out those responsibilities.

Ward Cunningham invented CRC cards in response to a need to document collaborative

design decisions. The cards started as a HyperCard stack which provided automatic

indexing to collaborators, but were moved to their current form to address problems of

portability and system independence.

CRC cards explicitly represent multiple objects simultaneously. However, rather than

simply tracing the details of a collaboration in the form of message sending, CRC cards

place the designer's focus on the motivation for collaboration by representing

(potentially) many messages as a phrase of English text.

As it is currently used, all the information for an object is written on a 4" x 6" index card.

These have the advantages that they are cheap, portable, readily available, and familiar.

Design with the cards tends to progress from known to unknowns, as opposed to top-

down or bottom up. Two teams could arrive at essentially the same design through nearly

opposite sequences, one starting with device drivers, the other with high- level models.

The problem demanded a certain set of capabilities which both teams discovered in the

course of fulfilling the requirements of the design.

4.2.1.3 CRC Modeling

AA CCRRCC mmooddee ll iiss rreeaa llllyy aa ccoo lllleecctt iioonn oo ff ssttaannddaa rrdd iinnddeexx ccaa rrddss tthhaa tt rreepp rreesseenntt cc llaasssseess.

The cards are divided into three sections

• Along the top of the card: write the name of the class

• In the body: list of class responsibilities on the left and collaborators on the right

Responsibilities

• Are the attributes and operations that are relevant for the classes



• “anything the class knows or does”

Collaborations

• Those classes that are required to provide a class with the information needed to

complete a responsibility

• Implies either a request for information or a request for some action

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.

CRC Index Card

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.

Class name

Responsibilities Collaborators



Some other tips on creating responsibilities :

• Keep it simple. Each responsibility should be a short phrase -- not a sentence, and for

sure not a paragraph.

• This is still a brainstorm activity, so the main goal is to just get things down on paper.

• Focus on what, not how implementation is still not your problem yet.

• Look for commonalties among classes you may be able to factor them out using

inheritance.

How are responsibilities assigned?

Either you have a list of responsibilities and you are trying to assign them to classes, or

you have a class and you are trying to define its responsibilities. Keep the following

principles in mind:

• The anthropomorphic principle: an object is responsible for all the things that would be

done to it in the real world.

• The expert principle: assign a responsibility to the class or classes that have the

knowledge to perform it.

• If more than one object has the knowledge, then the two classes should collaborate on

the responsibility.

• Distribute responsibility -- no one class should have most of the responsibilities. You

shouldn't be able to point to one class as the "center" of your design.

• Each class should have some responsibility, if not, question whether it belongs there at

all.

• If a class seems to have too much responsibility, or if its responsibilities seem unrelated,

look for ways to split it into smaller classes.

• Rarely, a responsibility may become a class all by itself. Look for this if the

responsibility is quite large, and potentially applies to a number of classes in your system

that are not otherwise related.

4.2.1.4 OOA Checkpoint

- The classes are relatively small.

- Responsibility and control are distributed.



- Information with different rates of change are separated.

- There are few assumptions about the language or system it will be implemented in.

- The OOA describes the world, not computer-science jargon.

- The objects in the system all have some responsibility.

- No object is merely a "manager" of another object's data.

- If the requirements were extended to include more things, the existing parts of the

design would only change minimally.

- If the input or output methods of the program were to change radically, the existing

design would only change minimally.

- There should be no redundancy.

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.

The ideal class

There is a clearly associated abstraction.

The class name is a noun or adjective, adequately characterizing the abstraction.

The class represents a set of possible run-time objects, its instances.

Several queries are available to find out properties of an instance.

Several commands are available to change the state of an instance.

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

4.2.2. OOD Checkpoint

- It is clear from the OOD how you would write your code.

- Every class should have at least one attribute or object connection.

- Every class should have at least one service.

- No object knows about every other object in the system

• No object is the clear "center" of the information flow.

- Objects connect to other objects only if they need information from them.

- There are no unnecessary middlemen

- Attributes and services are as high in the inheritance hierarchy as possible

4.3 Software problems

“Unsuccessful software projects fail in their own unique ways, but all successful

projects are alike in many ways”

- Grady Booch

Symptoms of software development problems

• User needs not met

• Requirements churn



• Modules do not integrate

• Hard to maintain

• Late discovery of flaws

• Poor quality or end-user experience

• Build-and-release issues

• Does not perform well for peak data

• No coordinated team work

4.4 Best practices of software engineering

Practice 1 - Develop iteratively

• A technique that is used to deliver the functionality of a system in a successive

series of releases of increasing completeness. Each iteration is focused on defining,

analyzing, designing, building and testing some set of requirements.

Practice 2 - Manage requirements

• Make sure you solve the right problem and build the right system by taking a

systematic approach to eliciting, organizing, documenting and managing the

changing requirements of a software application.

Practice 3 - Use component architecture

• It leads to resilient systems and to achieve it architects must anticipate evolution in

both problem domain and implementation technologies to produce a design that

can gracefully accommodate such changes. Key techniques are abstraction,

encapsulation and object-oriented analysis and design.

Practice 4 - Model visually

• They let us maintain consistency among a system‟s artifacts: its requirements,

design and implementation. It helps improve a team‟s ability to manage software

complexity.

Practice 5 - Continuously verify quality



• It is not just developing a software which meets the users needs and expectations; it

includes identifying the measures and criteria and the implementation of a process

to ensure that the resulting product ahs achieved the desired degree of quality.

Practice 6 - Manage change

• Control how and when changes are introduced into project artifacts and who

introduces the changes. Also synchronize change across development teams and

locations.

Object-Oriented system development consists of

Object-oriented analysis

Object-oriented information modeling

Object-oriented design

Prototyping and implementation

Testing, Iteration, and Documentation.


1. CRC stands for _______,_________,__________

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.


4.7 Review Questions

1. Explain briefly the various activities occur during Object-oriented system

development.

2. Discuss briefly Best practices of software engineering.

3. Briefly explain the software development problems.

4. List out OOA Checkpoint.

5. List out OOD Checkpoint.

6. Explain CRC model with an example.



UUMMLL



UNIT 5: Unified Modeling Language

5.0 Objectives: At the end of this unit, You would be able to:

Define the terms: model, process

Understand the Architecture of UML, RUP

Understand the Phases and iterations

Understand the Steps in UML

Understand the concept of Modeling and UML

Understand the Goals of UML

Know the Outside Scope Of UML

Understand An overview of UML

Know the what are Modeling elements

Know what are the Relationships

Know the various kinds of UML diagrams

Get an idea about the Extensibility mechanisms

55..11 IInnttrroodduuccttiioonn

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.

5.2 UML and brief background

UML is a language for specifying, visualizing, documenting and constructing the artifacts

of software systems, as well as for business modeling and other non-software systems.

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

5.2.1 Architecture of UML

UML is designed using the metamodel architecture, the layers of which are

(a) Meta-metamodel layer - consists of the most basic elements on which UML

is based - the concept of a thing, representing anything that may be defined.

(b) Metamodel layer - consists of the elements that constitute the UML,

including concepts from OO domain and component-oriented paradigms.

(c) Model layer - consists of UML models. It is at this level that the modeling of

problems, solutions or systems occur.

(d) User model layer - consists of those elements that exemplify UML models.

Each concept within this level is an instance of a concept within the model

layer.

To understand the architecture of the UML, consider how computer programs and

programming languages are related. All programming languages support various

declarative constructs for declaring data and defining the logic that manipulates the data.

Because a model is an abstraction, each of these concepts may be captured in a set of

related models. Programming language concepts are defined in a model called the

metamodel. Each particular programming language is defined in a model that uses and

specializes the concepts within the metamodel. Each program imp lemented 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.



5.2.2 Why is UML powerful ?

• As an object-oriented modeling language, all the elements and diagrams in UML are

based on object-oriented paradigms.

• UML was developed having the RUP model in mind.

This model is

1. Iterative and incremental

2. Architecture centric

3. Use case driven

• UML can be used to model a broad range of systems, a few of which are information

systems, technical systems, distributed systems, business systems and real-time

systems

• UML can also be used in the different phases of software development, from

requirements specification to test of a finished system

5.2.3 What is a process?

• Defines WHO is doing WHAT, WHEN to do it and HOW to reach a certain goal

New or changed New or changed Requirements System

Rational Unified Process (RUP)

• Any good process model

1. Provides guidelines for efficient development of quality software

2. Reduces risk and increases predictability

3. Promotes a common vision and culture

Software

Engineering Process



4. Captures and institutionalizes best practices.

• RUP is

1. Iterative and incremental

2. Use case driven

3. Architecture centric

An iterative process is one that involves managing a stream of executable releases. An

incremental process is one that involves the continuous integration of the system‟s

architecture to produce these releases, with each new release embodying incremental

improvements over the other. Together, an interactive and incremental process is risk-

driven, meaning that each new release is focused on attaching and reducing the most

significant risks to the success of the project.

Use-Case driven means that the use cases are used as a artifact for establishing the

desired behavior of the system, for verifying and validating the system‟s architecture, for

testing, and for communicating among the stakeholders of the project.

Architecture-centric means that a system‟s architecture is used as a primary artifact for

conceptualizing, constructing, managing, and evolving the system under development.

5.3 Phases and Iterations • A phase is span of time between two major milestones of the process

• An iteration is a sequence of activities with an established plan and evaluation criteria,

resulting in an executable release.

LLiiffeeccyyccllee pphhaasseess

Inception Elaboration Construction Transition



time

Inception: Define the scope of the project and develop business case

Elaboration: Plan project, specify features, and baseline the architecture.

Construction: Build the product.

Transition: Transition of the product to its users.

UML v/s Software Design Process Phases



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

• Describe run time architecture



– Identify active classes and threads

– Process diagram

– Activity diagram

• Describe distribution

– Deployment diagram

5.5 Modeling and UML:

Model

-- It is a simplification of reality and we build models so that we can better

understand the system we are developing

• The Unified Modeling Language (UML) is a language for

-- Specifying the structure and behavior of a system

-- Visualizing a system as it is or as we want it to be

-- Constructing a system from the template provided by the model

-- Documenting the decisions made

• UML represents a collection of best engineering practices that have proven

successful in the modeling of large and complex systems

The use of modeling has a rich history in all the engineering disciplines. That experience

suggests four basic principles of modeling which are as follows :

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

A healthy software organization produces all sorts of artifacts in addition to raw

executable code. These artifacts include requirements, architecture, design, source code,

project plans, rests, prototypes, and releases.

5.6 Goals of UML

The primary goals in the design of UML were as follow:

• Provide users a ready-to-use, expressive visual modeling language so they can ddeevvee lloopp

aanndd eexxcchhaannggee mmeeaanniinnggffuull mmooddee llss.

•• Provide extensibility and specialization mechanisms to eexxtteenndd tthhee ccoorree ccoo nncceeppttss..

• Be iinnddeeppeennddeenntt oo ff ppaa rrtt iiccuullaa rr pprroo ggrraammmmiinngg llaanngguuaaggeess and development processes.

• Encourage the ggrroowwtthh oo ff tthhee OOOO ttoooo llss market.

• Support hhiigghheerr-- lleevvee ll ddeevvee llooppmmeenntt ccoonncceeppttss such as collaborations, frameworks,

patterns, and components.

• Integrate bbeess tt pprraacc tt iicceess.

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.

5.7 Outside the Scope of the UML

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

5.8 An overview of UML

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

Component view is a description of the implementation modules and their dependencies.

The code modules are shown with their structure and dependencies.

The concurrency view deals with the division of the system into processes and

processors. This aspect which is a non-functional property of the system deals with

efficient resource usage, parallel execution and the handling of asynchronous events from

the environment.

Finally, the deployment view shows the physical deployment of the system, such as the

computers and devices and how they connect to each other.

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

5.8.3 Relationships connect modeling elements

They could be

– Association

– Generalization

– Dependency

– Realization

State

UseCase

(from Use Case View)

Package Componenet

Note



Realization is a semantic relationship between classifiers, wherein one classifier specifies

a contract that another classifier guarantees to carry out.

5.8.4 UML diagrams

• A diagram is a view into a model

• UML defines these diagrams

Use Case Diagrams Use Case Diagrams

Use Case

Diagrams

Scenario Diagrams

Scenario Diagrams

Collaboration

Diagrams

State Diagrams

State Diagrams

Component

Diagrams

Component

Diagrams Component

Diagrams Deployment

Diagrams

State Diagrams

State Diagrams

Object

Diagrams

Scenario Diagram

s

Scenario Diagrams

Statechart

Diagrams

Use Case Diagrams Use Case Diagrams

Sequence

Diagrams

State Diagram

s

State Diagrams

Class

Diagrams

Activity

Diagrams

Models



5.8.5 Extensibility Mechanisms

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



Unit 6: UML MMooddeelliinngg eelleemmeennttss

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.

• MMooddee lliinngg ee lleemmeennttss 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 :


Understand the types of Modeling elements

Understand the representational notations of Class, Object

Understand the representational syntax of Attributes and Operations

Understand the representational notations of Interface, Relationships

Understand the representational notations of Binary, Reflexive and N-array

Association, Dependency

Understand the representational notations of Links, Aggregation, Composition



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

• The bottom compartment holds a list of operations

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

vv iissiibbiill iittyy nnaammee :: ttyyppee--eexxpprreessssiioonn == iinn iitt iiaall --vvaalluuee {{ pprrooppeerrttyy--ssttrriinngg}}

where visibility is one of:

+ public visibility

# protected visibility

- private visibility

• Visibility may also be specified by keywords public, protected or private

• A non-changeable attribute is specified with the property “{frozen}”

• Multiplicity may be indicated by placing a multiplicity indicator in brackets after the

attribute name, for example:

ccoo lloorrss [[33 ]] :: CCoo lloo rr ppooiinnttss [[22....** ]] :: PPoo iinntt

• In the absence of a multiplicity indicator an attribute holds exactly 1 value

Example:

++ssiizzee:: AArreeaa == ((110000,,110000)) ##vviissiibbii llii ttyy:: BBoooolleeaann == iinnvviissiibbllee

++ddeeffaauulltt --ssiizzee :: RReeccttaannggllee ##mmaaxxiimmuumm--ssiizzee :: RReeccttaannggllee

--xxpp ttrr:: XXWWiinnddoowwPPttrr



In the absence of a multiplicity indicator an attribute holds exactly 1 value. Multiplicity

may be indicated by placing a multiplicity indicator in brackets after the attribute name,

for example:

colors [3]: Color

points [2..*]: Point

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.

6.2.1.1 Attribute Compartment



6.2.1.2 Attribute Scope

• Specifies weather the feature appears in each instance of the classifier

• Instance

• Each Instance holds its own value

• Class

• There is just one value for all the instances

6.2.1.3 Derived Element

• Derived element is one that can be computed from another one

• Normally shown for clarity

• Some times included for design purposes even though it adds no semantic information

• Shown by placing a slash (/) in front of an attribute

Example:

Header : FrameHeader

uniqueID : Long

Frame

Instance scope

Class scope



6.2.2 Operation

• Used to show operations defined on classes

• An operation is a service that an instance of the class may be requested to perform

• An operation is shown as a text string that can be parsed into the various properties of

an operation model element

The default syntax:

vviissiibbii llii ttyy nnaammee (( ppaarraammeetteerr--ll iisstt )) :: rreettuurrnn-- ttyyppee--eexxpprreessssiioonn {{ pprrooppeerrttyy --ssttrriinngg }}

where parameter-list is a comma-separated list of formal parameters, each specified

using the syntax:

name : type-expression = default-value

• An operation that does not modify the system state (one that has no side effects) is

specified by the property “{query}”

• The concurrency semantics of an operation are specified by a property string with one

of the names: sequential, guarded, concurrent

Example:

++ ccrreeaattee (())

++ ddiisspp llaayy (()) :: LLooccaa tt iioonn

++ hhiiddee (())

-- aattttaacchhXXWWiinnddooww((xxwwiinn::XXwwiinnddooww** ))



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 : oobbjjeecc ttnnaammee :: cc llaassssnnaammee

• The second compartment shows the attributes for the object and their values as a list

•• Each value line has the syntax: aattttrriibbuutteennaammee :: ttyyppee == vvaalluuee

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»



• A list of operations supported by the interface is placed in the operation compartment

• The attribute compartment may be omitted because it is always empty

• 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

• Packages and Model Organization

- It is a grouping of model elements that may be nested and all kinds of UML

model elements and diagrams can be organized into packages.

- Packages own model elements and model fragments and are the basis for

configuration control, storage, and access control .

- Each element can be directly owned by a single package, so the package

hierarchy is a strict tree.

- Packages can reference other packages, so the usage network is a graph.



A package is a grouping of model elements. Packages themselves may be nested within

other packages. A package may contain both subordinate packages and ordinary model

elements.

Some packages may be Subsystems or Models. The entire system description can be

thought of as a single high- level subsystem package with everything else in it. All kinds

of UML model elements and diagrams can be organized into packages.

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.

PPaacckkaaggee AA



UUNNIITT 77:: RReellaattiioonnsshhiippss connect modeling elements

7.0 Introduction

These bind the modeling elements.

7.1 Objectives :


Understand the Relationships Among Classes

Understand the Relationships Among Objects

Understand the Relationships Notations

7.2 Relationships Notations

-- Among Classes

• Association

• Aggregation

• Composition



• Generalization

• Dependency

• Realization

--- Among objects

• Links

7.3 Association

• It is an structural, static relationship between two or more classes

• May be a reflexive association from a class to itself

• A binary association is drawn as a solid path connecting two class symbols

• Or-association specifies that objects of a class may participate in at most one of the

associations at time.

OOrr AAssssoocciiaattiioonn

RReefflleexxiivvee AAssssoocciiaattiioonn AAssssoocciiaattiioonn

CCoouurrssee

SSttuuddeenntt

PPrrooffeessssoorr



7.4 Association End

The following kinds of adornments may be attached to an association end:

• Multiplicity

• 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

• Represents a “has-a” (whole-part) relationship

• An object of the whole has objects of the part

7.6 Composition

• Shown by a solid filled diamond as an association role adornment

Company

Department

Whole

part

aggregation



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/dis joint - 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.

Multiple

inheritance

Single inheritance



Generalization with constraints

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.

Various usage dependencies among classes



Dependencies among packages

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.

AAnnaallyyssiiss cc llaassss DDeessiiggnn ccllaassss

VVaalliiddaattee

uussee rr VVaalliiddaattiioonn

RReeaalliizzeess



7.10 Relationship between Objects:

--These bind the modeling elements.

Links

aController

a:DisplayItem

b: DisplayItem

aView

move()

isUnder()



Unit 8: Diagrams in UML

8.0 Introduction

The UML defines nine graphical diagrams:

1. Functional diagram

- Use case diagram

2. Static view diagrams(Structural diagrams)

- Class diagram

- Object diagram

3. Dynamic view diagram(Interaction diagrams)

- State diagram

- Interaction diagram

o Sequence diagram

o collaboration diagram

- Activity diagram

4. Implementation diagram

- Component diagram

- Deployment diagram

8.1 Objectives :


Understand the Functional diagram: - Use case diagram



Understand the Static view diagrams: - Class diagram, Object diagram

Understand these Dynamic view diagrams:- State diagram, Interaction diagram,

Activity diagram

Understand these Implementation diagrams:- Component diagram, Deployment

diagram.

8.2 Use Case model

1. A use case model consists of

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

Components of Use Case Model



USE CASE DIAGRAM

+

USE CASE DESCRIPTIONS

+

SUPPLEMENTARY SPECIFICATION

A Use Case Diagram shows a set of external Actors and their Use Cases connected with

communication associations. The communication associations between the Actors and

their Use Cases define the boundary between the system and its external environment.

The communication associations may be augmented to show the messages and events

exchanged between Actors and Use Cases. Messages and events may be shown through

relevant notes attached to specific communication associations.

A Use Case Description documents the detailed behavior and assumptions about a

particular Use Case. Sometimes this is accomplished using natural language descriptions.

Often, some form of template is used, accompanied by natural language descriptions of

the various execution paths through the Use Case. Natural language descriptions of the

Use Case behavior can be augmented or replaced by diagrammatic notations, such as

UML Activity Diagrams or flow charts.

Supplementary specification normally captures the non-functional requirements of the

system like performance, response time, scalability and design constraints.

Use case

- A use case is a sequence of actions a system performs that yield an observable

result of value to an particular actor.

- The characteristics of a use case are

o It should be complete

o It should always be initiated by actor

o It should provide an value to an actor



- An instantiation of a use case is called a scenario

Primary purpose of Use Case

o To decide and describe the functional requirements of the system

o To give a clear and consistent description of what the system should do. This

allows the model to be used throughout the development process

o To provide a basis for performing system tests that verify the system

o To provide the ability to trace functional requirements into actual classes and

operations in the system

Relationship between use cases

The relationship between use cases are

o Extends relationship - it is a generalization relationship where one use case

extends another by adding actions to a general use case. The extending use

case may include behavior from the use case being extended, depending on

conditions of extension.

o Uses relationship - it is a generalization relationship where one use case uses

another use case, indicating that as part of the specialized use case, the

behavior of the general use case will also be included.

o Grouping - when a number of use cases handle similar functionality or are

related they can be bundled in a UML package.

WWiitthhddrraawwmmoonneeyy



Actors

An actor is someone/something that interacts with the system.

An actor can be a human being or another system.

Actors can be ranked and they can be primary actors(they use systems main

functionality ) or secondary actors(they use secondary functions of the system

like managing Dbs, backups etc.)

Actors can be active in which case they initiate an use case or they can be

passive in which case they participate in an use case.

They are classes in UML with stereotype <<actor>> and hence can have the

same relationship as classes. In UCD only generalization relationship is used

to describe common behavior among a number of actors.

Relationship between actors

Customer

(from Use Case View)

Commercial

Customer(from Use Case View)

generalization

Actor



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.

IInnssuurraannccee bbuussiinneessss

Example -Use case diagram



Use case description

The description of use case is done through a text description

The text description should include :

(a) Objective for the use case

(b) Actors

(c) Preconditions

(d) Triggering event

(e) Description of main success path

(f) Description of alternative path

(g) Associations to other use cases

An use case can also be described though an activity diagram

Use case can be complemented by a number of actual scenarios

Describing Use Cases Use Cases can be described using natural language text; however,

most experts recommend using some sort of template so that useful information is not

overlooked. Every template includes a place for describing the main processing path of a

successful execution of the Use Case, as well as places for describing the alternative

paths contained within the Use Case. See Slide UC-16 for one example of a Use Case

template. As an alternative to, or an augmentation of, the natural language description of



behavior, diagrammatic notations, such as flow charts or activity diagrams can be used.

We will discuss activity diagrams in the next lecture.

Describing Actors Each Actor (including all devices, timers, external systems, and user

roles) should be described, too. Of main concern are: the specific Stereotype of each

Actor, relevant performance data that can affect the system design, and a description of

the interface presented by the Actor, including any error states that might occur. Slide

UC-17 gives a simple, example template for describing Actors.

Supplementary specification

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

Testing Use Case

Two very different types of tests are performed on use cases : vveerriiffiiccaattiioonn

aanndd vvaall iiddaattiioonn

VVeerriiffiiccaatt iioonn: confirms that the system is developed correctly



- Cannot be carried out until there are working parts of the system

VVaalliiddaa ttiioo nn: assures that the system under development is one that the user

really needs

o Done up front in the process

o To ensure, customers must understand the model and its meaning

o Also done at system test time: not the preferred one

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

Use cases are implementation-independent

The UML principles for realizing the use cases are:

- A use case is realized as collaboration

- A collaboration is represented in UML as a number of diagrams showing

both the context and the interaction between the participants in the

collaboration

- A scenario is an instance of a use case or a collaboration

Use Cases are implementation- independent descriptions of system functionality of the

system. This means that the use cases are realized in the system, that the responsibilities

to perform the actions described in the use-case descriptions are allocated to collaborating

objects that implement the functionality.



8.3 Static view diagrams(Structural diagrams)

- Class diagram

- Object diagram

8.3.1 Class Diagrams

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



Well Structured Class Diagram

Is focused on communicating one aspect of a system

Contains only elements that are essential to understanding that aspect

Provides details consistent with its level of abstraction

Is not so minimalist

Has a name that communicates its purpose

88..33..22 OObbjjeecctt DDiiaaggrraamm

An object diagram is a graph of instances, including objects and data values

A object diagram is an instance of a class diagram; it shows a snapshot of the

detailed state of a system at a point in time

The same notations as for class diagrams is sued, with two exceptions :

objects are written with their names underlined and all instances in a

relationship are shown.

They are not as important as class diagrams but can be used to exemplify a

complex class diagram by showing what the actual instances and the

relationships could look like.



An object diagram shows the existence of objects and their relationships in the logical

design of a system. An object diagram may represent all or part of the object structure of

a system, and primarily illustrates the semantics of mechanisms in the logical design. A

single object diagram represents a snapshot in time of an otherwise transitory event or

configuration of objects.

An object diagram is a graph of instances, including objects and data values. A static

object diagram is an instance of a class diagram.

The use of object diagrams is fairly limited, mainly to show examples of data structures.

Tools need not support a separate format for object diagrams. Class diagrams can contain

objects, so a class diagram with objects and no classes is an “object diagram.”

Object Diagram – Example

d1:department

Name=“sales”

c:company

:Department

Name=“R&D”

Link

Attribute Value

Anonymous object

object



8.4 Dynamic view diagram

88..44..11 SSttaatteecchhaarrtt DDiiaaggrraamm

A state diagram is a complement to the description of a class.

It shows all the possible states that an object can have and which events cause

the state to change. In a state diagram

The solid filled circles indicate starting point

The circle surrounding the circle indicates the end point

The state is shown as a rectangle with rounded corners

A state diagram for invoices

IInnssuurraannccee bbuussiinneessss

UUnnppaaiidd PPaaiidd PPaayyiinngg

IInnvvoo iiccee

CCrreeaatteedd

IInnvvoo iiccee

DDeesstt rroo yyeedd



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

88..44..22..11 SSeeqquueennccee DDiiaaggrraamm

• A sequence diagram shows an interaction arranged in time sequence.

- In particular, it shows the objects participating in the interaction by their

“lifelines” and the messages that they exchange arranged in time sequence

- It does not show the associations among the objects

- Better for real-time specifications and for complex scenarios.

o A sequence diagram has two dimensions

o The vertical dimension represents time.

Normally time proceeds down the page

o The horizontal dimension represents different objects.

There is no significance to the horizontal ordering of the objects

Sequence Diagram



Simple sequence diagram with concurrent objects

A sequence diagram shows an interaction arranged in time sequence. In particular, it

shows the objects participating in the interaction by their “lifelines” and the messages

that they exchange arranged in time sequence. It does not show the associations among

the objects. Sequence diagrams come in several slightly different formats intended for

different purposes. A sequence diagram can exist in a generic form (describes all the

possible sequences) and in an instance form (describes one actual sequence consistent

with the generic form). In cases without loops or branches, the two forms are isomorphic.

Sequence Diagram

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 message is a communication between objects that conveys information with the

expectation that action will ensue. The receipt of a message is one kind of event.

A message is shown as a horizontal solid arrow from the lifeline of one object to the

lifeline of another object. In case of a message from an object to itself, the arrow may

start and finish on the same object symbol. The arrow is labeled with the name of the

message (operation or signal) and its argument values. The arrow may also be labeled

with a sequence number to show the sequence of the message in the overall interac tion.

Sequence numbers are often omitted in sequence diagrams, in which the physical location

of the arrow shows the relative sequences, but they are necessary in collaboration

diagrams. Sequence numbers are useful on both kinds of diagrams for identifying

concurrent threads of control. A message may also be labeled with a guard condition.

Transition Times

A message may have a sending time and a receiving time

i. The two may be the same (if the message is considered atomic)

ii. Different (if its delivery is non-atomic)

These are formal names that may be used within constraint expressions

A transition instance may be given a name

In cases where the delivery of the message in not instantaneous, the time at

which the message is received is indicated by the transit ion name with a

prime sign appended

Constraints may be specified by placing Boolean expressions in braces on the

sequence diagram



A message may have a sending time and a receiving time. These are formal names that

may be used within constraint expressions. The two may be the same (if the message is

considered atomic) or different (if its delivery is nonatomic).

A transition instance (such as a message in a sequence diagram or a collaboration

diagram or a transition in a state machine) may be given a name. The name represents the

time at which a message is sent (example: A). In cases where the delivery of the message

in not instantaneous, the time at which the message is received is indicated by the

transition name with a prime sign appended (example: A'). The name may be shown in

the left margin aligned with the arrow (on a sequence diagram) or near the tail of the

message flow arrow (on a collaboration diagram). This name may be used in constraint

expressions to designate the time the message was sent. If the message line is slanted,

then the primed-name indicates the time at which the message is received.

Constraints may be specified by placing Boolean expressions in braces on the sequence

diagram.

88..44..22..22 CCoollllaabboorraatt iioonn ddiiaaggrraamm

A collaboration diagram shows an interaction organized around the objects in the

interaction and their links to each other

Unlike a sequence diagram, a collaboration diagram shows the relationships

among the object roles

On the other hand, a collaboration diagram does not show time as a separate

dimension

the sequence of messages and the concurrent threads must be determined using

sequence numbers

A collaboration diagram shows an interaction organized around the objects in the

interaction and their links to each other. Unlike a sequence diagram, a collaboration

diagram shows the relation-ships among the object roles. On the other hand, a



collaboration diagram does not show time as a separate dimension, so the sequence of

messages and the concurrent threads must be determined using sequence numbers.

Collaboration

The structure of objects playing roles in a behavior and their

relationships is called a collaboration

A collaboration may be attached to an operation or a use case to describe

the context in which their behavior occurs

May be expressed at different levels of granularity

The description of behavior involves two aspects

i. The structural description of its participants

ii. The behavioral description of its execution

The two aspects are often described together on a single diagram

In a collaboration behavior is implemented by sets of objects that exchange messages

within an overall interaction to accomplish a purpose. To understand the mechanisms

used in a design, it is important to see only the objects and the messages invo lved in

accomplishing a purpose or a related set of purposes, projected from the larger system of

which they are part for other purposes. Such a static construct is called a collaboration.

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.

A collaboration may be expressed at different levels of granularity. A coarse-grained

collaboration may be refined to produce another collaboration that has a finer granularity.



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

A collaboration diagram represents a Collaboration, which is a set of objects related in a

particular context, and an Interaction, which is a set of messages exchanged among the

objects within a collaboration to effect a desired operation or result.

Collaboration Diagram



A collaboration diagram is a graph of references to objects and links with message flows

attached to its links. The diagram shows the objects relevant to the performance of an

operation, including objects indirectly affected or accessed during the operation. The

collaboration used to describe an operation includes its arguments and local variables

created during its execution as well as ordinary associations. Objects created during the

execution may be designated as {new}; objects destroyed during the execution maybe

designated as {destroyed}; objects created during the execution and then destroyed may

be designated as {transient}. These changes in life state are derivable from the detailed

messages sent among the objects; the are provided as notational conveniences.

8.5 Implementation diagram

- Component diagram

- Deployment diagram



8.5.1 Component Diagrams

A component diagram is a graph of components connected by dependency

relationships

A component diagram shows the dependencies among software components

i. Source code components : components that exist at compile time

ii. Binary code components : components that exist at link time

iii. Executable components : components that exist at run time

Dependencies, are shown as dashed arrows from a client component to a

supplier component that it depends on in some way

Component Diagrams

A component diagram shows the dependencies among software components, including

source code components, binary code components, and executable components. A

software module may be rep-resented as a component type. Some components exist at

compile time, some exist at link time, and some exist at run time; some exist at more than

one time. A compile-only component is one that is only meaningful at compile time; the

run-time component in this case would be an executable program.



The components are the implementation in the physical architecture of the concepts and

the functionality defined in the logical architecture ( classes, objects, their relationships,

and collaborations).

Source Components is meaningful at compile time. It is typically a source code file

implementing one or more classes.

Binary component is typically object ocde that is the result of compiling a sourse

component. It could be an object code file, a static library file, or a dynamic library file.

A binary component is meaningful at link time or, in the case of a dynamic library, at run

time.

Executable component is an executable program file that is the result of linking all

binary components. An executable component represents the executable unit that is run

by a processor (computer).

Component Diagrams

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

Realizatio

Dependenc

Interfac

Iconic form trans.dll

nam

System:dialog.dll {version=4.1.3}

Extended components



A component diagram is a graph of components connected by dependency relationships.

Components may also be connected to components by physical containment representing

composition relationships.

A diagram containing component types and node types may be used to show compiler

dependencies, which are shown as dashed arrows (dependencies) from a client

component to a supplier component that it depends on in some way. The kinds of

dependencies are language-specific and may be shown as stereotypes of the

dependencies.

The diagram may also be used to show interfaces and calling dependencies among

components, using dashed arrows from components to interfaces on other components.

Components

A component type represents a distributable piece of implementation of a

system, including software code (source, binary, or executable)

Components may be used to show dependencies, such as compiler and run-

time dependencies

A component instance represents a run-time implementation unit

- Used to show implementation units that have identity at run time, including their

location on nodes

A component is shown as a rectangle with two small rectangles protruding

from its side.

A component type has a type name:

ccoommppoonneenntt--ttyyppee



A component type represents a distributable piece of implementation of a system,

including software code (source, binary, or executable) but also including business

documents, etc., in a human system. Components may be used to show dependencies,

such as compiler and runtime dependencies or information dependencies in a human

organization. A component instance represents a run-time implementation unit and may

be used to show implementation units that have identity at run time, including their

location on nodes.

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

home.html

<<page>>animlogo.java

<<file>>

animator.java

<<document>>

animlogo.doc

<<document>>

animator.doc

<<document>>



A dependency from one compile-time component to other compile-time components

reveal which components are needed to make its definition complete; for instance, which

other compile-time components does it include in its definition.

The result of compilation of one or more compile-time components is to produce link-

time components.

Run-Time components

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

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.

8.5.2 Deployment diagrams

commhandler.dll

<<library>>graphics.dll

<<library>>

umlviewer.exe

<<application>>

dbhandler.dll

<<library>>



o Deployment diagrams show the configuration of run-time processing elements

and the software components, processes, and objects that live on them

o A deployment diagram is a graph of nodes connected by communication

associations

o Software component instances represent run-time manifestations of code units

o Components that do not exist as run-time entities do not appear on these diagrams

o Nodes may contain component instances; this indicates that the component lives

or runs on the node

o Components may contain objects; this indicates that the object is part of the

component.

Deployment diagrams show the configuration of run-time processing elements and the

software components, processes, and objects that live on them. Software component

instances represent run-time manifestations of code units. Components that do not exist

as run-time entities (because they have been compiled away) do not appear on these

diagrams; they should be shown on component diagrams.

o Components are connected to other components by dashed-arrow

dependencies (possibly through interfaces)

o This indicates that one component uses the services of another component; a

stereotype may be used to indicate the precise dependency if needed.

o Stereotypes supported

o <<supports>> components may run on which nodes, by using

dashed arrows

o <<becomes>> Migration of components from node to node or

objects from component to component

A deployment diagram is a graph of nodes connected by communication associations.

Nodes may contain component instances; this indicates that the component lives or runs

on the node. Components may contain objects; this indicates that the object is part of the

component. Components are connected to other components by dashed-arrow



dependencies (possibly through interfaces). This indicates that one component uses the

services of another component; a stereotype may be used to indicate the precise

dependency if needed.

The deployment type diagram may also be used to show which components may run on

which nodes, by using dashed arrows with the stereotype «supports».

Migration of components from node to node or objects from component to component

may be shown using the «becomes» stereotype of the dependency relationship. In this

case the component or object is resident on its node or component only part of the entire

time. Note that a process is just a special kind of object

Deployment Diagrams

Nodes

nam

Componen

clientA:IB

M PC

ClientB:

IBM PC

Application

Server:

<<TCP/IP>>

<<TCP/IP>>



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

o A node is a run-time physical object that represents a processing resource,

generally having at least a memory and often processing capability



o Nodes include computing devices but also human resources or mechanical

processing resources

o Nodes may be represented as type and as instances.

o Run time computational instances, both objects and component instances, may

reside on node instances

oo A node is shown as a figure that looks like a 3-dimensional view of a cube. A

node type has a type name: nnooddee--ttyyppee

A node is a run-time physical object that represents a processing resource, generally

having at least a memory and often processing capability as well. Nodes include

computing devices but also human resources or mechanical processing resources.

Nodes may be represented as type and as instances. A type describes the characteristics

of a processor or device type and an instance represents actual occurrences of the type.

The detailed definition of the capability of the system can be defined either as attributes

or as properties defined for nodes.

Devices in the system are also represented as nodes, typically with a stereotype that

specifies the device type, or at least with a name that clearly defines it as a device node

and not a processor node.

Run time computational instances, both objects and component instances, may reside on

node instances.

Two nodes containing an object (cluster) that migrates from one node to another and also

an object that remains in place.

A node is shown as a figure that looks like a 3-dimensional view of a cube.

A node type has a type name:

node-type

A node instance has a name and a type name. The node may have an underlined name

string in it or below it. The name string has the syntax:

name „:‟ node-type



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.

Containment may also be shown by aggregation or composition association paths.



Nodes may be connected by associations to other nodes. An association between nodes

indicates a communication path between the nodes. The association may have a

stereotype to indicate the nature of the communication path (for example, the kind of

channel or network).

8.6 Summary of Diagrams in UML

1. Functional diagram

- Use case diagram


- 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



UUnniitt 99 :: EExxtteennssiibbiilliittyy MMeecchhaanniissmmss 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 :


Understand the concept of Constraint and Comment

Understand the

Understand these Dynamic view diagrams:- State diagram, Interaction diagram,

Activity diagram

Understand these Implementation diagrams:- Component diagram, Deployment

diagram.

9.2 Constraint and Comment

• Constraint is a semantic relationship among model elements

• Specifies conditions and propositions that must be maintained as true

• Can be pre-defined or user-defined



- User-defined constraint is described in words in a given

language, whose syntax and interpretation is a tool

responsibility

- A constraint represents semantic information attached

to a model element, not just a view of it

• Comment is a text string attached directly to a model element

- Equivalent to a constraint written in the language “text”

- Significant to humans but is not conceptually executable

A constraint is a semantic relationship among model elements that specifies conditions

and propositions that must be maintained as true (otherwise the system described by the

model is invalid, with consequences that are outside the scope of UML). Certain kinds of

constraints (such as an association “or” constraint) are predefined in UML, others may be

user-defined. A user-defined constraint is described in words in a given language, whose

syntax and interpretation is a tool responsibility. A constraint represents semantic

information attached to a model element, not just to a view of it.

A comment is a text string (including references to human-readable documents) attached

directly to a model element. This is syntactically equivalent to a constraint written in the

language “text” whose meaning is significant to humans but which is not conceptually

executable (except inasmuch as humans are regarded as the instruments of interpretation).

A comment can therefore attach arbitrary textual information to any model element of

presumed general importance.

Constraint and Comment

• A constraint is shown as a text string in braces ( { } ).

• The individual tools may provide one or more languages in which formal constraints

may be written.

• One predefined language for writing constraints is OCL

• Otherwise the constraint may be written in natural language.



• Constraint may be a “comment”: it that case it is written in text for “interpretation” by

a human.

• A comment is shown by a text string placed within a note symbol that is attached to a

model element. The braces are omitted to show that this is purely a textual comment.

Constraint and Comment – Example

Constraint across multiple

Note

Constraint placed

inside a note Formal constraint using OCL



9.3 Tagged values

• Users can define new element properties using the tagged value mechanism

• A string may be used to display properties attached to a model element

• Property is used 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

• The keyword is called a tag

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 : kkeeyywwoorrdd == vvaalluuee

Example:

{{ aauutthhoorr == ““JJooee SSmmiitt hh”” ,, ddeeaaddlliinnee == 3311--MMaarrcchh--11999977,, ssttaattuuss == aannaallyyssiiss }}

{{ aabbssttrraacctt }}

Tagged Values – Examples

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

• Stereotypes represent one of the built- in extensibility mechanisms of UML

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

Server

{processors=3}

Tagged Value

<<library>>

trans.dll

{serverOnly}

Value of Tag



a usage distinction. A stereotyped element may have additional constraints on it from the

base class. It is expected that code generators and other tools will treat stereotyped

elements specially. Stereotypes represent one of the built- in extensibility mechanisms of

UML.

The general presentation of a stereotype is to use the symbol for the base element but to

place a key-word string above the name of the element (if any); the keyword string is the

name of the stereotype within matched guillemets, which are the quotation mark symbols

used in French and certain other languages, as for example: «foo». (Note that a guillemet

looks like a double angle-bracket but it is a single character in most extended fonts. Most

computers have a Character Map utility. Double angle-brackets may be used as a

substitute by the typographically challenged.) The keyword string is generally placed

above or in front of the name of the model element being described. The keyword string

may also be used as an element in a list, in which case it applies to subsequent list

elements until another stereotype string replaces it, or an empty stereotype string («»)

nullifies it. Note that a stereotype name should not be identical to a predefined keyword

applicable to the same element type.

• The general presentation of a stereotype is to use the symbol for the base element but

to place a keyword string above the name of the element (if any)

• The keyword string is the name of the stereotype within matched guillemets, as for

example: «extends»

• The classification hierarchy of the stereotypes themselves could be displayed on a

class diagram

To permit limited graphical extension of the UML notation as well, a graphic icon or a

graphic marker (such as texture or color) can be associated with a stereo type. 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 Name

stereotype

with Icon

Stereotype

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.

Fill in the blanks

1. UML is a language for specifying, ___________,_________,______ and

_____ the artifacts of software systems, as well as for business modeling and

other non-software systems.

2. UML can be used to model a broad range of systems, a few of which are

information systems, technical systems, ______systems, _____ systems and

____ systems.

4. UML represents a collection of best engineering practices that have proven successful

in the modeling of _____ and ____ systems.

5. A Use Case Diagram shows a set of external Actors and their Use Cases connected

with communication associations. The communication associations between the

______ and their _______ define the boundary between the system and its external

environment.

6. An object diagram is a graph of instances, including objects and data values. A static

object diagram is an instance of a ________diagram.

7. Class diagrams show the static structure of the model, in particular, the things that

exist (such as classes and types), their internal ________, and their __________ to

other things



8. A sequence diagram shows an interaction arranged in time sequence. In particular, it

shows the objects participating in the interaction by their _______ and the

__________ that they exchange arranged in time sequence

9. A collaboration diagram shows an interaction organized around the objects in the

______ and their _______ to each other. Unlike a sequence diagram, a collaboration

diagram shows the relation-ships among the object roles.

9. A component diagram is a graph of components connected by dependency

relationships. Components may also be connected to components by physical

________representing composition relationships

10. Deployment diagrams show the configuration of run-time processing elements

and the software components, processes, and ______ that live on them. Software

component instances represent _________ manifestations of code units

Objective type questions.

1.Goals of UML as stated by the designers are

(a) To model systems using OO concepts, and To establish an explic it coupling to

conceptual as well as executable artifacts

(b) To address the issues of scale inherent in complex, mission-critical systems

(c) To create a modeling language usable by humans and machine

(d) All the above

(e) None of the above

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

4. The Unified Modeling Language (UML) is a language for

i. specifying the structure and behavior of a system

ii. visualizing a system as it is or as we want it to be

iii. constructing a system from the template provided by the model

iv. documenting the decisions made

v. None of the above

vi. All the above

5. Relationships connect modeling elements. They could be

i. dependency

ii. association

iii. generalization

iv. realization

v. None of the above

vi. All the above

6. Extensibility Mechanisms

a. Stereotype

b. Tagged value

c. Constraint


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


(a) Class diagrams

(b) Object diagrams

(c) Both (a) and (b)


(e) All the above

9. Interaction diagram are:

(a) Sequence diagram

(b) collaboration diagram

(c) Both (a) and (b)


(e) All the above

10. Implementation diagrams are :

a. Component diagram

b. Deployment diagram

c. Both (a) and (b)


e. All the above



11. A use case model consists of

(a) Use cases

(b) Actors

(c) System modeled

(d)All the above

(e)None of the above

12. The characteristics of a use case are

(a) it should be complete

(b) it should always be initiated by actor

(c) it should provide an value to an actor

(d) All the above

(e) None of the above

13. The relationship between use cases are

(a) Extends relationship

(b) Uses relationship

(c) Grouping

(d) All the above

None of the above

OOAD and UML - Penciljipencilji.com/download/30147121.pdf · OOAD and UML Prabhudeva S. Assistant...

Documents

Transcript of OOAD and UML - Penciljipencilji.com/download/30147121.pdf · OOAD and UML Prabhudeva S. Assistant...