0% found this document useful (0 votes)
10 views28 pages

Uml For Gender

The document outlines various diagrams used in UML, including class, object, use case, interaction, statechart, activity, component, and deployment diagrams, each serving distinct purposes in modeling system elements and their relationships. It also details use case specifications, class analysis, interaction diagrams, and the importance of testing in software development, including different testing levels and types. The document emphasizes the need for thorough testing to ensure software meets requirements and functions correctly.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views28 pages

Uml For Gender

The document outlines various diagrams used in UML, including class, object, use case, interaction, statechart, activity, component, and deployment diagrams, each serving distinct purposes in modeling system elements and their relationships. It also details use case specifications, class analysis, interaction diagrams, and the importance of testing in software development, including different testing levels and types. The document emphasizes the need for thorough testing to ensure software meets requirements and functions correctly.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 28

3.

3 Diagrams in the UML

 Diagram is the graphical presentation of a set of elements, most oftenrendered as a connected graph
of vertices (things) and arcs (relationships).
 In theory, a diagram may contain any combination of things and relationships.
 For this reason, the UML includes nine such diagrams:
 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Statechart diagram
 Activity diagram
 Component diagram
 Deployment diagram
Class diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.

Class diagrams that include active classes address the static process view of a system.

Object diagram

 Object diagrams represent static snapshots of instances of the things found in class diagrams
 These diagrams address the static design view or static process view of a system
 An object diagram shows a set of objects and their relationships

Use case diagram

 A use case diagram shows a set of use cases and actors and their relationships
 Use case diagrams address the static use case view of a system.
 These diagrams are especially important in organizing and modeling the behaviors of a system.

Interaction Diagrams

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams
Interaction diagrams address the dynamic view of a system

A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages


A collaboration diagram is an interaction diagram that emphasizes thestructural
Organization of the objects that send and receive messages

Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can
take one and transform it into the other

Statechart diagram

 A statechart diagram shows a state machine, consisting of states, transitions, events, and activities
 Statechart diagrams address the dynamic view of a system

 They are especially important in modeling the behavior of an interface, class, or collaboration and
emphasize the event-ordered behavior of anobject

Activity Diagram

An activity diagram is a special kind of a statechart diagram that shows the flow from activity
to activity within a system
Activity diagrams address the dynamic view of a system
They are especially important in modeling the function of a system and emphasize the flow of
control among objects

Component diagram

o A component diagram shows the organizations and dependencies among a set of components.
o Component diagrams address the static implementation view of a system
o They are related to class diagrams in that a component typically maps to one or more classes,
interfaces, or collaborations

Deployment diagram
 A deployment diagram shows the configuration of run-time processing nodes and the components that
live on them.
 Deployment diagrams address the static deployment view of an architecture
4.USE CASE DIAGRAMS
Use case diagrams are behavioral diagrams that have actors, use cases and relationships among the
use cases. The rectangular box represents the context of the system. All use cases within the
box are implemented by the system.

4.1 USE CASE DIAGRAM


4.2 USE CASE SPECIFICATION TABLE

Use Case ID: T6UC504

Use Case Name: Account Sign in.

End Objective: The Traffic and GHMC


department will be
notified/get complaints
through this page.

Created by: venkatesh On (date): 5/11/2018

User/Actor: User and System

Trigger: User attempts to signing the application using sign in option..

Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe the
events that walk through a successful scenario. The basic flow should not include “and/if scenarios”>

User Actions System Actions

1. The user selects the option doctor appointment, rating or 1. The System checks for already the
questioning. device is logged in or out.
If the system is already logged in, then
2. The user enters the fields according to the requests.. the page is redirected to the option
selected page.
Else the system requests to register or
login
2. The System checks and provide the
availability of option selected page..

Exception Flow <identify system and data error conditions that could occur for each step in the normal flow>

User Actions System Actions

1. The user enters the empty fields or wrong information. The system toast the message about the
error.

*******************************************

Use Case ID: T6UC504


Use Case generation of complaint numbers.
Name:

End This will generate the complaint number as soon as


Objective: the complaint register by user.

Created by: venkatesh On 5/11/2018


(date):

User/Actor: user can register any number of problems and any problem.

Trigger: System

Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe the
events that walk through a successful scenario. The basic flow should not include “and/if scenarios”>

User Actions System Actions

user register problems system generates


complaint number

Exception Flow <identify system and data error conditions that could occur for each step in the normal flow>

User Actions System Actions

User must register to get complaint number. The system will not
generate complaint
number if not generated

******************************************
Use Case HTUC02
ID:

Use Case Complaint Registration.


Name:

End The end user


Objective: will be able
to register a
complaint .

Created by: venkatesh On (date): 5/11/2018

User/Actor: Citizens of Hyderabad.

Trigger: When end user clicks Register,the System registers it.

Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe the
events that walk through a successful scenario. The basic flow should not include “and/if scenarios”>

User Actions System Actions

1.The user clicks the


Registration form. 2.The Registration form will be displayed.

3.User writes the 4.The System registers the complaint.


complaint and press the
Register button.

Exception Flow <identify system and data error conditions that could occur for each step in the normal flow>

User Actions System Actions

1.If the user does not have 1.The system will not allow to register complaint.
her/his own profile i.e
her/his Unique ID.

5. PRELIMINARY DESGIN
5.1 CLASS ANALYSIS
5.1.1 CRC TABLES
CRC ID: T1CRC506

Class Name: officals

Created by: venkatesh On (date): 5/11/2018

RESPONSIBILITIES COLLABORATORS

Department ID : OFFICIAL DEPARTMENT.


Department Name: END USER ACCOUNT.
Complaint ids.s
details about complaint.

Access official department page.


view complaint.
update status.

***********************

CRC ID: T1CRC502

Class Name: COMPLAINT

Created by: venkatesh On (date): 5/11/2018

RESPONSIBILITIES COLLABORATORS

COMPLAINT ID. END USER ACCOUNT.

DETAILS OF THE PERSON WHO COMPLAINTS, DEPARTMENT OFFICIAL


(PROFILE INFORMATION) . PAGE;

COMPLAINT DETAILS.

CRC ID: T1CRC512


CREATES A COMPLAINT AFTER REGISTERED BY THE
Class Name: END USER
END USER.
Created by: Venkatesh On (date):

RESPONSIBILITIES COLLABORATORS

END USER DETAILS END USER ACCOUNT.

END USER CAN CREATE UNIQUE ID(PROFILE).


5.2 CLASS DIAGRAMS

5.3 INTERACTION DIAGRAMS


5.3.1 SEQUENCE DAIGRAM

5.3.2 COLLABARATION DAIGRAM


6. DETALIED DESIGN
6.1 ACTIVITY DIAGRAM

ADMIN ACTIVITY DIAGRAM:-

GOVERNMENT ACTIVITY DIAGRAM:-


USER ACTIVITY DIAGRAM:-
6.2 GUI DESIGN
6.2.1 GUI TABLE
End-user interaction with UI prototype:

The user visits the main page of the app and gets to access various tabs like login ,register
which inturn will be redirected to another tab.

The user also gets to subscribe for the newsletter by giving their email.
The contact no's are given on main page for users convenience.

Exception Handling :
If user types invalid email id, the request is cancelled .
End-user interaction with prototype :

The user visits this page on clicking the "REGISTER" tab on home page. Users can register by
providing the required information. The user can create a password for their profile. After entering
everything they should click on submit to submit their details.In case they need any help,they can
click on the help button.

Exception Handling :

The user must enter data in the required format for fields like "DOB","Mobile No.",etc. In case they
don't, a pop-up message will be shown asking them to do so. The user must also agree to the terms
and conditions before clicking on submit. They can read all the terms and conditions by clicking on
the link provided. If they don't, a message will be shown asking them to do so
After selecting the Login onmain page the user will be directed to this page.

Login is possible only after the user is registered with the site,and the email id and the password
which he provided there will be saved in the database of our site.

Now that the user has already registered with us,in this particular page, he can directly enter the id
and password to log in.

In this particular page, he can directly enter the id and password to log in. he has to enter his email id
in the first box&password in the second on.
If at all the device is frequently used by him he can select the "keep me logged in" option.By doing so
the entry details will be saved in his device
and the next time he doesn't have to enter everything again.
The "Help" button below provides him with answers for his query regarding this particular page.
EXCEPTION HANDLING :
If the user enters an invalid email id and/or password a message will be provided asking the user to
re-check the entered information .
End-user interaction with UI prototype:
End-user interaction with UI prototype:

These UIs appears once the user has successfully logged into their GHMC account. This page allows
them to register their complaints, access feedback forms, access records of their previous complaints
and our work, edit their profiles and logout of their profiles.
Exception Handling :

Problems could arise if the user enters invalid information.


DESCRIPTION:In this,the user gets to lodge a the nature of his/her complaint.

The user is supposed to enter the complaint,the location,ward number,ward name and rate the
severity of the problem on the scale of 1-10 so that the action is taken as soon as possible.

The user can choose help option placed at the bottom of the page if he/she faces difficulties in
entering the information.

The user can choose undo option which is also at the bottom of the page if he/she has entered wrong
information and has to change it.

The user can utilize the back option provided on the left most corner of the page in order to go back
to the previous page.
EXCEPTION HANDLING : If the user enters invalid location,ward number or name a message will
be provided asking the user to re-check the entered information and the complaint will be cancelled.
7.TESTING

7.1 Introduction to testing

The purpose of testing is to detect error. Testing is the system of seeking to observe each possible
fault or weak point in a piece product. It presents a technique to determine the functionality of
accessories, sub-assemblies, assemblies and/or a finished product.

It is the approach of exercising program with the intent of ensuring that the application system
meets its standards and consumer expectations and does now not fail in an unacceptable method.
There are quite a lot of types of test. Each experiment style addresses a precise trying out
requirement.

Testing is one of the principal phases within the application development pastime. In program
development lifestyles cycle (SDLC), the predominant aim of Testing process is the satisfactory; the
progress application is demonstrated against achieving the specified performance and efficiency.

For the duration of the trying out procedure the program is worked with some detailed scan cases and
the output of the test circumstances are analyzed whether the application is working in step with the
expectations or not. The success of the Testing system in settling on the errors in general relies on the
experiment case standards, for trying out any program we have to have an outline of the anticipated
habits of the method and process of settling on whether or not the found habits confirmed to the
expected conduct.

LEVELS OF TESTING

When you consider that the mistakes within the application can be injured at any stage. So, we
have got to carry out the testing process at specific stages for the duration of the development. The
elemental stages of trying out are unit, Integration, method and acceptance trying out.

The unit testing is carried out on coding. Here exclusive modules are proven against the specification
produced during design for modules.

In case of Integration Testing exceptional verified modules are combined into sub systems and
established in case of the procedure Testing the entire application is demonstrated and within the
subsequent level of trying out the method is established with person requirement file prepared for the
duration of SRS.

There are two basic approaches for testing. They are,

Functional Testing:

In functional testing circumstances are decided solely and the groundwork of necessities of the
application or module and the Internals of the software or modules should not regarded for
determination of experiment cases. That is often known as black box testing.

Structural Testing:

In structural Testing scan circumstances are generated on actual code of the application or module to
be demonstrated. This is called white field Testing.

TESTING ACTIVITIES

Different levels of testing are used in the testing process,each level of testing aims to test
different aspects of the system.The basic levels are:

I.Unit Testing:

Unit trying out entails the design of scan circumstances that validate that the internal
application common sense is functioning correctly, and that application inputs produce legitimate
outputs. All decision branches and glide of inner code should be validated. It is the Testing of
individual software items of the applying its carried out after the completion of an character unit
earlier than integration.

It is a kind of structural Testing which depends on advantage of its construction and is


invasive. Unit assessments perform normal checks at element stage and experiment a certain industry
process, utility, and/or procedure configuration. Unit assessments ensure that every certain direction
of a industry system performs properly to the documented requisites and contains certainly outlined
inputs and expected outcome.

II. Integration Testing:

Integration exams are designed to experiment integrated application components to assess if they in
reality run as one software. Testing is occasion driven and is more worried with the elemental
outcome of screens or fields. Integration exams show that even though the accessories have been
individually delight, as proven by means of efficaciously unit testing, the blend of accessories is right
and consistent.

Integration trying out is chiefly aimed at exposing the problems that arise from the combination of
add-ons.

III.System Testing:

In system testing the entire software is tested.The reference document for this process is the
requirement document and the goal is to see whether the software meets its requirements.The system
was tested for various test cases with various inputs.

IV .Acceptance Testing:

User Acceptance Testing out is a primary section of any undertaking and requires big
participation with the aid of the end consumer. It also ensures that the approach meets the functional
specifications.

7.2 TYPES OF TESTING

Black Box Testing

Black Box Testing, a software testing method in which the internal structure/design/implementation of the
item being tested is not known to the tester. These tests can be functional or non-functional, though usually
functional. This method is named so because the software program, in the eyes of the tester, is like a
black box; inside which one cannot see. This method attempts to find errors in the following
categories:

 Incorrect or missing functions


 Interface errors
 Errors in data structures or external database access
 Behavior or performance errors
 Initialization and termination errors
White Box Testing

White Box Testing (also known as Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing
method in which the internal structure/design/implementation of the item being tested is known to the
tester. The tester chooses inputs to exercise paths through the code and determines the appropriate
outputs. Programming know-how and the implementation knowledge is essential. White box testing
is testing beyond the user interface and into the nitty-gritty of a system.

This method is named so because the software program, in the eyes of the tester, is like a
white/transparent box; inside which one clearly sees.

Input INTERNAL Output


WORKING

TEST PLAN

Experiment plan is common file for entire task, which defines the scope, method to be taken and the
individual accountable for extraordinary routine of testing. The inputs for forming scan aircraft are

Challenge plan

Requirement file

Process design
test case specification: although there is one scan plan for whole mission scan cases have to be exact
separately for every test case. Scan case specification gives for each item to be confirmed all scan
instances and outputs expected for those scan cases.

Testing Process

A quantity of routine ought to be carried out for Testing software. Trying out begins with
experiment plan. Experiment plan identifies all testing associated hobbies that needed to be
performed together with the agenda and consultant traces for testing.

The plan also specifies the phases of testing that have got to be completed, with the aid of
deciding upon the exceptional trying out units. For each unit specified within the plan first the scan
instances and studies are produced.

Test strategy and approach

Field testing can be performed manually and sensible assessments will likely be written in
detail.

Test objectives

 All field entries must work properly.


 Pages must be activated from the identified link.
 The entry screen, messages and responses must not be delayed.
Features to be tested

 Verify that the entries are of the correct format.

 No duplicate entries should be allowed.

 All links should take the user to the correct page.

TEST CASES

A TEST CASE is a set of conditions or variables under which a tester will determine whether a system under
test satisfies requirements or works correctly. The process of developing test cases can also help find problems
in the requirements or design of an application.
Types of test cases

There are two types of test cases as mentioned below:

1. Formal test cases: Formal test cases are those test cases which are authored as per the test case format.
It has all the information like preconditions, input data, output data, post conditions, etc. It has a
defined set of inputs which will provide the expected output.
2. Informal test cases: Informal test cases are authored for such requirements where the exact input and
output are not known. In order to test them the formal test cases are not authored but the activities
done and the outcomes are reported once the tests are run.

Test Cases Examples:

 Module: User Login


 File Name: Login.jsp

Test Input ExpOutp ActOutp Desc


Case ut ut

Valid usernam Success Success Login


login e, successfull.
passwor
d,
type
Invali usernam Failed Failed Login
d e, unsuccessful
Login passwor l. Try again.
d,
type

Module: User registration


 Filename: Register.jsp
Test Input ExpOutput ActOutput Desc
Case


Register User Register Register User
new Info. successfull. successfull. register
User ed.

Register new User Info. Failed. Failed. Invalid Data.


User

Module: Uploading a file


 File Name: upload.jsp

Test Case Input ExpOutput ActOutput Desc

Data owner Data owner File uploaded. File uploaded. Redirected


to home
page.

Data Owner Data Owner. Failed. Failed. Not


Uploaded.

 Module: feedback
 File Name: feedback.jsp

Test Case Input ExpOutput ActOutput Desc

User User. Feedback. Feedback. Feedback


is send to
backend.

user User. Failed. Failed. Feedback


again.
 Module: view users
Test Case Input ExpOutput ActOutput Desc

Data owner Data owner. View users list. View users list. Currently
registered
users list.

Data owner Data owner. Failed. Failed. Link is not


provided.

 File Name: viewusers.jsp

CONCULSION AND FUTURE WORK:

 It is an easy to use and handy application.


 As it works on GPS , nearest hospitals can be easily located.
 Neat and understandable GUI by the naïve users.
 Helps the people to complaints on traffic and ghmc problems.
 Slove the problems by government.

REFERENCES
1. Software engineering A practitioner’s Approach , Roger S Pressman McGraw Hill
International edition
2. Software Engineering , Ian Sommerville , Pearson.

You might also like