1 / 32

CSCI 383

CSCI 383. Object-Oriented Programming & Design Lecture 9 Martin van Bommel. Characteristics of Components. Let us return to the idea of a software component There are many different aspects to this simple idea, we will consider just a few: Behavior and State Instances and Classes

christophertwalker
Download Presentation

CSCI 383

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. CSCI 383 Object-Oriented Programming & Design Lecture 9 Martin van Bommel

  2. Characteristics of Components • Let us return to the idea of a software component • There are many different aspects to this simple idea, we will consider just a few: • Behavior and State • Instances and Classes • Coupling and Cohesion • Interface and Implementation CSCI 383 Lecture 9 M. van Bommel

  3. Behavior and State • All components can be characterized by two aspects: • The behavior of a component is the set of actions a component can perform. The complete set of behavior for a component is sometimes called the protocol • The state of a component represents all the information (data values) held within a component • Notice that it is common for behavior to change state. For example, the edit behavior of a recipe may change the preparation instructions, which is part of the state CSCI 383 Lecture 9 M. van Bommel

  4. Instances and Classes • We can now clarify a point we earlier ignored. There are likely many instances of recipe, but they will all behave in the same way. We say the behavior is common to the class Recipe • Since earlier our goal was to identify behavior, we ignored this distinction and concentrated on prototypical objects CSCI 383 Lecture 9 M. van Bommel

  5. Coupling and Cohesion • The separation of tasks into the domains of different components should be guided by the concepts of coupling and cohesion • Cohesion is the degree to which the tasks assigned to a component seem to form a meaningful unit. Want to maximize or minimize cohesion? • Coupling is the degree to which the ability to fulfill a certain responsibility depends upon the actions of another component. Want to maximize or minimize coupling? CSCI 383 Lecture 9 M. van Bommel

  6. Coupling and Cohesion • Students in a class were asked to write a large program (~ 1000 lines). One student’s entire program consisted of a single main() function int main() { CSCI 383 Lecture 9 M. van Bommel }

  7. Coupling and Cohesion • The student was told by the instructor that he needed to improve the program’s modularity • Student broke up code in main() arbitrarily, first 25 lines to function/module 1, next 25 lines to function/module 2, … int main() { } CSCI 383 Lecture 9 M. van Bommel

  8. Coupling and Cohesion • Cohesion is a measure of how well the parts of a component “belong together” • It is a property or characteristic of an individual module • Cohesion is strong if all parts are needed for the functioning of other parts • A method is cohesive when it does only a single, precise task. If you have trouble naming a method, would that suggest weak or strong cohesion? • Strong cohesion promotes maintainability and adaptability by limiting the scope of changes to a small number of components CSCI 383 Lecture 9 M. van Bommel

  9. Coupling and Cohesion • Coupling is a measure of the strength of the interconnections between system components • It is a property of a collection of modules • Coupling is tight between components if they depend heavily on one another (e.g., there is a lot communication among them) • Coupling is loose if there are few dependencies between components • Loose coupling promotes maintainability and adaptability since changes in one components are less likely to affect other ones CSCI 383 Lecture 9 M. van Bommel

  10. Interface and Implementation • We have characterized software components by what they can do • The user of a software component need only know what it does, not how it does it • “Ask not what you can do to a data structure, ask instead what your data structures can do for you” CSCI 383 Lecture 9 M. van Bommel

  11. Two views of a Software System • This naturally leads to two views of a software system • The term information hiding is used to describe the purposeful hiding of implementation details CSCI 383 Lecture 9 M. van Bommel

  12. The Unified Modeling Language • Several different notations for describing object-oriented designs were proposed in the 1980s and 1990s • The Unified Modeling Language (UML) is an integration of those notations • It describes notations for a number of different models that may be produced during OO analysis and design • It is now a de facto standard for OO modelling CSCI 383 Lecture 9 M. van Bommel

  13. History of OOAD leading to UML • 1970 • First object-oriented languages (Simula-67, Smalltalk) • 1980 • More than 50 different OOAD languages cause users trouble to find complete and appropriate tools • 1992 • New iterations of methods appear • Booch’93 (Grady Booch), OOSE (Ivar Jacobson), OMT-2 (James Rumbaugh) • 1995 • Unification, UML 0.9 by Booch and Rumbaugh • 1997 • Standardization, UML 1.1 by Booch, Rumbaugh, and Jacobson • Object Management Group (OMG) adapts UML as OOAD standard CSCI 383 Lecture 9 M. van Bommel

  14. History of UML CSCI 383 Lecture 9 M. van Bommel

  15. UML Diagrams CSCI 383 Lecture 9 M. van Bommel

  16. Diagrams and Process CSCI 383 Lecture 9 M. van Bommel

  17. Diagrams and Process CSCI 383 Lecture 9 M. van Bommel

  18. Diagrams and Process CSCI 383 Lecture 9 M. van Bommel

  19. Diagrams and Process CSCI 383 Lecture 9 M. van Bommel

  20. Diagrams and Process CSCI 383 Lecture 9 M. van Bommel

  21. UML Class Diagrams • Class diagrams describe the types of objects in the system and the various kinds of static relationships that exist among them • There are 2 principal kinds of static relationships: • Associations • “A customer may rent a number of videos” • Subtypes • “A student is a kind of person” • Class diagrams also show the attributesand operations of a class and the constraints that apply to the way objects are connected CSCI 383 Lecture 9 M. van Bommel

  22. UML Class Diagrams • The main symbols shown on class diagrams are • Classes • represent the types of data themselves • Attributes • are simple data found in classes and their instances • Operations • represent the functions performed by the classes and their instances • Associations • represent linkages between instances of classes • Generalizations • group classes into inheritance hierarchies CSCI 383 Lecture 9 M. van Bommel

  23. Classes • A class is represented as a box with name of the class inside • The diagram may also show the attributes and operations • A class can be drawn at several different levels of detail CSCI 383 Lecture 9 M. van Bommel

  24. Classes CSCI 383 Lecture 9 M. van Bommel

  25. Associations and Multiplicity • Anassociation is used to show how instances of two classes are related to each other (i.e., will reference each other) • Symbols indicating multiplicity are shown at each end of the association CSCI 383 Lecture 9 M. van Bommel

  26. Labelling associations • Each association can be labelled, to make explicit the nature of the association. There are 2 types of labels: • association names • should be a verb or verb phrase • Direction of association can be clarified by showing a little arrow • role names CSCI 383 Lecture 9 M. van Bommel

  27. Analyzing and validating associations • Many-to-one • A company has many employees • An employee can only work for one company • This company will not store data about the moonlighting activities of employees! • A company can have zero employees • E.g. a ‘shell’ company • It is not possible to be an employee unless you work for a company worksFor 1 Employee Company * CSCI 383 Lecture 9 M. van Bommel

  28. Analyzing and validating associations • Many-to-many • A secretary can work for many managers • A manager can have many secretaries • Secretaries can work in pools • Managers can have a group of secretaries • Some managers might have zero secretaries • Is it possible for a secretary to have, perhaps temporarily, zero managers? CSCI 383 Lecture 9 M. van Bommel

  29. Analyzing and validating associations • One-to-one • For each company, there is exactly one board of directors • A board is the board of only one company • A company must always have a board • A board must always be of some company 1 1 CSCI 383 Lecture 9 M. van Bommel

  30. Analyzing and validating associations • Avoid unnecessary one-to-one associations Avoid thisDo this CSCI 383 Lecture 9 M. van Bommel

  31. A more complex example • A booking is always for exactly one passenger • no booking with zero passengers • a booking could never involve more than one passenger • A passenger can have any number of bookings • a passenger could have no bookings at all • a passenger could have more than one booking CSCI 383 Lecture 9 M. van Bommel

  32. Association classes • Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes • The following are equivalent CSCI 383 Lecture 9 M. van Bommel

More Related