1 / 16

Relationships

Relationships. Relationships between objects and between classes. 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

scarlet-christensen
Download Presentation

Relationships

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related