OOAD UNIT I UML DIAGRAMS

1
Object-Oriented Analysis and Design
(OOAD)
By
Mikel Raj.K.T

2
Learning Objectives
Key terms
Association
Class diagram
Event
Object
Object class
Operation
Sequence diagram
State
State transition
Unified Modeling Language (UML)
Use case
A.2

3
The Object-Oriented Modeling
Approach
• Benefits
1.The ability to tackle more challenging problem
domains
2.Improved communication among users,
analysts, designers, and programmers
3.Reusability of analysis, design, and
programming results
4.Increased consistency among the models
developed during object-oriented analysis,
design, and programming
A.3

5
The Object-Oriented Modeling
Approach (continued)
• Object-Oriented Systems Development Life
Cycle
– Process of progressively developing
representation of a system component (or
object) through the phases of analysis,
design, and implementation
– The model is abstract in the early stages
– As the model evolves, it becomes more and
more detailed
A.5

6
The Object-Oriented Systems
Development Life Cycle
• Analysis Phase
– Model of the real-world application is developed
showing its important properties
– Model specifies the functional behavior of the
system independent of implementation details
• Design Phase
– Analysis model is refined and adapted to the
environment
• Implementation Phase
– Design is implemented using a programming
language or database management system
A.6

7
The Object-Oriented Systems Development Life Cycle
(continued)
• Unified Modeling Language (UML)
– A notation that allows the modeler to
specify, visualize and construct the artifacts
of software systems, as well as business
models
– Techniques and notations
• Use cases
• Class diagrams
• State diagrams
• Sequence diagrams
A.7

8
Use-Case Modeling
• Applied to analyze functional requirements of
the system
• Performed during the analysis phase to help
developers understand functional
requirements of the system without regard
for implementation details
• Use Case
– A complete sequence of related actions initiated
by an actor
• Actor
– An external entity that interacts with the system
A.8

9
Use-Case Modeling
• Use cases represent complete functionality
of the system
• Use cases may participate in relationships
with other use cases
• Use cases may also use other use cases
A.9

11
Object Modeling: Class Diagrams
• Object
– An entity that has a well-defined role in the
application domain, and has state, behavior,
and identity
• State
– A condition that encompasses an object’s
properties and the values those properties
have
• Behavior
– A manner that represents how an object acts
and reacts
• Object Class
– A set of objects that share a common
structure and a common behaviorA.11

12
Object Modeling:
Class Diagrams (continued)
• Class Diagram
– Class is represented as a rectangle with three
compartments
– Objects can participate in relationships with
objects of the same class
A.12

13
Object Modeling:
Object Diagrams
• Object Diagram
– A graph of instances that are compatible with a
given class diagram; also called an instance diagram
– Object is represented as a rectangle with two
compartments
• Operation
– A function or service that is provided by all the
instances of a class
• Encapsulation
– The technique of hiding the internal implementation
details of an object from its external view
A.13

15
Representing Associations
• Association
– A relationship between object classes
– Degree may be unary, binary, ternary or higher
– Depicted as a solid line between participating
classes
• Association Role
– The end of an association where it connects to a
class
– Each role has multiplicity, which indicates how
many objects participate in a given association
relationship
A.15

17
Representing Generalization
• Generalization
– Abstraction of common features among multiple
classes, as well as their relationships, into a more
general class
• Subclass
– A class that has been generalized
• Superclass
– A class that is composed of several generalized
subclasses
A.17

18
Representing Generalization (continued)
• Discriminator
– Shows which property of an object class is being
abstracted by a generalization relationship
• Inheritance
– A property that a subclass inherits the features
from its superclass
• Abstract Class
– A class that has no direct instances but whose
descendents may have direct instances
• Concrete Class
– A class that can have direct instances
A.18

20
Representing Aggregation
• Aggregation
– A part-of relationship between a component
object and an aggregate object
– Example: Personal computer
• Composed of CPU, Monitor, Keyboard, etc
A.20

21
Dynamic Modeling: State Diagrams
• State
– A condition during the life of an object during which it
satisfies some conditions, performs some actions or
waits for some events
– Shown as a rectangle with rounded corners
• State Transition
– The changes in the attributes of an object or in the
links an object has with other objects
– Shown as a solid arrow
– Diagrammed with a guard condition and action
• Event
– Something that takes place at a certain point in time
A.21

23
Dynamic Modeling:
Sequence Diagrams
• Sequence Diagram
– A depiction of the interaction among objects
during certain periods of time
• Activation
– The time period during which an object performs
an operation
• Messages
– Means by which objects communicate with each
other
A.23

24
Dynamic Modeling:
Sequence Diagrams (continued)
• Synchronous Message
– A type of message in which the caller has to wait
for the receiving object to finish executing the
called operation before it can resume execution
itself
• Simple Message
– A message that transfers control from the sender
to the recipient without describing the details of
the communication
A.24

26
Moving to Design
• Start with existing set of analysis model
• Progressively add technical details
• Design model must be more detailed than analysis model
• Component Diagram
– A diagram that shows the software
components or modules and their
dependencies
• Deployment Diagram
– A diagram that shows how the software
components, processes and objects are
deployed into the physical architecture of the
system
A.26

28
Summary
• Object-Oriented Modeling Approach
– Benefits
– Unified Modeling Language
• Use cases
• Class diagrams
• State diagrams
• Sequence diagrams
• Use Case Modeling
A.28

29
Summary (continued)
• Object Modeling: Class Diagrams
– Associations
– Generalizations
– Aggregation
• Dynamic Modeling: State Diagrams
• Dynamic Modeling: Sequence Diagrams
• Moving to Design
A.29

31
What is Process ???
• Defines who is doing, what and when to do it,
and how to reach a certain goal.
Software Engineering
Process
New or Changed
requirements
New or Changed
system

32
What is Unified Process ??
• Unified process (UP) is an architecture-centric, use-
case driven, iterative and incremental development
process that leverages unified modeling language and
is compliant with the system process engineering
metamodel.
• A popular iterative modern process model
(framework) derived from the work on the UML and
associated process.

33
Unified Process
• The leading object-oriented methodology for the
development of large-scale software
• Maps out when and how to use the various UML
techniques
• Develop high-risk elements in early iterations
• Deliver value to customer

34
Creating the Unified Process
Rational Unified Process 5.0
1998
Rational Objectory Process 4.1
1996-1997
Objectory Process 1.0-3.8
1987-1995
Ericsson Approach
Rational Approach
IBM Approach
Unified Process
1998
OO Approach

35
The Unified Process
• The Unified Process is an adaptable
methodology.
• The Unified Process is a modeling technique.
UML stands for unified modeling language.
• The object-oriented paradigm is iterative and
incremental in nature

36
Unified Process Phases
• Inception
– Establish the business case for the system, define risks,
obtain 10% of the requirements, estimate next phase effort.
• Elaboration
– Develop an understanding of the problem domain and the
system architecture, risk significant portions may be
coded/tested, 80% major requirements identified.
• Construction
– System design, programming and testing. Building the
remaining system in short iterations.
• Transition
– Starts when beta testing is completed, Deploy the system in
its operating environment. Deliver releases for feedback and
deployment

37
The Phases/Workflows Of Unified Process
qPhase is Business context of a step
Workflow is
Technical
context of a
step

38
q NOTE:
Most of the
requirements
work or
workflow is
done in the
inception
phase.
q However
some is done
later.

39
q NOTE:
Most of the
implementati
on work or
workflow is
done in
construction
q However
some is done
earlier and
some later.

40
Example roles in UP
• Stake Holder: customer, product manager, etc.
• Software Architect: established and maintains
architectural vision
• Process Engineer: leads definition and refinement
of Development Case
• Graphic Artist: assists in user interface design,
etc.

42
Agenda
• Manifesto for Agile Software Development
• What is Agility?
• Agile Teams
• Agility and the Cost of Change
• An Agile Process
• The principles of agile methods
• Human Factors
• Agile Process Models
• Agile Modeling
• Conclusion

43
Manifesto for Agile Software Development
• “We are uncovering better ways of developing software by doing it
and helping others do it.
• Agile values:
1. Individuals and interactions- in agile development, self organization &
motivation are important
2. Working software- working software will be more useful and welcome
than just presenting documents to clients in meetings
3. Customer collaboration-requirements cant be fully collected at the
beginning of the software development cycle, therefore continuous
customer involvement is important
4. Responding to change- agile development is focused on quick
responses to change and continuous development

44
Agility
• Effective response to change
• Effective communication among all
stakeholders
• Drawing the customer into the team.
• Organizing a team so that it is in control of the
work performed
In order to yield rapid, incremental delivery of
software

45
Agile Teams
• Responsive to changes during project
development
• Recognize that project plans must be flexible
• Eliminates the separation between customers
and developers

46
Agility and the Cost of Change
• Conventional wisdom is that the cost of
change increases nonlinearly as a project
progresses. It is relatively easy to
accommodate a change when a team is
gathering requirements early in a project.

47
Agility and the Cost of Change

48
An Agile Process
• Is driven by customer descriptions of what is required
(scenarios). Some assumptions:
– Recognizes that plans are short-lived (some requirements will
persist, some will change. Customer priorities will change)
– Develops software iteratively with a heavy emphasis on
construction activities (design and construction are
interleaved, hard to say how much design is necessary before
construction. Design models are proven as they are created. )
– Analysis, design, construction and testing are not predictable.
• Thus has to Adapt as changes occur due to unpredictability
• Delivers multiple ‘software increments’, deliver an operational
prototype or portion of an OS to collect customer feedback for
adaption.

49
Human Factors
• The process molds to the needs of the people and team, not the
other way around
• key traits must exist among the people on an agile team :
– Competence. ( talent, skills, knowledge)
– Common focus. ( deliver a working software increment )
– Collaboration. ( peers and stakeholders)
– Decision-making ability. ( freedom to control its own
destiny)
– Fuzzy problem-solving ability.(ambiguity and constant
changes, today problem may not be tomorrow’s problem)
– Mutual trust and respect.
– Self-organization. ( themselves for the work done, process for

50
Agile Process Models
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Agile Modeling (AM)

51
Extreme programming
• The most widely used agile process.
• Defines 4 framework activities
– Planning
– Design
– Coding
– Testing

52
Extreme programming
52
planning
planning
designdesign
coding
coding
testtest
refactoring
user stories
values
acceptance test criteria
iteration plan
simple design
CRC cards
spike solutions
prototypes
pair programming
unit test
continuous integration
acceptance testing
software increment
project velocity computed
software increment
project velocity computed
Release

53
Extreme programming
• XP Planning
– Begins with the creation of “user requirements”
– Agile team assesses it and assigns a
cost
– They are grouped to form a deliverable
increment
– A commitment is made on delivery date
– After the first increment “project velocity” is used
to help define subsequent delivery dates for other
increments

54
Extreme programming
• XP Design
–Follows the KIS principle
–For difficult design problems, suggests the
creation of “spike solutions”—a design
prototype
–Encourages “refactoring”—an iterative
refinement of the internal program design

55
Extreme programming
• XP Coding
–Recommends the construction of a unit test
for a store before coding commences.
–Encourages “pair programming”.
• XP Testing
–All unit tests are executed daily
–“Acceptance tests” are defined by the
customer and executed to assess customer
visible functionality

56
Adaptive Software Development (ASD)
• Self-organization arises when independent agents
cooperate to create a solution to a problem that is
beyond the capability of any individual agent
• Adaptive cycle characteristics
– Mission-driven planning
– Component-based focus
– Uses “time-boxing”
– Explicit consideration of risks
– Emphasizes collaboration for requirements
gathering

57
Three Phases of ASD
adapt ive cycle planning
uses mission st at ement
project const raint s
basic requirement s
t ime-boxed release plan
Requirement s gat hering
JAD
mini-specs
component s implement ed/ t est ed
focus groups for feedback
formal t echnical reviews
post mort ems
software increment
adjustments for subsequent cycles
Release

58
Three Phases of ASD
1. Speculation:
• Project is initiated and adaptive cycle planning
is conducted.
• Adaptive cycle planning uses project initiation
information.
• Based on the information obtained at the
completion of the first cycle, the plan is
reviewed and adjusted.

59
Three Phases of ASD
2. Collaborations
• Are used to multiply their talent and creative output
beyond absolute number (1+1>2).
• It encompasses communication and teamwork, but it
also emphasizes individualism.

60
Three Phases of ASD
3. Learning:
• As members of ASD team begin to develop the
components, the emphasis is on “learning”.
• Learning will help them to improve developers level
of real understanding.
• Three ways: focus groups, technical reviews and
project postmortems

62
What is Process Assessment
• An objective model-independent method to
assess the capability of an organization to meet
the process goals
• About collecting information
• A way to demonstrate program effectiveness

63
Assessment Method
• Assessment Stages
• Key Players
• Initiation
• Preparation
• Assessment
• Analysis and Reporting
• Closure

64
Assessment Stages
Initiation
Preparation
Assessment
Analysis
and
Reporting
Closure

65
Initiation (stage 1)
Define the
inputs
• identify the assessment purpose
• select the assessment model
• define goals for the assessment
• identify the business drivers
• identify constraints
• document assumptions
• identify additional information gathering requirements
• identify feedback and output requirements
• complete the assessment brief
Sanction
the
business case
• costs and benefits
• decision to proceed
Select the
Resources
OutputsOutputs
• assessment purpose
• constraints
• assessment goals
• confidentiality agreements
• quality measures to be collected

66
Assessment (stage 3)
Gather
Information
• conduct interviews
• study documentation
• document findings
• consolidate the findings
• rate the goals
• rate the process
• feedback initial conclusions
• determine the Organizational Unit’s Capability Level
Reach
Consensus
• on ALL ratings!
ConductConduct
• according assessment plan
• adapt plan for changes and feedback
• data collection by interview or document
• data review for process ratings
• assessors agree on ratings before submitting
them to the Lead Assessor
TypesTypes
• measurement only (no analysis)
• Findings & Recommendations
• Findings & Action Planning

67
Analysis & Reporting (stage 4)
Analyse
Findings
Disseminate
Findings
Identify
Action Plan
issue
Final Report
• Strengths & Weaknesses
• Gap Analysis
• Identify Improvement
Opportunities
• semi-formal interactive
feedback session
• prioritise improvements
according impact & effort
against business drivers
• Cost/benefit Analysis
• Schedule of improvement
roll-out
• management findings &
recommendations
• summary assessment process
& key players
• results compared with targets
• detailed process findings

68
Closure (stage 5)
Post-Assessment
Review
• results of the analysis of the participants feedback forms
• the assessments’ achievements against its goals
• the overall level of confidence in the assessments results
• any problems the assessors experienced during the assessment
including problems with the use of the method
• the successes achieved
• the techniques used during the assessment
• the organizational unit and the Sponsor's response to the results
• Lead Assessor ensures that the Assessment Conformance Checklist
is complete and signed-off.

70
What is UML?
• Standard language for specifying, visualizing,
constructing, and documenting the artifacts of
software systems, business modeling and other non-
software systems.
• The UML represents a collection of best engineering
practices that have proven successful in the
modeling of large and complex systems.

71
• The UML is a very important part of
developing object oriented software and the
software development process.
• The UML uses mostly graphical notations to
express the design of software projects.
• Using the UML helps project teams
communicate, explore potential designs, and
validate the architectural design of the
software.

72
Overview of UML Diagrams
Structural
: element of spec. irrespective of time
• Class
• Component
• Deployment
• Object
• Composite structure
• Package
Behavioral
: behavioral features of a system / business
process
• Activity
• State machine
• Use case
• Interaction
Interaction
: emphasize object interaction
• Communication(collaberati
on)
• Sequence
• Interaction overview
• Timing

73
Class diagram
UML class diagrams show the classes of the
system, their inter-relationships, and the
operations and attributes of the classes
 Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis
model
 Depict the detailed design of object-oriented or object-based
software

76
Component diagram
UML component diagrams shows the dependencies
among software components, including the classifiers
that specify them (for example implementation classes)
and the artifacts that implement them; such as source
code files, binary code files, executable files, scripts and
tables.

78
Deployment diagram
 UML deployment diagram depicts a static view of the run-
time configuration of hardware nodes and the software
components that run on those nodes. Deployment
diagrams show the hardware for your system, the software
that is installed on that hardware, and the middleware used
to connect the disparate machines to one another.

81
Object diagram
UML Object diagrams (instance diagrams), are useful
for exploring real world examples of objects and the
relationships between them. It shows instances instead
of classes. They are useful for explaining small pieces
with complicated relationships, especially recursive
relationships.

83
Package diagram
UML Package diagrams simplify complex class
diagrams, it can group classes into packages. A
package is a collection of logically related UML
elements. Packages are depicted as file folders and
can be used on any of the UML diagrams.

85
Composite structure diagram
UML Composite structure diagrams used to explore
run-time instances of interconnected instances
collaborating over communications links.
 It shows the internal structure (including parts and
connectors) of a structured classifier or
collaboration.

86
Activity diagram
UML Activity diagrams helps to describe the
flow of control of the target system.
 such as the exploring complex business rules
and operations, describing the use case also the
business process.
It is object-oriented equivalent of flow charts
and data-flow diagrams (DFDs).

88
State diagram
UML State diagrams can show the different
states of an entity also how an entity responds
to various events by changing from one state
to another.
The history of an entity can best be modeled
by a finite state diagram.

91
Use cases diagram
Use cases diagrams describes the behavior of the target
system from an external point of view. Use cases
describe "the meat" of the actual requirements.
Use cases: A use case describes a sequence of actions
that provide something of measurable value to an actor
and is drawn as a horizontal ellipse.

92
Use cases diagram (cont…)
 Actors: An actor is a person, organization, or external
system that plays a role in one or more interactions with
your system. Actors are drawn as stick figures.
 Associations: Associations between actors and use cases
are indicated by solid lines. An association exists whenever
an actor is involved with an interaction described by a use
case.

95
Communication diagram
Communication diagrams used to model the dynamic
behavior of the use case.
 When compare to Sequence Diagram, the
Communication Diagram is more focused on showing
the collaboration of objects rather than the time
sequence.

97
Sequence diagram
UML Sequence diagrams models the collaboration
of objects based on a time sequence.
 It shows how the objects interact with others in a
particular scenario of a use case.

99
Timing diagram
 Timing diagrams shows the behavior of the objects in
a given period of time.
 Timing diagram is a special form of a sequence
diagram.
 The differences between timing diagram and sequence
diagram are the axes are reversed so that the time are
increase from left to right and the lifelines are shown
in separate compartments arranged vertically.

102
Interaction overview diagram
Interaction overview diagrams focuses on the
overview of the flow of control of the
interactions.
It is a variant of the Activity Diagram where
the nodes are the interactions or interaction
occurrences.
It describes the interactions where messages
and lifelines are hidden.

103
Interaction overview diagram

105
References
• http://www.agilemodeling.com/
• http://www.visual-
paradigm.com/VPGallery/diagrams/index.html
• http://bdn.borland.com/article/0,1410,31863,00.ht
ml
• http://en.wikipedia.org/wiki/Unified_Modeling_Lang
uage
• http://pigseye.kennesaw.edu/~dbraun/csis4650/A&
D/UML_tutorial/index.htm

OOAD UNIT I UML DIAGRAMS

In this document