1. Business System Development
CSC581

2. Lecture 28 Object-Oriented Analysis and Design

3. Summary of the previous lecture
In previous lecture, we :
Discussed management skills required for success as a systems analyst.
Discussed interpersonal skills required for success as a systems analyst.
Described the systems analysis profession

4. Outlines We today’s lecture we will:
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

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

6. Object oriented cycle is like an onion, evolving from abstract to detailed, from external qualities to system architecture and algorithms.

7. Object-Oriented Deliverables and Outcomes
The ability to tackle more challenging problem domains
Improved communication among users, analysts, designers, and programmers
Increased consistency among analysis, design, and programming activities
Explicit representation of commonality among system components
Robust systems
Reusability of analysis, design, and programming results
Increased consistency among the models developed during object-oriented analysis, design, and programming

8. 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 models
Techniques and notations:
Use cases
Class diagrams
State diagrams
Sequence diagrams
Activity diagrams

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

11. Class Diagrams Revisited
Features:
Objects and classes
Encapsulation of attributes and operations
Polymorphism
Inheritance
Aggregation and composition

13. Dynamic Modeling
Representation of activities that occur throughout the lifetime of a system
Types 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

14. State Diagrams State State Transition Event
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 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 action
Event
Something that takes place at a certain point in time, triggering a state transition

15. Guard condition
Action
Guard condition
A transition is labeled with a guard condition and/or an action, separated with a forward slash /
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

16. Diagramming Sub-states and Decomposing States
A state can be expanded into substates using nested state diagrams, similar to expansion of processes in different levels of DFDs.

17. Dynamic Modeling: Sequence Diagrams
A depiction of the interaction among objects during certain periods of time
Elements 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

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

19. object
time
lifeline
message
activation

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

21. Elements of Activity Diagrams
Activity: a behavior that an object carries out while in a particular state
Transition: a movement from one activity or state to another
Branch: 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

22. branch
activity
synchronization bar
swimlane

23. Analysis Versus 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, process and objects are deployed into the physical architecture of the system

25. Summary of today’s lecture
In this lecture we talked about :
Defined events, state transitions, and sequence diagrams.
Described concepts and principles of object-orientation.
Described activities of the different phases of object-oriented development.
Compared object-oriented modeling with traditional systems development approaches.
Developed dynamic models with state, interaction, and activity diagrams.
Modelled real-world applications with UML.

26. Overview of the next lecture
In next lecture, we will:
We will consider few more case studies and further explore/practice the concepts of system development which we have learnt in the previous lectures.

27. The End