Uploaded on

 

More in: Automotive , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
93
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Object Oriented Design OO Design 1
  • 2. Object Orientation    Traditional procedural systems separate data and procedures, and model these separately Object orientation –views data and functions together; data abstraction is the basis The purpose of OO design is to define the classes in the system to be built and their relationships OO Design 2
  • 3. OOA and OOD      OO techniques can be used in analysis (requirements) as well as design The methods and notations are similar In Object Oriented Analysis (OOA) we model the problem, while in Object Oriented Deisgn (OOD) we model the solution Often OOA structures are subsumed in the solution domain structures The line between OOA and OOD is not fixed OO Design 3
  • 4. OOA and OOD… OO Design 4
  • 5. OO Concepts  Encapsulation – grouping of related ideas into one unit which we can refer to by a single name   Eg. procedures, functions, packages In OO, object is the unit; encapsulates state and provides interface to access and modify OO Design 5
  • 6. OO Concepts..    Information hiding – use encapsulation to restrict external visibility OO encapsulates the data, provides limited access, visibility Information hiding can be provided without OO – is an old concept OO Design 6
  • 7. OO Concepts…    State retention – functions, procedures do not retain state; an object is aware of its past and maintains state Identity – each object can be identified and treated as a distinct entity Behavior – state and services together define the behavior of an object, or how an object responds OO Design 7
  • 8. OO Concepts..   Messages – through which a sender object conveys to a target object a request For requesting O1     must have – a handle for O2 name of the operation information on operations that O2 requires General format O2.method(args) OO Design 8
  • 9. OO Concepts..  Classes – a class is a stencil from which objects are created; defines the structure and services. A class has       An interface which defines which parts of an object can be accessed from outside Body that implements the operations Instance variables to hold object state A class defines the attributes and operations Objects and classes are different; class is a type, object is an instance State and identity is of objects OO Design 9
  • 10. OO Concepts – access  Operations in a class can be     Public: accessible from outside Private: accessible only from within the class Protected: accessible from within the class and from within subclasses There are some constructor and destructor operations  Used to modify attributes OO Design 10
  • 11. Inheritance  Inheritance is unique to OO     not there in function-oriented languages/models Inheritance by class B from class A is the facility by which B implicitly gets the attributes and operations of A as part of itself Attributes and methods of A are reused by B When B inherits from A, B is the subclass or derived class and A is the base class or superclass OO Design 11
  • 12. Inheritance..    A subclass B generally has a derived part (inherited from A) and an incremental part (is new) Hence, B needs to define only the incremental part Creates an “is-a” relationship  objects of type B are also objects of type A OO Design 12
  • 13. Inheritance… OO Design 13
  • 14. Inheritance…     The inheritance relationship between classes forms a class hierarchy In models, hierarchy should represent the natural relationships present in the problem domain In a hierarchy, all the common features can be accumulated in a superclass An existing class can be a specialization of an existing general class – is also called generalization-specialization relationships OO Design 14
  • 15. Hierarchy Class Example Attributes Subclass has access to these Operations Subclass has access to these OO Design 15
  • 16. Inheritance…     Strict inheritance – a subclass takes all features of parent class Only adds features to specialize it Non-strict: when some of the features have been redefined Strict inheritance supports “is-a” cleanly and has fewer side effects OO Design 16
  • 17. Inheritance…  Single inheritance – a subclass inherits from only one superclass   Class hierarchy is a tree Multiple inheritance – a class inherits from more than one class   Can cause runtime conflicts Repeated inheritance - a class inherits from a class but from two separate paths OO Design 17
  • 18. Inheritance and Polymorphism    Inheritance brings polymorphism, i.e. an object can be of different types An object of type B is also an object of type A Hence an object has a static type and a dynamic type   Implications on type checking Also brings dynamic binding of operations which allows writing of general code where operations do different things depending on the type OO Design 18
  • 19. Module Level Concepts      Basic modules are classes During design key activity is to specify the classes in the system being built Correctness of design is fundamental But design should also be “good” – efficient, modifiable, stable, … Can evaluate a design using coupling, cohesion, and open-closed principle OO Design 19
  • 20. Coupling     Coupling is an inter-module concept, captures the strength of interconnection between modules More tightly coupled the modules, the more they depend on each other, more difficult to modify one Low coupling is desirable for making systems understandable and modifiable In OO, three types of coupling exists – interaction, component, and inheritance OO Design 20
  • 21. Coupling…  Interaction coupling occurs due to methods of a class invoking methods of other classes     Like calling of functions Worst form if methods directly access internal parts of other methods Still bad if methods directly manipulate variables of other classes Passing information through temporary variables is also bad OO Design 21
  • 22. Coupling…  Least interaction coupling if methods communicate directly with parameters     With least number of parameters With least amount of information being passed With only data being passed I.e. methods should pass the least amount of data, with least number of parameters OO Design 22
  • 23. Coupling…  Component coupling – when a class A has variables of another class C      A has instance variables of C A has some parameters of type C A has a method with a local variable of type C When A is coupled with C, it is coupled with all subclasses of C as well Component coupling will generally imply the presence of interaction coupling also OO Design 23
  • 24. Coupling…     Inheritance coupling – two classes are coupled if one is a subclass of other Worst form – when subclass modifies a signature of a method or deletes a method Coupling is bad even when same signature but a changed implementation Least, when subclass only adds instance variables and methods but does not modify any OO Design 24
  • 25. Cohesion   Cohesion is an intra-module concept Focuses on why elements are together      Only elements tightly related should exist together in a module This gives a module clear abstraction and makes it easier to understand Higher cohesion leads to lower coupling – many interacting elements are in the module Goal is to have higher cohesion in modules Three types of cohesion in OO – method, class, and inheritance OO Design 25
  • 26. Cohesion…  Method cohesion – why different code elements are together in a method (like cohesion in functional modules)   Highest form is if each method implements a clearly defined function with all elements contributing to implementing this function Should be able to state what the module does by a simple statement OO Design 26
  • 27. Cohesion…  Class cohesion – why different attributes and methods are together in a class    A class should represent a single concept with all elements contributing towards it Whenever multiple concepts encapsulated, cohesion is not as high A symptom of multiple concepts – different groups of methods accessing different subsets of attributes OO Design 27
  • 28. Cohesion…  Inheritance cohesion – focuses on why classes are together in a hierarchy  Two reasons for subclassing generalization-specialization  reuse   Cohesion is higher if the hierarchy is for providing generalization-specialization OO Design 28
  • 29. Friday OO Design 29
  • 30. Open-closed Principle  Principle: Classes should be open for extension but closed for modification     Behavior can be extended to accommodate new requirements, but existing code is not modified I.e. allows addition of code, but not modification of existing code Minimizes risk of having existing functionality stop working due to changes – a very important consideration while changing code Good for programmers as they like writing new code OO Design 30
  • 31. Open-closed Principle…     In OO this principle is satisfied by using inheritance and polymorphism Inheritance allows creating a new class to extend behavior without changing the original class This can be used to support the openclosed principle Consider example of a client object which interacts with a printer object for printing OO Design 31
  • 32. Example OO Design 32
  • 33. Example..   Client directly calls methods on Printer1 If another printer is to be allowed    A new class Printer2 will be created But the client will have to be changed if it wants to use Printer 2 Alternative approach    Have Printer1 a subclass of a general Printer For modification, add another subclass Printer 2 Client does not need to be changed OO Design 33
  • 34. Example… OO Design 34
  • 35. Liskov’s Substitution Principle   Principle: Program using object O1 of base class C should remain unchanged if O1 is replaced by an object of a subclass of C If hierarchies follow this principle, the openclosed principle gets supported OO Design 35
  • 36. Unified Modeling Language (UML) and Modeling     UML is a graphical notation useful for OO analysis and design Allows representing various aspects of the system Various notations are used to build different models for the system OOAD methodologies use UML to represent the models they create OO Design 36
  • 37. Modeling      Modeling is used in many disciplines – architecture, aircraft building, … A model is a simplification of reality “All models are wrong, some are useful” A good model includes those elements that have broad effect and omits minor elements A model of a system is not the system! OO Design 37
  • 38. Why build models?     Models help us visualize a system Help specify the system structure Gives us a template that can guide the construction Document the decisions taken and their rationale OO Design 38
  • 39. Modeling     Every complex system requires multiple models, representing different aspects These models are related but can be studied in isolation Eg. Architecture view, electrical view, plumbing view of a building Model can be structural, or behavioral OO Design 39
  • 40. Views in an UML  Different views       A use case view A design view A process view Implementation view Deployment view We will focus primarily on models for design  class diagram, interaction diagram, etc. OO Design 40
  • 41. Class Diagrams   Classes are the basic building blocks of an OO system as classes are the implementation units also Class diagram is the central piece in an OO design. It specifies    Classes in the system Association between classes Subtype, supertype relationship OO Design 41
  • 42. Class Diagram…     Class itself represented as a box with name, attributes, and methods There are conventions for naming If a class is an interface, this can be specified by <<interface>> stereotype Properties of attributes/methods can be specified by tags between { } OO Design 42
  • 43. Class – example OO Design 43
  • 44. Generalization-Specialization   This relationship leads to class hierarchy Can be captured in a class diagram    Arrows coming from the subclass to the superclass with head touching super Allows multiple subclasses If specialization is done on the basis of some discriminator, arrow can be labeled OO Design 44
  • 45. Example – class hierarchy OO Design 45
  • 46. Association/aggregation   Classes have other relationships Association: when objects of a class need services from other objects    Shown by a line joining classes Multiplicity can be represented Aggregation: when an object is composed of other objects   Captures part-whole relationship Shown with a diamond connecting classes OO Design 46
  • 47. Example – association/aggregation OO Design 47
  • 48. Interaction Diagrams    Class diagrams represent static structure of the system (classes and their relationships) Do not model the behavior of system Behavioral view    Interaction is between objects, not classes Interaction diagram in two styles    shows how objects interact for performing actions (typically a use case) Collaboration diagram Sequence diagram Two are equivalent in power OO Design 48
  • 49. Sequence Diagram      Objects participating in an interaction are shown at the top For each object a vertical bar represents its lifeline Message from an object to another, represented as a labeled arrow If message sent under some condition, it can be specified in bracket Time increases downwards, ordering of events is captured OO Design 49
  • 50. Example – sequence diagram Time Objects participating in an interaction OO Design 50
  • 51. Collaboration diagram     Also shows how objects interact Instead of timeline, this diagram looks more like a state diagram Ordering of messages captured by numbering them Is equivalent to sequence diagram in modeling power OO Design 51
  • 52. Example – collaboration diag OO Design 52
  • 53. Other Diagrams   Class diagram and interaction diagrams most commonly used during design There are other diagrams used to build different types of models OO Design 53
  • 54. State Diagrams     Dynamic model to represent behavior of an individual object or a system Shows the states of an object and transitions between them Helps understand the object – focus only on the important logical states State diagrams can be very useful for automated and systematic testing OO Design 54
  • 55. State diagram of a stack push pop OO Design 55
  • 56. Activity Diagrams   Another method for modeling the dynamic behavior Describes the sequence of activities, and parallel behavior in a system   Activity represented by ovals, dependence shown by inputs/outputs Variant of a state diagram – captures the state of the system and transitions OO Design 56
  • 57. Other Diagrams      Instead of objects/classes, can represent components, packages, subsystems These are useful for developing architecture structures UML is extensible – can model a new but similar concept by using stereotypes (by adding <<name>>) Tagged values can be used to specify additional properties, e.g. private, readonly.. Notes can be added OO Design 57
  • 58. Other symbols OO Design 58
  • 59. Design using UML      Many OOAD methodologies have been proposed They provide some guidelines on the steps to be performed Basic goal is to identify classes, understand their behavior, and relationships Different UML models are used for this Often UML is used, methodologies are not followed strictly OO Design 59
  • 60. Design using UML  Basic steps       Identify classes, attributes, and operations from use cases Define relationships between classes Make dynamic models for key use cases and use them to refine class diagrams Make a functional model and use it to refine the classes Optimize and package Class diagrams play the central role; class definition gets refined as we proceed OO Design 60
  • 61. Success Scenario         Customer read the menu Customer places the order Order is sent to the kitchen for preparation Ordered items are served Customer requests for a bill for the order Bill is prepared for this order Customer is given the bill Customer pays the bill OO Design 61
  • 62. Restaurant example: Initial classes OO Design 62
  • 63. OO Design 63
  • 64. Restaurant example: a sequence diagram OO Design 64
  • 65. Example: Word Count Problem     System prompts for the file name; user enters the file name System checks for existence of file System reads the words from the file Systems prints the count OO Design 65
  • 66. Example: Word Count Problem… File name History getword() isEof() Counter addWord() count exists() increment() display() Word string setstring() getstring() OO Design 66
  • 67. Example: Word Count Problem… Read File Check For Uniqueness Get words Increment Count Add to History OO Design 67
  • 68. Monday   Object Oriented Design Covered concepts       Covered constraints    Classes and objects Encapsulation State, behavior, identity Relationships among objects Inheritance and polymorphism Coupling Cohesion Covered tools   Class diagrams Sequence diagrams OO Design 68
  • 69. Metrics  Weighted Methods per Class (WMC)  Complexity of a class depends on number of classes and their complexity      Suppose class C has methods M1, M2, …, Mn Suppose complexity of methods is c1, c2… determined by some functional complexity metric WMC = Σ ci If the complexity of each method is considered 1, WMC gives the total number of methods in the class Large WMC might mean that the class is more fault-prone OO Design 69
  • 70. Metrics…  The deeper a class is in a class hierarchy    More methods to reuse – larger reuse potential Increased coupling – harder to make change Depth of Inheritance (DIT) Tree  DIT of class C in an inheritance hierarchy tree is depth from the root class   Shortest path from root to node C DIT is significant in predicting fault proneness OO Design 70
  • 71. Metrics…  Number of Children (NOC)     Number of immediate subclasses of C Evaluates the degree of reuse Higher NOC indicates reuse of definitions in superclass by a larger number of subclasses Indicates influence of a class on other elements   Larger influence, more important to get design correct Higher NOC classes are less defect-prone NOC is only measuring structure, not inheritance OO Design 71
  • 72. Metrics…  Coupling Between Classes (CBC)   Reduces modularity and makes module modification harder CBC = Number of classes to which this class is coupled   Can be determined from code   Two classes are coupled if methods of one use methods or instance variables of other There are indirect forms of coupling that cannot be statically determined (e.g., pointers) Can predict fault proneness of classes, particular user interface classes OO Design 72
  • 73. Metrics…  Response for a Class (RFC)   The total number of methods that can be invoked from an object of this class RFC of C is cardinality of the response set for a class  Set of all methods that can be invoked if a message is sent to an object of this class     All methods of C as well as other classes the methods of C send messages Even if CBC of a class is 1, RBC may be high Captures the strength of connections Harder to test classes with high RFC OO Design 73
  • 74. Metrics…  Lack of Cohesion in Methods (LCOM)  Cohesion captures how close are different methods of a class bound      Two methods form a cohesive pair if they access some common variables Form a non-cohesive pair if no common variables High cohesion is highly desirable LCOM is the number of method pairs that are noncohesive minus the number of cohesive pairs Not significant in predicting fault tolerance of a class OO Design 74
  • 75. Metrics Studies Show  Weighted Methods per Class (WMC)  Classes tend to have only small number of methods     Has a reasonable correlation with fault-proneness of a class Depth of Inheritance (DIT)  Classes tend to be close to the root     Classes are simple and provide some specific abstraction and operations Only few classes have many methods defined in them Max DIT around 10 Most classes have DIT of 0 (they are the root) Designers tend to keep the number of abstraction levels small, i.e., they give up reusability in favor of comprehensibility Number of Children (NOC)   Classes generally had a smaller NOC value with most having 0 Inheritance was not used very heavily OO Design 75
  • 76. Metrics Studies Show…  Coupling Between Classes (CBC)  Most classes are self contained with CBC = 0    Interface objects tend to have higher CBC Response for a Class (RFC)    Not coupled with any other class Most classes tend to invoke a small number of methods of other classes Classes for interface objects tend to have higher RFC Lack of Cohesion in Methods (LCOM)  Not very good at predicting fault-proneness OO Design 76
  • 77. Summary       OO is a newer paradigm, slowly replacing the functional approach OO models both data and functions UML is a notation that is used often to model systems in an OO manner UML provides various diagrams for modeling the structure, dynamic behavior, etc. Through UML modeling, design for the system can be developed Metrics can help predict fault proneness of design OO Design 77
  • 78. Example OO Design – PIMS Personal Investment System   Help investors keep track of their investments Determine rate of return    On individual investments On overall portfolio Determine net worth of portfolios OO Design 78
  • 79. Example OO Design – PIMS…    Investor can have many portfolios Portfolio can have many investments Investor can invest and withdraw any amount of money at any time    Get current value of each investment from Web site Invest in instruments with fixed interest rates       Alert to notify pending maturity dates Save information about the portfolio Edit entered data View any portfolio   Dates and amounts are tracked by PIMS Summary Detailed Provide security Determine rate of return     For each investment Overall for each portfolio Total investments Compute on monthly basis OO Design 79
  • 80. Example OO Design – PIMS… Basic Classes Class Principle Responsibility Investment Manages computations regarding total investment. Portfolio Manages computations regarding a Portfolio. Security Manages computations related to a security. Transaction Manages computations and stores attributes related to a transaction. GUI Manages the Graphical User Interface. NetLoader Manages downloading current prices of shares from the Internet. Current Value System Manages current value of shares. Alerts Manages alerts. SecurityManager Manages user validation. DataRepository Manages all file operations. It is an interface between the main modules and the database (which in our case is done using file system.) OO Design 80
  • 81. Example OO Design – PIMS… Inheritance Structure Two kinds of transactions buy: exchange cash for security sell: exchange security for cash Two kinds of securities Bank: interest bearing Shares: trading/dividends OO Design 81
  • 82. Example OO Design – PIMS… Aggregation Structure An investment consists of many portfolios A portfolio can consist of many different securities Many transactions can act on a single security OO Design 82
  • 83. Example OO Design – PIMS… Class Diagram Investment 1 m Transaction Portfolio m 1 m Security Bank Deposit Debit 1 Credit Shares OO Design 83
  • 84. Example OO Design – PIMS… associations for action Create/Delete/Edit Transaction OO Design 84
  • 85. Example OO Design – PIMS… Class diagram with all classes and associations OO Design 85
  • 86. Example OO Design – PIMS… Basic Actions Actions Create/Delete/Rename Portfolio/Security. Create/Delete/Edit Transactions. Calculate Net Worth of Investment/Portfolio/ Security. Calculate Rate of Investment of a security. Load Current Prices from the Internet. Check/Set/Delete Alerts. Validate User. OO Design 86
  • 87. Example OO Design – PIMS… Sequence diagram for principle action Create Portfolio OO Design 87
  • 88. Example OO Design – PIMS… Sequence diagram for principle action Delete Transaction OO Design 88
  • 89. Example OO Design – PIMS… Sequence diagram for action Compute Net Worth of Investment/Portfolio/Security OO Design 89
  • 90. Example OO Design – PIMS… Sequence diagram for action Compute ROI OO Design 90
  • 91. Example OO Design – PIMS… Sequence diagram for action Load current prices from the Internet OO Design 91
  • 92. Example OO Design – PIMS… Sequence diagram for action Set/Check/Delete Alerts OO Design 92
  • 93. Example OO Design – PIMS… Sequence diagram for action Validate User OO Design 93