Choose any one project(maximum two students in a group ) and do the

following experiments for that project

a. Student Result Management System

b. Library management system
c. Inventory control system
d. Accounting system
e. Fast food billing system
f. Bank loan system
g. Blood bank system
h. Railway reservation system
i. Automatic teller machine
j. Video library management system
k. Hotel management system
l. Hostel management system
m. E-ticking
n. Share online trading
o. Hostel management system
p. Resource management system
q. Court case management system
r. Attendance management system on e-portal
s. Language recognition system
t. Face recognition system
Experiment 1:

Prepare a SRS document in line with IEEE recommended standards.

Problem Statement : In this experiment student will prepare a Software Requirement

Specification (SRS) for any above chosen project .

Objective : The Software Requirements Specification is designed to document and describe

the agreement between the customer and the developer regarding the specification of the
software product requested. Its primary purpose is to provide a clear and descriptive “statement
of user requirements” that can be used as a reference in further development of the software
system.

Methodology/Scope:

A well-designed, well-written SRS accomplishes four major goals:

 It provides feedback to the customer. An SRS is the customer's assurance that the
development organization understands the issues or problems to be solved and the
software behaviour necessary to address those problems. Therefore, the SRS should be
written in natural language (versus a formal language, explained later in this article), in
an unambiguous manner that may also include charts, tables, data flow diagrams,
decision tables, and so on.
 It decomposes the problem into component parts. The simple act of writing down
software requirements in a well-designed format organizes information, places borders
around the problem, solidifies ideas, and helps break down the problem into its
component parts in an orderly fashion.
 It serves as an input to the design specification. As mentioned previously, the SRS
serves as the parent document to subsequent documents, such as the software design
specification and statement of work. Therefore, the SRS must contain sufficient detail in
the functional system requirements so that a design solution can be devised.
 It serves as a product validation check. The SRS also serves as the parent
document for testing and validation strategies that will be applied to the requirements for
verification.

SRSs are typically developed during the first stages of "Requirements Development," which
is the initial product development phase in which information is gathered about what
requirements are needed--and not. This information-gathering stage can include onsite visits,
questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or
needs analysis of the customer or client's current business environment. The actual
specification, then, is written after the requirements have been gathered and analyzed.

SRS should address the following

1
The basic issues that the SRS shall address are the following:

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s
hardware, other hardware, and other software?
c) Performance. What is the speed, availability, response time, recovery time of
various software functions, etc.?
d) Attributes. What are the portability, correctness, maintainability, security, etc.
considerations?
e) Design constraints imposed on an implementation. Are there any required standards
in effect, implementation language, policies for database integrity, resource limits,
operating environment(s) etc.

EXPECTED OUTCOME:

A sample of basic SRS Outline

Software Requirements Specification

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

2
Table of Contents

Revision History.............................................................................................................................ii
Document Approval......................................................................................................................ii
1. Introduction................................................................................................................................1
1.1 Purpose................................................................................................................................................1
1.2 Scope...................................................................................................................................................1
1.3 Definitions, Acronyms, and Abbreviations........................................................................................1
1.4 References...........................................................................................................................................1
1.5 Overview.............................................................................................................................................1
2. General Description...................................................................................................................2
2.1 Product Perspective.............................................................................................................................2
2.2 Product Functions...............................................................................................................................2
2.3 User Characteristics............................................................................................................................2
2.4 General Constraints.............................................................................................................................2
2.5 Assumptions and Dependencies.........................................................................................................2
3. Specific Requirements...............................................................................................................2
3.1 External Interface Requirements.........................................................................................................3
3.1.1 User Interfaces..............................................................................................................................3
3.1.2 Hardware Interfaces......................................................................................................................3
3.1.3 Software Interfaces.......................................................................................................................3
3.1.4 Communications Interfaces..........................................................................................................3
3.2 Functional Requirements....................................................................................................................3
3.2.1 <Functional Requirement or Feature #1>.....................................................................................3
3.2.2 <Functional Requirement or Feature #2>.....................................................................................3
3.3 Use Cases............................................................................................................................................3
3.3.1 Use Case #1...................................................................................................................................3
3.3.2 Use Case #2...................................................................................................................................3
3.4 Classes / Objects.................................................................................................................................3
3.4.1 <Class / Object #1>.......................................................................................................................3
3.4.2 <Class / Object #2>.......................................................................................................................3
3.5 Non-Functional Requirements............................................................................................................4
3.5.1 Performance..................................................................................................................................4

iii
3.25 Reliability.....................................................................................................................................4
3.5.3 Availability.........................................................................................................................4
3.5.4 Security...............................................................................................................................4
3.5.5 Maintainability....................................................................................................................4
3.5.6 Portability............................................................................................................................4
3.6 Inverse Requirements................................................................................................................4
3.7 Design Constraints....................................................................................................................4
3.8 Logical Database Requirements...............................................................................................4
3.9 Other Requirements..................................................................................................................4
4. Analysis Models................................................................................................................4
4.1 Sequence Diagrams...................................................................................................................5
4.3 Data Flow Diagrams (DFD)......................................................................................................5
4.2 State-Transition Diagrams (STD).............................................................................................5
5. Change Management Process..........................................................................................5
A. Appendices........................................................................................................................5
A.1 Appendix 1...............................................................................................................................5
A.2 Appendix 2...............................................................................................................................5

Sample questions:

1. Which is the IEEE standard for SRS?

Ans. Std 830-1998

2. What is the full form of SRS?

Ans. Software requirement Specification.

3. What are the quality attributes of SRS?

Ans. Reliability, security and availability.

4. Distinguish between functional and non-functional requirements of SRS.

Ans.

4
v
1. Introduction
The introduction to the Software Requirement Specification (SRS) document
should provide an overview of the complete SRS document. While writing this
document please remember that this document should contain all of the
information needed by a software engineer to adequately design and implement
the software product described by the requirements listed in this document.
(Note: the following subsection annotates are largely taken from the IEEE Guide
to SRS).

1.1 Purpose
What is the purpose of this SRS and the (intended) audience for which it is
written?

1.2 Scope
This subsection should:

(1) Identify the software product(s) to be produced by name; for example, Host
DBMS, Report Generator, etc

(2) Explain what the software product(s) will, and, if necessary, will not do

(3) Describe the application of the software being specified. As a portion of this,
it should:

(a) Describe all relevant benefits, objectives, and goals as precisely as

possible. For example, to say that one goal is to provide effective
reporting capabilities is not as good as saying parameter-driven, user-
definable reports with a 2 h turnaround and on-line entry of user
parameters.

(b) Be consistent with similar statements in higher-level specifications (for

example, the System Requirement Specification), if they exist. What is the
scope of this software product?

1.3 Definitions, Acronyms, and Abbreviations

This subsection should provide the definitions of all terms, acronyms, and
abbreviations required to properly interpret the SRS. This information may be
provided by reference to one or more appendixes in the SRS or by reference to
other documents.

1.4 References
This subsection should:

(1) Provide a complete list of all documents referenced elsewhere in the SRS, or
in a separate, specified document.

6
(2) Identify each document by title, report number - if applicable - date, and
publishing organization.

(3) Specify the sources from which the references can be obtained.

This information may be provided by reference to an appendix or to another

document.

1.5 Overview
This subsection should:

(1) Describe what the rest of the SRS contains

(2) Explain how the SRS is organized.

2. General Description
This section of the SRS should describe the general factors that affect 'the product
and its requirements. It should be made clear that this section does not state
specific requirements; it only makes those requirements easier to understand.

2.1 Product Perspective

This subsection of the SRS puts the product into perspective with other related
products or projects. (See the IEEE Guide to SRS for more details).

2.2 Product Functions

This subsection of the SRS should provide a summary of the functions that the
software will perform.
2.3 User Characteristics
This subsection of the SRS should describe those general characteristics of the
eventual users of the product that will affect the specific requirements. (See the
IEEE Guide to SRS for more details).
2.4 General Constraints
This subsection of the SRS should provide a general description of any other
items that will

limit the developer’s options for designing the system. (See the IEEE Guide to
SRS for a partial list of possible general constraints).

2.5 Assumptions and Dependencies

This subsection of the SRS should list each of the factors that affect the
requirements stated in the SRS. These factors are not design constraints on the
software but are, rather, any changes to them that can affect the requirements in
the SRS. For example, an assumption might be that a specific operating system
will be available on the hardware designated for the software product. If, in fact,
the operating system is not available, the SRS would then have to change
accordingly.

7
3. Specific Requirements
This will be the largest and most important section of the SRS. The customer
requirements will be embodied within Section 2, but this section will give the D-
requirements that are used to guide the project’s software design, implementation,
and testing.

Each requirement in this section should be:

 Correct
 Traceable (both forward and backward to prior/future artifacts)
 Unambiguous
 Verifiable (i.e., testable)
 Prioritized (with respect to importance and/or stability)
 Complete
 Consistent
 Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefuly organize the requirements presented in

this section so that they may easily accessed and understood. Furthermore, this
SRS is not the software design document, therefore one should avoid the tendency
to over-constrain (and therefore design) the software project within this SRS.
3.1 External Interface Requirements
3.1.1 User Interfaces

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

3.2 Functional Requirements

This section describes specific features of the software project. If desired, some
requirements may be specified in the use-case format and listed in the Use Cases
Section.
3.2.1 <Functional Requirement or Feature #1>
3.2.1.1 Introduction

3.2.1.2 Inputs

3.2.1.3 Processing

3.2.1.4 Outputs

3.2.1.5 Error Handling

3.2.2 <Functional Requirement or Feature #2>

…

8
3.3 Use Cases
3.3.1 Use Case #1

3.3.2 Use Case #2

…

3.4 Classes / Objects

3.4.1 <Class / Object #1>
3.4.1.1 Attributes

3.4.1.2 Functions

<Reference to functional requirements and/or use cases>

3.4.2 <Class / Object #2>

…

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these
requirements must be achieved at a system-wide level rather than at a unit level.
State the requirements in the following sections in measurable terms (e.g., 95% of
transaction shall be processed in less than a second, system downtime may not
exceed 1 minute per day, > 30 day MTBF value, etc).
3.5.1 Performance

3.5.2 Reliability

3.5.3 Availability

3.5.4 Security

3.5.5 Maintainability

3.5.6 Portability

3.6 Inverse Requirements

State any *useful* inverse requirements.
3.7 Design Constraints
Specify design constrains imposed by other standards, company policies,
hardware limitation, etc. that will impact this software project.
3.8 Logical Database Requirements
Will a database be used? If so, what logical requirements exist for data formats,
storage capabilities, data retention, data integrity, etc.
3.9 Other Requirements
Catchall section for any additional requirements.

9
4. Analysis Models
List all analysis models used in developing specific requirements previously given
in this SRS. Each model should include an introduction and a narrative
description. Furthermore, each model should be traceable the SRS’s
requirements.
4.1 Sequence Diagrams
4.3 Data Flow Diagrams (DFD)
4.2 State-Transition Diagrams (STD)

5. Change Management Process

Identify and describe the process that will be used to update the SRS, as needed,
when project scope or requirements change. Who can submit changes and by
what means, and how will these changes be approved.

Appendices may be used to provide additional (and hopefully helpful)

information. If present, the SRS should explicitly state whether the information
contained within an appendix is to be considered as a part of the SRS’s overall set
of requirements.

Example Appendices could include (initial) conceptual documents for the

software project, marketing materials, minutes of meetings with the customer(s),
etc.

A.1 Appendix 1
A.2 Appendix 2

Sample questions:

1. Which is the IEEE standard for SRS?

2. What is the full form of SRS?

3. What are the quality attributes of SRS?

4. Distinguish between functional and non-functional requirements of SRS.

10
 Experiment 2

Draw the Use Case diagram and specify the role of each of the actors.

Problem Statement : In this experiment student will prepare a Use Case diagram
for any chosen project.

Objective : The purpose of this diagram is to demonstrate how objects will interact
with particular project and map out the basic functionality of the system.

According to the UML specification a use case diagram is “a diagram that shows the
relationships among actors and use cases within a system.” Use case diagrams are often
used to:

 Provide an overview of all or part of the usage requirements for a system or

organization in the form of an essential model or a business model
 Communicate the scope of a development project
 Model your analysis of your usage requirements in the form of a system use case
model

Use case models should be developed from the point of view of your project stakeholders
and not from the (often technical) point of view of developers. There are guidelines for:

Use Cases

Actors

Relationships

System Boundary Boxes

1. Use Cases

A use case describes a sequence of actions that provide a measurable value to an actor. A
use case is drawn as a horizontal ellipse on a UML use case diagram.

1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology
3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram
4. Imply Timing Considerations By Stacking Use Cases.

2. Actors

An actor is a person, organization, or external system that plays a role in one or more
11
interactions with your system (actors are typically drawn as stick figures on UML Use
Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don’t Interact With One Another
8. Introduce an Actor Called “Time” to Initiate Scheduled Events

3. Relationships

There are several types of relationships that may appear on a use case diagram:

 An association between an actor and a use case

 An association between two use cases
 A generalization between two actors
 A generalization between two use cases

Associations are depicted as lines connecting two modeling elements with an optional
open-headed arrowhead on one end of the line indicating the direction of the initial
invocation of the relationship. Generalizations are depicted as a close-headed arrow with
the arrow pointing towards the more general modeling element.

1. Indicate An Association Between An Actor And A Use Case If The Actor

Appears Within The Use Case Logic
2. Avoid Arrowheads On Actor-Use Case Relationships
3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case
Steps
5. Introduce <<extend>> associations sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, <<includes>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case To The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. Apply the “Is Like” Rule to Use Case Generalization
12. Place an Inheriting Use Case Below The Base Use Case
13. Apply the “Is Like” Rule to Actor Inheritance
14. Place an Inheriting Actor Below the Parent Actor

12
4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name
suggests it indicates the scope of your system – the use cases inside the rectangle
represent the functionality that you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

we start by identifying as many actors as possible. You should ask how the actors
interact with the system to identify an initial set of use cases. Then, on the diagram, you
connect the actors with the use cases with which they are involved. If actor supplies
information, initiates the use case, or receives any information as a result of the use case,
then there should be an association between them.

Procedure (for rational rose):

13
1. Open the project created by starting up Rational Rose Enterprise Edition,
choosing Create New Model and clicking the Existing tab and selecting the
model by name. If a class diagram is open in the application window, close
it.
2. In the Browser window, select Use Case View. Double click on Main. This
opens the main Use Case. Note that the diagram toolbar has changed to
reflect the fact that the active diagram is a Use Case diagram.

3. A Use Case can be added by clicking on the Use Case icon on the toolbar and
then clicking in the active diagram.

14
4. The Use Case can be renamed while it is highlighted in blue. To rename it
later, right click the use case and choose the Specification from the menu:
5. The Use Case can be renamed while it is highlighted in blue. To rename it
later, right click the use case and choose the Specification from the menu:
6. The use case can be renamed here.

15
7. Continue to add all necessary Use Cases to the diagram.
8. . Add actors to the diagram by clicking on the Actor icon a clicking on the
active diagram. A new actors are named, they a in a list below an new actor
that is represented o diagram until such time as the new actor is named. This
allows for the same actor to appear on a diagram twice. If the user decides to
place the actor on the diagram twice, then (s)he will be prompted with the
warning ‘Newclass will be deleted from the model’ Yes/No. WARNING: If
you want to delete a duplicate icon from the model, be sure to use DEL – not
Delete from Model. Delete from Model will remove all information on that
actor / usecase/ class from the model.!!! nd s ppear y n the
9. Use the ‘Unidirectional Association’ icon to draw the associations between
actors and use cases.
10. Use the ‘Extend Use Case’ icon to extend a use case from another one. If
there is no button on the toolbar for this, right click on the toolbar and choose
“customize…”. This will bring up the set of possible buttons. ‘Extend Use
Case’ and ‘Include Use Case’ are about half way down the list. Add these to
the toolbar and close the dialogue box. 8. Use the ‘Include Use Case’ to
include the functionality of one use case in another.
11. . Note that the items appear in the browser window when you insert them into
the diagram.
12. . If you wish to copy the diagram into Word, while the diagram is active,
choose Edit from the standard toolbar and ‘Copy Active Diagram’. This will
put the diagram into the paste buffer.
13. An actor can be a generalisation of another actor or actors.
16
 14. The Font of the diagram can be changed by changing the ‘General’ tab in the
model properties, or by using the ‘format’ menu from the toolbar.
15. If you want to name a Use Case and you have left it, you can select it, right
click and choose ‘Open Specification’. Type over the current highlighted
name.
16. When you ‘save’ it saves the entire model. If you want to add another
diagram to this model, reopen the model.

EXPECTED OUTCOME:-
Some Sample Use Case Diagrams are given below for illustration purpose:

Authentication

User/BT Searching

Data Transfer
Administrator

Mobility Management

Signalling Management

Software Updation

Use Case Diagram for Bluetooth Software

17
Solution

1. Use case diagrams consist of:

Actor

Actor in a use case diagram is any entity that performs a role in one given system. This
could be a person, organization or an external system and usually drawn like skeleton
shown below.

Use Case

A use case represents a function or an action within the system. Its drawn as an oval and
named with the function.

18
Relationships in Use Case Diagrams

There are five types of relationships in a use case diagram. They are

 Association between an actor and a use case

 Generalization of an actor

 Extend relationship between two use cases

 Include relationship between two use cases

 Generalization of a use case

2. How to Create a Use Case Diagram:

Identifying Actors

Actors are external entities that interact with your system. It can be a person, another
system or an organization.

Identifying Use Cases

Now it’s time to identify the use cases. A good way to do this is to identify what the
actors needs from the system. In a banking system a customer will need to open accounts,
deposit and withdraw funds, request check books and similar functions. So all of these
can be considered as use cases.
3. Fine Tune Use Cases:
Fine tune it and add extra layers of detail to it.

Look for Common Functionality to use Include

Look for common functionality that can be reused across the system. If you find two or
more use cases that share common functionality you can extract the common functions
and add it to a separate use case. Then you can connect it via the include relationship to
show that its always called when the original use case is executed.

19
Is it Possible to Generalize Actors and Use Cases
There maybe instances where actors are associated with similar use cases while triggering
few use cases unique only to them. In such instances you can generalize the actor to show
the inheritance of functions. You can do a similar thing for use case as well.

One of the best examples of this is “Make Payment” use case in a payment system. You
can further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All
of them have the attributes and the functionality of a payment with special scenarios
unique to them.

Optional Functions or Additional Functions

There are some functions that are triggered optionally. In such cases you can use the
extend relationship and attach and extension rule to it. In the below banking system
example “Calculate Bonus” is optional and only triggers when a certain condition is
matched.

Steps (screen shots)

1. Create a new Use Case

20
2. Add Actors

21
3. Add Use Cases

22
4. Add Actors Use Cases Uni Directional Associations

5. Add Generalization relations in use cases

23
6. Add Include relationship in Use Case

24
6. Add extend relationship between use cases

25
7. Generalize actors (optional)

Sample questions:
1. How a UML Use Case is Diagram different from a traditional flow chart?

2. How to identify the actors in a UCD?

3. What is a UML Use Case Diagram (UCD), and when should you use it?

26
 Experiment 3

Draw the Activity diagram.

Problem Statement : In this experiment student will prepare a Activity diagram for
any chosen project.

Objective : - UML 2 activity diagrams are typically used for business process
modeling, for modeling the logic captured by a single use case or usage scenario, or for
modeling the detailed logic of a business rule. Although UML activity diagrams could
potentially model the internal logic of a complex operation it would be far better to
simply rewrite the operation so that it is simple enough that you don’t require an activity
diagram. In many ways UML activity diagrams are the object-oriented equivalent of flow
charts and data flow diagrams (DFDs) from structured development.

Let’s start by describing the basic notation:

 Initial node. The filled in circle is the starting point of the diagram. An initial
node isn’t required although it does make it significantly easier to read the
diagram.
 Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An activity may
be physical, such as Inspect Forms, or electronic, such as Display Create Student
Screen.
 Flow/edge. The arrows on the diagram. Although there is a subtle difference
between flows and edges,never a practical purpose for the difference although.

 Fork. A black bar with one flow going into it and several leaving it. This denotes
the beginning of parallel activity.
 Join. A black bar with several flows entering it and one leaving it. All flows
going into the join must reach it before processing may continue. This denotes the
end of parallel processing.
 Condition. Text such as [Incorrect Form] on a flow, defining a guard which must
evaluate to true in order to traverse the node.
 Decision. A diamond with one flow entering and several leaving. The flows
leaving include conditions although some modelers will not indicate the
conditions if it is obvious.
 Merge. A diamond with several flows entering and one leaving. The implication
is that one or more incoming flows must reach this point until processing
continues, based on any guards on the outgoing flow.
 Partition. If figure is organized into three partitions, it is also called swimlanes,
indicating who/what is performing the activities (either the Applicant, Registrar,
or System).
 Sub-activity indicator. The rake in the bottom corner of an activity, such as in
the Apply to University activity, indicates that the activity is described by a more
finely detailed activity diagram.

27
 Flow final. The circle with the X through it. This indicates that the process stops
at this point.

PROCEDURE:

1. Right click on the Use Case View and choose New and
Activity diagram. The tools in the toolbar that will be need
are :-

EXPECTED OUTCOME:- Submitting Expenses

28
Solution

(Steps: screen shots)

1. Create a new Activity diagram

2. Create 3 notes

29
3. Create start state

30
4. Create activity and connect with start state

4. Create more activities and connect them

31
5. Create Stop State and connect with 1 activity

6. Add vertically oriented synchronization bars

32
Sample Questions:

1. What is purpose of using an activity diagram?

2. Contrast between fork and join.

3. How are the initial and final states of an activity diagram

represented?

33
 Experiment 4

Identify the classes. Classify them as weak and strong classes and draw the
class diagram.

Problem Statement : In this experiment student will prepare classify different type
of classes in the class diagram for any chosen project.

Objective : -
A class diagram is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, and the relationships between the
classes.

Class diagrams show the classes of the system, their inter-relationships, and the
operations and attributes of the classes, Class diagrams are typically used, although
all at once, to:

34
  Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis model
 Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting
specifications that describe model elements including classes, relationships between
classes, and interfaces. There are guidelines

1. General issues
2. Classes (Weak &Strong)
3. Interfaces
4. Relationships
5. Inheritance
6. Aggregation and Composition

PROCEDURE:-

1. After completing the sequence diagrams and collaboration

diagram which are a part of the interaction diagrams. In
Rational Rose, right click on the “Use Case View” and select
new class diagram.
2. Enter the class name (here “Hostel Class”).

3.Click the cursor on the block representing class from

the table of predefined symbols into the screen
4. Select a new Class
5.Double click on the class formed to enter the class name in the general
field .
6. In the operation field right click and select the inset option to add class
operations or functions.
7. Input the name of the new operation , its return type in the respective
columns.
8. In the attribute field, enter the attribute names , their type and the parent
class in the respective columns.
9. Enter all the attributes and operations , and press “OK” button to get the required
class.
10. While building the classes of the system if you want to make nested class in
some main class(here “LOGIN” class), then insert classes in the ‘Nested’ field of
class specification(like the “EDIT_RECORD” class)
11. Select the nested class and drag it to the Class diagram window
12. All the required classes were built completely with there operations, attributes
and nested classes , into the class diagra
 13. Now we want to show the relationships between the various classes. To
show an ASSOCIATION relation select a block named ‘association’ from the
blocks to the left and draw the arrows between the requisite classes.
14. To show a GENERALIZATION or inheritance relation select a block named
‘generalization’ from the blocks to the left and draw the arrows between the
requisite classes.
15. Select the ‘text box’ block from the blocks field to describe any relation with the
help of text.
16. Enter text by placing text boxes over the various relationship arrows
EXPECTED OUTCOME:-

Solution
Step1. Choose new class diagram from logical view and give some suitable name
Step2. Click on class icon and click in draw area and choose specifications and
name class to one of actors
Step 3. Add attributes
Step 4. Add operations

Step 5. Add Associations

Sample Questions:
1. Differentiate between association and aggregation.
2. What is the relationship between abstract data types and classes?
 Experiment 5

Draw the sequence diagram for any two scenarios

Problem Statement : In this experiment student will prepare sequence diagram for
any two scenarios .

Objective : - UML sequence diagrams model the flow of logic within the system in a
visual manner, enabling the user both to document and validate the logic, and are
commonly used for both analysis and design purposes. Sequence diagrams are the most
popular UML artifact for dynamic modeling, which focuses on identifying the behavior
within your system. Sequence diagrams, along with class diagrams and physical data
models are the most important design-level models for modern application development.

Sequence diagrams are typically used to model:

1. Usage scenarios. A usage scenario is a description of a potential way the system

is used. The logic of a usage scenario may be part of a use case, perhaps an
alternate course. It may also be one entire pass through a use case, such as the
logic described by the basic course of action or a portion of the basic course of
action, plus one or more alternate scenarios. The logic of a usage scenario may
also be a pass through the logic contained in several use cases. For example, a
student enrolls in the university, and then immediately enrolls in three seminars.
2. The logic of methods. Sequence diagrams can be used to explore the logic of a
complex operation, function, or procedure. One way to think of sequence
diagrams, particularly highly detailed diagrams, is as visual object code.
3. The logic of services. A service is effectively a high-level method, often one that
can be invoked by a wide variety of clients. This includes web-services as well as
business transactions implemented by a variety of technologies such as
CICS/COBOL or CORBA-compliant object request brokers (ORBs).

FIG .shows the logic for how to enroll in a seminar. One should often develop a system-
level sequence diagram to help both visualize and validate the logic of a usage scenario.
It also helps to identify significant methods/services, such as checking to see if the
applicant already exists as a student, which the system must support.
Figure . Enrolling in a seminar (method).

The dashed lines hanging from the boxes are called object lifelines, representing the life
span of the object during the scenario being modeled. The long, thin boxes on the
lifelines are activation boxes, also called method-invocation boxes, which indicate
processing is being performed by the target object/class to fulfill a message.

PROCDEURE:
 Click on the File menu and select New.
 Now from the Dialogue Box that appears ,select the language which you want
to use for creating your model.
In the left hand side window of Rational Rose right click on “Use Case view” and
select New>Sequence Diagram
 Enter the name of new Sequence file in the space provided, and then click on
that file name.
 You can now use the window that appears on right hand side to draw your Sequence
diagram using the buttons provided on the vertical toolbar.

EXPECTED OUTCOME:-
Solution

1. Select New -> Sequence diagram from Use Case View

Step 2. Create 3 objects and sequence of self directed to other object directed steps
Sample questions:
1. How a UML Use Case is Diagram different from a traditional flow chart?

2. How to identify the actors in a UCD?

3. What is a UML Use Case Diagram (UCD), and when should you use it?

Experiment 6
Draw a collaboration diagram.

Problem Statement : In this experiment student will prepare a Collaboration

Diagram for any above chosen project .

Objective :

A Collaboration diagram has classes, links and messages. The links show how the classes
communicate, while the messages travel on the links Any two classes that communicate
must be joined by links. Two classes may only be joined by one link but there can be
many messages passing between them. The messages can be directional so usage of
proper symbol is important .

 Objects drawn as rectangles

 Links between objects shown as lines connecting the linked object
 Messages shown as text,
 An arrow that points from the client to the supplier

PROCEDURE:

USING SEQUENCE DIAGRAM:-

 Double-click on the sequence diagram in the browser to open the diagram.
 Choose the Browse: Create Collaboration Diagram menu choice or press the F5
key.
 Rearrange the object and messages on the diagram as needed.

EXPECTED OUTCOME:-

Solution
V Experiment 5: Create Collaboration Diagram

From Sequence Diagram to Collaboration Diagram

In reality, sequence diagrams and collaboration diagrams show the same information, but
just present it differently. In fact, collaboration diagrams are so closely related to
sequence diagrams, that some modeling tools, such as Rational Rose, can automatically
create one type of diagram from the other.

To demonstrate this close relationship, this article will take a sequence diagram from the
previous article in this series and show how it translates into a collaboration diagram.
This sequence diagram is one of the design documents created for a research and
development library. This particular sequence, shown in Figure 1, documents the
interaction that occurs between business objects when determining how many items a
borrower can check out of the library.

Figure 1: A sequence diagram is ideal for showing the time-ordering of messages during
an object interaction.

If you open this sequence diagram in Rational® Rose and then press the F5 key, Rose
automatically generates the collaboration diagram shown in Figure 2. If you compare the
two diagrams, you'll see they both contain objects and messages. It also becomes clear
that it's much easier to determine the time ordering of messages by looking at the
sequence diagram and it's easier to see the relationships between objects by looking at the
collaboration diagram.

Figure 2: A collaboration diagram is best suited for showing the relationships between
objects involved in a collaboration.

However, before fully understanding this difference, you need to learn about the basic
elements of a collaboration diagram.

Collaboration Diagram Elements

There are three primary elements of a collaboration diagram:

 Objects
 Links
 Messages

Objects

Objects participating in a collaboration come in two flavors?supplier and client. Supplier

objects are the objects that supply the method that is being called, and therefore receive
the message. Client objects call methods on supplier objects, and therefore send
messages.

Collaboration diagrams are so closely related to sequence diagrams that some modeling
tools can automatically generate one type of diagram from the other.

In Figure 2, the Transaction object acts as a Supplier to the UI (User Interface) Client
object. In turn, the Fine object is a Supplier to the Transaction Client object.
Links

The connecting lines drawn between objects in a collaboration diagram are links. These
links are what set collaboration diagrams apart from sequence diagrams. They enable you
to see the relationships between objects. Each link represents a relationship between
objects and symbolizes the ability of objects to send messages to each other. A single link
can support one or more messages sent between objects. This is different from sequence
diagrams, where the lines drawn between objects represent messages sent from one
object to another.

As you can see by looking at Figure 2, the visual representation of a link is a straight line
between two objects. If an object sends messages to itself, the link carrying these
messages is represented as a loop icon. This loop can be seen on both the UI object and
the Transaction object.

Advertisement

Links in a collaboration diagram directly correlate to associations between classes in a

class diagram. For example, Figure 3 shows an association between the Transaction
object and Fine object as seen on a class diagram. Below the association, you can see a
corresponding link between the two objects. The association in the class diagram
translates into a link in a collaboration diagram.

Figure 3: Associations
specified in a class diagram can be represented as links in a collaboration diagram.

If you don't specify otherwise, a link is assumed to represent an association between

objects. However, you can also specify the following adornments for links to indicate
how objects are associated:

 Global (the object is visible as a global variable)

 Local (the object is visible as a local variable)
 Parameters (the object is visible as a parameter)
 Self (represents the ability of an object to send a message to itself)
Messages

Messages in collaboration diagrams are shown as arrows pointing from the Client object
to the Supplier object. Typically, messages represent a client invoking an operation on a
supplier object.

Message icons have one or more messages associated with them. Messages are composed
of message text prefixed by a sequence number. This sequence number indicates the
time-ordering of the message. For example, in the collaboration diagram in Figure 2, you
can follow the sequence numbers to determine the order of messages between objects:

1. Enter Borrower ID

1.1 CalcAmtCanBorrow

1.1.1 <<create>>

1.1.2 CalcBorrowerFines

1.1.3 GetBorrowersCheckedOutMedia

1.1.4 IsMediaOverdue

1.1.5 Amt Can Borrow

1.2 Display Invalid User Msg

Sample questions :

1. What are the elements of collaboration diagram?

2. Differentiate between collaboration and sequence diagram.

3. What is the purpose of using collaboration diagram?

Experiment 7:

Draw the start chart diagram .

Problem Statement : In this experiment student will prepare a state chart diagram
for any above chosen project .

Objective : State Chart Diagrams provide a way to model the various states in which
an object can exist. There are two special states: the start state and the stop state. The
Start state is represented by a block dot. The Stop state is represented by a bull’s eye..
A condition enclosed in square brackets is called a guard condition, and controls when a
transition can or cannot occur.
Process that occur while an object is in certain state are called actions.

PROCEDURE :-

 To insert new state diagram secondary click on Logical View.

 Select---New----State chart Diagram.
 A new diagram will be created, type in a name for the new
diagram.
 Now double click on the new diagram to open it on the stage
 To begin the diagram click on the START STATE button .
 Place a start icon on the diagram by clicking the mouse once,
 Now add states to the diagram , these make up the content of the
diagram .
 Click on the state button . Place the instances for each state into
the diagram and type in name for them.
 Now arrange the states better to fill the diagram better .
 Drag the states to new position to make the easiest layout to work
with.
 Add an end state to the diagram by clicking the END STATE
button . Place the instance into the diagram , Now add
relationship to the diagram .
 Click on the “STATE TRANSITION” button and drag arrows
between the appropriate states.
 To edit the specification secondary click on the relation lines and
select “ OPEN SPECIFICATIONS “ button .
 Add a name for event in the specifications . Then click on Apply
button and then OK button .
 There may be instances on the diagram where a state can join
more than one state .In this case add relationship in the same way.

EXPECTED OUTCOME:

State diagram for reservation of tickets & display confirmation form .

Solution
Statechart Diagram

A statechart diagram is a view of a state machine that models the changing behavior of a
state. Statechart diagrams show the various states that an object goes through, as well as
the events that cause a transition from one state to another.

Statechart diagram model elements

The common model elements that statechart diagrams contain are:

 States
 Start and end states
 Transitions
 Entry, do, and exit actions

A state represents a condition during the life of an object during which it satisfies some
condition or waits for some event. Start and end states represent the beginning or ending
of a process. A state transition is a relationship between two states that indicates when an
object can move the focus of control on to another state once certain conditions are met.
In a statechart diagram, a transition to self element is similar to a state transition.
However, it does not move the focus of control. A state transition contains the same
source and target state.
Actions in a Statechart diagram
Each state on a statechart diagram can contain multiple internal actions. An action is best
described as a task that takes place within a state. There are four possible actions within
a state:

 On entry
 On exit
 Do
 On event
Creating a statechart diagram in Rational Rose
A statechart diagram is usually placed under the Logical View package. Right-click on
the Logical View package and select New>Statechart Diagram to create a Statechart
Diagram. Name your diagram and then double-click on the name to open the diagram
work area.

States
Place the start state, , end state, , and states, , on the diagram work area by
selecting the respective icon from the diagram toolbox and then clicking on the work area
at the point where you want to place the states.

To name the states, double-click on the state. This action will bring up the State
Specification dialog box. In the General tab, type the name of your state in the Name text
box.

Actions
To add an action to a state, select the Actions tab in the State Specification dialog box,
right-click anywhere in the white area and select Insert from the shortcut menu. An
action will be automatically placed. Double-click the action item to bring up the Action
Specification dialog box. Select an action from the When drop-down list box. Type the
action description in the Name field. Click OK and then click OK again to exit the State
Specification dialog box.

Transitions
To create a transition to self , click the icon and then click on the state. To create
transitions between the states, click the icon and then click on the first state and drag
and release on the next state.

To name the transitions, double-click on the transition to bring up the State Transition
Specification dialog box. Type the name or label in the Event text box and click OK.
 Figure 1. shows a Statechart Diagram depicting the various elements of a state machine.

Transition to
self
Start
State

Transition

End
State State

Action

Figure: A state machine

Sample Questions :

Q1) What are the differences between activity and state chart diagram?

Q2) What is meant by State chart Diagram ?

Q3) List out the utilities of state chart diagram ?

 Experiment 8

Draw the component diagram .

Problem Statement : In this experiment student will prepare a component diagram

for any above chosen project .

Objective : Component is a physical and replaceable part of system and models physical
things Used to describe the dependencies between various software components .
Component diagrams show the physical placement of the components in the system

PROCEDURE :-

1. Double-click on the Main Diagram under the Component View package on the browser
to open the diagram.
2. Click to select a package and drag the package onto the diagram.
3. Repeat step 2 for each additional package.
4. Dependency relationships are added by selecting the dependency icon from the toolbar,
clicking on the package representing the client, and dragging the arrow to the package
representing the supplier.

EXPECTED OUTCOME:-
Solution
1. Double-click on the Main Diagram under the Component View package on the browser
to open the diagram.
2. Click to select a package and drag the package onto the diagram.
3. Repeat step 2 for each additional package.
4. Dependency relationships are added by selecting the dependency icon from the toolbar,
clicking on the package representing the client, and dragging the arrow to the package
representing the supplier.

Step 1:

Step 2: Add component

Step 3:
Add Relationships
Sample questions:
1. Differentiate between a package diagram and a component diagram.
2. What types of units’ does component diagram follows?
3. What is a delegation connector?
Experiment 9:

Perform Forward Engineering.

Problem Statement : In this experiment student will perform Forward Engineering

using JAVA for any above chosen project .

Objective:

Forward Engineering is the process of transforming a model into code through a mapping to
an implementation language. Forward engineering results in a loss of information, because
models written in the UML are semantically richer than any current object-oriented
programming language. In fact, this is a major reason why you need models in addition to
code. Structural features, such as collaborations, and behavioral features, such as
interactions, can be visualized clearly in the UML, but not so clearly from raw code.

To forward engineer a class diagram

 Identify the rules for mapping to your implementation language or languages of

choice.
 Depending on the semantics of the languages you choose, you may want to
constrain your use of certain UML features. For example, the UML permits you to
model multiple inheritance, but Smalltalk permits only single inheritance. You can
choose to prohibit developers from modeling with multiple inheritance (which
makes your models language-dependent), or you can develop idioms that transform
these richer features into the implementation language (which makes the mapping
more complex).

 Use tagged values to guide implementation choices in your target language. You can
do this at the level of individual classes if you need precise control. You can also do
so at a higher level, such as with collaborations or packages.

 Use tools to generate code.

Procedure :
Setting the Model’s Default Language to Java

If most of the classes in your model will be Java classes, you might want to set the
default language of the model Java. If you do this, each class you create will a Java class
by default.

To set the default language to Java:

1. Verify that the Java Add-In is active by selecting Add-In Manager from the add-Ins
menu. Activate it, if it is not currently active.

2. On the Tools menu, point to Model Properties and select Edit.

3. Click the Notation Tab in the Model Properties dialog.

4. Select Java from the Default Language list.

5. Click OK to set Java as the default language for your model.

Generating Java Source from a Class Diagram
1. Open your model and display the Class Diagram that contains the
classes and packages for which you want to generate Java source.
2. Select one or more classes or packages in the diagram.
3. Optionally, use the syntax checker before generating your Java
source. On the Tools menu, point to Java, and then click Generate Java.
EXPECTED OUTCOME: -

Solution

2. A Forward Engineering Example with Rational Rose:

2.1. Creating a class

1. In the logical view of your new model create a class called Point.
2. Right click the class Point and click New Attribute. Name the attribute itsX and itsY.

3. Right click again, click New Operation. Name the new operation getX(), and getY().

4. Your model should now look as follows:

5. In the browser window, click on Logical View and then expand on Point.
5. Double click itsX and set its type to int and also set its various modifiers [private, etc.], also for
itsY.

6. Similarly, double-click getX() and getY() in the browser and set its various attributes {return
type, etc.}
7. In the browser, left-click the Component View to create a new component called Point.

8. In the browser, drag the Point class to the Point component to assign the class to the Component.

9. Check the browser to make sure the class now has the component name next to it in parenthesis.

10. The browser should now look as follows:

11. In the browser or in the diagram, right-click the Point class, click Java > Generate Java.

12. Since this is the first time you’ve generated code for this model, Rational Rose displays a
mapping dialog prompting you to map the file it will generate to a directory in your class path. Click
on the class path name to select it, click on the component name to select it, and then click Map:
13. If code generation is successful, a “successful” dialog will be seen:

14. Click on Java > Browse Java Source to view the Java source:

15. Complete your code.

16. Save your model.

Creating an abstract Class

1. Use the same technique of creating a class, create an abstract class name Shape.

2. Double click on the class Shape to open Class specification and change its modifier into
abstract.

3. Add a member itsCenter with the type of Point.

4. Add a function getCenter() with return type is Point.

5. Add a function getArea() with return type is double and its modifier is abstract, your model
should look like the following:

6. Do step 7 – 16 as describe above, to generate Java file of this model, and save the model.

Creating Relationship between Classes

Inheritance

1. Create a new concrete class Circle with radius (double) as a member and getRadius()
(returning double) as its operation. It should be look like :
2. Generate inheritance relationship between Circle (subclass) and Shape (super class). Click on
generalization icon (see below figure) or select Tool  Create  Generalization.

3. While the pointer is displaying up arrow (generalization mode), drag it from Circle class to
Shape abstract class. Your model should look like :

4. Validate your model by double-clicking the class Circle, then verify that abstract class Shape
has been added in extends fields.

5. Do step 7 – 16 as describe above, to generate Java file of this model, and save the model. If it is
successful then the getArea() operation will automatically added to Circle class. As following
figure:
Suppose that we would like to create the Association relationship between Shape and Point. These
are steps:

1. Select Association icon (as shown bellow) or select Tool  Create  Association.

2. While the pointer is displaying up arrow (Association mode), drag it from Shape class to Point
class. Your model should look like:
3. Double click on the line between Shape and Point to open Association specification, to update
the properties such as Name, the Roles etc.

4. To modify type of relationship to Aggregate / Composition, or to add navigations and

multiplicity, select either Role A detail or Role B detail accordingly.

Exercises:
1. Create class Rectangle with length and width as members, and getWidth() and getLength() as
operation, make this rectangle as a subclass of Shape.
2. Create a class Picture that is consists of set of (more than one) Shape.
3. Reverse Engineering

import java.util.Random;

class ArrayUtil {

public static int[] randomIntArray(int length, int n) {

int[] a = new int[length];

Random generator = new Random();

for (int i = 0; i < a.length; i++)

a[i] = generator.nextInt(n);

return a;

public static void swap(int[] a, int i, int j) {

int temp = a[i];

a[i] = a[j];

a[j] = temp;

public static void print(int[] a) {

for (int i = 0; i < a.length; i++)

System.out.print(a[i] + " ");

System.out.println();

}
1. The following steps will be taken to reverse-engineer the model.

2. Check your class path by opening the Java Project Specification: click Tools > Java > Project
Specification. If needed, use Directories field of the Class Path tab to extend your class path.
Note that you must have a class path to the Java API library in order to reverse engineer.

3. In the browser or in a class or component diagram, right-click to display the shortcut menu.
Click Java > Reverse Engineer. This displays the Java Reverse Engineer dialog:

4. Click the Java file whose code you want to reverse engineer.

5. Click a folder in the tree to display the list of files it contains. (Traverse the tree to find the
folder or subfolder that contains the files to be reverse engineered.)

6. Do one of the following to place the Java files of the type you selected into the Selected Files
list:

- In the list box, click on one or more individual files and click Add.
 - Click Add All to add all of the files.

- Click Add Recursive to take all of the files of the selected file type that are contained in
the currently selected folder and all of its subfolders and place them in the Selected Files
list. (Use Add Recursive to select files in multiple folders without having to search for
and select each one.)

7. Click on one or more files in the Selected Files box or click Select All to confirm the entire list
of files to reverse engineer.

8. Click Reverse to create or update your model from the Java source you specified.

9. If Rose encounters an error, a message appears and you should check the Rose Log Window for
a description of the error. Otherwise, click done to close the dialog.

When reverse engineering is complete, you can view the new model elements in the browser, create
your own logical views, and drag and drop the new elements into the views you create.

Sample Questions:

1. What is forward engineering?

2. Differentiate between forward and reverse engineering.

Experiment 10

Perform Reverse Engineering.

Problem Statement:
In this experiment student will perform Reverse Engineering using JAVA for any above
chosen project .

Objective:

Reverse Engineering is the process of transforming code into a model through a mapping
from a specific implementation language. Reverse engineering results in a flood of
information, some of which is at a lower level of detail than you'll need to build useful
models. At the same time, reverse engineering is incomplete. There is a loss of information
when forward engineering models into code, and so you can't completely recreate a model
from code unless your tools encode information in the source comments that goes beyond
the semantics of the implementation language.

To reverse engineer a class diagram,

 Identify the rules for mapping from your implementation language or languages of
choice. This is something you'll want to do for your project or your organization as a
whole.
 Using a tool, point to the code you'd like to reverse engineer. Use your tool to
generate a new model or modify an existing one that was previously forward
engineered. It is unreasonable to expect to reverse engineer a single concise model
from a large body of code. You need to select portion of the code and build the
model from the bottom.

 Using your tool, create a class diagram by querying the model. For example, you
might start with one or more classes, then expand the diagram by following specific
relationships or other neighboring classes. Expose or hide details of the contents of
this class diagram as necessary to communicate your intent.

 Manually add design information to the model to express the intent of the design
that is missing or hidden in the code.

Procedure:-
1. Create a project
2. Add Project Caption
3. Add Referenced Libraries and Base Projects
4. Set the File Type and Analyze the Files
5. Evaluate the Errors
6. Select Export Options and export to Rose. Update Rose Model.

Expected Outcome:-

Solution

Reverse Engineering is the process of transforming code into a model through a mapping
from a specific implementation language.

Step 1: Copy Java project in a folder on your machine

Step 2: Open Rational Rose and select J2SE 1.3

We will get a figure as below:

Step 3: Once Rational Rose is ready with a new empty project, click on Tools -> Java /
J2EE -> Reverse Engineer

Step 4: We will need to add the folder we created earlier to the CLASSPATH. Use Edit
CLASSPATH to do this
Step 5: Now select all the java files in the right hand side window and add them to the main
window below. Once selected, click on 'Reverse'. This will reverse engineer UML content
from the Java files. Once this is complete, click done.

Step 6: Expand the logical view to see dit folder and all java components as class
specifications.
Step 7: Create a class diagram and then open it up. Drag over each of the three class
specifications into the diagram.

Sample questions:
1. Why it is difficult to reverse engineer a software?
2. How does reverse engineering affect project ideas?
3. Why reverse engineering is required?
 Experiment 11

Draw the deployment diagram .

Problem Statement : In this experiment student will prepare a deployment diagram

for any above chosen project .

Objective : Deployment diagrams show the interconnection of the hardware and

software components . Visualizes the distribution of components across the enterprise
Nodes: They are Run-time physical object that represents a computational resource,
generally having at least a memory and often processing capability as well . Formed by
Nodes, connections ( with stereo types) and components

PROCEDURE: -

Rose automatically creates the deployment diagram.

1. To open the diagram, double-click on the Deployment Diagram on the browser.
2. To create a node, click to select the Processor icon, and click on the diagram to place the
node.
3. With the node still selected, enter the name of the node.
4. To create a connection between nodes, click to select the connection icon from the
toolbar, click on one node on the deployment diagram, and drag the connection to the other
node

EXPECTED OUTCOME:

Solution
 1. Allow the capturing of the topology of the system nodes, including the assignment
of run-time elements to nodes
2. Allows to visually see potential bottlenecks

3. Formed by Nodes, connections (Shown with stereo types) and devices

Step 1: Create a new blank Deployment Diagram

Step 2 Add a Processor node used to show a system or software

Step 3: Add a device node to show a device of system or interfaces used
Step 4: Show the connection in devices and nodes

Step 5: Add the connection between nodes and edit connection specifications
Sample Questions :

Q1) what are the types of nodes used in deployment diagram?

Q2) what does a deployment diagram consists of?

Q3) List out the ways to represent nodes in a deployment diagram?

Experiment 12:
Identifying Requirements from Problem Statements .

Problem Statement : In this experiment student will create functional and non
functional requirement from any given Problem Statements .

Objective : To generalize students for collecting functional and non functional requirements
for any given problem statements of case study.

PROCEDURE: -

1) Case study will be provided to students for distinguishing functional and non functional
requirements .

EXPECTED OUTCOME:

Functional Requirements :-
 Business Rules
 Transaction corrections, adjustments and cancellations

 Administrative functions

 Authentication

 Authorization levels

 Audit Tracking
 External Interfaces

 Certification Requirements

 Reporting Requirements

 Historical Data

 Legal or Regulatory Requirements

Non Functional Requirements :-

 Performance – for example Response Time, Throughput, Utilization, Static Volumetric
 Scalability

 Capacity

 Availability

 Reliability

 Recoverability

 Maintainability

 Serviceability

 Security

 Regulatory

 Manageability

Sample Questions:
Q1) List out different types of requirements in problem statements?
Q2) What is brainstorming?
Q3) Explain the significance of domain analysis?
Experiment 13:
Modeling UML Use Case Diagram and Capturing Use Case Scenarios

Problem Statement: In this experiment student will prepare classify different type of classes
in the class diagram for any chosen project.

Objective : - A class diagram is a type of static structure diagram that describes the
structure of a system by showing the system's classes, their attributes, and the
relationships between the classes.

There are guidelines

1. General issues

2. Classes (Weak &Strong)

3. Interfaces
 4. Relationships

5. Inheritance

6. Aggregation and Composition

EXPECTED OUTCOME:

…..Whatever you have observed your own project

Sample Questions:
1. Which diagram in UML shows a complete or partial view of the structure of a
modeled system at a specific time?
2. Differentiate between primary and secondary actors.
3. Differentiate between specialization and generalization.

Experiment 14:
E-R modeling from the problem statement. In this experiment student will create E-R
diagram from any given Problem Statements .

Objective : To generalize students for creating E-R diagram for any given problem
statements of case study.

PROCEDURE: -

1) Case study will be provided to students for distinguishing functional and non functional requirements .

Expected outcome

Sample Questions : -

Q1) What is an E-R Diagram ?

Q2) Compare and contrast between weak entity and strong entity ?

Q3) What is the relationship between the class diagram in UML and the Entity relationship
diagram ?