1 / 47

Appendix B

Appendix B. Object-Oriented Analysis and Design. 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. Learning Objectives.

blake
Download Presentation

Appendix B

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 • 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

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

  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 • 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 • 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. SAD/APPENDIX_B

  47. Appendix B End of Chapter

More Related