PROJECT FOR

AKTU SYLLABUS

SRS CONTENT AND

EXPERIMENT FOR

SMART HEALTH CARE

SYSTEM FOR KIDS

 INDEX OF THE CONTENTS
 Introduction to the lab.

 (Details of H/w & S/w to be used in the lab)

 List of Programs (as per the syllabus of AKTU.)

 Format of the lab record to be prepared by the students.

 Steps to be followed ( for each practical )

 Sample Diagram/s

 List/Details of the additional things. ( extra programs, projects etc. )

 Marking scheme

INTRODUCTION TO THE LAB

 Requirement of the lab

 Hardware Requirements:

Dual Core processor (2.0 GHz), 4 GB RAM, Standard keyboard and mouse, colored
monitor.

 Software Requirements:

Rational Rose, Windows 7, Jupyter Notebook.

This lab deals with the analysis and design of a software problem .the tool

used in a lab is Rational Rose Enterprise Edition .This tool is used for a object

oriented design of a problem. We draw a uml diagram in a rational rose which

deals with the objects and classes in a system .The Unified Modeling

Language or UML is a mostly graphical modeling language that is used to

express designs. It is a standardized language in which to specify the

artifacts and components of a software system. It is important to understand

that the UML describes a notation and not a process. It does not put forth a

single method or process of design, but rather is a standardized tool that can

be used in a design process. The Unified Modeling Language (UML) is a

standard language for specifying, visualizing, constructing, and documenting

the artifacts of software systems, as well as for business modeling and other

non-software systems. The UML represents a collection of best engineering

practices that have proven successful in the modeling of large and complex

systems.1 The UML is a very important part of developing object oriented

software and the software development process. The UML uses mostly

graphical notations to express the design of software projects. Using the UML

helps project teams communicate, explore potential designs, and validate the

architectural design of the software

Goals of UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual modeling language so

they can develop and

exchange meaningful models.

2. Provide extensibility and specialization mechanisms to extend the core

concepts.

3. Be independent of particular programming languages and development

processes.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of the tools market.

6. Support higher-level development concepts such as collaborations,

frameworks, patterns and

components.

7. Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry

looks for techniques to automate the production of software and to improve

quality and reduce cost and time-to-market. These techniques include

component technology, visual programming, patterns and frameworks.

Businesses also seek techniques to manage the complexity of systems as

they increase in scope and scale. In particular, they recognize the need to

solve recurring architectural problems, such as physical distribution,

concurrency, replication, security, load balancing and fault tolerance.

Where Can the ML Be Used?

The UML is intended primarily for software-intensive systems. It has been
used effectively for such domains as
1. Enterprise information systems
2. Banking and financial services
3. Telecommunications
4. Transportation
5. Defense/aerospace
6. Retail
7. Medical electronics
8. Scientific
9. Distributed Web-based services
 The UML is not limited to modeling software. In fact, it is expressive enough

to model non software systems, such as work-flow in the legal system, the

structure and behavior of a patient health-care system, and the design of

hardware.

Introduction of all Diagrams to be drawn Using Rational Rose

A diagram is the graphical presentation of a set of elements, most often

rendered as a connected graph of vertices (things) and arcs (relationships). A

diagram is a projection into a system. The UML includes nine such diagrams.

1. Class diagram A structural diagram that shows a set of classes,

interfaces, collaborations, and their relationships
2. Object diagram A structural diagram that shows a set of objects and their
relationships
3. Use case diagram A behavioral diagram that shows a set of use cases and
actors and their relationships
4. Sequence A behavioral diagram that shows an interaction,
diagram emphasizing the time ordering of messages
5. Collaboration A behavioral diagram that shows an interaction,
diagram emphasizing the structural organization of the objects
that send and receive messages
6. State chart A behavioral diagram that shows a state machine,
diagram emphasizing the event-ordered behavior of an object
7. Activity diagram A behavioral diagram that shows a state machine,
emphasizing the flow from activity to activity
8. Component A structural diagram that shows a set of components and
diagram their relationships
9. Deployment A structural diagram that shows a set of nodes and their
diagram relationships
1. Write the complete problem statement

2. Write the software requirement specification document

3. Draw the entity relationship diagram

4. Draw the data flow diagrams at level 0 and level 1

5. Draw use case diagram

6. Draw activity diagram of all use cases.

7. Draw state chart diagram of all use cases

8. Draw sequence diagram of all use cases

9. Draw collaboration diagram of all use cases

10. Assign objects in sequence diagram to classes and make

class diagram .
S. No. Na me of the P ro gr am D ate Si gnature Re ma rks
& Date
 Experiment:- 1

AIM:-
Smart health management for kids..

REQUIREMENTS:

Hardware Interfaces

Dual Core Processor (2.0 GHz), 2 GB RAM

Screen resolution of at least 800 x 600 required for proper and

complete viewing of screens. Higher resolution would not be a

problem.

Software Interfaces

Windows 7

Word Pad or Microsoft Word or LibreOffice

PROBLEM STATEMENT OF “SMART HEALTH MANAGEMENT FOR KIDS”

In 2015 “PUBLIC HEALTH FOUNDATION OF INDIA” published a report

“INDIA HEALTH REPORT: NUTRITION 2015” according to which 43% of Indian
Kids are suffering from Malnutrition, Pneumonia, Diarrhoea, Anemia and
Psychological diseases due to which the overall growth of kids will be
affected.
 So, “ THE SMART HEALTH MANAGEMENT FOR KIDS” are developed to
overcome this situation and predict to the growth and development of kids.
In current scenario,the record of vaccination of kids are mention in
register, so the proper data will not be stored and it is not easy to access the
data from register. Register contain the normal information such as Name,
Dob, and vaccination Record.
So, from this record the advance health report can not be access due to
which the prediction of health of kids is no poissible.
Some issue in present health system are following :-
· Missing of record.
· Proper vaccination not be done on time.
· Lack of nutritions,and care.
· Lot of kids suffering from underweight, overweight and mentally disorder.
· Prediction is not possible.
· Access of data is not easier.
· A lots of diseas are not track.
· Needs of calories, protine, vitamins, and other essential nutrient depends
upon the weight of the kid but due to not getting the proper nutrition the
growth of the kids not achive as required.
· The ratio of hight and weight not be maintain.

To overcome all the situation which mention above “THE SMART

HEALTH MANAGEMENT FOR KIDS” will be very effective and reduce the
problem which mention above.
 Experiment :- 2
Aim: Understanding an SRS.

Requirements:

Hardware Requirements:

PC with 2.0 gigahertz

2 GB Ram

500 gigabytes (GB) of available hard disk space

Keyboard and Mouse (compatible pointing device).

Software Requirements:

Rational Rose, Windows 7

Theory:

An SRS is basically an organization's understanding (in writing) of a

customer or potential client's system requirements and dependencies at a

particular point in time (usually) prior to any actual design or development

work. It's a two-way insurance policy that assures that both the client and the

organization understand the other's requirements from that perspective at a

given point in time.

The SRS document itself states in precise and explicit language those

functions and capabilities a software system (i.e., a software application, an

e commerce Web site, and so on) must provide, as well as states any

required constraints by which the system must abide. The SRS also functions

as a blueprint for completing a project with as little cost growth as possible.

The SRS is often referred to as the "parent" document because all

subsequent project management documents, such as design specifications,

statements of work, software architecture specifications, testing and

validation plans, and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional

requirements only; it doesn't offer design suggestions, possible solutions to

technology or business issues, or any other information other than what the

development team understands the customer's system requirements to be.

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

 It provides feedback to the customer. An SRS is the customer's

assurance that the development organization understands the issues or

problems to be solved and the software behavior necessary to address

those problems. Therefore, the SRS should be written in natural

language (versus a formal language, explained later in this article), in an

unambiguous manner that may also include charts, tables, data flow

diagrams, decision tables, and so on.

 It decomposes the problem into component parts. The simple act of

writing down software requirements in a well-designed format organizes

information, places borders around the problem, solidifies ideas, and

 helps break down the problem into its component parts in an orderly

fashion.

 It serves as an input to the design specification. As mentioned

previously, the SRS serves as the parent document to subsequent

documents, such as the software design specification and statement of

work. Therefore, the SRS must contain sufficient detail in the functional

system requirements so that a design solution can be devised

 It serves as a product validation check. The SRS also serves as the

parent document for testing and validation strategies that will be applied

to the requirements for verification.

SRS are typically developed during the first stages of "Requirements

Development," which is the initial product development phase in which

information is gathered about what requirements are needed--and not.

This information-gathering stage can include on-site visits,

questionnaires, surveys, interviews, and perhaps a return-on-investment

(ROI) analysis or needs analysis of the customer or client's current

business environment. The actual specification, then, is written after the

requirements have been gathered and analyzed.

SRS should address the following :-

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

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

b) External interfaces. How does the software interact with people,

the system’s hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time,

recovery time of various software functions, etc.?

 d) Attributes. What are the portability, correctness, maintainability,

security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any

required standards in effect, implementation language, policies for

database integrity, resource limits, operating environment(s) etc.

Characteristics of a good SRS

An SRS should be:-

a) Correct

b) Unambiguous

c) Complete

d) Consistent

e) Ranked for importance and/or stability

f) Verifiable

g) Modifiable

h) Traceable

Correct - This is like motherhood and apple pie. Of course you want the

specification to be correct. No one writes a specification that they

know is incorrect. We like to say - "Correct and Ever Correcting." The

discipline is keeping the specification up to date when you find things

that are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every

requirement stated therein has only one interpretation. Again, easier

 said than done. Spending time on this area prior to releasing the SRS

can be a waste of time. But as you find ambiguities - fix them.

Complete - A simple judge of this is that is should be all that is needed

by the software designers to create the software.

Consistent - The SRS should be consistent within itself and consistent

to its reference documents. If you call an input "Start and Stop" in one

place, don't call it "Start/Stop" in another.

Ranked for Importance - Very often a new system has requirements that are

really marketing wish lists. Some may not be achievable. It is useful provide

this information in the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast

response." Another of my favorites is - "The system should never crash."

Instead, provide a quantitative requirement like: "Every key stroke should

provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not be

wrong - but tends to make the document not maintainable.

Traceable - Often, this is not important in a non-politicized environment.

However, in most organizations, it is sometimes useful to connect the

requirements in the SRS to a higher level document. Why do we need this

requirement?
A sample of basic SRS Outline

1. Introduction

1.1. Purpose

1.2. Scope

1.3. Definition, Acronyms, and Abbreviation

1.4. References

1.5. Overview

2. The Overall Description

2.1. Product perspective

2.1.1. System Interfaces 2.1.2.User Interfaces

2.1.3. Hardware Interfaces

2.1.4. Software Interfaces

2.1.5. Communication Interfaces

2.1.6. Memory Constraints

2.1.7. Operations

2.1.8. Site Adaptation Requirements

2.2. Product Functions

2.3. User Characteristics

2.4. Constraints

2.5. Assumptions and Dependencies

 2.6. Apportioning and Requirements

3. Specific Requirements

3.1. External Interfaces Requirements

3.1.1. User Interfaces

3.1.2. Hardware Interfaces

3.1.3. Software Interfaces

3.1.4. Communications Interfaces

3.2. System Features

3.2.1. System Feature 1

3.2.1.1. Introduction of feature

3.2.1.2. Stimulus Sequence
3.2.1.3. Associated Functional Requirements
3.3. Performance Requirements

3.4. Design Constraints

3.5. Software System Attributes

3.6. Other Requirements

 SOFTWARE REQUIREMENTS
SPECIFICATION

SMART HEALTH MANAGEMENT FOR KIDS

1. Introduction-
“SMART HEALTH MANAGEMENT SYSTEM FOR KIDS ” are the health
management system mainly focus on the overall care of kid from birth upto 5
years.It include the tracking of vaccination of the kids and their diets.
The careing of kids is very difficult specially upto 5 year and kids also grow
very fast during this period.The overall developement of the kids depend on
care which will be provided during this time period.
1.1 Purpose-
The purpose of this SRS is to describe the requirements involved in
developing “SMART HEALTH MANAGEMENT SYSTEM FOR KIDS” (SHMSK).
The intended audience is any parent who wants track the growth of his kids.
And the doctors or goverement body who want to manage the record of the
kids.
1.2 Scope-
The product is titled “SMART HEALTH MANAGEMENT SYSTEM FOR KIDS”
(SHMSK). This product will perform the following task:-
 It allow the doctor/nurse to create the new entry for kids.
 It allow the doctor/nurse to mentain the database of the kids.
 It allow the doctor/nurse to update the information about the kids.
 It allow parent to fatch the information of the kids.
 It allow the goverment body to fatch the informaion regarding kids.

1.3 Definition, Acronyms, and Abbreviation-

SHMSK:-“SMART HEALTH MANAGEMENT SYSTEM FOR KIDS”
1.4 References-
IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description
1.5 Overview-
The SRS contains an analysis of the requirements necessary to help easy
design. The overall description provides interface requirements for the health
management, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user
characteristics and other constraints. Succeeding pages illustrate the
characteristics of typical naïve users accessing the system along with legal
and functional constraints enforced that affect health management in any
fashion.
2. The Overall Description-
2.1 Product perspective-
2.1.1 System Interfaces-
The system must interface with the standard output device, keyboard
and mouse to interact with this software.
2.1.2 User Interfaces-
The system must interface with the standard output device, keyboard
and mouse to interact with this software.
2.1.3 Hardware Interfaces-
Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system (such
as any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and backup systems to support the primary goal of reliability.
2.1.4 Software Interfaces-
Back End: Jupyter notebook.
Front End: Pycharm.
2.1.5 Communication Interfaces-
The machine needs to communicate with the central database for each
session for various functions such as login verification, database access etc.
so the following are the various communication interface requirements that
are needed to be fulfilled in order to run the software successfully:-
The system will employ dial-up POS with the central server for low cost
communication. The communication protocol used shall be TCP/IP.
Protocol .used for data transfer shall be File Transfer Protocol.(FTP)
2.1.6 Memory Constraints-
No specific constraints of memory.
2.1.7 Operations-
 The doctor/nurse can create an entering and they acn also performed
the some operation such as Login, Update. The Parent can access the detail
of his kids. They get the information regarding the kids health-care.
2.1.8 Site Adaptation Requirement-
No specific requirement of a site.
2.2 Product Functions-
During the Creation of new Id the following data should be provided to the
doctor/nurse by the parent.
1.Creating a new ID:-
 Kid’s Name
 Kid’s Parent Name
 Kid’s Date Of Birth
 Kid’s weight
 Kid’s hight
 Kid’s address
2.Operating with created account:-
 Parent can access the information.
 Doctor/nurse can edit the information
 Goverment body can access the record.

2.3 User Characteristics-

The intended users of this software need not have specific knowledge as to
what is the internal operation of the system. Thus the end user is at a high
level of abstraction that allows easier, faster operation and reduces the
knowledge requirement of end user. The Product is absolutely user friendly,
so the intended users can be the naïve users. The product does not expect
the user to possess any technical background. Any person who knows to use
the mouse and the keyboard can successfully use this product.
2.4 Constraints-
At the time of creating the new account, each user gives a Id number and is
provided with a password that must be used for furthe login. Hence the user
is required to remember or store these numbers carefully. At the time of
creating the new Id date of Birth of kids must be less then 5 Years.
2.5 Assumptions and Dependencies-
The requirements stated in the SRS could be affected by the following
factors:-
One major dependency that the update of information regarding kids will be
on fixed interval of the so that the software will work properly . A delay in
doing the same will result to tremendous loss for health of the kids. So this
should be changed as and when required by the developer.
Another constraint relating to the operating environment is that we are
specific to Oracle Database
2.6 Apportioning of Requirements-
Our development team is working on a health prediction so that the disease
which may affected the health of the kids can be treated on first stage We will
also working for prediction a diet accourding to height and weight ratio of the
kids. All of these facility will be available at our next update.
3. Specific Requirements-
3.1 External Interfaces-
3.1.1. User Interfaces-
Open Id Screen:-
Various fields available on this screen will be:-
-Enter Name
-Enter Id
-Enter Mob-No
-Enter address
Login Screen:-
Fields available on this screen are:-
-Login ID
-Password
Updation Info Screen:-
Fields available on this screen are:-
-Update vaccination
-Update hight
-update weight
-View Info
Fields available on this screen are:-
-Change Password
3.1.2. Hardware Interfaces-
None
3.1.3 Software Interfaces-
-Any Windows based operating system.
-MySql Server Database
-Python, Html, Css
3.1.4 Communications Interfaces-
None
 3.2 System Features-
3.2.1 System Feature 1-
3.2.1.1 Introduction of feature-
Validity check: JavaScript provides validity checks for various fields
in the forms.
Sequencing Information: All the information regarding Id details, Kids
details, Vaccination Info etc should be handled.
Error handling: If any of the validations or sequencing flows does not hold
true then. Appropriate error messages will be prompted to the user for doing
the needful.
3.2.1.2 Response Sequence-
As user open his browser, browser have already fixed address. The dns
server will map the domain to ip Address of the host server and a TCP
connection is setup between user browser and the server. Then using HTTP
protocol the server will send the homepage of health management system to
the user browser and if Everything goes well, user see the home page.
3.2.1.3 Associated Functional Requirement-
This section gives a functional requirement that applicable to the Online
Health Management System for Kids. There three sub modules in this phase.
1. Parent module
2. Administrative module
3. Account Setting module
3.3 Performance Requirements –
No specific Static and dynamic Numerical requirements are available.
3.4 Design Constraints-
None.
3.5 Software System Attributes-
3.5.1 Reliability-
The system should work reliably, with automatic backup and recovery
features. In case of unexpected termination of a session, the unsaved data
should be recovered without loss and displayed to the respective users for
saving into the system or continuing with the work.
3.5.2 Availability-
The entire system should be available round the year, except for a
periodic maintenance. The maintenance period should be pre scheduled and
short. The users should be reminded of the unavailability period, well in
advance.
3.5.3 Security-
The system, at any time, should be accessed only by the authenticated users.
The system is required to end the session automatically, when an open
session is not used for a specific period of time.
3.5.4 Maintainability-
The document should be easy for the users who execute the system day
to day, for the developers who wish to edit or develop further, and for the
personnel who is in charge of the maintenance.
The system should inform the main center automatically as soon as it detects
any error. The kind of fault and the problem being encountered should also be
mentioned by the system automatically.
3.5.5 Portability-
The system should support new versions of the related browsers. The
administrative and server technologies should be standard and supported by
most platforms.
3.6 Other Requirements-
None

Experiment :- 3

AIM :-
To draw a sample ENTITY RELATIONSHIP DIAGRAM for Automated Banking
System.
Hardware Requirements:-
Dual Core processor (2.0 GHz), 2 GB RAM, Standard keyboard And mouse,
colored monitor.
Software Requirements:-
Rational Rose, Windows 7,
THEORY:-
Entity Relationship Diagrams are a major data modeling tool and will help
organize the data in your project into entities and define the relationships
between the entities. This process has proved to enable the analyst to
produce a good database structure so that the data can be stored and
retrieved in a most efficient manner.
Entity:-
A data entity is anything real or abstract about which we want to store data.
Entity types fall into five classes: roles, events, locations, tangible things or
concepts. E.g. Parent, Doctor, Nurse, Vaccination. Specific examples of an
entity are called instances.
Relationship:-
A data relationship is a natural association that exists between one or more
entities. E.g. Kids and Doctor/Nurse. Cardinality defines the number of
occurrences of one entity for a single occurrence of the related entity.

Attribute:-
A data attribute is a characteristic common to all or most instances of a particular
entity. Synonyms include Kids, data element, field. E.g. Name, address, Id are all
attributes of the entity Kids. An attribute or combination of attributes that uniquely
identifies one and only one instance of an entity is called a primary key or
identifier. E.g. Id is a primary key for Kids.

AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY: (One way of

doing it)

1. Identify Entities
2. Find Relationships
3. Draw Rough ERD
4. Fill in Cardinality
5. Define Primary
Keys
6. Draw Key-Based
ERD
Identify the roles, events, locations, tangible things or concepts
about which the end-users want to store data.
Find the natural associations between pairs of entities using a
relationship matrix.
Put entities in rectangles and relationships on line segments
connecting the entities.
Determine the number of occurrences of one entity for a single
occurrence of the related entity.
Identify the data attribute(s) that uniquely identify one and
only one occurrence of each entity.
Eliminate Many-to-Many relationships and include primary
and foreign keys in each entity.
7. Identify Attributes Name the information details (fields) which are essential to the
system under development.
8. Map Attributes For each attribute, match it with exactly one entity that it
describes.

Experiment:-4

AIM:-
To prepare DATA FLOW DIAGRAM for any project.
REQUIREMENTS:-
Hardware Interfaces:-
Dual Core Processor ( CPU 2.0 GHz), 2 GB RAM
Screen resolution of at least 800 x 600 required for proper and complete
viewing of screens. Higher resolution would not be a problem.
Software Interfaces:-
Windows 7
Word-pad or Microsoft Word
THEORY:
Data flow diagrams illustrate how data is processed by a system in terms of
inputs and outputs.

Experiment :-5

Aim :-
Draw The Use Case Diagram using Rational Rose.
Hardware Requirements:-
Dual Core processor (2.0 GHz), 2 GB RAM,
Standard keyboard and mouse, Colored monitor.
Software Requirements:-
Rational Rose, Windows 7,
Theory:-
According to the UML specification a use case diagram is “a diagram that
shows the relationships among actors and use cases within a system.” Use
case diagrams are often used to:
 Provide an overview of all or part of the usage requirements for a
system or organization in the form of an essential model or a
business model.
 Communicate the scope of a development a project Model.
 your analysis of your usage requirements in the form of a system use
case model.
Use case models should be developed from the point of view of your project
stakeholders and not from the (often technical) point of view of developers.
There are guidelines for:
USE CASES:-
A use case describes a sequence of actions that provide a measurable value
to an actor. A use case is drawn as a horizontal ellipse on a UML use case
diagram.
1. Use Case Names Begin With a Strong Verb

2. Name Use Cases Using Domain Terminology

3. Place Your Primary Use Cases In The Top-Left Corner Of The Diagram

4. Imply Timing Considerations By Stacking Use Cases.

ACTOR:-
An actor is a person, organization, or external system that plays a role in one
or more interactions with your system (actors are typically drawn as stick
figures on UML Use Case diagrams).
5. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

6. Draw Actors To The Outside Of A Use Case Diagram

7. Name Actors With Singular, Business-Relevant Nouns

8. Associate Each Actor With One Or More Use Cases

9. Actors Model Roles, Not Positions

10. Use <<system>> to Indicate System Actors

11. Actors Don’t Interact With One Another

12. Introduce an Actor Called “Time” to Initiate Scheduled Events

RELATIONSHIPS:-
There are several types of relationships that may appear on a use case
diagram:-
 An association between an actor and a use case
 An association between two use cases
 A generalization between two actors
 A generalization between two use cases
Associations are depicted as lines connecting two modeling elements with an
optional open-headed arrowhead on one end of the line indicating the
direction of the initial invocation of the relationship. Generalizations are
depicted as a close-headed arrow with the arrow pointing towards the more
general modeling element.
SYSTEM BOUNDARY BOXES:-
The rectangle around the use cases is called the system boundary box and
as the name suggests it indicates the scope of your system – the use cases
inside the rectangle represent the functionality that you intend to implement.
1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

 Experiment:-6

AIM:-
To draw a sample activity diagram for automated banking system.
Hardware Requirements:
Dual Core processor (2.0 GHz), 2 Gb RAM, Standard keyboard and
mouse, colored monitor.
Software Requirements:
Rational Rose, Windows 7
THEORY:-
UML 2 activity diagrams are typically used for business process modeling,
for modeling the logic captured by a single use case or usage scenario, or
for modeling the detailed logic of a business rule. Although UML activity
diagrams could potentially model the internal logic of a complex operation it
would be far better to simply rewrite the operation so that it is simple
enough that you don’t require an activity diagram. In many ways UML
activity diagrams are the object-oriented equivalent of flow charts and
dataflow diagrams (DFDs) from structured development.

Let’s start by describing the basic notation :

 Initial node. The filled in circle is the starting point of the diagram. An
initial node isn’t required although it does make it significantly easier
to read the diagram.
 Activity final node. The filled circle with a border is the ending point.
An activity diagram can have zero or more activity final nodes.
 Activity. The rounded rectangles represent activities that occur. An
activity may be physical, such as Inspect Forms, or electronic, such
as Display Create Student Screen.
 Flow/edge. The arrows on the diagram. Although there is a subtle
difference between flows and edges, never a practical purpose for the
difference although
 Fork. A black bar with one flow going into it and several leaving it.
This denotes the beginning of parallel activity.
 Join. A black bar with several flows entering it and one leaving it. All
flows going into the join must reach it before processing may
continue. This denotes the end of parallel processing.
 Condition. Text such as [Incorrect Form] on a flow, defining a guard
which must evaluate to true in order to traverse the node.
 Decision. A diamond with one flow entering and several leaving. The
flows leaving include conditions although some modelers will not
indicate the conditions if it is obvious.
 Merge. A diamond with several flows entering and one leaving. The
implication is that one or more incoming flows must reach this point
until processing continues, based on any guards on the outgoing
flow.
 Partition. If figure is organized into three partitions, it is also called
swim lanes, indicating who/what is performing the activities (either
the Applicant, Registrar, or System).
 Sub-activity indicator. The rake in the bottom corner of an activity,
such as in the Apply to University activity, indicates that the activity is
described by a more finely detailed activity diagram.
 Flow final. The circle with the X through it. This indicates that the
process stops at this point.
 Experiment:-7

AIM:-
To prepare STATE CHART DIAGRAM for “HEALTH MANAGEMENT SYSTEM
FOR KIDS”.
REQUIREMENTS:-
Hardware Interfaces:-
Dual Core Processor (CPU 2.0 GHz), 2 Gb RAM ,Screen resolution of at
least 800 x 600 required for proper and complete viewing of screens. Higher
resolution would not be a problem.
Software Interfaces:-
Windows 7
IBM Rational Rose Software
THEORY:-
 State Chart Diagrams provide a way to model the various states in
which an object can exist.
 There are two special states: the start state and the stop state. The
Start state is represented by a block dot.
 The Stop state is represented by a bull’s eye.
 A condition enclosed in square brackets is called a guard condition,
and controls when a transition can or cannot occur.
  Processes that occur while an object is in certain state are called
actions.

Experiment:- 8
Aim:-
Steps to draw the Sequence Diagram automated banking system.
Hardware Requirements:-
Dual Core processor (2.0 GHz),2 GB RAM, Standard keyboard and
mouse, colored monitor.
Software Requirements:-
Rational Rose, Windows 7
Theory:
UML sequence diagrams model the flow of logic within the system in a visual
manner, enabling the user both to document and validate the logic, and are
commonly used for both analysis and design purposes. Sequence diagrams
are the most popular UML artifact for dynamic modeling, which focuses on I
dentifying the behavior within your system. Sequence diagrams, along with
class diagrams and physical data models are the most important design-
level models for modern application development.
Sequence diagrams are typically used to model:-
Usage scenarios:-
A usage scenario is a description of a potential way the system is used. The
logic of a usage scenario may be part of a use case, perhaps an alternate
course. It may also be one entire pass through a use case, such as the logic
described by the basic course of action or a portion of the basic course of
action, plus one or more alternate scenarios. The logic of a usage scenario
may also be a pass through the logic contained in several use cases. For
example, a Kids make an id and then immediately enrolls in three
vaccenication.
The logic of methods. Sequence diagrams can be used to explore the logic of
a complex operation, function, or procedure. One way to think of sequence
diagrams, particularly highly detailed diagrams, is as visual object code. The
logic of services. A service is effectively a high-level method, often one that
can be invoked by a wide variety of clients.

Experiment :-9

Aim:-
To draw the collaboration Diagram using Rational Rose.
Hardware Requirements:-
Dual Core Processor (2.0 GHz), 2 GB RAM, Standard keyboard and
mouse, colored monitor.
Software Requirements:-
Rational Rose, Windows 7
THEORY:-
Collaboration diagrams are also relatively easy to draw. They show the
relationship Between objects and the order of messages passed between
them. The objects are listed as icons and arrows indicate the messages
being passed between them. The numbers next to the messages are called
sequence numbers. As the name suggests, they show the sequence of the
messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format
can be used, as the example below shows, or for more detailed and complex
diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can because.
 Experiment:-10

Aim:-
To draw the Class Diagram using Rational Rose.
Hardware Requirements:-
Dual Core processor (2.0 GHz), 2 GB RAM, Standard keyboard and
mouse, colored monitor.
Software Requirements:-
Rational Rose, Windows 7
THEORY:
A class diagram is a type of static structure diagram that describes the
structure of a System by showing the system's classes, their attributes, and
the relationships between the Classes.
Class diagrams show the classes of the system, their inter-relationships, and
the Operations and attributes of the classes. Class diagrams are typically
used, although not all at once, to:
 Explore domain concepts in the form of a domain model
 Analyze requirements in the form of a conceptual/analysis model
  Depict the detailed design of object-oriented or object-based software
A class model is comprised of one or more class diagrams and the
supporting Specifications that describe model elements including classes,
relationships between Classes, and interfaces. There are guidelines
1. General issues

2. Classes

3. Interfaces

4. Relationships

5. Inheritance

6. Aggregation and Composition GENERAL GUIDELINES:-

Because class diagrams are used for a variety of purposes – from

understanding Requirements to describing your detailed design – it is
needed to apply a different style in Each circumstance. This section
describes style guidelines pertaining to different types of Class diagrams.

CLASSES:-
A class in the software system is represented by a box with the name of the
class written Inside it. A compartment below the class name can show the
class's attributes (i.e. its Properties). Each attribute is shown with at least its
name, and optionally with its type, Initial value, and other properties.
A class is effectively a template from which objects are created (instantiated).
Classes Define attributes, information that is pertinent to their instances, and
operations, Functionality that the objects support. Classes will also realize
interfaces (more on this Later).
Class diagrams are widely used to describe the types of objects in a system
and their Relationships. Class diagrams model class structure and contents
using design elements Such as classes, packages and objects. Class
diagrams describe three different Perspectives when designing a system,
conceptual, specification, and implementation. These perspectives become
evident as the diagram is created and help solidify the Design.
INTERFACES:-
An interface is a collection of operation signature and/or attribute
definitions that ideally Defines a cohesive set of behaviors. Interface a class
or component must implement the Operations and attributes defined by the
interface. Any given class or component may Implement zero or more
interfaces and one or more classes or components can implement The same
interface.
RELATIONSHIPS:-
A relationship is a general term covering the specific types of logical
connections found on a class and object diagram. Class diagrams also
display relationships such as containment, inheritance, associations and
others. The association relationship is the most common relationship in a
class diagram. The Association shows the relationship between instances of
classes. Another common relationship in class diagrams is a generalization.
A generalization is used when two classes are similar, but have some
differences.
AGGREGATION:-
Aggregation is a variant of the "has a" or association relationship;
composition is more Specific than aggregation. Aggregation occurs when a
class is a collection or container of other classes, but where the contained
classes do not have a strong life cycle dependency on the container--
Essentially, if the container is destroyed, its contents are not.

ASSOCIATION:-
Association are semantic connection between classes. When an association
connects two classes , each class can send messages to other in a
sequence or a collaboration diagram . Associations can be bidirectional or
unidirectional.

DEPENDENCIES:-
Dependencies connect two classes. Dependencies are always
unidirectional and show that one class, depends on the definitions in
another class.
GENERALIZATION:-

The generalization relationship indicates that one of the two related classes
(the super type) is considered to be a more general form of the other (the
subtype). In practice, this means that any instance of the subtype is also an
instance of the super type . The generalization relationship is also known as
the inheritance or "is a" relationship.
The super type in the generalization relationship is also known as the
"parent", superclass, base class, or base type.

The subtype in the generalization relationship is also known as the "child",

subclass, derived class, derived type, inheriting class, or inheriting type.

MULTIPLICITY:-
The association relationship indicates that (at least) one of the two related
classes makes reference to the oth.