OOAD Notes

April 8-12, 2002 NIC Delhi

By Mr. Achalla, (Reformatted Ramesh Nougain)

Day 1

RUP has two types of workflows.

1. Main Workflows
• Business Modeling
• Requirements
• Analysis and Design
• Implementation
• Testing
• Deployment
2. Sub Workflows
• Project Management
• Environment
• Configuration Management

Every workflow will have many activities, which are performed by a worker.
To perform that activity, he/she needs an input artifact. He is responsible for
generating certain output artifacts.

Procedural paradigm – Principles – Modularity. (Structures/ functions).

OO Paradigm – Principles – Modularity (Class, packages, subsystems)

Object and Class

Class Object
Car Maruti car
Employee Ram
Book Title of the book
Furniture Chair
Hardware Pentium 4
Group Transport
Bank Citibank
State Delhi
Country India
Trainer Achalla
Cricket player Sachin Tendulkar

Class – a concept, a prototype.

Object – provides visibility to the class.

Vehicle –> 4 Wheeler –> car -> Hyundai Santro -> my hyundai snatro, bright
silver, lp , owned by achalla, parked in MG Road Bangalore on 8/4/2002 at
8.00 pm.
Characteristics of an object
1. Occupy space.
2. Lifetime.
3. Unique.
4. Identity.
5. State – an object exist in a particular state at any time.

Architecture of an object
6. Object has specific properties (values).
• Static – doesn’t change often.
• Dynamic – keeps changing.
Car 1 Car 2
Red Green
Santro Zen
Ka01-x323 Ka02-333
Hari Rama
Parked Moving
Left
Lodhi Road Mathura Road
On 8/4/2002 On 8/4/2002
At 2:30 pm At 2:30 pm

7. Objects exhibit behaviors.

• Iterator.
• Selector.
• Modifier.
8. Iterator – used to maintain the state of an object and should be called
repetitively throughout the lifetime of an object.
9. Selector – used to retrieve the state of an object.
10. Modifier – updates the dynamic property of an object.
11. When one or more properties of an object change, its state changes.

Basic Principles of Object Orientation

Major Principles.
1. Abstraction.
2. Encapsulation.
3. Modularity.
4. Hierarchy.
Minor Principles.
1. Typing.
2. Persistence.
3. Concurrency.
4. Distribution.

Abstraction –
Abstract – not clear, complex, vague.
Abstract – gist, brief, summary.
Abstraction is a process of making things clear.
In software development perspective --
Input to Abstraction – problem statement, client statement.
Output – domain classes.

Guidelines for Abstraction Process.

1. Identify the important behaviors of the application domain.
2. Ignore minute details.
3. Form fixed boundaries.
4. Think with the perspective of the user.

Library Management System for NIC, India

1. Apply for Membership.

2. Access the system.
3. Issue of books.
4. Search.
5. Catalog.
6. Entry for the new books.
7. Procurement of the books.
8. Return of books.
9. Distributed functionality.
10. Availability of the books.
11. Outstanding.
12. Fine calculation.

1. Taking care of books.

2. Managing library transactions like issue return etc.
3. Maintaining member details.
4. Procuring books from suppliers.
5. Managing suppliers.

There are two types of Abstraction.

1. Entity Abstraction – Important entities involved in the domain. Book,
Member and Supplier are entity classes.
2. Action Abstraction – Important actions involved in the domain. Library
Transaction and Procurement are action class.

Encapsulation –
Hiding implementation details from clients.

Write a program to accept the radius of a circle and display the area and the
perimeter?

There are two types of Programming.

1. Algorithmic.
2. Framework oriented (collection of classes).

Algorithmic
Main() {
float radius, area, peri;
cin >> radius;
area = 3.14 * radius * radius;
peri = 2 *3.14 * radius;
cout << area << peri;
}

Framework oriented programming – designing a framework (collection of

classes) and using the framework to cater to an implementation. When the
requirements change, either use the existing framework or add value to the
framework to cater to that implementation.

Class Circle {
private:
Float radius;
public:
Circle() {
radius = 0;
}
Void setRadius(float r) {
radius = r;
}
float getArea() {
return 3.14 * radius * radius;
}
float getPeri() {
return 2 * 3.14 * radius;
}
};

void main() {
Circle c1;
Float r;
Cin >> r;
C1.setRadius(r );
Cout << c1.getArea() << c1.getPeri();
}

write a program to accept 2 heights in ft and inches and display their sum in
cm?

Class Height {
Private:
Int ft,inch;
Public:
Void setHeight(int f,int I) {
ft = f;
inch = I;
}
 float getCm() {
return (2.54 * (ft*12+inch));
}

Height add(Height h) {
Height temp;
Temp.ft = ft + h.ft;
Temp.inch = inch + h.inch;
If(temp.inch >=12) {
temp.ft++;
temp.inch-=12;
}
Return temp;
}
float getX() {
}
};

void main() {
Height h1;
Height h2,h3,h4;
H1.setHeight(5,8);
H2.setHeight(5,9);
H3.setHeight(5,7);
H4 = h1.add(h2.add(h3));
Cout << h3.getX();
}

Guidelines for designing a domain class

1. The Class name should be generic in nature.
2. Data members are linked to the lifetime of an object. Derived
attributes can be kept keeping the non-functional requirements into
consideration.
3. A class is independent of environment.
4. User interface is not part of the class design.
5. Class provides services.
6. A class is designed not keeping the number of instances in mind.
7. Object oriented programming is programming in terms of objects. (not
only in bits).

Modularity – A system is decomposed into subsystems and is connected to

external subsystems.

Concept – packages and subsystems.

Implementation unit of a subsystem is a component.

Day 2
Class Relationships

Objects communicate because classes are related to each other.

1. Person and bike – rides -> association.

2. Car and wheel – has -> aggregation.
3. Car and vehicle – is a -> inheritance or generalization.

1. Aggregation – Lifetime relationship.

Class Car {
Wheel w[4];
};

2. Association – Selfish relationship.

Class Person {
Void ride(Bike b1) {
b1.start();
b1.changeGear();
b1.accelerate();
}
};

Guidelines for identifying relationships between classes

1. Class relationships are based on lifetime, domain and customer
perception.
2. Entity -> Entity, association, aggregation or inheritance.
3. Action -> Entity, association.
4. Action -> Action, association or generalization.
5. Entity -> Action, no relationship.
6. In inheritance hierarchy, a sentence has to be formed.

Polymorphism - is associated at behavior level/ method level.

Checkin, move, etc.

Interface – A communication protocol between a component and a client.

Client accesses the component via an interface. Interface is a set of rules. It
is not an implementation. The class implements the rules of the interface.

Binding –
1. Static binding.

Main() {
x();
}
x() {
}
2. Dynamic binding – runtime polymorphism. The ability to find the
component at runtime.

Requirements
1) Process
a) Requirements.
b) Analysis.
c) Design.
2) UML.
3) Together Control Center Case Tool.

Requirement workflow activities

1. Identify the key system behaviors (Use Cases) and actors
surrounding it in a Use Case Model (Use Case Diagram).
2. Capture the vocabulary of the domain in a Glossary Document.
3. Capture the non-functional requirements in a Supplementary
specification document.
4. Detail a use case in a use case specification document and an
activity diagram for that use case.

Use Case –
• An important behavior of an application domain.
• Ex: withdraw is a use case in a banking domain.
• A use case has a beginning, a set of activities and a concrete
end to it.
• The system which we are developing is not a use case, it will
have use cases.
• Use cases can have sub flows and alternate flows.

Use cases for Course Registration System.

1. Register for a course.
2. View Report Card.
3. Signup to Teach course.
4. Record Grades.
5. Close Registration.
6. Accessing the system.
7. Maintain student information.
8. Maintain professor information.

Actors –
• An external factor affecting (initiate/ participate) the use case.
• An actor is identified by a role.
• An actor is not a specific instance.
• An actor can be a machine provided it is performing a role.
• An actor cannot be a commodity.
• An actor can be an external system or external software.
• An actor can be an imaginary role.
Stereotype – an extension to an existing model element.

UML provides notation to a Model element

Film actor – model element

Comedian – stereotype of Actor

Questions.

A. How many use cases does a use case diagram can have.
B. Can we 40 use case, how to handle it.
C. Can we have more than one use case diagrams.
D. When do we say that we are done with use case modeling.

Answers.

• 7±2 use cases can be there per diagram.

•

Processing an order – use case.

Vendor – actor.

Basic flow.

• Enquiry.
• Tech. Evaluation.
• Arrange for resources.
• Training.
• Feedback is collected.
• Cheque is collected.

When the sub-flows of a use case become complex, and starts having its own
sub-flows, or new actors start emerging from each sub-flow, then the use
case is upgraded to a use case package and its sub-flows become use cases.

Analysis

Architect Designer
Architectural Analysis Use Case Analysis

Architectural Analysis Activities

1. Define the high-level organization of the subsystems.
2. Identify Analysis Mechanisms.
3. Identify Key Abstractions.
4. Analyze the Use Case Realizations.

Patterns are of four types.

 1. Analysis Patterns.
2. Architectural Patterns.
3. Architectural Mechanisms.
4. Design Patterns.

Analysis Patterns – Business patterns.

Architectural Patterns – to define the high-level organization of the

subsystems.

Architectural Mechanisms – technology is associated to a project.

Design Patterns – creating, organizing and maintaining frameworks (class

libraries).

There are three types of Architectural Mechanisms

• Analysis Mechanisms (Conceptual).
• Design Mechanisms (concrete).
• Implementation Mechanisms (Actual).

Implementation Mechanisms

Dbase, foxpro, oracle, sybase, ingres, db2, progress, informix, sql server,
object store.

Design Mechanisms – DBMS, RDBMS, OODBMS.

Analysis Mechanism – Persistence.

Implementation Mechanisms –

C++ com, atl com, mfc com, java com, vb com, visibroker, mico, arbacus, hp
orbix, java 1.2 from sun, visual age.

Design Mechanisms – COM, CORBA, RMI, SOM.

Analysis Mechanism – Distribution.

Analysis Classes
• Conceptual classes, they need not be implemented.
• They are converted into design elements.
• There are three types of analysis classes.
• Boundary Class.
• Entity class.
• Control class.

Boundary class –
• An interface between an actor and a use case and vice versa.
• Registration Form is the boundary class between student and Register for
a course.
• Course Catalog System interface is the boundary class between a Register
for a course and Course Catalog.
• A boundary class can be
• User interface.
• System interface.
• Device driver interface.
• One boundary class between an actor-use case pair.

Entity Class –
• Key abstractions.
• Student, course offering are entity classes.

Control Class –
• Use case behavior coordinator.
• One control class per use case.
• Registration Controller is the control class for Register for a course.

Guidelines for a sequence diagram

a) In sequence diagram, we will have objects.
b) We can have more than one object, belonging to the same class.
c) Starts with an Actor.
d) Next a boundary object, with whom the actor interacts.
e) Next a control object
f) Next other entity and boundary objects.

For each Analysis class.

• Describe Responsibilities.
• Define attributes.
• Define associations.

Adding value to a class diagram.

• Role
• Cardinality
• Keys
• Notes etc

Role – the responsibility of the class in that association.

Cardinality – instance feeling.

Use Cases of Payroll System.

i) Record Time Card Information.
ii) Generate Paycheck.
iii) Change Employee Preference or Enter Payment method.
iv) Record Purchase Order.
v) Create Employee Report.
 vi) Maintain Employee Information.
vii) Run Administrative Reports.
viii) Access the system.

Design

Architect Designer
Identify the design elements Use Case Design
Identify design mechanisms Subsystem design
Describe the runtime architecture of Class design
the system
Describe the distribution

Identify design elements.

Design elements are design class, interface, package and subsystem.

Identify Design Elements Activities

1. Identify design classes.
2. Group design classes into packages.
3. Identify subsystem interfaces and subsystems.
4. Update the organization of the design model.

Guidelines for Converting Analysis Classes to Design Elements.

Boundary Class –
• User Interface –
• If implemented as a class, it will have many classes.
• If not implemented as a class, then we will be using an IDE like
pb, visual age, delphi, d2k, html/JavaScript etc.
• System interface or a device driver interface, it will remain as an
interface.

Entity Class –
• If the entity class is simple and provides a single logical abstraction, it
remains as a class.
• If it is complex, it is broken down into simpler classes leading to
aggregation and inheritance.
• If we can group them, we do it in a package.
• If the package provides a uniform goal, it becomes a subsystem.

Control Class –
• If the control class is simple, then other related simple control classes can
be grouped in a single control class, where earlier ones become methods.
(Note – sub flows became use cases).
• If the control class is too complex, we break into simpler control classes,
leading to inheritance (Note - use cases were merged).

Group design classes into packages.

Criteria.

• Architectural Pattern.
At the Application Subsystem level, We can further sub-packaging based on
actors.
At the business specific layer, We can further sub-packaging, like.
• Key Abstractions.
• Use Cases packages
• Use case.

Day 5

Together Control Center Features. Modeling.

Use Case Diagram

Concept Notation
Use Case
Actor
Unidirectional Association
Association
Generalization
System Boundary
Notes
Anchor to Notes

Stereotypes in association.
1. Includes.
2. Extends.

Class Diagram
Concept Notation
Class
Interface
Package
Class by pattern
Link by pattern
Association
Generalization
Dependency
Aggregation
Composition
Realization
Navigability
Sequence Diagram
Concept Notation
Object
Actor Instance
Message
Message with delivery time
Conditions
Reflexive message

State Transition Diagram

• Dynamic Behavior of an object across domain.
• Portrays different states of an object throughout the lifetime.
• We should use State Transition Diagram for effective communication.
• Helpful for identify use cases and methods.

Activity diagram
The activity diagram will have activities, states of objects etc. using which, it
explains the entire flow.

Subsystems
• A part of the main system or connected to the main system.
• There are two types of subsystems.
• Internal subsystem (Candidate subsystem).
• External Subsystem.

External subsystems –
Requirements – Actor (External).
Analysis – Boundary class (System interface).
Design – subsystem interface and we will design an external subsystem,
which will implement the subsystem interface.

Subsystem – a package with a behavior.

Package – a collection of classes.

Package serves many purposes.

Subsystem is a package, where one class implements an interface and other
classes support him. Generally, the class which implements the interface is
having accessibility public, rest are private.

Implementation unit of a subsystem is a component , which is visible via dll,

com exe, beans, corba,and rmi components.

Identify Design Mechanisms Activities

1. Categorize the clients of analysis mechanisms.
2. Document the mechanisms via package, class and sequence
diagrams.
The Criteria in identifying the processes for a system is
1. Architectural Pattern.
2. High level package diagram.

-END-