CIS 210 - Systems Analysis and Development Week 10
Slide #
Topic
Narration
1
Intro
Welcome to Systems Analysis and Development. In this week’s lesson, we are going to be discussing object-oriented analysis and design.
Please go to slide #2
2
Objectives
Upon completion of this lesson you will be able to:
Understand and be able to explain the concepts related to Object Oriented Analysis and Design,
Understand and be able to explain the concepts related to the concepts and principles underlying the Object Oriented approach,
Understand and be able to explain the concepts related to activities in different phases of the object oriented development life cycle,
Understand and be able to explain the concepts related to object modeling using use case diagrams, and
Understand and be able to explain the concepts related to modeling real-world applications using UML diagrams.
Please go to slide #3
3
Overview
In this lesson, we will be discussing the object-oriented approach to systems analysis and design. Object oriented design is becoming increasingly popular because of its ability to thoroughly represent complex relationships, as well as to represent data and data processing with a consistent notation.
An object-oriented model is built around objects. An object encapsulates both data and behavior, implying that analysts can use the object oriented approach for both data modeling and process modeling. The object oriented approach provides a powerful environment for developing complex systems.
Please go to slide #4
4
The Object-Oriented
Life Cycle
The object-oriented development life cycle consists of progressively developing an object representation through the following phases:
Analysis,
Design, and
Implementation.
In the analysis phase, a model of the real-world application is developed that shows its important properties. The model abstracts concepts from the application domain and describes what the intended system must do. The model specifies the functional behavior of the system.
In the object oriented design phase, you define how the application-oriented analysis model will be realized in the implementation environment. Jacobson cited the following three reasons for using object-oriented design:
The analysis model is not formal enough to be implemented directly into a programming language,
The actual system must be adapted to the environment in which the system will actually be implemented, and
The analysis results can be validated using object-oriented design.
To develop the design model, you must identify and investigate the consequences that the implementation environment will have on the design. After all strategic decisions are made, you incorporate those decisions into a first-cut design model that adapts to the implementation environment. Finally, you formalize the design model to describe how the objects interact with each other.
The design phase is followed by the implementation phase. In this phase, you implement the design using a programming language and/or a database management system. Translating the design into program code is a relatively straightforward process, given that the model already incorporates the nuances of the programming language or the DBMS.
As with structured modeling techniques, the deliverables from project activities using object oriented modeling are diagrams and repository descriptions, which provide full specification of the information system.
Please go to slide #5
The Unified Modeling Language, or UML, is a language for specifying, visualizing, and constructing the artifacts of software systems, as well as for business modeling. The UML notation is useful for graphically depicting object-oriented analysis and design models.
To represent a complex system effectively, the model you develop should have a small set of independent views or perspectives. The UML allows you to represent multiple views of a system using a variety of graphical diagrams such as use case, class, state, sequence, and collaboration diagrams. The underlying model integrates those views so that the system can be analyzed, designed, and implemented in a complete and consistent fashion.
Please go to slide #6
6
Dynamic Modeling
In UML, state transitions are shown using state diagrams. A state diagram depicts the various state transitions or changes an object can experience during its lifetime, along with the events that cause those transitions.
A state is a condition during the life of an object when it satisfies some condition. The state changes when the object receives some event; the object is said to undergo a state transition. The state of an object depends on its attribute values and links to other objects.
An event is something that takes place at a certain point in time. It is a noteworthy occurrence that triggers a state transition. An object remains in a particular state for some time before transitioning to another state.
Not all attributes are important in determining the state of an object. In determining the state of an object, only those objects that affect its gross behaviors are considered to be important.
The other thing to note is that the state of an object does not change whenever an attribute changes its values.
In UML, a state is shown as a rectangle with rounded corners. A state diagram shows how the object transitions from an initial state to another state when certain events occur or when certain conditions are satisfied.
A transition is shown as a solid arrow from the source state to the target state and is labeled with the name of the event. A transition may be labeled with a string consisting of the event name, parameters of the event, guard condition, and action expression. A transition only shows those elements that are relevant to the transition.
We can expand a state or an event to show more details. In a nested state diagram, sub-states are nested within a general state.
An activity is an operation that is performed when an object is in a certain state. An ongoing activity is labeled by the keyword “do” followed by the forward slash sign. It could be a continuous operation or it could be a sequential operation.
To develop a dynamic model for an application, you need to combine all the state diagrams that you have drawn for different object classes. In such a model, the interactions among the component state diagrams are shown via shared events.
Please go to slide #7
7
Dynamic Modeling
In UML, an interaction diagram is used to show the pattern of interactions among objects for a particular use case. There are two types of interaction diagrams: sequence diagrams and collaboration diagrams. Sequence diagrams show the explicit sequencing of messages; collaboration diagrams show the relationships among objects.
A sequence diagram depicts the interactions among objects during a certain period of time. Each sequence diagram shows only the interactions pertinent to a specific use case. It shows the participating objects by their lifelines and the interactions among those objects.
A sequence diagram may be presented either in a generic form or in an instance form. The generic form shows all possible sequences of interactions. The instance form shows the sequence for only one scenario.
The following are some important terms to understand when discussing a sequence diagram in instance form:
Activation is the time period during which an object performs an operation.
A synchronous message is 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.
A simple message is a message that transfers control from the sender to the recipient without describing the details of the communication.
And an asynchronous message is a message in which the sender does not have to wait for the recipient to handle the message.
Please go to slide #8
8
Dynamic Modeling
An activity diagram shows the conditional logic for the sequence of the system activities needed to accomplish a business process. An individual activity may be manual or automated and often represents the actions needed to move an object between states. Further, each activity is the responsibility of a particular organizational unit. Thus, an activity diagram is another view or model of a system that combines aspects of both sequence and state diagrams and is similar to a data flow diagram from the structured methodology.
An activity diagram clearly shows parallel and alternative behaviors. It provides a good way to document work or flows through an organization. However, objects are obscured and the links between objects are not shown. An activity diagram can be used to show the logic of a use case.
Please go to slide #9
9
Analysis vs. Design
You might wonder which diagrams belong to the analysis phase, and which diagrams belong to the design phase. The answer is that, in general, the same types of diagrams may apply to different phases. However, as you move from analysis to design, you need to refine the diagrams based on the requirements of the implementation environment. During design, you need to consider technical details relating to the target hardware and database management system, and refine models that you developed earlier.
All of the diagrams you have seen thus far are useful for analyzing a system. When you move to design, you start with the existing set of analysis models and keep adding technical details. During design, you would also refine the other analysis models.
In addition to the types of diagrams we have discussed so far, there are two other types of diagrams—component diagrams and deployment diagrams.
A component diagram shows the software components or modules and their dependencies. A deployment diagram shows how the software components, processes, and objects are deployed into the physical architecture of the system.
Please go to slide #10
10
Summary
We have now reached the end of this lesson. Let’s take a look at the material we have just covered:
The object oriented analysis and design process,
