1 / 146

Chapter Three

Chapter Three. Object Oriented Design. Object Oriented Design. Object oriented design transforms the analysis model created using OO analysis into design model that serves as a blueprint for software construction. There are four layers of OO design pyramid.

snow
Download Presentation

Chapter Three

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. Chapter Three Object Oriented Design

  2. Object Oriented Design • Object oriented design transforms the analysis model created using OO analysis into design model that serves as a blueprint for software construction. • There are four layers of OO design pyramid. 1. The Subsystem Layer- subsystems to achieve customers requirements. 2. The Class and Object Layer- contains hierarchies. 3. The Message Layer- design details for communication. 4. The Responsibilities Layer- contains data structure & algorithmic design for attributes and operations for each objects.

  3. Object Oriented Design

  4. Object Oriented Design Steps To perform object-oriented design, a software engineer should perform the following generic steps: • Describe each subsystem and allocate it to processors and tasks. • Choose a design strategy for implementing data management, interface support, and task management. • Design an appropriate control mechanism for the system. • Perform object design by creating a procedural representation for each operation and data structures for class attributes. • Perform message design using collaborations between objects and object relationships. • Create the messaging model. • Review the design model and iterate as required.

  5. Relationship Between OOA and OOD

  6. Relationship Between OOA and OOD • Subsystem design is derived by: • considering overall customer requirements (represented with use-cases) • events and states that are externally observable (the object-behavior model) • Class and object design : • mapped from the description of attributes, operations, and collaborations contained in the CRC model. • Message design driven by: • the object-relationship model • Responsibilities design: • is derived using the attributes, operations, and collaborations described in the CRC model.

  7. Design Issues Five criteria for judging a design method's ability to achieve modularity: • Decomposability • Composability • Understandability • Continuity • Protection

  8. Most important early OOD methods: • The Booch method. • encompasses both "micro development process" and  "macro development process." • The Rumbaugh method. • encompasses a design activity that encourages design to be conducted at two different levels of abstraction: System design and Object design. • The Jacobson method. • design model emphasizes traceability to the OOSE analysis model. • The Coad and Yourdon method. • design approach addresses not only the application but also the infrastructure for the application • focuses on the representation of major system components:

  9. Collaboration • A collaboration is the specification of how an element such as classifier(including a class, interface, component, node or use case) or an operation is realized by a set of classifiers and associations playing specific roles used in a specific ways. • Collaborations have two aspects: • Structural part- • Specifies the classes, interfaces and other elements that work together. • Structural part of collaboration is typically rendered by a class diagram. • Behavioral part- • Specifies the dynamics of how those elements interact. • Behavioral part is rendered by using interaction diagram.

  10. A Collaboration

  11. Structural Aspects of Collaboration Class Diagram

  12. Behavioral Aspects of Collaboration

  13. Organizing Collaborations

  14. Collaboration Diagram • A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML). • An interaction diagram emphasizes the structural organization of the objects that send and receive messages.

  15. Collaboration Diagram • Collaboration diagrams have two features that distinguish them from sequence diagrams. • First, there is the path. To indicate how one object is linked to another. • Second, there is the sequence number. To indicate the time order of a message, you prefix the message with a number. • As Shown in following diagrams:

  16. Example of Collaboration Diagram

  17. Message – Link - Sequence • Flow of control within an operation, a class, a component, a use case, or the system as a whole. • Set of messages in a particular context to accomplish a purpose.

  18. Links and Association • A Link is a semantic connection among objects • A Link is an instance of an association

  19. Link specification for an Object

  20. Action Categories

  21. Messages

  22. Flow of Control - by Time

  23. Flow of Control - by Organization

  24. Case Study of simple HMS • A simple Hospital Management System (HMS) consists of receptionist, doctor, nurse and patient. Firstly the patient should get appointment from receptionist. The receptionist takes appointment from doctor. If the doctor is available, receptionist confirms to the patient. Then the patient consults to the doctor, so that doctor treats the patient. After completing treatment, receptionist asks for payment so that the patient pays fees and leaves the hospital. • Draw a collaboration diagram for above mentioned scenario of HMS.

  25. Collaboration diagram for simple HMS

  26. Class Work • Draw a Collaboration diagram for online banking system with authentication. OR • Draw a Collaboration diagram for facebook authentication system. Hint: User/client, fb application/web browser, fb authentication server, fb web server. OR

  27. Case Study -A • Ministry of Health and Population is willing to computerize its system. This new system will be able to tell the population of the country, zone and district and even of the ward of specific place. The system will update its data in monthly basis so that the birth rate and death rate can be easily seen. The home page is displayed when a person enters to the system. Administrators can enter to the admin panel by logging in with an ID and a password. He/she has privileges to enter and modify the data into the database. On the other hand, normal users can view the data but not modify them. They can also visualize the data in graphical form with animated charts, maps as well as in tabular form based on their selection of data. Besides, they can also view the forecasted data. (Make your assumptions if necessary)

  28. Case Study- B “Buy a landline telephone service scenario” Customer arrives at the reception of Telephone office and makes query about landline telephone. Receptionist requests to fill up an application form and send him to Sales department. Sales department asks for nearest/neighbor’s telephone number and search in the system (Sales Division system) so that SD system displays all information including availability of telephone distribution point (DP). If point is not available, sales department tells customer to submit application form and tells him that he will make contact if point became available in future. And customer leaves the office. Otherwise, sales officer enters customer details in SD system and sends him to telephone distribution department. Telephone distribution department makes cost estimation and forward him to cash counter for payment. Cashier receives cash and prints receipt after payment process and send him back to telephone distribution department. Customer presents receipt to the telephone distribution department so that telephone distribution department provides new landline telephone service to the customer.

  29. Object Diagram • An object diagram is a diagram that shows a set of objects and their relationships at a point in time. • Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams. • Object diagrams represent an instance of a class diagram. The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment.

  30. Example Object Diagram

  31. Modeling Object Structure

  32. Autonomous Robot : Object Structure Modeling

  33. A well-structured object diagram Drawing an object diagram

  34. Component Diagrams • Component diagrams are different in terms of nature and behavior. Component diagrams are used to model physical aspects of a system. • Now the question is what are these physical aspects? Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node. • So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems.

  35. Purpose of the component diagram • The purpose of the component diagram can be summarized as: • Visualize the components of a system. • Construct executables by using forward and reverse engineering. • Describe the organization and relationships of the components.

  36. How to draw Component Diagram? • Before drawing a component diagram the following artifacts are to be identified clearly: • Files used in the system. • Libraries and other artifacts relevant to the application. • Relationships among the artifacts. • After identifying the artifacts the following points needs to be followed: • Use a meaningful name to identify the component for which the diagram is to be drawn. • Prepare a mental layout before producing using tools. • Use notes for clarifying important points.

  37. Where to use Component Diagrams? • The usage of component diagrams can be described as: • Model the components of a system. • Model database schema. • Model executables of an application. • Model system's source code.

  38. Component Diagrams

  39. Component Diagrams

  40. Component Diagram[for withdrawal of cash] policy.dll Bank Server.exe Branch customer.dll Bank.dll Branch Bank.exe ATM.exe

  41. Forward Engineering of Component Diagram • To forward engineer a component diagram:- • For each component, identify the classes or collaborations that the component implements. • Choose the target for each component. Your choice is basically between source code (a form that can be manipulated by development tools) or a binary library or executable (a form that can be dropped into a running system). • Use tools to forward engineer your models.

  42. Reverse Engineering of Component Diagram • To reverse engineer a component diagram:- • Choose the target you want to reverse engineer. Source code can be reverse engineered to components and then classes. Binary libraries can be reverse engineered to uncover their interfaces. Executables can be reverse engineered the least. • Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new model or to modify an existing one that was previously forward engineered. • Using your tool, create a component diagram by querying the model. For example, you might start with one or more components, then expand the diagram by following relationships or neighboring components. Expose or hide the details of the contents of this component diagram as necessary to communicate your intent.

  43. Deployment Diagram • Deployment diagrams are used for describing the hardware components where software components are deployed. • Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware. • A deployment diagram consists of : • Nodes • Relationships among nodes

  44. The Purpose/Uses of deployment diagrams • To model the hardware topology of a system. • To model embedded system. • To model hardware details for a client/server system. • To model hardware details of a distributed application. • Forward and reverse engineering.

  45. .

  46. Deployment diagram Branch Bank_ Bank.exe Ethernet Ethernet Bank_ server ATM_ machine BankServer.exe ATM.exe

  47. Deployment Diagram

  48. To model embedded systems

  49. To model client/server systems

  50. To model distributed systems

More Related