Software Architecture and Design Patterns (17IS72)

Module-2
Analysing a System
2.1 Overview of the Analysis Phase

The major goal of this phase is to address this basic question: what should the system do?
Requirements are often simple and any clarifications can be had via questions in the classroom,
e- mail messages, etc.
However, as in the case of the classroom assignment, there are still two parties: the user community,
which needs some system to be built and the development people, who are assigned to do the work.

The process could be split into three activities:

1. Gather the requirements: this involves interviews of the user community, reading of any available
documentation, etc.
2. Precisely document the functionality required of the system.
3. Develop a conceptual model of the system, listing the conceptual classes and their relationships.

It is not always the case that these activities occur in the order listed.

2.2 Stage 1: Gathering the Requirements

The purpose of requirements analysis is to define what the new system should do. Since the system
will be built based on the information garnered in this step, any errors made in this stage will result
in the implementation of a wrong system. Once the system is implemented, it is expensive to modify
it to overcome the mistakes introduced in the analysis stage.

Imagine the scenario when you are asked to construct software for an application. The client may
not always be clear in his/her mind as to what should be constructed.

First reason for this is that it is difficult to imagine the workings of a system that is not yet built.
Second reason Incompleteness and errors in specifications can also occur because the client does
not have the technical skills to fully realize what technology can and cannot deliver
Third reason for omissions is that it is all too common to have a client who knows the system
very well and consequently either assumes a lot of knowledge on the part of the analyst or simply
skips over the ‘obvious details’.

Requirements can be classified into two categories:

• Functional requirements: These describe the interaction between the system and its users, and
between the system and any other systems, which may interact with the system by supplying or
receiving data.
•
Non-functional requirements: Any requirement that does not fall in the above category is a non-
functional requirement. Such requirements include response time, usability and accuracy.
Sometimes, there may be considerations that place restrictions on system development; these may
include the use of specific hardware and software and budget and time constraints.

7th Semester, Department of ISE Page : 2

 Software Architecture and Design Patterns (17IS72)

2.2.1 Case Study Introduction

Let us proceed under the assumption that developers of our library system have available to them a
document that describes how the business is conducted. This functionality is described as a list of
what are commonly called business processes.

The business processes of the library system are listed below.

1 Add a member
2 Add books
3 Issue books
4 Return books\
5 Remove books
6 Place a hold on a book
7 Remove a hold on a book
8 Process Holds: Find the first member who has a hold on a book
9 Renew books
10 Print out a member’s transactions
11 Store data on disk
12 Retrieve data from disk
13 Exit

In addition, the system must support three other requirements that are not directly related to the
workings of a library, but, nonetheless, are essential.
• A command to save the data on a long-term basis.
• A command to load data from a long-term storage device.
• A command to quit the application. At this time, the system must ask the user if data is to be saved
before termination.
 A real library would have to perform additional operations like generating reports of various
kinds, impose fines for late returns, etc.
 Many libraries also allow users to check out books themselves without approaching a clerk.
 Whatever the case may be, the analysts need to learn the existing system and the
requirements. As mentioned earlier, they achieve this through interviews, surveys, and study.

2.3 Functional Requirements Specification

The requirements specification document serves as a contract between the users and the developers.
we attempt to create a precise documentation of the requirements, we will discover errors and omissions.
An accepted way of accomplishing this task is the use case analysis which we study now.

Use Case Analysis: It is a powerful technique that describes the kind of functionality that a user expects
from the system.
 It is essentially a narrative describing the sequence of events (actions) of an external agent (actor)
using the system to complete a process.

 It is a powerful technique that describes the kind of functionality that a user expects from the
system.
 Use cases have two or more parties: agents who interact with the system and the system itself.

7th Semester, Department of ISE Page : 3

Software Architecture and Design Patterns (17IS72)
In our simple library system, the members do not use the system directly. Instead, they get services
via the library staff.

To initiate this process, we need to get a feel for how the system will interact with the end-user. We
assume that some kind of a user-interface is required, so that when the system is started, it provides a
menu with the following choices:
1. Add a member
2. Add books
3. Issue books
4. Return books
5. Remove books
6. Place a hold on a book
7. Remove a hold on a book
8. Process Holds: Find the first member who has a hold on a book
9. Renew books
10. Print out a member’s transactions
11. Store data on disk
12. Retrieve data from disk
13. Exit

Use case diagram for the library system

7th Semester, Department of ISE Page : 4

 Software Architecture and Design Patterns (17IS72)

Use case for registering a user

Steps:
1 Member will give the details of name, address, phone number to the clerk
2 Clerk process the request through the system
3 System asks the details of the customer to be registered.
4 Clerk enters the necessary information of the member into the system.
5 System check the details of the member and if the member is a valid person, then generates member
identification number and display the necessary information at the output
6 Clerk provides the identification number to the user.

7th Semester, Department of ISE Page : 5

 Software Architecture and Design Patterns (17IS72)

Use case for adding books

Actions performed by the actor Responses from the system

1. Library receives a shipment of
books from the publisher
2. The clerk issues a request to
add a new book
3. The system asks for the
identifier, title, and author name
of the book
4. The clerk generates the unique
identifier, enters the identifier,
title, and author name of a book
5. The system attempts to enter
the information in the catalog
and echoes to the clerk the title,
author name, and id of the book.
It then asks if the clerk wants to
enter information about another
book
6. The clerk answers in the
affirmative or in the negative
7. If the answer is in the
affirmative, the system goes to
Step 3. Otherwise, it exits

Steps:
1 Library receives the information about the books shipped from the publisher.
2 Clerk receives a request to process the addition of books to the catalog.
3 System asks the details of the identifier, title, and author name of the book to be added.
4 Clerk generates the necessary information of the book to be added into the system.
5 System adds the details of the book and displays the necessary information of the book at the output
and asks for any more books to be added.
6 If clerk replies affirmative, then same procedure is followed for the next set of books to be added.
Otherwise system quits the application.

7th Semester, Department of ISE Page : 6

 Software Architecture and Design Patterns (17IS72)

Use case for issuing books

Steps:
1 Member gives the set of books with the member identification number to the clerk at the
checkout counter and requests clerk to check out the books.
2 Clerk receives a request to check out the books and start checking in the system.
3 System asks the details of the user ID.
4 Clerk enters the user ID
5 System asks the details of the book ID.
6 Clerk enters the ID of the book to be checked out.
7 i) System checks whether the member possesses the book and generates a due date.
ii) System displays the book title, due date and asks if there is any more books to be processed
8 Clerk stamps due date on the book say yes, if there are books to be checked out. Otherwise no
when there are no books to be processed.
9 If yes, system continues to process from step 5 and asks only for book ID since customer ID is
same, otherwise system exits.
10 Customer collects the books and leave the checkout counter

7th Semester, Department of ISE Page : 7

 Software Architecture and Design Patterns (17IS72)

Steps:

1 Member gives the set of books with the member identification number to the clerk at the checkout
counter and requests clerk to check out the books.
2 Clerk receives a request to check out the books and start checking in the system.
3 System asks the details of the user ID.
4 Clerk enters the user ID
5 System asks the details of the book ID.
6 Clerk enters the ID of the book to be checked out.
7 i) System checks whether the member is a valid person or not and then records the member has a
possession on the book and generates a due date based on the result of Rule 1.
ii) System displays the book title and due date.
iii) The system displays error message, if the Rule 2 is not satisfied and asks if there is any more
books to be processed.
8 i) Clerk stamps due date on the book and take the print out of the transactions, if the user is
requesting for print out.
ii) Clerk says yes, if there are books to be checked out. Otherwise no when there are no books to be
processed.
9 If yes, system continues to process from step 5 and asks only for book ID since customer ID is same,
otherwise system exits.
10 Customer collects the books and leave the checkout counter

7th Semester, Department of ISE Page : 8

 Software Architecture and Design Patterns (17IS72)

Use case Return Book

Steps:

1. Member gives the set of books to be returned to the clerk at the checkout counter.
2. On receiving the request, clerk process the return books request in the system.
3. System asks the details of the book ID.
4. Clerk enters the ID of the book to be returned.
5. i) System checks whether the book is valid or not and then records that book is returned.
ii) System informs the clerk about the deadline of the book to be returned and asks clerk that if any
more books are to be returned.
6. i) Clerk says yes, if there are books to be returned, Otherwise no when there are no books to
be returned.
ii) Clerk checks the deadline of the book to be returned based on Rule 5.
7. If yes, system continues to process from step 3, otherwise system exits.

7th Semester, Department of ISE Page : 9

 Software Architecture and Design Patterns (17IS72)

Use case Removing Books

Steps:

1 Librarian gives the list of books to be deleted for the clerk.

2 On receiving the list, the clerk starts processing the deletion of books.
3 The system asks ID of the book.
4 The clerk enters the ID of the book.
5 i) The system checks whether the book can be removed as per Rule 3 by verifying the check out and
deadline of the book.
ii) If the book ID is valid, the system removes the book ID from the library’s catalog.
iii) The system displays the success of the deletion operation to the clerk.
iv) System asks the clerk that, there are any more books are to be deleted.
6 The clerk answers yes, if there are books to be processed or no, when there are no books to be
processed.
7 If the answer is yes, then the system goes to Step 3 Otherwise, it exits

7th Semester, Department of ISE Page : 10

 Software Architecture and Design Patterns (17IS72)
Use case Member Transactions

Steps:

1 The clerk receives a request from the user to give member transactions
2 The system asks for the user ID of the member and the date for which the transactions are required.
3 The clerk enters the ID of the user and the date of the transactions required
4 If the ID is valid, the system outputs information about all transactions completed by the user on the
given date along with the details of book borrowed, book returned, hold placed and the title of the
book.
5 Clerk prints out the transactions and hands them to the user

7th Semester, Department of ISE Page : 11

 Software Architecture and Design Patterns (17IS72)
Use case Place a Hold and Remove a Hold

Steps:

1 On receiving the request, clerk start processing to place a hold

2 The system asks details of the book such as book ID, the ID of the member and the duration of the
hold
3 The clerk enters all the necessary details.
4 i) The system checks that the user and book ID's whether it is valid or not as per Rule 6
ii) If Rule 6 is satisfied, then the system records that the user has a hold on the book and displays
that; otherwise, it outputs an appropriate error message

Steps:

1 On receiving the request, clerk start processing to remove a hold

2 The system asks details of the book such as book’s ID and the ID of the member
3 The clerk enters the ID of the user and ID of the book
4 The system removes the hold that the user has on the book, prints a confirmation and exits

7th Semester, Department of ISE Page : 12

 Software Architecture and Design Patterns (17IS72)

Use case Process Holds

Steps:

1 On receiving the request, clerk start processing to place a hold as per Rule 5 by notifying the
member who crosses the deadline.
2 The system asks book ID
3 The clerk enters book ID
4 i) The system checks for the hold whether it is expired or not
ii) If yes, the system records that there is no hold and ask for next books to be processed
5 i) If there is no hold, the book is then kept back to its designated location in the library and no
notification generated.
ii) Clerk replies the system yes or no for the next books to be processed
6 If the answer is yes, the system goes to Step 2; otherwise it exits

7th Semester, Department of ISE Page : 13

 Software Architecture and Design Patterns (17IS72)

Use case Renew Books

Steps:

1 Member requests for the renew of the books

2 On receiving the request, clerk start processing the renew of books in the system
3 System asks for the member’s ID
4 The clerk enters the member ID into the system
5 i) System checks the record to find out which book is availed by the member
ii) If there are none, the system prints an appropriate message and exits; otherwise it moves to Step 6
6 The system displays the title of the next book to be renewed
7 The clerk replies yes or no
8 i) The system renews the book based on Rule 4 by checking holds on the book and reports the result.
ii) If the system has displayed all checked-out books, it reports that and exits; otherwise the system
goes to Step 6

7th Semester, Department of ISE Page : 14

 Software Architecture and Design Patterns (17IS72)

Different Rules for the Library System

Rule number Rule
Rule 1 Due-date for a book is one month from the date of
issue
Rule 2 All books are issuable
Rule 3 A book is removable if it is not checked out and if it
has no holds
Rule 4 A book is renewable if it has no holds on it
Rule 5 When a book with a hold is returned, the appropriate
member will be notified
Rule 6 Holds can be placed only on books that are currently
checked out

Guidelines to write use cases

 A use case must provide something of value to an actor or to the business.

 Use case should be functionally cohesive, i.e., they encapsulate a single service that the system
provides.
 Use case should be temporally cohesive. This notion applies to the time frame over which the use
case occurs.
 If a system has multiple actors, each actor must be involved in at least one, and typically several use
cases.
 The model that we construct is a set of use cases.
 Use cases are written from the point of view of the actor.
 A use case describes a scenario.
 Use cases change over the course of system analysis.

Defining Conceptual Classes and Relationships

The last major step in the analysis phase involves the determination of the conceptual classes and the
establishment of their relationships. Example, in the library system, some of the major conceptual classes
include members and books. Members borrow books, which establish a relationship between them.

1 Design facilitation: Via use case analysis, we determine the functional requirement of the system.
Obviously, the design stage must determine how to implement the functionality. For this, the designers
should be in a position to determine the classes that need to be defined, the objects to be created, and
how the objects interact. This is better facilitated if the analysis phase classifies the entities in the
application and determines their relationships.

2 Added knowledge: The use cases do not completely specify the system. Some of these missing details
can be filled in by the class diagram.

3 Error reduction: In carrying out this step, the analysts are forced to look at the system more carefully.
The result can be shown to the client who can verify its correctness.

4 Useful documentation: The classes and relationships provide a quick introduction to the system for
someone who wants to learn it. Such people can join the project to carry out the design or
implementation or subsequent maintenance of the system.

7th Semester, Department of ISE Page : 15

 Software Architecture and Design Patterns (17IS72)

While using this approach, we must remember that natural languages are imprecise and that synonyms
may be found. We can eliminate the others as follows:

 Customer: Becomes a member, so it is effectively a synonym for member.

 User: The library refers to members alternatively as users, so this is also a synonym.

 Application form and request: Application form is an external construct for gathering
information, and request is just a menu item, so neither actually becomes part of the data
structures. Customer’s name, address, and phone number: They are attributes of a customer, so
the Member class will have them as fields.

 Clerk: An agent for facilitating the functioning of the library, so it has no software
representation.

 Identification number: Become a part of a member.

 Data: Gets stored as a member.

 Information: Same as data related to a member.

 System: Refers to the collection of all classes and software.

UML Diagram
(Unified Modeling Language Diagram)

Figure 2.2 UML diagram for the class library

 In the above figure, system implies a conceptual class that represents all of the system.
 This class is Library UML without any attributes and methods.

Figure 2.3 UML diagram for the class Member

 The UML convention is to write the class name at the top with a line below it and the attributes
listed just below that line.

7th Semester, Department of ISE Page : 16

Software Architecture and Design Patterns (17IS72)

Figure 2.4 UML diagram showing the association of Library and Member

• An association between the conceptual classes Library and Member.

• The line between the two classes and the labels 1, *, and ‘maintains a collection of’ just above it.
• There is only one instance of the Library that maintains a collection of zero or more members.

Figure 2.5 UML diagram for the class Book

Figure 2.6 UML diagram showing the association of Library and Book

Figure 2.7 UML diagram showing the association Borrows between Member and Book

Figure.2.8 UML diagram showing the association Holds between Member and Book

7th Semester, Department of ISE Page : 17

 Software Architecture and Design Patterns (17IS72)

Figure 2.9 Conceptual classes and their associations

All the conceptual classes and their associations are captured into a single diagram. To reduce complexity,
attributes of the Library, Member, and Book are omitted. As seen before, a relationship formed between
two entities is sometimes accompanied by additional information. This additional information is relevant
only in the context of the relationship.

2.4 Using the Knowledge of the Domain

 Domain analysis is the process of analysing related application systems in a domain so as to discover what
features are common between them and which parts are variable. Thus, one of the goals of this approach is
reuse.

 Any area in which we develop software systems qualifies to be a domain.

 Examples include library systems, hotel reservation systems, university registration systems, etc. It is possible
to divide a domain into several interrelated domains.

 Where does the knowledge of a specific domain come from? It could be from sources such as surveys,
existing applications, technical reports, user manuals, and so on.

 A domain analyst analyses this knowledge to come up with Specifications, designs, and code that can be
reuse in multiple projects

7th Semester, Department of ISE Page : 18

 Software Architecture and Design Patterns (17IS72)

Fig. 2.10 Domain analysis

2.5 Design and Implementation

The main UML tool employed here is the sequence diagram. In a sequence diagram, the designer specifies
the details of how the behaviour specified in the model will be realized. This process requires the system’s
actions to be broken down into specific tasks, and the responsibility for these tasks to be assigned to the
various players in the system.

Design
During the design process, a number of questions need to be answered:

1 On what platform(s) (hardware and software) will the system run?

2 What languages and programming paradigms will be used for implementation?
3 What user interfaces will the system provide? These include GUI screens, printouts, and other
devices.
4 What classes and interfaces need to be coded? What are their responsibilities?
5 How is data stored on a permanent basis? What medium will be used? What model will be used for
data storage?
6 What happens if there is a failure? Ideally, we would like to prevent data loss and corruption. What
mechanisms are needed for realizing this?

7 Will the system use multiple computers? If so, what are the issues related to data and code
distribution?

8 What kind of protection mechanisms will the system use?

Major subsystems
The first step in our design process is to identify the major subsystems. We can view the library system as
composed of two major subsystems:

1 Business logic: This part deals with input data processing, data creation, queries, and data updates.
This module will also be responsible for interacting with external storage, storing and retrieving data.
2 User interface: This subsystem interacts with the user, accepting and outputting information. It is
important to design the system such that the above parts are separated from each other so that they can
be varied independently.

7th Semester, Department of ISE Page : 19

 Software Architecture and Design Patterns (17IS72)

Creating the Software Classes

The next step is to create the software classes. During the analysis, after defining the use case model,
We came up with a set of conceptual classes and a conceptual class diagram for the entire system.
In this phase there are two major activities.
1. Come up with a set of classes.
2. Assign responsibilities to the classes and determine the necessary data structures and methods.

In general, it is unlikely that we can come up with a design simply by doing these activities exactly once.
Several iterations may be needed and classes may need to be added, split, combined, or eliminated.

Member and Book

 Each Member object comprises several attributes such as name and address, stays in the system for
a long period of time and performs a number of useful functions.
 Books stay part of the library over a long time and we can do a number of useful actions on them.
We need to instantiate books and members quite often. Clearly, both are classes that require
representation in software.

Library: Do we really need to make a class for this? To answer the question, let us ask what real library.
When a member thinks of a library, he/she thinks of borrowing and returning books, placing and removing
holds, i.e., the functionality provided by the library.
Borrows: This class represents the one-to-many relationship between members and books. In typical one-
to-many relationships, the association class can be efficiently implemented as a part of the two classes at the
two ends.
Holds: Unlike Borrows, this class denotes a many-to-many relationship between the Member and Book
classes. In typical many-to-many relationships, implementation of the association without using an
additional class is unlikely to be clean and efficient.

Assigning Responsibilities to the Classes

 Having decided on an adequate set of software classes, our next task is to assign responsibilities to
these. Since the ultimate purpose of these classes is to enable the system to meet the responsibilities
specified in the use case, we shall work with these system responsibilities to find the class
responsibilities.

7th Semester, Department of ISE Page : 20

Software Architecture and Design Patterns (17IS72)

 Sequence diagrams
 Describe interactions among classes in terms of an exchange of messages over time.

Figure. 2.11 Sequence diagram for adding a new member

7th Semester, Department of ISE Page : 21

Software Architecture and Design Patterns (17IS72)

Figure. 2.12 Sequence diagram for adding books

Figure. 2.13 Sequence diagram for issuing books

7th Semester, Department of ISE Page : 22

Software Architecture and Design Patterns (17IS72)

Figure. 2.14 Sequence diagram for returning books

7th Semester, Department of ISE Page : 23

Software Architecture and Design Patterns (17IS72)

Figure. 2.15 Sequence diagram for removing books

Figure. 2.16 Sequence diagram for printing a member’s transactions

Figure.2.17 Sequence diagram for placing a hold

7th Semester, Department of ISE Page : 24

Software Architecture and Design Patterns (17IS72)

Figure. 2.18 Sequence diagram for processing holds

7th Semester, Department of ISE Page : 25

 Software Architecture and Design Patterns (17IS72)

Figure. 2.19 Sequence diagram for removing a holds

Figure. 2.20 Sequence diagram for renewing books

2.6.1.1 Class Diagrams

Hopefully, at this stage, we have come up with all the software classes. To review:
1. Library
2. MemberList
3. Catalog
4. Member
5. Book
6. Hold
7. Transaction

 The relationships between these classes are shown in Figure.

 Note that Hold is not shown as an Association class, but an independent class that connects
Member and Book.
 The new class Transactions added to record transactions; this has a dependency on Book since
it stores the title of the book.

7th Semester, Department of ISE Page : 26

Software Architecture and Design Patterns (17IS72)

Class Diagram for Library

Figure. 2.21 Relationships between the software classes

Figure. 2.22 Class diagram for Library

7th Semester, Department of ISE Page : 27

Software Architecture and Design Patterns (17IS72)

Class Diagram for Member

Figure. 2.23 Class diagram for Member

Class Diagram for Book

7th Semester, Department of ISE Page : 28

Software Architecture and Design Patterns (17IS72)

Class Diagram for Catalog

Figure. 2.24 Class diagram for the Book class

Figure.2.25 Class diagram for Catalog class

Class Diagram for MemberList

Figure. 2.26 Class diagram for the MemberList class

7th Semester, Department of ISE Page : 29

Software Architecture and Design Patterns (17IS72)

Class Diagram for Hold

Figure.2.27 Class diagram for Hold

Class Diagram for Transaction

Figure 2.28 Class diagram for Transaction

User Interface

As discussed earlier, our UI provides a menu with the following options:

1 Add a member
2 Add books
3 Issue books 4 Return books
4 Renew books
5 Remove books
6 Place a hold on a book
7 Remove a hold on a book
8 Process holds
9 Print a member’s transactions on a given date
10 Save data for long-term storage
11 Retrieve data fromstorage
12 Help
13 Exit

7th Semester, Department of ISE Page : 30

 Software Architecture and Design Patterns (17IS72)

2.6.1.2 Data Storage

Following commands in our UI

1. A command to save the data on a long-term basis.
2. A command to load data from a long-term storage device.
• When the first command is executed, we will copy all of the data onto secondary storage.
Similarly,
• when the second command is executed, the data stored on the storage device is copied to
recreate the object.

2.6.2 Implementing Our Design

1 In this phase, we code, test, and debug the classes that implement the
business logic (Library, Book, etc.) and UserInterface.
2 An important issue in the implementation is the communication via the
return values between the different classes: in particular between Library and
UserInterface.

Adding New Books

The addBooksmethod in UserInterfaceis shown below:
public void addBooks() { Book result;
do {
String title = getToken("Enter book title"); String author = getToken("Enter author");
String bookID = getToken("Enter id");
result = library.addBook(title, author, bookID); if (result != null) {
System.out.println(result);
} else {
System.out.println("Book could not be added");
}
if (!yesOrNo("Add more books?")) {
break;
}
} while (true);
}

7th Semester, Department of ISE Page : 31

Software Architecture and Design Patterns (17IS72)

Issuing Books
public void issueBooks() { Book result;
String memberID = getToken("Enter member id"); if
(library.searchMembership(memberID) == null) {
System.out.println("No such member"); return;
}
do {
String bookID = getToken("Enter book id"); result = library.issueBook(memberID,
bookID); if (result != null){
System.out.println(result.getTitle()+ " " + result.getDueDate());
} else {
System.out.println("Book could not be issued");
}
if (!yesOrNo("Issue more books?")) {

break;
}
} while (true);
}

The issueBookmethod in Librarydoes the necessary processing and returns a reference to the issued
book.
public Book issueBook(String memberId, String bookId) { Book book = catalog.search(bookId);
if (book == null) { return(null);
}
if (book.getBorrower() != null) { return(null);
}
Member member = memberList.search(memberId); if (member == null) {
return(null);
}
if (!(book.issue(member) && member.issue(book))) { return null;
}
return(book);
}

7th Semester, Department of ISE Page : 32

 Software Architecture and Design Patterns (17IS72)

Printing Transactions

public void getTransactions() { Iterator result;

String memberID = getToken("Enter member id");
Calendar date = getDate("Please enter the date for which you want " +
"records as mm/dd/yy"); result =
library.getTransactions(memberID,date); if (result == null) {
System.out.println ("Invalid Member ID");
} else {while (result.hasNext ()) {
Transaction transaction = (Transaction) result.next (); System.out.println (transaction.getType () + "
" +
transaction.getTitle () + "\n");
}
System.out.println ("\n There are no more transactions \n”);
}
}

2.6.2.1 Placing and Processing Holds

public void placeHold(Hold hold) {
transactions.add(new Transaction ("Hold Placed", hold.getBook().getTitle()
)); booksOnHold.add(hold);
}

To process a hold, Libraryinvokes the getNextHold method in Book, which returns the first valid hold.

public Hold getNextHold() {

for (ListIterator iterator = holds.listIterator(); iterator.hasNext();) {Hold hold = (Hold) iterator.next ();
iterator.remove(); if (hold.isValid()) {
return hold;
}
}
return null;
}

7th Semester, Department of ISE Page : 33

 Software Architecture and Design Patterns (17IS72)

2.6.2.2 Storing and Retrieving the Library Object

Java Serialization
• Our approach to long-term storage of the library data uses the Java serialization mechanism.
• In our Current example, Book and Hold can be serialized by simply declaring them to be
Serializable.

Storing the Data

• Library has references to both the Catalog and member List objects, which in turn have
references to the Book and Member objects respectively.
• The Hold objects are referred by the Book objects and the Member objects.
• Thus, if we simply store the Library object, all of the data will be stored.

Maintaining the Singleton Property

Figure.2.29 A pitfall in using serialization with a singleton

 The Library, MemberList and Catalog objects are singletons: they cannot have more than one instance. Using
the serialization mechanism, it is now possible to serialize an object and then deserialize it to get a second
instance.
 Library library = Library.instance(); Serialize library onto a disk file "library1";
 Library library2 = Deserialized version of "library1"; Update library (add a member);
 Update library2 (delete a book);

Dealing with Static Fields in Non-singletons

 The static fields in non-singletons pose a different challenge. Since the static field idCounter
in Member stores the value that is used to generate the ID for each new member, this value
must be saved along with the library. Since static fields are not serialized, this value will have
to be explicitly written in the write Object method of Member.
 One simple solution to this is to circumvent the problem by encapsulating the static field as a
separate class. The singleton Member Id Server, shown below, holds the idCounter and also
increments it each time getId is invoked.

7th Semester, Department of ISE Page : 34

 Software Architecture and Design Patterns (17IS72)

class MemberIdServer implements Serializable

{ private int idCounter;
private static MemberIdServer server; private MemberIdServer()
{
idCounter = 1;
}
public static MemberIdServer instance()
{
if (server == null)
{
return (server = new MemberIdServer());
}
else
{
return server;
}
}
public int getId() { return idCounter++;
}/
/ other code not shown
}

7th Semester, Department of ISE Page : 35

 Software Architecture and Design Patterns (17IS72)

2.6 Discussion and Further Reading

Converting the model into a working design is the most complex part of the software design process.
The sequence of topics so far suggests that the design would progress linearly from analysis to design to
implementation.
 Conceptual, Software and Implementation Classes:
Finding the classes is a critical step in the object-oriented methodology. In the analysis phase, we found the
conceptual classes. These correspond to real- world concepts or things, and present us with a conceptual or
essential perspective.
As we go further into the design process and construct the sequence diagrams, we need to deal with the
issue of these conceptual classes. we are now dealing with software classes.
The last step is the implementation class, which is a class created using a specific programming language
such as Java or C++. The last step is the implementation class, which is a class created using a specific
programming language such as Java or C++.

 Building a Commercially Acceptable System:

 Non-functional Requirements: Some issues like portability are automatically resolved since Java is
interpreted and is thus platform independent. Response time (run-time performance) is a sticking
point for object-oriented applications.
 Functional Requirements: It can be argued that for a system to be accepted commercially, it must
provide a sufficiently large set of services, like –
 Additional features can be easily added
 Allowing for variability among kinds of books/members
 Having a more sophisticated interface
 Allowing remote access

 The Facade Pattern: Library class that provided a set of methods for the interface and thus served as a single
point of entry to and exit from the business logic module. In the language of design patterns, what we created
is known as a facade.
• The primary motivation behind using a façade is to reduce the complexity by minimizing
communication and dependencies between a subsystem and its clients . The facade not only shields
the client from the complexity but also enables loose coupling between the subsystem and its clients.
Facades are not typically designed to prevent the client from accessing the components within the
subsystem.

 Using a Facade
Where do we employ this? A situation in which we have:
1. A system with several individual classes, each with its own set of public methods.
2. An external entity interacting with the system requires knowledge of the public
methods of several classes.

7th Semester, Department of ISE Page : 36

 Software Architecture and Design Patterns (17IS72)

Figure 2.30 Structure diagram for facade

Figure 2.31 Interactions with a subsystem without a facade

Note: Explanation for sequence diagrams can be referred from use case analysis.

7th Semester, Department of ISE Page : 37