Sie sind auf Seite 1von 93

Practical Workbook

Software Engineering

Name : _____________________________
Year : _____________________________
Batch : _____________________________
Roll No : _____________________________
Department: _____________________________

Dept. of Computer & Information Systems Engineering


NED University of Engineering & Technology,
Karachi 75270, Pakistan
INTRODUCTION

This practical workbook of Software Engineering appropriately covers all the phases followed in
Software Development Life Cycle (SDLC). Since major phases of SDLC use CASE (Computer
Aided Software Engineering) tools therefore, several such tools are covered in this workbook to help
the students in getting hand-on experience with them.

The First lab session is about the feasibility study which is the first phase of SDLC. In this lab
session a detailed overview of the feasibility study and its implementation is covered. Two case
studies are also included to make students learn in detail about the realistic feasibility study material.

Second lab session covers the importance of documentation as many of the SDLC phases are to be
presented in the form of documentation. In this lab session different types of documentation are
discussed along with the documentation standards. Steps followed during document preparation are
also discussed. SRS template is also present in the appendix.

Lab session 3 covers the CASE tool Ms Project, which is used for project planning. It covers step by
step guidance for creating a project plan and to view different diagrams generated by the software.

The software design phase is covered in next four lab sessions using UML (Unified Modeling
Language) as the CASE tool. Starting from overview of UML, in which various windows and other
available options are explored, it moves on by describing in detail the creation of Use case diagram,
Data Flow Diagram, Class Diagram and State Transition Diagram.

Next phase of SDLC is software coding or implementation. Here, ASP.Net is selected which is
covered in the next six lab sessions. It begins with getting user familiarized with the ASP.Net
environment and adding some basic controls and field validation to the web form. Login controls
and Postback events are also covered. Advanced and helpful topics like adding Database, ActiveX
components, Cascading Style Sheets and Master Pages are also discussed.

The last lab session covers the steps followed during software testing emphasizing over the test
patterns being applied to the software.
CONTENTS

Lab Session No. Object Page No.

1 Learning the concepts of Feasibility Study. 1

2 Understanding the concepts of Software Documentation. 6

3 Learning Project Management. 12

4 Getting familiarized with the Unified Modeling Language (UML) 18


Environment.

5 Working with the Use-case View of UML. 26

6 Working with the Class Diagrams of UML. 35

7 Working with the State Transition Diagrams of UML. 40

8 Learning the basics of ASP.Net. 44

9 Exploring some controls and the concept of field validation in 49


ASP.Net.

10 Exploring the working of Login controls and some basic Postback 53


controls in ASP.Net.

11 Working with Databases in ASP.Net. 56

12 Exploring some concepts of Cascading Style Sheets in ASP.Net. 61

13 Working with Master Pages in ASP.Net. 65

14 Learning to perform software testing 68

Appendix 74
Software Engineering Lab Session 01
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 01
OBJECT
Learning the concepts of Feasibility Study.

THEORY
The development of software begins with requirement gathering and their analysis. The
Software Requirements are the descriptions of the system services and constraints that are
generated during the requirements engineering process. Before the software requirements are
gathered and analysed, it is necessary to do some research to study the impact of the software,
which is to be developed, over the clients business. This research is known as Feasibility study.

Software Requirements Engineering Process

It is the process of establishing the services that the customer requires from a system and the
constraints under which it operates and is developed.

The processes used for RE vary widely depending on the application domain, the people
involved and the organisation developing the requirements. However, there are a number of
generic activities common to all processes

Feasibility Studies
Requirements elicitation and analysis
Requirements validation
Requirements management

The Feasibility Study

The Feasibility Study is a combination of a market study and an economic analysis that provides
an investor with knowledge of both the environment where a project exists and the expected
return on investment to be derived from it.

Feasibility Study may also be defined as:

A preliminary study undertaken before the real work of a project starts to ascertain the
likelihood of the projects success.
A small-scale investigation of a problem to ascertain whether a proposed research
approach is likely to provide useful data.
An analysis of the practicability of a proposal.
A study that usually recommends selection of a cost-effective alternative.
A study that decides whether or not the proposed system is worthwhile.

1
Software Engineering Lab Session 01
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Feasibility Study is a study undertaken:


To assess in broad terms of technology, cost and time the feasibility of meeting a Staff
Target.
To identify alternative solutions, their relative advantages and disadvantages, and key
problem areas for further study.
To provide detailed costed proposals for project definition studies and information in the
detail necessary to draft a Staff Requirement.
To check:
If the system contributes to organisational objectives
If the system can be engineered using current technology and within budget
If the system can be integrated with other systems that are used

Feasibility Study Report

The study addresses issues including the project's benefits, costs, effectiveness,
alternatives considered, analysis of alternative selection, environmental effects, public
opinions, and other factors.
A written report includes the study findings, recommendations, and (when the goal is
feasible) a campaign plan, timetable, and budget.

Feasibility Study Implementation

Feasibility Study is carried out through information assessment (i.e. what is required),
information collection and report writing. Certain areas may be targeted by asking the following
questions:

What if the system wasnt implemented?


What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?

Case Studies of Feasibility Studies

Consider the following Real-world case studies of Feasibility Studies carried out by various
organizations:

Case 1: BankSoft Feasibility Study - World Bank ATM Pilot Project

This document outlines a feasibility study done by BankSoft for World Bank. World Bank has
proposed a pilot project where they would like to implement several ATM machines to measure
the popularity of such machines. In the future, they would use the data that they collect on these
machines to implement more machines worldwide.

2
Software Engineering Lab Session 01
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

World Bank is renowned for its attention to security. Herein, three alternatives have been
suggested for designing these test machines. Each alternative is quite secure, but has its own
advantages and disadvantages over the other. The alternatives are as follows:
An embedded system. This would require a lot of time and custom hardware, but would
be extremely fast and BankSoft would provide an excellent warranty for the software.
Custom software on Microsoft Windows. This system would require minimal time and
cost, but would not require any special hardware. Interoperability with the bank's central
computer would be maximized, and warranty coverage would also be at peak.
Custom software on a free Unix OS. This system would also not require special
hardware, but making the software interoperable with the bank's central computer would
take additional time and effort. Such a system would be extremely stable and
inexpensive.

The recommendation has been made that the second alternative be designed, with custom
software designed on top of the Microsoft Windows platform. It is strongly believed that its
advantages outweigh its disadvantages more than any other alternative.

Case 2: The Mentoring Database System Feasibility Study


In this document, an overview of the Otonabee College Mentoring Program has been given and
then a description of the requirements for a software system to support the various administrative
tasks associated with that program. Then an analysis of the system currently in use is given to
emphasize the need for a redesign and the development of a new software system, the Mentoring
Database System (MDBS). Finally, a description of the proposed solution, an analysis of the
projects feasibility, and a conclusion is presented.

EXERCISES

1. Mention the sequence of issues that are to be addressed in a Feasibility Study Report.

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

3
Software Engineering Lab Session 01
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

2. Mention the various Feasibility Areas discussed in the MDBS Feasibility Study.

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

3. Consider any Real-world Feasibility Study Report. Comment on the quality of the report
by highlighting its strengths and weaknesses.

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________
4
Software Engineering Lab Session 01
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

5
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 02
OBJECT
Understanding the concepts of Software Documentation.

THEORY

All large software development projects, irrespective of application, generate a large amount of
associated documentation. For moderately sized systems, the documentation will probably fill
several filing cabinets; for large systems, it may fill several rooms. A high proportion of software
process costs is incurred in producing this documentation. Furthermore, documentation errors
and omissions can lead to errors by end-users and consequent system failures with their
associated costs and disruption. Therefore, managers and software engineers should pay as much
attention to documentation and its associated costs as to the development of the software itself.

The documents associated with a software project and the system being developed, have a
number of associated requirements:

1. They should act as a communication medium between members of the development team.
2. They should be a system information repository to be used by maintenance engineers.
3. They should provide information for management to help them plan, budget and schedule
the software development process.
4. Some of the documents should tell users how to use and administer the system.

Satisfying these requirements requires different types of document from informal working
documents through to professionally produced user manuals. Software engineers are usually
responsible for producing most of this documentation although professional technical writers
may assist with the final polishing of externally released information.

Process and Product Documentation

Generally, the documentation produced falls into two classes:

1. Process documentation: These documents record the process of development and


maintenance. Plans, schedules, process quality documents and organizational and project
standards are process documentation. The major characteristic of process documentation is
that most of it becomes outdated. Plans may be drawn up on a weekly, fortnightly or monthly
basis. Progress will normally be reported weekly. Memos record thoughts, ideas and
intentions, which change. Although of interest to software historians, much of this process
information is of little real use after it has gone out of date and there is not normally a need to
preserve it after the system has been delivered. However, there are some process documents
that can be useful as the software evolves in response to new requirements. For example, test
schedules are of value during software evolution as they act as a basis for re-planning the
validation of system changes. Working papers which explain the reasons behind design

6
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

decisions (design rationale) are also potentially valuable as they discuss design options and
choices made.

2. Product documentation This documentation describes the product that is being developed.
System documentation describes the product from the point of view of the engineers
developing and maintaining the system; user documentation provides a product description
that is oriented towards system users. Unlike most process documentation, it has a relatively
long life. It must evolve in step with the product, which it describes. Product documentation
includes user documentation, which tells users how to use the software product and system
documentation, which is principally intended for maintenance engineers. See Figure 2.1 for
different types of User Documents.

Figure 2.1: Different Types of User Documents

In short, Process documentation is produced so that the development of the system can be
managed. Product documentation is used after the system is operational but is also essential for
management of the system development. The creation of a document, such as a system
specification, may represent an important milestone in the software development process.

Document Quality

Document quality is as important as program quality. Without information on how to use a


system or how to understand it, the utility of that system is degraded. Achieving document
quality requires management commitment to document design, standards, and quality assurance
processes. Producing good documents is neither easy nor cheap and many software engineers
find it more difficult that producing good quality programs.

Document structure

The document structure is the way in which the material in the document is organized into
chapters and, within these chapters, into sections and subsections. Document structure has a
major impact on readability and usability and it is important to design this carefully when
creating documentation. As with software systems, you should design document structures so

7
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

that the different parts are as independent as possible. This allows each part to be read as a single
item and reduces problems of cross-referencing when changes have to be made.

The IEEE standard for user documentation proposes that the structure of a document should
include the components shown in Figure 2.2.

Component Description
Identification data Data such as a title and identifier that uniquely
identifies the document.
Table of contents Chapter/section names and page numbers.
List of illustrations Figure numbers and titles
Introduction Defines the purpose of the document and a brief
summary of the contents
Information for use of the documentation Suggestions for different readers on how to use
the documentation effectively.
Concept of operations An explanation of the conceptual background to
the use of the software.
Procedures Directions on how to use the software to
complete the tasks that it is designed to support.
Information on software commands A description of each of the commands
supported by the software.
Error messages and problem resolution A description of the errors that can be reported
and how to recover from these errors.
Glossary Definitions of specialized terms used.
Related information sources References or links to other documents that
provide additional information
Navigational features Features that allow readers to find their current
location and move around the document.
Index A list of key terms and the pages where these
terms are referenced.
Search capability In electronic documentation, a way of finding
specific terms in the document.

Figure 2.2: Suggested components in a software user document

Documentation Standards

Documentation standards act as a basis for document quality assurance. Documents produced
according to appropriate standards have a consistent appearance, structure and quality. The
standards that may be used in the documentation process are:

1. Process standards These standards define the process, which should be followed for
high-quality document production.

2. Product standards These are standards, which govern the documents themselves.

8
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

3. Interchange standards It is increasingly important to exchange copies of documents via


electronic mail and to store documents in databases. Interchange standards ensure that all
electronic copies of documents are compatible.

Writing style

Writing documents well is neither easy nor is it a single stage process. Written work must be
written, read, criticized and then rewritten until a satisfactory document is produced. Technical
writing is a craft rather than a science but some broad guide-lines about how to write well are:
1. Use active rather than passive tenses
2. Use grammatically correct constructs and correct spelling
3. Do not use long sentences which present several different facts
4. Keep paragraphs short
5. Dont be verbose
6. Be precise and define the terms which you use
7. If a description is complex, repeat yourself
8. Make use of headings and sub-headings.
9. Itemize facts wherever possible
10. Do not refer to information by reference number alone

Documents should be inspected in the same way as programs. During a document inspection, the
text is criticized, omissions pointed out and suggestions made on how to improve the document.
As well as personal criticism, grammar checkers can also be used, which are incorporated in
word processors.

On-line documentation

It is now normal to provide some on-line documentation with delivered software systems. This
can range from simple read me files that provide very limited information about the software
through interactive hypertext-based help systems to a complete on-line suite of system
documentation. Most commonly, however, hypertext-based help systems are provided. These
may be based on a specialized hypertext system or may be HTML-based and rely on web
browsers for access. The main advantage with on-line documentation is its accessibility.

Document Preparation

Document preparation is the process of creating a document and formatting it for publication.
Figure 2.3 shows the document preparation process as being split into 3 stages namely document
creation, polishing and production. Modern word processing systems are now integrated
packages of software tools that support all parts of this process. However, it is still the case that
for the highest-quality documents, it is best to use separate tools for some preparation processes
rather than the built-in word processor functions. The three phases of preparation and associated
support facilities are:

1. Document creation The initial input of the information in the document. This is
supported by word processors and text formatters, table and equation processors, drawing
and art packages.
9
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

2. Document polishing This process involves improving the writing and presentation of the
document to make it more understandable and readable. This involves finding and
removing spelling, punctuation and grammatical errors, detecting clumsy phrases and
removing redundancy in the text. Tools such as on-line dictionaries, spelling checkers,
grammar and style checkers and style checkers may support the process.

3. Document production This is the process of preparing the document for professional
printing. It is supported by desktop-publishing packages, artwork packages and type
styling programs.

Figure 2.3: Stages of document preparation

EXERCISE

1. Write the Software Requirement Specifications (SRS) for the project assigned by the lab
teacher (Refer to the SRS template in the Appendix)

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

10
Software Engineering Lab Session 02
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________
11
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 03

OBJECT
Learning Project Management

THEORY

Project management is the process of planning, organizing, and managing tasks and
resources to accomplish a defined objective, usually within constraints on time,
resources, or cost. Sound planning is one key to project success, but sticking to the plan
and keeping the project on track is no less critical. Microsoft Project features can help in
monitoring progress and keep small slips from turning into landslides.

First let us understand some basic terms and definitions that will be used quite often:
Tasks: They are a division of all the work that needs to be completed in order to
accomplish the project goals.
Scope: of any project is a combination of all individual tasks and their goals.
Resources: can be people, equipment, materials or services that are needed to complete
various tasks. The amount of resources affects the scope and time of any project.

STARTING A NEW PROJECT


You can create a Project from a Template File by choosing File > New from the menu. In
the New File dialog box that opens, select the Project Templates tab and select the
template that suits your project best and click OK. (You may choose a Blank Project
Template and customize it)
Once a new Project page is opened, the Project Information dialog box opens.

Figure 3.1: Project Information dialog box

12
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Enter the start date or select an appropriate date by scrolling down the list. Click OK.
Project automatically enters a default start time and stores it as part of the dates entered
and the application window is displayed.

Figure 3.2: Main window

Views
Views allow you to examine your project from different angles based on what
information you want displayed at any given time. You can use a combination of views in
the same window at the same time.

Project Views are categorized into two types:


Task Views (5 types)
Resource Views (3 types)

The Project worksheet is located in the main part of the application window and displays
different information depending on the view you choose. The default view is the Gantt
Chart View.

Tasks
Goals of any project need to be defined in terms of tasks. There are four major types of
tasks:
1. Summary tasks - contain subtasks and their related properties

13
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

2. Subtasks - are smaller tasks that are a part of a summary task


3. Recurring tasks - are tasks that occur at regular intervals
4. Milestones - are tasks that are set to zero duration and are like interim goals in
the project

Entering Tasks and assigning task duration

Click in the first cell and type the task name. Press enter to move to the next row. By
default, estimated duration of each task is a day. But, there are very few tasks that can
be completed in a day's time. You can enter the task duration as and when you decide
upon a suitable estimate.

Double-clicking a task or clicking on the Task Information button on the standard


toolbar opens the Task Information box. You can fill in more detailed descriptions of
tasks and attach documents related to the task in the options available in this box.

To enter a milestone, enter the name and set its duration to zero. Project represents it
as a diamond shape instead of a bar in the Gantt chart.

To copy tasks and their contents, click on the task ID number at the left of the task
and copy and paste as usual.

You can enter Recurring tasks by clicking on Insert > Recurring task and filling in the
duration and recurrence pattern for the task.

Any action you perform on a summary task - deleting it, moving or copying it apply
to its subtasks too.

Outlining tasks
Once the summary tasks have been entered in a task table, you will need to insert
subtasks in the blank rows and indent them under the summary task. This is
accomplished with the help of the outlining tool.

Outlining is already active when you launch a project and its tools are found at the
left end of the Formatting bar. To enter a subtask, enter the task in a blank cell in the
Task Name column and click the Indent button on the Outlining tool bar. The Show
feature in this toolbar is drop down tool that gives you an option of different Outline
levels.

A summary task is outdented to the left cell border, is bold and has a Collapse (-)
(Hide subtasks) button in front of it and its respective subtasks are indented with
respect to it.

Advantages of Outlining:
It creates multiple levels of subtasks that roll up into a summary task
Collapse and expand summary tasks when necessary

14
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Apply a Work Breakdown structure


Move, copy or delete entire groups of tasks

LINKS
Tasks are usually scheduled to start as soon as possible i.e. the first working day after the
project start date.

Dependencies
Dependencies specify the manner in which two tasks are linked. Because
Microsoft Project must maintain the manner in which tasks are linked, dependencies can
affect the way a task is scheduled. In a scenario where there are two tasks, the following
dependencies exist:

Finish to Start Task 2 cannot start until task 1 finishes.


Start to Finish Task 2 cannot finish until task 1 starts.
Start to Start Task 2 cannot start until task 1 starts.
Finish to Finish Task 2 cannot finish until task 1 finishes.

Tasks can be linked by following these steps:


1. Double-click a task and open the Task Information dialog box.
2. Click the predecessor tab.
3. Select the required predecessor from the drop down menu.
4. Select the type of dependency from drop down menu in the Type column.
5. Click OK.

The Split task button splits tasks that may be completed in parts at different times with
breaks in their duration times.

CONSTRAINTS
Certain tasks need to be completed within a certain date. Intermediate deadlines may
need to be specified. By assigning constraints to a task you can account for scheduling
problems. There are about 8 types of constraints and they come under the flexible or
inflexible category. They are:
 As Late As Possible Sets the start date of your task as late in the Project as possible,
without pushing out the Project finish date.
 As Soon As Possible Sets the start date of your task as soon as possible without
preceding the project start date.
 Must Finish On Sets the finish date of your task to the specified date.
 Must Start On Sets the start date of your task to the specified date.
 Start No Earlier Than Sets the start date of your task to the specified date or later.
 Start No Later Than Sets the start date of your task to the specified date or earlier.
 Finish No Earlier Than Sets the finish date of your task to the specified date or
later.

15
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

 Finish No Later Than Sets the finish date of your task to the specified date or
earlier.

Flexible constraints (demarcated by a red dot in Microsoft Project 2000) restrict


scheduling to a great extent whereas flexible constraints (blue dot) allow Project to
calculate the schedule and make appropriate adjustments based on the constraint applied.

Inflexible constraints can cause conflicts between successive and preceding tasks at times
and you may need to remove such a constraint.

To apply a constraint:
1. Open the Task Information dialog box.
2. Click the Advanced tab and open the Constraint type list by clicking on the drop-
down arrow and select it.
3. Select a date for the Constraint and click OK.

UPDATE COMPLETED TASKS


If you have tasks in your project that have been completed as they were scheduled, you
can quickly update them to 100% complete all at once, up to a date you specify.

1. On the View menu, click Gantt Chart.


2. On the Tools menu, point to Tracking, and then click Update Project
3. Click Update work as complete through and then type or select the date through
which you want progress updated.
4. If you don't specify a date, Microsoft Project uses the current or status date.
5. Click Set 0% or 100% complete only.
6. Click Entire Project

RESOURCES

Once you determine that you need to include resources into your project you will need to
answer the following questions:
What kind of resources do you need?
How many of each resource do you need?
Where will you get these resources?
How do you determine what your project is going to cost?

Resources are of two types - work resources and material resources.

Work resources complete tasks by expending time on them. They are usually people and
equipment that have been assigned to work on the project.

Material resources are supplies and stocks that are needed to complete a project.
A new feature in Microsoft Project 2000 is that it allows you to track material resources
and assign them to tasks.

16
Software Engineering Lab Session 03
NED University of Engineering & Technology Department of Computer & Information Systems Engineering


Entering Resource Information in Project
The Assign Resources dialog box is used to create list of names in the resource pool.

To enter resource lists:


1. Click the Assign Resources button on the Standard Tool bar or Tools > Resources
> Assign resources.
2. Select a cell in the name column and type a response name. Press Enter
3. Repeat step 2 until you enter all the resource names.
4. Click OK.

Resource names cannot contain slash (/), brackets [ ] and commas (,). Another way of
defining your resource list is through the Resource Sheet View.
1. Display Resource Sheet View by choosing View > Resource Sheet or click the
Resource Sheet icon on the View bar.
2. Enter your information. (To enter material resource use the Material Label field)

To assign a resource to a task:


1. Open the Gantt Chart View and the Assign Resources Dialog box.
2. In the Entry Table select the tasks for which you want to assign resources.
3. In the Assign Resources Dialog box, select the resource (resources) you want to
assign.
4. Click the Assign button.

EXERCISE

1. Make a project plan for the project assigned by the lab teacher. Attach its printout

17
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 04

OBJECT
Getting familiarized with the Unified Modeling Language (UML) Environment.

THEORY
Once the Requirements have been gathered, it is necessary to convert them into an
appropriate design. In order to bridge the requirements gathering and design phases, we
use some modeling or specification tool, e.g. the Unified Modeling Language. A
commonly available CASE tool for design through UML is the Rational Rose. Given
below is an overview of the various Aspects in which development could be done using
Rational Rose.

The Browser

The Browser contains a list of all the modeling elements in the current model. The
Browser contains a tree view of all the elements in the current Rose model. Elements in
the tree structure are either compressed or expanded.

Figure 4.1: The Browser Window

18
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

The Documentation Window

The Documentation Window may be used to create, review, and modify for any selected
modeling element. If nothing is selected, the window displays the string No selection.
The contents of the Documentation Window will change as different modeling elements
are selected.

To create the documentation for a selected element, click to select the element and enter
its documentation in the Documentation Window.

The Documentation Window may be docked or floating just like the Browser. Visibility
of the window is controlled via the View:Documentation window command.

Figure 4.2: The Documentation Window

Diagram Windows

Diagram windows allow you to create and modify graphical views of the current model.
Each icon on a diagram represents a modeling element. Since diagrams are used to
illustrate multiple views of a model, each model element can appear in none, one, or
several of a model's diagrams.

19
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 4.3: The Diagram Windows

Views in Rational Rose

There are many views of a software project under development. Rational Rose is
organized around the views of a software project:

1. The Use Case View


2. The Logical View
3. The Component View
4. The Deployment View.

Each view presents a different aspect of the visual model. Each view contains a Main
diagram by default. Additional elements and diagrams are added to each view throughout
the analysis and design process.

1. The Use Case View

The use case view of the system addresses the understandability and usability of the
system. This view looks at actors and use cases along with their interactions. The
diagrams in this view are use case diagrams, sequence diagrams and collaboration
diagrams.

20
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 4.4: Use Case View  Use Case Diagram

Packages in the Use Case View

Packages in the use case view can contain actors, use cases, sequence diagrams, and/or
collaboration diagrams. To create a package:

1. Right-click on the parent modeling element (use case view or another package) to
make the shortcut menu visible.
2. Select the New:Package menu command. This will add a new package called
NewPackage to the browser.
3. While the new package is still selected, enter its name.

Once a package is created, modeling elements may be moved to the package. To move a
modeling element to a package:

1. Click to select the modeling element to be relocated.


2. Drag the modeling element to the package.

2. The Logical View

The logical view of the system addresses the functional requirements of the system. This
view looks at classes and their static relationships. It also addresses the dynamic nature of
the classes and their interactions. The diagrams in this view are class diagrams and state
transition diagrams.

21
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

2.1 Class Diagram

The browser provides a textual view of the classes in a system. Class diagrams are
created to graphically view the classes and packages in the system. Rose automatically
creates a class diagram called Main in the Logical View. This diagram may be opened
by double-clicking on it in the browser. The Main class diagram typically contains
packages thus, by the end of development it is a graphical view of the major architectural
elements of the system. A package may be added to a class diagram by selecting it in the
browser and dragging it onto the class diagram.

Figure 4.5: Logical View  Class Diagram

2.2 State Transition Diagram


State transition diagrams show the life history of a given class, the events that cause a
transition from a state and the actions that result from a state change. They are created
for classes whose objects exhibit significant dynamic behavior.

22
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 4.6: Logical View  State Transition Diagram

3. The Component View

The component view of the system addresses the software organization of the system.
This view contains information about the software, executable and library components
for the system. This view contains component diagram.

Component Diagram
A component diagram shows the organizations and dependencies among components.
Most models contain many component diagrams. A component is represented as a
rectangle with one small ellipse and two small rectangles protruding from its side.

Figure 4.7: Component View

23
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Rose automatically creates one component diagram called Main. To create an additional
component diagram:
1. Right-click on the owning package (either the component view itself or a user
created package) to make the shortcut menu visible.
2. Select the New:Component Diagram menu command. This will place a new
component diagram called NewDiagram in the browser.
3. While the new diagram is still selected, enter its name.
Rose will automatically add the new diagram to the browser.

To open a component diagram:


1. Double-click on the diagram in the browser.

To create a component:
1. Click to select the package specification icon from the toolbar.
2. Click on the component diagram to place the component.
3. While the component is still selected, enter its name.
Rose will automatically add the new component to the browser.

To create a dependency relationship:


1. Click to select the dependency icon from the toolbar.
2. Click on the package or component representing the client.
3. Drag the dependency arrow to the package or component representing the
supplier.

4. The Deployment View


The deployment view addresses the configuration of run-time processing nodes and the
components, processes, and objects that live on them. This view contains only one
diagram the deployment diagram.

Deployment Diagram
The deployment diagram contains nodes and connections. Rose provides two icons that
can be used to draw a node the processor and the device. A processor is a node that has
processing capacity.

Figure 4.8: Deployment View

24
Software Engineering Lab Session 04
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

To open the deployment diagram:


1. Double-click on the Deployment View in the browser.

To create a node:
1. Click to select the processor icon from the toolbar.
2. Click on the deployment diagram to place the node.
3. While the node is still selected, enter its name.

To create a connection:
1. Click to select the connection icon from the toolbar.
2. Click on the node representing the client.
3. Drag the connection line to the node representing the supplier.

EXERCISES

1. Develop the Component Diagram following the specifications given below:


Create a package called Registration
Create the main component diagram for the Registration package
Create three components on the Main component diagram for the
Registration package Registrar.exe, Courses.dll and People.dll //Create
dummy files for this purpose
Create a dependency relationship between
o Registrar.exe and Courses.dll
o Registrar.exe and People.dll

Attach printout of the model.


2. Develop the Deployment Diagram following the specifications given below:
Open the deployment diagram.
Add the following nodes (processors): Registration, Database, Main
Building, Dorm, Library
Add the connections as shown in the table below

Node Connected to Node


Registration Database
Registration Main Building
Registration Dorm
Registration Library

Attach printout of the model here.

25
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 05
OBJECT
Working with the Use-case View of UML.

THEORY

The use case view of the system addresses the understandability and usability of the system.
This view looks at actors and use cases along with their interactions. The diagrams in this view
are use case diagrams, sequence diagrams and collaboration diagrams.

Actor
An actor is represented by a stickman. To create an actor:

1. Right-click to select the Use Case View in the browser and make the shortcut menu
visible.
2. Select the New:Actor menu command. This will add an actor called NewClass to the
browser.
3. While the new class is still selected, enter the name of the actor.

As actors are created, their documentation is added to the model. To add the documentation for
an actor:

1. Click to select the actor in the browser.


2. Position the cursor in the Documentation Window.
3. Enter the documentation for the actor.

Actors

Documentation
for Actor

Figure 5.1: Use Case View

26
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Each modeling element is associated with a Specification window. The Specification contains
additional information about the element. To view the Specification for an actor:
1. Right-click to select the actor in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
When you view the Specification for an actor, you will notice that the title is Class
Specification for <actor>. This is due to the fact that an actor is a class in Rose with a
stereotype /*Extension of Metaclass*/ of Actor.

Use Case
A use case is represented by an oval. To create a use case:
1. Right-click to select the Use Case View in the browser and make the shortcut menu
visible.
2. Select the New:Use Case menu command. This will add an unnamed use case to the
browser.
3. While the new use case is still selected, enter the name of the use case.
Use cases are documented in two ways they have a brief description and a flow of events. To
add the brief description for a use case:
1. Click to select the use case in the browser.
2. Position the cursor in the Documentation Window.
3. Enter the brief description for the use case.
The flow of events is captured in documents and/or web pages external to Rose. The documents
and web pointers are linked to the use case. To link an external document or web pointer to the
use case:
1. Right-click to select the use case in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Files tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert File menu command and enter the name of the document to be linked to
the use case.
6. Or, select the Insert URL menu command and enter the www pointer to be linked to the
use case.
7. Click the Open button.

Use Cases

Documentation
for Use Case

Figure 5.2: Use Cases

27
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Use Case Diagrams


A use case diagram shows the relationships among actors and use cases within the system. The
use case view is automatically created with one use case diagram called Main. A system may
have other use case diagrams (e.g. a diagram to show all the use cases for one actor).

Figure 5.3: Use Case Diagram


To open a use case diagram:

1. Click the + next to the Use Case View in the browser to expand the view.
2. Double-click on the diagram you wish to open.
3. Re-size the diagram as needed.

To add an actor or use case to the diagram:

1. Click to select the actor or use case in the browser.


2. Drag the actor or use case to the diagram.

The main type of relationship is a communication relationship. This relationship is shown as a


uni-directional association. To add communication relationships to the diagram:

1. Click to select the uni-directional icon from the toolbar.


2. Click on the actor or use case initiating the communication.
3. Drag the relationship line to the participating use case or actor.

A use case diagram may have two other types of relationships extends and uses relationships.
Extends and uses relationships are shown as generalization relationships with stereotypes. To
create an extends or uses relationship:

1. Click to select the generalization icon from the toolbar.


2. Click on the using or extension use case.
3. Drag the relationship line to the used or extended use case.

28
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

4. Double-click on the relationship line to make the Specification visible.


5. Enter uses or extends in the Stereotype field.
6. Click the OK button to close the Specification.
7. Right-click on the generalization line to make the shortcut menu visible.
8. Select the Show Stereotype menu command.

Actors and use cases may also be created on a use case diagram. To create an actor or use case
on the diagram:

1. Click to select the actor icon or the use case icon from the toolbar.
2. Click on the diagram to place the actor or use case.
3. While the actor or use case is still selected, enter its name.

The actor or use case is automatically added to the browser.

Sequence Diagrams
Use case diagrams present an outside view of the system. The functionality of a use case is
captured in its flow of events. Scenarios are used to describe how use cases are realized as
interactions among societies of objects. Scenarios are captured in sequence diagrams. Sequence
diagrams are associated with use cases.

Figure 5.4: Sequence Diagram

29
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

To create a new sequence diagram:

1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the New:Sequence Diagram menu command. This will add a new sequence
diagram called NewDiagram to the browser.
3. While the new diagram is still selected, enter the name of the diagram.
4. Double-click on the diagram in the browser to open it.
5. Re-size the sequence diagram as needed.

Sequence diagrams contain actors, objects and messages.

To add an actor to a sequence diagram:

1. Click to select the actor in the browser.


2. Drag the actor onto the diagram.

To add an object to the sequence diagram:

1. Click to select the object icon from the toolbar.


2. Click on the diagram to place the object.
3. While the object is still selected, enter its name.

To create a message:

1. Click to select the message icon from the toolbar.


2. Click on the object representing the client (sender of the message).
3. Drag the message to the object representing the supplier (receiver of the message).
4. While the message line is still selected, enter the name of the message.

To create a reflexive message:

An object may send a message to itself. This is called a reflexive message.

1. Click to select the message to self icon from the toolbar.


2. Click on the object that needs a reflexive message.
3. While the message line is still selected, enter the name of the message.

Collaboration Diagrams

A scenario may also be represented in a collaboration diagram. Like sequence diagrams,


collaboration diagrams are associated with use cases.
To create a collaboration diagram directly from a sequence diagram:
1. Select the Browse:Create Collaboration Diagram menu command or use the F5
accelerator.
2. Re-size the diagram as needed.
3. Re-arrange the objects as needed.

30
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 5.5: Collaboration Diagram

Collaboration diagrams may also be created from scratch.

To create a new collaboration diagram:

1. Right-click on the use case in the browser to make the shortcut menu visible.
2. Select the New:Collaboration Diagram menu command. This will add a new
collaboration diagram called NewDiagram to the browser.
3. While the new diagram is still selected, enter the name of the diagram.
4. Double-click on the diagram in the browser to open it.
5. Re-size the collaboration diagram as needed.

Collaboration diagrams contain actors, objects, links, messages, and optional data flows.

To add an actor to a collaboration diagram:

1. Click to select the actor in the browser.


2. Drag the actor onto the diagram.

To add an object to the Collaboration diagram:

1. Click to select the object icon from the toolbar.


2. Click on the diagram to place the object.
3. While the object is still selected, enter its name.

31
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

To add a link:

1. Click to select the link icon from the toolbar.


2. In the collaboration diagram, click on one actor or object that participates in the link.
3. Drag the link to the other participating actor or object.

An object may be linked to itself. This is called a reflexive link.

To create a link message:

1. Click to select the message to self icon from the toolbar.


2. Click on the object in the collaboration diagram.

To create a message:

1. Click to select the message icon from the toolbar.


2. Click on the link between the communicating objects
3. While the message line is still selected, enter the name of the message.

To create a data flow:

1. Click to select the data flow icon from the toolbar.


2. Click to select the message it modifies.
3. While the data flow is still selected, enter the data flow information.

EXERCISES
1. Open a new model. Add the following Actors and their description:

Actor Documentation
Student A person who is registered to take classes at the University.
Professor A person who is certified to teach courses at the University.
Registrar The person who is responsible for the maintenance of the
Registration System.
Billing System External system responsible for student billing.

2. Create and enter the brief description for the use cases shown in the table below. Save the
model.

Use Case Brief Description


Register for Courses This use case provides the capability for a student to
select courses for a specified semester.

32
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Use Case Brief Description


Select Courses to Teach This use case provides the capability for a professor to
select courses to teach for a specified semester.
Maintain Curriculum This use case provides the capability for the Registrar to
maintain the curriculum for a specified semester.
Maintain Student Info This use case provides the capability for the Registrar to
maintain student information needed by the Registration
System.
Maintain Prof Info This use case provides the capability for the Registrar to
maintain professor information needed by the Registration
System.

3. Open the Main use case diagram.

Add the Student, Professor, Registrar and Billing System actors to the diagram.
Add the Register for Courses, Select Courses to Teach, Maintain Curriculum, Maintain
Student Info and Maintain Prof Info use cases to the diagram.
Create a communication relationship (uni-directional association) between:
o The Student actor and the Register for Courses use case.
o The Register for Courses use case and the Billing System actor.
o The Professor and the Select Courses to Teach use case.
o The Registrar and the Maintain Curriculum, Maintain Student Info, Maintain Prof
Info use cases.

Create a new use case called Registrar Validation.


Add the brief description of the use case. This use case verifies that the user may access
the Registration system playing the role of the Registrar.
Create a uses relationship between
o The Maintain Curriculum use case and the Registrar Validation use case.
o The Maintain Student Info use case and the Registrar Validation use case.
o The Maintain Prof Info use case and the Registrar Validation use case.
Save the model.

4. Create a new sequence diagram called Add a Course Offering for the Select Courses to Teach
use case.

Add the Professor actor to the diagram.


Create the following objects: course options form, add course form, course, course
offering
Create the messages as shown in the table below.

From To Message
Professor course options form add a course
course options form add course form display
Professor add course form select course offering

33
Software Engineering Lab Session 05
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

add course form course add professor (prof id)


course course get professor (prof id)
course course offering add professor (professor)

Save the model.

5. Create a collaboration diagram from the Add a Course Offering sequence diagram.

6. Create a new collaboration diagram called Add a Student for the Maintain Student Information
use case.
Add the Registrar actor to the diagram.
Create the following objects: student options form, student form, student
Create a link from:
o The Registrar actor to the student options form.
o The student options form to the student form.
o The Registrar actor to the student form.
o The student form to the student.
o The student to the student (link to self).
Create the messages and data flows as shown in the table below.

From To Message Data Token


Registrar student options form new student none
student options form student form display none
Registrar student form enter student info none
student form student new student Success flag
student student save none

Save the model.

7. Generate the Sequence Diagram for the Add a Student Collaboration Diagram.

For all the Exercises given above attach printouts of the Diagrams.

34
Software Engineering Lab Session 06
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 06
OBJECT
Working with the Class Diagrams of UML.

THEORY
Class Diagrams
The browser provides a textual view of the classes in a system. Class diagrams are
created to graphically view the classes and packages in the system. Rose automatically
creates a class diagram called Main in the Logical View. This diagram may be opened
by double-clicking on it in the browser. The Main class diagram typically contains
packages thus, by the end of development it is a graphical view of the major architectural
elements of the system. A package may be added to a class diagram by selecting it in the
browser and dragging it onto the class diagram.

Figure 6.1: The Class Diagram

Each package typically has its own main diagram which is a picture of its key packages
and classes. To create the Main class diagram for a package, double-click on the package
on a class diagram. Once the Main diagram is created for a package, you can add

35
Software Engineering Lab Session 06
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

packages and classes to the diagram by selecting them in the browser and dragging them
onto the diagram.

Classes from any package may be added to a class diagram by selecting the class on the
browser and dragging it onto the open class diagram. If the Show Visibility option is set
to true either as a default using the Tool:Options menu or individually by using the
shortcut menu for the class, the name of the owning package is displayed. The package
name will be visible for all classes that do not belong to the package owning the class
diagram.

Packages and classes may also be created using the class diagram toolbar. To create a
package or class using the toolbar:

1. Click to select the icon (package or class) on the class diagram toolbar.
2. Click on the class diagram to place the package or class.
3. While the new package or class is still selected, enter its name.
4. Multiple packages or classes may be created by depressing and holding the Shift
key.

Packages and classes created on class diagrams are automatically added to the browser.

To create a class diagram:


1. Right-click to select the owning package and make the shortcut menu visible.
2. Select the New:Class Diagram menu command. This will add a class diagram
called NewDiagram to the browser.
3. While the new class diagram is still selected, enter its name.
4. To open the class diagram, double-click on it in the browser.

Class Structure

The structure of a class is represented by its set of attributes. Attributes may be created in
the browser, via the Class Specification or on a class diagram.

To create an attribute in the browser:


1. Right-click to select the class in the browser and make the shortcut menu visible.
2. To create an attribute, select the New:Attribute menu command. This will add an
attribute called name to the browser.
3. While the new attribute is still selected, enter its name.
4. Attribute data types and default values may not be entered via the browser

To create an attribute using the Class Specification:


1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Attributes tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an attribute called name.

36
Software Engineering Lab Session 06
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

6. While the new attribute is still selected, enter its name. Type and initial value
may be filled in at this time or you may choose to fill in this information later in
the development cycle.

To create an attribute on a class diagram:


1. Right-click to select the class on the class diagram and make the shortcut menu
visible.
2. Select the Insert New Attribute menu command. This will insert an attribute in
the form
name : type = initval
3. While the attribute is still selected, fill in its name. Type and initial value may be
filled in at this time or you may choose to fill in this information later in the
development cycle.

Attributes of a class may be viewed in the browser. The class will be initially collapsed.
To expand the class to view its attributes, click the + next to the class.

Attributes should be documented. To add the documentation for an attribute:


1. Click to select the attribute in the browser.
2. Position the cursor in the Documentation Window. If the Documentation
Window is not visible, select the View:Documentation menu command.
3. Enter the documentation for the attribute.

To delete an attribute:
1. Right-click to select the attribute in the browser or on the Attributes tab of the
Class Specification and make the shortcut menu visible.
2. Select the Delete menu command.

Class Behavior
The behavior of a class is represented by its set of operations. Operations may be created
in the browser, via the Class Specification or on a class diagram. To create an operation
in the browser:

1. Right-click to select the class in the browser and make the shortcut menu visible.
2. To create an operation, select the New:Operation menu command. This will add
an operation called opname to the browser.
3. While the new operation is still selected, enter its name.
4. The operation signature may not be entered via the browser

To create an operation using the Class Specification:


1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the Specification menu command.
3. Select the Operations tab.
4. Right-click to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an attribute called opname.

37
Software Engineering Lab Session 06
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

6. While the new operation is still selected, enter its name. The signature and return
value may be filled in at this time or you may choose to fill in this information
later in the development cycle.

To create an operation on a class diagram:


1. Right-click to select the class on the class diagram and make the shortcut menu
visible.
2. Select the Insert New Operation menu command. This will insert an attribute in
the form
opname ( argname : argtype = default) : return
3. While the operation is still selected, fill in its name. The signature and return
value may be filled in at this time or you may choose to fill in this information
later in the development cycle.

Operations of a class may be viewed in the browser. The class will be initially collapsed.
To expand the class to view its operations, click the + next to the class.

To enter the signature of an operation:


1. Right-click to select the operation in the browser and make the shortcut menu
visible.
2. Select the Specification menu command.
3. Select the Detail tab.
4. Right-click in the Arguments field to make the shortcut menu visible.
5. Select the Insert menu command. This will insert an argument called argname of
type argtype with a default value of default.
6. Click to select the name, type, or default and enter the desired information.
7. Click the OK button to close the Specification.

To delete an operation:
1. Right-click to select the operation in the browser or on the Operations tab of the
Class Specification and make the shortcut menu visible.
2. Select the Delete menu command.

Operations should be documented.

To add the documentation for an operation:


1. Click to select the operation in the browser.
2. Position the cursor in the Documentation Window. If the Documentation
Window is not visible, select the View:Documentation menu command.
3. Enter the documentation for the operation.

Relationships
Relationships provide a conduit for communication. There are four different types of
relationships : association, aggregation, dependency, and inheritance. Relationships may
only be created on a class diagram using the toolbar.

38
Software Engineering Lab Session 06
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

EXERCISES
1. Develop a Class Diagram using the specifications given below:
Add the PeopleInformation, UniversityArtifacts, and Interfaces packages to
the Main class diagram.
Create the Main class diagram for each package.
Add the StudentInformation and ProfessorInformation classes to the
PeopleInformation package Main class diagram.
Add the Course and CourseOffering classes to the UniversityArtifacts
package Main class diagram.
Add the CourseOptionsForm and CourseForm classes to the Interfaces
package Main class diagram.
Create a new class called Catalog using the toolbar and place it on the
UniversityArtifacts package Main class diagram. Dont forget to document
the new class.
Create a new class diagram called Course Information for the
UniversityArtifacts package.
Add the Course class to the Course Information class diagram.

Save the model and Attach Print here.

39
Software Engineering Lab Session 07
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 07
OBJECT

Working with the State Transition Diagrams of UML.

THEORY
State Transition Diagrams

State transition diagrams show the life history of a given class, the events that cause a
transition from a state, and the actions that result from a state change. They are created
for classes whose objects exhibit significant dynamic behavior.

Figure 7.1: State Transition Diagram

To create a state transition diagram:


1. Right-click to select the class in the browser and make the shortcut menu visible.
2. Select the State Diagram menu command.

40
Software Engineering Lab Session 07
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

To open a state transition diagram


1. Click the + next to the class to expand the tree
2. Double-click on the State Diagram for the class

States
A state is represented by an oval.

To create a state
1. Click to select the State icon from the toolbar.
2. Click on the state transition diagram to place the state.
3. While the state is still selected, enter its name.

State Transitions
A state transition is represented as an arrow which points from the originating state to the
successor state.

To create a state transition


1. Click to select the state transition arrow from the toolbar.
2. Click on the originating state and drag the arrow to the successor state.

State Actions
Behavior that occurs while an object is in a state can be expressed in three ways: entry
actions , activities , and exit actions . The behavior may be a simple event or it may be an
event sent to another object.

To create an entry action, exit action or activity


1. Point to the state and double click to make the State Specification dialog box
visible.
2. Select the Detail tab.
3. Click-right in the Actions field to make the pop-up menu visible.
4. Select the Insert menu choice to insert a new action called entry.
5. Double-click on the action to make the State Action Specification visible.
6. If the action is a simple action, enter the name of the action in the Action field.
7. If the action is a send event action, enter the name of the event to be sent in the
Send Event field. If the event has arguments, enter the arguments in the Send
Arguments field. Enter the name of the target object (object receiving the event)
in the Send Target field.
8. Select the appropriate radio button in the When field (On Enty to create an entry
action, On Exit to create an exit action, or Entry Until Exit to create an activity.
9. Click the OK button to close the Action Specification.
10. Click the OK button to close the State Specification.

Start and Stop States


There are two special states associated with state transition diagrams the start state and
the stop state. The start state is represented by a filled in circle and the stop state is
represented by a bulls eye.

41
Software Engineering Lab Session 07
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

To create a start state


1. Click to select the start state icon from the toolbar.
2. Click on the diagram to place the start state on the diagram.
3. Click to select the state transition icon from the toolbar.
4. Click on the start state and drag the state transition arrow to the successor state.

To create a stop state


1. Click to select the stop state icon from the toolbar.
2. Click on the diagram to place the stop state on the diagram.
3. Click to select the state transition icon from the toolbar.
4. Click on the originating state and drag the state transition arrow to the stop state.

EXERCISES

1. Create a state transition diagram for the CourseOffering class (developed in


previous laboratory session). Create the following states: Initialization, Open,
Closed, Canceled
Save the model.

2. Open the state transition diagram for the CourseOffering class. Create the state
transitions as shown in the tables below.

From State To State Event Name


Initialized Open Add student
Open Open Add student
Open Closed None
Open Canceled Cancel course
Closed Canceled Cancel course

From State To State Action


Initialized Open set count = 0
Open Open None
Open Closed None
Open Canceled None
Closed Canceled None

From State To State Guard


Initialized Open None
Open Open count < 10
Open Closed count = 10
Open Canceled None
Closed Canceled None

42
Software Engineering Lab Session 07
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

From State To State Send Event Send Target


Initialized Open None None
Open Open None None
Open Closed Create report CourseReport
Open Canceled None None
Closed Canceled None None

Save the model.

3. Open the state transition diagram for the CourseOffering class

Add a start state with a transition to the Initialization state to the diagram.
Add a transition from the Canceled state to a stop state to the diagram.
Add a transition from the Closed state to a stop state to the diagram.

Save the model and Attach printout for the Final State transition Diagram.

43
Software Engineering Lab Session 08
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 08
OBJECT
Learning the basics of ASP.Net

THEORY

Active Server Pages is a programming environment that provides the ability to combine
HTML, scripting, and components to create powerful internet applications that run on the
server. It allows developers to create dynamic web pages. Dynamic web pages are pages
whose content is dynamically regenerated each time the web page is requested.

ASP.NET

ASP.NET is a server side scripting technology that enables scripts (embedded in web
pages) to be executed by an Internet server. It is a program that runs inside the windows
server component IIS (Internet Information Services). An ASP.NET file can contain
HTML, XML, and scripts. Scripts in an ASP.NET file are executed on the server. An
ASP.NET file has the file extension ".aspx".

When an ASP is incorporated into Web site, the following step happens:
The user brings up a Web site where the default page has the extension .aspx.
The browser requests the ASP file from the Web server, instead of processing itself
like in .html extension.
The server-side script begins to run with ASP.
ASP processes the requested file sequentially (top-down), executes any script
commands contained in the file, and produces an HTML Web page.
The result, which is 100% pure HTML code, is sent back to the browser. Because the
script runs on the server, the Web server does all of the processing and standard
HTML pages can be generated and sent to the browser. This means that the Web
pages are limited only by what your Web server supports. Another benefit of having
your script resides on the server is that the user cannot view source on the original
script and code. Instead, the user sees only the generated HTML as well as non-
HTML content, such as XML, on the pages that are being viewed.
The ASP .Net code can either be written inside the ASPX page or it can be included as a
.cs or vb .net file. When the ASPX page is embedded with the code of either C# or VB
.Net, the ASP .Net run time automatically compiles the code into an assembly and loads
it. If the code is kept in a separate source file either as a VB or C# file, it has to be
compiled by the programmer, which will be used by the run time for further execution.

Creating A New Website

Open the Microsoft Visual Studio 2008. Go to File  New Website the following dialog
box appears

44
Software Engineering Lab Session 08
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 8.1: Creating a New Website

The website can be built either using Visual C#, Visual Basic. Select the default ASP.Net
Website from the template and type in the name for the project after selecting the
language (here we select Visual C#). Now a new blank website is created.

45
Software Engineering Lab Session 08
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 8.2 : Design View of a Project


The default.aspx is included in the project. To rename it, right click on the Default.aspx
select Rename from the popup menu and then name it to First.aspx.

Source View

Source view displays the HTML markup for the Web page, which you can edit. By
default, all HTML elements and scripts are displayed when the Source View is initially
selected. Elements can be dragged from the Toolbox, just as they are dragged when
editing a Web page in Design view, and then see their markup inserted into the
document.

To select Source view, click the Source tab at the bottom of the HTML Designer
window.

Design View

Design view displays ASP.NET Web pages, master pages, content pages, HTML pages,
and user controls. It allows you to add text and elements and then position and size them
and set their properties using special menus or the Properties window.

To select Design view, click the Design tab at the bottom of the HTML Designer
window.

Properties Window

It's a window where you can edit properties or events for the controls. To access
Properties Window, Select Properties Window on the View menu.

Solution Explorer

Solution Explorer provides you with an organized view of your projects and their files as
well as ready access to the commands that pertain to them. A toolbar associated with this
window offers commonly used commands for the item you highlight in the list. To access
Solution Explorer, select Solution Explorer on the View menu

Toolboxs Auto Hide Option

The toolbox navigator is present on the left end of the screen. If the mouse is scrolled
over it, the toolbox appears presenting many control options that can be added to a
website. The auto hide option presented by icon can be clicked to make the toolbox
locked on the left side of the screen turning the icon to icon.

46
Software Engineering Lab Session 08
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Move the control on the screen

To drag it to the desired position on the page, go to Format Set PositionAbsolute.


This option can also be applied to the controls using Cascading Style Sheets. The
Cascading Style Sheets or CSS allow you to control the layout and look of your page
easily.// CSS tags or properties are easy to use and affect the look and feel or style of
your pages by setting its Property: CSS Class to the already defined Style Sheet.

Adding some controls on the website

Double click on the Button icon present in the Standard toolbox to add it to the website.
Drag to the desired location. The default ID for this Button is Button1. To change this ID
go to properties window, type the ID as OKButton. Also change the Text property of
this control to OK. Drag a label on the website and remove the text label from its
properties. Double click the OKButton to open its code and add the following code:

protected void OKBotton_Click(object sender, EventArgs e)


{
Label1.Text = "Hello User" ;
}

Use Ctrl+Shift+S to save the project.

Debugging the Website

Press F5 or the play button in the standard toolbar to start debugging. A window displays
a message that Debugging Not Enabled. Select the option Add web.config file with
debugging enabled and click OK. The Visual Studio Web Developer 2008 launches a
mini testing web server that will work for the purpose of testing the website just created
locally. A popup on the taskbar shows ASP.Net Development Server
http://localhost:50701/First/. The website is now open on the website explorer. When the
OK button is clicked, a welcome message, Hello User is displayed on the website.

Figure 8.3 : How To Start Debugging

To make it more user friendly, add a textbox and change its ID to NameTextBox. Add a
Label on its left side and change its text to Enter Your Name:. Add the following
code to OKButton:

47
Software Engineering Lab Session 08
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

protected void OKBotton_Click(object sender, EventArgs e)


{
Label1.Text = "Hello " + NameTextBox.Text ;
}

Where + is used for string concatenation.

Adding a Hyperlink

From the toolbox drag a Hyperlink control to the webpage. Change its Text property to
CIS Department and its NavigateUrl property to http://www.neduet.edu.pk/CISE. To
open this link in a new browser, change its Target property to _blank.

EXERCISE

1. Write down the advantages of server side scripting in ASP.Net.

48
Software Engineering Lab Session 09
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 09
OBJECT
Exploring some controls and the concept of field validation in ASP.Net

THEORY

Add a New Web Form to the Project

A new web form can be added to the project. To do so open Solution Explorer right click
on the root of the project and click on Add New item A number of different types of
templates are displayed for the selection of the developer. Select Web Form and give this
new item an appropriate name.

Two check boxes at the bottom of the page allow the separation of the code and the
selection of a master page. The restructured code-behind schema of Visual Studio 2008
supports separation of code but makes it optional. The language selected for the project is
displayed in the language box.

Once a new page is open, select Default.aspx  Set as Start page to enable the debugger
to run this page whenever the project is debugged.

Figure 9.1 : Setting Up As Start Page

49
Software Engineering Lab Session 09
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Adding a Table

To insert a table on a webpage, click Table  Insert Table. An Insert Table window pops
up enabling a user to select from the available templates or creating a customized table
with required number of cells and cell formatting.

Add a Dropdown List

Drag the Drop down list from the standard toolbox. Change its ID to DeptDropDown.
Click on the arrow on upper right hand corner of the control to see the various options
available. Select the Edit Items to add a number of options from which the user can
select. The ListItem Collection Editor opens in a pop up window. Click Add to add a new
entry in the drop down list and type in the name of the entry in the Text property. Click
Add to enter another option or OK to exit.

Adding Radio Buttons

To add radio buttons on a webpage, drag the number of radio buttons required (here
consider two radio buttons are being dragged) from the standard toolbox. Rename them
as studentRadioButton and facultyRadioButton. Also change their text property to
Student and faculty respectively. In the GroupName property, write User for both of the
radio buttons which makes them to belong to same group.

Field Validation

Validation controls are available in the toolbox. Some of these are discussed below:

Required Field Validator

Required field validator is used for required fields. Fields that cannot be left empty is
validated using the required field validator. A good example will be a TextBox which is
used for taking the username as the input. Since the user must enter the username in the
TextBox in order to access the website. The required field validator can be used with the
TextBox control to validate the input. If user does not enter any data in the TextBox than
an error message is displayed and further processing of the request will be stopped.

In order to set the required validator on the TextBox control just drag and drop the
validator on the webform and set its ControltoValidate property to the TextBox id that is
to be validated.

Regular Expression Validator

Regular Expression Validator is used to check the user input against some built in regular
expressions. The control provides the RegularExpression collection property that can be
used to select the desired Regular Expression. Some of the built in expressions are Email,
postal code, telephone number and many more. If the user input does not match the

50
Software Engineering Lab Session 09
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

regular expression expected an error will occur and the request for the resources will not
be authorized unless the user corrects the input data.

Range Validator

The Range Validator control is used to check whether the input control contains value in
the specified range. You can check the range of values against different data types such
as String, Date, Integer and so on.

The two most important properties of the range validator control is the Maximum value
and the minimum value. The range can be used to restrict the user data. Suppose if the
user is entering a roll number so the range can be set from 1 to 500.

Compare Validator

The compare validator control is used to compare the input server control's value. The
compare validator can be used to compare against a value or another control. If both the
ControlToCompare and ValueToCompare properties are set for a CompareValidator
control, the ControlToCompare property takes precedence.

It can be used to compare whether the user has selected a value from the dropdown list or
not. For this purpose, select the dropdown list from ControlToValidate property and in
ValueToCompare write down the string e.g. Select a Department (which must be the
first entity in the dropdown list) and set the Operator property to NotEqual.

Another good use of the compare validator is to check whether the passwords entered by
the user in the two TextBoxes while registering for a website are same or not. This
validator also performs validation on the client side as well as the server side. So, no
postback will be required when doing the comparison and hence resources will be saved
and performance will increase.

Figure 9.2 : Validation Controls

51
Software Engineering Lab Session 09
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

EXERCISE

1. Design a web page LOGIN.aspx and apply field validation on it.


(Hint:
1. Use Required Field Validator for all the fields.
2. Use Compare Validator for the Re-enter password.
) Attach printout.

2. Explain which of the validators are server side validators and which are client
side?

52
Software Engineering Lab Session 10
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 10
OBJECT
Exploring the working of Login controls and some basic Postback
controls in ASP.Net

THEORY

ASP.Net Website Administration Tool

In ASP.Net, a login page can be inserted very easily by a series of mouse clicks i.e. no
time is spent in writing extensive code for the authentication purposes. Open the ASP.Net
Configuration from the Website menu to view the website administration tools. This
option provides, amongst other facilities, the ability to update the security settings for a
website. The figure 1 shown below will appear when the security tab is selected.

Figure 10.1: Security settings update window

53
Software Engineering Lab Session 10
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Various options are available here, through which new user can be created or an existing
user can be edited. Roles of the users can be created and the access rules can also be
created or edited.

To create a new role, click on the Enable Roles option and then click on the Create or
manage roles link. Enter the name of the role (e.g. Administrator or Premium User) and
click OK. Now once a role is created, its users can be defined and the access rules for the
user of this role can be set. To add a new user, first set the authentication type to From
the Internet. Select the Create User link and fill up the form for a new user. Make sure to
enter a password with having minimum 7 characters including a non-alphanumeric
character. Close this explorer window and return to the Visual Studio environment.

Creating a login page

Add a Web form to the project and name it Login.aspx. In its design view, drag the Login
control from the Login Toolbox. From the Smart Tag, this control can be formatted or the
text boxes or the labels present in it can be edited too. In the DestinationPageUrl
property, write down the name of the webpage which the user can visit after logging in.
On the Home Page, a login hyperlink can be created which will link to this login page or
set the login page as the start page.

The User login name and status can also be displayed in the webpage. Drag the Login
Status and Login Name control on the webpage to do so. The Change Password control
can be used to change the existing users password. A new can sign up if the Create user
Wizard is added to the webpage.

What is PostBack?

A Postback is an action taken by an interactive webpage, when the entire page and its
contents are sent to the server for processing some information and then, the server post
the same page back to the browser. This is done to verify user names and passwords, for
example, when processing an on-line order form data, or other similar tasks that require
server interaction.

Each Asp.Net page, when loaded, goes through a regular creation and destruction cycle
like Initialization, Page load etc., in the beginning and unload while closing it. This
Postback is a read only property with each Asp.Net Page (System.Web.UI.Page) class.
This is false when the first time the page is loaded and is true when the page is submitted
and processed. This enables users to write the code depending on if the PostBack is true
or false (with the use of the function Page.IsPostBack).

Working on a PostBack event

For some WebPages it may be required to fill up the entities in a drop down list
depending upon selection made by user. For instance, the user is filling up a form that
asks for the country and city the user belongs. Instead of typing in the country, the user

54
Software Engineering Lab Session 10
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

can simple select from the drop down list. As soon as the country is selected, the drop
down list of the city becomes populated with the cities of that country. This action is
taken in response of the users action and is made possible by the PostBack event.

Add a textbox, a button and label to the webpage and write the following code:

protected void Page_Load(object sender, EventArgs e)


{
if (Page.IsPostBack == false)
{
TextBox1.Text = "";
}
}
protected void Button1_Click(object sender, EventArgs e)
{
Label1.Text = TextBox1.Text;
}

This code helps the user to enter some text in the textbox and when the button is clicked
it copies that text to the label. If you want to make sure that the textbox is empty at the
time the page is first time loaded then you write TextBox1.Text = "";. But this will
empty the textbox as well as the label whenever the button is clicked. To empty the
contents of the textbox for only the first time the condition if (Page.IsPostBack ==
false)is inserted. The IsPostBack is a property that is false only when the page is loaded
for the first time.

Adding a Calendar Control

Whenever it is required to take date as input from the user, a useful control called
Calendar can be added from the standard toolbox. To illustrate its working, add a textbox
and set its ReadOnly property to True. Also change its ID to dateTextbox. Double click
on the control to open its coding and add the following code:

protected void Calendar1_SelectionChanged(object sender, EventArgs e)


{
dateTextBox.Text = Calendar1.SelectedDate.ToString("MM/dd/yyyy");
}

The date clicked by the user is Postback and is displayed in the textbox which is
uneditable.

55
Software Engineering Lab Session 11
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 11

OBJECT
Working with Databases in ASP.Net

THEORY

Microsoft provides a tool window in Visual Studio 2008 IDE called the Server
Explorer which is a management console for any server (or system) and is used to open
databases, manage and control the data of different databases, manage system services,
and so on. Whenever a project is opened in ASP.Net the server explorer is also visible
often tabbed with the Solution explorer.

Figure 11.1 : Server Explorer

ActiveX Data Objects

ADO.NET is a set of classes that expose data access services to the .NET programmer.
ADO.NET provides functionality to developers writing managed code, consistent access
to data sources such as Microsoft SQL Server, as well as data sources exposed through
OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to
these data sources and retrieve, manipulate, and update data. Its primary objects are:

DataSet objects are in-memory representations of data. They contain multiple Datatable
objects, which contain columns and rows, just like normal database tables. You can even
define relations between tables to create parent-child relationships. The DataSet is
specifically designed to help manage data in memory and to support disconnected
operations on data.

56
Software Engineering Lab Session 11
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Connection object creates the connection to the database. Microsoft Visual Studio .NET
provides two types of Connection classes: the SqlConnection object, which is designed
specifically to connect to Microsoft SQL Server, and the OleDbConnection object, which
can provide connections to a wide range of database types like Microsoft Access and
Oracle.

Command objects are used to execute commands to a database across a data connection.

They provide three methods that are used to execute SQL commands on the database:

ExecuteNonQuery: Executes commands that have no return values such as INSERT,


UPDATE or DELETE.

ExecuteScalar: Returns a single value from a database query.

ExecuteReader: Returns a result set by way of a DataReader object.

DataReader object provides a forward-only, read-only, connected stream record set


from a database. It allows you to obtain the results of a SELECT statement from a
command object.

DataAdapter object contains a reference to the connection object and opens and closes
the connection automatically when reading from or writing to the database. Additionally,
the data adapter contains command object references for SELECT, INSERT, UPDATE,
and DELETE operations on the data

Working with SQL database

Creating a Database

Right click on the root directory on the Solution Explorer window and select Add New
Item. From the pop-up window select the SQL Database and assign a name to the
database (e.g. StudentDB.mdf). To add a new table click on Server Explorer then right
click the Tables Option shown beneath the database filename and click Add New Table.
Insert all the column names of the database along with their data types in the database.
Also rename the table with an appropriate name.

Connecting to Database

Drag a SQL Data source from the Data Toolbox into the webpage. Click on the arrow
present on the upper right corner of the Data Source (known as Smart tag) as shown in
figure 2. Select Configure Data Source to make a new connection. A popup window will
appear asking the user to choose the database from a drop down list. Select the desired
database and click Next. After passing through a series of steps in which the connection
string will be saved and also the required columns in the table are selected, the database
connection is established.

57
Software Engineering Lab Session 11
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 11.2: Adding an SQL Data Source

Displaying the Data on the Webpage

To view the data present in a table on the webpage, drag the table to be shown on to the
design window or drag the GridView or DetailsView in the data Toolbox and click on the
arrow on its upper right corner and in choose the data source option, select the desired
SQLDataSource.

Working with SQL database using ADO.NET

Creating a Database

Right click on the root directory on the Solution Explorer window and select Add New
Item. From the pop-up window select the SQL Database and assign a name to the
database (e.g. ItemDB.mdf). To add a new table click on Server Explorer then right click
the Tables Option shown beneath the database filename and click Add New Table. Insert
all the column names of the database along with their data types in the database. Also
rename the table with an appropriate name.

Consider an example to create the columns with name ID and CategoryName and
select appropriate data types. Select the column ID as primary key. Also rename the table
as Categories.

ID CategoryName
1 abcd
2 efgh
Figure 11.3: Table with test data

To display the database records

The SqlConnection object holds the connection string that connects the database engine
to the ItemDB.mdf database. To provide appropriate connection string to this connection

58
Software Engineering Lab Session 11
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

object, drag a SQL Data source from the Data Toolbox into the webpage. Select
Configure Data Source to make a new connection. A popup window will appear asking
the user to choose the database from a drop down list. Select the desired database. Open
the ConnectionString tab below to get the required string. This connection string is to be
copied in the code.

The SqlCommand.ExecuteReader( ) method creates an SqlDataReader object to read


these records. The DataGrid is connected to the data reader through its
DataGrid.DataSource property.

When the DataGrid.DataBind( ) method executes, database records are moved from the
database to the DataGrid, which displays them one record per row.

From the toolbox, drag a DataGrid to the Web form. Switch to code view by double-
clicking the form. Add this line to the using statements at the beginning of
Default.aspx.cs.

using System.Data.SqlClient;

Insert this code into the Page Load method:

private void Page_Load(object sender, System.EventArgs e)

if(!IsPostBack)
ReadData( );
}

Add the ReadData method just after the Page Load method

public void ReadData()


{

SqlDataReader rdr = null;


SqlConnection conn = null;
try
{
conn = new SqlConnection("Data Source=(local);Initial
Catalog=Northwind; Integrated Security=SSPI");

// Open the connection


conn.Open();

// 1. Instantiate a new command with a query and conne


ction

59
Software Engineering Lab Session 11
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

SqlCommand cmd = new SqlCommand("select CategoryName f


rom Categories", conn);

// 2. Call Execute reader to get query results

rdr = cmd.ExecuteReader();
Datagrid1.DataSource = rdr;
Datagrid1.DataBind ();

// print the CategoryName of each record

while (rdr.Read())
{
Console.WriteLine(rdr[0]);
}
}
finally
{
// close the reader
if (rdr != null)
{
rdr.Close();
}

// Close the connection


if (conn != null)
{
conn.Close();
}
}
}

Press F5 to launch the Web application under the debugger. The contents of the database
should appear in the browser.

abcd
efgh

Figure 11.4: The database as seen in the browser

60
Software Engineering Lab Session 12
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 12
OBJECT

Exploring some concepts of Cascading Style Sheets in ASP.Net

THEORY

Cascading Style Sheets

Professionally, whenever a webpage is designed is more often contain more than one
webpage. The basic design of the webpage like the fonts used or the background color etc
should be consistent to give it a uniform professional look. For this purpose style sheets
are used. CSS is a Style Sheet language that is used to describe the presentation of the
markup tags present in HTML. The style sheet reduces the complexity in the code by
providing all the similar styles at one place, thus reducing repetition and length of code.

To add a style sheet in the project, click Add New Item from the root directory and add
the Style Sheet from there. The style sheet is now open having an extension .css. If the
syntax for adding different styles to the style sheet is known, they can be simply typed-in.
Other way of creating new styles is to click on the Build Style icon present on the Style
sheet toolbar. If the toolbar is not visible, select it from View  Toolbars  Style Sheet.
The Style Builder window pops up as shown in the figure 1.

Figure 12.1: Building a style sheet

61
Software Engineering Lab Session 12
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Different tabs are available in this Style Builder window. The Font tab is used to set the
font family, font color, font size, the impact of making some text italic, bold and so on.
The Background tab is used to set the background color and the background image. The
background image to be set should be dragged on to the App_Data folder of this project,
which is visible in the Solution Explorer. The Text tab sets the alignment of the text,
along with its indentation and spacing between paragraphs. The Position tab sets the
position to absolute or normal etc. The Layout tab deals with the flow control, overflow
conditions and page breaks. The Edges page of the Style Builder dialog box makes it
possible to define cascading style sheet (CSS) style attributes that determine the border
and margins for the area surrounding an HTML element. The List tab will set the list type
like whether it should be bulleted or not. If bulleted then what type of bullets it should
have. The Other tab can define the type of cursor visible to the user and the setting of the
borders in a table.

Adding a style sheet to a webpage

Once a style sheet is build and saved, now this style sheet can be added to the webpage(s)
in the project. For this purpose, select ViewManage Styles. Click Attach Style Sheet, a
window appears through which the style sheet can be added to the webpage.

Figure 12.2: Adding a style sheet to web page

62
Software Engineering Lab Session 12
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Adding Style Rule

If the style is to be set for a particular tag or a particular text, then instead of building a
style, you can define the style rule. The Add Style Rule icon is present in the toolbar and
by clicking it the dialog box shown in figure 3 appears. From here choose a type of CSS
style selector from one of the following:
Select an Element (for example, choose the BODY element to define a default
background, a font-family, or link colors for your page).
Enter a Class name (this defines a style that can be used to format multiple
elements on your page).
Enter an Element ID (this defined a style used to format just one element on your
page).

Enter a Class name as Button, after creating it, click Build Style to provide some style
for this class. Go back to the webpage Default.aspx, drag a button on the page, open its
properties, here select the property CssClass and provide the Class name to this control,
the style will be applied on this button.

Figure 12.3: Add Style Rule Dialog box

63
Software Engineering Lab Session 12
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Figure 12.4: Applying Style rule on the control


Similarly, create an Element ID as label [in figure 3]. Go back to Default.aspx
webpage, drag a label, open its properties to change its ID to label.

Figure 12.5: Applying Style rule on the control

64
Software Engineering Lab Session 13
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 13
OBJECT

Working with Master Pages in ASP.Net

THEORY

Master Pages

One of the most prominent features of ASP.NET is a technique called Master Pages. It
provides the means to define the overall layout of an ASP.NET application at a single
point (the .master file) and reuse it in all content pages that derive from the master.
Updates to the layout can be done quickly and will be applied to the content pages
immediately.

Master Pages are templates that can be created to control the look and feel of the content
pages. If multiple pages share the same header, footer, navigation bar, and content
elements, for example, Master Pages will make this work much easier. This model allows
developers to define and centralize a site-wide page layout, thereby making it easier to
create a consistent look and feel across all pages that can easily be updated.

Creating a Master Page

To create a master page, right-click on the project name in the Solution Explorer and
choose Add New Item. Then select the Master Page type from the list of templates and
rename it as FirstMasterPage.master. The master page can be edited using the design
view as well as source view. If a style sheet is to be added here, select the document in
the properties window and provide the link of the .css file in the Style Sheet property.

By default a Content Place Holder is visible in the Master page. In the source view, the
following code is visible for this Content Place holder:

<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">


</asp:ContentPlaceHolder>

Any text that is written in between these tags will be visible in the master page only. This
means that the contents of this place holder will vary from webpage to webpage while the
contents outside it will remain static. Multiple content holders can be added to give space
for more contents. A Content Place Holder can be added in a webpage by dragging it
from the Standard toolbox.

65
Software Engineering Lab Session 13
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Sometimes it is difficult to move a Content Place Holder or to align it to a desired place.


To do so, add a table to the webpage and drag the Content Place Holder to a desired cell.
This will help in achieving a uniform and more professional look.

Adding Master Page to a Webpage

A Master Page can be added to a new webpage as well as the existing pages. To add the
Master page to a new webpage, first click the Add New Item from the root directory and
then add a new Web Form. On the lower right corner of this Add New Item window,
there is a check box to Select Master page. Check this option and click OK. Another
window will pop up asking to select which Master Page you want to add. Select the
desired master page and click OK.

To add Master page to an existing page add the following code, with necessary changes
as per your requirements, should be added in the Source View of the webpage.

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"


AutoEventWireup="true" CodeFile="Home.aspx.cs"
Inherits="Home" Title="Untitled Page" %>
<asp:Content ID="Content1"
ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">
</asp:Content>

Here the MasterPageFile should contain the file name of the Master Page that is present
in the project. The CodeFile contains the name of the webpage in which this code is
added. The ContentPlaceHolderID should also be changed if it is changed on the Master
Page.

Creating a Site Map

One of the challenges of managing a website composed of more than a handful of pages
is providing a straightforward way for visitors to navigate through the site. To begin with,
the site's navigational structure must be defined. Next, this structure must be translated
into navigable user interface elements, such as menus or breadcrumbs. Finally, this whole
process needs to be maintained and updated as new pages are added to the site and
existing ones removed.

The ASP.NET 2.0 site navigation system provides a means for a developer to define a
site map and to then access this information through a programmatic API. ASP.NET
ships with a site map provider that expects site map data to be stored in an XML file
formatted in a particular way.

To add a site map, click on the root directory to add a new item and select the Site Map
from the Add New Item Window. Change the Site Map file to look something like this:

66
Software Engineering Lab Session 13
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

<?xml version="1.0" encoding="utf-8" ?>


<siteMap
xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-
1.0" >

<siteMapNode url="Home.aspx" title="Home"


description="This is the home page" >

<siteMapNode url="Login.aspx" title="Login"


description="This is the Login page" />

<siteMapNode url="SignIn.aspx" title="Sign In"


description="This is the Sign Up page" />

</siteMapNode>
</siteMap>

The site map file is an XML file. The site map file must have the <siteMap> node as its
root node, which must contain precisely one <siteMapNode> child element. That first
<siteMapNode> element can then contain an arbitrary number of descendent
<siteMapNode> elements.

There are three options to include a site map to a webpage:

1. SiteMapPath
2. Menu
3. TreeView

Drag any of the desired view from the Navigation Toolbox into the Master Page or any
other webpage. By using the Smart Tag, select the new data source option from the
Choose Data Source menu. Select the SiteMap from the pop up window and click OK.
The menus can be formatted by using the Auto Format option.

67
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Lab Session 14
OBJECT
Learning to perform software testing
THEORY
Following are the general steps followed during software testing:-
1. Choosing Test Data
The choice of data to be used to test programs and functions, depends on the project under
development. Hence, only general guidelines can be established for choosing test data.
First we should note that the quality of test data is more important than its quantity.
Many sample runs that do the same calculations in the same cases provide no more
effective a test than one run. It is possible that other cases remain that have never been
tested even after many sample runs. However, for any program of substantial complexity,
it is impossible to perform exhaustive tests, yet the careful choice of test data can provide
substantial confidence in the program.
Everyone, for example, has great confidence that the typical computer can add two
floating point numbers correctly, but this confidence is certainly not based on testing the
computer having it add all possible floating point numbers and checking the results.
2. Testing Methods
a) The Black-Box Method
Most users of a large program are not interested in the details of its functioning. That is,
they wish to treat the program as a black box.
Data Selection for Black Box Testing
Test data should be chosen according to the specifications of the problem, without regard
to the internal details of the program, to check that the program operates correctly. At a
minimum the test data should be selected in the following ways:-
Easy Values
Generally, programmers who try a program only for complicated data, and think it
works properly, are embarrassed when an independent tester tries trivial data.
Typical Realistic Values
Always try a program on data chosen to represent how the program will be used.
Extreme Values
Many programs err at the limits of their range of applications. It is very easy for
counters or array bounds to be off by one.
Illegal Values
Garbage In, Garbage Out is an old saying in computer circles that should not be
respected. When a good program has garbage coming in, then its output should at
least be a sensible error message. Indeed, the program should provide some indication

68
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

of the likely errors in input and perform any calculations that remain possible after
discarding the erroneous input.

b) The Glass-Box Method


In the glass-box method of testing, tests are derived from knowledge of the software's
structure and implementation. In fact, understanding the algorithm used in a module can
help in identifying further test cases.
Path testing
A form of glass-box testing objective is to exercise every independent execution path
through a component. Ideally all statements must be executed at least once. All
conditions are tested for both true and false cases.
If the program has several selection or iteration statements then it will require different
combinations of test data to check all the paths that are possible. Consider a short
program segment with its possible execution paths and the associated test data to traverse
those paths.
Example 1
switch (a) {
case 1: x = 3; break;
case 2: if (b == 0) x = 2;
else x = 4;
break;
case 3: while (c > 0)
function (c);
break; }

a==1 a==3

a== 2
b == 0 b != 0

x = 3; x = 2; x = 4 ; while (c > 0)
function( c );

69
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

The starting point for path testing is a program (or control) flow graph (to be covered in
the theory class).
An independent program path: One that traverses at least one new edge in the flow
graph.
Cyclomatic Complexity: number of independent paths in a program. Equals to (No. of
simple conditions in the program + 1).
A simple condition: logical expression without and or or connectors.
For instance, if there are six if-statements and a while loop and all conditional
expressions are simple, the cyclomatic complexity is 8.
Example 2
Following program segment grants scholarship to a candidate based on his or her
academic and financial background:-
1. if (P_HSC >= 80)
2. { InitialAmount = 15000;
3. Increment = 3000; }
4. else if ((P_HSC >= 70) && (P_SSC >= 80))
5. { InitialAmount = 12000;
6. Increment = 2000; }
7. else if ((P_HSC >= 60) && (P_SSC >= 80) && (GuardianSalary < 20000))
8. { InitialAmount = 10000;
9. Increment = 1000; }
10. else
11. { InitialAmount = 0;
12. Increment = 0; }
13. Print InitialAmount, Increment
Objective: Identifying the various paths in the above code module and developing test
cases for each.
Solution: The number of simple conditions = 6 so the Cyclomatic Complexity = 6 + 1 =
7. Developing control graph of the given code can be taken as an exercise for the theory
course. Next, listed below are the test cases for each of the seven independent paths
identified:-
1. P_HSC = 85
2. P_HSC = 55
3. P_HSC = 75, P_SSC = 70
4. P_HSC = 75, P_SSC = 85
5. P_HSC = 65, P_SSC = 70
6. P_HSC = 65, P_SSC = 85, GuardianSalary = 25000
7. P_HSC = 65, P_SSC = 85, GuardianSalary = 15000
The students are required to test the given code segment over the above test cases and
note and distinguish the paths followed in each case. Finally write down their
observations in exercise (c) given below.

70
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

For a large program glass-box approach is clearly not practicable, but for a single small
module, it is an excellent testing method. In a well-designed program, each module will
involve few loops and alternatives. Hence only a few well-chosen test cases will suffice
to test each module on its own.
Conclusion
A reasonable testing philosophy for a large project would be to apply glass-box methods
to each small module as it is written and use black-box test data to test larger sections of
the program when they are complete.
EXERCISES
a) Find suitable black-box test data for each of the following.
i) A function that returns the largest of its three parameters, which are real numbers.

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

___________________________________________________________________

ii) A function that returns the least common multiple of its two parameters, which
must be positive integers.

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

iii) A function that returns the square root of a real number.

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________
iv) A function that sorts an array A of integers indexed from 0 to a variable n-1
into ascending order, where A and n are both parameters.

71
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

____________________________________________________________________

b) Find suitable glass-box test data for the following statement.

if (a < b) if (c > d) x = 1; else if (c == d) x = 2;


else x = 3; else if (a == b) x = 4; else if (c == d) x = 5;
else x = 6;

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

c) Give a suitable account of the execution of seven test cases in example 2 above.

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

72
Software Engineering Lab Session 14
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________
d) Following function finds the count of digits in integers in the range of 1000 and 10000000.
int count_digit (unsigned long int num)
{ int cnt = 0;

if (num < 1000 || num > 10000000) return(-1);


do
{ cnt++;
num = num/10; }
while (num != 0);
return(cnt); }
Calculate the cyclomatic complexity and develop five suitable test cases for the function.

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

73
APPENDIX

74

Software Engineering SRS Template
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Software Requirements
Specification

for

<Project>

Version <X.X>

Prepared by

Group Name: <place your group name here>


<name> <student #> <e-mail>
<name> <student #> <e-mail>
<name> <student #> <e-mail>
<name> <student #> <e-mail>

Instructor: <place your instructors name here>

Date: <place the date of submission here>

i
Software Engineering SRS Template
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Contents
REVISIONS .............................................................................................................................................................. III

1 INTRODUCTION ...............................................................................................................................................1
1.1 DOCUMENT PURPOSE ................................................................................................................................1
1.2 PRODUCT SCOPE .......................................................................................................................................1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW ...................................................................................1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS .......................................................................................1
1.5 DOCUMENT CONVENTIONS ........................................................................................................................1
1.6 REFERENCES AND ACKNOWLEDGMENTS ..................................................................................................2
2 OVERALL DESCRIPTION...............................................................................................................................3
2.1 PRODUCT PERSPECTIVE ............................................................................................................................3
2.2 PRODUCT FUNCTIONALITY .........................................................................................................................3
2.3 USERS AND CHARACTERISTICS .................................................................................................................3
2.4 OPERATING ENVIRONMENT........................................................................................................................3
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS ..........................................................................................4
2.6 USER DOCUMENTATION .............................................................................................................................4
2.7 ASSUMPTIONS AND DEPENDENCIES ..........................................................................................................4
3 SPECIFIC REQUIREMENTS ..........................................................................................................................5
3.1 EXTERNAL INTERFACE REQUIREMENTS ....................................................................................................5
3.2 FUNCTIONAL REQUIREMENTS ....................................................................................................................6
3.3 BEHAVIOUR REQUIREMENTS .....................................................................................................................6
4 OTHER NON-FUNCTIONAL REQUIREMENTS..........................................................................................7
4.1 PERFORMANCE REQUIREMENTS................................................................................................................7
4.2 SAFETY AND SECURITY REQUIREMENTS ...................................................................................................7
4.3 SOFTWARE QUALITY ATTRIBUTES .............................................................................................................7
5 OTHER REQUIREMENTS ..............................................................................................................................8

APPENDIX A DATA DICTIONARY ......................................................................................................................9

ii
Software Engineering SRS Template
NED University of Engineering & Technology Department of Computer & Information Systems Engineering

Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does 00/00/00
and not need to be filled in whenever a document is
Number touched, only when the version is being upgraded.

<In this template you will find text bounded by the <> symbols. This text appears in italics and
is intended to guide you through the template and provide explanations regarding the different
sections in this document. There are two types of comments in this document. These
comments that are in black are intended specifically for that course. These comments that are
in blue are more general and apply to any SRS. Please, make sure to delete all of the
comments before submitting the document.

The explanations provided below, do not cover all of the material, but merely, the general
nature of the information you would usually find in SRS documents. It is based on the IEEE
requirements. Most of the sections in this template are required sections, i.e. you must include
them in your version of the document. Failure to do so will result in marks deductions. Optional
sections will be explicitly marked as optional.>

iii
Software Requirements Specification for <Project> Page 1

1 Introduction
<TO DO: Please provide a brief introduction to your project and a brief overview of what the reader
will find in this section.>

1.1 Document Purpose


<Identify the product whose software requirements are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SRS,
particularly if this SRS describes only part of the system or a single subsystem.
TO DO: Write 1-2 paragraphs describing the purpose of this document as explained above.>

1.2 Product Scope


<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals.
TO DO: 1-2 paragraphs describing the scope of the product. Make sure to describe the benefits
associated with the product.>

1.3 Intended Audience and Document Overview


<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers (In your case it would
probably be the client and the professor). Describe what the rest of this SRS contains and how it
is organized. Suggest a sequence for reading the document, beginning with the overview sections
and proceeding through the sections that are most pertinent to each reader type.>

1.4 Definitions, Acronyms and Abbreviations


<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.
TO DO: Please provide a list of all abbreviations and acronyms used in this document sorted in
alphabetical order.>

1.5 Document Conventions


<In general this document follows the IEEE formatting requirements. Use Arial font size 11, or 12
throughout the document for text. Use italics for comments. Document text should be single
spaced and maintain the 1 margins found in this template. For Section and Subsection titles
please follow the template.

TO DO: Describe any standards or typographical conventions that were followed when writing this
SRS, such as fonts or highlighting that have special significance. Sometimes, it is useful to divide
this section to several sections, e.g., Formatting Conventions, Naming Conventions, etc.>

1
Software Requirements Specification for <Project> Page 2

1.6 References and Acknowledgments


<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document.

TO DO: Use the standard IEEE citation guide for this section>

2
Software Requirements Specification for <Project> Page 3

2 Overall Description

2.1 Product Perspective


<Describe the context and origin of the product being specified in this SRS. For example, state
whether this product is a follow-on member of a product family, a replacement for certain existing
systems, or a new, self-contained product. If the SRS defines a component of a larger system,
relate the requirements of the larger system to the functionality of this software and identify
interfaces between the two. In this part, make sure to include a simple diagram that shows the
major components of the overall system, subsystem interconnections, and external interface. In
this section it is crucial that you will be creative and provide as much information as possible.

TO DO: Provide at least one paragraph describing product perspective. Provide a general diagram
that will illustrate how your product interacts with the environment and in what context it is being
used.>

2.2 Product Functionality


<Summarize the major functions the product must perform or must let the user perform. Details
will be provided in Section 3, so only a high level summary is needed here. Organize the functions
to make them understandable to any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow diagram or object class diagram,
will be effective.
TO DO:
1. Provide a bulleted list of all the major functions of the system
2. (Optional) Provide a Data Flow Diagram of the system to show how these functions relate to
each other.>

2.3 Users and Characteristics


<Identify the various users that you anticipate will use this product. Users may be differentiated
based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience.
TO DO:
1. Describe the pertinent characteristics of each user. Certain requirements may pertain only to
certain users.
3. Distinguish the most important users for this product from those who are less important to
satisfy.>

2.4 Operating Environment


<Describe the environment in which the software will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must peacefully coexist. In this part, make sure to include a simple diagram that shows the major
components of the overall system, subsystem interconnections, and external interface
TO DO: As stated above, in at least one paragraph, describe the environment your system will
have to operate in. Make sure to include the minimum platform requirements for your system. >

3
Software Requirements Specification for <Project> Page 4

2.5 Design and Implementation Constraints


<Describe any items or issues that will limit the options available to the developers. These might
include: hardware limitations (timing requirements, memory requirements); interfaces to other
applications; specific technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customers organization will be responsible for
maintaining the delivered software).
TO DO: In this section you need to consider all of the information you gathered so far, analyze it
and correctly identify at least 5 constraints.>

2.6 User Documentation


<List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software. Identify any known user documentation delivery formats
or standards.
TO DO: You will not actually develop any user-manuals, but you need to describe what kind of
manuals and what kind of help is needed for the software you will be developing. One paragraph
should be sufficient for this section.>

2.7 Assumptions and Dependencies


<List any assumed factors (as opposed to known facts) that could affect the requirements stated in
the SRS. These could include third-party or commercial components that you plan to use, issues
around the development or operating environment, or constraints. The project could be affected if
these assumptions are incorrect, are not shared, or change. Also identify any dependencies the
project has on external factors, such as software components that you intend to reuse from
another project.
TO DO: Provide a short list of some major assumptions that might significantly affect your design.
For example, you can assume that your client will have 1, 2 or at most 50 Automated Banking
Machines. Every number has a significant effect on the design of your system. >

4
Software Requirements Specification for <Project> Page 5

3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the
users. This may include sample screen images, any GUI standards or product family style guides
that are to be followed, screen layout constraints, standard buttons and functions (e.g., Cancel)
that will appear on every screen, error message display standards, and so on. Define the software
components for which a user interface is needed.
TO DO: The least you can do for this section is to describe in words the different User Interfaces
and the different screens that will be available to the user. Those who will be able to provide
optional Graphical User Interface screenshots, will be rewarded by extra marks.>

3.1.2 Hardware Interfaces

<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware. You are not
required to specify what protocols you will be using to communicate with the hardware, but it will
be usually included in this part as well.
TO DO: Please provide a short description of the different hardware interfaces. If you will be using
some special libraries to communicate with your software mention them here. In case you have
more than one hardware interface divide this section into subsections.>

3.1.3 Software Interfaces

<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems (Windows? Linux? Etc), tools, libraries,
and integrated commercial components. Identify the data items or messages coming into the
system and going out and describe the purpose of each. Describe the services needed and the
nature of communications. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a global data
area in a multitasking operating system), specify this as an implementation constraint.

TO DO: The previous part illustrates some of the information you would usually include in this part
of the SRS document. To make things simpler, you are only required to describe the specific
interface with the operating system.>

3.1.4 Communications Interfaces


<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication standards
that will be used, such as FTP or HTTP. Specify any communication security or encryption issues,
data transfer rates, and synchronization mechanisms.

TO DO: Do not go into too much detail, but provide 1-2 paragraphs were you will outline the major
communication standards. For example, if you decide to use encryption there is no need to specify

5
Software Requirements Specification for <Project> Page 6
the exact encryption standards, but rather, specify the fact that the data will be encrypted and
name what standards you consider using. >

3.2 Functional Requirements

< Functional requirements capture the intended behavior of the system. This behavior may be
expressed as services, tasks or functions the system is required to perform. This section is the
direct continuation of section 2.2 where you have specified the general functional requirements.
Here, you should list in detail the different product functions with specific explanations regarding
every function.

TO DO: Break the functional requirements to several functional areas and divide this section into
subsections accordingly. Provide a detailed list of all product operations related to these functional
areas.

3.3 Behaviour Requirements

3.3.1 Use Case View

<A use case defines a goal-oriented set of interactions between external actors and the system
under consideration. Since sometimes we will not be able to specify completely the behaviour of
the system by just State Diagrams, we use use-cases to complete what we have already started in
section 3.3.1.

TO DO: Provide a use case diagram which will encapsulate the entire system and all possible
actors. Do not include detailed use case descriptions (these will be needed when you will be
working on the Test Plan), but make sure to include a short description of what every use-case is,
who are the actors in your diagram.>

6
Software Requirements Specification for <Project> Page 7

4 Other Non-functional Requirements

4.1 Performance Requirements


<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.
TODO: Provide at least 5 different performance requirements based on the information you
collected from the client. For example you can say 1. Any transaction will not take more than 10
seconds, etc>

4.2 Safety and Security Requirements


<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the products design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements.
TODO:
Provide at least 3 different safety requirements based on your interview with the client, and
again you need to be creative here.
Describe briefly what level of security is expected from this product by your client and
provide a bulleted (or numbered) list of the major security requirements.>

4.3 Software Quality Attributes


<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Portability, etc) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
This software shall be maintainable Indicate how you plan to achieve it, & etcDo not forget to
include such attributes as the design for change. Please note that you need to include at least 2
quality attributes, but it is the mere minimum and it will not receive the full marks.>

7
Software Requirements Specification for <Project> Page 8

5 Other Requirements
<This section is Optional. Define any other requirements not covered elsewhere in the SRS. This
might include database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the project.>

8
Software Requirements Specification for <Project> Page 9

Appendix A Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that
you described in your document. Make sure to include the complete list of all constants, state
variables (and their possible states), inputs and outputs in a table. In the table, include the
description of these items as well as all related operations and requirements.>