OOAD, UML and RUP - Glarimy

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]

http://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


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


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


G l a r i m y

Corporate Trainings


G l a r i m y

BangaloreChennaiMysore

Hyderabad

Agenda• Session 1




G l a r i m y


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


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


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


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


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


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


Inheritance• Deals with hierarchical complexity

– Reuses an existing class and extends it further– Specializes the general class

• It’s a relation of specialization between parent and child

• It’s 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 parent’s 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


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


Analysis & Design• Understand the big picture

– Don’t 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

• They are candidate objects or attributes or relations– Identify all verbs

• They are candidate behavior interfaces (operations)– Develop classes

• Bind the attributes & behavior to appropriate objects• Establish the relations among the objects• Do not introduce any classes that are not part of the problem statement• Remove the classes that are outside of the boundary

G l a r i m y


Agenda• Session 1




G l a r i m y


OOAD

, UML

2.0 &

RUP

Unified Modeling Language• UML

– A visual modeling language• Offers syntax and semantics

– Roots are in software development• Applicable to any field

– Not a process• Used as part of a process

• Bit of History– Object Orientation and Three Amigos

• Booch – Booch Methodology• Rumbaugh – Object Modeling Technology• Jacobson – Objectory

– Unified• 1994: Started in 1994 with Rational• 1997: UML 1.0 adoption by Object Management Group (OMG)• 2005: UML 2.0• www.omg.org

G l a r i m y


http://www.ong.org/

UML 2.0• The Specification

– Diagram Interchange Specs• For Tool Vendors• For importing and exporting diagrams across tools• XML representation of elements & their interconnections of a diagram

– Infrastructure• Foundation for Superstructure• Meta model of UML

– Superstructure• The UML that we use

– Object Constraint Language• To Define constrains and expressions for elements

• The Philosophy– Model Driven Architecture

• Model as an abstraction over programming language • To facilitate auto code generation

G l a r i m y


UML Artifacts• Classifiers

– Artifacts that share common properties in UML• Classes, objects, methods, activities and etc.,

• Adornments– What you add on top of classifiers

• Constraints and Stereotypes and etc.,

• Diagrams– Models the system using the artifacts & Adornments

• Structural & Behavioral Diagrams

• Profiles– Means to extend the UML

• Collection of domain specific adornments

• Notes– Anything that you want to add to improve the clarity

G l a r i m y


Views & Diagrams• Classic 4+1 System Views

– Not part of UML– Design Views

• Classes, Patterns and etc– Deployment Views

• Configuration, Installation and etc., – Implementation Views

• Components, Resources, Files and etc., – Process Views

• Concurrency, Performance and etc., – And Use Case View

• Overall what is seen by the users

• UML 2.0 Diagrams– Structural

• Class Diagrams, Object Diagrams• Composite Structure Diagrams, Package Diagrams, Component Diagrams• Deployment Diagrams

– Behavioral• Use Case Diagrams, Activity Diagrams• State Machine Diagrams, Sequence Diagrams, Communication Diagrams• Time Diagrams, Interaction Overview Diagrams

G l a r i m y


Use Case Analysis• Use Case Analysis

– An approach to requirement analysis• Customer & Analyst participate• Comes out with User Stories and Use Case Diagrams

– Identifies system boundaries• Finalizes the requirement scope

– Focus is on “what needs to be delivered” • Not concerned about “How the functionality will be achieved”

• Deliverables– Use Cases

• Feature of the system from external point of view• Helps in putting together a requirements traceability matrix

– Use case Diagrams• Helps in putting together the requirements specifications

G l a r i m y


Use Case Diagrams• Use Case Diagrams

– One of the UML 2.0 Behavioral Diagram• Collection of Use Cases, Actors and Subject

• Subject– Whose functionality is being analyzed

• Typically of a process/subsystem/component/class and etc• Actor

– Uses the use case or receives the use case results• External to the subject, not part of it• May not map to real users, but to their roles• Can inherit other actors

• Use Case– A feature of the system from the external user point of view

• Must be initiated by an actor• Can <<extend>>/<<include>> other use cases

– When it is completed• Desired functionality must have been performed• Or an error has been thrown• Use can be repeated

G l a r i m y


Use Case DiagramsG l a r i m y


Activity Diagrams• Activity Diagrams

– Model activities of a classifier• Classifier can be a class, use case, component

– Activities are made up of actions connected with edges– Rectangle with rounded corners with a name

• Actions– Data manipulation/processing unit of activity diagram– Classifier provides the context– Accesses attributes and relations of the classifier.– Rectangle with rounded corner – Can have pseudo code within them

• Constraints– <<precondition>>– <<postcondition>>– Notes also can be supplied

G l a r i m y


Activity Diagrams• Tokens

– Data output from an action to another action– Data input to an action from other action

• Input parameter sets– Provides input parameters to whole activity diagram

• Control Flows– No tokens flows from an action to other action; Simple edges

• Object flows– Tokens flows from one action to another action– {weight=N}

• N instances of ip token are required to start the activity• N instances of op tokens are required to start the next activity

• Stereotypes– <<selection>>– <<transformation>>– <<multicast>>– <<multireceive>>

G l a r i m y


Activity Diagrams• Parameter nodes

– Simple input and output• Object nodes

– Complex data– Input Pin– Output Pin– Exception pin - with triangle– Value pins - with const value written at the pin

• Initial node - starts the activity• Final node - ends the activity• Decision & Merge nodes

– Selects (only) one flow– Guard condition resolves to Boolean value– Non intrusive data as <<decissionInput>>– Merge join several flows into one flow

• Fork & Join nodes– Fork creates several concurrent flows – Join joins concurrent flows into one flow– Join specification

G l a r i m y


Activity Diagrams• Connectors

– Splits diagram into smaller pieces• Activity partitions

– Activity Ownership• Swim lanes to separate the ownership • Underlined class names on the activity

– Exception handling activities• With lightening edges

• Other nodes– Stream Nodes

• Output can be delivered while input is still being received– Data store Nodes

• Represents data stores• Loops

G l a r i m y


Activity DiagramsG l a r i m y


Class DiagramsG l a r i m y


• Class diagrams– Invariably, most popular static UML diagram– Presents classes and their relations, statically

• Class– Three compartments: name, attributes, operations:

• Attributes– Primitive types (Inline attributes)– References (Relationships)

• Inline attribute– visibility /name :type multiplicity default {property strings &

constraints}• visibility: +, -, #, ~• multiplicity: [lower...upper], [5], [1..5], [*], nothing is one.

• Derived Attributes– Prepend with /– Computed based on other parts of the class, typically read-only



• Attribute Constraints– Natural language– OCL

• {[name]:expression}• {ordered} • {unique}

• Collections– Order Set- OU– Sequence: O– Set: U– Bag:

• Static Attributes– underline

Class Diagrams• Operations

– To specify how to invoke behavior– op:= visibility name (params): return-type {properties}

• params:= direction param: type [multiplicity] = default {properties}

– direction := in, out, inout, return– properties:= {precondition:<>|postcondition:<>}

– Query operations: doesn't change the state– Body conditions: can be replaced by subclass– Exceptions– Static: underline

• Method is an implementation of operation• Operations without implementation are abstract

G l a r i m y


Class Diagrams• Relations

– Dependency: weekest, uses, dashed line– Association: has-a, solid line, navigation (right, cross symbols), name

that will not get into code, multiplicity (shared)– Aggregation: owns-a, solid line with empty diamond on owner, name,

multiplicity, navigability (shared with others)– Composition: is-part-of, not shared, all others, filled-diamond on owner

• Association class– Named association as a class– Linked classes know each other through it– Dashed line from the association link to the association class.

• Association qualifier– Like membership-id in the relation between member & club.

• Generalization– is-a, – Triangle on parent– Abstract classes are realized

• dashed inheritance

G l a r i m y


Class Diagrams• Abstract Class

– Class name is in italics– Some operations are abstract– Can't be instantiated

• Interface– pure abstract– Need not to have operations

• Templates– Dashed rectangle on top-right corner of template class– Comma separated element types in the dashed rect

• To specify types

G l a r i m y


Package Diagrams• Packages

– Grouping elements– Packages themselves can be packaged

• Visibility– Element names with + are public to the package– Element names with – are private to the package– Imported elements are public in importing package

<<import>>– Accessed elements are private in importing package

<<access>>

G l a r i m y


Package DiagramsG l a r i m y


Component Diagrams• Component

– Is a sub-system– Internals are hidden– Shows "provided interfaces“– Shows functionality– Shows "required interfaces“– Shows what is required from the user

• Component Diagrams– Rectangle– <<component>> or component icon on top-right corner

• Black-box– Three compartments:

• <<component>> name, • <<provided interface>> and <<required interfaces>>• <<artifacts>>

• White-box– Shows component structure

G l a r i m y


Component DiagramsG l a r i m y


Deployment Diagrams• Deployment Diagrams

– Maps software pieces (artifacts) to hardware (nodes)– Nodes communicate with each other along the communication paths

• Artifact– Rectangle with dog-ear paper on top-right, name in the center– Can have properties/operations (configuration)– Instance is underlined artifact– Manifests (implements) other component

• Nodes– Hardware or containers

• Execution Environment– Software container node like Browser– Stereotypes to be provided by profile developers like <<OS>>, <<RDBMS>> etc– May have a comportment showing the <<services>>– <<Device>> are hardware, can be nested– Communication Paths are undirected solid lines between nodes, what passes

(PDU) is not specified.– Deployment is associating nodes with artifacts– <<Deployment specs>> define properties to specify how the deployment should

happen like web.xml.

G l a r i m y


Deployment DiagramsG l a r i m y


Sequence Diagrams• Sequence Diagrams

– Lifelines– Participants– <<create>>, <<destroy>>, local variables, <<self>>, filled arrows– Message:= attribute=signal/opName(args):return value

• Creation & Deletion– Object creation using arrowed dashed line with <<create>>– Object deletion using <<destroy>>

• Messages– Asynchronous message as open arrow– Return values using arrowed dashed line– Found message from unknown sender using filled circle– Lost message to unknown destination using filled circle

• Execution occurrences– Rectangles on the lifeline– Shows object as busy

G l a r i m y


Sequence Diagrams• Interaction Fragments

– Parts in the sequence diagram of special interest– Fragments are shown as combined fragment with interaction

operator• Interaction Operators

– alt ernative: [guard] and [else]– opt: [guard]– break: [guard] then {...., return}– par allel– critical region– loop

• Decomposition– Replace lifelines with REF <other diagram>

• Continuations– Placeholders in sequence diagram to put your own

implementation

G l a r i m y


Sequence DiagramsG l a r i m y


State Chart Diagrams• State chart Diagrams

– State changes of a class/component – Note on the class/component to link to its state chart diagram

• States– Is a moment in the behavior of classifier– can represent static (waiting) or dynamic (doing) situation

• State Representation– Rectangle with rounded corners with

• Name• Internal activities• Internal transitions

• Transition– Transition:= event {att list} [guard]/transition– Upon entering state becomes active– Upon leaving it becomes inactive

• Types– Simple– Composite– Submachine states

G l a r i m y


State Chart DiagramsG l a r i m y


Leave Process SystemOrganization x wants to automate its leave process. All the employees are eligible for paid leaves and

the number depends on their designation. Each employee have to request the manager for leave

except the CEO for whom there is no manager. The request should have details like start date and end

date, number of days, reason for leave and contact number on leave. The manager can accept or

reject the leave. However, the immediate manager can grant leave only if the sufficient leave balance is

available for the employee. Otherwise, the manager will have to escalate it to his/her mamanger. That

means, negative leave balance is allowed but can not be granted by the immediate manager. No

leaves would be carried forward to the next year.

This application should be a web based application and all the employees must be authenticated. The

employee data base is already available which have the details like name, employee id, designation,

employee id of the immediate manager, maximum leaves per year, leaves utilized and etc., Employees

must be able to raise the leave request, view the status of the request, update the request and cancel

the request. The manager must be able to view the leave record of all his/her team members, view the

leave requests pending, cancel/accept/escalate a the request and view the leave history of an

employee. Reports can also be provided.

G l a r i m y


Leave Process SystemG l a r i m y


Agenda• Session 1




G l a r i m y


OOAD

, UML

2.0 &

RUP

Rational Unified Process• What is RUP

• A software engineering process• A process product from Rational (now IBM)• A way to enhance team productivity• A way to replace paper documentation with models• A guideline to effectively using UML• A configurable process• A repository of best practices

• The 6 Best Practices• Develop software iteratively• Manage requirements• Use component-based architecture• Visually model software• Verify software quality• Control changes to software

G l a r i m y


Rational Unified Process• Phases

• Inception, Elaboration, Construction, Transition• The 2-D Process View

G l a r i m y


RUP: Inception Phase– A vision document

– A general vision of the core requirements– Key features– Main constraints

– A initial use-case model– 10% -20% complete

– An initial project glossary– An initial business case

– Business context– Success criteria– Financial forecast.

– An initial risk assessment– A project plan

– Phases and iterations– One or several prototypes– Milestone: Lifecycle Objective

G l a r i m y


RUP: Elaboration– A use-case model

– Around 80% complete– Actors for all use cases– Description for most of the use cases

– Supplementary requirements– Non functional requirements– Other requirements

– Not associated with a specific use case– A Software Architecture Description– An executable architectural prototype– A revised risk list and a revised business case– A development plan for the overall project

– Coarse-grained project plan– Iterations with evaluation criteria

– Milestone: Lifecycle Architecture

G l a r i m y


RUP: Construction & Transition– Construction

– The software product integrated on the adequate platforms– The user manuals– A description of the current release.– Milestone: Initial Operational Capability

– Transition– Beta testing

– Validate the new system against user expectations– Parallel operation with a legacy system

– Pilot run– Conversion of operational databases– Training of users and maintainers– Roll-out the product

– To the marketing– To the distribution– To the sales teams

– Milestone: Product Release

G l a r i m y


Final WordsOOAD

A way to comprehend the systemA way to design an automated solution

UMLA way to communicate the system or

solution

RUPA process to effectively use the UML

G l a r i m y



G l a r i m yG l a r i m y


For Technical [email protected]

FAQ, Tutorials, Presentations, Samples, Quiz

http://www.glarimy.com

For Appointments091-9731 4231 66

Thank Youwww.glarimy.com

mailto:[email protected]

http://www.glarimy.com/

OOAD, UML and RUP - Glarimy

Documents

Transcript of OOAD, UML and RUP - Glarimy