1. CSCI-383 Object-Oriented Programming & Design Lecture 9

2. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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

3. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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

4. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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

5. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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?

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() { }

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() { }

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

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

10. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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”

11. Adapted From: An Introduction to Object Oriented Programming, 3 rd Edition, by Timothy Budd 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

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

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

14. History of UML

15. UML Diagrams

16. Diagrams and Process

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 attributes and operations of a class and the constraints that apply to the way objects are connected

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

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

24. Classes

25. Associations and Multiplicity An association 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

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

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 EmployeeCompany 1

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?

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

30. Analyzing and validating associations Avoid unnecessary one-to-one associations Avoid this Do this

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

32. Association classes Sometimes, an attribute that concerns two associated classes cannot be placed in either of the classes The following are equivalent