3.2.5. Associations

1. 3.2.5. Associations The relations is_a and has_a are fundamental ways to understand collections of classes. In an OO implementation these relations will usually be visible in the code. But they are not the only interesting relations!

2. Almost every OO model features relations which are ad hoc and reflect the special semantical meaning or intension of classes. Such general relations are called associations. They are used in database theory, where • records, and • relationships between records are described in Entity/Relationship diagrams.

3. Reasons: • because two or more objects may exchange messages or services, • because two or more objects may co-exist independently, or dependently • because a relation may clarify the meaning of a class when we don’t quite know what it is yet. • etc. etc. …

4. So aspects of dynamical behaviour and meaning may be visible in a (static) class diagram. An important association will be reflected in the code somewhere, but not in any naïve way, e.g. inheritance construct, line 27, etc.

5. The simplest association is binary and represented by a line … e.g. <name> Class_A Class_B Normally, we at least annotate the association with a <name>, e.g.

6. studies Student Course name title An arrow can be added to show the orientation or asymmetry of the relation. In this case studies is not symmetric.

7. Actually, this asymmetry is already implicit in the two different class names. We can also make the asymmetry explicit and more interesting by assigning role names For example …

8. Studies subject Student Course participant name title The existence of an association between two classes often indicates some level of coupling, in the sense of related concepts. According to standard practice, coupling should be minimized and cohesion maximized.

9. Excessive coupling often indicates a bad architectural decomposition. Many associations (relations) are binary, but not all! Some are: • ternary relations (3 arguments) • n-ary relations (n arguments)

10. Men Women E.g. a ternary relation can be drawn as: marries Priests and we can add more classes to the diamond.

11. 3.2.6. Multiplicity of Associations In an ER diagram it is common to give the multiplicity of each component of a relation. In OO analysis and design this can help to implement, test and debug the code.

12. The commonest multiplicities are: • One-to-one tax_coding John Smith 760901-1234 Mary Jones 691205-5678 People Tax_codes

13. mother_of • One-to-many M.E. Meinke K. Meinke N. Meinke Women People

14. parent_of • Many-to-many M.E. Meinke K. Meinke K.W. Meinke N. Meinke People People

15. Relation R between classes X and Y is: n-to-… if for every object y :Y there are n distinct objects x1 ,…, xn : X with xiR y for i = 1 ,…, n …-to-m if for every object x :X there are m distinct objects y1 ,…, ym : Y with x R yi for i = 1 ,…, m

16. So e.g. parent_of is 2-to-many. We can add multiplicity constraints to all relations except inheritance, UML multiplicities: • 1 one (can be omitted if 1 to 1) • 1, 2 one or two • n unknown at compile time but bound • m .. n range from m up to n • * greater than or equal to zero • 0 .. * …same … • n .. * greater than or equal to n

17. Examples: one-to-one, one-to-many, many-to-many Rel_1 1 1 Class_A Class_B Rel_2 1 * * * Rel_3

18. 3.2.7. Inner Classes Inner_Class_1 Outer_Class Inner_Class_2 Inner_Class_3

19. 3.2.8. Dependency <<creates>> User Resource User uses resource, but Resource is not an attribute of User class. If Resource is modified then User may have to be modified too. Resource is typically a local variable or argument of some method in User. Can be stereotyped: <<creates>>, <<modifies>>

20. 3.2.9. Navigability User Resource User Resource • Messages flow in direction of the arrow only. • Unmarked means ”unspecified”.

21. 3.2.10. Interfaces • An interface is a contract that specifies a set of methods that must be implemented by a derived class. • Interfaces contain no attributes. • Interfaces achieve ”multiple inheritance” in Java. • There are various possible notations in UML 2.0

22. User f() { role.operation() } Relationship role Implementor InterfaceName implements operation() operation() { /* stuff */ }

23. 3.2.11. Constraints on Associations Vector Container {or} Hashtable member_of Comittee Person {subset} chair_of

24. package MyPackage abstract class MyAbstractClass package MyPackage class MyDerivedClass extends MyAbstractClass { int att; void myFunction( referencedClass r ) { .. } } 3.3. Mapping to Code MyPackage MyAbstractClass MyDerivedClass att: int myFunction()

25. class MyClass { MyAggregatedClass ac; int att; void myFunction( referencedClass r ) { .. } } Aggregation MyClass att: int myFunction() ac MyAggregatedClass

26. class MyDependentClass { void myFunction_1( MyReferencedClass r ) { .. } MyreferencedClass myFunction_2( .. ) { .. } void myFunction_3( .. ) { MyReferencedClass m .. } } Dependence 3 possible implementations! MyClass att: int myFunction_i(), i=1,2,3 dependence arrow MyReferencedClass

27. 3.3. Object Diagrams Introduction. An object diagram represents a specific collection of objects, with specific attribute values and relationships. Therefore it looks like a snapshot of an O-O system at some instant in time.

28. We can draw an object diagram to try to instantiate a particular class diagram. An object diagram O is a valid instance a class diagram C if, and only if, O satisfies all the constraints (numerical and logical) of C. This means we must check (validate) whether O really instantiates C.

29. In fact, even without any class diagrams, we can just draw object diagrams to help us think about how the system might look. So object diagrams are a complement or an alternative to class diagrams. An object diagram is also called an instance diagram.

30. Common uses of object diagrams are: • to illustrate the system state at a high level of abstraction, before and after some action (e.g. instruction execution) i.e. dynamic modeling !! • to analyze the structure of recursive data types (classes) by unfolding a class diagram.

31. 3.3.1. Objects An object is drawn as a rectangle, containing possibly the: • object name, • object type (class), • attribute names, • attribute values. For example …

32. typeless name name : type name : type : type attribute = value nameless = “anonymous object”

33. 3.3.2. Links A link is a concrete instance of an association or relation. A class can be modeled as the set of all its instances. Then an n-ary association (relation) R is modeled as an n-ary relation on these sets.

34. In this case, a link is a specific n-tuple of objects: l = ( o1 , …, on )  R Graphically a link looks like an association, only the context distinguishes the two. Association and role names are copied over to links.

35. Important Notes: • Logical constraints on associations are carried over as the presence or absence of links. 2. Numerical constraints on associations are carried over as numbers of links between endpoints. 3. Inheritance arrows from class diagrams dissappear in object diagrams, (why???)

36. has For example, the following object diagram (below) is a legal instance of the class diagram (above): Biplane Wing 2 Upper_wing : Wing has Sopwith-Camel : Biplane has Lower_wing : Wing

37. But this object diagram is not a valid instance of the previous class diagram: Sopwith-Camel : Biplane Lower_wing : Wing has since it has the wrong number of links (1 instead of 2 on RHS)

38. Ternary and n-ary relations are represented using the diamond as before, e.g. Object_1 : Class_1 Object_2 : Class_2 Object_3 : Class_3

39. Object composition and aggregation use the same symbols as for classes, e.g. Component1 : Class_1 Component2 : Class_2 Object : Class

40. Notice that now we can capture the semantic difference between composition and aggregation. E.g. the following is illegal P1 : Polygon L1 : Line !!!!! Start : Point Myname : Name text = “big” x = 0 y = 0

41. We can use object diagrams to understand recursively defined classes. For example, the class diagram Binary_Tree 0,1 0 .. 2

42. T1 : Binary Tree has the object diagram T2 : Binary Tree T3 : Binary Tree T4 : Binary Tree T5 : Binary Tree

43. 4. Software Architectures Software architecture: structure or structures of the system which comprise software components, externally visible properties of these components, and relationships among them. Not the operational software!

44. Purposes: enables software engineer to … • Analyse effectiveness of design in meeting requirements .. • Because small intellectually graspable model of how components collaborate • So, consider architectural alternatives at a stage when making changes is still easy • Hence, reduces project risks associate with software construction.

45. Lets see a classification of architectures, taken from M. Shaw & D. Garlan, Software Architecture, Prentice Hall, 1996. Note: our list is just a sample!

46. 4.1 Data Flow Data flows between static functional elements which transform it, aka pipeline architecture e.g. compiler C code assembler Machine code parse tree Parse Translate Link & Assemble procedure calls assembler Library

47. 4.2. Model-View-Controller MVC • An architectural model that solves many user interface (UI) problems, e.g. • shared data, • multiple users, • different views of the same data, • updating information across all users, • changes to underlying data, • changes to representation

48. Architecture Goals • Same information capable of being presented in different formats in different windows • Changes made in one view should be immediately reflected in other views • Changes in the UI should be easy to make • Core functionality should be independent of the interface to enable multiple interface styles

49. An abstract object model v1 : ViewA v2 : ViewB access access propagate propagate m : Model access access access access c1 : ControllerA c2 : ControllerB

50. Model: provides central functionality of the application, is aware of its dependent view and controller components • View: each view corresponds to a particular style and format of presentation of information. View retrieves data from model and updates itself when data has been changed in another view. View creates its own controller. • Controller: accepts user input events that trigger operations/changes within the model. These may trigger updates in other views ensuring they are up to date. • See also Observer design pattern.