Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

  • Login to see the comments


  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>