Object Orientation

Object orientation basics

      Object orientation is mainly used for two purpose i) maintainability ii) Reusability. 
 
Abstraction
	Finding the common properties/ taking the essential things in collections of objects 
      in common pool.

      (Need for abstraction: when we create a object no chance to create a wrong object. i.e., no 
      properties should left out. It is used for maintainability.)

Encapsulation
            Putting together the data members and the functions works on those data members
      is called Encapsulation. It gives supports for information hiding property

      (Need for Encapsulation:  when we change the data member no need to run-through all the lines 
      of code in the program to change. It is used for maintainability.)
	
Information hiding
	Hiding how the data members are executed.(Private data members). 

      (Need for information hiding:  It is used for maintainability to hide details from its clients
      and keep things simple. This property leads for reusability.)
 
Inheritance
	Inherit properties form its parent class.

      (Need for Inheritance: It used for reusability)
	
Polymorphism
	The ability to hide many different implementations behind a single interface.
      (Need for Inheritance: It used for reusability)

Aggregation
 	Building a class from common properties of group of classes.
     (Need for Inheritance: It used for reusability)

OOAD

OOAD OVERVIEW

OBJECT ORIENTED ANALYSIS AND DESIGN OVERVIEW
============================================

1 Requirements Overview (Role : Designer / Architect)
------------------------------------------------------

* Review usecase diagrams, specifications and supplementary specifications

2 Architectural Analysis (Role : Architect)
--------------------------------------------

* Identify architectural layers
* Identify architectural mechanisms
* Provide modelling conventions and design guidelines
* Identify key abstractions from the problem statement (and any other documents provided by the stakeholders)

3 Usecase Analysis (Role : Analyst / Designer)
-----------------------------------------------

For each use case sequence
* Identify classes
* Classify them as boundary, control and entity classes
* Include them in appropriate packages(and subsystems)
* Draw a sequence diagram
* Draw a class diagram 

4 Identify Design Elements and Mechanisms (Role : Architect)
-------------------------------------------------------------

* Identify packages
* Identify subsystems and their interfaces, based on
* services
* reuse oppurtunities
* closely held collaboration
* optional features
* change frequency
* Position the packages and subsystems in appropriate layers
* Identify patterns for design mechanisms

5 Process View (Role : Architect)
---------------------------------

* Decide on processes and threads based on concurrency requirements
* Draw a process diagram indicating process relationships
* Draw a diagram to indicate process - design elements mapping

6 Deployment View (Role : Architect)
------------------------------------

* Draw a deployment diagram
* Indicate processes that are deployed in each processor

7. Usecase Design (Role : Designer)
-----------------------------------

* Refine the sequence and class diagrams by incorporating new subsystems
- incorporate subsystems in terms of theiir interfaces
- Incorporate patterns for architectural  mechanisms
* Refine flow of events description
* Encapsulate frequently occuring sub-flows
* Refine package / subsystem dependencies

8. Subsystem Design (Role : Designer)
-------------------------------------

For each interface operation
* Draw a sequence diagram
* Draw a class diagram (or, one class diagram for the subsystem)
* Reuse existing classes, packages and subsystems (as much as possible)
* Refine subsystem and package dependencies

9. Class Design (Role : Designer)
---------------------------------

* Incorporate environment classes and provide appropriate relations
* Define atrributes and their data types
* Define operations
- paramters and their types
- return type
- methods 
* Draw state charts for a few classes
- states captured as enumerated data typee
- events and actions captured as operatioons
* Refine relations
- avoid multiple inheritance
- decide on dependency vs association (onn a case-to-case basis)
- decide on generalization vs aggregationn (or composition)
- avoid shared aggregations
- resolve many to many as well as zero too zero
- check where metamorphosis is needed andd design for it
- delegate changes

Additional Resources
--------------------

a. www.rational.com
b. www.rational.net
c. www.therationaledge.com
d. www.jroundup.com
e. www.rationalrose.com

 UML
MENU | HOME