OOAD UNIT I UML DIAGRAMS

1

Object-Oriented Analysis and Design(OOAD)

By

Mikel Raj.K.T

2

Learning ObjectivesKey terms

AssociationClass diagramEventObjectObject classOperationSequence diagramStateState transitionUnified Modeling Language (UML)Use case

A.2

3

The Object-Oriented Modeling Approach

• Benefits1.The ability to tackle more challenging problem

domains2.Improved communication among users,

analysts, designers, and programmers3.Reusability of analysis, design, and

programming results4.Increased consistency among the models

developed during object-oriented analysis, design, and programming

A.3

4

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

10A.10

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

14A.14

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

16A.16

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

19A.19

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

22A.22

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

25A.25

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

27A.27

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

30

Unified Process

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.01998

Rational Objectory Process 4.11996-1997

Objectory Process 1.0-3.81987-1995Ericsson 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 ProcesslPhase is Business context of a step

Workflow is Technical

context of a step

38

The Phases/Workflows Of Unified Process

l NOTE: Most of the

requirements work or

workflow is done in the inception phase.

l However some is done

later.

39

The Phases/Workflows Of Unified Process

l NOTE: Most of the

implementation work or workflow is

done in construction

l 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.

41

Agile Process

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 performedIn 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

its local environment, the work schedule)

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

design

coding

test

refactoring

user stories values

acceptance test criteriaiteration plan

simple design CRC cards

spike solutions prototypes

pair programming

unit test continuous integration

acceptance testing

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– Emphasizes “learning”

57

Three Phases of ASD adaptive cycle planning uses mission statement project constraints basic requirements time-boxed release plan

Requirements gathering J AD mini-specs

components implemented/ tested focus groups for feedback formal technical reviews postmortems

software incrementadjustments 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

61

Process Assessment

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

Analysisand

Reporting

Closure

65

Initiation (stage 1)

Define theinputs

• 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

Sanctionthe

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)

AnalyseFindings

DisseminateFindings

IdentifyAction 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-AssessmentReview

• 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.

69

UML Diagrams

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(collaberation)

• 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

74

Class diagram

75

Class diagram

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.

77

Component diagram

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.

79

Deployment diagram

80

Deployment diagram

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.

82

Object diagram

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.

84

Package diagram

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 diagramUML 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).

87

Activity diagram

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.

89

State diagram

90

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.

93

Use cases diagram

94

Use cases diagram

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.

96

Communication diagram

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.

98

Sequence diagram

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.

100

Timing diagram

101

Timing diagram

102

Interaction overview diagramInteraction 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

104

UML Diagram Hierarchy

105

References

• http://www.agilemodeling.com/• http://www.visual-paradigm.com/VPGallery/

diagrams/index.html• http://bdn.borland.com/article/

0,1410,31863,00.html• http://en.wikipedia.org/wiki/

Unified_Modeling_Language• http://pigseye.kennesaw.edu/~dbraun/csis4650/

A&D/UML_tutorial/index.htm

106

Thank u