Software Engineering

Experiment - 02
Name of experiment : Functional and non-functional dependency
Case Study : A Library Information System for SE VLabs Institute
The SE VLabs Institute has been recently setup to provide state-of-the-art research facilities in the field of
Software Engineering. Apart from research scholars (students) and professors, it also includes quite a large
number of employees who work on different projects undertaken by the institution.
As the size and capacity of the institute is increasing with the time, it has been proposed to develop a Library
Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the
members to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a
member to extend the date of his borrowing if no other booking for that particular book has been made. For the
library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into the system when a
new book has been purchased, or remove a record in case any book is taken off the shelf. Any non-member is
free to use this system to browse/search books online. However, issuing or returning books is restricted to valid
users (members) of LIS only.
The final deliverable would a web application (using the recent HTML 5), which should run only within the
institute LAN. Although this reduces security risk of the software to a large extent, care should be taken no
confidential information (ex : passwords) is stored in plain text.
Identification of functional requirements
The above problem statement gives a brief description of the proposed system. From the above, even without
doing any deep analysis, we might easily identify some of the basic functionality of the system:
New user registration: Any member of the institute who wishes to avail the facilities of the library has to
register himself with the Library Information System. On successful registration, a user ID and password would
be provided to the member. He has to use this credentials for any future transaction in LIS.
Search book: Any member of LIS can avail this facility to check whether any particular book is present in the
institute's library. A book could be searched by its:
 Title
 Authors name
 Publisher's name
User login: A registered user of LIS can login to the system by providing his employee ID and password as set
by him while registering. After successful login, "Home" page for the user is shown from where he can access
the different functionalities of LIS: search book, issue book, return book, reissue book. Any employee ID not
registered with LIS cannot access the "Home" page -- a login failure message would be shown to him, and the
login dialog would appear again. This same thing happens when any registered user types in his password
wrong. However, if incorrect password has been provided for three time consecutively, the security question
for the user (specified while registering) with an input box to answer it are also shown. If the user can answer
the security question correctly, a new password would be sent to his email address. In case the user fails to
answer the security question correctly, his LIS account would be blocked. He needs to contact with the
administrator to make it active again.
Name : Rashida Jahan Roll No : CSE2016/006

 Issue book : Any member of LIS can issue a book against his account provided that :
a) The book is available in the library i.e. could be found by searching for it in LIS
b) No other member has current issued the book
c) Current user has not issued the maximum number of books
If above conditions are met , the book is issued to the member.
 Return book: A book is issued for a finite time, which we assume to be a period of 20 days. That is, a
book once issued should be returned within the next 20 days by the corresponding member of LIS.
After successful return of a book, the user account is updated to reflect the same.
 Reissue book: Any member who has issued a book might find that his requirement is not over by 20
days. In that case, he might choose to reissue the book, and get the permission to keep it for another 20
days. However, a member can reissue any book at most twice, after which he has to return it. Once a
book has been successfully reissued, the user account is updated to reflect the information.
 In a similar way we can list other functionality offered by the system as well. However, certain features
might not be evident directly from the problem system, but which, nevertheless, are required. One such
functionality is "User Verification". The LIS should be able to judge between a registered and non-
registered member. Most of the functionality would be available to a registered member. The "New
User Registration" would, however, be available to non-members. Moreover, an already registered user
shouldn't be allowed to register himself once again.
 Having identified the (major) functional requirements, we assign an identifier to each of them [v] for
future reference and verification. Following table shows the list:
# Requirement Priority
R1 New user Registration High
R2 User Login High
R3 Search Book High
R4 Issue Book High
R5 Return Book High
R6 Reissue Book Low
Identification of non-functional requirements

Having talked about functional requirements, let's try to identify a few non-functional requirements.
 Performance Requirements:
 This system should remain accessible 24x7
 At least 50 users should be able to access the system altogether at any given time
 Security Requirements:
 This system should be accessible only within the institute LAN
 The database of LIS should not store any password in plain text -- a hashed value has to be
stored
 Software Quality Attributes
 Database Requirements
 Design Constraints:
 The LIS has to be developed as a web application, which should work with Firefox 5, Internet
Explorer 8, Google Chrome 12, Opera 10
 The system should be developed using HTML 5
Once all the functional and non-functional requirements have been identified, they are documented formally
in SRS, which then serves as a legal agreement.

Exercise :
Consider the problem statement for an "Online Auction System" to be developed: New users can register to the
system through an online process. By registering a user agrees to abide by different predefined terms and
conditions as specified by the system. Any registered user can access the different features of the system
authorized to him / her, after he authenticates himself through the login screen. An authenticated user can put
items in the system for auction. Authenticated users can place bid for an item. Once the auction is over, the
item will be sold to the user placing the maximum bid. Payments are to be made by third party payment
services, which, of course, is guaranteed to be secure. The user selling the item will be responsible for it's
shipping. If the seller thinks he's getting a good price, he can, however, sell the item at any point of time to the
maximum bidder available.

Experiment - 03
Name of experiment : E-R Modeling from problem statement

Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the
members to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables
a member to extend the date of his borrowing if no other booking for that particular book has been made. For
the library staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has
administrative privileges and complete control over the system, can enter a new record into the system when
a new book has been purchased, or remove a record in case any book is taken off the shelf. Any non-member
is free to use this system to browse/search books online. However, issuing or returning books is restricted to
valid users (members) of LIS only.
confidential information (eg., passwords) is stored in plain text.
A robust database backend is essential for a high-quality information system. Database schema should be
efficiently modeled, refined, and normalized. In this section we would develop a simple ER model for the
Library Information System.
The first step towards ER modeling is to identify the set of relevant entities from the given problem statement.
The two primary, and obvious, entity sets in this context are "Member" and "Book". The entity set "Member"
represents all students, professors, or employees who have registered themselves with the LIS. While
registering with the LIS one has to furnish a lot of personal and professional information. This typically
includes name (well, that is trivial), employee ID (roll # for students), email address, phone #, age, date of
joining in this institute. The system may store some not-so-important information as well like, blood group,
marital status, and so on. All these pieces of information that an user has to provide are sufficient to describe
a particular member. These characteristics are the attributes of the entities belonging to the entity set
"Member".
It is essential for an entity to have one or more attributes that help us to distinguish it from another entity.
'Name' can't help that -- two persons could have exactly the same name. However, ('Name', 'Phone #')
combination seems to be okay. No two persons can have the same phone number. 'Employee ID', 'Email
address' are other potential candidates. Here, 'Employee ID', 'Email address' and ('Name', 'Phone #') are super
keys. We choose 'Employee ID' to uniquely identify an user in our implementation. So, 'Employee ID'
becomes our primary key (PK) for the "Member" entity set.

Let us now focus on the "Book" entity set. Typical attributes of a book are it's title, name of author(s), publisher,
date of publication, edition, language, ISBN-10, ISBN-13, price (of course!), date of purchase. The set of listed
attributes for a book doesn't give a straight forward choice of primary key. For instance, several books could
have the same title. Again, ISBN numbers for a book are specific to it's edition -- it can't distinguish between
two books of the same edition. One might be tempted to use a combination of ('Title', 'Authors') as a primary
key. This has some shortcomings. It is advisable not to use texts as a PK. Moreover, the number of authors that
a book could have is not fixed, although it is a small, finite number. The rules of normalization (not covered
here) would dictate to have a separate field for each author like 'Author1', 'Author2', and so on. Therefore, we
assign an extra attribute, 'ID', to each book as it's PK. Different databases available in the market provide
mechanisms to generate such an unique ID, and automatically increment it whenever a new entity is added. In
fact, we could assign such an ID to the "Member" entity set as well. However, because of availability of the
unique 'Employee ID' field, we skipped that. A graphical representation of the "Book" entity set
One point to note here is that a book is likely to have multiple copies in the library. Therefore, one might wish
to have a '# of copies' attribute for the "Book" entity set. However, that won't allow us to differentiate among
the different copies of book bearing same title by same author(s), edition, and publisher. The approach that we
have taken is to uniquely identify each book even though they are copies of the same title.
To buy any new book an order is to be placed to the distributor. This task is done by the librarian. Therefore,
"Librarian" and "Distributor" are two other entities playing roles in this system.
Having identified the key entities, we could now relate them with each other. Let us consider the entity sets
"Member" and "Book". A member can issue books. In fact, he can issue multiple books up to a finite number
say, N. A particular book, however, could be issued by a single member only. Therefore, we have a one-to-
many mapping from "Member" to "Book" entity sets. This relationship between "Member" and "Book" entity
sets is pictorially depicted

It also shows that the librarian can "place order" for books to the distributor. This is a many-to-many mapping
since a librarian can purchase books from multiple distributors. Also, if the institute has more than one librarians
(or any other staff having such authority), then each of them could place order to the same distributor. An order
is termed as complete when distributor supplies the book(s) and invoice.
The design in figure 3 has a flaw. Librarian himself could be a member of the LIS. However, he is a "special"
kind of member since he can place order for books. Our ER diagram doesn't reflect this scenario. Such special
roles of an entity set could be represented using "ISA" relationship, which is not discussed here.
Any kind of designing couldn't be possibly done at one go. Therefore, the baseline ER model so prepared should
be revised by considering the business model yet again to ensure that all necessary information could be
captured. Once this has been finalized, the next logical step would be to create table structures for each identified
entity set (and relationships in some cases) and normalize the relations.
Exercise :
From the following problem statement identify the possible entity sets, their attributes, and relationships.
SE VLabs Inc. is a young company with a few departments spread across the country. As of now, the company
has a strength of 200+ employees.
Each employee works in a department. While joining, a person has to provide a lot of personal and professional
details including name, address, phone #, mail address, date of birth, and so on. Once all these information are
furnished, a unique ID is generated for each employee. He is then assigned a department in which he will work.
There are around ten departments in the company. Unfortunately, two departments were given same names.
However, departments too have ID's, which are unique.

Experiment - 04
Name of experiment : UML Use Case Diagrams
Information System (LIS) for the benefit of students and employees of the institute. LIS will enable the members
to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a member
to extend the date of his borrowing if no other booking for that particular book has been made. For the library
staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has administrative
privileges and complete control over the system, can enter a new record into the system when a new book has
been purchased, or remove a record in case any book is taken off the shelf. Any non-member is free to use this
system to browse/search books online. However, issuing or returning books is restricted to valid users
(members) of LIS only.
From the given problem statement we can identify a list of actors and use cases as shown in tables 1 & 2
respectively. We assign an identifier to each use case, which we would be using to map from the software
requirements identified earlier.
Table 1: List of actors

Actor Description
Member Can avail LIS facilities; could be student, professor, researcher
Non-member Need to register to avail LIS facilities
Librarian Update inventory and other administrative tasks
Library staff Handle day-to-day activities with the LIS
Table 2: List of use cases

# Use Case Description
UC1 Register Allows to register with the LIS and create an account for all transactions
UC2 User login LIS authenticates a member to let him avail the facilities
UC3 Search book A member can can search for a book
UC4 Issue book Allows a member to issue a specified book against his account
UC5 Return book To return a book, which has been issued earlier by a member
UC6 Reissue book To reissue a book
UC7 User logout User logs out from the system
Before presenting the details of individual use cases, let us do a mapping from requirements specifications to
use cases. A list of functional requirements can be found in the table 1. For each such requirements, we identify
the use case(s) that helps to achieve the requirement. This mapping is shown in table 3. Please note that we
would be mapping only functional requirements into use cases. A method to deal with non-functional
requirements could be found in [vi].

Now let us deal with the inner details of a few use cases and the actors with whom they are associated. Table 4
shows the details of the "User login" use case using a template presented in table 1 in [v].
The above use case lets an already registered member of the LIS to login to the system and possible use it's
various features. If the user provides a correct pair of (<user_id>, <password>) then he can access his home
page. However, if login credentials are incorrect, an error message is displayed to him. Figure 1 shows its
pictorial representation.
The above figure also depicts extension of a use case. "Answer security question" is not a use case by itself, and
is not invoked in a "normal" flow. However, when a member is trying to login, and provides incorrect
(<user_id>, <password>) for three consecutive times, he is asked the security question that was set during
registration. If user can answer the question correctly, the password is send to his email address. However, if
the user fails to answer the security question correctly, his account is temporarily blocked. Details of the
concerned use case extension is shown in table 5.

The details of the "Issue book" use case is shown in table 6.
In order to issue a book, the availability of the book has to be checked. Also, the system needs to verify whether
another book could be issued to the current user. These are shown in figure 2 by the «include» relationship
among the use cases. The maximum # of books that can be issued to a user depends on whether he is a student
or a professor. So, "Verify issue count" is a general use case, which has been specialized by "Verify student
issue count" and "Verify professor issue count" use cases. These have been represented by the "generalization"
relationship in figure .
In the above scenario "Member" is the primary actor who triggers the "Issue book" use case. "Library staff" is a
secondary actor here.

Exercise :
Draw a use case diagram for the following problem : Consider your neighbouring travel agent from whom you
can purchase flight tickets. To book a ticket you need to provide details about your journey i.e. on which date and
at what time you would like to travel. You also need to provide your address. The agency has recently been
modernized. So you can pay either by cash or by card. You can also cancel a booked ticket later if you decide to
change your plan. In that case you need to book a new ticket again. Your agent also allows you to book a hotel
along with flight ticket. While canceling a flight ticket you can also cancel hotel booking. Appropriate refund as
per policy is made in case of cancellation.

Experiment - 05
Name of experiment : UML Class Diagram

to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a member
to extend the date of his borrowing if no other booking for that particular book has been made. For the library
staff, this system aids them to easily handle day-to-day book transactions. The librarian, who has administrative
system to browse/search books online. However, issuing or returning books is restricted to valid users
(members) of LIS only.
Let us consider the "Issue Book" use case and represent the involved steps in a sequence diagram as shown in
figure 1. We assume that the book to be issued is available. An user makes a request to issue a book against his
account. This is shown by the "issueBook(bookID)" call from "Member" to "IssueManager" objects. At this
point the system checks whether that particular user can issue another book (based on the maximum number of
books that he can issue) by invoking the "canIssue()" method on the "Member". As a result of this call, a
response ("status") is sent back to the "IssueManager" class. If the "status" is "true" (as indicated in the note),
status of the concerned book is set to "issued". A new transaction is saved corresponding to the current issue of
book by the user. Finally, a success message is sent back to "Member" indicating that the book was successfully
issued.
Figure 1: Sequence diagram for "Issue Book"

Few points could be noted here. Notes can be used almost anywhere within an UML diagram for whatever
purpose. In figure 1 we use a note to specify the condition when status of a book is set to 'issued'. UML 1.0 had
used guard conditions to specify such kind of Boolean logic. UML 2.0 provide components to specify the
alternate scenarios within a sequence diagram (not discussed here). One can definitely make use of these
components. However, if the number of IF-THEN-ELSE conditions in a sequence diagram becomes high, the
diagram gets complicated. In such cases one can draw multiple sequence diagrams for alternate conditions.

One key component in figure 1 is the "IssueManager" class. This class doesn't represent the actual Library
Information System (LIS). Rather, this is a part of LIS -- a specific module to handle issuing of books to the
members.Also, note that the life cycle of the "Transactions" has been shown as self-destroyed. To understand
this, consider how a transaction is actually implemented in code. One creates an object from "Transactions" class,
fills it up with all necessary information, and then saves the transaction. Thereafter, the transaction object is not
required to be in memory.Figure 2 shows the order of steps involved in the process of purchasing of a new book.
In this case also, "PurchaseManager" is a part of LIS, which manages all books that are being purchased. The
activation bars indicate the different instances when a particular object is active in their corresponding life cycles.
Figure 2: Sequence diagram for "Purchase Books"

One may have doubts over the inclusion of "Distributor" class. "Distributor" is not a constituent of the LIS;
however, it interacts with LIS. Here "Distributor" is meant to represent the "interface" between LIS and the
actual, physical book sellers and distributors. For instance, LIS can store details of distributor XYZ, including
it's email address, bank account number, into it's records. Whenever the librarian places a new order to XYZ, the
order is being sent electronically to XYZ, processed (possibly with a delay), a corresponding invoice is generated,
and sent back to LIS. "placeOrder(orderID)" has been indicated as asynchronous calls since the calling object
can continue with other tasks. The books would be dispatched by XYZ physically, which lies outside the
boundary of LIS. Once the ordered books have been received, the librarian opts to make payment for his orders,
which, too, could happen electronically through Net Banking. Technology has, indeed, made a huge progress!
Finally, at his leisure time, the librarian might consider updating the inventory according to the corresponding
order.
Classes are the fundamental components of any object oriented design and development. Unless individual
class, it's attributes and associated operations have been modeled well, a lot of suffereing could await during
the development phase. However, unlike waterfall model, the life cycle in object oriented development is
iterative. One builds a model, analyze it's efficiency, and refines it thereafter, if required. Therefore, an analyst,
designer, or developer doesn't have the tight constraints to create a perfect art at one go.
Based on conceptual modeling and domain knowledge we already had identified a list of
classes. We present them here once again:
 Member ,Book , Transaction (of books) , Librarian , Employee , Book Inventory , Distributor ,Order
Order Line Item , Payment , Invoice

Let's focus on the "Member", "Librarian" and "Employee" classes. The "Employee" class could be considered
as a parent class, some of whose properties are inherited by the "Member" class. Again, "Librarian" is just a
special type of "Member" with certain extra privileges. However, it may be noted here that LIS in no way
would be interested to know about employees who are not members of LIS. Moreover, to distinguish between
a normal member and a librarian, one could define a set of roles, and assign them appropriately to the
members. This approach provides a flexible approach to manage users. For example, if the librarian goes on a
leave, another member could be assigned the librarian role temporarily. Therefore, we decide to have a single
"Member" class, whose instances could have one or more roles. This is shown in figure 3 with the
"association" relationship between "Member" and "Role" classes. The "Role" class could consist of a list of
available roles. A list could be maintained in the "Member" class to indicate which roles are associated with a
particular instance of it
The "LIS" class consists of several modules: "RegistrationManager", "IssueManager" "ReturnManager", and
"PurchaseManager". Their "composition" relationship with "LIS" indicates that any of these individual modules
wouldn't exist without the existence of "LIS". The "IssueManager" class is responsible for issue and reissue of
books while considering the two-times reissue constraint placed on a book.
The relation between "IssueManager" class and "Book" class is shown as "weak dependency". This is due to
the reason that the "IssueManager" class do not require a "Book" as it's member variable. Rather, when an user
has issued a book, the concerned method in "IssueManager" just needs to update the status of the corresponding
book. No instance of "Book" needs to be created. The arrow from "IssueManager" to "Book" indicates that only
the former knows about the "Book" class. The relationship between "PurchaseManager" and "Distributor" is,
however, not a weak dependency. The "PurchaseManager" class has a member variable of type "Distributor",
which keeps track of the distributor selected for the current purchase.

Exercise :

Experiment - 06
Name of experiment : Modeling Data Flow Diagram

to borrow a book (or return it) with ease while sitting at his desk/chamber. The system also enables a member to
extend the date of his borrowing if no other booking for that particular book has been made. For the library staff,
this system aids them to easily handle day-to-day book transactions. The librarian, who has administrative
system to browse/search books online. However, issuing or returning books is restricted to valid users (members)
of LIS only.
Figure 1 shows the context-level DFD for LIS. The entire system is represented with a single circle (process). The
external entities interacting with this system are members of LIS, library staff, librarian, and non-members of LIS.
Two databases are used to keep track of member information and details of books in the library.
Let us focus on the external entity, Member. In order to issue or return books a member has to login to the system.
The data flow labeled with "Login credentials" indicate the step when a member authenticates himself by
providing required information (user ID, password). The system in turn verifies the user credentials using
information stored in the members database. If all information are not provided correctly, the user is shown a
login failure message. Otherwise, the user can continue with his operation. Note that a DFD does not show
conditional flows. It can only summarize the information flowing in and out of the system.
The data flow with the label "Requested book details" identify the information that the user has to provide in order
to issue a book. LIS checks with the books database whether the given book is available. After a book has been
issued, the transaction details is provided to the member.

Figure 1: Context-level DFD for Library Information System
The level-1 DFD is shown in figure 2. Here, we split the top-level view of the system into multiple logical
components. Each process has a name, and a dotted-decimal number in the form 1.x. For example, the process
"Issue book" has the number 1.2, which indicates that in the level 1 DFD the concerned process is numbered 2.
Other processes are numbered in a similar way.
Figure 2: Level 1 DFD for Library Information System

Comparing figures 1 and 2 one might observe that the information flow in and out of LIS has been preserved. We
observe in figure 2 that the sub-processes themselves exchange information among themselves. These information
flows would be, in turn, preserved if we decompose the system into a level 2 DFD.
Finally, in order to eliminate intersecting lines and make the DFD complex, the Member external entity has been
duplicated in figure 2. This is indicated by a * mark near the right-bottom corner of the entity box.
Exercise:-
Draw a context-level DFD to depict the typical user authentication process used by any system. An user gives
two inputs -- user name and password.

Software Engineering

Uploaded by

Copyright:

Available Formats

Software Engineering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

Experiment - 02

Name of experiment : Functional and non-functional dependency

Case Study : A Library Information System for SE VLabs Institute

Name : Rashida Jahan Roll No : CSE2016/006

Identification of non-functional requirements

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name of experiment : E-R Modeling from problem statement

Case Study : A Library Information System for SE VLabs Institute

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Table 1: List of actors

Table 2: List of use cases

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name of experiment : UML Class Diagram

Case Study : A Library Information System for SE VLabs Institute

Figure 1: Sequence diagram for "Issue Book"

Name : Rashida Jahan Roll No : CSE2016/006

Figure 2: Sequence diagram for "Purchase Books"

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name : Rashida Jahan Roll No : CSE2016/006

Name of experiment : Modeling Data Flow Diagram

Case Study : A Library Information System for SE VLabs Institute

Name : Rashida Jahan Roll No : CSE2016/006

Figure 2: Level 1 DFD for Library Information System

Name : Rashida Jahan Roll No : CSE2016/006

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.