chapter 12 n.
Skip this Video
Loading SlideShow in 5 Seconds..
CHAPTER 12 PowerPoint Presentation
play fullscreen
1 / 99


178 Views Download Presentation
Download Presentation


- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  2. Object-Oriented Analysis • OOA is a semiformal analysis technique for the object-oriented paradigm • There are over 60 equivalent techniques • Today, the Unified Process is the only viable alternative • During this workflow • The classes are extracted

  3. Object-Oriented Analysis/Design • Object: is a component of the real world that is mapped into the software domain. A class is a set of objects that each has the same characteristics. • Encapsulation: is an act of grouping into a single object both data and the operations that affect data. • Information-hiding: The private side of an object is how it does these things, and it can do them in any way required. How it performs the operations or computes the information is not a concern of other parts of the system.

  4. Classes • Subclass is a class that inherits behavior from another class. • A subclass usually adds its own behavior to define its own unique kind of object. • Superclass is a class from which a specific behavior is inherited. • Abstract Class: class that is not intended to produce instances of itself.

  5. Messages • A message consists of the name of an operation and any required argument. • Polymorphism is the ability of two or more classes of object to respond to the same message, each in its own way.

  6. The Analysis Workflow • There are three types of classes: • Entity classes • Boundary classes • Control classes

  7. The Analysis Workflow (contd) • Entity class • Models long-lived information • Examples: • Account Class • Investment Class

  8. The Analysis Workflow (contd) • Boundary class • Models the interaction between the product and the environment • A boundary class is generally associated with input or output • Examples: • Investments Report Class • Mortgages Report Class

  9. The Analysis Workflow (contd) • Control class • Models complex computations and algorithms • Example: • Estimate Funds for Week Class

  10. UML Notation for These Three Class Types • Stereotypes (extensions of UML) Figure 12.1

  11. 12.5.2 CRC Cards • Used since 1989 for OOA • For each class, fill in a card showing • Name of Class • Functionality (Responsibility) • List of classes it invokes (Collaboration) • Now CRC cards are automated (CASE tool component)

  12. The Process of OOA/D-The CRC approach • Find the classes in your system. • Determine what operations each class is responsible for performing, and what knowledge it should maintain. • Determine the ways in which objects collaborate with other objects in order to discharge their responsibilities.

  13. The Process of OOA/D • a list of classes within your application, • a description of the knowledge and operations for which each class is responsible, and • a description of collaborations between classes.

  14. Exploratory Phase • Extract noun phrases from the specification and build a list. • Walk through various scenarios to explore possibilities. • Record the results on design cards.

  15. Classes - Exploratory Phase • Extract noun phrases from the specification and build a list. • Look for nouns that may be hidden, and add them to the list. • Identify candidate classes from the noun phrases by applying the following guidelines: • Model physical objects. • Model conceptual entities. • Use a single term for each concept. • Be wary of the use of adjectives. • Model categories of objects. • Model external interfaces. • Model the values of an object's attributes. • Identify candidates for abstract superclasses by grouping classes that share common attributes. • Use categories to look for classes that may be missing. • Write a short statement of the purpose of the class.

  16. Responsibilities - Exploratory Phase • Find responsibilities using the following guidelines: • Recall the purpose of each class, as implied by its name and • specified in the statement of purpose. • Extract responsibilities from the specification by looking for actions and information. • Identify responsibilities implied by the relationships between classes. • Assign responsibilities to classes using the following guidelines: • Evenly distribute system intelligence. • State responsibilities as generally as possible. • Keep behavior with related information. • Keep information about one thing in one place. • Share responsibilities among related classes. • Find additional responsibilities by looking for relationships between classes. • Use ``is-kind-of'' relationships to find inheritance relationships. • Use ``is-analogous-to'' relationships to find missing superclasses. • Use ``is-part-of'' relationships to find other missing classes.

  17. Collaborations - Exploratory Phase • Find and list collaborations by examining the responsibilities associated with classes. Ask: • With whom does this class need to collaborate to fulfill its responsibilities? • Who needs to make use of the responsibilities defined for this class? • Identify additional collaborations by looking for these relationships between classes: • the ``is-part-of'' relationship, • the ``has-knowledge-of'' relationship, and • the ``depend-upon'' relationship. • Discard classes if no classes collaborate with them, and they collaborate with no other classes.

  18. A product is to be installed to control n elevators in a building with m floors. The problem concerns the logic required to move elevators between floors according to the following constraints: 1. Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause the elevator to visit the corresponding floor. The illumination is canceled when the corresponding floor is visited by the elevator 2. Each floor, except the first and the top floor, has two buttons, one to request an up-elevator, one to request a down-elevator. These buttons illuminate when pressed. The illumination is canceled when an elevator visits the floor, then moves in the desired direction 3. If an elevator has no requests, it remains at its current floor with its doors closed

  19. 12.5.1 Noun Extraction • A two-stage process • Stage 1. Concise problem definition • Describe the software product in single paragraph • Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed

  20. Noun Extraction (contd) • Stage 2. Identify the nouns • Identify the nouns in the informal strategy • Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed • Use the nouns as candidate classes

  21. Noun Extraction (contd) • Nouns • button, elevator, floor, movement, building, illumination, request, door • floor, building, door are outside the problem boundary — exclude • movement, illumination, request are abstract nouns — exclude (they may become attributes) • Candidate classes: • Elevator Class and Button Class • Subclasses: • Elevator Button Class and Floor Button Class

  22. First Iteration of Class Diagram • Problem • Buttons do not communicate directly with elevators • We need an additional class:Elevator Controller Class Figure 12.5

  23. Second Iteration of Class Diagram Figure 12.6

  24. 12.6 Dynamic Modeling: The Elevator Problem Case Study Figure 12.7

  25. Dynamic Modeling: Elevator Problem (contd) • This UML statechart is equivalent to the state transition diagram of Figures 11.15 through 11.17 • This is shown by considering specific scenarios • In fact, a statechart is constructed by modeling the events of the scenarios

  26. Figure 12.8

  27. CRC Cards • Consider responsibility • 1. Turn on elevator button • This is totally inappropriate for the object-oriented paradigm • Responsibility-driven design has been ignored • Information hiding has been ignored • Responsibility 1. Turn on elevator button should be 1. Send message to Elevator Button Classto turn itself on

  28. CRC Cards (contd) • Also, a class has been overlooked • The elevator doors have a state that changes during execution (class characteristic) • Add class Elevator Doors Class • Safety considerations • Modify the CRC card

  29. Second Iteration of the CRC Card Figure 12.9

  30. CRC Cards (contd) • Having modified the class diagram, reconsider the • Use-case diagram (no change) • Class diagram (see the next slide) • Statecharts • Scenarios (see the slide after the next slide)

  31. Third Iteration of Class Diagram Figure 12.10

  32. Responsibilities • 8. Start timer • 10. Check requests, and • 11. Update requests are assigned to the elevator controller • Because they are carried out by the elevator controller

  33. The remaining eight responsibilities have the form • “Send a message to another class to tell it do something” • These should be assigned to that other class • Responsibility-driven design • Safety considerations • Methods open doors, close doors are assigned to class Elevator Doors • Methods turn off button, turn onbutton are assigned to classes Floor Button and Elevator Problem

  34. Detailed Class Diagram: Elevator Problem Figure 13.11

  35. Detailed Design: • Detailed design of elevatorEventLoop is constructed from the statechart Figure 13.12

  36. Software Design Software Design-``a system decomposition into modules-description of what each module is intended to do and of the relationship among the modules.'‘ • Design for Change • Program Families

  37. Design Process • Management Aspects: • Preliminary design (high level design) • Detail design (low level design) • Technical Aspects: • Data design • Architectural design • Procedure design • Interface design

  38. Effective modular design • Functional Independence • coupling: is a measure of the relative interdependence among modules. • cohesion: is a measure of the relative functional strength of a module

  39. Coupling • Coupling is a measure of interconnection among modules in a software structure. • Coupling depends on the interface complexity between modules.

  40. Cohesion • Coincidental cohesion: A module that performs a set of tasks that relate to each other loosely. • Logical cohesion: A module that performs tasks that are related logically. • Temporal cohesion: A module that performs tasks that are related by the fact that all must be executed with the same span of time. • Procedure cohesion: A module that processes elements that are related and must be executed in a specific order. • Communicational cohesion: A module that processes elements that all concentrate on one area of a data structure. • Sequential cohesion: The output data from an element is the input for the next element. • Functional cohesion: All of the elements are related to the performance of a single function.

  41. Coupling • No direct coupling: two modules are subordinate to different modules. • Data coupling: data passed via a module interface. • Stamp Coupling: data structure passed via a module interface. • Control coupling: control is passed via a ``flag'' on which decisionsare made in a subordinate or supordinate module. • External coupling: Modules are tied to an environment external to software. • Common coupling: a number of modules reference a global data area. • Content coupling: one module makes use of data or control information `maintained within the boundary of another module.

  42. Design Heuristics • Evaluate the ``First-Cut'' Program Structure to Reduce Coupling and Improve Cohesion. • Attempt to Minimize Structures with High Fan-Out; Strive for Fan-In as Depth Increases. • Keep Scope of Effect of a Module within the scope of Control of that Module. • Evaluate Module Interfaces to Reduce Complexity and Redundancy and Improve Consistency. • Define Modules Whose Function is Predictable, But Avoid Modules That are overly restrictive. • Strive for Single-Entry-Single-Exit Modules, Avoiding ``Pathological Connections.'' • Package Software Based on Design Constraints and Portability Requirements.

  43. Design Metrics Metrics: “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.” [IEEE93] • LOC • Cyclomatic complexity: McCabe, 1976 • V(G) = P + 1, V(G) = E – N + 2 • Function point: Albrecht, 1979 • FP entities: # of user inputs, # of user outputs, # of user inquiries, # of files, # of external interfaces • FP = count total * [0.65 + 0.01 * sum(fi )] Where fi ( 1 ~ 14) are value adjustment value factors based on the responses to 14 questions. Count total is the sum of weighted FP entities. • Henry and Kafura, 1981 • Length * (fan-in * fan-out)2

  44. Chidamber & Kemerer (CK) Metrics • Weighted Methods per Class (WMC) • Depth of Inheritance Tree (DIT) • Number of Children (NOC) • Coupling Between Object Classes(CBO) • Response For a Class (RFC) • Lack of Cohesion in Methods (LCOM)

  45. Weighted Methods Per Class (WMC) • Consider a Class C1 , with methods M1, …, Mn that are defined in the class. Let c1, …, cn be the complexity of the methods. Then: WMC = • If all method complexities are considered to be unity, then WMC = n

  46. Class foo { int local_var; int *pInt; public: foo(){local var = 1; pInt = new int;} int f1(){return local_var;} int f2(){return ++local_var;} int f3(){return 1/f1();} } Assume all methods with the same complexity: WMC(foo) = 4 WMC Example

  47. Depth of Inheritance Tree (DIT) • Depth of inheritance of the class is the DIT metric for the class. DIT = depth of the class in the inheritance tree • If multiple inheritance is allowed, DIT = the maximum length from the node to the root of the tree

  48. Number of Children (NOC) NOC = number of immediate subclasses subordinated to a class in the class hierarchy

  49. Coupling Between Objects (CBO) • A count of the number of other classes to which it is coupled. • An object is coupled to another object if one of them acts on the other. • Two classes are coupled when methods declared in one class use methods or instance variables defined by the other class.

  50. Class A { : M1(){ : B.M1(); C.M2(); : } } CBO (A) = 2 Class B { : M1(){ : } } Class C { : M2(){ : } } CBO Example