OOAD, UML 2 & RUPKrishna Mohan Koyya, M.Tech, DBM, PMP
Technology Consultant & Corporate TrainerGlarimy Technology Services, Bangalore, India
[email protected] | www.glarimy.com091-9731 4231 66
2009, Glarimy. All rights reserved. http://www.glarimy.com
G l a r i m y
mailto:[email protected]://www.glarimy.com/
Agenda Session 1
Fundamentals of Object Orientation Object Oriented Analysis Object Oriented Design
Session 2 Use Case Analysis Introduction to UML Use Case Diagrams Activity Diagrams Class Diagrams Package Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams State Chart Diagrams
Session 3 Rational Unified Process
G l a r i m y
2009, Glarimy. All rights reserved.
OOAD
, UML
2.0 &
RUP
Call me Krishna Originally from Tadepalligudem in
Andhra Pradesh Have been in Bengaluru since 1998
Held various positions in the IT Industry Worked on development of huge
systems Extensive work in the areas of
Object Orientation Distributed Systems Network Management Systems Java Technologies
Krishna Mohan Koyya
2009, Glarimy. All rights reserved.
G l a r i m y
Graduation B.E. in Electronics & Communication Engineering
SRKR Engineering College, Bhimavaram, affiliated to Andhra University, Visakhapatnam
1989-1993 Post Graduation
M.Tech in Computer Science & Technology College of Engineering, Andhra University, Visakhapatnam 1995-1997
Certifications PMP (Project Management Professional)
PMI USA 2005 (Now expired!)
Others Diploma in Business Management (Finance)
ICFAI, Hyderabad 2007
Academics
2009, Glarimy. All rights reserved.
G l a r i m y
A total of 14 years of experience with the IT Industry Since July 2008
Technology Consultant & Corporate Trainer Runs G l a r i m y, online skill development portal
June 2007- May 2008 Associate Professor & HOD of Department of IT Sasi Institute of Technology and Engineering, Tadepalligudem, India
Jan 2006 Dec 2006 Chief Executive Officer Sudhari IT Solutions India Private Limited, Bangalore, India
Dec 2000 Jan 2006 Software Engineer at Grade 10 Cisco Systems India Private Limited, Bangalore, India
Nov 1998 Dec 2000 Senior Software Engineer Wipro Technologies, Bangalore, India
Others Dhanya Software for Hewlett-Packard ISO, Bangalore, India in 1998 Ace Software Exports Limited, Rajkot, India in 1997 Neo Software, Visakhapatnam in 1994-1995
Career
2009, Glarimy. All rights reserved.
G l a r i m y
Corporate Trainings
2009, Glarimy. All rights reserved.
G l a r i m y
BangaloreChennaiMysore
Hyderabad
Agenda Session 1
Fundamentals of Object Orientation Object Oriented Analysis Object Oriented Design
Session 2 Use Case Analysis Introduction to UML Use Case Diagrams Activity Diagrams Class Diagrams Package Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams State Chart Diagrams
Session 3 Rational Unified Process
G l a r i m y
2009, Glarimy. All rights reserved.
OOAD
, UML
2.0 &
RUP
Object Orientation Software
Set of Programs Program is a set of instructions that can be executed by a computer
Code, Documentation, Configuration Software sans any of the above becomes less useful
Automates existing business process It [typically] never creates anything new for a business process
Model Abstracts a thing or a process or an idea
Presents only relevant detail, Leaves extra details Always have a context and a purpose
No two models may be exactly same
Object Orientation Models existing business processes
In terms of objects and their interdependencies
G l a r i m y
2009, Glarimy. All rights reserved.
Abstraction & Encapsulation Abstraction
One of the fundamental principles of Object Orientation Presents only required detail about an object A means to deal with the complexity
Encapsulation Wraps the object internals
Users look only at the utility Presents abstraction
Outsiders can deal with whole rather than parts Creation, destruction, usage - in terms of whole Objects become reusable
Controls access to the internals Protects the internal details of the object
Security, by default Provides interface for controlled access
Public members for every one Private members for no one (except for the object itself)
G l a r i m y
2009, Glarimy. All rights reserved.
Classes Blue Prints
Describes the structure & behavior of objects How an object can be created? What and how an object does something? Who are related to this object? What is visible & accessible to whom?
Do not do anything They are not runtime elements Only objects do, not the blue prints
Three Parts Attributes & Relationships
Attributes describe the static internal picture Relationships describe dependencies among objects
Behavior Describes the dynamic picture
Class Level Data Specific to the given class Data is available even before object is created Shared among all object of the class
G l a r i m y
2009, Glarimy. All rights reserved.
Objects Represent real world objects/ideas
An object oriented system is just a collection of objects Runtime elements in the system
Represent tangibles as well as intangibles Things, Processes, concepts
Instances of classes Each object belongs to a class
All class level data is available to each of the objects
A class can be realized into any number of objects Object level data
Specific to the given instance of the class Not shared among objects Data is available only with the specific object
G l a r i m y
2009, Glarimy. All rights reserved.
Attributes & Relations Attributes
Characteristics Describes the inherent structure
Granular Generally very granular in nature May not be described using other structures
Inseparable Every object should have a value for the attribute An object sans the defined attribute is not possible
Relations Among objects
Cardinality: One-to-One, One-to-Many, Many-to-One, Many-to-Many Role: Each object has a purpose Navigation: At least one of them knows the other
Types of Relations Dependency uses relation, weakest Association has a relation Aggregation owns a relation Composition is part of relation, strongest
Relation itself can be a class
G l a r i m y
2009, Glarimy. All rights reserved.
Behavior State
Snapshot of set of values of attributes & relations Changes if any of these values change Only object changes states, not class
Behavior The way an object changes its state
Class changing state is meaningless
Operation Interface to invoke the behavior State better not be changed directly accessing it
Method An implementation of an operation An operation can be carried in more than one methods - Overloading
Message A means to invoke operation on (another) object
Objects passing messages in a system delivers the functionality
G l a r i m y
2009, Glarimy. All rights reserved.
Inheritance Deals with hierarchical complexity
Reuses an existing class and extends it further Specializes the general class
Its a relation of specialization between parent and child
Its an IS-A relation Every child class IS-A a parent class, in a way
Vice-versa is not true Also not true between two child classes of the same parent
Parent Classes & Child Classes Child inherits everything from the parent
Parent can stop one/some/all of its members being inherited All protected members are meant only for the self & children
Child can override parents behavior Parent can stop one/some/all of its methods being overridden
Child can extend the parent By adding its own attributes/associations/behavior Parent can stop being extended, of course
Multiple Inheritance A child extends more than one parent
G l a r i m y
2009, Glarimy. All rights reserved.
Interfaces & Polymorphism Classic distinction
What & How What deals with requirement How deals with implementation
Classes, Objects and Interfaces Class specifies both what & how Object exhibits that specification Interface specifies only what, not how.
Interface can not do anything, its abstract A class needs to realize this interface by providing how specs More than one class can realize the same interface Each class provides different how to the same what
Polymorphism Users deals with interfaces rather than actual objects
Actual object may belong to any of the class implementations One Interface, many possible implementations
Actual behavior depends on the real implementation that is provided The behavior is not known till the implementation is known Different implementations are supplied at different contexts
G l a r i m y
2009, Glarimy. All rights reserved.
Analysis & Design Understand the big picture
Dont look for trees, find the forest Identify the scope and boundaries of the system
Generate User Stories Ask how user wants to use the system Ask what user expects from the system Develop Use Cases
Identify the external actors and triggers Identify the expected outcomes Identify the exceptional scenarios.
Model the existing business process Identify all nouns
