Software Engineering BTCS 506-18

Practical-1
Aim : Study and usage of OpenProj or similar software to draft a project plan.
Introduction: - Project managers can use OpenProj, a free task tracking application, when
creating effective plans. OpenProj delivers functionality that rivals the capabilities of commercial
software. This can save thousands of dollars in startup costs. Of course, saving a lot of money can
be foolish if the required tasks can't be done. This is not the case with OpenProj. Luckily the
OpenProj application gives managers a full set of tools that are typically used to track projects.
Useful aids such as critical path analysis, resource tracking and task comments are all present in
OpenProj. The tool is ideal for simple project management but is capable of larger efforts as well.

Fig no: -1

For the purposes of the example project plan, the following assumptions are made:
-The OpenProj software has already been installed and correctly configured on a workstation with
an attached printer
The goal is to launch a new marketing effort in 6 months, called "Anganwadi"
There are three full-time staff resources, including the manager
Budget is not a consideration
Schedule is the primary consideration
The target implementation date is 6 months away but is not an absolute fixed date

Page 1
Software Engineering BTCS 506-18

Step 1: Create the project plan shell:

The first step is to use OpenProj to identify the basic parameters. The manager starts the OpenProj
application and presses the "Create Project" button. The file is named, ("Anganwadi"), and a starting
date is given. You can forward schedule which is the default. This allows you to enter the required
tasks and OpenProj will calculate a completion date. If required, you can schedule a finish date and
have OpenProj work backwards for you. This alternate method works best if there is a hard drop-
dead date, such as a launch date. The project manager can also add initial project notes. These might
refer to locations of phase initiation documentation or other optional information.

Fig no: -2

Step 2: Identify the project resources

Use the resources view to enter the particulars of all of the project team. The names and roles of the
team members can be specified. If required, you can enter hourly rates, overtime and availability
information for each team member. For this example, three 100% resources will be entered.

Page 2
Software Engineering BTCS 506-18

Fig no: -3

Step 3: Identify the high-level tasks

For this example, the project is similar to an earlier effort that was completed successfully. That
work required tasks for initiation, research, contracting, development and launch. The project
manager enters these tasks into the Gantt view of OpenProj. The duration estimates

are based on the values previously seen for similar tasks. There is no ordering of tasks or
dependencies. The raw Gantt list is below.

Notice that the task "Application Development" is shown with a red duration bar while all other
tasks have blue bars. This task is identified as the project critical path. It is the longest running task
in the project. Since all tasks default to the start date of the project, the analysis of the critical path
is quite premature at this time. The project manager must now modify dependencies.

Page 3
Software Engineering BTCS 506-18

Step 4: Identify the task dependencies for critical path analysis

During a effort, some tasks can't start until others have been completed. This is true for the "Test
launch" task. There is nothing to test until the development is completed. As well, the "News
Shower" launch is dependent on every other task. The project manager, in discussions with team
members or sponsors as appropriate, determines the task dependencies. The modified Gantt view
now shows a realistic schedule.
.

Fig no: -4

Notice that there is now a critical path, shown as a red bar, that is comprised of two tasks. The
other tasks are completed in parallel and don't affect the critical path. At this point, no resources
have been assigned to the tasks. No tasks have been split into component

Step 5: Assign project resources to tasks

Each of the tasks can have one or more resources assigned. The column "Resource Names" on the
Gantt View allows direct data entry of this information. Enter the name of a resource in the field.
The default action is to have each named resource work 100% of their time on the task. The field
also supports the direct entry of multiple resources. Enter the resource names separated by a semi-
2002633 Page 4
Software Engineering BTCS 506-18

colon.

Fig no: -5

2002633 Page 5
Software Engineering BTCS 506-18

Step 6: Task elaboration

An important feature of project management applications is the ability to allow the manager to split
tasks into smaller sub-tasks. This can allow better accuracy in schedule estimating. It also allows team
members to be specified in a just-in-time fashion for their assignments. The example project has some
opportunities for task elaboration

Fig no: -6

Step 7: Evaluate the project plan

2002633 Page 6
Software Engineering BTCS 506-18

With all of the tasks entered, and sub-tasks specified, the plan has really evolved. It now shows a lot
of information which can be useful in project reporting. The first item is the critical path. This of the
highest importance to the project manager and the organization. Reports showing the tasks can be
presented to company executives. An analysis of work loads can be done. Task reports can be
printed. In time, as completion percentages are entered for tasks, the project manager can run status
reports showing progress and schedule tracking.

Result: The total project Cost is predicted.

2002633 Page 7
Software Engineering BTCS 506-18

Practical-2

Aim: Study and usage of Openproj to track the progress of a project.

Finding the right project management solution for your team can be very hard. Finding an open
source project management solution may be even harder. That's the mission of a solution that allows
teams to collaborate throughout the project life cycle. Additionally, the project aims to replace
proprietary software like Microsoft Project Server or Jira.

The OpenProject objectives:

Establish and promote an active and open community of developers, users, and companies for
continuous development of the open source project.
Define and develop the project vision, the code of conduct, and principles of the application.
Create development policies and ensure their compliance.
Define and evolve the development and quality assurance processes.
Provide the source code to the public.
Provide and operate the OpenProject platform.

Mission of OpenProject
The mission of OpenProject can be quickly summarized: we want to build excellent open source
project collaboration software. And when I say open source, I meant it. We strive to make
OpenProject a place to participate, collaborate, and get involved—with an active, open- minded,
transparent, and innovative community.
Companies have finally become aware of the importance of project management software and also
the big advantages of open source. But why is it that project teams still tend to switch to old-
fashioned ways of creating project plans, task lists, or status reports with Excel, PowerPoint, or
Word—or having other expensive proprietary project management software in use? We want to
offer a real open source alternative for companies: free, secure, and easy to use.
Progress of the project is as below:-

2002633 Page 8
Software Engineering BTCS 506-18

2002633 Page 9
Software Engineering BTCS 506-18

Figures 2.1-2.4:-Project Progress Screenshots

Maintenance will keep on going till the lifetime of this project.

Result: The progress of the project is tracked.

2002633 Page 10
Software Engineering BTCS 506-18

Practical- 3

Aim: Preparation of Software Requirement Specification Document and

Design Documents

Theory:

I) Software Requirement Specification Document

1. Introduction
The is the Software Requirements Specification (SRS) for online shopping projectt. It describes
the functions, goals and tasks that this project performs. This is used to describe the scope of the
project and to plan the system's design and implementation.
1.1 Purpose

This document is meant to delineate the features of OSS, so as to serve as a guide to the
developers on one hand and a software validation document for the prospective client on the
other.

The Online Shopping System (OSS) for electronics item shop web application is intended to
provide complete solutions for vendors as well as customers through a single get way using the
internet.It will enable vendors to setup online shops, customer to browse through the shop and
purchase them online without having to visit the shop physically. The administration module
will enable a system administrator to approve and reject requests for new shops and maintain
various lists of shop category.

1.2 Scope

This system allows the customer’s to maintain their cart for add or remove the product over the
internet.

1.3 Definitions:

2002633 Page 11
Software Engineering BTCS 506-18

OSS- Online shopping System (for electronics item shop)

SRS- Software Requirement Specification

GUI- Graphical User Interface

Stackholder- The person who will participate in system

Ex. Customer, Administrator, Visitor etc.

1.5 Overview:

This system provides an easy solution for customers to buy the product without going to the shop
and also to shop owner to sale the product.

This proposed system can be used by any naïve users and it does not require any educational
level,experience or technical expertise in computer field but it will be of good use if user has the
good knowledge of how to operate a computer.

2. Overall Description:

The Online Shopping system (OSS) application enables vendors to set up online shops,
customers to browse through the shops, and a system administrator to approve and reject requests
for new shops and maintain lists of shop categories. Also the developer is designing an online
shopping site to manage the items in the shop and also help customers to purchase them online
without visiting the shop physically.The online shopping system will use the internet as the sole
method for selling goods to its consumers.

2.1 Product Perspective:

This product aimed toward a person who don’t want to visit the shop as he might don’t get time
for that or might not interested in visiting there and dealing with lot of formalities.

2.2 Product Functions:

OSS should support this use case:

2002633 Page 12
Software Engineering BTCS 506-18

2.3 User Characeristics:

User should be familiar with the terms like login,register,order system etc.

2.4 Principle Actors:

2 Principle Actors are Customer and Administrator.

2.5 General Constraints:

A full internet connection is required for OSS.

2.6 Assumptions and Dependencies:

Working of OSS need Internet Connection.

3. Specific Requirements:

3.1 Functional Requirements:

2002633 Page 13
Software Engineering BTCS 506-18

This section provides requirement overview of the system.

Various functional modules that can be implemented by the system will be -

3.1 Description:

the product logout.

3.1.1 Registration

If customer wants to buy the product then he/she must be registered, unregistered user can’t go
to the shopping cart.

3.1.2 Login

Customer logins to the system by entering valid user id and password for the shopping.

3.1.3 Changes to Cart

Changes to cart means the customer after login or registration can make order or cancel order of
the product from the shopping cart.

3.1.4 Payment

In this system we are dealing the mode of payment by Cash.We will extend this to credit
card,debit card etc in the future.

3.1.5 Logout

After ordering or surfing for customer has to logout.

3.1.6 Report Generation

After ordering for the product,the system will sent one copy of the bill to the customer’s Email-
address and another one for the system data base.

3.2 Non-Functional Requirements:

2002633 Page 14
Software Engineering BTCS 506-18

Following Non-Functional Requirements will be there in the insurance to the internet:

(ii) 24X7 availability.

(iii) Better component design to get better performance at peak

time.

(iv) Flexible service based architecture will be highly desirable for

future extension.Non-Functional Requirements define system properties and constraints.

Various other Non-Functional Requirements are:

● Security
● Reliability
● Maintainability
● Portability
● Extensibility
● Reusability
● Compatibility
● Resource Utilization

Result: The SRS Document and Design Phase Document is prepared.

Outcome: Students will learn how to prepare the SRS Document and Design phase
document.

2002633 Page 15
Software Engineering BTCS 506-18

Practical -4

Aim: Preparation of Testing Phase related documents for some problem

Testing Phase Testing
1. Introduction
This approach document is designed for the Information and Technology Services System
Development Life Cycle (SDLC) projects.
A. Purpose
The intent of Development/Unit Testing is to efficiently and accurately develop, unit test, and provide
documentation for Designs produced. Repeatable, consistent processes and comprehensive
documentation support this goal. The end result should be increased quality (fewer bugs), and the
reduction of delivery time and effort needed for subsequent projects.

2. Approach

A. Approach Description
The general methodology/approach for SDLC Development/Unit Testing at ITS will involve the following
steps:
Initial planning efforts for this phase will include the establishment of:
A project status reporting approach.
A defect tracking approach.
A metric collection approach for the phase.
(If New Hardware or Configuration) Perform SDLC Environment Setup & Validation Process (9000)
The guidelines for Development and Unit Test work will be:
Eliminate Objects to be obsoleted. System Testing will be the only verification of success for these
changes.
For Objects with Design Documents (S300 – Design Document) the following steps are performed:
Code the Design.
Develop the Unit Test Plan.
Review Code and Unit Test Plan if functionality has been added or changed.
Unit Test the Coded Objects.
Review and Approve the Unit Testing results.

2002633 Page 16
Software Engineering BTCS 506-18

The order in which the Objects should be Developed and Unit-Tested will be based upon all of the following:
Priority assigned.
Grouping of all objects for a Business Process.
Direction of the SDLC Lead or Project Manager.
Ordering of System Testing and Acceptance activities.
Ordering of Objects from Design Phase.
Availability of Test Data.
Steps involved in Coding are as follows:
Review and understand the information in the S300 Design Document.
Determine exactly which objects will need to be changed and update the S300 Design Document to
include that information.
Notify any other ITS units affected by the changes made to the S300 Design Document.
Code the Object using the PS Programming Standards and Guidelines in Lotus Notes. Also refer to the
Development and Unit Test Checklists as informational guidelines.
Notify the Project Manager of any needed changes or additions to the PS Programming Standards and
Guidelines. An interim working standard will be developed to meet this need.
Steps to develop an S404 Unit Test Plan for each S300 Design Document:
Define the conditions to be tested based on functional requirements and include
conditions that exercise every path of new or changed logic.
Follow the Unit Test Process Guidelines in Lotus Notes.
Refer to the Upgrade Unit Test Checklist as an informational guide in the creation,
execution and review of the Unit Test Plan.
Organize testing into cycles to simplify troubleshooting and analysis of results.
Prepare the test model with input data and expected results.
Determine and document test data.
Test good data and boundary conditions.
Ask for Designer’s assistance if needed when identifying and/or creating data
needed for testing.
Follow Test Data Creation Guidelines in Lotus Notes.
Conduct Code and Test Plan Review.
Attendees could include: Tech Lead, Peer, and Designer.

2002633 Page 17
Software Engineering BTCS 506-18

Verify the following of Programming and Unit Testing Standards and Guidelines found
in Lotus Notes.
Utilize the Software Development and Unit Test Checklists as informational guidelines
during reviews.
Update the Unit Test Plan with the appropriate Signoff/Approval signatures.
If the Code and/or Test Plan is not approved, make necessary changes and conduct a
re-review.
Review and obtain signoff of Unit Test results, updating the S404 Unit Test Plan with the appropriate
Signoff/Approval signatures.
Update the Tracking Spreadsheet/Database.
Migrate the Object(s) to the System Test environment in a planned release.

3. Status and Reporting

A. Defect Tracking Approach
During Development/Unit Testing, problems encountered will be tracked within the Tracking
Spreadsheet/Database.

B. Time Tracking & Reporting

The Project Manager will be responsible for ensuring that time is entered into PlanView and that Monthly Status
Reports are created.

C. Metrics To Utilize
Metrics that will be tracked include but are not limited to:
Percentage of Objects with Unit Testing complete

From Planview or the Tracking Spreadsheet/Database.

Also include interim milestones by objects.

Effort Completed as Percentage of Estimated Effort.

From Planview – Time Reported and ETC (Estimated Time to Completion) updates.

Percentage of Effort Earned. (Actual vs. Planned work completed).

Percentage of Effort Remaining – only 100% completion factored in.

2002633 Page 18
Software Engineering BTCS 506-18

Effort Rate

Burn Rate

Green/Yellow/Red tasks.

D. Status/Issues Meetings
During Development/Unit Testing, it is recommended that a weekly status meeting be held at the same
scheduled time on the same day each week. This meeting will support a communication process to inform the
project team of status, problems or issues, and changes. The Agenda will include a review of open high and
medium issues, Unit Test plans, and any action items from the previous week. Meeting minutes should be
taken that include a list of attendees, discussion points, and action items. TIO/AIG, Module Leads, Data
Delivery, Access Services groups etc. should be represented in the meeting, as needed.
E. Acknowledgement
Where deliverables require “acknowledgement”, this means that the responsible party has reviewed the
documentation and feels that the documentation was sufficient. It is important to define who is responsible for
reviewing and approving any results or documentation early in the project lifecycle.
4. Assumptions and Risks
A. Assumptions
The following assumptions are critical to the successful accomplishment of this Approach to Development/Unit
Testing:
An S404 Unit Test Plan is created for each S300 Design Document.

If the Design included cross-functional input and review, then the unit test should also include cross-
functional input and review.

Both Technical and Functional knowledge resources should have input to test plan and results review.

The Designs should be referenced with the Unit Test Plan through document naming and repository
standards as a minimum.

Test Plan and Results Signoff may be different for each team. A provision should be made for Reviewer
and cross-functional Review if needed.

Database tuning help will be available if needed.

Retesting will occur after tuning.

This approach makes the following assumptions for the System Test Phase:
Testing will be conducted for each Business Process.

Reusable test conditions will be utilized, which may include the use of reusable test scripts.

2002633 Page 19
Software Engineering BTCS 506-18

Every business condition will be tested.

Testing will be especially detailed in areas having new functionality.

Regression and integration testing is covered.

Data plans will be included in the System Test Plans.

B. Risks
Completion of Design Phase misses targeted schedule.

Insufficient resource levels.

Production Support activities pull resources away.

Design Phase activities pull developers away.

Infrastructure Changes that impact work processes.

Tasks underestimated for effort and/or duration.

5. Deliverables
Deliverables from the Project Manager
The following deliverables are required.
Updated Development/Unit Test Phase Approach Document, if needed.

Updated Metrics/Tracking Reports

Work Breakdown Structure (WBS)/Schedule - updated tasks and adjusted hours. This is required at
the beginning of the Development/Unit Test Phase, in order to put the WBS into PlanView for tracking
and reporting.

B. Deliverables from the Phase

The following deliverables are required from the Development/Unit Test Phase for it to be considered
completed.
S404 - Unit Test Plan

Unit Test Results

S405 - Dev/Unit Test Phase Completion Checklist

A coded, Unit-Tested Application

C. Deliverables from the Methodology Team

2002633 Page 20
Software Engineering BTCS 506-18

The following deliverables are required.

Updated Process Flows, Templates, or Tools if necessary, based upon project team feedback regarding
successes and challenges.

Appendix
A. Definitions

Test Phases Focus

Unit Test Testing individual modules and programs, and testing them in
sufficient context to insure that work flows correctly through the
affected business process.

Integration/System Test Validates that all processes, including customizations and

interfaces, work together to support the business functions

Volume/Stress Test Validates that critical functions will meet production performance
requirements

User Test Validating production-ready functionality and data integrity

Regression Test Ensures that the application doesn’t negatively impact previously
migrated objects/modules. Re-tests the application to ensure that
the application performs correctly after a package upgrade or
change.

Result: The Testing Phase Document is prepared.

2002633 Page 21
Software Engineering BTCS 506-18

Practical-5

Aim : Preparation of the Software Configuration management and Risk

management related documents.

Software Configuration management

SCM or Software Configuration management is a Project Function (as defined in the SPMP) with the
goal to make technical and managerial activities more effective. Software configuration management
(SCM) is a software engineering discipline consisting of standard processes and techniques often used by
organizations to manage the changes introduced to its software products. SCM helps in identifying
individual elements and configurations, tracking changes, and version selection, control, and baselining.

SCM is also known as software control management. SCM aims to control changes introduced to
large complex software systems through reliable version selection and version control.
The SCM system has the following advantages:
Reduced redundant work.
Effective management of simultaneous updates.
Avoids configuration-related problems.
Facilitates team coordination.
Helps in building management; managing tools used in builds.
Defect tracking: It ensures that every defect has traceability back to its source.
Benefits of Software Configuration Management
SCM provides significant benefits to all projects regardless of size, scope, and complexity. Some of
the most common benefits experienced by project teams applying the SCM disciplines described in
this guide are possible because the SCM system:
Organization
Being that Configuration Management is like the framework for greater information
management programs, it should go without saying that it is critical for greater management
and organization of information as a whole. With a well-ordered system in place, a good
IT worker should be able to see all of the past system implementations of the business, and
can better address future needs and changes to keep the system up to date and running
smoothly.

2002633 Page 22
Software Engineering BTCS 506-18

Reliability
Nothing is worse than an unreliable system that is constantly down and needing repairs
because a company’s configuration management team is lacking in organization and pro-
activeness. If the system is used correctly, it should run like the well-oiled machine that it
is, ensuring that every department in the company can get their jobs done properly.
Increased stability and efficiency of the system will trickle down into every division of a
company, including customer relations, as the ease and speed in which their problems can
be solved and information can be accessed will surely make a positive impact.
Cost Reduction and Risks
Like anything else in business, a lack of maintenance and attention to details can have
greater risks and cost down the line, as opposed to proactive action before a problem arises.
Configuration Management saves money with the constant system maintenance,

record keeping, and checks and balances to prevent repetition and mistakes. The organized
record keeping of the system itself saves time for the IT department and reduces wasted
money for the company with less money being spent on fixing recurring or nonsensical
issues.

SCM Process
The software configuration management process defines a series of tasks that have four primary objectives:
To identify all the items that collectively defines the software configuration.
To manage changes to one or more of these items.
To facilitate the construction of different versions of an application.
To ensure that software quality is maintained as the configuration evolves over time.

2002633 Page 23
Software Engineering BTCS 506-18

Figure 5.1:- SCM process

Risk Management

A risk is any anticipated unfavourable event or circumstance that can occur while project is being
developed
The project manager needs to identify different type of risk in advance so that the project deadlines don’t
get extended
There are three main activities of risk management
Risk identification
The project manager needs to anticipate the risk in project as early as possible so that the impact of
risk can be minimised by using defective risk management plans
Following are the main types of risk that need to be identified
Project risk:- these include
Resource related issues
Schedule problems
Budgetary issues
Staffing problem
Customer related issues
Technical risk := includes
Potential design problems

2002633 Page 24
Software Engineering BTCS 506-18

Implementation and interfacing issues

Incomplete specification.
Changing specification and technical uncertainty
Ambiguous specification
Testing and maintenance problem
Business risk :-
Market trend changes

Developing a product similar to the existing applications

Personal commitments
In order to be able to successfully identify and foresee the different type of risk that might affect a project it
is good idea to have a company disaster list
The company disaster list contains al the possible risk or events that can occur in similar projects
Risk assessment: -
The main objective of risk assessment is to rank the risk in terms of their damage causing potential
The priority of each list can be computed using the equation p=r*s, where p is priority with which the risk
must be handled , r is probability of the risk becoming true and s is severity of damage caused due to the risk
becoming true
If all the identified risk are prioritized than most likely and damaging risk can be handled first and others later
on
Risk containment: -
Risk containment include planning the strategies to handle and face the most likely and damaging risk first
Following are the strategies that can be used in general
Avoid the risk :- eg:- in case of having issues in designing phase with reference to specified
requirements , one can discuss withe customer to change the specifications and avoid the risk
Transfer the risk :-
This includes purchasing and insurance coverage
Getting the risky component developed by Third party
Risk reduction: - leverage factor:
The project manger must consider the cost of handling the risk and the corresponding reduction of
the risk
Risk leverage = ( risk exposure before reduction - risk exposure after reduction) / cost of reduction

Result: The Software configuration management document is prepared.

2002633 Page 25
Software Engineering BTCS 506-18

Practical -6

Aim: Study and usage of any Design phase CASE tool.

CASE Tools: -
CASE stands for Computer Aided Software Engineering. It means, development and maintenance
of software projects with help of various automated software tools. CASE tools are set of software
application programs, which are used to automate the SDLC activities. CASE tools are used by
software project managers, analysts and engineers to develop software system.
Reasons for using case tools:
The primary reasons for using a CASE tool are:
To increase productivity
To help produce better quality software at lower cost
To decrease the development time and cost.
Various tools are incorporated in CASE and are called CASE tools, which are used to support
different stages and milestones in a software development lifecycle.
Architecture Of CASE tools: -

2002633 Page 26
Software Engineering BTCS 506-18

Figure: - 6.1

Layer 1 is the user interface whose function is to help the user to interact with core of
the system. It provides a graphical user interface to users using which interaction with the
system become easy.
Layer 2 depicts tool management system (TMS) which constitutes multiple tools of different
category using which automation of the development process can be done. TMS may include
some tools to draw diagrams or to generate test cases.
Layer 3 represents object management system (OMS) which represents the set of objects generated
by the users. Group of design notations, set of test cases (test suite) are treated as the objects.
Layer 4 represents a repository which stores the objects developed by the user. Layer 4 is nothing
but a database which stores automation files.

Components of CASE Tools: - CASE tools can be broadly divided into the following parts
based on their use at a particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a source of
common, integrated and consistent information. Central repository is a central place of storage
where product specifications, requirement documents, related reports and diagrams, other useful
information regarding management are stored. Central repository also serves as data dictionary.

2002633 Page 27
Software Engineering BTCS 506-18

Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of
SDLC.
Lower Case Tools - Lower CASE tools are used in the implementation, testing and
maintenance stages.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from
Requirement gathering to Testing and documentation.

Figure: - 6.2

Why CASE Tools are developed?

Main purpose of the CASE tools is to decrease the development time and cost and
increase the quality of software.
CASE tools are developed for the following reasons:
Firstly Quick Installation
Time saving by reducing coding and testing time.
Enrich graphical techniques and data flow.
Enhanced analysis and design development.
Create and manipulate documentation

The speed during the system development increased.

2002633 Page 28
Software Engineering BTCS 506-18

Types of CASE tools: - Major categories of CASE tools are:

Diagram tools
Project Management tools
Documentation tools
Web Development tools
Quality Assurance tools
Maintenance tools

Benefits of CASE tools

Project Management and control is improved: CASE tools can aid the project management and
control aspects of a development environment. Some CASE tools allow for integration with
industry-standard project management methods (such as PRINCE). Others incorporate project
management tools such as PERT charts and critical path analysis. By its very nature, a CASE tool
provides the vehicle for managing more effectively the development activities of a project.
System Quality is improved: CASE tools promote standards within a development environment.
The use of graphical tools to specify the requirements of a system can also help remove the
ambiguities that often lead to poorly defined systems. Therefore, if used correctly, a CASE tool can
help improve the quality of the specification, the subsequent design and the eventual working
system.
Consistency checking is automated: Large amounts of information about a business area and its
requirement are gathered during the analysis phase of an information systems development project.
Using a manual system to record and cross reference this information is both time-consuming and
inefficient. One of the advantages of using CASE tool is that all data definitions and other relevant
information can be stored in a central repository that can then be used to cross check the consistency
of the different views being modelled.
Productivity is increased: One of the most obvious benefits of a CASE tool is that it may increase
the productivity of the analysis team. If used properly, the CASE tool will provide a support
environment enabling analysts to share information and resources, manage the project effectively
and produce supporting documentation quickly.
The maintenance effort is better supported: It has been argued that CASE tools help reduce the
maintenance effort required to support the system once it is operational. CASE tools can be used to
provide comprehensive and up-to-date documentation – this is obviously a critical requirement for

2002633 Page 29
Software Engineering BTCS 506-18

any maintenance effort. CASE tools should result in better systems being developed in the first place.
Problems associated with CASE tools
Need for organization - wide commitment: To be used effectively, CASE tools require the
commitment of the organisation. Every member of the development team must adhere to the
standards, rules and procedures laid down by the CASE tool environment.
Unrealistic expectations: CSE tools cannot replace experienced business/systems analysts and
designers. They cannot automatically design a system nor can they ensure that the business
requirements are met. Analysts and designers still need to understand the business environment and
identify the system requirements. CASE tools can only support the analytical skills of the developers,
not replace them.
Long learning curve: CASE is technical software. It will take time for the development team to get
use to flow and use it effectively for development work.
Costs of CASE tools: CASE tools are complicated software packages and are, therefore, expensive
to buy. In addition to the initial costs, there are many ‘soft’ costs that have to be considered. These
‘soft costs’ include integration of the new tool, customising the new tool, initial and on-going
training of staff, hardware costs and consultancy provided by the CASE tool vendor.

Result: The Design phase CASE tool document is prepared.

2002633 Page 30
Software Engineering BTCS 506-18

Practical-7
Aim : To perform unit testing and integration testing.

Unit Testing:- Unit testing, a testing technique using which individual modules are tested to
determine if there are any issues by the developer himself. It is concerned with functional correctness
of the standalone modules. The main aim is to isolate each unit of the system to identify, analyze
and fix the defects.

Unit Testing Life cycle:-

Figure: - 7.1

Advantages of unit testing:

Defects are found at an early stage. Since it is done by the dev team by testing individual pieces of
code before integration, it helps in fixing the issues early on in source code without affecting other
source codes.

2002633 Page 31
Software Engineering BTCS 506-18

It helps maintain the code. Since it is done by individual developers, stress is being put on making
the code less inter dependent, which in turn reduces the chances of impacting other sets of source
code.
It helps in reducing the cost of defect fixes since bugs are found early on in the development cycle.
It helps in simplifying the debugging process. Only latest changes made in the code need to be
debugged if a test case fails while doing unit testing.
Disadvantages:
It’s difficult to write good unit tests and the whole process may take a lot of time

A developer can make a mistake that will affect the whole system.

Not all errors can be detected, since every module it tested separately and later different
integration bugs may appear.
Testing will not catch every error in the program, because it cannot evaluate every execution
path in any but the most trivial programs. This problem is a superset of the halting problem,
which is un decidable.
The same is true for unit testing. Additionally, unit testing by definition only tests the
functionality of the units themselves. Therefore, it will not catch integration errors or broader
system-level errors (such as functions performed across multiple units, or non-functional test
areas such as performance).
Unit testing should be done in conjunction with other software testing activities, as they can
only show the presence or absence of particular errors; they cannot prove a complete absence
of errors.
To guarantee correct behaviour for every execution path and every possible input, and ensure
the absence of errors, other techniques are required, namely the application of formal methods
to proving that a software component has no unexpected behaviour.

Unit Testing Techniques:

Black Box Testing - Using which the user interface, input and output are tested.
White Box Testing - used to test each one of those functions behavior is tested.
Gray Box Testing - Used to execute tests, risks and assessment methods.

Integration Testing:- It tests integration or interfaces between components, interactions to

different parts of the system such as an operating system, file system and hardware or interfaces

2002633 Page 32
Software Engineering BTCS 506-18

between systems.
Also after integrating two different components together we do the integration testing. As displayed
in the image below when two different modules ‘Module A’ and ‘Module B’ are integrated then the
integration testing is done.

Fig 7.2 Figure: - 7.3

Integration testing is done by a specific integration tester or test team.

Integration testing follows two approach known as ‘Top Down’ approach and ‘Bottom Up’
approach as shown in the image below:

Below are the integration testing techniques:

Big Bang integration testing: - In Big Bang integration testing all components or modules
are integrated simultaneously, after which everything is tested as a whole. As per the below image
all the modules from ‘Module 1’ to ‘Module 6’ are integrated simultaneously then the Testing is
carried out.

2002633 Page 33
Software Engineering BTCS 506-18

Fig 7.4

Advantage: Big Bang testing has the advantage that everything is finished before integration
testing starts.

Disadvantage: The major disadvantage is that in general it is time consuming and difficult to
trace the cause of failures because of this late integration.

Top-down integration testing: Testing takes place from top to bottom, following the control
flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems
are substituted by stubs. Below is the diagram of ‘Top down Approach”

2002633 Page 34
Software Engineering BTCS 506-18

Fig 7.5

Advantages of Top-Down approach:

The tested product is very consistent because the integration testing is basically performed in an
environment that almost similar to that of reality
Stubs can be written with lesser time because when compared to the drivers then Stubs are simpler
to author.

Disadvantages of Top-Down approach:

Basic functionality is tested at the end of cycle
Bottom-up integration testing: Testing takes place from the bottom of the control flow
upwards. Components or systems are substituted by drivers. Below is the image of ‘Bottom up
approach’:

Fig 7.6

2002633 Page 35
Software Engineering BTCS 506-18

Advantage of Bottom-Up approach:

In this approach development and testing can be done together so that the product or
application will be efficient and as per the customer specifications.

Disadvantages of Bottom-Up approach:

We can catch the Key interface defects at the end of cycle
It is required to create the test drivers for modules at all levels except the top control

System Testing: - System Testing (ST) is a black box testing technique performed to evaluate
the complete system and the system's compliance against specified requirements. In System testing,
the functionalities of the system are tested from an end-to-end perspective. System Testing is usually
carried out by a team that is independent of the development team in order to measure the quality of
the system unbiased. It includes both functional and Non- Functional testing.

Fig 7.7

Result: The unit testing and integration testing is performed.

.

2002633 Page 36
Software Engineering BTCS 506-18

Practical- 8

Aim: To perform various white box and black box testing techniques.

White Box Testing: -

White Box Testing is the testing of a software solution's internal coding and infrastructure. It
focuses primarily on strengthening security, the flow of inputs and outputs through the
application, and improving design and usability. White box testing is also known as Clear Box
testing, Open Box testing, Structural testing, Transparent Box testing, Code-Based testing, and
Glass Box testing.
It is one of two parts of the "box testing" approach of software testing. Its counterpart, black
box testing, involves testing from an external or end-user type perspective. On the other hand,
White box testing is based on the inner workings of an application and revolves around internal
testing.
The term "white box" was used because of the see-through box concept. The clear box or white
box name symbolizes the ability to see through the software's outer shell (or "box") into its
inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not being able
to see the inner workings of the software so that only the end-user experience can be tested.

What do you verify in White Box Testing

White box testing involves the testing of the software code for the following:
Internal security holes
Broken or poorly structured paths in the coding processes
The flow of specific inputs through the code
Expected output
The functionality of conditional loops
Testing of each statement, object and function on an individual basis

2002633 Page 37
Software Engineering BTCS 506-18

The testing can be done at system, integration and unit levels of software development. One of
the basic goals of white box testing is to verify a working flow for an application. It involves
testing a series of predefined inputs against expected or desired outputs so that when a specific
input does not result in the expected output, you have encountered a bug.

How do you perform White Box Testing

To give you a simplified explanation of white box testing, we have divided it into two basic
Steps. This is what testers do when testing an application using the white box testing technique:

Step 1) Understand the source code

The first thing a tester will often do is learn and understand the source code of the application.
Since white box testing involves the testing of the inner workings of an application, the tester
must be very knowledgeable in the programming languages used in the applications they are
testing. Also, the testing person must be highly aware of secure coding practices. Security is
often one of the primary objectives of testing software. The tester should be able to find security
issues and prevent attacks from hackers and naive users who might inject malicious code into
the application either knowingly or unknowingly.

Step 2) Create test cases and execute

The second basic step to white box testing involves testing the application's source code for
proper flow and structure. One way is by writing more code to test the application's source code.
The tester will develop little tests for each process or series of processes in the application. This
method requires that the tester must have intimate knowledge of the code and is often done by
the developer. Other methods include Manual Testing, trial and error testing and the use of
testing tools as we will explain further on in this article.

White Box Testing Techniques

The 3 main White Box Testing Techniques are:
Statement Coverage
Branch Coverage
Path Coverage

Let’s understand these techniques one by one with a simple example.

Statement coverage:

2002633 Page 38
Software Engineering BTCS 506-18

In a programming language, a statement is nothing but the line of code or instruction for the
computer to understand and act accordingly. A statement becomes an executable statement
when it gets compiled and converted into the object code and performs the action when the
program is in a running mode.
Hence “Statement Coverage”, as the name itself suggests, it is the method of validating whether
each and every line of the code is executed at least once.

Branch Coverage:
“Branch” in a programming language is like the “IF statements”. An IF statement has two
branches: True and False. So in Branch coverage (also called Decision coverage), we validate
whether each branch is executed at least once.
In case of an “IF statement”, there will be two test conditions:
One to validate the true branch and,
Other to validate the false branch.
Hence, in theory, Branch Coverage is a testing method which is when executed ensures that
each and every branch from each decision point is executed.
more powerful than Branch coverage. This technique is useful for testing complex programs.

Types of White Box Testing

White box testing encompasses several testing types used to evaluate the usability of an
application, block of code or specific software package. There are listed below --

Unit Testing: It is often the first type of testing done on an application. Unit testing is
performed on each unit or block of code as it is developed. Unit Testing is essentially done by
the programmer. As a software developer, you develop a few lines of code, a single function or
an object and test it to make sure it works before continuing. Unit testing helps identify majority
of bugs, early in the software development lifecycle. Bugs identified in this stage are cheaper

2002633 Page 39
Software Engineering BTCS 506-18

and easy to fix.

Testing for Memory Leaks: - Memory leaks are the most important causes of slower running
applications. A QA specialist who is experienced at detecting memory leaks is essential in cases
where you have a slow running software application. There are many tools available to assist
developers/testers with memory leak testing, example, Rational Purify for windows application.
Apart from above a few testing types are part of both black box and white box testing. They are
listed as below:

White Box Penetration Testing: In this testing, the tester/developer has full information of the
application's source code, detailed network information, IP addresses involved and all server
information the application runs on. The aim is to attack the code from several angles to expose
security threats

White Box Mutation Testing: Mutation testing is often used to discover the best coding
techniques to use for expanding a software solution.

Integration Testing: - Integration testing is a level of software testing where individual units
are combined and tested as a group. The purpose of this level of testing is to expose faults in
the interaction between integrated units. Test drivers and test stubs are used to assist in
Integration Testing.

Advantages of White Box Testing: -

Code optimization by finding hidden errors.
White box tests cases can be easily automated.
Testing is more thorough as all code paths are usually covered.
Testing can start early in SDLC even if GUI is not available.

Disadvantages of White Box Testing: -

White box testing can be quite complex and expensive. Developers who usually execute white
box test cases detest it. The white box testing by developers is not detailed can lead to
production errors.

White box testing requires professional resources, with a detailed understanding of

programming and implementation.
White-box testing is time-consuming, bigger programming applications take the time to test
fully

2002633 Page 40
Software Engineering BTCS 506-18

Black Box Testing

Black box testing is a software testing techniques in which functionality of the software under
test (SUT) is tested without looking at the internal code structure, implementation details and
knowledge of internal paths of the software. This type of testing is based entirely on the software
requirements and specifications. In Black Box Testing we just focus on inputs and output of
the software system without bothering about internal knowledge of the software program.

Black Box Testing – Steps: -

Here are the generic steps followed to carry out any type of Black Box Testing.
Initially requirements and specifications of the system are examined.
Tester chooses valid inputs (positive test scenario) to check whether SUT processes them
correctly. Also some invalid inputs (negative test scenario) are chosen to verify that the SUT is
able to detect them.
Tester determines expected outputs for all those inputs.
Software tester constructs test cases with the selected inputs.
The test cases are executed.
Software tester compares the actual outputs with the expected outputs.
Defects if any are fixed and re-tested.

Types of Black Box Testing

There are many types of Black Box Testing but following are the prominent ones -
Functional testing - This black box testing type is related to functional requirements of a
system; it is done by software testers.
Non-functional testing - This type of black box testing is not related to testing of a specific
functionality, but non-functional requirements such as performance, scalability, usability.
Regression testing - Regression Testing is done after code fixes, upgrades or any other system

2002633 Page 41
Software Engineering BTCS 506-18

maintenance to check the new code has not affected the existing code.

Black box testing strategy:

Following are the prominent Test Strategy amongst the many used in Black box Testing
Equivalence Class Testing: It is used to minimize the number of possible test cases to an
optimum level while maintaining reasonable test coverage.
Boundary Value Testing: Boundary value testing is focused on the values at boundaries.
This technique determines whether a certain range of values are acceptable by the system or
not. It is very useful in reducing the number of test cases. It is mostly suitable for the systems where
input is within certain ranges.
Decision Table Testing: A decision table puts causes and their effects in a matrix. There is
unique combination in each column.

Advantages of Black Box Testing

Testers can be non-technical.
Used to verify contradictions in the actual system and the specifications.
Test cases can be designed as soon as the functional specifications are complete

Disadvantages of Black Box Testing

The test inputs needs to be from large sample space.
It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow
and difficult
Chances of having unidentified paths during this testing

Result: Various white box and black box testing techniques has been performed.

2002633 Page 42
Software Engineering BTCS 506-18

Practical- 9

Aim: - Testing of a web site or any suitable software problem/product

Introduction:-
Web Testing, or website testing is checking your web application or website for potential
bugs before its made live and is accessible to the general public. Web Testing checks for
functionality, usability, security, compatibility, performance of the web application or
website.
During this stage issues such as that of web application security, the functioning of the site, its
access to handicapped as well as regular users and its ability to handle traffic is checked.

How to test Web Application

In Software Engineering, the following testing types/technique may be performed depending on

your web testing requirements.

1. Functionality Testing of a Website

Functionality testing of a Website is a process that includes several testing parameters like user
interface, APIs, database testing, security testing, client and server testing and basic website
functionalities. Functional testing is very convenient and it allows users to perform both manual
and automated testing. It is performed to test the functionalities of each feature on the website.
Web based Testing Activities includes:

Test all links in your webpages are working correctly and make sure there are no broken links.
Links to be checked will include –

Outgoing links
Internal links
Anchor Links
MailTo Links

Test Forms are working as expected. This will include-

2002633 Page 43
Software Engineering BTCS 506-18

Scripting checks on the form are working as expected. For example- if a user does not fill a
mandatory field in a form an error message is shown.
Check default values are being populated
Once submitted, the data in the forms is submitted to a live database or is linked to a working
email address
Forms are optimally formatted for better readability

Test Cookies are working as expected. Cookies are small files used by websites to primarily
remember active user sessions so you do not need to log in every time you visit a website. Cookie
Testing will include

Testing cookies (sessions) are deleted either when cache is cleared or when they reach their
expiry.
Delete cookies (sessions) and test that login credentials are asked for when you next visit the
site.

Test HTML and CSS to ensure that search engines can crawl your site easily. This will include

Checking for Syntax Errors

Readable Color Schemas
Standard Compliance. Ensure standards such W3C, OASIS, IETF, ISO, ECMA, or WS-I are
followed.

Test business workflow– This will include

Testing your end – to – end workflow/ business scenarios which takes the user through a series
of webpages to complete.
Test negative scenarios as well, such that when a user executes an unexpected step, appropriate
error message or help is shown in your web application.

2. Usability testing

2002633 Page 44
Software Engineering BTCS 506-18

Usability Testing has now become a vital part of any web based project. It can be carried out
by testers like you or a small focus group similar to the target audience of the web
application.

Test the site Navigation:

Menus, buttons or Links to different pages on your site should be easily visible and consistent
on all webpages

Test the Content:

Content should be legible with no spelling or grammatical errors.

Images if present should contain an “alt” text

3. Interface Testing:

Three areas to be tested here are – Application, Web and Database Server

Application: Test requests are sent correctly to the Database and output at the client side is
displayed correctly. Errors if any must be caught by the application and must be only shown to
the administrator and not the end user.
Web Server: Test Web server is handling all application requests without any service denial.
Database Server: Make sure queries sent to the database give expected results.

Test system response when connection between the three layers (Application, Web and
Database) cannot be established and appropriate message is shown to the end user.

Database Testing:

Database is one critical component of your web application and stress must be laid to test it
thoroughly. Testing activities will include-

Test if any errors are shown while executing queries

Data Integrity is maintained while creating, updating or deleting data in database.
Check response time of queries and fine tune them if necessary.
2002633 Page 45
Software Engineering BTCS 506-18

Test data retrieved from your database is shown accurately in your web application

Compatibility testing.

Compatibility tests ensures that your web application displays correctly across different devices.
This would include-

Browser Compatibility Test: Same website in different browsers will display differently. You
need to test if your web application is being displayed correctly across browsers, JavaScript,
AJAX and authentication is working fine. You may also check for Mobile Browser
Compatibility.

The rendering of web elements like buttons, text fields etc. changes with change in Operating
System. Make sure your website works fine for various combination of Operating systems such
as Windows, Linux, Mac and Browsers such as Firefox, Internet Explorer, Safari etc.

Performance Testing:

This will ensure your site works under all loads. Software testing activities will include but not
limited to –

Website application response times at different connection speeds

Load test your web application to determine its behavior under normal and peak loads
Stress test your web site to determine its break point when pushed to beyond normal loads at
peak time.
Test if a crash occurs due to peak load, how does the site recover from such an event
Make sure optimization techniques like gzip compression, browser and server side cache
enabled to reduce load times

7. Security testing:

Security Testing is vital for e-commerce website that store sensitive customer information like
credit cards. Testing Activities will include-

Test unauthorized access to secure pages should not be permitted

Restricted files should not be downloadable without appropriate access
Check sessions are automatically killed after prolonged user inactivity
2002633 Page 46
Software Engineering BTCS 506-18

On use of SSL certificates, website should re-direct to encrypted SSL pages.

8. Crowd Testing:

You will select a large number of people (crowd) to execute tests which otherwise would have
been executed a select group of people in the company. Crowdsourced testing is an interesting
and upcoming concept and helps unravel many a unnoticed defects.

This concludes the tutorial. It includes almost all testing types applicable to your web application.

As a Web-tester its important to note that web testing is quite an arduous process and you are
bound to come across many obstacles. One of the major problems you will face is of
course deadline pressure. Everything is always needed yesterday! The number of times the code
will need changing is also taxing. Make sure you plan your work and know clearly what is
expected of you. Its best define all the tasks involved in your web testing and then create a work
chart for accurate estimates and planning

Result: Testing of a web site has been performed.

2002633 Page 47
Software Engineering BTCS 506-18

Practical- 10

Aim: - To create Collaboration Diagram of Specific Projects

S/W Requirements: Rational Rose S/W Edition 7.0.
Theory:A collaboration diagram shows both structural and behavioral aspects explicitly.
To Draw a Collaboration Diagram
1. Open the previously created class diagram if it is not presently the current diagram.
2. Right-click anywhere on the background of the diagram. The Utilities background menu opens.

Fig. 10.1. Create a collaboration diagram

3. Choose CREATE ASSOCIATED DIAGRAM->AUTOMATIC->COLLABORATION

DIAGRAM. The Collaboration Diagram Name dialog box opens. The default name includes the
class diagram name, the number of the diagram , and the type of diagram. You can edit this name.
4. Choose "Selected" from the Classes drop down menu. Only the classes you selected earlier
will be used in the creation of the collaboration diagram.
5. Click. The dialog box closes and Diagram Window opens. The Diagram Window opens with
the selected classes

The Collaboration Diagram Palette

2002633 Page 48
Software Engineering BTCS 506-18

Icon Notation Definition

Actor Actors represents roles of entities outside of a system

that interact directly with the system.
Actors can be anything - humans, devices, other systems
One physical object can play several roles and so can be
modeled by several actors.

Object An object represents a particular instance of a class.

You name the object, the name of the class
of the object, and if applicable, the name of the
package in which the object element can reside. If
the class of the object is scoped, the scope name
of the class is required, an example of this would
be, Package1_ClassA. You can define object
attributes and assign initial values.

Composite Objects made of sub-objects can be represented

using a composite object. Using the composite
object can reduce the diagram's complexity.
Composite objects are represented like normal
objects except that attributes are replaced by
objects. Composite objects are instances of
composite classes. All properties are the same as
an Object and represents an object composed of
tightly bound parts.

Message In collaboration diagram objects collaborate by

exchanging messages. These messages are

2002633 Page 49
Software Engineering BTCS 506-18

placed parallel to the links that connect the

objects. The arrows point toward the recipient of
the message. The message implementation can
take various forms: a procedure call; the sending
of a signal between active threads; the explicit
raising of events, and so on. Since time is not
represented explicitly in a collaboration diagram
the messages are numbered to indicate the
sending order.

Objects Link In a collaboration diagram objects are connected

` by links. These links are instances of associations
between the classes of the objects being
considered. Messages are placed parallel to the
links that connect the objects.

Link Adornment An adornment is used as a link qualifier to

indicate various kinds of implementations of
the link.
These are predefined types to declare how
the link is used - global variable, local
variable, parameter, etc.

Pattern Member Link Used to show the member classes or objects

participating in a pattern.

Design Pattern Patterns describe small, recurring entities,

reusable on a day to day basis in order to resolve
specific problems. These patterns do not express
the general form of an application.
This symbol is available in the following diagrams:
Use Case, Class, Collaboration, Deployment, and
Component.

Binary Constraint The binary constraint notation is available on all

2002633 Page 50
Software Engineering BTCS 506-18

diagram palettes. A constraint is a semantic

relationship among model elements that specifies
conditions and propositions that must be
maintained as true. Otherwise the system
described by the model is invalid. Certain kinds of
constraints (such as association "or" constraint)
are predefined in UML, others can be user
defined. A constraint represents semantic
information attached to a model element, not just a
view of it.
A binary constraint allows a constraint to be
defined between any symbols on the diagram. The
binary constraint allows the constraint to be
defined on the link rather than in a note symbol. If
there is a need for a single constraint or three or
more way constraint, then a note symbol is used
to explain the constraint and the note symbol is
linked to the constrained symbols using a note
link.

Note Link The note link notation is available on all diagram

palettes. The note pad can be used to record
information for an object or link in a diagram. This
information is not included in generated code but
is for information only. Each note pad can contain
unlimited text, can be numbered, a stereotype
defined, and a noted element entered.

Note Pad The note pad notation is available on all diagram

palettes. The note pad can be used to record
information for an object or link in a diagram. This
information is not included in generated code but
is for information only. Each note pad can contain
unlimited text, and be numbered. You can also
define a stereotype, and enter a noted element.

2002633 Page 51
Software Engineering BTCS 506-18

Result: The Collaboration Diagram is prepared.

2002633 Page 52
Software Engineering BTCS 506-18

Practical- 11

Aim: - To create an Activity Diagram of Specific Projects

S/W Requirements: Rational Rose S/W Edition 7.0.
Theory:
Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system. Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system
This diagram is useful in showing work flow connections and describing behavior that has a lot
of parallel processing. When you use an activity diagram you can choose the order in which to
do things. It states the essential sequencing rules to follow. It is different from a flow chart in that
it shows parallel processes, not just sequential processes.
When you have completed your Activity Diagram portion your model should be similar to the
following example.

Fig. 11.1 Activity Diagram

2002633 Page 53
Software Engineering BTCS 506-18

Activity Diagram Notations

Activity diagrams symbols can be generated by using the following notations:

Initial states: The starting stage before an activity takes place is depicted as the initial state
Final states: The state which the system reaches when a specific process ends is known as a
Final State
State or an activity box:
Decision box: It is a diamond shape box which represents a decision with alternate paths. It
represents the flow of control.

Fig 11.2 Activity Diagram Notation and Symbol

Drawing the Activity Diagram

1. Right-click in the background of the state diagram. The Utilities background menu opens
2. Choose CREATE ASSOCIATED DIAGRAM->MANUAL->ACTIVITY DIAGRAM. The
diagram type dialog box opens. The default name includes the type of diagram (Activity), and the
diagram name
2002633 Page 54
Software Engineering BTCS 506-18

Fig.11.3 Activity Diagram Creation

3. Click. The Diagram type dialog box closes and the Diagram Window opens with an Activity
Diagram labeled.

Result: The Activity Diagram is Created.

2002633 Page 55
Software Engineering BTCS 506-18

Practical- 12

Aim: - To create a State Chart Diagram of Specific Projects

S/W Requirements: Rational Rose S/W Edition 7.0.
Theory: In the class diagram, select the persistent class for which you wish to draw a state
diagram. Right click and choose Sub diagrams, ‘New State chart diagram’. Alternately, a state
chart diagram can be started by right clicking on the Logical View and choosing ‘New’ and State
Chart Diagram. However, this does not attach the diagram to an existing class.

Fig. 12.1 State Chart Diagram

Generating tables from classes

You can only generate tables from PERSISTENT classes.
2. To generate tables, there must be a defined schema.
The schema must be associated with a database in the component view.
In the component view:
Set up a database (Right click on logical view, choose data modeler, new, database).
Open the specification for the database and associate it with whichever implementation route suits

2002633 Page 56
Software Engineering BTCS 506-18

Fig. 11.2 Database Specification

In the logical view:

Classify the classes, using a 3-tier system. (To do this, tick the ‘Three-tier diagram’ box in the
tools - options menu in Rational Rose.)
Move all persistent classes into one package.
For each persistent class:
Open the standard specification
Select the ‘detail’ tab
Turn on the ‘persistent’ radio button.
If you have not already given the attributes data types, do so now.

Fig. 11.3 Class specification

Set up a new schema (Right click on logical view, choose data modeler, new, schema.)
Open the schema specification.
Associate it with the database you have created.

2002633 Page 57
Software Engineering BTCS 506-18

Fig. 11.4 Schema Specification

Transform the objects to data. Right click on the package that holds the classes in
the Logical view.
Choose data modeler
Choose ‘Transform to data model’
Fill in destination schema and target database that you have set up. Execute the
transformation. (To see your tables, expand the schema. If they aren’t there, maybe you
didn’t make them persistent?).
To see your data model, right click on the schema, choose data modeler, new, data model

Fig. 11.5 Transformation to data model

Result:The State Chart Diagram is Created.

2002633 Page 58