An aggregation is a stronger form of relationship where the relationship is between a whole and its parts. The aggregate has an aggregation association to the its constituent parts. A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation. Since aggregation is a special form of association, the use of multiplicity, roles, navigation, etc. is the same as for association. Sometimes, a class may be aggregated with itself. This does not mean that an instance of that class is composed of itself (this would be silly), it means that one instance if the class is an aggregate composed of other instances of the same class. Some situations where aggregation may be appropriate: An object is physically composed of other objects (e.g. car being physically composed of an engine and four wheels). An object is a logical collection of other objects (e.g., a family is a collection of parents and children). An object physically contains other objects (e.g., an airplane physically contains a pilot). In the above example, the relationship from Student to Schedule is modeled as an aggregation because a Schedule is inherently tied to a particular Student. A Schedule outside of the context of a Student makes no sense in a Course Registration System.
Composition is a form of aggregation with strong ownership and coincident lifetimes of the part with the aggregate. The whole “owns” the part and is responsible for the creation and destruction of the part. The part is removed when the whole is removed. The part may be removed (by the whole) before the whole is removed. A solid filled diamond is attached to the end of an association path (on the “whole side”) to indicate composition. In some cases, composition can be identified as early as analysis, but more often it is not until design that such decisions can be made confidently. That is why composition is introduced here rather than in Use-Case Analysis.
Define Domain Model
How to develop Domain Model
Features of Domain Model
Example of Domain Model
Structural model of basic domain concepts and their
It may show:
domain objects or conceptual classes
associations between conceptual classes
Also called conceptual models, domain object
models, and analysis object models.
Identify conceptual classes
Draw them as in a UML domain model
Add associations necessary to record relationship
Add the attributes necessary to fulfill the information
Describes how many instances of one concept can be
associated with one instance of the related concept.
A Student can take up to five Courses.
Student has to be enrolled in at least one course.
Up to 300 students can enroll in a course.
A class should have at least 10 students.
A special form of association that models a whole-part
A strong form of aggregation where components cannot
exist without the aggregate.
The parts cannot survive the whole/aggregate
The children classes inherit the attributes of the parent
Each end of an association is called a role.
Roles may have:
Show who is dominant
Put an arrow on one end of association
We first analyze the stated domain model requirements and then
present the domain model.
The system must be able to keep track of which movie videos have
been bought/rented and by whom.
classes & associations: customer Buys movie video;
customer Rents movie video
For videos bought, the system must record the quantity bought; for
videos rented, the system must record which copy of the video has
been rented and when it is due back.
classes & associations: customer Rents movie video;
–> movie video Has rental copy;
customer Rents rental copy;
Attributes : Buys –> quantity;
Rentalcopy -> copyNumber, dateDue
The system must keep track of overdue rental videos and allow notices
to be sent to customers who have videos overdue.
functional requirement: no new domain model requirements in this
The video shop will have a customer membership option for an annual
fee, which will entitle the member to discounts (10%) on video sales
generalization: Member is a kind of Customer
Member Specializes Customer
Members should be able to make reservations for movie video
rentals either in person at the store, by telephone or via the Web.
◦ classes & associations: Member Reserves Rentalcopy
A member can reserve at most five movie videos at any one time, but
there is no limit on how many movie videos a member or nonmember
can rent at any one time.
◦ constraint: max-card(rental copy, Reserves) = 5
◦ max-card(rental copy, Rents) = *
As an added feature, the video shop would like to allow customers
(either members or nonmembers) to input, via the Web, mini-reviews
(up to 100 words) and a rating (from 1, lowest, to 5, highest) of
movies they have rented.
classes & associations: Customer Provides review IsFor Movie Video
–> Customer Provides Review;
MovieVideo Has Review
attributes: Review –> review text, rating
These reviews should be anonymous if the customer so wishes (i.e.,
the customer can specify whether or not he wants his name to be
made known when other customers browse the reviews).
Attributes: Review –> anonymous
The video shop maintains the following information about all
customers (members or nonmembers): name, address, phone
number, fax number, age, sex, and email address
◦ Attributes : Customer–> name, address,
◦ phoneNumber, faxNumber, age, gender, email;
In addition, members are assigned a membership number by the
video shop when they become members and a password, which
allows them to access the member's only area of the video
shop's web site, including accessing and changing their personal
Member –>memberNumber, password
An employee must be able to enter the basic information about a
movie video (i.e., title, leading actor(s), director, producer, genre,
synopsis, release year, running time, selling price, and rental
attributes: MovieVideo –> title, leadingActor[0..*], director,
producer, genre, synopsis, releaseYear, runningTime,