Relationships. Association Aggregation/Composition Multiplicity Dependencies

Transcription

1 1/13/ Association Aggregation/Composition Dependencies 1/13/ Relationships Very few classes stand alone in an OO system Three kinds of class/object relationships are defined to help model abstractions 1. Associations represent structural relationships among objects 2. Generalizations link generalized(parent) classes to their specializations(subclasses ) 3. Dependencies represent using relationships among classes Dependencies and generalizations are onesided. 1/13/

2 Relationships in UML Window generalization open() close() move() Display() handleevent() Event dependency association ConsoleWindow DialogBox Control A relationship is a connection among things 1/13/ Binary Associations indicator goes here association name Class 1 Class 2 role of class 1 role of class 2 Use only if value added Binary =>A relationship between two different classes; Indicated with a line between classes 1/13/ Binary Associations advises advisor is advised by advisor < advises advisor If the direction of the association is not clear, a direction arrow can be added. The arrow does not imply visibility or navigability. 1/13/

3 Unary Association Unary => a relationship between two different objects belonging to the same class prerequisite > is a prerequisite for (a different) 1/13/ Aggregation Aggregation is an association that implies containment Not usually labeled University School containing class a University is comprised of Schools: School of Law, School of Medicine, SICE, etc. This relationship could also be modeled as a binary association 1/13/ Aggregation Involving Two Classes When two or more different classes represent parts of some other whole, each part is involved in a separate aggregation with the whole Nothing is implied about relationship of PartA to PartB Whole Part A Part B 1/13/

4 Composition Composition is a strong from of aggregation. The parts of a composition can be part of at most one composition at a time. If the composition goes away, the parts of that composition may go away, be moved to another composition, or assume responsibility for themselves. It is up to the composite to decide the fate of the parts 1/13/ Composition ATM Display CardReader CashDispenser The composition relationship is denoted with a filled diamond. The relationship shown here means that there is only one ATM object. The Display, CardReader and CashDispenser can be associated with at most one ATM 1/13/ Associations - a Recap An association declares a connection between two classes Aggregation is an association with whole/part semantics. A part may be included in several aggregates Composition is an aggregate with the added condition that a part may be included in at most one composition 1/13/

5 Generalization (inheritance) Illustrated by connecting a subclass to its parent with a line ending in an open triangle touching the base class. Person Person Single inheritance involving one subclass Single inheritance involving two subclasses 1/13/ Each end of an association is called a role. A role may have multiplicity indicates the number of objects of each type that can participate in the association name description describes > 1 * date time Section One object may be associated with 0 or more Section objects. For every Section object, there is only one object. 1/13/ * 3 1..* 4,6,8, or many Exactly 3 1 or more Exactly 4,6,8 or to 30 Types of multiplicities allowed 1/13/

6 registers for * Interpretation: An object of type may be enrolled in 0 or more courses. i.e., there is no limit to the number of courses a student can take. At least 10 students are needed for a course offering, and no more than 30 students can sign up for one course. 1/13/ has a 1 1 Transcript works for 1..* 1 Department chairs Department Grad GTA * 0..2 Department 1/13/ prerequisite > 0..* 0..* A is prerequisite for many s, and a can have 0 or more prerequisites PlanOfStudy * * A student s Plan of Study is comprised of many s; any given can be included in many different students Plans of Study 1/13/

7 Dependencies An association represents a permanent link between two objects. i.e. the link exists during the whole lives of the objects, although the instances that are connected may change over time. A parameter reference, or the creation of an object, does not imply an association; these are modeled with dependencies. Dependencies are between classes or packages. They show that one class uses another class as an argument in the signature of an operation. String Buffer String A String Buffer has several routines that take a String as a parameter. If the class String changed, String Buffer would have to be analyzed for possible changes also. 1/13/ Dependencies A dependency exists between two classes or packages if changes to the definition of one may cause changes to the other. Examples of dependencies between classes: one class sends a message to another one class has another as part of its data one class has another class as a parameter to an operation If a class changes its interface, any message it sends may no longer be valid. A dependency between two packages exists if a dependency exists between any two classes in the packages 1/13/ Dependencies FilmClip name playon(c:channel) start() stop() reset() Channel Create a dependency pointing from the class with the operation to the class used as a parameter in the operation. 1/13/

8 Dependencies Schedule add (c: ) remove (c: ) <<friend>> Iterator This dependency models a C++ idiom: friend. The stereotype Specifies that this is not a plain dependency, but represents a Friend. 1/13/ Dependencies Dependencies may also be used to show that a class relies on an interface. InputStream <<interface>> DataInput OrderReader generalization dependency DataInputStream realization (implements) Interfaces and Abstract Class: example from Java The dependency between the OrderReaderand DataInput means that if the DataInput interface changes, the OrderReadermay also have to change. 1/13/ Relationships Recap In an association, classes are peers of one another. Both rely on the other in some way and you can navigate in either direction. In a generalization, the parent knows nothing about its children In a dependency, one class depends on the other, but the class depended on has no knowledge of the dependent class. 1/13/

9 Modeling Hints When you model relationships in UML Use dependencies only when the relationship is not structural Use generalization when you have is-a-kind-of relationship; replace multiple inheritance with aggregation Keep generalizations balanced (not too deep or too wide) Use associations where there are structural relationships among objects 1/13/