Date post: | 19-Jan-2017 |
Category: |
Engineering |
Upload: | mikel-raj |
View: | 385 times |
Download: | 14 times |
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