1. Object-Oriented Analysis and Design
Appendix B
Object-Oriented Analysis and Design

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

6. Figure B-1. Objects, Attributes, Methods, and Instances
SAD/APPENDIX_B

7. Figure B-2. Software Object Representation of a Bicycle
SAD/APPENDIX_B

8. The Concepts of Object-Orientation
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

10. Figure B-3. Blueprint Concept of a Software Object
SAD/APPENDIX_B

11. Figure B-4. Example of Object Class Implementations
SAD/APPENDIX_B

12. Figure B-5. Instance Objects Created From BICYCLE Class
SAD/APPENDIX_B

13. Figure B-6. Example of Instance Derived From Object Class
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

15. Figure B-7. Hierarchical Inheritance – Superclass and Subclasses
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

17. Figure B-8. Example of Object Messaging
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. Table B-2. Diagramming Tools Contained Within the Unified Modeling Language
SAD/APPENDIX_B

25. 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 Use cases
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

29. Figure B-9. Simple Use Case Diagram
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

31. Table B-3. Class Diagram Components
SAD/APPENDIX_B

32. Figure B-10. Example Class Diagram for a Contact Maintenance System
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. Table B-4. Component Elements of a Statechart Diagram
SAD/APPENDIX_B

35. Figure B-12. Statechart Diagram for a Bank Account
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

37. Figure B-13. Activity Diagram for Order Process
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

39. Figure B-15. Collaboration Form of Interaction 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

42. Figure B-16. Example of a Simple Component Implementation Diagram
SAD/APPENDIX_B

43. Figure B-17. Deployment Implementation Diagram
SAD/APPENDIX_B

44. Advantages of the Object-oriented Approach
Based on very intuitive set of concepts
High modularity
Code re-use
SAD/APPENDIX_B

45. Disadvantages of the Object-oriented Approach
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.
SAD/APPENDIX_B

47. Appendix B
End of Chapter