"Object Oriented ": Software Engineering

“Object Oriented Software Engineering”
SE-201
Lecture 9
“ Modeling with Classes”
By: Sajid Ullah

Lecturer, Institute of Computing
KUST
Agenda
• Analyzing and validating associations
• Association classes
• Reﬂexive associations
• Object diagrams
Course: Object Oriented Software Engineering -Instructor: Mr. Sajid Ullah Lecturer of computing KUST-Email: Sajid.fast@gmail.com 2
Analyzing and validating associations
• It is very common to make errors when creating associations .
• Most importantly, you should always ask yourself whether a less restrictive multiplicity could also makes
sense in some circumstances.
• In general, you should err on the side of being less restrictive so as to increase the flexibility of the
system.
• On the other hand, using ‘many’, as opposed to ‘one’, when it is not justified, will increase a system’s
complexity and reduce its efficiency.
• The following points discuss three of the most common patterns of multiplicity.
■ One-to-many.
• A company has many employees.
• You might argue that this is incorrect, since somebody might moonlight, working for several companies.
• Finally, since it is not possible to be an employee unless you work for a company, the multiplicity at the
Company end is correctly shown to be exactly one, not optional .
■ Many-to-many.
• An administrative assistant can work for many managers.
• It is also the case that some managers might have zero assistants.
• An interesting question arises when you consider whether it is possible for an assistant to have, perhaps
temporarily, zero managers.
■ One-to-one.
• For each company, there is exactly one board of directors.
• Also, a board is the board of only one company.
• A company must always have a board, and a board must always be of some company.
• The most common multiplicity pattern is one-to-many.
• The next most common is many-to-many.
• One-to-one associations are less common.
Association classes
• In some circumstances, an attribute that concerns two associated classes cannot be placed in either of the
classes.
• For example, imagine the association shown in Figure 3
• In which class should the student’s grade be put?
Association classes
• As shown in the left half of Figure 4, an association class is connected to its association by a dashed line.
Fig 4:
Reﬂexive associations
• It is possible for an association to connect a class to itself.
• Two examples of this are found in Figure 5.
Fig.5:
Links as instances of associations
• In the same way that we say an object is an instance of a class, we say that a link is an instance of an
association.
• Each link connects two objects – an instance of each of the two classes involved in the association.
• For example, there will be one link of the Passenger-to-Booking association for every Booking.
Directionality in associations
• Associations and links are by default bi-directional.
• That is, if a Driver object is linked to a Car object, then the Car is also implicitly linked to that Driver.
• It is possible to limit the navigability of an association’s links by adding an arrow at one end.
• For example, Figure below shows two classes that might exist in a calendar application.
Object diagrams
• Class diagrams tell us what classes will exist in a given system, but they are quite abstract.
• An object diagram shows an example configuration of objects and links that may exist at a particular point
during execution of a program.
• Objects are shown as rectangles, just like classes; the difference is that the name of the class is underlined and
preceded by a colon,:Employee, for example.
• You can also give a name to each instance before the colon, as in Pat:Employee, or even omit the class name
entirely if it is clear from the context, such as Pat:.
Object diagrams
Associations versus generalizations in the
context of object diagrams
• It is a common mistake for beginners to think of generalizations as special associations.
• The differences between the two concepts are profound.
 An association describes a relationship that will exist between instances at runtime.
 A generalization describes a relationship between classes in a class diagram.
Associations versus generalizations in the
context of object diagrams
• When you show an object diagram generated by an association, you show instances of both classes joined by
that association.
• On the other hand, when you show an object diagram generated by an inheritance hierarchy, you show a
single instance of one of its concrete classes.
• That single instance will contain values of the attributes defined in its class, as well as those attributes
inherited from superclasses.
Thanks

"Object Oriented ": Software Engineering

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

"Object Oriented ": Software Engineering

Caricato da

Copyright:

Formati disponibili

“Object Oriented Software Engineering”

By: Sajid Ullah

• A company has many employees.

• An administrative assistant can work for many managers.

• For each company, there is exactly one board of directors.

• Also, a board is the board of only one company.

• The most common multiplicity pattern is one-to-many.

• The next most common is many-to-many.

• One-to-one associations are less common.

• In which class should the student’s grade be put?

 An association describes a relationship that will exist between instances at runtime.

 A generalization describes a relationship between classes in a class diagram.

Potrebbero piacerti anche