Embed Size (px)
Citation preview
Information and So&are Technology 1995 37 (I 1) 609-62 I
Domain object identification through events and functions
Danny C C Poo and Shwu-Yi Lee Department of Information Systems and Computer Science, National University of Singapore, Kent Ridge Roud, Singapore 051 I e-mail:dpooQiscs.nus.sg and [email protected]
This paper views a system as being made up of two sections: Domain and Port. It recognizes the need to distinguish the two sections as objects having differing characteristics and roles in a system. Focus is placed on understanding and identifying objects that characterize the Domain section of a system. The identification process differs from contemporary object-oriented development methods in that the three elements of data (static property), operations (dynamic property) and policies of an object are considered as important features of an object definition. The paper suggests that these features be specitied early in the development process. Objects in the Port section and how they are inter-connected with objects in the Domain section will be briefly discussed. A more thorough discussion of Port section objects will be carried out in a separate paper.
Keywords: object Identification, object-oriented domain analysis, information systems specification, event modelling
A system can generally be viewed as a compostion of two sections, as shown in Figure 1. In an object-oriented view,
the two sections would be represented by objects that are
characteristics of the sections. Examples of objects in the Domain section include: customer and account in a banking domain, member and book in a library domain, employees
and pay in a personnel domain, purchase order and supplier
in an inventory domain, etc. The state of these Domain section objects collectively represents the state of the
system. Objects in the Port section, however, are represen- tatives of objects that form the direct interface between external entities and the system as a whole. External entities
are those objects that are outside the boundary of the
system. They could be users of the system or any other systems that have communications with the system under consideration. The arrows in Figure 1 suggest that objects communicate with one another within a system and with
external entities.
In viewing a system in an object-oriented manner, it is important that the appropriate set of objects is identified. This is because an object-oriented system is primarily
composed of objects. Not only should we have a correct set of objects, they should also be identified early in the dev- elopment process, as the poor decisions made in the earlier phase would be reflected in the resultant system archi- tecture’ and this could have adverse effects on the main- tainability of the system at a later stage.
Many practitioners have indicated that object identific-
ation is not a simple task (Meye?, Bryant and Evans’). As Meyer pointed out: ‘the objects are there for the picking but
selecting the correct one is a problematic task’. One approach commonly recommended by most object-oriented
development methods is the use of nouns, verbs and adjec- tives in the requirement description as the source of infor-
mation for identifying objects and their structures (e.g.
Rumbaugh et ~i.~, Goad’, Shlae?, Coleman et al.‘). While
this approach could quickly help developers in defining a set of objects, it has its weaknesses. Firstly, the approach
may yield a number of false positives (de Champeaux’). Secondly, the approach tends to produce incomplete or incorrect representations of domain requirements (Constantine’). Thirdly, a developer may lose focus of the
relevant and essential objects when too many objects are
identified in the beginning. Last, but not least, there is
difficulty in sieving out essential or substantial objects from non-essential ones during the analysis phase (Jacobson”, Aksit”); the problem is compounded when too many
objects are initially identified.
The entity-relationship model is perhaps the most common model recommended by most object-oriented development methods to structure an application system (e.g. Rumbaugh et al.“, Goad’*, and Coleman et a/.‘). Since the first step in system development using the entity-relationship model- ling approach is the identification of objects and their
0950-5849/95/$09.50 8 1995 Elsevier Science B.V. All rights reserved
Domain object identljkation: D C C Poo and S-Y Lee
External
Figure 1 A system structure
relationships with one another, the primary and foremost concern in the first step of the analysis process is the consideration of the static properties of objects. Dynamic behaviour of objects is usually delayed till a much later stage. It is also separately modelled. Since the state of an object is represented by its data attributes and the change in the object’s state is determined by its dynamic behaviour, it is important that the identification process focuses on both the static and dynamic behaviour of objects.
In addition, since objects in the Domain section charac- terize a problem domain, any policies that the user usually defined for a system would be applicable to these objects. Consider as an example objects in a Library domain. The Domain section objects for this domain might be: Library Member and Books. Policies that are binding on these objects might include:
A library member can borrow up to a maximum allowed (also known as the loan quota) for his category of mem- bership: undergraduate student, postgraduate student, academic staff, non-academic staff or external member. If a member is an undergraduate student, he may borrow up to a maximum of six books. A postgraduate student, a non-academic staff member, an academic staff and a corporate member has a loan quota of 10 books, 6 books, 25 books and 6 books respectively. A library book can only be borrowed by a registered member if the book is available, i.e. it is not sent for binding or put on display as a new book, and it is not reserved by another member. The loan period is 28 days for a postgraduate student, an academic staff or a corporate member; otherwise, it is 14 days. A borrowed book has a due date for return. The latter is derived using the following formula: DueDate = TodayDate + LoanPeriod. An item can only be returned if it has earlier been loaned to a member. A returned item is considered to be overdue if it is returned a day later than its due date. If a returned item is overdue, a fine is to be imposed on the member. The fine amount is derived in the following manner: Amount of Fine = Days Overdue*10 (cents); Days Overdue = Return Date - Due Date. When a returned item has an outstanding reservation,
610
print a notification card informing the reserved the item of its availability.
These policies are usually specified by
member who has
users during the requirements specification stage. Unfortunately, most con- temporary methods do not pay much attention to them. There is a need to recognize these policies as they form part of the definition of an object in the domain and their definitions do affect the overall maintainability of a system at a later stage.
In summary, it is essential that the three elements of data (static properties), operations (dynamic properties) and policies be specified during the early stage of the develop- ment cycle.
In this paper, we will discuss how to identify objects in the Domain section, particularly the three elements that characterize an object. We will briefly mention objects in the Port section and how they are inter-connected with objects in the Domain section. A thorough discussion on Port section objects is scheduled for in a separate paper.
Objects in the Domain section
Objects in the Domain section are identified by examining events characterizing a domain and the information requests that a system is required to support. We look to events because a system is basically a model of the hap- penings in the real world and any changes in the real world are reflected in the system via events. Requests for information are derived values of the state of the system or simply a function of the state of the system. The purpose of examining the requests for information from a system is to identify new objects or refine the definition of objects specified earlier through the analysis of events.
List all events and information requests
To facilitate the identification process of objects in the Domain section, we first list all the events and information requests that a system is required to support. An ‘event’ is an instantaneous point in time when something happens. The occurrence of an event changes the states of the objects represented in the system. An event is participated by one or more objects. The participating object that triggers an event is known as the ‘source’ and the event is the triggered event.
An augmented context diagram is used to depict the identified events, information requests and their respective sources (see Figure 2: the domain description for the Library system is given in the Appendix). An arrow in the diagram is either an event trigger or an information request. An event trigger is represented by an arrow with a bold head and the label on the arrow represents the triggered event. An information request is shown as a regular arrow. The label on the arrow represents the information request while the corresponding output is indicated by the label below the arrow. The source of an event or information request is represented by a rectangular box.
Event scripting
For each event represented in a context diagram, an event
Information and Software Technology 1995 Volume 37 Number II
Domain object ident$cation: D C C Poo and S-Y Lee
script
pants,
Member Registration
Book Loan Produce Book
Librarian
Figure 2 An augmented context diagram for a library system
is used to describe the event in terms of its partici- Name: Book Loan (member.2E)
effects, constraints and controls. An example of an Source: Member __ . >. . . .
event script is given in Figure 3. Objects relevant to a
problem domain are identified incrementally from event
scripts.
Meanmg: A member ot the library Dorrows a book. The book is considered as on loan to the member for a period of time. He is expected to return the book when the loan is due.
An event script generally contains the following infor-
mation:
name;
source; meaning; participant set (if any); this includes the set of participant types that can be involved with the event. For instance,
the event script as shown in Figure 3 includes participants
from undergraduate members, postgraduate members,
academic members, non-academic staff members, personal members and corporate members;
pre-event conditions; these are constraints that must be
satisfied before an event can take place;
inputs.
This lists the inputs required for the event to be carried out:
. changes.
This lists the changes in the domain due to the event:
. post-event triggers.
This defines the triggers to other activities after the event is complete:
. Policies.
This section defines the policies that are pertinent to the
event. Note that policies pertaining to an event and to the
participants (or objects) are identified and specified during
event scripting.
Identifying objects from event script
Objects are identified by examining the script. For the event ‘Book Loan’, we note that Member and Book are partici- pants of the event so they are considered as potential object classes. A class represents information on a set of objects that have similar characteristics. When an event occurs, certain information would be required or affected. For
Participant Member
Book
sets: {Undergraduate, Postgraduate, Academic Staff, Non-Academic Staff, Personal Member, Corporate Member}
Pre-Event Constraints: 1. Member has not exceeded his loan quota.
A member has not exceeded his loan quota if loan- count of member is less than his loan quota
Inputs: 1. Member: member identification number 2. Book: accession number, borrow date
Changes: 1. Member borrows the Book. 2. Book is borrowed. 3. Increment loan-count of Member. 4. Book is stamped with a Due-Date. 5. Due-Date = Borrow-Date -1 Loan Period. 6. Borrow-Date is Today’s Date.
Post-Event Trigger: nil
Policies: Member loan-quota
Undergraduate Postgraduate Academic Staff Non-academic Staff External Member
Book loan period Undergraduate, MS-Book Postgraduate, MS-Book Academic Staff, MS-Book Non-academic Staff, MS-Book Personal Member, MS-Book Corporate Member, MS-Book Undergraduate, Recommended-Book Postgraduate, Recommended-Book Academic Staff, Recommended-Book Non-academic Staff, Recommended-Book External Member, Recommended-Book Member, Standards
Figure 3 Event script for ‘Book Loan’
: 6 books : 10 books : 25 books : 6 books : 6 books
: 14 days : 28 days : 28 days : 14 days : 14 days : 28 days
1 day : 2 days : 2 days
1 day 1 day 1 day
Informadon and Sofrware Technology 1995 Volume 37 Number I I 611
Domain object ident$cation: D C C Poo and S-Y Lee
example, the event ‘Book Loan’ would affect information such as: member identification number, loan-count, due-
date, accession number, borrow-date and loan period. Given
these, we are able to define Member as an object class with
the following static properties (data attributes): member identification number and loan-count. Similarly, Book is
also selected as a relevant object class with attributes like accession number, loan period, due-date and borrow-date.
Besides the static properties of objects, we also identify
their dynamic behaviour. For each object’s participation in an event, an operation is defined for the object. For
example, in the event ‘Book Loan’, Member and Book will
each have an operation that reflects their participation in the
event. As the occurrence of an event affects the state of a system, the state of the objects involved in an event will be affected too. The operations identified therefore are state-
changing operations. Such an operation is known as an
action of the object.
Member and Book are examples of domain objects; they are objects whose states are affected by their participation in events. There are also objects whose states are not affected by their participation in events; such objects are
known as supporting objects. To illustrate, consider the
event ‘Membership Registration’. In this event, the librarian
plays a supportive role in facilitating the happening of the event of registering the member. Both Librarian and
Member participate in the event, but it is only the state of
Member that we are concerned with. For instance, only
registered members can borrow books; this would require
the knowledge that a member has registered with the library (or participated in the ‘Membership Registration’ event)
before he could borrow the books. However, we may not
be interested if a librarian had registered any members
prior to any other actions. In other words, the state of the librarian is not significant in so far as the domain description is concerned. We say that Member is a domain object while
the Librarian is a supporting object in the event ‘Member- ship Registration’. The action of the Member in response
to this event could be called ‘Register’.
From the above ‘Book Loan’ event, we were able to identify two object classes, namely Member and Book. The
following are the events extracted from the context diagram
of Figure 2:
Events 1. Member registration 2. Book Loan 3. Reserved Book Loan
4. Return a Book 5. Book Loan Renewal 6. Book Reservation 7. Book Reservation Cancellation 8. Loss of Book 9. Membership termination
Event scripts for the following events are given below:
. Return a Book (Figure 4)
. Book Loan Renewal (Figure 5)
. Loss of Book (Figure 6)
. Membership Termination (Figure 7)
612
Name: Return a Book (member.4E) Source: Member Meaning: A member of the library returns a book he has earlier
borrowed. A fine is imposed on the loan if it is overdue.
Participant Sets: Member {Undergraduate, Postgraduate, Academic Staff,
Non-Academic Staff, Personal Member, Corporate Member}
Book
Pre-Event Constraints Policies: nil
Inputs: Book: accession number, borrow date, loan period Member: member identification number, loan count
Changes: 1. Member returns the Book. 2. Book is returned. 3. Decrement loan-count of Member. 4. Book is stamped with a Return-Date. 5. Due-Date = Borrow-Date + Loan Period. 6. Borrow-Date is Today’s Date.
Post-Event Trigger: 1. If the returned book is overdue then calculate fine
amount. 2. If the book is on reservation then print a notification
card.
Policies: 1. A book is overdue if return date of book is later than
due date. DaysOverdue = ReturnDate - DueDate
Figure 4 Event script for ‘Return a Book’
Object relationships
For each event, we also identify the relationships among the objects that participate in the event. The relationships
among objects are recorded using an Object-Relationship Diagram. Constructing object-relationship diagrams at event level allows the analysts to focus on a smaller subset
of objects that exist in an application domain. This could
reduce the complexity often associated with large numbers
of object classes.
Figure 8 is an object relationship diagram for the event ‘Book Loan’. The relationship between Member and Book
is an association; this relationship is represented by a line
connecting the two object classes. ‘An association is a relationship among instances of two or more classes des-
cribing a group of link with common structures and common semantics’ (Rumbaugh et ~21.~). The association
between Member and Book is derived from the fact that
both objects participate in the same event ‘Book Loan’. Cardinality constraint can be imposed on a relationship
and is expressed as follows (Coleman et ~1.~):
(1) a number, e.g. 5, indicating 5 instances of object; (2) a range, e.g. O..lO, representing a range of object
instances; (3) an asterisk, ‘*‘, denoting zero or more object instances; (4) a plus, ‘ + ‘, denoting one or more object instances.
For each association, link attributes connecting objects in a relationship are identified. A link attribute is the key that uniquely identifies the other object (Rumbaugh et ~1.~). In
Information and Sojiware Technology 1995 Volume 37 Number I1
Domain object ident$cation: L) C C Poo and S-Y Lee
Name: Book Loan Renewal (member.SE) Name: Loss of Book (member.8E) Source: Member Source: Member Meaning: A member of the library renews the loan of a book Meaning: Member lost book borrowed from the library. He is
he has earlier borrowed. A book can only be renewed liable to pay for the cost of the book plus library if it has not been reserved by another member of the administrative and processing charges of S$lO.OO library. for M-S books and S$20.00 for Recommended book.
Participant Sets: Member {Undergraduate, Postgraduate, Academic Staff,
Non-Academic Staff, Personal Member, Corporate Member}
Book
Pre-Event Constraint Policies: 1. Member renews the loan of a book that he has
borrowed earlier. 2. Book must not be reserved by another member.
Input: Member: member identification number Book: accession number, borrow date. return date, loan period.
Changes: I. Member renews the Book. 2. Book loan is renewed. 3. Book is stamped with a Return-Date. 4. Due-Date = Borrow-Date + Loan Period. 5. Borrow-Date is Today’s Date.
Post-Event Trigger: nil
Policies: Member loan-quota
Undergraduate : 6 books Postgraduate : 10 books Academic Staff : 25 books Non-academic Staff : 6 books External Member
Book loan period Undergraduate, MS-Book Postgraduate, MS-Book Academic Staff, MS-Book Non-academic Staff, MS-Book Personal Member, MS-Book Corporate Member, MS-Book Undergraduate, Recommended-Book Postgraduate, Recommended-Book Academic Staff, Recommended-Book Non-academic Staff, Recommended-Book External Member, Recommended-Book Member, Standards
6 books
14 days 28 days 28 days 14 days 14 days 28 days
1 day 2 days 2 days 1 day 1 day 1 day
Figure 5 Event script for ‘Book Loan Renewal’
this example, the link attribute for Member is ‘accession
number’ which identifies the book a member has borrowed. Similarly, the link attribute for Book in the above relation-
ship is ‘member identification number’.
The result of event scripting
Based on the above, a portion of an object’s static and dynamic behaviour is identified. Policy definitions relating to an object with respect to an event are also specified.
Finally, the relationships between objects involved in events are drawn out. The above identification process is repeated for each event in the context diagram. The result is the definition of a set of domain objects and supporting
objects. For the library domain in discussion, the following
domain and supporting objects were identified through
For members who are liable for overdue book fines, such tines will be calculated from the date due to the date when the book was reported lost or, if sub- sequently found, till the date the book is returned.
Participant Sets: Member {Undergraduate, Postgraduate. Academic, Non-
Academic, Corporate Member. Personal member} Book
Pre-Event Constraints: nil
Inputs: Member: member identification number. loan count Book: accession number
Changes: 1. Member lost book. 2. Book is lost by member
Post-Event Trigger: 1. If Book is overdue then compute Overdue Fines. 2. Compute Lost Book Charges.
Constraint Description: nil
Policies: 1. Book is overdue if date Book is reported lost is later
than due date DaysOverdue = Date reported lost - Due Date Date reported lost = Current Date Due Date = Borrow Date + Member.Loan Period
Figure 6 Event script for ‘Loss of Book’
Name: Membership Termination (member.9E) Source: Member Meaning: A member of the library terminates his membership
of the library. All the reservations made by the member must be cancelled, all books borrowed by the member must be returned and all outstanding fines of the member must be paid in full before he can terminate his membership.
Participant Sets: Member {Undergraduate, Postgraduate. Academic. Non-
Academic. Personal Member, Corporate Member} Book
Pre-Event Constraints: I. Member has no outstanding loans.
Input: Member: member identification number, loan count
Changes: 1. Member terminates membership.
Post-Event Trigger: I. Cancel all outstanding reservations made by Member. 2. Compute outstanding fines owed by Member.
Policies: nil
Figure 7 Event script for ‘Membership Termination’
the event scripting process: Member, External Member, Personal Member, Coroporate Member, Internal Member, Postgraduate, Staff, Academic Staff, Non-Academic Staff and Reservations (Domain Objects); Reservation and Loan (Supporting Objects).
fnformarion and Sofrware Technology 1995 Volume 37 Number I I 613
Domain object identijication: D C C Poo and S-Y Lee
Member O..l borrows O..Q
Book
Figure 8 Object-relationship diagram for event ‘Book Loan’
Function scripting
An information request is a function of the state of a system at a particular point in time. An example of an information request is ‘Produce a monthly report on book loans’. For each information request, there is an output produced by the system. By analysing how the output is produced, we could identify firstly, additional attributes for objects prev- iously identified through event scripting, and secondly, new objects that are necessary to fulfil the production of the output which is a function of the state of the system.
A function script is used to describe a function. Functions
and events are different in the sense that an event changes
the state of a system while a function does not. Functions
can be triggered externally in the form of an information request as shown in the context diagram or internally via a post-event trigger. An example of an internally triggered function is the calculation of the fine amount when a book loan is returned late by a member. The function script (known as ‘Calculate Fine Amount’) for this function is shown in Figure 9. This function is an internally triggered function from the event ‘Book Loan’. No new object is identified from this function script. It will, however, be
Name: Calculate Fine Amount Source: 1. member.3E: Book Return
2. member.8E: Loss of Book Meaning: Calculate the amount of fine a member has to pay for
an overdue loan.
Particiuant Sets: Membir
Book
Inputs:
Derivation: 1. 2. 3. 4.
output: 1.
Policies:
{Undergraduate, Postgraduate, Academic Staff, Non-Academic Staff, Personal Member, Corporate Member}
Book: borrow date
Due date = borrow date + loan period DaysOverdue = return date - Due date Return date = today’s date Apply fine calculation
Fine amount.
Fine Calculation Formula: {Undergraduate, Postgraduate, Personal Member,
Corporate Member} :
Derivation: 1.
output: Lost Book Charge slip.
Policies: AmountOfFine = DaysOverdue * Member.RateOfFine Charge Calculation Formula: RateOfFine = 30 IF DaysOverdue <= 10 RateOfFine = 50 IF DaysOverdue > 10.
ChargeAmount = Book.CostPrice + Miscellaneous Charges
{Academic Staff, Non-Academic Staff} : Miscellaneous Charges = S$lO.OO IF Book is M-S Book Miscellaneous Charges = S$20.00 IF Book is Recommended
AmountOfFine = 0. Book
Figure 9 Function script of ‘Calculate fine amount’ Figure 11 Function script for ‘Compute Lost Book Charges’
used to specify the operation (or service) of an object, namely the Member object, since the calculation of fine is pertinent in Member.
The following is a list of functions taken from the context diagram and event scripts:
. Print notification card (function script given in Figure 10).
. Compute Lost Book Charges (function script given in Figure 11).
. Produce Book Loan Statistics Report.
Name: Print Notification Card Source: member.3E: Book Return Meaning: Upon the return of a reserved book, a notification
card will be printed for the first member that has reserved the book.
Particiuant Sets: Membir
Book
Input:
Derivation: 1.
{Undergraduate, Postgraduate, Academic, Non- Academic, Personal Member, Corporate Member}.
Book: accession number
2.
3.
Get the member identification number with the top priority for the reservation with call number of book having accession number. Get information of the member of member identific- ation number: name, mailing address, contact number. Get information of book using the accession number: title, author, editor, edition, publisher, date of publication.
4.
output: Notification
Policies: 1.
Apply latest date of collection.
card
Member with the top priority is the first member who reserves the book.
2.
3.
Latest date of collection for reserved book = current date + reserved period. Reserved Period = 7 days.
Figure 10 Function script for ‘Print Notification Card’
Name: Source: Meaning:
Compute Lost Book Charges member.8E: Loss of Book Member is charged for the book he loaned and lost.
Particiuant Sets: Member
Book
Input:
{Undergraduate, Postgraduate, Academic, Non- Academic, Personal Member, Corporate Member}.
Member: member identification number Book: accession number
Apply charges due.
Information and Software Technology 1995 Volume 37 Number II
. Produce Books Overdue Report (function script given in
Figure 12).
The following is a list of objects identified through
function scripting:
. Notification Card (from function script ‘Print Notification
Card’). . Book Loan Statistics Report (from function script
‘Produce Book Loan Statistics Report’)
. Overdue Books Report (from function script ‘Produce Overdue Books Report’).
Consolidate object definitions
The information gathered on object definitions and their relationships, from event and function scripting, is seg-
mented and needs to be consolidated and refined further.
The refinement process involves the use of abstraction mech-
anisms like generalization-specialization and aggregation.
A consolidated object-relationship diagram (ORD) is then produced. The ORD for the library application is produced
in Figure 13.
Class template
The definitions of object classes are documented using a
class template as shown in Figure 14. The template has the following information:
Name: Source: Meaning:
Participant Member
Book
Input:
Derivation: 1. 2.
output:
Produce Overdue Books report Librarian Information of books on loan to members of the library that are overdue are outputted.
Sets: {Undergraduate, Postgraduate, Academic, Non- Academic, Personal Member, Corporate Member}.
Member: member identification number, name, address, contact number Book: title, accession number, borrow date
Due Date = Borrow Date + Loan Period DaysOverdue = Today’s Date - Due Date
Overdue Books Report
Policies: 1. A book is overdue if return date of book is later
2. than due date. Loan Period: Undergraduate, MS-Book Postgraduate, MS-Book Academic Staff, MS-Book Non-academic Staff, MS-Book Personal Member, MS-Book Corporate Member, MS-Book Undergraduate, Recommended-Book Postgraduate, Recommended-Book Academic Staff, Recommended-Book Non-academic Staff, Recommended-Book External Member, Recommended-Book Member, Standards
: 14 days : 28 days : 28 days : 14 days : 14 days : 28 days
1 day : 2 days : 2 days
1 day 1 day I day
Figure 12 Function script for ‘Produce Overdue Books Report’
Information and Sofiware Technology 1995 Volume 37 Number II
Domain object identification: Ll C C Poo and S-Y Lee
Class Name.
Class Type: Domain, Supporting, Port or Abstractt Class. Names of classes from which attributes and behaviour
are inherited.
Names of classes which inherits its attributes and behaviour.
Attributes identified with the class.
In the case of domain object, actions of the object. Class services and instance services.
Domain policies relating to actions Domain Objects.
Relationship attributes with other objects in the applic- ation domain.
The following are two object class definitions: Member
(Figure 14) and Personal Member (F;igure 15).
Local dynamic behaviour
The local dynamic behaviour of each domain object can be
depicted using a state-transition diagram. A state-transition
relates the present state of a domain object to its possible
future states. By considering the state-transitions, we would more accurately define a domain object since a domain
object does not conduct its activities in a random manner in
the real world. Figure 16 is a state-transition diagram for
Postgraduate Member. It shows the sets of states a Post-
graduate Member can take and the actions that would bring
it to a particular state given a present state. Any actions that do not conform to any of the state-transitions is considered
as invalid. A valid state-transition for a Postgraduate Member is (REGISTERED, borrow, ON-LOAN); that is, if the
member object is in the state REGISTERED and the action is borrow, then the object will proceed to the ON-LOAN
state upon the successful completion of the action. A state-transition diagram records t.he entire life history
of an object. Since an object’s life history consists of a
beginning and an end, we may need to add further actions to the set of actions derived earlier through event scripting.
In this way, we may be able to identify further events that may have been left out earlier. This will ensure a more
complete analysis of the domain.
Objects in the Port section
Objects in the Port section are identified by anafysing how
a system is used. Since the users of a system are outside the
boundary of a system, understanding how a system is used
could help us identify those objects in a system that interface with the environment. To facilitate this, an Object
Interaction Model is constructed. This model shows how
objects interact with one another in the system. The con-
struction of an Object Interaction Model is based on use scenarios. Detail discussion of objects in the Port section is beyond the scope of this paper. However, in this paper we shall show what is a use scenario and the basic principle
used to identifying and structuring objects in the Port section.
tAn Abstract Class is a class that has no direct instances but whose descendant classes have direct instances (Rumbaugh et al.‘, p 61).
615
Domain object ident$cation: D C C Poo and S-Y Lee
Notification L
0..6 ReWVLHions .O..l
0..6 O..M * * O..l * i Member * Book
I External
7 Internal Report
Member Member
I
corporate Member
Legend
Supporting Domain Bisa Generalisation- Object Object component of A Specialisation
Figure 13 Object-relationship diagram for the library system
Use scenarios
A use scenario is a textual description of a behaviourally related sequence of operations in a dialogue that a user has with a system. It is similar to what Jacobson” calls a use case.
For each event in the context diagram, a use scenario is created. A use scenario may contain one or more events or functions. An example of a use scenario in the library domain is: Book Return (see Figure 17).
A use scenario is depicted using an Object Interaction Diagram. While a use scenario describes what needs to be
carried out in terms of the use of the system, an Object
Interaction Diagram enables the spec$cation of object’s responsibilities. Objects are identified by examining the interactions between the external entities and the system. An external entity is anything that is outside the boundary of the system. It could be a human user or any other systems that have interactions with the system. For each interaction, we recognize that there is an object in the
616 Information and Sojiware Technology 1995 Volume 37 Number II
Domain object identification: L) C C Poo and S-Y Lee
Class Name: Member Class Type: Abstract Class Inherited From: nil Inherited By: Internal Member, External Member
Component Of: nil Has Component: nil
Link Attributes: Book --- {Accession number, borrow date}* Reservation --- {Call number, reservation date}*
Attributes: member identification number NRIC number name mailing address contact number loan count reservation count
Actions: Register, Borrow, Borrow with reservation, Return, Renew, Reserve, Cancel, Terminate. Lose
Pi-e-Action Constraints: Borrow: Borrow with Reservation:
Member has not exceeded loan quota Book to be borrowed is reserved for the member
Renew: Reserve:
Book is already on loan to member Member has not exceeded reservation quota
Cancel :
Terminate:
Post-Action Triggers:
Member has already made reservation on book Member has no outstanding loans
Register: Terminate:
output member identification number 1. cancel all outstanding reservations 2. calculate outstanding fines
Derivative Policies: 1. Loan-Quota = 6 2. Reserve-Quota = 6 3.
4.
5.
6.
7.
RateOfFine = S$O.30 IF (DaysOverdue <= 10) IF Book is a non-RBR book RateOfFine = S$OSO IF (DaysOverdue > 10) IF Book is a non-RBR Book Fine = RateOfFine * DaysOverdue IF book is a non-RBR book Fine = 0.50 IF (PeriodOverdue <= 1) and (book is a RBR book) Fine = 0.50 + 1.00 * (PeriodOverdue - 1) IF (PeriodOverdue > 1) and (book is a RBR book) and (loan is not overnight) Fine = 6.00 * DaysOverdue + 1.00 * (PeriodOverdue) IF (loan is overnight) and (book is a RBR book) DaysOverdue = Today’s date - book.Duedate PeriodOverdue = Current Time - book.DueTime
8.
9. 10.
Services: addloan, removeloan, addResv, removeResv. cancelOutstandingResv, hasloans, hasReservations, checkloan, checkReservation, checkReservationCount, checkLoanCount, notify, calculateOverdueFine, listAll, listone, printloan. prinResv, print
Figure 14 Class definition for member
system that would respond to the message (Wirf-Brocks”). By iteratively defining messages from external entities to a system, we identify responsibilites of objects that are involved in the interaction process.
Figure 18 is an Object Interaction Diagram for the use scenario ‘Book Return’. Each participating object in a use
Class Name: Personal member Class Type: Domain Class Inherited From: External member Inherited By: nil
Component Of: Has Component:
Link Attributes:
Attributes:
Actions: nil
Pi-e-Action Constraints: nil
Post-Action Triggers: nil
Derivative Policies: 1. RateOfFine = S$OSO IF (DaysOverdue <= 10) and ((Book
is a non-RBR book) 2. RateOfFine = S$l.OO IF (DaysOverdue > 10) and ((Book
is a non-RBR book)
Services: nil
Figure 15 Class definition for personal member
scenario is represented as a column in the interaction
diagram. All the behaviour of an object in the use scenario is attached to the column representing the object. An arrow
in an interaction diagram is a message sent from one object to another. A message is associated with an operation.
Three types of messages are shown in the diagram:
(1)
(2)
(3)
A regular arrow: an activation of an operation which
could be an action or a service. A service is a data
accessing operation that does not update the state of
objects. An arrow with an empty arrowhead: an activation of a
service prior to the execution of an action. The acti-
vated service is connected with a pre-action condition check. An arrow with a darkened arrowhead: an activation
of a service after the successful completion of an action.
The definition of objects identified earlier through event or function scripting would be refined or enhanced
from information gathered in the object interaction
diagrams. Figure 19 is the revised definition for the
Member class. The revision includes the addition of new services (or operations) identified via the object interaction diagrams.
Conclusion
At the outset of the paper, it was mentioned that the three elements of data, operations and policies of an object
should be defined during the analysis phase of the develop-
ment cycle. This paper recognizes the importance of object identification and argues that it is essential to consider
the three elements during the identification process. The fundamental identification approach as discussed in this paper is based on the recognition of events and infor- mation requests on a system. In a step-by-step manner, the paper discussed how Domain section objects could be incrementally identified and refined. The paper also briefly
Information and Sofiwure Technology 1995 Volume 37 Number II 617
Domain object identification: D C C Poo and S-Y Lee
*loan- actions
End
START RECWl-‘ERJ3D ON-LOAN TERMINATED END
I *loan-actions: borrow, reserve, return, renew, cancel, lose
Figure 16 State-transition diagram for ‘Postgraduate member’
Name: Book Return User: Librarian Meaning: The librarian will carry out the book return when a
person returns one or more books belonging to the library.
Events Triggered: 1. Book Return 2. Book Reservation
Functions Triggered: 1. Calculate Fine Amount 2. Print Notification Card
Description: 1. Librarian request to start a loan return session
Return Window is displayed 2. Repeat {
Librarian enters accession number of Book Validate accession number If ok
Event: Book is returned by Member else display error message
} until Librarian requests to end session
Figure 17 Use scenario ‘Book return’
discussed how use scenarios could be used to assist dev- elopers in identifying objects in the Port section. Through the use of Object Interaction Diagrams the paper discussed how responsibilities could be assigned to objects. In this way, we were able to identify both the static and dynamic properties of objects in the Port section. A more thorough discussion on the Port section objects will be documented in a separate paper.
Acknowledgement
The authors would like to acknowledge the financial support granted by the National University of Singapore (grant RP910689). They are grateful to the University in granting them the opportunity to carry out the work as described in this paper.
References
I Rubin, K S and Goldberg, A ‘Object behaviour analysis’, Comm. ACM Vol 35 No 9 pp (1992) 48-62
2 Meyer, B Object-oriented sofnvare construction Prentice-Hall (1988) 3 Bryant, T and Evans, A ‘00 oversold’, In& and Soft. Technol. Vol
36 No 1 (1994) pp 35-42 4 Rumbaugh, I, Blaka, M, Premerlani, W, Eddy, F and Lbrensen, W
Objea-oriented modefling and design Prentice-Hall (1991) 5 Coad, P and Yourdon, E Object-oriented design Prentice-Hall (1991) 6 Shlaer, S and Mellor, S J Object lifecycles: modelling the world in
states Yourdon Press (1992) 7 Coleman, D, Arnold, P, Bodoff, S, Dollin, C, Gilchrist, H, Hayes, F
and Jeremes, P Object-oriented development: the fusion method Prentice-Hall (1994)
8 de Champeaux, D, Lea, D and Faure, P Object-oriented system development Addison-Wesley (1993)
9 Constantine, L L (chair) ‘From events to objects: the heresy of event- orientation in a world of objects’ Proc. of the Conference of Object- Oriented Programming Languages, Sysrems and Applications Vol 27 No 10 (1992) pp 295-296
10 Jacobson, I Object-oriented sofiare engineering Addison-Wesley (1992)
11 Aksit, M and Bergmans, L ‘Obstacles in object-oriented software development’ Proc. of the Object-Oriented Programming Systems, Languages, and Applications Vol 21 No 10 (1992) pp 341-358
12 Coad, P and Yourdon, E Object-oriented analysis Prentice-Hall (1989)
13 Wirf-Brocks, R Designing object-oriented sofhoore Prentice-Hall
(1990)
Information and Sofrware Technology 199s Volume 37 Number II
Domain object identification: D C C Poo and S-Y Lee
Figure 18 Use scenario and object interaction diagram for ‘Book return’
Information and Sofware Technology I995 Volume 37 Number 11 619
Domain object iderhfication: D C C Poo and S-Y Lee
Class Name: Member Terminate: Member has no outstanding loans Class Type: Abstract Class Inherited From: nil
Post-Action Triggers:
Inherited By: Internal Member, External Member Register: output member identification number Terminate: 1. cancel all outstanding reservations
Component Of: 2. calculate outstanding fines Has Component: Derivative Policies: Link Attributes: 1. Book-Loan --- {Accession number}* 2. Reservation --- {Call number}* 3.
Attributes: identification number NRIC number name mailing address contact number loan count reservation count
4.
5.
6.
7.
Actions: Register, Borrow, Borrow with reservation, Return, Renew, Reserve, Cancel, Terminate, Lose
8.
Pre-Action Constraints: Borrow: Member has not exceeded loan quota
9. 10.
Loan-Quota = 6 Reserve-Quota = 6 RateOfFine = S$O.30 IF (DaysOverdue <= 10) IF Book is a non-RBR book RateOfFine = S$O.50 IF (DaysOverdue > 10) IF Book is a non-RBR Book Fine = RateOfFine * DaysOverdue IF book is a non-RBR book Fine = 0.50 IF (PeriodOverdue <= 1) and (book is a RBR book) Fine = 0.50 + 1.00 * (PeriodOverdue - 1) IF (PeriodOverdue > 1) and (book is a RBR book) and (loan is not overnight) Fine = 6.00 * DaysOverdue + 1.00 * (PeriodOverdue) IF (loan is overnight) and (book is a RBR book) DaysOverdue = Today’s date - book.Duedate PeriodOverdue = Current Time - book.DueTime
Reservation Borrow: Book to be borrowed is reserved for the member
Renew : Book is already on loan to member Reserve: Member has not exceeded reservation quota Cancel: Member has already made reservation on
book
Services: addloan, removeloan, addResv, removeResv, CancelOutstandingResv, hasloans, hasReservations, checkloan, checkReservation, checkReservationCount, checkLoanCount, notify, caIculateOverdueFine, listAll, listone, printloan, prinResv, print, getName, getMemDetails
Figure 19 Revised definition for member class
Appendix A library system
Domain description of library circulation they need to register themselves as a member at the library
application counter.
The following is the domain description of the circulation
department of the Science Library of the National University of Singapore. The domain is used as one of the case studies in the TarTan project. The examples illustrated
in this paper are based on this domain.
The circulation department of the library has a large collection of prints and non-print items for use by its members. The print collection includes the main-shelf
books (henceforth referred to as M-S books) and the recom- mended books (henceforth referred to as RBR books).
Membership in the library can be classified into two main
types: the internal and external membership. Internal members are the undergraduate as well as the postgraduate students and the staff members of the University (this includes both the academic as well as the non-academic staff). External memberships can be further classified into personal memberships and corporate memberships.
To be a member of the library, the individual has to go
through a registration process. For internal members, the registration process is carried out at the point where the member joins the University. As for external members,
A member of the library can carry out the following types of activities pertaining to a book loan: borrowing a book,
returning a loan made earlier, reserving a book that is on loan to another member of the library and renewing a loan
made earlier. Different membership types have different entitlement, as shown in Table A 1.
For instance, a postgraduate student member can borrow up to a maximum of 10 books. For each M-S book bor- rowed, the loan period is 28 days.
A member can make reservations on books that are
already on loan to another borrower. Reservation of books
is by title, that is it is based on call number of the book since there may be more than one copy of the book in the library. Members can reserve books at the library counter by informing the librarian. For any title, the maximum number of reservations that can be made is six and a member can make up to a maximum of six reservations. Reservations are fulfilled on a first-come-first-served basis. A reserv- ation may subsequently be cancelled if the member does not want to borrow the book. When a book which has been reserved is returned to the library, a notification card is sent to the member with the top priority, informing him of the
620 infomarion and Sofhvare Technology 1995 Volume 37 Number I1
Domain object ident$cation: D C C Poo and S-Y Lee
Table Al.
Categories
Loan entitlement
Loan period: M-S Books
RBR books (1 book at a time)
Undergraduate Postgraduate Academic staff Non-academic staff Personal Corporate
6 books 10 books 25 books 6 books 6 books 6 books
14 days 28 days 28 days 14 days 14 days 28 days
2 hours/overnight 2 hours/overnight 2 days 2 hours/overnight 2 hours/overnight 2 hours/overnight
availability of the book. The member can then go to the library counter personally to borrow the book which has
been set aside for him for collection. The reserved book will be set aside for the member for a maximum period of
seven days, after which the member’s reservation is nullified and the member with the second priority will be notified in a similar manner. If there are no other reserv-
ations made on the book, it is then returned to the main
shelves. A member may also renew any loans he had made earlier
provided the books have not been reserved by another member of the library. Renewals of loans have to be made
personally by the member at the library counter.
A member is liable to fines for overdue loans. The fines
scheme for the different categories of membership is shown in Table A2.
(i) Fine policy for M-S books according to membership
types. (ii) Fine policy for RBR books applicable to all the
membership types.
For the hours that the RBR counter is opened: S$O.50 per
book for the first hour or fraction thereof, and S$l.OO for
each subsequent hour or thereof. For hours that the RBR
counter is closed: a fine of S$6.00 for the entire period.
In the case of a lost book, the member must report the loss of the book to the Circulation department. Members
who lose books are liable to pay for the current cost of the books plus a library administrative and processing charge
of S$lO.OO per book for M-S books, or S$20.00 per book
Table AZ.
for RBR books. If the loss of books is reported after the
due-date of the books; the member is also liable to pay for the overdue fines imposed.
The library employs a librarian, a library office and four clerks to ensure the smooth running of the services and facilities that it provides to its members. Their duties are
generally administrative, such as purchasing of books, administrating the issue, return. renewal or reservation of
books, cataloguing and classifying books and shelving
books that are returned or left on the reading tables in the library. The library is opened from 8 a.m. to 9.30 p.m. on
weekdays, 8 a.m. to 7 p.m. on Saturdays and 8 a.m. to
4 p.m. on Sundays. It is closed on public holidays.
User requirements
The library system is expected to provide the following
functionalities:
(1) (2) (3) (4)
(5) (6)
Process membership registration.
Allow members to borrow books.
Allow members to return books.. Allow members to renew a book.
Allow members to reserve a book.
Allow members to cancel a reservation that was made
earlier.
(7) Inform member of the availability of a book that he has reserved earlier.
(8) Process loan overdue fine paymemts.
(9) Process lost book charge payments.
(10) Allow enquiry of overdue loans.
(11) Allow enquiry of loan statistics of books in the library.
Categories
Undergraduate Postgraduate Personal Corporate Academic Staff Non-Academic Staff
Days Overdue <= 10 days
S$O.30 per day per book S$O.30 per day per book SsO.50 per day per book S$ I .OO per day per book no fines imposed no fines imposed
Days Overdue > 10 days
S$O.50 per day per book S$O.50 per day per book S$l.OO per day per book S$2.00 per day per book no fines imposed no fines imposed
Information and .‘jofware Technology 1995 Volume 37 Number II 621
