Relationships

1. Relationships Relationships between objects and between classes

2. What is a relationship • Meaningful connection between elements • Objects standing in isolation is useless • Connection among objects are called links • When objects work together we say that they collaborate • Semantic links between classes are called associations • Dependencies are catch-all relationships

3. Links • Links between objects allow messages to be passed between them – and objects in response will invoke methods • It can be implemented using pointers, references, or by direct inclusion • Links can be unidirectional or bidirectional • Arrowhead indicates navigability

4. Object to object link determines a role • FirstConstruction (Company object) to Jim (Employee/Manager object) with the role Manage • Note that this role can apply to many other objects of type employee • Links with similar properties can be combined (diagrammatically) into a path

5. Association • Link is an instantiation of an association • Associations can have association name, role name, multiplicity, and navigability • Company employs person – employs is an association name • Person plays the role of employee and Company has the role name of employer • Company can employ multiple persons

6. Multiplicity needs to be stated and is implied strongly : every person is employed by some company!! • If not stated then it is undecided • Multiplicity describes business issues and constraints • Reflexive associations (?) • Association roles contributes to attributes in the class – member, array, or collection

7. Dependency • Client depends on the supplier • Usage – client uses the service of supplier to implement its own behavior • Abstraction – supplier is more abstract than client • Permission – supplier grants/limits permission for access • Binding – parameterized templates

8. Usage Types: • As a local parameter in its method • As a parameter to a method • As a return type • Used anywhere in its implemention • Instantiate - client an instance of supplier • As a conduit between entities

9. Abstraction dependencies • Different levels of abstraction • Refine – two elements in same model with refined characteristics • Derive – a derived role from other association • Trace – similar to refine but in different models • Permission dependencies express abilities to access • Access – between packages • Import – name spaces are merged • friend

10. Inheritance • Generalization – with substitutability principle • Subclasses inherit – attributes, operations, relationships and constraints • Overriding – with exact signature • Abstract operations and classes • Only Derived classes used to instantiate objects • Proper levels of inheritance is suggested

11. Polymorphism • Many forms for the same • The exact kind is resolved based on context • Gives us the ability to send pertinent messages without knowing the exact nature of the object • Helps in transparent collections

12. Analysis Packages • Package is a collection – container and owner of model elements • Purpose • Group semantically related things • Define semantic boundary in the model • Provide parallel units for design work • Provide encapsulated name space • Contains use-cases, analysis classes, and use-case realizations for a coherent content of the software

13. Package • Package name, visibility of elements • Minimize visible and protected elements • Package dependencies • Use: client uses a public element in the supplier (default dependency) • Import: name-space merge and potential use of all public elements of supplier • Access: similar to import but name space not merged • Trace: represents historical development from supplier to client.

14. Access and import relationships are not transitive • Packages may be nested inside other packages • Two forms of notation • Access is like block structure scoping • Can have package generalization • Package stereotypes • System: representing the entire system • Subsystem: independent part of the system • Façade: view on another package • Framework: package of fundamental system patterns • Stub: package containing proxys • Typically a set of intrinsically related packages providing a complete set of services become a component!

15. Architecture • All analysis classes are organized into a set of cohesive packages • They are then organized/partitioned into layers • Minimize coupling • Cohesive cluster of classes and inheritance hierarchies suggest a package • 5-10 classes per package

16. What have we covered • Use case modeling and diagrams • Objects and Classes and their depiction • How to find analysis classes and behavior • Relationships – links and association • Dependencies and fundamental dependencies • Review of inheritance and polymorphism • Packages and their relationships