1 Task description and demarcation of the task *

2 Class diagram *

2.1 Classes and Objects *

2.2 Structures *

2.3 Attributes *

2.4 Methods *

3 Sequence diagram *

4 From analysis to design *

References *

‘Make a class and sequence diagram for a library session using an UML-tool (Rational Rose)’.

The task consists of two major characteristics of modeling something using an object-oriented modeling approach. First there has to be engineered a static aspect of a system – the class diagram – and then a more dynamic aspect of the system – a sequence of operations – expressed in a sequence diagram. In this case both diagrams are part of the software development stage analysis. At a later stage – during the design phase – the results of the analysis stage can be used to develop it to a design model, which later on leads to the final software system.

Although the goal of using an object-oriented modeling methodology, which basically consist of a modeling language and a process model (description of the successive stages which lead to the final system model), is to expound a consistent and complete model of a software system, this work will concentrate only on two views of this whole model – a class view and a view of the dynamics in that model. This is possible because UML and the tool Rational Rose allow an engineer to develop only parts of the whole model, which he thinks are most important to get an impression of the system, which has to be developed.

Because UML does not include a process model one is free to use his own process model. For developing the class diagram I will follow the approach of Coad/Yourdon [Coad91, p. 34]. They suggest to divide your work into five major steps:

1. (Subject layer)
2. Class & Object layer
3. Structure layer (finding relationships and dependencies between the classes)
4. Attribute layer
5. Service layer

Although UML also supports the idea of subjects (e.g. with packages) there is no need to use this kind of concept in this case, because the engineered model will be quite simple. Coad/Yourdon don’t want to give a suggestion for the order of their major steps (mostly to give an engineer the possibility to jump back and forth during the modeling). So in this reader I will use the above order, excluding the first step.

The second step, after drawing the class diagram, will be to draw a sequence diagram for a special use case. I chose to draw this diagram for the use case: ‘Creation of a loan’:

Let us first take a look at the description of a librarian. ‘A librarian: One who has the care of a library and its contents, selecting the books, documents and non-book materials which comprise its stock, and provide information and loan services to meet the needs of its users.’ [Harr77, p. 486] This leads us to the first basic classes and objects for modeling a library:

• Librarian (or library operator)
• Book
• User
• Loan

If you put it in one sentence: ‘A user loans books from the librarians desk.’ First let us take these four words as classes. Furthermore a library should also accept reservations. And it should also offer the possibility to loan books from other libraries. This adds following basic classes to the list of classes:

• Reservation
• Foreign library

Or as first class diagram:

Furthermore one has to distinguish between a certain type of book (= class Book) and its ‘materialization’ (= class Entity), e.g. there can be a book title, like ‘C++ Primer’ which is not only once but several times available.

Each book has of course an author. But authors are not necessarily a part of a book. They are something which has its own life. So, e.g. Stanley B. Lippman has written more books than just this ‘C++ primer’.

Another issue is the classification of books. They are classified in an hierarchy of subjects. Which supports the idea of making subject a own class. A hierarchy of subjects can exists without even one book – although books are always related to a certain subject – the subject itself is not an integrative part of a book.

Furthermore I want to introduce a new class ‘Supervising Agent’, which has the responsibility to manage all loans, reservations, users and books. E.g. this class is responsible for checking every day, whether every book is returned on time and so on.

This leads to four more classes:

• Entity
• Author
• Subject
• Supervising Agent

The corresponding class diagram looks like this:

2.2.1 Hierarchies

Let us take every class of the preliminary class diagram and check it, whether it is part of a hierarchy or not.

A user as well as a library operator are both persons with their own special properties. But they also have some similarities (e.g. both have the property name). So let us add an additional super class:

• Person

That users of the library can only loan books is a little bit to simplified. There are a lot more kinds of publications, which users can lend. Books are only a part of it. There are also thesisses, journals, periodicals, CD-Roms and access to databases. The two latter ones are electronic publications and first ones are traditional publications.

This leads to following hierarchy for publications:

Because there is a big difference between reservations, loans and entities from our own library and from a foreign library one has to distinguish between e.g. our own loans and loans from foreign libraries. This leads to 6 new classes, which are all subclasses of their already existing super classes:

• Loans of our own library
• Loans from another library
• Reservations of our own library
• Reservations from another library
• Entity of our own library
• Entity from another library

This leads to following preliminary class diagram:

For aggregations Coad/Yourdon consider three variations [Coad91 p. 93]:

• Assembly – Parts
• Container – Contents
• Collection – Members

Keeping that in mind there are six aggregations in the library example:

• Author as part of Publication
• Subject as part of Publication
• Subject as part of itself (recursion)
• OwnEntity as part of LoanOwnLibrary
• ForeignEntity as part of LoanForeignLibrary
• User as part of Loan
• User as part of Reservation

Each of these Aggregations has a certain type of cardinality. E.g. the aggregation from Author to Publication has on both sides the cardinality 0...*, because an author could possibly write more than one book and a book could be written by more than one author.

An association is something needed, when one object needs to know about another to fulfill its responsibilities. This leads to following associations:

• Between ForeignLibrary and ReservationForeignLibrary
• Between ForeignLibrary and ForeignEnity
• Between Publication and OwnEntity
• Between SupervisingAgent and Reservation
• Between SupervisingAgent and Loan
• Between SupervisingAgent and Entity
• Between SupervisingAgent and User
• Between SupervisingAgent and LibraryOperator

Objects of the classes on the right have only one connection to the other class, but in the opposite direction an object on the left can have multiple connections to objects on the right.

The class diagram including all aggregations and association looks like this:

Attributes describe the state of an object. They change over time. So when looking for attributes one should follow the question: ‘How can the state of that object be described?’ (For more information on how to find attributes see [Coad91 p. 121]). So, e.g. for the class Publication there are four basic attributes:

• ISBN : String
• Date of acquisition : Date
• Date of publication : Date
• Title : String

Each of these attributes needs a certain data type. Furthermore there are properties of classes, which are not directly stored in the class. So, e.g. is the property author, which is for sure a property of each publication, not stored in the class publication itself, but available via the aggregation to the class author.

The class diagram including attributes looks like this:

A method is a specific behavior of an object. There are methods, which are changing the state of an object and methods which do not change the state of an object (accessor methods). Regarding to the ideas of information hiding and reuseability each publicly accessible attribute should have its accessor methods for getting and setting the value of itself (e.g. getAttribute() and setAttribute()). When modeling the library example I left these out, because they would only bring unnecessary confusion to the reader of a model. Furthermore we should keep in mind, that putting accessor method in a model is a clear design decision and we are still in the analysis stage.

So, e.g. the class Person has only one method sendEmail(). This method can be called by every class, which knows about the existence of a certain Person object. This method is also available in subclasses of these class.

The complete class diagram looks like this:

For drawing a sequence diagram I chose the use case ‘Creation of loan’.

This use case is owned by a library operator, who is confronted with the situation, that a user is coming to his desk and wants to lend a book. Therefore the library operator is asking for the user number of that particular user and enters it into the software system. It is a design decision, whether we use a barcode scanner for that or not. After that the library operator gets first the user object, which he can ask for the user data, e.g. to check whether everything is okay with that user. After that the library operator has to enter a ID for the entity, which is to be loaned, and by that ID the supervising agent delivers the entity object. With knowledge about the user object and the entity object the library operator is able to create a new loan. This loan will be registered to the supervising agent, which handles the checking of the loaning period.

The corresponding sequence diagram looks like this:

Because the stage of analysis is free of decisions regarding the programming language and the usage of already existing components. These decisions have to be made during the design phase.

One point I want to highlight here is the possibility to use an object-oriented database for storing the huge amount of objects, which apparently is created over time. E.g. there is one object for every entity (book, journal, …) in the library. This means, that there has to be an efficient and fast system for handling these objects.

An object-oriented database is optimized for fast storage and look up of objects. Furthermore it offers services like recovery, access control (multiple users with different rights) and guarantees semantic integrity. Basically the class SupervisingAgent is handling the storage and the retrieval of persistent objects (e.g. like Entity or Loan). So, hopefully it is not that difficult to transfer this class into an adaptor to an object-oriented database.

[Coad91] Coad, P. and Yourdon, E., 1991. Object-oriented Analysis. Englewood Cliffs, Prentice Hall.

[Harr77] Harrod, L.M. 1977. The Librarians Glossary. London, Andre Deutsch.