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