Sooad Manual

GHARDA FOUNDATION’SGHARDA INSTITUTE OF TECHNOLOGY

Department of Computer EngineeringA/P:-LAVEL, TALUKA: KHED, DIST. RATNAGIRI, STATE: MAHARASTRA, PIN:- 415 708

LABORATORY MANUAL

Department Of Computer Engineering

Structured and Object Oriented Analysis and Design

Class: - TE

Semester: - V

LIST OF EXPERIMENTS



1 Develop Requirement specification document

2 Develop DFD model (level0, level1 DFD and Data dictionary) of selected / allotted project.

3 Develop UML Use case model

4 Develop sequence diagram selected

5 Develop Class diagram

6 Develop prototype of selected / allotted project

7 Draw system architecture diagram selected / allotted project.

8 Mini Project Presentation

Course Code Course/Subject Name CreditsCPC503 Structured and Object Oriented Analysis and Design 5



Outcomes: Learner will be able to…1. Understand and apply techniques to get the system requirements and present it in standard format.2. Apply key modeling concepts to both the traditional structured approach and the object oriented approach.3. Construct the candidate system following design methodology.Module Detailed Contents Hrs.01 Introduction

1.1 System overview, Types of Systems ,1.2 Key Differences Between Structured and Object Oriented Analysis and Design1.3 Role of the System Analyst1.4 Systems Development Life Cycle

06

02 System Analysis2.1 Business process Reengineering and the Zachman Framework, SystemRequirement, Stakeholders, Techniques for information gathering,Validating the requirements.

06

03 Feasibility Analysis3.1 Feasibility Analysis, Tests for feasibility, Cost Benefit Analysis, Feasibility analysis of candidate system.3.2 The system Proposal.

06

04 Modeling System Requirements4.1 Traditional Approach to Requirement: Data Flow Diagrams,Documentation of DFD Components. Information EngineeringModels,4.2 Object Oriented Approach to Requirement: Object OrientedRequirements, The System Activities, Identifying Input and Outputs,Identifying Object Behavior, Integrating Object OrientedModels.4.3 Evaluating Alternatives for requirements, Environment andImplementation

12

05 System Design5.1 Moving To Design5.2 The traditional Approach to design5.3 The Object OrientedApproach to design: Use Case Realization5.4 Designing Database, Designing the User Interface, Designing SystemInterfaces, Controls and security

12

06 Application Architecture6.1 IT Architecture, Application Architecture Strategies, Modeling

06



Application Architecture for Information System.6.2 Deployment using UML diagrams, Component and deployment diagram for various architectures.

Term Work:The distribution of marks for term work shall be as follows:· Laboratory work: ………………………………………….. (10) Marks.· Mini Project presentation :…………………………………..(10) Marks.· Attendance …………………………………………………. (05) MarksTOTAL: ………………………………….....………………... (25) Marks.Oral exam will be based on the above syllabus and Laboratory work.

Text Books:1. System Analysis & Design by Satzinger, Jackson and Burd, Cengage Learning, 20072. System Analysis and Design Methods by Jeffery l. Whitten, Lonnie D Bentley, McGraw Hill, 7th edition.3. System Analysis and Design by Alan Dennis, Barbara H. Wixom, Roberta M. Roth, Wiley India 4th edition

Reference Books:1. Systems Analysis and Design by Kendall & Kendall, PHI Publication, 7th Edition.2. Analysis and Design of Information Systems by James a. Senn, 2nd Edition, McGrawHill.3. Object Oriented Modeling and Design with UML by Michael Blaha, James Rumbaugh, Pearson Education Publication, 2nd Edition.4. The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, Ivar Jacobson, Pearson Education Publication.5. Modern Systems Analysis and Design by Jeffrey A. Hoffer, Joey F. George, Joseph S.Valacich, Prabin K. Panigrahi, Pearson Education Publication, 4th Edition.6. UML Distilled by Martin Fowler, Pearson Edition, 3rd Edition.

Experiment No. 01

Aim: To prepare the SRS (Software Requirement Specification) for allotted project.



Example Project

PASSPORT AUTOMATION SYSTEM

AIM:

To develop the Passport Automation System using rational rose tools, visual basic and MS access.

PROBLEM ANALYSIS AND PROJECT PLAN

This system is intended to simplify the process of applying passport, software has been created by designing through rational rose tool, using visual basic as a front end and Microsoft access as a back end. Initially the applicant login the passport automation system and submits his details. These details are stored in the database and verification process done by the passport administrator, regional administrator and police then the passport is issued to the applicant.

PROBLEM STATEMENT

1. Passport Automation System is used in the effective dispatch of passport to all of the applicants. This system adopts a comprehensive approach to minimize the manual work and schedule resources, time in a cogent manner.

2. The core of the system is to get the online registration form (with details such as name, address etc.,) filled by the applicant whose testament is verified for its genuineness by the Passport Automation System with respect to the already existing information in the database.

3. This forms the first and foremost step in the processing of passport application. After the first round of verification done by the system, the information is in turn forwarded to the regional administrator's (Ministry of External Affairs) office.

4. The application is then processed manually based on the report given by the system, and any forfeiting identified can make the applicant liable to penalty as per the law.

5. The system forwards the necessary details to the police for its separate verification whose report is then presented to the administrator. After all the necessary criteria have been met, the original information is added to the database and the passport is sent to the applicant.

SOFTWARE REQUIREMENT SPECIFICATION



for

PASSPORT AUTOMATION SYSTEMVERSION 1.0

Prepared by

Group Name: <place your group name here>

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



Instructor: <place your instructor’s name here>

Course: Structured and Object Oriented Analysis and Design

Lab Section: Batch No.

Teaching Assistant:

NA

Date: 24/07/2014



Table of Contents1. Introduction………………………………………………………………………………...1

1.1 Purpose.................................................................................................................................2

1.2 Scope....................................................................................................................................3

1.3 Definition, Acronyms and Abbreviations..................................................................................4

1.4 Reference..........................................................................................................................................5

1.5 Technology to be used......................................................................................................................6

1.6 Tools to be used................................................................................................................................7

1.7 Overview...........................................................................................................................................8

2. Overall Description………………………………………………………………………...9

2.1 Productive description......................................................................................................................10

2.2 Software interface.............................................................................................................................11

2.3 Hardware interface............................................................................................................................12

2.4 System function.................................................................................................................................13

2.5 User Characteristic............................................................................................................................14

2.6 Constraints........................................................................................................................................15

2.7 Assumption and Dependences..........................................................................................................16

3. External Interface Requirements………………………………………………………....174. System Features……………………………………………………………………………185. Other Nonfunctional Requirements………………………………………………………196. Other Requirements……………………………………………………………………….20



INTRODUCTION

1.0 INTRODUCTION

Passport Automation System is an interface between the Applicant and the Authority responsible for the

Issue of Passport. It aims at improving the efficiency in the Issue of Passport and reduces the complexities

involved in it to the maximum possible extent.

1.1 PURPOSE

If the entire process of 'Issue of Passport' is done in a manual manner then it would take several months

for the passport to reach the applicant. Considering the fact that the number of applicants for passport is

increasing every year, an Automated System becomes essential to meet the demand. So this system uses

several programming and database techniques to elucidate the work involved in this process. As this is a

matter of National Security, the system has been carefully verified and validated in order to satisfy it.

1.2 SCOPE

The System provides an online interface to the user where they can fill in their personal details. The

authority concerned with the issue of passport can use this system to reduce his workload and process the

application in a speedy manner. Provide a communication platform between the applicant and the

administrator Transfer of data between the Passport Issuing Authority and the Local Police for

verification of applicant's information.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

1. Administrator - Refers to the super user who is the Central Authority who has been vested with the

privilege to manage the entire system. It can be any higher official in the Regional Passport Office of

Ministry of External Affairs.

2. Applicant - One who wishes to obtain the Passport.



3. PAS - Refers to this Passport Automation System.

1.4 REFERENCES IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED • Microsoft Visual Basic 6.0

1.6 TOOLS TO BE USED • Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW

SRS includes two sections overall description and specific requirements - Overall description will

describe major role of the system components and inter-connections. Specific requirements will describe

roles & functions of the actors.

2.0 OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

The PAS acts as an interface between the 'applicant' and the 'administrator'. This system tries to make the

interface as simple as possible and at the same time not risking the security of data stored in. This

minimizes the time duration in which the user receives the passport.

2.2 SOFTWARE INTERFACE

1. Front End Client - The applicant and Administrator online interface is built using Microsoft Visual

Basic 6.0.

2. Back End – MS Access database

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access to the database in

the server.

2.4 SYSTEM FUNCTIONS



1. Secure Registration of information by the Applicants.

2. Message box for Passport Application Status Display by the Administrator.

3. Administrator can generate reports from the information and is the only authorized personnel to add the

eligible application information to the database.

2.5 USER CHARACTERISTICS

1. Applicant - They are the people who desire to obtain the passport and submit the information to the

database.

2. Administrator - He has the certain privileges to add the passport status and to approve the issue of

passport. He may contain a group of persons under him to verify the documents and give suggestion

whether or not to approve the dispatch of passport.

3. Police - He is the person who upon receiving intimation from the PAS, perform a personal verification

of the applicant and see if he has any criminal case against him before or at present. He has been vetoed

with the power to decline an application by suggesting it to the Administrator if he finds any discrepancy

with the applicant. He communicates via this PAS.

2.6 CONSTRAINTS

1. The applicants require a computer to submit their information.

2. Although the security is given high importance, there is always a chance of intrusion in the web world

which requires constant monitoring.

3. The user has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES

1. The Applicants and Administrator must have basic knowledge of computers and English Language.

2. The applicants may be required to scan the documents and send.



Experiment No. 02

Aim: To design the Usecase Diagram for allotted project.

Description: Use case diagrams are usually referred to as behavior diagrams used to describe a

set of actions (use cases) that some system or systems (subject) should or can perform in

collaboration with one or more external users of the system (actors). Each use case should

provide some observable and valuable result to the actors or other stakeholders of the system.



Use case diagrams are used to gather the requirements of a system including internal and

external influences. These requirements are mostly design requirements. So when a system is

analyzed to gather its functionalities use cases are prepared and actors are identified.

Now when the initial task is complete use case diagrams are modeled to present the outside view.

So in brief, the purposes of use case diagrams can be as follows:

Used to gather requirements of a system.

Used to get an outside view of a system.

Identify external and internal factors influencing the system.

Show the interacting among the requirements are actors.

How to draw Use Case Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the

requirements of a system are analyzed the functionalities are captured in use cases.

So we can say that uses cases are nothing but the system functionalities written in an organized

manner. Now the second things which are relevant to the use cases are the actors. Actors can be

defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications.

So in a brief when we are planning to draw a use case diagram we should have the following

items identified.

Functionalities to be represented as an use case

Actors

Relationships among the use cases and actors.



Use case diagrams are drawn to capture the functional requirements of a system. So after

identifying the above items we have to follow the following guidelines to draw an efficient use

case diagram.

The name of a use case is very important. So the name should be chosen in such a way so

that it can identify the functionalities performed.

Give a suitable name for actors.

Show relationships and dependencies clearly in the diagram.

Do not try to include all types of relationships. Because the main purpose of the diagram

is to identify requirements.

Use note when ever required to clarify some important points.



The following is a sample use case diagram representing Passport Automation System.

DOCUMENTATION OF USECASE DIAGRAM

a. The actors in use case diagram are Applicant, regional administrator, database, passport Administrator,

Police.

b. The use cases are Login, givedetails, logout, collectdetails, verification, issue.

c. The actors use the use case are denoted by the arrow

d. The login use case checks the username and password for applicant, regional administrator, passport

administrator and police.



e. The submit details use case is used by the applicant for submitting his details

f. The check status use case is used by the applicant for checking the status of the application process.

g. The get details, verify and store verification use case is used by passport administrator, regional

administrator, and police.

h. The details use case is used for getting the details form the database for verification.

i. The verify use case is used for verifying the details by comparing the data in the database.

j. The store verification use case is to update the data in the database

k. And finally the issue passport use case is used by the passport administrator for issuing passport who’s

application verified successfully by all the actor.

Experiment No. 03

Aim: To design the Class Diagram for allotted project.

Description: The class diagram is a static diagram. It represents the static view of an application.

Class diagram is not only used for visualizing, describing and documenting different aspects of a

system but also for constructing executable code of the software application.

The class diagram describes the attributes and operations of a class and also the constraints imposed on

the system. The class diagrams are widely used in the modelling of object oriented systems because they

are the only UML diagrams which can be mapped directly with object oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It

is also known as a structural diagram.



A class is a classifier which describes a set of objects that share the same

features

constraints

semantics (meaning).

A class is shown as a solid-outline rectangle containing the class name, and optionally with

compartments separated by horizontal lines containing features or other members of the classifier.

As class is the most widely used classifier, there is no need to add the "class" keyword in

guillemets above the class name. Class name should be centered and in bold face, with the first letter of

class name capitalized (if the character set supports upper case).

Features of a class are attributes and operations.

When class is shown with three compartments, the middle compartment holds a list of

attributes and the bottom compartment holds a list of operations. Attributes and operations

should be left justified in plain face, with the first letter of the names in lower case.

Characteristics represented by feature may be of the classifier’s instances considered individually

(not static) or of the classifier itself (static). The same feature cannot be static in one context and non

static in another.

With regard to static features, two alternative semantics are recognized. Static feature may have:

different values for different featuring classifiers, or

the same value for all featuring classifiers.

In accordance with this semantics, inheritance of values for static features is permitted but not required

by UML 2.

Static features are underlined - but only the names. An ellipsis (...) as the final element of a list of

features indicates that additional features exist but are not shown in that list.

Attributes of a class are represented by instances of property that are owned by the class. Some of these

attributes may represent the navigable ends of binary associations.

Objects of a class must contain values for each attribute that is a member of that class, in accordance with

the characteristics of the attribute, for example its type and multiplicity.



The following is a sample use case diagram representing Passport Automation System.



DOCUMENTATION OF CLASS DIAGRAM

APPLICANT-The applicant has attribute such as name, email-id and so on to describe details of

Applicant and Operations are login, SubmitDetails and CheckStatus. The applicant login and fill the

details that are required for applying the passport .After applying the person can view the status of

the passport verification process

THE DATABASE-The database has attributed such as name and operation is store. The purpose is

to store the data.

REGIONAL ADMINISTRATOR- The regional administrator has attribute such as name and

operation are get details, verify details and send. The regional administrator get the details form

database and verify with their database

PASSPORT ADMINISTRATOR-The passport administrator has attributed such as name and

operation are get details, verify details and issue. The passport administrator get the details form

database and verify with their database, update the verification and issue the passport

THE POLICE-The police has attribute such as name and operation are login, get details, verify

details and send. The police get the details form database and verify with their database , update the

verification in the database

Sooad Manual

Documents

Transcript of Sooad Manual