SOFTWARE ARCHITECTURE AND

DESIGN PATTERNS

BMS Institute of Technology and Mgmt

Module-2 :
Analysing a System
Contents :
1. Overview of the analysis phase
2. Stage 1: Gathering the Requirements
⮚ Case Study Introduction
3. Functional Requirements Specification
⮚ Use Case Analysis
4. Defining Conceptual Classes and Relationships
[Link] the Knowledge of the Domain
[Link] and Further Reading
[Link] and Implementation
 1. Overview of the analysis phase

What should the system do?

Simple minded approach does not suffice for the real-life projects:
reasons:
1. Systems are typically much bigger in scope and size.
2. Have complex and ambiguously-expressed requirements.
3. Usually a large amount of money involved, which makes matters
quite serious.
4. Project deadlines for these ‘real-life’ projects are more critical
The process of building a system could be split into
3 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.

These activities could be iterative or nested

 Stage 1: Gathering the Requirements
The purpose of requirements analysis is to define what the new
system should do.
• System will be built based on the information garnered.
• 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.
• Requirements for a new system are determined by a team of
analysts by interacting development (clients) and the user
community.
• This interaction can be in the form of interviews, surveys,
observations, study of existing manuals, etc.,
Requirements can be classified into 2 categories
1. Functional requirements :
These describe the interaction between
• System and its users,
• System and any other systems, which may interact with the
system by supplying or receiving data.
2. Non-functional requirements: Any requirement that does
not fall in the above category is a non-functional
requirement.
• Such as response time, usability and accuracy.
• May be considerations that place restrictions on system
development; the use of specific hardware and software
and budget and time constraints.
BMS Institute of Technology and Mgmt
Case Study : A simple library system

Functionality is described as a list called business processes.

The business processes of the library system are listed below.
1. Register new members
2. Add books to the collection
3. Issue a book to a member (or user)
4. Record the return of a book
5. Remove books from the collection
6. Print out a user’s transactions
7. Place/remove a hold on a book
8. Renew books issued to a member
9. Notify member of book’s availability
A simple library system In addition, the system must support
three other requirements that are not directly related to the
workings of a library:
1. A command to save the data on a long-term basis.
2. A command to load data from a long-term storage device.
3. A command to quit the application. At this time, the
system must ask the user if data is to be saved before
termination.
 Functional Requirements Specification
• The requirements be precisely documented.
• The requirements specification document serves as a contract
between the users and the developers.
• No confusion as to what the expectations are.
• An accepted way of accomplishing this task is the use case analysis,
Use Case Analysis:
Def: Use case analysis is a case-based way of describing the uses of
the system with the goal of defining and documenting the system
requirements.
• 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:
1. Agents: Who interact with the system
2. The system itself.
A simple library system…
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
chnology and Mgmt
for the library system
 A simple library system…
Use case for registering a user: specified using a 2-column format
 A simple library system…
Illustrates several aspects of use cases.

1. Every use case has to be identified by a name.

Ex: Register New Member
2. Reasonably-sized activity in the organisation.
• Not all actions and operations should be identified as use cases.
Ex: stamping a due-date on the book should not be a use case
• A use case is a relatively large end-to-end process description
that captures some business process
• A business process may be decomposed into more than one use
case
• when there is some intervening real-world event(s) for which
the agent has to wait for an unspecified length of time.
3. The first step of the use case specifies a ‘real-world’ action that
triggers the exchange described in the use case.
A simple library system…
4. The use case does not specify how the functionality is
to be implemented. Ex: the details of how the
clerk enters the required information into the system
is unspecified.
5. The use case is not expected to cover all possible
situations.
• Use case does not specify what the system should do
if there are errors.
• The use case explains only the most commonly-
occurring scenario- referred to as the main flow.
A simple library system…
Use case for adding books:
A simple library system…
Use case for issuing books:
• Putting all these details in the use case would make the use
case quite messy and harder to understand. Business Rules.
• A business rule may be applicable to one or more use cases.
• Example: The business rule for due-date generation is
simple in our case.
After applying the rules in the Book Checkout use case

Department of ISE BMS Institute of Technology and Mgmt

Similarly use case for the remaining can be written using table
1. Use case for returning books table 6.6
2. Use cases for removing (deleting) books, printing member
transactions, placing a hold, and removing a hold (Table 6.7,
Table 6.8, Table 6.9, Table 6.10)
 How do Business Rules Relate to Use Cases?
• Business rules can be broadly defined as the details through
which a business implements its strategy.
• Business analysts perform the task of gathering business rules,
and these belong to one of four categories:

1. Definitional rules
2. Factual rules
3. Constraints
4. Derivations
 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. Usefulness of this step is:
1. Design facilitation
2. Added knowledge
3. Error reduction
4. Useful documentation
 Guidelines to Remember When Writing Use Cases
1. A use case must provide something of value to an actor or to the business :
each use case has at least one actor.
2. Use cases should be functionally cohesive : they encapsulate a single service
that the system provides.
3. Use cases should be temporally cohesive : constitute separate use cases
4. If a system has multiple actors, each actor must be involved in at least one,
and typically several use cases.
5. The model that we construct is a set of use cases, i.e., there is no
relationship between individual use cases.
6. Exceptional exit conditions are not handled in use cases: For instance, if a
system should crash in the middle of a use case,
7. Use cases are written from the point of view of the actor in the active voice.
8. A use case describes a scenario, : i.e., tells us what the visible outcome is and
does not give details of any other requirements that are being imposed on
the system.
9. Use cases change over the course of system analysis: Use cases may be
merged, added or deleted from the model at any time.
 In practice the analyst will use multiple methods to come
up with the conceptual classes and their relationships

The text of use case, all nouns bold-faced:

(1) The customer fills out an application form containing the
customer’s name, address, and phone number and gives this
to the clerk.
(2) The clerk issues a request to add a new member.
(3) The system asks for data about the new member.
(4) The clerk enters the data into the system.
(5) Reads in data, and if the member can be added, generates an
identification number for the member and remembers
information about the member. Informs the clerk if the
member was added and outputs the member’s name,
address, phone, and id.
(6) The clerk gives the user his identification number.
 First, let us eliminate duplicates to get
list
customer, application form, customer’s name, address, phone
number, clerk, request, system, data, identification
number, member, user, member information, and member’s
name.
Some of the nouns such as member are composite entities
that qualify to be classes.
1. customer: becomes a member, so it is effectively a synonym for member.
2. user: the library refers to members alternatively as users, so this is also a synonym.
3. 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.
4. customer’s name, address, and phone number: They are attributes of a customer,
so the Member class will have them as fields.
5. clerk: is just an agent for facilitating the functioning of the library, so it has no
software representation.
6. identification number: will become part of a member.
7. data: gets stored as a member.
8. information: same as data related to a member.
9. system: refers to the collection of all classes and software.
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.

UML diagram showing the association of Library and

UML diagram for Member : one-to-many association: mean that one
the class Member
instance of the Library maintains a collection of zero or
more members.
• In this example we have many conceptual classes like library
members, system etc.,
• Some associations are static, i.e., permanent, whereas others are
dynamic. Dynamic associations are those that change as a result of
the transactions being recorded by the system.
• Such associations are typically associated with verbs.
• many-to-many between users and books.
• Several users can have holds placed on a book, and a user may place holds
on an arbitrary number of books.
We capture all of the conceptual classes and their
associations into a single diagram:

• Additional information can be accompanied.

• This is added when a user borrows a book and when a user places a hold on
a book.
• Borrowing a book introduces new information into the system, viz., the date
on which the book is due to be returned. Likewise, placing a hold introduces
some information, viz., the date after which the book is not needed.
• conceptual classes are attached to the line representing the corresponding
associations.
 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 what parts are variable.
OR
• we identify and analyse common requirements from a specific
application domain.
• we apply the knowledge we already have from our study of similar
systems to speed up the creation of specifications, design, and
code.
• one of the goals of this approach is reuse.
• For example, we could say that the
domain ( university applications ) => domain (course
management + student admissions + payroll applications, and so
on )
• The interactions of the smaller domains that make up the bigger
one.
In the domain of libraries includes the
following.

1. The environment, including customers and users. Libraries have

loanable items such as books, CDs, periodicals, etc. A
library’s customers are members. Libraries buy books from
publishers.
2. Terminology that is unique to the domain. For example, the Dewey
decimal classification (DDC) system for books.
3. Tasks and procedures currently performed. In a library system, for
example:
(a) Members may check out loanable items.
(b) Some items are available only for reference; they cannot be
checked out.
(c) Members may put holds on loanable items.
 Finding the Right Classes

• In general, finding the right classes is non-trivial.

• Process is iterative,
• The following thumb rules and caveats come in handy:
1. Do not build classes around functions. If class name is
imperative, e.g., print, parse, etc., either the class is wrong or
the name is wrong.
2. Remember that a class usually has more than one method;
otherwise it is probably a method that should be attached to
some other class.
3. Do not form an inheritance hierarchy too soon unless we have
a pre existing taxonomy.
4. Be wary of classes that have no methods, Some
situations in which they occur are:
a) representing objects from outside world,
b) encapsulating facilities, constants or shared
variables,
c) applicative classes used to describe non-modifiable
objects,
5. Check for the following properties of the ideal class:
a. a clearly associated abstraction, which should be a
data abstraction (as opposed to a process
abstraction),
b. a descriptive noun/adjective for the class name,
c. a nonempty set of runtime objects,
d. queries and commands,
e. abstract properties that can be described as
pre/post conditions and invariants.
One of the major activities of this analysis is discovering
the business rules, the rules that any properly-functioning
system in that domain must conform to.
Q. 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.

Domain analysis
Chapter 7: Design and Implementation
Contents:
1. Design
a. Major Subsystem
b. Creating the software classes
c. Assigning responsibilities to the
classes
d. Class diagrams
e. User interface
f. Data storage
2. Implementing our design
Design:
We use the class structure produced by the analysis to design
a system that behaves in the manner specified by the model.
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?
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 realising 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?
a. 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.

BMS Institute of Technology and Mgmt

b. Creating 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.
• The software classes are more ‘concrete’ in that they correspond to
the software components that make up the 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.
• Several iterations may be needed and classes may need to be
added, split, combined, or eliminated.
• The classes for the business logic module will be the ones
instrumental in implementing the system requirements described in
the use case model.

BMS Institute of Technology and Mgmt

Conceptual classes of Library System are:
1. 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.
2. Library a library, can be viewed as borrowing
and returning books, placing and removing holds,
i.e., the functionality provided by the library.
• All the computation required of the business logic
module must be executed on some current object; that
object is a Library.
• So Library be class in its own.
• A class that has just one instance is called a singleton.
Both MemberList and Catalog are singletons.
BMS Institute of Technology and Mgmt
3. Borrows: (An association class between member and books
class)
• 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.
4. Holds: (An association class between member and books class)
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.
• Have a class for this relationship and make the Hold
object accessible to the instances of Member and Book
C. Assigning Responsibilities to the Classes:
• Having decided on an adequate set of software
classes, next task is to assign responsibilities to these.
• The ultimate purpose of these classes is to enable the
system to meet the responsibilities specified in the
use case.
• For each system response listed in the right-hand
column of the use case tables, we need to specify the
following:
a. The sequence in which the operations will occur.- we
need a complete algorithm
b. How each operation will be carried out.- Describes
which classes will be involved in each step of the
algorithm and how the classes will be engaged.
Register Member: Sequence Diagram:
This interaction occurs between the library staff member and the
UserInterface instance. The clerk enters the requested data, which the
UserInterface accepts.
The addMember method, algorithm here consists of three steps:
1. Create a Member object.
2. Add the Member object to the list of members.
3. Return the result of the operation.
To carry out the first two steps, we have two options:
Option1:
• Invoke the Member constructor from within the addMember method of
Library.
• The constructor returns a reference to the Member object and an
operation, insertMember, is invoked on MemberList to add the new
member.
Option2:
• Invoke an addNewMember method on MemberList and pass as parameters all
the data about the new member.
• MemberList creates the Member object and adds it to the collection.
BMS Institute of Technology and Mgmt
To carry out the first two steps, we have two options:
Option1:

• Invoke the Member constructor from within the addMember

method of Library.
• The constructor returns a reference to the Member object and an
operation, insertMember, is invoked on MemberList to add the
new member.
Add Books: This use case allows the insertion of an
arbitrary number of books into the system. In this case, when
the request is made by the actor, the system enters a loop.
The algorithm here consists of the following steps:
(i) create a Book object,
(ii) add the Book object to the catalog and
(iii) return the result of the operation.

Department of ISE BMS Institute of Technology and Mgmt

Issue Books: When a book is to be checked out, the clerk
interacts with the UI to input the user’s ID. The system has to first
check the validity of the user. This is accomplished by invoking the
method searchMembership on the Library.
Two options suggest themselves for implementing the search:
Option 1 Get an enumeration of all Member objects from
MemberList, get the ID from each and compare with the target ID.
• Option 2 Delegate the entire responsibility to MemberList.

Department of ISE BMS Institute of Technology and Mgmt

Return Books:
• For each book returned, the returnBook method of the Library
class obtains the corresponding Book object from
Catalog.
• The returnBook method is invoked using this Book object, and
this method returns the Member object corresponding
to the member who had borrowed the book.
• The returnBook method of the Member object is now called to
record that the book has been returned.
• This operation has three possible outcomes that the use case
requires the system to distinguish.
1. The book’s IDwas invalid,whichwould result in the operation
being unsuccessful;
2. the operation was successful;
3. The operation was successful and there is a hold on the book.
The value returned by returnBook must enable UserInterface
to make the distinction between these.
BMS Institute of Technology and Mgmt
Sequence diagram for returning books
Remove Books:
• we remove only those books that are not checked out and do
not have a hold. This logic for deciding whether the book is
removable is in the removeBook method in Library.
• This method checks each property of the book in question and
if all properties are satisfied, the remove method in Catalog is
invoked, which then removes the book.

Department of ISE BMS Institute of Technology and Mgmt

Member Transactions:
• The end-user (clerk) interacts with the Library class to print out the
transactions of a given member.
• The Member class stores the necessary information about the
transactions, but the UI would be the one to decide the format.
• It would, therefore, be desirable to provide the information
to the UI as a collection of objects, each object containing the
information about a particular transaction.

Department of ISE BMS Institute of Technology and Mgmt

Class Diagrams:
1. Library
2. MemberList
3. Catalog
4. Member
5. Book
6. Hold
7. Transaction

Relationships between the software

Department
Department of ISE classes
ofISE BMS
BMS
Institute
Institute
of of
Technology
Technology
and
and
Mgmt
Mgmt
Class diagram for Library
Class Diagram for Member

Department of ISE BMS Institute of Technology and Mgmt

Class Diagram for Book

Department of ISE BMS Institute of Technology and Mgmt

Class Diagram for Catalog Class Diagram for MemberList

Class Diagram for Hold Class Diagram for Transaction

Department
Departmentof
ofISE
ISE nstitute of
BMS Institute of Technology
Technology and
and Mgmt
Mgmt
BMS I
User Interface: UI provides a menu with the following
options
1 Add a member
2 Add books
3 Issue books
4 Return books
5 Renew books
6 Remove books
7 Place a hold on a book
8 Remove a hold on a book
9 Process holds
10 Print a member’s transactions on a given date
11 Save data for long-term storage
12 Retrieve data from storage
0 Exit
13 Help
BMS Institute of Technology and Mgmt
Data Storage
In a full-blown system, data is usually stored in a database,
and this data is managed by a database management
system.
Include the following commands in 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.
Implementing Our Design
• Library has several methods that return int values, and these
values must be interpreted by the UI.
• A separate named constant is declared for each of these outcomes
as shown below.
public static final int BOOK_NOT_FOUND = 1;
public static final int BOOK_NOT_ISSUED = 2;
// etc.

BMS Institute of Technology and Mgmt

Setting Up the Interface:

The main program resides in the class UserInterface. When the

main program is executed, an instance of the UserInterface is
created (a singleton).
public static void main(String[] s)
{
[Link]().process();
}

public static UserInterface instance()

{
if (userInterface == null) {
return userInterface = new UserInterface();
} else {
return userInterface;
}} BMS Institute of Technology and Mgmt
private UserInterface()
{
File file = new File("LibraryData");
if ([Link]() && [Link]()) {
if (yesOrNo("Saved data exists. Use it?"))
{
retrieve();
}
}
library = [Link]();
}

BMS Institute of Technology and Mgmt

Process Method of UI
public void process()
{ int command;
help();
while ((command = getCommand()) != EXIT) {
switch (command) {
case ADD_MEMBER: addMember();
break;
case ADD_BOOKS: addBooks();
break;
case ISSUE_BOOKS: issueBooks();
break;
// several lines of code not shown
case HELP: help();
break;
}
}
} BMS Institute of Technology and Mgmt
Adding New Books

Department of ISE
addBook() method in Library is
invoked:
The Catalog (which is also a singleton) is an
adapter for the LinkedList class, so all it does is to
invoke the add method in Java’s LinkedList class,
Issuing Books

Department of ISE BMS Institute of Technology and Mgmt

The issueBook( )s the necessary processing and
returns a reference to the issued book.

Department of ISE BMS Institute of Technology and Mgmt

The issue methods in Book and Member record the fact
that the book is being issued. The method in Book
generates a due date for our simple library by adding
one month to the date of issue.

Department of ISE
Member is also keeping track of all the transactions (issues
and returns) that the member has completed. This is done
by defining the class Transaction.

Department of ISE BMS Institute of Technology and Mgmt

Department of ISE BMS Institute of Technology and Mgmt
With each book issued, a record is created and added to
the list of transactions, as shown in the following code
snippet from Member.
 Placing and Processing Holds
• When placing a hold, the information about the hold is passed to
Library, which checks the validity of the information and
creates a Hold object

• The problem with this simple solution is that unwanted holds

can stay in the system forever.
• To prevent this, we may want to delete all invalid holds periodically,
perhaps just before the system is saved to disk.
To process a hold,
Library invokes the
getNextHold
method in Book,
which returns the
first valid hold.
Department of ISE BMS Institute of Technology and Mgmt
Storing and Retrieving the Library
Object Java Serialization

• long-term storage of the library data uses the Java

serialization mechanism.
• The methods readObject()and writeObject (Object) in
ObjectInputStream and ObjectOutputStream
respectively can be used to read and write objects and that
this can be easily done for simple cases by having the
corresponding class implement the Serializable interface.
• The default serialization mechanism in Java does not store
static fields.
BMS Institute of Technology and Mgmt
Department of ISE BMS Institute of Technology and Mgmt