SAD/APPENDIX_B 2
Learning Objectives Understand the basic
characteristics and objectives of the object-oriented approach to software development
Identify the component elements of object-oriented software design
SAD/APPENDIX_B 3
Learning Objectives Understand the Unified Modeling
Language (UML) and its relationship to object-oriented design
Explore the various diagrams and their applications contained within the UML
SAD/APPENDIX_B 4
Introduction Object-oriented approach to
software development Views the system as a collection of
self-contained modules, or objects, that carry with them both the processes necessary to execute their intended role and the data necessary for that execution
SAD/APPENDIX_B 5
The Concepts of Object-Orientation
Object Any person, place, thing, or event
about which we wish to store data or capture its behavior
Attributes Current state Behavior Unique Identifier (UID)
SAD/APPENDIX_B 8
The Concepts of Object-Orientation
Object Encapsulation
Object encapsulates both data and implementation
The user can view the object as a black box
Modularity Information Hiding
SAD/APPENDIX_B 9
The Concepts of Object-Orientation
Class Blueprint or prototype that defines
the variables and the methods common to all objects of a certain kind
Generalized description for objects that are similar in nature or share many of the same characteristics
SAD/APPENDIX_B 14
The Concepts of Object-Orientation
Hierarchical Inheritance Each subclass inherits state and
methods from the superclass Subclass can add variables and
methods to the ones they inherit from the superclass
SAD/APPENDIX_B 16
The Concepts of Object-Orientation
Messages Objects interact and communicate
with each other by sending messages Additional information can be passed
along with the message (parameter)
SAD/APPENDIX_B 18
The Concepts of Object-Orientation
Polymorphism A message to one object could invoke
different behavior than the same message to a different object
The requesting object does not need any information with regard to how that behavior is accomplished
SAD/APPENDIX_B 19
Unified Modeling Language Within a system-intensive process, a
method is applied as a process to derive or evolve a system.
As a language, it is used for communication. That is, a means to capture knowledge (semantics) about a subject and express knowledge (syntax) regarding the subject for the purpose of communication. The subject is the system under discussion.
SAD/APPENDIX_B 20
Unified Modeling Language As a modeling language, it focuses on
understanding a subject via the formulation of a model of the subject (and its related context). The model embodies knowledge regarding the subject, and the appropriate application of this knowledge constitutes intelligence.
Regarding unification, it unifies the information systems and technology industry’s best engineering practices across types of systems (software and non-software), domains (business versus software), and life-cycle processes.
SAD/APPENDIX_B 21
Unified Modeling Language As it applies to specifying
systems, it can be used to communicate "what" is required of a system, and "how" a system may be realized.
As it applies to visualizing systems, it can be used to visually depict a system before it is realized.
SAD/APPENDIX_B 22
Unified Modeling Language As it applies to constructing
systems, it can be used to guide the realization of a system similar to a "blueprint".
As it applies to documenting systems, it can be used for capturing knowledge about a system throughout its life-cycle.
SAD/APPENDIX_B 23
Unified Modeling Language UML is NOT
A visual programming language, but a visual modeling language
A tool or repository specification, but a modeling language specification
A process, but it enables processes
SAD/APPENDIX_B 24
UML Diagram Diagram Description Diagram Application Typical SDLC Phase
Use Case
Depicts the interactions between external end users and the system.
Used to describe the system requirements.
Entire SDLC
Class
Displays the system in its static form at the class level.
Used to illustrate the class relationships for a particular use case.
Logical Analysis Logical/Physical Design
Object
Displays the system in its static form at the object level.
Used to illustrate the object relationships for a particular use case.
Logical Analysis Logical/Physical Design
Sequence
Depicts the interaction between classes within a particular use case. Diagram is arranged in temporal sequence.
Models the behavior of the various classes for a particular use case.
Logical Analysis Logical/Physical Design
Collaboration
Depicts the interaction between classes within a particular use case. Diagram is not arranged in temporal sequence.
Models the behavior of the various classes for a particular use case.
Logical Analysis Logical/Physical Design
Table B-2. Diagramming Tools Contained Within the Unified Modeling Language
SAD/APPENDIX_B 25
UML Diagram Diagram Description Diagram Application Typical SDLC Phase
Statechart
Depicts the various sequence of states that a particular object can assume, the events that can cause transition from one state to another, and the actions that can occur as a result of a state change.
Focuses on the behavior of a single class for a particular use case.
Logical Analysis Logical/Physical Design
Activity
Depicts a specific business process and provides a view of the flows inside a use case or among several classes.
Provides a graphical representation of the flow of activities for a particular use case.
Logical Analysis Logical/Physical Design
Component
Displays the physical components (files) in a software application along with their location.
Used to depict the physical structure of a given software application.
Physical Design Implementation
Deployment
Depicts the structure of the entire run-time system by identifying how the various code modules are distributed across platforms.
Used to illustrate the associations between the code modules in a software application and the hardware components necessary to support them.
Physical Design Implementation
Table B-2. Diagramming Tools Contained Within the Unified Modeling Language
SAD/APPENDIX_B 26
The Use Case Model Use case diagram is the central
building block of the UML Provide high level description of
what the system must do
SAD/APPENDIX_B 27
The Use Case Model Actor
Any person, organization, or computer system, external to the system but interacting with it
Represent a role that an end user can play
Use cases Represent a sequence of steps, either
manual or automated, that define the completion of a single business task
SAD/APPENDIX_B 28
The Use Case Model Actors are illustrated as stick figures, use
cases as ovals, association as a solid line with no directionality, and the system as a box surrounding the use case diagram
Use case can use another use case. They are connected using a hollow arrowhead contains the word uses or extends, surrounded by pointers, << >>.
SAD/APPENDIX_B 30
Class Diagram Provide a static structure of all the
classes that exist within the system
Three perspectives in drawing and interpreting class diagrams Conceptual perspective Specification perspective Implementation perspective
SAD/APPENDIX_B 33
Statechart Diagram Describe a single object that can
have different states during its lifetime
Show how the object reacts from one state to another in response to a given event
SAD/APPENDIX_B 34
State - Displayed as a round-cornered
rectangle. - Contains a label identifying the state
object.
Initial State - Displayed as a solid circle. - Used to represent the moment at which
an object begins to exist.
Final State - Displayed as a solid circle within a
larger unfilled circle (much like a bull’s eye).
- Used to represent the moment at which an object activity is complete.
State Transition - Displayed as an arrow from the first
state to the second state. - Label indicates the event which triggers
the transition from one state to another. - State change can occur due to a
condition becoming true, the passage of a specified length of time, or receipt of a message from another object.
Active
Table B-4. Component Elements of a Statechart Diagram
SAD/APPENDIX_B 36
Activity Diagram Focus on the flow of operations
driven by internal processing as opposed to external events
Does not make explicit which object executes which activities or in what way the messaging works between them
SAD/APPENDIX_B 38
Interaction Diagram Describe how objects within a set
of objects interact with each other Describe how a group of objects
collaborate in some behavior – typically a single use-case
Sequence Diagram Collaboration Diagram
SAD/APPENDIX_B 40
Implementation Diagram Component Diagram
Illustrate the physical nature of the system in terms of actual components
Show the dependencies among the software components
SAD/APPENDIX_B 41
Implementation Diagram Deployment Diagram
Show the configuration of runtime processing elements and the software components, processes, and objects that live on them
Represent how the hardware and software units are configured and deployed
SAD/APPENDIX_B 44
Advantages of the Object-oriented Approach
Advantages Based on very intuitive set of
concepts High modularity Code re-use
SAD/APPENDIX_B 45
Disadvantages of the Object-oriented Approach
Disadvantages Perception of inefficiency (single
processor)
- End -
SAD/APPENDIX_B 46
Summary The object-oriented approach is a new
and highly promising method that may one day become the standard for designing and development complex software system.
You should make every effort to pursue your exploration of the topic and plan on becoming skillful in its application.