Requirements Engineering 3:
Static Domain Modelling
Readings: Sommerville Ch 6
Pressman Ch 19, 20
External
(user perspective)
General Modelling Process
Internal
(system perspective)
Dynamic/Behavioural
Use Cases
Analysis
Activity Diagrams Robustness Diagrams
Specification
Sequence Diagrams
& State Diagrams
Design
Static
Domain Model
Class Diagram
Domain Modelling
• Problem domain : area that encompasses real-world
things and concepts related to the problem that the
system is being designed to solve
• Domain modelling : discovering objects (classes) that
represent those things and concepts
– Objects have two fundamental aspects:
• Data
• Operations (methods) that operate on the data. Defer assigning methods
to classes until the design phase
• Work outward from data requirements to build a static
model of the problem domain
2002
0657.314 Software Engineering
Identifying Classes
• Key domain abstractions
– features and facts about the library, which matter in
the system we are designing
• Noun identification technique
– underline nouns and noun phrases in requirements
(ie. identify the words and phrases that denote
things)
– provides a rough list of candidate classes
representing important domain concepts
2002
0657.314 Software Engineering
Noun Identification
• Books and journals The library contains books and journals. It may
have several copies of a given book. Some of the books are for short
term loans only. All other books may be borrowed by any library
member for three weeks. Members of the library can normally borrow
up to six items at a time, but members of staff may borrow up to 12
items at one time. Only members of staff may borrow journals. New
books and journals arrive regularly. The current year’s journals are
sent away to be bound into volumes at the end of each year.
• Borrowing The system must keep track of when books and journals
are borrowed and returned, enforcing the rules described above.
2002
0657.314 Software Engineering
Suitability of nouns…
• Considering candidate classes in the singular form,
discard any which are inappropriate for any reason:
– redundant, where the same class is given more than one
name
– vague, where you can’t tell unambiguously what is meant by
a noun
– an operation, where the noun refers to something which is
done to, by or in the system
– meta-language, where the noun forms part of the way we
define things.
2002
0657.314 Software Engineering
Suitability of nouns…
• What kinds of things are potential classes?
–
–
–
–
Tangible or ‘real-world’ things: book, course, copy
Users: library member, student, nurse
Events: arrival, departure, request
Interactions: meeting, intersection
• Important characteristics to check for
– Retained information – potential classes require information (data)
to be stored about them
– Multiple attributes – only a single attribute? Then this noun should
probably serve as an attribute of some other class
– Common attributes: do all instances of this noun share the same
attributes?
2002
0657.314 Software Engineering
Nouns in the library system…
• Discard:
– library, because it is outside of the scope of our system
– short term loan, because a loan is really an action, the
lending of a book to a user – will reconsider this later
– member of the library, which is redundant: same as library
member
– week, because it’s a measure of time, not a thing
– time, because it’s outside the scope of the system
– system, because it’s part of the meta-language of
requirements description
– rule, for the same reason
2002
0657.314 Software Engineering
Nouns in the library system…
• Left with:
–
–
–
–
–
–
book
journal
copy (of book)
library member
member of staff
volume
• Note, library member and member of staff are also
users of the system
– represented in the system because data on these users will be
maintained
2002
0657.314 Software Engineering
Associations between classes…
• Identify and name real-world relationships or associations
– Static relationship, independent of time
– Clarify understanding of the domain, by describing how objects
work together
• Verb analysis
–
–
–
–
–
2002
A library member borrows/returns a copy
A member of staff borrows/returns a copy
A member of staff borrows/returns a journal
A copy is a copy of a book
A journal belongs to a volume
0657.314 Software Engineering
Associations between classes…
• Denote relationships (dependencies) between classes
• Analysis considers the conceptual point of view
– ‘a LibraryMember borrows a Book’
• Design considers the implementation – class A and class B
are associated if:
– An object of class A sends a message to an object of class B
– An object of class A creates an object of class B
– An object of class A has an attribute whose values are objects of
class B or collections of objects of class B
– An object of class A receives a message with an object of class B
as an argument
2002
0657.314 Software Engineering
Domain Model
(Initial Class Diagram)
LibraryMember
borrows/returns
Copy
is a copy of
borrows/returns
Book
MemberOfStaff
borrows/returns
Journal
belongs to
Volume
More on associations…
1
0..*
Copy
is a copy of
Book
• Multiplicities
– An exact number – simply by writing it
– A range of numbers – using two dots between a
pair of numbers
– An arbitrary, unspecified number – using ‘*’
Updated Domain Model
LibraryMember
1
borrows/returns
0..*
Copy
is a copy of
1..*
0..*
MemberOfStaff
1
Book
borrows/returns
1
1
borrows/returns
0..*
Journal
belongs to
1..*
1
Volume
More on associations…
• Constraints on associations
– Sometimes an association between two classes has
to follow a rule
{ordered}
Bank Teller
serves
1..*
Customer
1
is a copy of
Copy
Book
1..*
{or}
1
Journal
2002
0657.314 Software Engineering
Association Classes
• We might wonder where the due date for a book should be
stored
– Could store in the copy class and reset every time a book is
borrowed
– However, might want to keep historical records of book/journal
borrowing that links library members and books
• The borrows/returns association could have data associated
with it, ie. a due date
– Treat the association as a class, hence the name “association class”
• Association classes are often used if there is a many-tomany association between two classes
2002
0657.314 Software Engineering
Updated Domain Model
LibraryMember
1
0..*
Loan
+dueDate:
Copy 1..*is a copy of
0..*
1
Book
MemberOfStaff 1
1
0..*
Journal 1..* belongs to
1
Loan
+dueDate:
Volume
Generalization
• LibraryMember is a generalization of
MemberOfStaff
– Conceptually every MemberOfStaff is a LibraryMember
– If part of the system works on LibraryMember, it ought to
work on MemberOfStaff too
– On the other hand, there might be things that only make
sense for MemberOfStaff (eg. Borrow journal).
Therefore, MemberOfStaff is a special type of
LibraryMember
2002
0657.314 Software Engineering
Revised Domain Model
LibraryMember 1
0..*
Copy
Loan
+dueDate:
1..*
is a copy of
1
MemberOfStaff
Book
1
0..*
Journal
1..*
belongs to
1
Volume
Attributes
• Describe data contained in an object of a class
– Shown in the second, middle compartment of the class icon
• Don’t show attributes that simply implement associations
– Eg no ‘copies’ attribute in the ‘Book’ class
• Some nouns identified during the domain modelling process
may become attributes of classes rather than classes
themselves
Book
title
author
publisher
isbn
2002
0657.314 Software Engineering
Updated Domain Model
LibraryMember
1
0..*
+name:
+address:
+membership_number:
Copy
+copy_ID:
+on_loan:
Loan
1..*
+dueDate:
is a copy of
MemberOfStaff
+staff_ID:
1
1
Book
0..*
+author:
+title:
+publisher:
+description:
+subject:
+notes:
+series:
Journal
1..*
belongs to
1
Volume
Link requirements with domain classes
Req #
Requirement
Domain class
1.1
The normal loan period for a book is three weeks
Book, Copy, Loan
1.2
The borrowing limit of a library member is six books LibraryMember
1.3
The system shall check that potential book borrowers LibraryMember
are members of the library before issuing books
1.4
The system shall not issue further books to library
members who have reached their borrowing limit
LibraryMember,
Loan
1.5
The system shall provide a facility to record the
books that library members borrow along with their
due dates
LibraryMember,
Loan, Book, Copy
1.6
The system should provide a facility to extend the
loan of a book for a library member if it is not
reserved
LibraryMember,
Loan, Book, Copy