© 2005 by prentice hall appendix 3 object-oriented analysis and design modern systems analysis and...
TRANSCRIPT
© 2005 by Prentice Hall© 2005 by Prentice Hall
Appendix 3Object-Oriented Analysis and
Design
Modern Systems Analysisand Design
Fourth Edition
Jeffrey A. Hoffer Joey F. George
Joseph S. Valacich
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-2
Learning ObjectivesDefine events, state transitions, and
sequence diagrams.Describe concepts and principles of object-
orientation.Describe activities of the different phases of
object-oriented development.Compare object-oriented modeling with
traditional systems development approaches.Develop dynamic models with state,
interaction, and activity diagrams.Model real-world applications with UML.
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-3
The Object-Oriented 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
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-4
Object oriented cycle is like an onion, evolving from abstract to detailed, from external qualities to system architecture and algorithms.
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-5
Object-Oriented Deliverables and Outcomes
1. The ability to tackle more challenging problem domains
2. Improved communication among users, analysts, designers, and programmers
3. Increased consistency among analysis, design, and programming activities
4. Explicit representation of commonality among system components
5. Robust systems6. Reusability of analysis, design, and programming
results7. Increased consistency among the models developed
during object-oriented analysis, design, and programming
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-6
The Unified Modeling Language (UML)
A notation that allows the modeler to specify, visualize, and construct the artifacts of software systems, as well as business modelsTechniques and notations:
Use cases Class diagrams State diagrams Sequence diagrams Activity diagrams
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-7
Use Cases Revisited
A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users
Full functioning for a specific business purpose
See Chapter 7
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-8
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-9
Class Diagrams Revisited
Features: Objects and classes Encapsulation of attributes and operations Polymorphism Inheritance Aggregation and composition
See Chapter 9
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-10
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-11
Dynamic Modeling
Representation of activities that occur throughout the lifetime of a systemTypes of UML dynamic models State diagram: state changes within an
object Sequence diagram: time-sequenced
interactions between objects Activity diagram: flow of control between
activities within an object
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-12
State DiagramsState
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 cornersState Transition
The changes in the attribute of an object or in the links an object has with other objects
Shown as a solid arrow Diagrammed with a guard condition and actionEvent
Something that takes place at a certain point in time, triggering a state transition
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-13
State diagram: a model of the states of a single object and the events that cause the object to change from one state to another
Guard condition
Guard condition
Action
A transition is labeled with a guard condition and/or an action, separated with a forward slash /
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-14
Diagramming Substates and Decomposing States
A state can be expanded into substates using nested state diagrams, similar to expansion of processes in different levels of DFDs.
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-15
Diagramming Substates and Decomposing States
An event can be expanded into using nested state diagrams, and may involve substates and subtransitions and events.
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-16
Dynamic Modeling:Sequence Diagrams
A depiction of the interaction among objects during certain periods of timeElements of a sequence diagram
Objects: represented by boxes at top of diagram Lifeline: the time during which an object exists Activation: the time period during which an
object performs an operation Messages: means by which objects
communicate with each other
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-17
Types of Messages in Sequence Diagrams
Synchronous message The caller must wait for the receiving object to
finish executing the called operation before it can resume execution itself
Asynchronous message The caller can resume execution right after
sending the message, without waiting for the receiver to complete
Simple message A message that transfers control from the sender
to the recipient without describing the details of the communication
20.1720.17
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-18
time
lifeline
activation
message
object
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-19
Process Modeling:Activity Diagrams
Shows the conditional logic for the sequence of system activities needed to accomplish a business process
Clearly shows parallel and alternative behaviors
Can be used to show the logic of a use case
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-20
Elements of Activity DiagramsActivity: a behavior that an object carries out while in a particular stateTransition: a movement from one activity or state to anotherBranch: a diamond symbol containing a condition whose results provide transitions to different paths of activities Synchronization bar: horizontal or vertical bars denoting parallel or concurrent paths of activities
Fork: the beginning of parallel activities Join: the end of parallel activities
Swimlanes: columns representing different organizatonal units of the system
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-21
swimlane
activity
branch
synchronization bar
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-22
Analysis Versus DesignStart with existing set of analysis modelProgressively add technical detailsDesign model must be more detailed than analysis modelComponent Diagram A diagram that shows the software components or
modules and their dependencies
Deployment Diagram A diagram that shows how the software
components, process and objects are deployed into the physical architecture of the system
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-23
© 2005 by Prentice Hall© 2005 by Prentice HallAppendix 3-24
SummaryIn this chapter you learned how to: Define events, state transitions, and sequence
diagrams. Describe concepts and principles of object-
orientation. Describe activities of the different phases of object-
oriented development. Compare object-oriented modeling with traditional
systems development approaches. Develop dynamic models with state, interaction, and
activity diagrams. Model real-world applications with UML.