Understanding Software Components: Characteristics and Design Principles

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