11 topic 9 ooa

840 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
840
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

11 topic 9 ooa

  1. 1. Object-Oriented Paradigm• Object-oriented paradigm – Reaction to perceived shortcomings in structured paradigm – Problem of larger products – Data and action treated as equal partnersCS540 Software Design 1 Lecture 14 & 15
  2. 2. Object-Oriented Analysis (OOA) • Semi-formal specification technique • Multiplicity of different methods • All essentially equivalent • Nowadays, we represent OOA using UML (unified modeling language)CS540 Software Design 2 Lecture 14 & 15
  3. 3. The Three Steps of OOA • 1. Use-case modeling – Determine how the various results are computed by the product (without regard to sequencing) – Largely action oriented • 2. Class modeling (“object modeling”) – Determine the classes and their attributes – Purely data-oriented • 3. Dynamic modeling – Determine the actions performed by or to each class – Purely action-oriented • Iterative processCS540 Software Design 3 Lecture 14 & 15
  4. 4. The Object-Oriented Modeling Approach • Benefits 1. The ability to tackle more challenging problem domains 2. Improved communication among users, analysts, designers, and programmers 3. Reusability of analysis, design, and programming results 4. Increased consistency among the models developed during object-oriented analysis, design, and programmingA.4 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  5. 5. The Object-Oriented Modeling Approach (continued) • Object-Oriented Systems Development Life Cycle – Process of progressively developing representation of a system component (or object) through the phases of analysis, design, and implementation – The model is abstract in the early stages – As the model evolves, it becomes more and more detailedA.5 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  6. 6. The Object-Oriented Systems Development Life Cycle • Analysis Phase – Model of the real-world application is developed showing its important properties – Model specifies the functional behavior of the system independent of implementation details • Design Phase – Analysis model is refined and adapted to the environment • Implementation Phase – Design is implemented using a programming language or database management systemA.6 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  7. 7. The Object-Oriented Systems Development Life Cycle (continued) • Unified Modeling Language (UML) – A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models – Techniques and notations • Use cases • Class diagrams • State diagrams • Sequence diagramsA.7 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  8. 8. Use-Case Modeling • Applied to analyze functional requirements of the system • Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details • Use Case – A complete sequence of related actions initiated by an actor • Actor – An external entity that interacts with the systemA.8 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  9. 9. Use-Case Modeling • Use cases represent complete functionality of the system • Use cases may participate in relationships with other use cases • Use cases may also use other use casesA.9 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  10. 10. Elevator Problem: OOA• 1. Use-Case Modeling – Use case: Generic description of overall functionality• Get comprehensive insight into behavior of productCS540 Software Design 11 Lecture 14 & 15
  11. 11. Normal ScenarioCS540 Software Design 12 Lecture 14 & 15
  12. 12. Exception ScenarioCS540 Software Design 13 Lecture 14 & 15
  13. 13. Use Case• Use Case Name• Actors• Pre-Conditions• Normal Flow• Post-Conditions• Exceptions or Alternate FlowsCS540 Software Design 14 Lecture 14 & 15
  14. 14. Class Modeling• Extract classes and their attributes• Represent them using an entity-relationship diagram• Deduce the classes from use cases and their scenarios• Often there are many scenarios – Possible danger: too many candidate classesCS540 Software Design 15 Lecture 14 & 15
  15. 15. Two Approaches to Class Modeling• Noun extraction – Always works• CRC classes – Need to have domain expertiseCS540 Software Design 16 Lecture 14 & 15
  16. 16. Noun Extraction• Stage 1. Concise Problem Definition – Define product in single sentence • Buttons in elevators and on the floors control the motion of n elevators in a building with m floors.CS540 Software Design 17 Lecture 14 & 15
  17. 17. Noun Extraction (contd)• Stage 2. Informal Strategy – Incorporate constraints, express result in a single paragraph • Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; 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.CS540 Software Design 18 Lecture 14 & 15
  18. 18. Noun Extraction (contd)• Stage 3. Formalize the Strategy – Identify nouns in informal strategy. Use nouns as candidate classes• Nouns – button, elevator, floor, movement, building, illumination, do or – floor, building, door are outside problem boundary — exclude – movement and illumination are abstract nouns — exclude (may become attributes)• Candidate classes: Elevator and Button• Subclasses: Elevator Button and Floor Button CS540 Software Design 19 Lecture 14 & 15
  19. 19. First Iteration of Class Diagram • Problem – Buttons do not communicate directly with elevators – We need an additional class: Elevator ControllerCS540 Software Design 20 Lecture 14 & 15
  20. 20. Second Iteration of Class Diagram• All relationships are now 1-to-n – Makes design and implementation easierCS540 Software Design 21 Lecture 14 & 15
  21. 21. CRC Cards• Class Responsibility Collaboration (CRC)• Used since 1989 for OOA• For each class, fill in card showing – Name of class – Functionality (responsibility) – List of classes it invokes (collaboration) – Now automated (CASE tool component)• Strength – When acted out by team members, powerful tool for highlighting missing or incorrect items• Weakness – Domain expertise is needed CS540 Software Design 22 Lecture 14 & 15
  22. 22. 3. Dynamic Modeling• Produce UML state diagram• State, event, predicate distributed over state diagram• UML “guards” are in bracketsCS540 Software Design 23 Lecture 14 & 15
  23. 23. Testing during the OOA Phase • CRC cards are an excellent testing techniqueCS540 Software Design 24 Lecture 14 & 15
  24. 24. CRC Cards • Consider responsibility – 1. Turn on elevator button • Totally unacceptable for object-oriented paradigm • Responsibility-driven design ignored • Information hiding ignored • Responsibility 1. Turn on elevator button should be 1. Send message to Elevator Button to turn itself onCS540 Software Design 25 Lecture 14 & 15
  25. 25. CRC Cards (contd)• A class has been overlooked – Elevator doors have a state that changes during execution (class characteristic) – Add class Elevator Doors – Safety considerations• Reconsider class model• Then reconsider dynamic model, use-case modelCS540 Software Design 26 Lecture 14 & 15
  26. 26. Second Iteration of CRC CardCS540 Software Design 27 Lecture 14 & 15
  27. 27. Third Iteration of Class DiagramCS540 Software Design 28 Lecture 14 & 15
  28. 28. Second Iteration of Normal ScenarioCS540 Software Design 29 Lecture 14 & 15
  29. 29. Elevator Problem: OOA (contd)• All three models are now fine• We should rather say: – All three models are fine for now• We may need to return to the object- oriented analysis phase during the object-oriented design phaseCS540 Software Design 30 Lecture 14 & 15
  30. 30. Why Is All This Iteration Needed?• Perhaps the method is not yet mature? – Waterfall model (explicit feedback loops) – Rapid prototyping model (aim: to reduce iteration) – Incremental model, and – Spiral model• Latter two explicitly reflect iterative approach• Iteration is an intrinsic property of all software production – Especially for medium- and large-scale products – Expect iteration in the object-oriented paradigmCS540 Software Design 31 Lecture 14 & 15
  31. 31. Figure 10.5 An example of a state diagram10.32
  32. 32. Use case diagramsA use-case diagram gives the user’s view of a system: itshows how users communicate with the system. A use-casediagram uses four components: system, use cases, actors andrelationships. A system, shown by a rectangle, performs afunction. Figure 10.6 An example of use case diagram 10.33
  33. 33. Class diagramsThe next step in analysis is to create a class diagram for thesystem. For example, we can create a class diagram for ourold-style elevator. To do so, we need to think about theentities involved in the system. Figure 10.7 An example of a class diagram 10.34
  34. 34. State chartAfter the class diagram is finalized, a state chart can beprepared for each class in the class diagram. A state chart inobject-oriented analysis plays the same role as the statediagram in procedure-oriented analysis. 10.35
  35. 35. Object Modeling: Class Diagrams • Object – An entity that has a well-defined role in the application domain, and has state, behavior, and identity • State – A condition that encompasses an object’s properties and the values those properties have • Behavior – A manner that represents how an object acts and reacts • Object Class – A set of objects that share a common structure and a common behaviorA.36 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  36. 36. Object Modeling: Class Diagrams (continued) • Class Diagram – Class is represented as a rectangle with three compartments – Objects can participate in relationships with objects of the same classA.37 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  37. 37. Object Modeling: Object Diagrams • Object Diagram – A graph of instances that are compatible with a given class diagram; also called an instance diagram – Object is represented as a rectangle with two compartments • Operation – A function or service that is provided by all the instances of a class • Encapsulation – The technique of hiding the internal implementation details of an object from its external viewA.38 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  38. 38. A.39 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  39. 39. Representing Associations • Association – A relationship between object classes – Degree may be unary, binary, ternary or higher – Depicted as a solid line between participating classes • Association Role – The end of an association where it connects to a class – Each role has multiplicity, which indicates how many objects participate in a given association relationshipA.40 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  40. 40. A.41 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  41. 41. Representing Generalization • Generalization – Abstraction of common features among multiple classes, as well as their relationships, into a more general class • Subclass – A class that has been generalized • Superclass – A class that is composed of several generalized subclassesA.42 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  42. 42. Representing Generalization (continued) • Discriminator – Shows which property of an object class is being abstracted by a generalization relationship • Inheritance – A property that a subclass inherits the features from its superclass • Abstract Class – A class that has no direct instances but whose descendents may have direct instances • Concrete Class – A class that can have direct instancesA.43 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  43. 43. A.44 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  44. 44. Representing Aggregation • Aggregation – A part-of relationship between a component object and an aggregate object – Example: Personal computer • Composed of CPU, Monitor, Keyboard, etc.A.45 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  45. 45. Dynamic Modeling: State Diagrams • State – A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events – Shown as a rectangle with rounded corners • State Transition – The changes in the attributes of an object or in the links an object has with other objects – Shown as a solid arrow – Diagrammed with a guard condition and action • Event – Something that takes place at a certain point in timeA.46 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  46. 46. A.47 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  47. 47. Dynamic Modeling: Sequence Diagrams • Sequence Diagram – A depiction of the interaction among objects during certain periods of time • Activation – The time period during which an object performs an operation • Messages – Means by which objects communicate with each otherA.48 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  48. 48. Dynamic Modeling: Sequence Diagrams (continued) • Synchronous Message – A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself • Simple Message – A message that transfers control from the sender to the recipient without describing the details of the communicationA.49 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  49. 49. A.50 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  50. 50. Moving to Design • Start with existing set of analysis model • Progressively add technical details • Design model must be more detailed than analysis model • Component Diagram – A diagram that shows the software components or modules and their dependencies • Deployment Diagram – A diagram that shows how the software components, processes and objects are deployed into the physical architecture of the systemA.51 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  51. 51. A.52 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  52. 52. Summary • Object-Oriented Modeling Approach – Benefits – Unified Modeling Language • Use cases • Class diagrams • State diagrams • Sequence diagrams • Use Case ModelingA.53 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  53. 53. EXAMPLE 2
  54. 54. USE CASE: How do we find the use cases?• What functions will the actor want from the system?• Does the system store information? What actors will create, read, update. Or delete that information?• Does the system need to notify an actor about changes in its internal state? 55
  55. 55. USE CASE:• Generic format for documenting the use case: - Pre condition: If any – Use case : Name of the case. – Actors : List of actors(external agents), indicating who initiates the use case. – Purpose : Intention of the use case. – Overview : Description. – Type : primary / secondary. – Post condition: If any• Typical Course of Events: ACTOR ACTION : Numbered actions of the actor. SYSTEM RESPONSE : Numbered description of system responses. 56
  56. 56. USE CASE: USE CASE documentation example:• The following use case describes the process of opening a new account in the bank. Use case :Open new account Actors :Customer, Cashier, Manager Purpose :Like to have new saving account. Description :A customer arrives in the bank to open the new account. Customer requests for the new account form, fill the same and submits, along with the minimal deposit. At the end of complete successful process customer receives the passbook. Type :Primary use case. 57
  57. 57. Grouping USE CASES:• Those use case functionality which are directly dependent on the system environment are placed in interface objects• Those functionality dealing with storage and handling of information are placed in entity objects• Functionalitys specific to one or few use cases and not naturally placed in any of the other objects are placed in control objects By performing this division we obtain a structure which helps us to understand the system from logical view 58
  58. 58. OOAD --- USE CASE driven Analysis Design & Implementation Test Use cases make up the glue Implement Verify that use casesCapture,clarify use cases are satisfied& validate use cases 59
  59. 59. SYSTEM BOUNDARY: What is System Boundary?• It is shown as a rectangle.• It helps to identify what is external verses internal, and what the responsibilities of the system are.• The external environment is represented only by actors. 60
  60. 60. RELATIONSHIP:What is Relationship?• Relationship between use case and actor. Communicates• Relationship between two use cases Extends Uses• Notation used to show the relationships: << >> 61
  61. 61. RELATIONSHIP:• Relationship between use case and actor is often referred as “communicates” .• Relationship between two use cases is refereed as either uses or extends. USES:• - Multiple use cases share a piece of same functionality.• - This functionality is placed in a separate use case rather than documenting in every use case that needs it. 62
  62. 62. RELATIONSHIP: Contd...• A uses relationship shows behavior that is common to one or more use cases. EXTENDS:• It is used to show optional behavior, which is required only under certain condition. 63
  63. 63. USE CASE diagram: Use case diagram for the shown functionality. Balance status report extendsClerk Withdraw cash Customer uses Validation ATM Manager 64
  64. 64. Objective• To understand and capture the detailed specification of a system to be developed, from user perspective. 65
  65. 65. Beginning Analysis and Design• Completion of first version of use case diagram initiates the processes of analysis and design.• UML provides the framework to carry out the process of analysis and design in form of set of diagrams.• Every diagram and notation used in the diagram carries the semantics.• First step towards analysis and design is to specify the flow of events. 66
  66. 66. Flow of Events:• A flow of events document is created for each use case.• Details about what the system must provide to the actor when the use is executed.• Typical contents – How the use case starts and ends – Normal flow of events – Alternate flow of events – Exceptional flow of events• Typical Course of Events has: Actor Action(AA) System Response(SR) 67
  67. 67. Normal Flow of Events: For withdrawal of cash:• 1.(SR) The ATM asks the user to insert a card.• 2.(AA) The user inserts a cash card.• 3.(SR) The ATM accepts the card and reads its serial number.• 4.(SR) The ATM requests the password.• 5.(AA) The user enters 1234.• 6.(SR) The ATM verifies the serial number and password with the bank and gets the notification accordingly.• 7.(SA)The ATM asks the user to select the kind of transaction.• 8.(AA)User selects the withdrawal. 68
  68. 68. Normal Flow of Events: Contd...• 9.(SR)The ATM asks for the amount of cash; user enters Rs. 2500/-• 10.(SR)The ATM verifies that the amount of cash is within predefined policy limits and asks the bank, to process the transaction which eventually confirms success and returns the new account balance.• 11.(SR) The ATM dispenses cash and asks the user to take it.• 12.(AA) The user takes the cash.• 13.(SR) The ATM asks whether the user wants to continue.• 14.(AA) The user indicates no. 69
  69. 69. Normal Flow of Events: Contd...• 15.(SR) The ATM prints a receipt, ejects the card and asks the user to take them• 16.(AA) The user takes the receipt and the card.• 17.(SR) The ATM asks a user to insert a card. 70
  70. 70. Alternative Flow of Events: For withdrawal of cash use case:• 9. The ATM asks for the amount of cash; the user has change of mind and hits the “cancel”. 71
  71. 71. Exceptional Flow of Events: For withdrawal of cash use case:• 3 Suspicious pattern of usage on the card.• 10 The machine is out of cash.• 11 Money gets stuck in the machine. 72
  72. 72. Why flow of events?• It helps in understanding the functionality of a system to be developed.• Flow of events helps in finding objects of the system to be developed.• Happens to be most important and very first step towards analysis and design. 73
  73. 73. What is Scenario?• The functionality of the use case is captured in flow of the events.• A scenarios is one path through the flow of events for the use case.• Scenarios are developed to help identify objects, classes and object interactions for that use case. 74
  74. 74. USE CASE Realizations:• The use case diagram presents an outside view of the system• Interaction diagrams describe how use cases are realized as interactions among societies of objects.• Two types of interaction diagrams – Sequence diagrams – Collaboration diagrams 75
  75. 75. What is Interaction diagram?• Interaction diagrams are models that describe how groups of objects collaborate in some behavior• There are 2 kinds of interaction diagrams • Sequence diagram • Collaboration diagram• Sequence diagrams are a temporal representation of objects and their interactions• Collaboration diagrams are spatial representation of objects, links and interrelations 76
  76. 76. What is sequence diagram?• Typically these diagrams capture behaviors of the single scenario.• Shows object interaction arranged in time sequence.• They show sequence of messages among the objects.• It has two dimensions, vertical represents time & horizontal• represents objects.• Components of sequence diagram: -objects -object lifeline -Message -pre/post conditions. 77
  77. 77. OBJECT & OBJECT LIFE LINE:•Object are represented by rectangles and name of the objects are underlined.•Object life line are denoted as dashed lines. They are used to model the existence of objects over time. Name:Class 78
  78. 78. MESSAGES:• They are used to model the content of communication between objects. They are used to convey information between objects and enable objects to request services of other objects.• The message instance has a sender, receiver, and possibly other information according to the characteristics of the request.• Messages are denoted as labeled horizontal arrows between life lines.• The sender will send the message and receiver will receive the message. 79
  79. 79. MESSAGES: Contd…• May have square brackets containing a guard conditions. This is a Boolean condition that must be satisfied to enable the message to be sent.• May have have an asterisk followed by square brackets containing an iteration specification. This specifies the number of times the message is sent.• May have return list consisting of a comma -separated list of names that designate the values of returned by the operation.• Must have a name or identifier string that represents the message.• May have parentheses containing an argument list consisting of a comma separated list of actual parameters passed to a method. 80
  80. 80. Sequence diagram [for withdrawal of cash, normal flow]:Customer :ATM :Bank Insert card Request password Enter the password Verify account Account o.k. Request option Enter option Create Request amount Transaction :Transaction Enter the amount Update transaction Transaction commit Transaction Dispense cash complete Request take cash Take cash Request continuation Terminate Print receipt ,eject card Request take card Take card Display main screen and prompt for the card. 81
  81. 81. What is Collaboration diagram?• Collaboration diagrams illustrate the interaction between the objects, using static spatial structure.• Unlike sequence diagram the time is not explicitly represented in these diagrams• In collaboration diagram the sequence of messages is indicated by numbering the messages. The UML uses the decimal numbering scheme.• In these diagrams, an actor can be displayed in order to represent the triggering of interaction by an element external to the system.• This helps in representing the interaction, without going into the details of user interface. 82
  82. 82. Components of collaboration diagram:• Named objects• Links: Links are represented by a continuous line between objects, and indicates the exchange of messages.• Messages has following attributes: • Synchronization --thread name, step within thread. • Sequence number • Message labels : The name of the message often corresponds to an operation defined in the class of the object that is the destination of the message. Message names may have the arguments and return values. • *[iteration]. • It uses decimal notation. • Message direction. 83
  83. 83. Semantics of components:• Object names identify which objects are participating and the links show which objects collaborate• A link between two objects must exist for one object to send message to another and vice a versa.• Messages in the collaboration diagram get transformed to more detailed signature.• They use the decimal notation system for numbering the messages.• The direction of the message defines the sender and receiver of the message 84
  84. 84. The elements of message:• Predecessor• Role names• Message qualifiers – Iteration expression – Parameters – Return values – Guard – Message stereotypes• Concurrent thread sequencing• Thread dependencies• Message expression [Pre] A1:*(expression):doIt(p,r):return value 85
  85. 85. The examples of message: 4:Display(x,y) Simple message 3.3.1:Display(x,y) Nested message 4.2:subtract[Today,Birthday]:age Nested message with return value [Age >=18] 6.2:Vote() Conditional message 4.a,b.6/c.1:Turnon(Lamp) Synchro. with other flow of execution 1*:wash() Iteration 3.a,3.b/4*||[i:=1..n]:Turnoff() Parallel iteration 86
  86. 86. Collaboration diagram [for withdrawal of cash, normal flow.] 1. Insert card Enter password, Enter kind Enter amount, Take cash, Take card cancel,Terminate, Continue Create Transaction Transaction complete CUST- TRANSA- ATM CTION OMER Display main screen unreadable card message, request password, request kind, request amount, canceled message, eject card, failure message, dispense cash, request take cash Transaction succeed request continuation, Transaction failed print receipt, request take card account o.k. bad account message, Verify account, bad account, bad bank account message process transaction bad password, bad bank code BANK 87
  87. 87. Objective of the fifth module• To know the interaction among the objects in temporal and spatial form.• To know how objects collaborate among each other and hence delegate the responsibility to the respective objects.• To understand how the messages get matured with more information. 88
  88. 88. Module-5 89
  89. 89. What is Class diagram?• A class diagram shows the existence of classes and their relationships in the logical view of a system• UML modeling elements in class diagrams are: – Classes, their structure and behavior. – relationships components among the classes like association, aggregation, composition, dependency and inheritance – Multiplicity and navigation indicators – Role names or labels. 90
  90. 90. Major Types of classes:Concrete classes• A concrete class is a class that is instantiable; that is it can have different instances.• Only concrete classes may be leaf classes in the inheritance tree.Abstract classes• An abstract class is a class that has no direct instance but whose descendants classes have direct instances.• An abstract class can define the protocol for an operation without supplying a corresponding method we call this as an abstract operation.• An abstract operation defines the form of operation, for which each concrete subclass should provide its own implementation. 91
  91. 91. 10-3 DESIGN PHASEThe design phase defines how the system willaccomplish what was defined in the analysis phase. Inthe design phase, all components of the system aredefined. 10.93
  92. 92. Procedure-oriented designIn procedure-oriented design we have both procedures anddata to design. We discuss a category of design methods thatconcentrate on procedures. In procedure-oriented design, thewhole system is divided into a set of procedures or modules. 10.94
  93. 93. Structure chartsA common tool for illustrating the relations betweenmodules in procedure-oriented design is a structure chart.For example, the elevator system whose state diagram isshown in the previous slides can be designed as a set ofmodules shown in the structure chart below 10.95 A structure chart
  94. 94. ModularityModularity means breaking a large project into smaller partsthat can be understood and handled easily. In otherwords, modularity means dividing a large task into smalltasks that can communicate with each other. The structurechart discussed in the previous section shows the modularityin the elevator system. There are two main concerns when asystem is divided into modules: coupling and cohesion.Coupling is a measure of how tightly two modules are boundto each other. i Coupling between modules in a software system must be minimized. 10.96
  95. 95. Another issue in modularity is cohesion. Cohesion is ameasure of how closely the modules in a system are related.We need to have maximum possible cohesion betweenmodules in a software system. i Cohesion between modules in a software system must be maximized. 10.97
  96. 96. Object-oriented designIn object-oriented design the design phase continues byelaborating the details of classes. As we mentioned inChapter 9, a class is made of a set of variables (attributes)and a set of methods. The object-oriented design phase listsdetails of these attributes and methods. Figure 10.9 shows anexample of the details of our four classes used in the designof the old-style elevator. Figure 10.9 An example of classes with attributes and methods 10.98

×