0
OBJECT ORIENTED ANALYSIS AND DESIGN August 04, 2010
Agenda <ul><li>Introduction to Object Orientation  </li></ul><ul><li>Introduction to  OOAD? </li></ul><ul><li>Various OOA ...
Introduction to Object Orientation <ul><li>Basic Principles of Object Orientation </li></ul><ul><li>Basic Concepts of Obje...
Basic Principles of Object Orientation Object Orientation Encapsulation Abstraction Hierarchy Modularity
What is Abstraction? Manages Complexity Salesperson Not saying  Which  salesperson – just a salesperson in general!!! Cust...
What is Encapsulation? <ul><li>Hide implementation from clients </li></ul><ul><ul><li>Clients depend on interface </li></u...
What is Modularity? <ul><li>The breaking up of something complex into manageable pieces </li></ul>Order Processing System ...
What is Hierarchy?  <ul><li>Levels of abstraction </li></ul>Asset RealEstate Savings BankAccount Checking Stock Security B...
Strengths of Object Orientation <ul><li>A single paradigm </li></ul><ul><li>Facilitates architectural and code reuse </li>...
Basic Concepts of Object Orientation <ul><li>Object </li></ul><ul><li>Class </li></ul><ul><li>Attribute </li></ul><ul><li>...
What is OOAD? <ul><li>Object-oriented analysis and design  (OOAD)  is a software engineering approach that models a system...
Definitions of OOA and OOD <ul><li>What is Object Oriented Analysis? </li></ul><ul><li>Object-oriented analysis (OOA) appl...
Object Oriented Analysis <ul><li>Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a c...
Analysis Techniques <ul><li>Ad-hoc </li></ul><ul><li>Noun lists </li></ul><ul><li>Use cases </li></ul>
Adhoc Analysis <ul><li>when the problem is too difficult for the &quot;analyst&quot; </li></ul><ul><li>Hard to do in colla...
Noun List Analysis <ul><li>Identify nouns, adjectives, verbs from e.g. requirements documents </li></ul><ul><ul><li>nouns ...
Use Case Analysis <ul><li>Start from requirements </li></ul><ul><li>Describe response of system to events </li></ul><ul><u...
The Booch Micro Cycle Identify classes and objects Identify classes and objects semantics Identify classes and objects rel...
Object Oriented Design <ul><li>OOD transforms the analysis model created using OOA into a design model that serves as a bl...
OOD <ul><li>The subsystem layer:  Representation of each of the subsystems that enable the software to achieve its custome...
OOA to OOD
OOA to OOD
Design Issues <ul><li>decomposability—the facility with which a design method helps the designer to decompose a large prob...
Process Flow for OOD
Unified Modeling Language
UML Diagram  –  What is UML? <ul><li>The Unified Modeling Language (UML) is a standard  language for  </li></ul>Visualizin...
Different Views Users Designers Analyzers
UML- Eight Diagrams and One Language  <ul><li>Use Case Diagram </li></ul><ul><li>Class Diagram/Object Diagram </li></ul><u...
Use case diagram Online C2C shopping <ul><li>overview the usage requirements </li></ul><ul><li>presentations project stake...
Class  Diagram Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation...
Relationships between Class Diagrams <ul><li>Association  -- a relationship between instances of the two classes. There is...
Activity  Diagram Activity diagrams describe the workflow behaviour of a system  Start Fork Branch Merge Joint End
State Machine Diagram <ul><li>A  State Machine diagram </li></ul><ul><li>shows the possible states of </li></ul><ul><li>th...
Sequence Diagram <ul><li>A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of meth...
Collaboration Diagram <ul><li>The collaboration diagram illustrates messages being sent between classes and objects (insta...
Component Diagram <ul><li>A  component diagram  in the Unified Modeling Language, depicts how components are wired togethe...
Deployment Diagram <ul><li>deployment diagram specifies a set of constructs that can be used to define the execution archi...
<ul><li>QUESTIONS </li></ul>
Upcoming SlideShare
Loading in...5
×

Ooad

11,689

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
11,689
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
487
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Before moving on, ask the students to name the four basic principles of OO (as a review).
  • Discuss what makes a good abstraction with the students: Concise, Represents a single coherent concept, etc.
  • Encapsulation is putting the “databits” and operations that manipulate them in the same place. Encapsulation DISALLOWS direct manipulation of things that have been encapsulated without utilising the supplied interface. Another example - the accelerator on a car. You put your foot down and car goes faster - this works on most cars, and you don’t worry about the cables, electronics, engine, etc.
  • Modularity supports separation of concerns. Another example of modularity is a car, which is made up of a body, chassis, engine, wheels, etc.
  • Hierarchy is not an organizational chart. Hierarchy is not a functional decomposition. Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize similarities and differences. For example, in botany, plants are organized into families, chemistry uses a periodic table to organize the elements. Another example -- telephone number, then a 0800 (free call) number, premium rate number, etc
  • Review the 4 basic principles of OO (abstraction, encapsulation, modularity, and hierarchy) and why they are good. Ask the students to name the OO concepts (e.g., class, package, interface, etc.) that support those principles. Emphasize that OO facilitates the following best practices: Develop Iteratively Model Visually Use Component Architecture
  • Transcript of "Ooad"

    1. 1. OBJECT ORIENTED ANALYSIS AND DESIGN August 04, 2010
    2. 2. Agenda <ul><li>Introduction to Object Orientation </li></ul><ul><li>Introduction to OOAD? </li></ul><ul><li>Various OOA techniques </li></ul><ul><li>Various OOD techniques </li></ul><ul><li>Flow of OOA to OOD </li></ul><ul><li>Introduction to UML </li></ul><ul><li>Various Diagrams in UML </li></ul>
    3. 3. Introduction to Object Orientation <ul><li>Basic Principles of Object Orientation </li></ul><ul><li>Basic Concepts of Object Orientation </li></ul><ul><li>Strengths of Object Orientation </li></ul>
    4. 4. Basic Principles of Object Orientation Object Orientation Encapsulation Abstraction Hierarchy Modularity
    5. 5. What is Abstraction? Manages Complexity Salesperson Not saying Which salesperson – just a salesperson in general!!! Customer Product
    6. 6. What is Encapsulation? <ul><li>Hide implementation from clients </li></ul><ul><ul><li>Clients depend on interface </li></ul></ul>Improves Resiliency How does an object encapsulate? What does it encapsulate?
    7. 7. What is Modularity? <ul><li>The breaking up of something complex into manageable pieces </li></ul>Order Processing System Billing Order Entry Order Fulfillment Manages Complexity
    8. 8. What is Hierarchy? <ul><li>Levels of abstraction </li></ul>Asset RealEstate Savings BankAccount Checking Stock Security Bond Elements at the same level of the hierarchy should be at the same level of abstraction Decreasing abstraction Increasing abstraction
    9. 9. Strengths of Object Orientation <ul><li>A single paradigm </li></ul><ul><li>Facilitates architectural and code reuse </li></ul><ul><li>Models more closely reflect the real world </li></ul><ul><ul><li>More accurately describe corporate data and processes </li></ul></ul><ul><ul><li>Decomposed based on natural partitioning </li></ul></ul><ul><ul><li>Easier to understand and maintain </li></ul></ul><ul><li>Stability </li></ul><ul><ul><li>A small change in requirements does not mean massive changes in the system under development </li></ul></ul>
    10. 10. Basic Concepts of Object Orientation <ul><li>Object </li></ul><ul><li>Class </li></ul><ul><li>Attribute </li></ul><ul><li>Operation </li></ul><ul><li>Interface (Polymorphism) </li></ul><ul><li>Component </li></ul><ul><li>Package </li></ul><ul><li>Subsystem </li></ul><ul><li>Relationships </li></ul>
    11. 11. What is OOAD? <ul><li>Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects . </li></ul><ul><li>Analysis — understanding, finding and describing concepts in the problem domain. </li></ul><ul><li>Design — understanding and defining software solution/objects that represent the analysis concepts and will eventually be implemented in code. </li></ul><ul><li>OOAD — Analysis is object-oriented and design is object-oriented. A software development approach that emphasizes a logical solution based on objects. </li></ul>
    12. 12. Definitions of OOA and OOD <ul><li>What is Object Oriented Analysis? </li></ul><ul><li>Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. </li></ul><ul><li>What is Object Oriented Design? </li></ul><ul><li>Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. </li></ul><ul><li>OOA focuses on what the system does, OOD on how the system does it. </li></ul>
    13. 13. Object Oriented Analysis <ul><li>Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. </li></ul><ul><li>Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built </li></ul><ul><li>The sources for the analysis can be a written requirements statement, a formal vision document, interviews with stakeholders or other interested parties. </li></ul>
    14. 14. Analysis Techniques <ul><li>Ad-hoc </li></ul><ul><li>Noun lists </li></ul><ul><li>Use cases </li></ul>
    15. 15. Adhoc Analysis <ul><li>when the problem is too difficult for the &quot;analyst&quot; </li></ul><ul><li>Hard to do in collaboration Analysis on-the-fly while implementing </li></ul><ul><ul><li>Simple problems </li></ul></ul><ul><ul><li>Objects, methods and behaviour obvious </li></ul></ul><ul><li>Probably the only analysis method in HEP? </li></ul><ul><li>Works well with a good &quot;analyst/designer“ Works miserably </li></ul>
    16. 16. Noun List Analysis <ul><li>Identify nouns, adjectives, verbs from e.g. requirements documents </li></ul><ul><ul><li>nouns -> objects? </li></ul></ul><ul><ul><li>verbs -> methods? </li></ul></ul><ul><ul><li>adjectives -> object variations? -> abstractions? </li></ul></ul><ul><li>Fight blank page syndrome </li></ul><ul><li>Depends on quality of existing documentation </li></ul><ul><li>Too concrete, difficult in large projects </li></ul>
    17. 17. Use Case Analysis <ul><li>Start from requirements </li></ul><ul><li>Describe response of system to events </li></ul><ul><ul><li>Normal flow of action </li></ul></ul><ul><ul><li>Error and exception handling </li></ul></ul><ul><li>Can implement tests to check use cases </li></ul><ul><li>Can be quite formal </li></ul><ul><ul><li>UML diagrams </li></ul></ul><ul><ul><li>Nested use cases </li></ul></ul>
    18. 18. The Booch Micro Cycle Identify classes and objects Identify classes and objects semantics Identify classes and objects relationships Specify classes and objects interfaces and implementation <ul><li>Static model </li></ul><ul><li>Method names </li></ul><ul><li>Associations </li></ul><ul><li>Dynamic model </li></ul><ul><li>Message flow </li></ul><ul><li>Refine relationships </li></ul><ul><li>Find abstractions </li></ul><ul><li>Create headers </li></ul><ul><li>Write code </li></ul><ul><li>Test </li></ul>
    19. 19. Object Oriented Design <ul><li>OOD transforms the analysis model created using OOA into a design model that serves as a blueprint for software construction. </li></ul><ul><li>OOD results in a design that achieves a number of different levels of modularity. </li></ul><ul><li>Subsystems: Major system components. </li></ul><ul><li>Objects: Data and the operations. </li></ul><ul><li>Four important software design concepts: </li></ul><ul><ul><li>Abstraction </li></ul></ul><ul><ul><li>Information Hiding </li></ul></ul><ul><ul><li>Functional Independence </li></ul></ul><ul><ul><li>Modularity </li></ul></ul>
    20. 20. OOD <ul><li>The subsystem layer: Representation of each of the subsystems that enable the software to achieve its customer defined requirements. </li></ul><ul><li>The class and object layer: The class hierarchies, (generalization) and representation of objects. </li></ul><ul><li>The message layer: The design details of communication of each object with its collaborators. (external and internal interfaces) </li></ul><ul><li>The responsibilities layer: Data Structure and algorithmic design for all attributes and operations. </li></ul>
    21. 21. OOA to OOD
    22. 22. OOA to OOD
    23. 23. Design Issues <ul><li>decomposability—the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve; </li></ul><ul><li>composability—the degree to which a design method ensures that program components (modules), once designed and built, can be reused to create other systems; </li></ul><ul><li>understandability—the ease with which a program component can be understood without reference to other information or other modules; </li></ul><ul><li>continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules; </li></ul><ul><li>protection—a architectural characteristic that will reduce the propagation of side affects if an error does occur in a given module. </li></ul>
    24. 24. Process Flow for OOD
    25. 25. Unified Modeling Language
    26. 26. UML Diagram – What is UML? <ul><li>The Unified Modeling Language (UML) is a standard  language for </li></ul>Visualizing Constructing Documenting Business Modeling Communications Specifying
    27. 27. Different Views Users Designers Analyzers
    28. 28. UML- Eight Diagrams and One Language <ul><li>Use Case Diagram </li></ul><ul><li>Class Diagram/Object Diagram </li></ul><ul><li>State Diagram </li></ul><ul><li>Sequence Diagram </li></ul><ul><li>Collaboration Diagram </li></ul><ul><li>Activity Diagram </li></ul><ul><li>Component Diagram </li></ul><ul><li>Deployment Diagram </li></ul>
    29. 29. Use case diagram Online C2C shopping <ul><li>overview the usage requirements </li></ul><ul><li>presentations project stakeholders </li></ul><ul><li>&quot;the meat&quot; of the actual requirements </li></ul>Actor Actor: An actor is a person, organization, or external system that plays a role in one or more interactions with your system Use case Use case: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse System boundary System boundary: indicates the scope of your system.  Anything within the box represents functionality that is in scope and anything outside the box is not
    30. 30. Class Diagram Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Name Attributes Operations Relations <ul><li>Associations </li></ul><ul><li>Aggregation </li></ul><ul><li>Generalization </li></ul>
    31. 31. Relationships between Class Diagrams <ul><li>Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes. </li></ul><ul><li>Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. </li></ul><ul><li>Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. </li></ul>
    32. 32. Activity Diagram Activity diagrams describe the workflow behaviour of a system Start Fork Branch Merge Joint End
    33. 33. State Machine Diagram <ul><li>A State Machine diagram </li></ul><ul><li>shows the possible states of </li></ul><ul><li>the object and the transitions </li></ul><ul><li>that cause a change in state. </li></ul>? What is different between activities and Statemachine diagram
    34. 34. Sequence Diagram <ul><li>A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. </li></ul>
    35. 35. Collaboration Diagram <ul><li>The collaboration diagram illustrates messages being sent between classes and objects (instances). </li></ul>
    36. 36. Component Diagram <ul><li>A component diagram in the Unified Modeling Language, depicts how components are wired together to form larger components and or software systems. </li></ul>
    37. 37. Deployment Diagram <ul><li>deployment diagram specifies a set of constructs that can be used to define the execution architecture of systems that represent the assignment of software artifacts to nodes. </li></ul>
    38. 38. <ul><li>QUESTIONS </li></ul>
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×