8 Medical Transcription

PROBLEM STATEMENT
A problem statement is a class concise designation

of the issues that need to be addressed by a problem
solving team and should be presented to them or
created by them before they try to solve the problem
When bringing together a team to achieve a
particular purpose efficiently provide them with a
problem statement .A good problem statement
answers the following questions:
1. What is the problem?
2. Who has the problem? Or who is the client
customer?
This should explain who needs the solution and who
will decide the problem has been solved.
3. What is the scope and limitations (in time, money
resources, technology) that can be used to solve the
problem?
4. What are the features of the problem?
In this srs of Medical Transcription, the problem

faced by the doctor while doing the surgery or
operation is solved. In Functionality of the Online
Medical transcription System, a physician dictates
into a dicta phone, the details that need to be
transcribed. This is then converted into voice files
and after encryption uploaded to the portal. The
assigned Transcriptions then transcribe these files
online via the transcription interface; Options for
viewing, editing and approving the transcribed
document were developed. Reports are then
generated and made available to the physician.
This process is requires less time if answers for

questions are stored in the database or other wise
doctor will get response from transcription for his
problem.
SOFTWARE REQUIREMENT
SPECIFICATION OF MEDICAL
TRANSCRIPTION
1.Introduction:
This is the document of the development life cycle

of the project. It guides the designers and
developers to identify the functionality of the
project.
The Medical Transcription business consists of
receiving dictations from doctors, transcribing them
according to set rules, editing the output for errors,
and transmitting it back to the sources of the
recordings. Turnaround times typically demand that
recordings are returned by the start of the next
working day. Quality obviously is important as
mistakes can affect the treatment of patients.
1.1Purpose:
Medical transcription is the primary mechanism by
which physicians, hospitals and other medical
professionals communicate patient record
information with other physicians, insurance
companies, etc., and which forms the basis of what
we would otherwise consider to be the paper
record that resides within the medical office.
Medical transcription, which is also known as MT,
is the process of transcribing or converting
recorded dictations by physicians and/or other
healthcare professionals regarding a patient's
medical record into a written text. Medical
transcription follows prescribed and established
document (record) formats and is highly
dependent upon trained professional, known as
medical transcriptions. Specialized knowledge for
medical transcription includes the ability to
correctly spell often difficult medical words, as
well as a working knowledge of general medical
terminology.
Medical transcription can also used to describe the

name of the document (electronic or physical) that
results from the medical transcription process,
normally in reference to a healthcare professional's
record of a medical encounter with a patient. It is
referred to as a "medical record."
1.2 Scope:
To create an online portal that provides a platform

where “practices” and Medical transcription
companies can interact and do business. The scope
of the proposed system included
• Dictations Jobs
• Uploading of encrypted voice files to a ftp site
(automated process)
• To transcribe online thru the transcription
interface
• Generate a List of transcribed jobs
• To view / approve the transcriptions
• To Batch print, convert to PDF
• Generate reports
1.3 Definitions Acronyms & Abbreviations:

Function: A defined objects or characteristics action
of a system or a component. A software module that
performs a specific action is invoked by the
appearance of its name in an expression may receive
input values and return a single value.
Interface: A connection between two devices or

systems.
Network: Describes the physical hardware and

software conections between computers allowing
information to be shared and electronic
communications to take place.
Project: The combined resources (people, machines,

materials), processes and activities that are dedicated
in building and delivering the product to a customer.
Requirements: The statement of needs by a user
that triggers the development of a program, system
or project. That May be called business functional
requirements or requirements specification.
HTML: Hyper Text Markup Language

DDBMs: Distributed Data Base Management
System
CN: Computer Network
TCP: Transport Communication Protocol
IP: Internet Protocol
UDP: User Data gram Protocol
1.4 References:
1) www.binaryspectrum.com
2) Medical transcription books
3) Wikipedia.org
4) IEEE. IEEE Std 830-1998 IEEE Recommended
Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.

1.5 Overview:
The rest of the SRS contains general description of

medical transcription such as advantages of
medical transcription, functionality of online
medical transcription, workflow of medical
management system.
2) General Description:
streamlines the flow of information and jobs
between the doctor’s office and the transcription
provider. Considerably reduces time taken to
manually allocate jobs and further provides specific
reports like tracking and audits.
2.1 Product Perspective:

The concept is not a follow on member of a product
family o a replacement of an existing operating
system. It is a new self- contained product or
software. It is a product rather than a component of a
larger system.
It helps the doctors to get the information
regarding the task which he/she is performing.
2.2 Product function:
It helps to enable transcription services online
through web. Provides an administration module,
which enables transcription provider management,
user management, synchronization & other setup
information.
The Functions are:
• Login: This function takes the username and

password as the input. Based on this it goes
into the corresponding batch among users.
Doctors, management, Medical Transcription,
Proofreader and administrator.
• Functionality: This function contains the

information of all users
2.3 User characteristics:
As the every new system, users are strictly reluctant

to change to the new system. The problem gets more
complicated as the users have never been used to
automated solutions, and thus a shift might mean
getting used to the new system, or otherwise a loss
of job. Incorporating a new system of- course needs
planning for training the end-user. Thus the
responsibilities lies on our shoulders to a much
greater extent in that we have to deliver a fully
efficient system, which is customizable and is
absolutely user-friendly.
It contains the following characters
I) Doctor: Doctor dictates the records
II) Database: Who stores all the records and
maintains documents
III) Manager: Manages all the operations
IV) Medical Transcriptor: Transcripts the
records
V) Proof reader: Verifies & edits the records
VI) Documentation: Verifies & stores the
records in database.
2.4 General constraints:
The system must implement the constraints like

 Each user must be able to enter into services
provided by the database management only if
he/she has a valid username ad password
 The time taken to complete a job must be in
small amount. After that the task must be
displaced.
 If an account opened by a user or a doctor is
inactive for log period of time, automatic
logoff must be provided.
 Each user must have proper authenticity to
enter the different fields of services provided
by the management.
 Doctors cannot access the management
details of the medical transcription.
 The system must automatically respond to
the report/query which has been send by the
doctor if it is already exists in the system.
Time constraint:
The system must complete the operation with in the

specified time constraint.
2.5 Assumptions & Dependencies:

 It is assumed that this software will
work for upcoming hardware architecture.
 It has also assumed that all the hardware
that is required is laid down prior to the
installation of the system.
3 Specific Functions:
3.1 Functional Requirements
3.1.1 Functional Requirement number 1:

Creation and transfer of records
3.1.1.1 Introduction:
The doctor records the message or report and sends
it to the database.
3.1.1.2 Inputs:
The doctor has to get login by typing his username
& password.
3.1.1.3 Processing:
The doctor dictates the report into a Dictaphone.
This is then converted into voice files and after
encryption it is send to database. If the answer is
present in database, then it will response
immediately to the query transmitted by the doctor.
If it is not present, it will send it to manager.
3.1.1.4 Output:
The database will send the answer for the query
transmitted by the doctor.
3.1.2 Functional Requirement Number 2:
transcription of records
The manager transmits the report from database to
the medical transcription.
3.1.2.2 Inputs:
The manager & medial transcription has to get login
with his user name & password.
3.1.2.3 Processing:
The manager will transmit the report, which doesn’t
contain its answer in database to the medical
transcription for Tran scripting the report.
3.1.2.4 Output:
The transcriptionist will transcripts the reports via
the transcription interface and sends it for proof
reading.

verification of records
The Proof reader will verify the records.
3.1.3.2 Inputs:
The proofreader must get login into with his id and
password.
3.1.3.3 Processing:
The proofreader will receive the Tran scripted report
from medical transcriptions. It verifies the report for
any errors. It also edits the report. After that
proofreader will send it for documentation.
3.1.3.4 Output:
After editing the report, the proofreader will send it
for documentation.

writing and verifying of records
3.1.4.1Introduction:
The writing, verifying & storing of documents.
3.1.4.2 Inputs:
The administrator has to get login with his
administrator id and password.
3.1.4.3 Processing:
The administrator writes the document for the report
send by the proofreader. After writing the document,
he verifies the document. Then he will store the
document in the database.
3.1.4.4 Output:
The documents are stored in the database.

transfer of reports to doctor
Transmission of document to the doctor.
3.1.4.2 Inputs:
doctor has to get login with his id and password
3.1.4.3 Processing:
The database will generate the reports and it will
send it to the doctor.
3.1.4.4 Output: The doctor will receive the answer

for his query.
3.2 External Interface Requirements:
3.2.1 User Interface:

Administrator and use press a hot key to pop up
the login window. It contains two fields, Id &
Password and a button called login.
3.2.2 Hardware Interface:

The software does not require any specific
hardware interfaces. It required the user could use
the hardware interfaces provided by the operating
system.
3.2.3 Software Interface:

The system will interface with the Internet
browser for establishing a secure connection
between the user and web server for transmitting
data safely and securely. The system will interface
with medical transcription database management
system for reading and updating the database in a
secure fashion by SQL server.
3.2.4 Communication Interface:

At the user side, a communication interface such
as HTTP is required which can support encryption
and TCP/IP for connection setup so that data can be
securely transferred.
3.3 Performance Requirements:

The interaction between doctor & medical
transcriptor, how they perform their jobs? It mainly
includes the voice clarity should be good. It includes
• Throughput: Throughput is the rate at which

the system can respond to the queries/reports
transmitted by user/doctor. We measure
throughput in Responds per second. If there are
more users, the system reaches a maximum
throughput and then starts to drop as more users
join the system. A good system must be able to
maintain stable throughput as we add more
users.
• Response Time: Response time is the elapsed

time we experience from the time he/she submits
a report until he/she receives the response/
answer for his query. The response time must be
linear.
• Concurrent Users: The number of concurrent

users is an important factor in this system. We
should measure throughput, response time and
also the performance of the system at peak time.
We measure them as the function of number of
users. In addition, database consistency is an
important issue when thee are concurrent users
accessing the database.
3.5 Attributes:
It includes
• Portability: Portability is the ease with which

software transferred from one environment to
other. The system must be able to serve the users
with the most browsers that satisfy the security
requirements. The system must work with
internet explorer and Netscape.
• Reliability: Reliability is the ability of the

system to perform required function under stated
conditions for specific period of time.
• Availability: It is a measure of the time the

system is able to serve the customers.
Availability must be high.
• Robustness: Robustness is the extent to which
software scan continue to operate correctly
despite the introduction of invalid inputs. The
system should be highly robust.
• Accuracy: It is qualitative assessment of

freedom from error. Due to financial nature f the
system, it must be highly accurate.
3.5.1 Security:
In internet medical transcription, security is a

primary concern. Every necessary precaution should
be taken to be sure that information is transmitted
safely and securely. Te latest methods in security are
needed to increase and monitor the integrity and
security of the system.
3.5.2 Maintainability:
The maintainability of this software is very easy.

The records and documents of the records is stored
in the data base which is simultaneously stored as a
hard copy to preserve the records thus any loss to the
data base can be easily verified with the hard copy
and later it can be added.
3.7 Testing:
The product on medical transcriptions must undergo

white box testing as every data must be accessed of
the doctor, manager, transcriptions, and proof reader.
UML CLASS DIAGRAMS
A Unified Modeling Language (UML) class diagram

provides a graphical representation of the structures
and relationships of elements in an application.
For example, a class diagram can depict some or all
of the components or elements in an application.
You can use class diagrams to create your own
context to examine, understand, collaborate, and
design using a subset of the components or elements
in an application.
Class diagrams use multiple variations of association
relationships to indicate which classifiers must share
data with other classifiers
UML classes
Unified Modeling Language (UML) classes are

diagram elements that represent abstractions of an
object or set of objects that share a common
structure and behavior.
A UML class identifies the attributes, operations,
relationships, and semantics that instances of the
class possess. Every object that instantiates a class
usually provides its own attribute values. Attributes
are also called variables, member variables,
properties, and fields, but are usually implemented
as variables. In a diagram, each class has properties
that govern its appearance and location. Modifying
properties of a class in a diagram only changes the
appearance of the shape and does not affect the
underlying semantics or any other shape that
represents that application element.
As the following figure illustrates, a class shape
appears as a rectangle with three compartments:
• The upper compartment contains the class name.
• The middle compartment contains the attributes.
• The lower compartment contains the operations.
You can show, hide, or collapse the attribute and
operation compartments.
You can use additional compartments to display

other details such as constraints or signals that
instances of the class can receive.
The classes in an application usually appear in class
diagrams. Classes or instances of classes, such as
objects or classifier roles, also appear frequently in
other types of diagrams, including sequence
diagrams. You can add classes to diagrams to
represent the following items:
• Workers and artifacts of a business
• Components or building blocks of a software
system, such as C/C++ classes and database
tables for databases
UML class diagrams
A Unified Modeling Language (UML) class diagram

provides a graphical representation of the structures
and relationships of elements in an application.
For example, a class diagram can depict some or all
of the components or elements in an application.
You can use class diagrams to create your own
context to examine, understand, collaborate, and
design using a subset of the components or elements
in an application.
Class diagrams use multiple variations of association
relationships to indicate which classifiers must share
data with other classifiers.
Attributes
In Unified Modeling Language (UML) class

diagrams, an attribute represents a data definition for
an instance of a classifier. An attribute describes a
range of values for that data definition.
A classifier can have any number of attributes or
none at all. Attributes describe the structure and
value of an instance of a class.
For example, one of the attributes that a "Customer"
class has is a "balance" attribute that holds the
amount of money in the customer's account.
In UML class diagrams, the following mappings
exist:
• C/C++ fields map to attributes,
• C/C++ primitive types always map to attributes,
• C/C++ attributes can be shown as associations,
except primitive types (int, float, char, and so
on).
Attributes are shown in the attribute compartment of
a shape.
The following table shows attributes declared in
source code and how they are illustrated in the
Visualizer.
C/C++ source code UML visualization
You can show, hide, or collapse the attribute

compartment, and show or hide the compartment
title. You can also specify the visibility styles of
attributes as text symbols (such as "-") or icons (such
as ).
Operations in UML class diagrams

diagrams, an operation requests a service that a
classifier or an instance of a class is called to
perform. Operations are contained by classes. A
classifier can have any number of operations or none
at all.
Operations are implementations of functions or
queries that an object might be called to perform. A
well-defined operation does only one thing.
For example, you can make a Cart class responsible
for adding and removing merchandise that a
customer plans to buy. Then you can add an
addItem() operation that adds merchandise to the
cart and a removeItem( ) operation that removes
merchandise.
In class diagrams, C/C++ methods map to UML
class operations or behaviors.
As the figure in the following table illustrates,
operations are shown in the operation compartment
of a shape in a UML class diagram.
C/C++ source code UML visualization

You can show, hide, or collapse the operation
compartment, and show or hide the compartment
title. You can also specify the visibility styles of
operations as text symbols (such as "+") or icons
(such as ).
Multiplicity

diagrams, multiplicity specifies the range of
allowable cardinalities that a set of associated
classes can assume.
A multiplicity specification is a subset of the open
set of non-negative integers. You can give
multiplicity specifications for roles in association
relationships.
A multiplicity relationship appears as a text string
that comprises an integer value that represents the
number of data objects that can be associated with a
C/C++ class.
Multiplicity relationships are possible in that one
class can relate to another in a one-to-one or a one-
to-a bounded interval; for example, 1 to 1 or 1 to 10.
.
Visibility
In class diagrams, visibility defines whether other

classes can see and use the attributes and operations
of specific classes.
For example, other classes can see and use the
attributes and operations in a class with public
visibility, while the attributes and operations with
private visibility can be seen and used only by the
class that contains them.
As the following table illustrates, you can use
decoration icons or text symbols to show the level of
visibility for attributes and operations. A text symbol
appended to the name of an association end shows
the visibility of that association end.
Visibility Icon for Icon for Text Description

level attribute operation symbol
Private - Only classes
within the
same
container
can see and
use the
classes with
Private
visibility.
Protected # Only classes
within the
same
container or
Visibility Icon for Icon for Text Description
level attribute operation symbol
a descendent
of the
container
can see and
use the
classes with
Protected
visibility.
Public + Any class
that can see
the
container
can also see
and use the
classes with
Public
visibility.
You can specify visibility styles for classifier

features, including attributes and operations in class
diagrams. You can specify the visibility styles by
showing or hiding decoration icons (such as ) and
text symbols (such as #) that indicate the level of
visibility for attributes and operations
Class diagrams for medical transcription services

manager
name : string
doctor id : integer
name : string tra nscript ionist
monitoring the record()
id : 'integer
receives the records() name : string
sends to transcriptionist() id : integer
create a record()
send to data base()
reciving the report() receives the records()
sending the report transcripts the records()
* sends records for proof reading()
sending documents
database
name : string
capacity : varchar2
storing of records()
storing of documentation()
sends documents to doctor()
documentation proof reader

name : string name : string
id : integer id : integer
writing the document() verify the records()

verify the document() editing of records()
storing in the data base() ordering for documentation()
Use-case diagrams
In UML, use-case diagrams model the behavior of a

system and help to capture the requirements of the
system.
Use-case diagrams describe the high-level functions
and scope of a system. These diagrams also identify
the interactions between the system and its actors.
The use cases and actors in use-case diagrams
describe what the system does and how the actors
use it, but not how the system operates internally.
Use-case diagrams illustrate and define the context
and requirements of either an entire system or the
important parts of the system. You can model a
complex system with a single use-case diagram, or
create many use-case diagrams to model the
components of the system. You would typically
develop use-case diagrams in the early phases of a
project and refer to them throughout the
development process.
Use-case diagrams are helpful in the following
situations:
• Before starting a project, you can create use-case
diagrams to model a business so that all
participants in the project share an
understanding of the workers, customers, and
activities of the business.
• While gathering requirements, you can create
use-case diagrams to capture the system
requirements and to present to others what the
system should do.
• During the analysis and design phases, you can
use the use cases and actors from your use-case
diagrams to identify the classes that the system
requires.
• During the testing phase, you can use use-case
diagrams to identify tests for the system.
The following topics describe model elements in

use-case diagrams:
Use cases
A use case describes a function that a system

performs to achieve the user’s goal. A use case must
yield an observable result that is of value to the user
of the system.
Use cases contain detailed information about the
system, the system’s users, relationships between the
system and the users, and the required behavior of
the system. Use cases do not describe the details of
how the system is implemented.
Each use case describes a particular goal for the user
and how the user interacts with the system to
achieve that goal. The use case describes all possible
ways that the system can achieve, or fail to achieve,
the goal of the user.
You can use use cases for the following purposes:
• Determine the requirements of the system
• Describe what the system should do
• Provide a basis for testing to ensure that the
system works as intended
In models that depict businesses, use cases represent
the processes and activities of the business. In
models that depict software systems, use cases
represent the capabilities of the software.
Each use case must have a unique name that
describes the action that the system performs. Use
case names are often short phrases that start with a
verb, such as Place Order Online.
As the following figure illustrates, a use case is
displayed as an oval that contains the name of the
use case.
You can add the following features to use cases:
• Attributes that identify the properties of the
objects in a use case
• Operations that describe the behavior of objects
in a use case and how they affect the system
• Documentation that details the purpose and flow
of events in a use case
Actors
An actor represents a role of a user that interacts

with the system that you are modeling. The user can
be a human user, an organization, a machine, or
another external system.
You can represent multiple users with a single actor
and a single user can have the role of multiple
actors. Actors are external to the system. They can
initiate the behavior described in the use case or be
acted upon by the use case. Actors can also
exchange data with the system.
In models that depict businesses, actors represent the
types of individuals and machines that interact with
a business. In models that depict software
applications, actors represent the types of
individuals, external systems, or machines that
interact with the system.
You would typically use actors in use-case diagrams,
but you can also use them in class and sequence
diagrams.
As the following figure illustrates, an actor is
displayed as a line drawing of a person.
Each actor has a unique name that describes the role

of the user who interacts with the system.
You can add documentation that defines what the
actor does and how the actor interacts with the
system.
Subsystems
In UML models, subsystems are a type of

stereotyped component that represent independent,
behavioral units in a system. Subsystems are used in
class, component, and use-case diagrams to
represent large-scale components in the system that
you are modeling.
You can model an entire system as a hierarchy of
subsystems. You can also define the behavior that
each subsystem represents by specifying interfaces
to the subsystems and the operations that support the
interfaces.
In diagrams, compartments display information
about the attributes, operations, provided interfaces,
required interfaces, realizations, and internal
structure of the subsystem.
Typically, a subsystem has a name that describes its
contents and role in the system.
As the following figure illustrates, a subsystem is
displayed as a rectangle that contains the name of
the subsystem. It also contains the keyword
«Subsystem» and the subsystem icon.
Relationships in use-case diagrams
In UML, a relationship is a connection between

model elements. A UML relationship is a type of
model element that adds semantics to a model by
defining the structure and behavior between the
model elements.
UML relationships are grouped into the following
categories:
Category Function
Activity edges Represent the flow between
activities
Associations Indicate that instances of one model
element are connected to instances
of another model element
Dependencies Indicate that a change to one model
element can affect another model
element
Generalizations Indicate that one model element is a
specialization of another model
element
Realizations Indicate that one model element
provides a specification that another
model element implements
Transitions Represent changes in state
You can set properties and use keywords to create
variations of these relationships.
The following topics describe the relationships that
you can use in use-case diagrams:
Association relationships
In UML models, an association is a relationship

between two classifiers, such as classes or use cases,
that describes the reasons for the relationship and the
rules that govern the relationship.
An association represents a structural relationship
that connects two classifiers. Like attributes,
associations record the properties of classifiers. For
example, in relationships between classes, you can
use associations to show the design decisions that
you made about classes in your application that
contain data, and to show which of those classes
need to share data. You can use an association's
navigability feature, to show how an object of one
class gains access to an object of another class or, in
a reflexive association, to an object of the same
class.
The name of an association describes the nature of
the relationship between two classifiers and should
be a verb or phrase.
In the diagram editor, an association appears as a
solid line between two classifiers.
Association ends
An association end specifies the role that the object
at one end of a relationship performs. Each end of a
relationship has properties that specify the role of the
association end, its multiplicity, visibility,
navigability, and constraints.
Example
In an e-commerce application, a customer class has a
single association with an account class. The
association shows that a customer instance owns one
or more instances of the account class. If you have
an account, you can locate the customer that owns
the account. Given a particular customer, you can
navigate to each of the customer’s accounts. The
association between the customer class and the
account class is important because it shows the
structure between the two classifiers.
Generalization relationships
In UML modeling, a generalization relationship is a
relationship in which one model element (the child)
is based on another model element (the parent).
Generalization relationships are used in class,
component, deployment, and use-case diagrams to
indicate that the child receives all of the attributes,
operations, and relationships that are defined in the
parent.
To comply with UML semantics, the model
elements in a generalization relationship must be the
same type. For example, a generalization
relationship can be used between actors or between
use cases; however, it cannot be used between an
actor and a use case.
You can add generalization relationships to capture
attributes, operations, and relationships in a parent
model element and then reuse them in one or more
child model elements. Because the child model
elements in generalizations inherit the attributes,
operations, and relationships of the parent, you must
only define for the child the attributes, operations, or
relationships that are distinct from the parent.
The parent model element can have one or more
children, and any child model element can have one
or more parents. It is more common to have a single
parent model element and multiple child model
elements.
Generalization relationships do not have names.
As the following figures illustrate, a generalization
relationship is displayed in the diagram editor as a
solid line with a hollow arrowhead that points from
the child model element to the parent model
element.
Single parent with a Single parent with multiple

single child children
Include relationships
In UML modeling, an include relationship is a

relationship in which one use case (the base use
case) includes the functionality of another use case
(the inclusion use case). The include relationship
supports the reuse of functionality in a use-case
model.
You can add include relationships to your model to
show the following situations:
• The behavior of the inclusion use case is
common to two or more use cases.
• The result of the behavior that the inclusion use
case specifies, not the behavior itself, is
important to the base use case.
Include relationships usually do not have names. If
you name an include relationship, the name is
displayed beside the include connector in the
diagram.
As the following figure illustrates, an include
dashed line with an open arrow pointing from the
base use case to the inclusion use case. The keyword
«include» is attached to the connector.
Example
The following figure illustrates an e-commerce
application that provides customers with the option
of checking the status of their orders. This behavior
is modeled with a base use case called
CheckOrderStatus that has an inclusion use case
called LogIn. The LogIn use case is a separate
inclusion use case because it contains behaviors that
several other use cases in the system use. An include
relationship points from the CheckOrderStatus use
case to the LogIn use case to indicate that the
CheckOrderStatus use case always includes the
behaviors in the LogIn use case.
Extend relationships
In UML modeling, you can use an extend
relationship to specify that one use case (extension)
extends the behavior of another use case (base). This
type of relationship reveals details about a system or
application that are typically hidden in a use case.
The extend relationship specifies that the
incorporation of the extension use case is dependent
on what happens when the base use case executes.
The extension use case owns the extend relationship.
You can specify several extend relationships for a
single base use case.
While the base use case is defined independently and
is meaningful by itself, the extension use case is not
meaningful on its own. The extension use case
consists of one or several behavior sequences
(segments) that describe additional behavior that can
incrementally augment the behavior of the base use
case. Each segment can be inserted into the base use
case at a different point, called an extension point.
The extension use case can access and modify the
attributes of the base use case; however, the base use
case is not aware of the extension use case and,
therefore, cannot access or modify the attributes and
operations of the extension use case.
You can add extend relationships to a model to show
the following situations:
• A part of a use case that is optional system
behavior
• A subflow is executed only under certain
conditions
• A set of behavior segments that may be inserted
in a base use case
Extend relationships do not have names.
As the following figure illustrates, an extend
dashed line with an open arrowhead pointing from
the extension use case to the base use case. The
arrow is labeled with the keyword «extend».
Example
You are developing an e-commerce system in which
you have a base use case called Place Online Order
that has an extending use case called Specify
Shipping Instructions. An extend relationship points
from the Specify Shipping Instructions use case to
the Place Online Order use case to indicate that the
behaviors in the Specify Shipping Instructions use
case are optional and only occur in certain
circumstances.
Extending the behavior of use cases
In UML modeling, when you draw use-case

diagrams, you communicate the essence of the
system or application without exposing any
unnecessary details. It’s generally good practice to
hide the complexity of the system, but there are
times when you might need to expose details. You
can depict these details in their own use cases and
connect them to the base use cases, which enables
you to reveal information that would otherwise be
hidden.
• Adding extend relationships to modeling

diagrams
In UML modeling, an extend relationship
indicates that the extension use case extends the
behaviors in a base use case.
• Creating an extension point for a use case

In UML modeling, you can create extension
points for the base use case. These extension
points identify where the behavior of an
extension use case can be inserted into the base
use case
Adding extend relationships to modeling

diagrams
In UML modeling, an extend relationship indicates

that the extension use case extends the behaviors in a
base use case.
You must have a least two use cases in a diagram.
To add an extend relationship:
1.In the Palette, under Use-case Diagram, click
Extend.
2.Click the extension use case and drag the arrow
cursor to the base use case.
3. On the pop-up menu, click Create new
Extension Point.
The extend relationship is added between the base
use case and the extension use case and a new
extension point is added to the Extension Points
compartment of the base use case.
Creating an extension point for a use case
In UML modeling, you can create extension points

for the base use case. These extension points identify
where the behavior of an extension use case can be
inserted into the base use case.
To create an extension point:
1.In the diagram editor, right-click a use case; then
click Add UML > Extension Point.
2.Type a name for the extension point and press
Enter.
Use case diagrams for medical transcription
services
creat e a reco rd
recieves t he records
send to data base

doctor
transcript s the rec ords
transcriptionist
recieves the documents

sends records for proof reading
monitoring the records

storing of records
reci eves the records

manage r
storing of documents
data base
sends to transcriptionist
send ing documents to d octor
verify the records
writ ing t he documents
editing of records
proof reader
verify the documents
documentation
ordering for documentation
storing in the database

Sequence diagrams
You can use Unified Modeling Language (UML)

sequence diagrams to create a graphical
representation of the source elements in a system or
application to understand and develop behaviors and
interactions between classes and data types.
You can create new sequence diagrams, populate
existing sequence diagrams with source elements,
and add lifelines, messages, and combined fragments
to sequence diagrams.
• Creating sequence diagrams from existing

elements
You can create sequence diagrams in the typical

way that you create any UML diagram, or you can
create them from existing elements in your project.
You can create a sequence diagram either within a
model, which also creates a collaboration and
interaction, or as a standalone diagram, which
becomes a DNX file.
• Populating sequence diagrams
You can create sequence diagrams and populate

them with elements to understand and develop
behaviors and interactions between objects in
systems. You can add lifelines to represent objects
or actors, messages to represent communication
between the objects, and combined fragments to
represent the control structures.
• Organizing sequence diagrams
You can organize sequence diagrams to better

represent a system. You can reorder messages,
delay asynchronous messages, as well as manage
combined fragments and lifelines.
• Deleting messages from sequence diagrams
You can delete messages from your project that

you no longer need. When you delete a message,
you have different results depending on the type of
message that you delete.
• Deleting lifelines from UML diagrams
You can delete lifelines from UML diagrams, such

as sequence or communication diagrams, to
remove an object from an interaction. When you
delete a lifeline, all send and receive messages that
originate from the deleted lifeline are also deleted.
When you delete a lifeline from a sequence
diagram, all interaction fragments that cover the
lifeline are deleted, but the combined fragments
and interaction uses that cover other lifelines
Creating sequence diagrams from existing

elements
You can create sequence diagrams in the typical way

that you create any UML diagram, or you can create
them from existing elements in your project. You
can create a sequence diagram either within a model,
which also creates a collaboration and interaction, or
as a standalone diagram, which becomes a DNX file.
To create a sequence diagram from existing
elements:
1.In the navigation view, right-click one or more
elements and complete one of the following
steps:
o To add the sequence diagram to a model,
click Visualize > Add to New Diagram in

Model File > Sequence Diagram.
o To create a standalone diagram, click
Visualize > Add to New Diagram File >

Sequence Diagram.
2. In the New Sequence Diagram wizard, specify a
parent folder and file name.

3. Click Finish.
Tip: You can also populate an existing sequence

diagram with source elements. In the navigation
view, right-click one or more classes, interfaces, and
data types; then click Visualize > Add to Current
Diagram.
Populating sequence diagrams
You can create sequence diagrams and populate

them with elements to understand and develop
behaviors and interactions between objects in
systems. You can add lifelines to represent objects
or actors, messages to represent communication
between the objects, and combined fragments to
represent the control structures.
• Creating lifelines in UML diagrams
In UML diagrams, such as sequence and

communication diagrams, you can create lifelines
to represent objects in a system.
• Creating messages in sequence diagrams
In sequence diagrams, you can add synchronous

and asynchronous messages to lifelines to
represent communication between objects. You
can also specify the signatures of messages.
• Creating combined fragments in sequence

diagrams
In sequence diagrams, you can create combined

fragments to visually represent control structures
in interactions.
• Managing interaction operands in sequence
diagrams
In sequence diagrams, an interaction operand is a

container that groups interaction fragments, such
as messages, that runs if the guard condition is
true. An interaction operand is created
automatically when you create a combined
fragment. You can add new interaction operands
to combined fragments that allow multiple
operands, such as alternative, parallel, strict, or
weak combined fragments. You can also remove
and reposition interaction operands in a combined
fragment to reflect changes in your system.
• Adding guard conditions to sequence

diagrams
In sequence diagrams, a guard condition contains

an interaction constraint. An interaction constraint
is a condition or restriction. A guard condition is
created automatically when you create a combined
fragment. You can also manually add a guard
condition to an interaction operand that does not
have an existing guard condition.
• Creating interaction uses in sequence
diagrams
In sequence diagrams, you can create an

interaction use by specifying a new unspecified
occurrence or by creating a new interaction.
Organizing sequence diagrams
You can organize sequence diagrams to better

represent a system. You can reorder messages, delay
asynchronous messages, as well as manage
combined fragments and lifelines.
•
• Reordering messages in sequence diagrams
In sequence diagrams, you can move a message

across other messages and interaction fragments
on the same lifeline or on another lifeline to
reorder the message. After you reorder a message,
the message number automatically indicates the
updated position on the lifeline.
• Adding and removing covered lifelines in
sequence diagrams
In sequence diagrams, you can add and remove

lifelines from combined fragments or interaction
uses.
Deleting messages from sequence diagrams
You can delete messages from your project that you

no longer need. When you delete a message, you
have different results depending on the type of
message that you delete.
You must have a sequence diagram open.
To delete a message, in the diagram editor, right-
click a message; then click Delete from Model.
When you delete a message, the result differs
depending on the type of message.
• If you delete a send message from a
synchronous message, the corresponding
execution specification and return message are
also deleted.
• If you delete a return message from a
synchronous message, the corresponding send
message and execution specification remain
intact.
• If you delete an asynchronous message, the send
message and corresponding execution
specifications are deleted.
• If you delete a create message, the lifeline
extends vertically to the top of the interaction
frame.
• If you delete a destroy message, the lifeline
extends vertically to the bottom of the
interaction frame.
Deleting lifelines from UML diagrams
You can delete lifelines from UML diagrams, such

as sequence or communication diagrams, to remove
an object from an interaction. When you delete a
lifeline, all send and receive messages that originate
from the deleted lifeline are also deleted. When you
delete a lifeline from a sequence diagram, all
interaction fragments that cover the lifeline are
deleted, but the combined fragments and interaction
uses that cover other lifelines are not.
You must have a UML diagram open that contains
lifelines.
To delete a lifeline, in the diagram editor, right-click
a lifeline; then click Delete from Model.
All send and receive messages that originate from
the deleted lifeline and all interaction fragments that
cover the lifeline are deleted. The combined
fragments and interaction uses that cover other
lifelines are not deleted.
SEQUENCE DIAGRAMS
1) Sequence diagram of creating a
ecord
:doct or :data base
creates a record
sends to data base
checks the availability of record
returns the document

2) Sequence diagram of checking the record
: doct or :data base
sends to data base
checks the availability
: manager
create manager
monitors the records
destroy
3) Sequence diagram of Tran scripting the
records
:dat a base : manager transcript ionist
sends records to the manager
monitors the records
sends the records
transcripts the records
4) Sequence diagram for verifying the records

: manager :transcriptionist :proof reader
sends the records
transcripts the record
sends for proof reading
verifies the records

5) Sequence diagram of documenting the records
:proof reader :documentation
verify the records
orders for documentation :data base
documenting the records
creates the data base
stores the documents
storing of records and documentation
destroy
Collaborations
In UML diagrams, a collaboration is a type of

structured classifier in which roles and attributes co-
operate to define the internal structure of a classifier.
You use a collaboration when you want to define
only the roles and connections that are required to
accomplish a specific goal of the collaboration. For
example, the goal of a collaboration can be to define
the roles or the components of a classifier. By
isolating the primary roles, a collaboration simplifies
the structure and clarifies behavior in a model.
Because you do not show the specific classes or
identities of the participating instances, but only the
roles and connectors, you can reuse a collaboration
to diagram architectural patterns of collaborating
objects and to model their common behavior, similar
to a template. When you want to show a specific
occurrence of a pattern, you use a collaboration
occurrence.
A collaboration can include classifiers from different
parts of the system being modeled, and a single
classifier can play different roles and participate in
multiple collaborations. This means that a role in a
collaboration references or types a classifier, but the
collaboration does not physically own or contain the
referenced classifier.
As the following figure illustrates, a collaboration is
displayed as a dashed ellipse with two
compartments.
The top compartment specifies the unique name of

the collaboration. Typically, the name identifies the
pattern or mechanism that the collaboration
provides. In the above example, the collaboration
defines the components of a car. The name of the
collaboration is Car. The structure compartment
shows the internal structure of the collaboration by
using a set of roles. In this example, the Door and
the Frame roles collaborate to define the
collaboration Car. The roles are depicted as
rectangles that contain the name of the role, a colon,
and, if specified, the name of the referenced
classifier. A solid line connects the Door and the
Frame roles in the collaboration.
Collaboration diagrams:
1) Collaboration diagram of creating a record
1: creates the records 3: check s the availabilit y of rec ords
:doctor 2: sends to data base :data base
4: returns the document

2) Collaboration diagram of checking the records
4: monitors the records
:doct or :manager
3: creat e manager
5: destroy
1: sends to data base
2: checks the availability 3)
:data base
Collaboration diagram of Tran scripting the record

2: monitors the records
1: sends records to the manager

:data base :manager
3: sends the records

4: transcripts the records
:transcriptio
nist
4) Collaboration diagram of verifying the records
2: transcript s t he record 4: verifies the records
3: sends for proof reading

: transcriptio : proof
nist reader
1: sends the records
: manager
5) Collaboration diagram of documenting the
records
1: verify the records 3: documenting the records
2: orders for documentation

: proof :documenta
reader tion
4: creates the data base

5: storing of documents
7: destroy
6: storing of records and documentation
:dat a base
ACTIVITY DIAGRAMS
In UML, an activity diagram provides a view of the

behavior of a system by describing the sequence of
actions in a process. Activity diagrams are similar to
flowcharts because they show the flow between the
actions in an activity; however, activity diagrams
can also show parallel or concurrent flows and
alternate flows.
In activity diagrams, you use activity nodes and
activity edges to model the flow of control and data
between actions.
Activity diagrams are helpful in the following
phases of a project:
• Before starting a project, you can create activity
diagrams to model the most important
workflows.
• During the requirements phase, you can create
activity diagrams to illustrate the flow of events
that the use cases describe.
• During the analysis and design phases, you can
use activity diagrams to help define the behavior
of operations.
As the following figure illustrates, an activity
diagram belongs to an activity in the model. When
you create an activity diagram, it is displayed in the
Project Explorer view in the Diagrams folder, and
also in the Models folder as a child element of the
owning activity. The corresponding activity frame is
displayed in the diagram editor.
The header of the activity frame displays the name
of the activity, Activity1, and the body of the
activity frame displays the nodes and edges that
describe the activity. After you create the activity
diagram, you cannot move it in the Project Explorer
view.
activity diagrams:
• Activities
In UML, activities are container elements that

describe the highest level of behavior in an activity
diagram. Activities contain several activity nodes
and activity edges that represent the sequence of
tasks in a workflow that result in a behavior.
• Actions
In UML, an action represents a discrete unit of

functionality in an activity.
• Control nodes
In activity diagrams, a control node is an abstract
activity node that coordinates the flow of control
in an activity.
• Object nodes
In activity diagrams, an object node is an abstract

activity node that helps to define the object flow in
an activity. An object node indicates that an
instance of a classifier might be available at a
particular point in the activity.
• Activity edges
In activity diagrams, an activity edge is a directed

connection between two activity nodes. When a
specific action in an activity is complete, the
activity edge continues the flow to the next action
in the sequences
Activities
In UML, activities are container elements that
describe the highest level of behavior in an activity
diagram. Activities contain several activity nodes
and activity edges that represent the sequence of
tasks in a workflow that result in a behavior.
An activity is composed of a series of discrete
activity nodes, such as actions, that are connected by
control flows or object flows. The actions in an
activity are invoked when one of the following
events occur:
• Other actions finish executing
• Objects and data become available to the action
• Events that are external to the flow occur
Each activity has a unique name that describes the
purpose for the activity.
You can use activities to do the following things:
• Create organizational models of business
processes where events can originate from inside
or outside the system
• Create information system models that specify
the system-level processes that occurance
Actions
In UML, an action represents a discrete unit of

functionality in an activity.
Actions have incoming and outgoing activity edges
that specify the flow of control and data to and from
other activity nodes. The actions in an activity start
when all of the input conditions are met. You can
add input pins and output pins to specify values that
are passed to and from the action when it starts. "
Each action has a unique name that describes the
behavior.
The Rational® UML modeling products provide
several different types of actions that you can use
when you create an activity diagram to describe a
particular workflow. The following table lists a few
of the more commonly used actions. You can find
detailed information about the available actions in
the Unified Modeling Language specification that is
available on the Object Management Group (OMG)
Web site.
Type of
action Description Representation
Opaque Opaque
action actions are a
type of action
that you can
use to
represent
implementati
on
information.
You can also
use them as
placeholder
actions until
you
determine the
specific type
of action to
use.
Call Call
behavior behaviors are
a type of
action that
Type of
you can use
to reference
behaviors in
other activity,
state
machine, or
interaction
diagrams in a
model. You
can also add
unspecified
call behaviors
to activity
diagrams, and
then specify a
type later.
Call
behaviors
reference the
behavior,
instead of
referencing
Type of
an operation
which then
invokes a
behavior.
Input pins
and output
pins are
created for
the input and
output
parameters of
the behavior.
Call Call
operation operations are
actions that
you can use
to invoke
operations in
a model. The
referenced
operation
Type of
defines a type
of behavior,
such as a
transformatio
n or a query,
that the target
object can
perform.
Each call
operation has
a unique
name that is
synchronized
with the
operation that
is referenced.
A call
operation
contains the
following
pins:
Type of
• «target»
input pin
-
Represent
s the
target
object to
which the
request is
sent; for
example,
the
classifier
that owns
the
operation.
• Input pin
- There is
one for
each in
parameter
. The
Type of
input
value
must be
compatibl
e with the
operation
parameter
s and the
class that
owns the
operation.
• Output
pin -
There is
one for
each out
parameter
.
Type of
Structure Structured
d activity activities are
a type of
node that you
can use to
create logical
groups of
activity nodes
and edges.
You can add
activity nodes
and edges to
a structured
activity;
however,
these nodes
and edges
belong only
to the
structured
activity. They
are not shared
Type of
with other
structured
activities.
When a
structured
activity is
invoked, the
activity nodes
in the
structured
activity do
not start until
all of the
input data is
received. The
output data
from a
structured
activity is not
available to
other nodes in
the activity,
Type of
and flow does

not continue
through the
activity, until
all the actions
in the
structured
activity have
finished
running.
Tip: You can
change the
orientation of
the flow of
nodes and
edges in a
structured
activity node
by right-
clicking in
the node; then
Type of
clicking
Vertical flow.
Accept Accept events
event are a type of
action that
you can use
to represent
the
processing of
an event. This
type of action
waits for the
occurrence of
an event that
meets
specific
conditions.
Send Send signals
signal are a type of
action that
creates an
instance of a
Type of
signal from
its inputs, and
sends it to the
target object,
which might
invoke a state
machine
transition or
another
activity.
Control nodes
In activity diagrams, a control node is an abstract
activity node that coordinates the flow of control in
an activity.
The following table describes the types of control
nodes that you can use in activity diagrams.
Control
node
type Description Icon
Activity This node represents a point
final where all flows in an activity
stop. An activity can have
several activity final nodes.
When the first activity final
node is encountered, all flows
stop and the activity
terminates.
Decision This node represents a point
in an activity where a single
incoming edge divides into
several outgoing edges. You
typically use constraints, also
called guard conditions, on
the outgoing edges to
determine which edge should
be followed.
Flow This node represents a point
final where one flow in an activity
terminates, but does not affect
the other flows in the activity.
Fork This node represents a point
in an activity where a single
incoming flow divides into
several outgoing flows.
Initial This node marks the point at
which flow begins when the
activity or structured activity
node is invoked. An activity
can have several initial nodes,
which means that several
flows with start when the
activity is invoked - one for
each initial node.
Join This node represents a point
in an activity where several
incoming flows are
synchronized into a single
outgoing flow.
Merge This node represents a point
in an activity where several
incoming edges come
together into a single
outgoing edge.
Object nodes
In activity diagrams, an object node is an abstract
activity node that helps to define the object flow in
an activity. An object node indicates that an instance
of a classifier might be available at a particular point
in the activity.
The following table describes the types of object
nodes that you can use to model object flow in
activity diagrams.
Object
node type Description Icon
Activity This node specifies the
parameter input and output parameters
for the activity.
Central This node consolidates data
buffer from several sources and
destinations. Central buffer
nodes do not connect
directly to actions.
Data store This node models data flow
in which the data is
persistent.
Input pin This node represents the
input parameters on an
action. The input pin holds
the input values that are
received from other actions.
Output pin This node represents the
output parameters on an
action. The output pin holds
the output values that an
action produces. Object
flow edges deliver the
output values to other
actions.
Value pin This node represents the
input parameter on an
action. The action is
enabled when the value pin,
which holds a specific
value, is evaluated. The
result of a "successful"
evaluation is the input to
the action.
Activity edges
In activity diagrams, an activity edge is a directed
connection between two activity nodes. When a
specific action in an activity is complete, the activity
edge continues the flow to the next action in the
sequence.
You can use two types of activity edges to model the
flow in activities:
• Control flow edges model the movement of
control from one node to another.
• Object flow edges model the flow of objects or
data from one node to another.
Typically, activity edges do not have names;
however, you can add a name to describe the
purpose of each edge.
As the following figure illustrates, an activity edge is
displayed as a solid line with an open arrowhead that
points in the direction of the flow.
Tip: You can specify a default style for the edges

that you add to activity diagrams in the Preferences
window, on the Activity Diagrams page.
Guard conditions on activity edges

You can add a guard condition to an activity edge
between two nodes, where the guard condition
defines a condition that must be satisfied before the
target activity node can be invoked. You can define
the guard condition in the following ways:
• name [guard condition] - The guard
condition is created and is assigned a name.
• [guard conditon] - The guard condition is
created, but is not assigned a unique name.
In the following figure, one activity node called
OpaqueAction is connected to a second activity
node, called OpaqueAction2. A guard condition,
called Guard1, specifies that the value of g coming
from OpaqueAction must be greater than 10 for
OpaqueAction2 to be invoked.
Activity diagrams:
1)Activity diagram of transfer of records:
recording
converting
sending records
to data base
reciving doc ument s

from data base
2)Activity diagram of checking the availability:
checking the
records
document found sending to

doctor
sending to
manager
3) Activity diagram of Tran scripting the records:
recives records
for transcription
transcripts the
records
sends for proof

reading
transcription
copmlete
4) Activity diagram of verifying the records:
reciving the
records
verifying the ordering for

records documentation
verification
complete
Activity diagram of documentation of records:
Docume ntati on Database Doctor
receiving the
records
Documenting
of records
Sending document
to database
Storing documents
in database
Receiving documents
from database
Statechart Diagram (STD)
Purpose
A statechart diagram (STD) describes the possible states
of a single class and the events that cause state transitions.
They are useful for showing the life cycle of the class.
Compared with activity diagram
Statechart and activity diagrams both describe state
transitions and share many of the same elements. An
activity diagram is most effective for describing processes
that involve more than one object.
Types of STDs
There are two kinds of STDs:
• One-shot life cycles describe objects with finite lives.
They have initial and final states:
o The initial state, in which the object is created, is
a solid circle.
o The final state, in which the object is destroyed,
is a bull's eye.
• Continuous loops describe objects that move through
a series of states. Where, how, and when the object is
created or destroyed is unimportant.
Contents
A state diagram defines:
• The external stimuli of the system: the events
• The values of objects: the states
• The changes of the object values: the transitions
More than one transition may leave a state. The first
event to occur causes the corresponding transition to
fire. Transitions are guarded by conditions, that is, an
event can only fire a transition if the condition of the
event is true. A condition is valid over an interval of
time.
• The messages sent to classes: the event messages
Activities and actions
You use activities and actions to describe the response of
an object to an event:
Associated
Operation Purpose timing
With
Relevant for Sequential or
Activity State control continuous; takes
purposes time to complete
Not relevant
Action Event for control Instantaneous
purposes
Decomposition of activities
You can define an activity further through graphical
decomposition. Opening an activity leads to another STD
that is the definition itself, or an AD.
An activity has a starting event, an ending event, and
possibly some intermediate events. A continuous activity
persists until an event terminates it by causing a transition
from the state. A sequential activity terminates by itself
after an interval of time.
Do not use super states to specify events or concurrency.
Specify these through decomposition diagrams. Use
decomposition to define activities as well. Each state in
the decomposition diagram represents one step of the
activity. The decomposition diagram is a one-shot
diagram with input and output transitions.
Example STD
A sample STD.
Control panel
The control panel for the STD.
States
State
A state represents an externally observable mode of
behavior that persists for a period of time. Activities can
run within a state. Transformations occur between states
rather than within a state. Use the State with internal
actions to add activities to a state.
Label
state-name
Initial state
The initial state is the first state of behavior of an object
after its creation.
Label
state-name
The label is optional and usually not supplied.
Final state
The final state is the last state of behavior of an object
before it expires or is destroyed.
Label
state-name[(parameter[,parameter...])]
The label is optional and usually not supplied.
State with internal actions
Similar to a state without internal actions, but allows you
add to the lower area of the symbol the activities initiated
during this state.
Label for the upper area

state-name
Label for the lower area
one or more event condition activity send-clauses
where
• event specifies an event name and optional
parameters:
event-name(parameter, parameter, ...)
• condition specifies a guard condition in brackets:
[ condition-text ]
• activity specifies a list of activities separated by
commas, where each activity has the syntax:
/[name1=|name1:=]name2[(parameter[,
parameter...])]
• send-clause has the syntax:
name1.name2[(parameter[, parameter. . .])]
Note: Multiple send-clauses use the following syntax:
^send-clause, send-clause. . .
This table shows example activities.
Syntax Examples explanation

entry/entry- Entering the
activity coins state. Activity
event/activity in(amount)/add that takes place
to balance inside the state.
exit/exit-activity Exiting the state.
Represents the
invocation of a
do/activity do/play dial tone
nested state
machine.
activity(parameter- XtRemoveGrab An activity that
list) asked to remove may arise during
a widget not on the existence of
the list (widget) the state. The
optional
parameter list
must be
enclosed in
parentheses;
separate
parameters with
commas.
Super State
A super state generalizes parts of a diagram. From
outside the diagram, you can treat the generalized
part as a single state.
States and transitions inside the super state are
connected to the outside via the super state only.
Transition arrows can be attached to the super state
from the inside and the outside. By nesting a
relatively autonomous part of a diagram in a super
state, you can reduce the number of transitions and
make the diagram easier to read.
Label
super-state
Concurrent state separators and State
regions
Horizontal and vertical concurrent state separators
can be used to create concurrent state regions in a
super state.
Label
Each region has one label: name
History state
A concurrent state region can contain one history
state and one deep history state. A transition to the
history state indicates that the object resumes the
state it last had in this state region. A history state can
have multiple incoming events/actions. It can have at
most one unlabeled outgoing events/actions, which
identifies the state to "resume" if the transition occurs
before the object has been in the state identified by
the state region.
You can move a history state, but only within its
concurrent state region. You cannot resize a history
state.
Label
No label.
Deep history state
A concurrent state region can contain one history
state and one deep history state. A transition to the
deep history state indicates that the object resumes
the state it last had at any depth within the state
region. A deep history state can have multiple
incoming events/actions. It can have at most one
unlabeled outgoing events/actions, which identifies
the state to "resume" if the transition occurs before
the object has been in the state identified by the state
region.
You can move a history state, but only within its
concurrent state region. You cannot resize a history
state.
Label
No label.
Events and Transitions
Transitions occur between two states
Transitions occur between two states:
• States (as source or target)
• States with internal actions (as source or
target)
• Superstates (as source or target)
• Start states (only as source)
• Final states (only as target)
• History states (as source or target)
Transition
An event causes (or fires) a change of state: the
transition. The arrow of the transition indicates the
order in which the states appear. A complete STD
specifies a state sequence that is caused by an event
sequence.
Label
event condition action send-clause
where
• event specifies an event name and optional
parameters.
event-name(parameter, parameter, ...)
Alternatively, the UML suite recognizes two special
event names: when and after. In this case, the event
name is followed by a boolean expression in
parentheses.
when (<boolean-expression>)
after (<boolean-expression>)
• condition specifies a guard condition in brackets.
[ condition-text ]
• action specifies a list of actions separated by
commas, where each action has this syntax:
/[name1=|name1:=]name2[(parameter[,
parameter...])]
• send-clause has this syntax:
name1.name2[(parameter[, parameter...])]
Note: Multiple send-clauses use the following syntax:
^send-clause, send-clause. . .
Complex transitions
You can use complex transitions to converge and
diverge transitions. Use the horizontal complex
transition to converge/diverge vertical transitions.
Use the vertical complex transition to
converge/diverge horizontal transitions.
Label
The label for a complex transition is the same as that
for a simple transition (see Transition).
Event Messages to Classes
Class
A class in an STD represents a class receiving an
event. It is connected to a transition by an event
message.
Label
name
Classes referenced in an STD must be defined in a
class diagram.
Event message
An event message sends a message to a class. In a
complete model, every event message corresponds to
an operation in a CD.
An event message always originates from an event
and ends at a class.
State Chart Diagram
1) State chart diagram for doctor
Creating
Request for conversion of records
Converting
Sending to database[if valid]

Sending
Receives if document is present
Receiving
2) State chart diagram for Database
check folder
[if present]
receiving
checking verifing
sends to manager transfers to doctor

sends
sending
3) State Chart Diagram for Manager
receiving
handling the records
monitoring
sends for transcription
sending
4) State Chart Diagram For Transcriptions
receiving
writing the solution for records
transcripting
t ranscripting for proof reading[if correct]
sending
5) State Chart Diagram For Proofreader
Verifies
Checks the records
Edits
Edits if there are mistakes
Orders
sends for documents

COMPONENT DIAGRAMS
In UML, component diagrams show the structure of

the software system, which describes the software
components, their interfaces, and their dependencies.
You can use component diagrams to model software
systems at a high level or to show components at a
lower, package level.
This type of diagram supports component-based
development in which a software system is divided
into components and interfaces that are reusable and
replaceable.
Component diagrams are useful for the following
reasons:
• Defining the executable and reusable aspects of
a software system
• Revealing software configuration issues through
dependency relationships
• Showing an accurate depiction of a software
application before you make changes or
enhancements
You can also use component diagrams to depict the
following physical parts of a software system:
• Source code files that you develop in an
integrated development environment
• Executable files that are necessary to deliver a
running system
• Physical databases that store information in the
tables of a relational database or in the pages of
an object-oriented database
• Adaptable systems that have components that
migrate for load balancing and failure recovery
Note: Component diagrams are distinct from
deployment diagrams. A component diagram defines
the composition of components and artifacts in the
system. A deployment diagram shows components
and artifacts in relation to where they are used in the
deployed system.
component diagrams:
Components
In UML modeling, components are model elements

that represent independent, interchangeable parts of
a system. They conform to and realize one or more
provided and required interfaces, which determine
the behavior of components.
Components make a system more flexible, scalable,
and reusable.
For a component to be replaceable, it must meet the
following criteria:
• The internal structure of the component must be
hidden. No dependencies can exist between the
contents of the component and other objects.
• Components must provide interfaces so that
external objects can interact it with them.
• The internal structure of the component must be
independent. The internal objects must have no
knowledge of the external objects.
• Components must specify their required
interfaces so that they have access to external
objects.
In models that depict executable systems,
components represent the components that are used
during the execution of the system. Examples
include COM+ objects, JavaBeans™, and Web
services.
A component usually takes the name of the part of
the system that it represents.
As the following figure illustrates, a component is
displayed in the diagram editor as a rectangle that
contains the name of the component. It also contains
a stereotype of «component» or a component icon,
which is a box with two small rectangles that
protrude from its side.
Component instances
In UML modeling, component instances are model
elements that represent actual entities in a system.
You typically use component instances in
deployment diagrams to represent implementation
units that exist at run time; however, you can also
use them in component diagrams.
The name of a component instance consists of an
underlined concatenation of the instance name, a
colon (:), and the component name; for example,
Shopper1:Cart.
As the following figure illustrates, a component
instance is displayed in the diagram editor as a
rectangle that contains the name and stereotype.
Example
You are developing an e-commerce application that
distributes components among the customer's Web
browser, a public Web server, and a private data
server. To specify on which device a specific
component (for example, the Cart component) runs,
you can create a deployment diagram with three
node instances: one for the computer running the
Web browser, another for the Web server, and a
third for the data server. You can then create a
deploy relationship between the Cart component
instance and the Web server node instance to
indicate that the component instance is run on the
Web server.
Packages
Packages group related model elements of all types,

including other packages.
You can group model elements in packages for the
following reasons:
• Organize the model elements so that the model
is easier to understand and to navigate in the
Project Explorer.
• Model the architecture of your system by using
packages to represent the various layers or
subsystems
Packages also represent namespaces, which means
that the model elements within a package must have
unique names. For example, if you validate a model
that has an actor named Customer and a class named
Customer in the same package, you will receive a
warning that conflicting names appear in the same
package. To prevent the warning, you can put the
Customer actor in another package.
You can use packages in several diagrams, including
class, component, and use-case diagrams. Each
package has a unique name that describes its
content.
As the following figure illustrates, a package is
displayed as a rectangle with a tab in the upper-left
corner. The rectangle contains the name of the
package and the package icon.
Note: The package shape also represents models and

subsystems. In this case, a keyword or graphic
symbol is displayed in the package shape.
Artifacts
In UML models, artifacts are model elements that
represent the physical entities in a software system.
Artifacts represent physical implementation units,
such as executable files, libraries, software
components, documents, and databases.
You would typically use artifacts in deployment
diagrams, but you can also use them in component
diagrams to show the model elements, such as
components or classes, that are manifested in the
artifact. Model elements can be manifested in
several different artifacts.
Artifacts are deployed on nodes and specify the
physical pieces of information that the deployment
and operation of a system uses or produces. Artifacts
can be supported for deployment on several kinds of
nodes.
about the attributes and operations of the artifact.
An artifact has a unique name that describes the file
or software component that it represents.
Interfaces
In UML modeling, interfaces are model elements

that define sets of operations that other model
elements, such as classes, or components must
implement. An implementing model element realizes
an interface by overriding each of the operations that
the interface declares.
You can use interfaces in class diagrams and
component diagrams to specify a contract between
the interface and the classifier that realizes the
interface. Each interface specifies a well-defined set
of operations that have public visibility. The
operation signatures tell the implementing classifiers
what kind of behavior to invoke, but not how they
should invoke that behavior. Many classifiers can
implement a single interface, each one providing a
unique implementation.
Interfaces support the hiding of information and
protect client code by publicly declaring certain
behavior or services. Classes or components that
realize the interfaces by implementing this behavior
simplify the development of applications because
developers who write client code need to know only
about the interfaces, not about the details of the
implementation. If you replace classes, or
components that implement interfaces, in your
model, you do not need to redesign your application
if the new model elements implement the same
interfaces.
You can specify the following types of interfaces:
• Provided interfaces: these interfaces describe the
services that instances of a classifier (supplier)
offer to their clients
• Required interfaces: these interfaces specify the
services that a classifier needs to perform its
functions and to fulfill its own obligations to its
clients
An interface typically has a name that reflects the
role that it plays in an application. A common
convention is to prefix the name of the interface with
a forward slash to indicate that a model element is an
interface.
As the following figures illustrate, the diagram
editor displays an interface in the following ways:
• Class rectangle symbol that contains the
keyword «interface». This notation is also called
the internal or class view.
Use the class shape when you need to model the

details of the interface. Compartments in the
class shape display information about the
attributes, operations, and signal receptions of
the interface.
• Ball and socket notation, in which the
implementation dependency from a classifier to
the provided interface is displayed as a circle
(ball) and the usage dependency from a classifier
to the required interface is displayed as a half-
circle (socket). This notation is also called the
external view.
Provided interface Required interface
(circle shape) (socket shape)
• Use the ball and socket notation, also called the
lollypop notation, when you need to model only
that provided and required interfaces exist.
. Relationships in component diagrams

defining the structure and behavior between model
elements.
categories:
Category Function
activities
element
element
you can use in component diagrams:
• Abstraction relationships
•
An abstraction relationship is a dependency

between model elements that represents the
same concept at different levels of abstraction or
from different viewpoints. You can add
abstraction relationships to a model in several
diagrams, including use-case, class, and
component diagrams.
• Association relationships
•
In UML models, an association is a relationship

between two classifiers, such as classes or use
cases, that describes the reasons for the
relationship and the rules that govern the
relationship.
• Implementation relationships
•
In UML diagrams, an implementation

relationship is a specialized type of realization
relationship between a classifier and a provided
interface. The implementation relationship
specifies that the realizing classifier must
conform to the contract that the provided
interface specifies.
• Realization relationships
•
In UML modeling, a realization relationship is a

relationship between two model elements, in
which one model element (the client) realizes
the behavior that the other model element (the
supplier) specifies. Several clients can realize
the behavior of a single supplier. You can use
realization relationships in class diagrams and
component diagrams.
• Usage relationships
•
In UML modeling, a usage relationship is a type

of dependency relationship in which one model
element (the client) requires another model
element (the supplier) for full implementation or
operation.
Component Diagram
Medical Transcript ion Services.ex e
transriptionist.hlp database.dll document.tbl

Deployment diagrams
In UML, deployment diagrams model the physical

architecture of a system. Deployment diagrams show
the relationships between the software and hardware
components in the system and the physical
distribution of the processing.
Deployment diagrams, which you typically prepare
during the implementation phase of development,
show the physical arrangement of the nodes in a
distributed system, the artifacts that are stored on
each node, and the components and other elements
that the artifacts implement. Nodes represent
hardware devices such as computers, sensors, and
printers, as well as other devices that support the
runtime environment of a system. Communication
paths and deploy relationships model the
connections in the system.
Deployment diagrams are effective for visualizing,
specifying, and documenting the following types of
systems:
• Embedded systems that use hardware that is
controlled by external stimuli; for example, a
display that is controlled by temperature change
• Client/server systems that typically distinguish
between the user interface and the persistent data
of a system
• Distributed systems that have multiple servers
and can host multiple versions of software
artifacts, some of which might even migrate
from node to node
Because deployment diagrams focus on the
configuration of the runtime processing nodes and
their components and artifacts, you can use this type
of diagram to assess the implications of distribution
and resource allocations.
Note: Deployment diagrams are distinct from
component diagrams. A deployment diagram shows
components and artifacts in relation to where they
are used in the deployed system. A component
diagram defines the composition of components and
artifacts in the system.
deployment diagrams:
Nodes
In UML modeling, nodes are model elements that

represent the computational resources of a system,
such as personal computers, sensors, printing
devices, or servers. Nodes can be interconnected, by
using communication paths, to describe network
structures.
Nodes can contain other nodes, called nested nodes,
and can also have artifacts deployed on them.
Typically, a node has a name that describes the piece
of hardware that it represents.
As the following figure illustrates, a node is
displayed as a three-dimensional rectangle that
contains the name of the node and the node icon.

about the attributes, deployed elements, nested
nodes, and internal structure of the node.
When you develop software for a distributed system,
you can model the different components on which
the system executes by using nodes in a deployment
diagram. For example, an e-commerce application
might have some software that runs on the client's
computer and some that runs on a public server.
These different components are represented by
nodes. The artifacts that each node deploys can be
listed in its Deploy compartment or are shown
explicitly with deployment relationships.
As the following figure illustrates, you can model
the client/server system with two nodes that are
connected by a communication path.
Stereotyped nodes
A node can be stereotyped to represent a specific
type of hardware. Several stereotyped nodes are
available in the Palette under Deployment Diagram.
You can also assign a stereotype to a node, and
replace the cube shape with a shape that resembles
the system component. For example, the following
figure shows how a node is stereotyped to represent
a mainframe computer.
As the following figure illustrates, you can model

the same client/server system, with two stereotyped
nodes that are connected by a communication path,
by using shapes that represent the specific system
components.
Node instances
In UML modeling, a node instance is a model

element that represents an instantiation, or actual
occurrence, of a node.
While a node represents a generic type of
computational device, a node instance represents a
specific and defined node in your system
environment. You can use node instances in
deployment diagrams to represent resources that
exist at run time. For example, you can use node
instances to represent a Web server and a data server
in a deployment diagram for an e-commerce
application.
Compartments display information about the
elements that are deployed on the node instance.
A node instance typically has a unique name that
consists of an underlined concatenation of the
instance name, a colon (:), and the node name; for
example: NodeInstance:Node.
As the following figure illustrates, a node instance is
contains the name of the node instance.
Artifacts
In UML models, artifacts are model elements that

represent the physical entities in a software system.
Artifacts represent physical implementation units,
such as executable files, libraries, software
components, documents, and databases.
You would typically use artifacts in deployment
diagrams, but you can also use them in component
diagrams to show the model elements, such as
components or classes, that are manifested in the
artifact. Model elements can be manifested in
several different artifacts.
Artifacts are deployed on nodes and specify the
physical pieces of information that the deployment
and operation of a system uses or produces. Artifacts
can be supported for deployment on several kinds of
nodes.
about the attributes and operations of the artifact.
An artifact has a unique name that describes the file
or software component that it represents.
As the following figure illustrates, an artifact is
displayed as a rectangle that contains the name of
the artifact. The rectangle also contains the
stereotype «artifact» and the artifact icon.
Artifact instances
In UML modeling, an artifact instance is a model

element that represents an instantiation, or actual
occurrence, of an artifact.
Different instances of an artifact can be deployed on
various node instances, and each artifact instance
can have separate property values.
An artifact instance typically has a unique name that
consists of an underlined concatenation of the
instance name, a colon (:), and the artifact type; for
example, Artifact3Instance:Artifact3.
As the following figure illustrates, an artifact
instance is displayed as a rectangle that contains the
name of the artifact instance.
Devices
In deployment diagrams, a device is a type of node

that represents a physical computational resource in
a system, such as an application server.
A device can consist of other devices; for example,
an application server contains a processor.
Although there is little difference between a device
and a node, the distinction can be more significant in
a profile that defines specific kinds of devices in a
particular environment.
attributes, deployed elements, nested nodes, and
internal structure of the device.
As the following figure illustrates, a device is
contains the device name and the device icon.
Execution environment
In UML modeling, an execution environment is a

type of node that represents a particular execution
platform, such as an operating system or a database
management system. You can use execution
environments to describe the context in which the
execution of a model takes place.
Execution environments are typically part of another
node that models the computing hardware of a
system. For example, an execution environment
within a server processor might provide the
operating system-level services that are required to
support a database application installed in that
environment.
internal structure of the execution environment.
As the following figure illustrates, an execution
environment is displayed as a three-dimensional
rectangle that contains a name and the execution
environment icon, which is a small rectangle with a
command prompt.
Execution environment
In UML modeling, an execution environment is a

type of node that represents a particular execution
platform, such as an operating system or a database
management system. You can use execution
environments to describe the context in which the
execution of a model takes place.
Execution environments are typically part of another
node that models the computing hardware of a
system. For example, an execution environment
within a server processor might provide the
operating system-level services that are required to
support a database application installed in that
environment.
internal structure of the execution environment.
As the following figure illustrates, an execution
environment is displayed as a three-dimensional
rectangle that contains a name and the execution
environment icon, which is a small rectangle with a
command prompt.
CoRelationships in deployment diagrams

defining the structure and behavior between model
elements.
categories:
Category Function
activities
element
element
you can use in deployment diagrams:
• Association relationships
• In UML models, an association is a relationship
between two classifiers, such as classes or use
cases, that describes the reasons for the
relationship and the rules that govern the
relationship.
• Communication paths
• In UML modeling, a communication path is a
type of association between nodes in a
deployment diagram that shows how the nodes
exchange messages and signals.
• Deploy relationships in UML
• In UML, deploy relationships specify that a
particular node type supports the deployment of
an artifact type.
• Generalization relationships
• In UML modeling, a generalization relationship
is a relationship in which one model element
(the child) is based on another model element
(the parent). Generalization relationships are
used in class, component, deployment, and use-
case diagrams to indicate that the child receives
all of the attributes, operations, and relationships
that are defined in the parent.
• Manifestation relationships
• In UML modeling, a manifestation relationship
shows which model elements, such as
components or classes, are manifested in an
artifact. The artifact manifests, or includes, a
specific implementation for, the features of one
or several physical software components.
Deployment Diagram
Database server
Doctor Documentation
Transcriptionist
Manager
Proof reader
Data flow diagram

A data-flow diagram (DFD) is a graphical representation
of the "flow" of data through an information system.
DFDs can also be used for the visualization of data
processing (structured design).
On a DFD, data items flow from an external data source
or an internal data store to an internal data store or an
external data sink, via an internal process.
A DFD provides no information about the timing of
processes, or about whether processes will operate in
sequence or in parallel. It is therefore quite different from
a flowchart, which shows the flow of control through an
algorithm, allowing a reader to determine what operations
will be performed, in what order, and under what
circumstances, but not what kinds of data will be input to
and output from the system, nor where the data will come
from and go to, nor where the data will be stored (all of
which are shown on a DFD).
Overview
It is common practice to draw a context-level data flow
diagram first, which shows the interaction between the
system and external agents which act as data sources and
data sinks. On the context diagram (also known as the
Level 0 DFD) the system's interactions with the outside
world are modelled purely in terms of data flows across
the system boundary. The context diagram shows the
entire system as a single process, and gives no clues as to
its internal organization.
This context-level DFD is next "exploded", to produce a
Level 1 DFD that shows some of the detail of the system
being modeled. The Level 1 DFD shows how the system
is divided into sub-systems (processes), each of which
deals with one or more of the data flows to or from an
external agent, and which together provide all of the
functionality of the system as a whole. It also identifies
internal data stores that must be present in order for the
system to do its job, and shows the flow of data between
the various parts of the system.
Data-flow diagrams were invented by Larry Constantine,
the original developer of structured design,[2] based on
Martin and Estrin's "data-flow graph" model of
computation.
Data-flow diagrams (DFDs) are one of the three essential
perspectives of the structured-systems analysis and design
method SSADM. The sponsor of a project and the end
users will need to be briefed and consulted throughout all
stages of a system's evolution. With a data-flow diagram,
users are able to visualize how the system will operate,
what the system will accomplish, and how the system will
be implemented. The old system's dataflow diagrams can
be drawn up and compared with the new system's data-
flow diagrams to draw comparisons to implement a more
efficient system. Data-flow diagrams can be used to
provide the end user with a physical idea of where the
data they input ultimately has an effect upon the structure
of the whole system from order to dispatch to report. How
any system is developed can be determined through a
data-flow diagram.
In the course of developing a set of levelled data-flow
diagrams the analyst/designers is forced to address how
the system may be decomposed into component sub-
systems, and to identify the transaction data in the data
model.
There are different notations to draw data-flow diagrams,
defining different visual representations for processes,
data stores, data flow, and external entities.[3]
Data flow diagram ("bubble charts") are directed graphs

in which the nodes specify processing activities and the
arcs specify data items transmitted between processing
nodes.
Developing a data-flow diagram
data-flow diagram example

Top-down approach
1. The system designer makes "a context level DFD" or
Level 0, which shows the "interaction" (data flows)
between "the system" (represented by one process)
and "the system environment" (represented by
terminators).
2. The system is "decomposed in lower-level DFD
(Level 1)" into a set of "processes, data stores, and
the data flows between these processes and data
stores".
3. Each process is then decomposed into an "even-
lower-level diagram containing its subprocesses".
4. This approach "then continues on the subsequent
subprocesses", until a necessary and sufficient level
of detail is reached which is called the primitive
process
DFD is also a virtually designable diagram that
technically or diagrammatically describes the inflow and
outflow of data or information that is provided by the
external entity.
• In Level0 the diagram does not contain any
Datastores
Event partitioning approach
A context level Data flow diagram created using Select

SSADM.
This level shows the overall context of the system and its
operating environment and shows the whole system as
just one process. It does not usually show data stores,
unless they are "owned" by external systems, e.g. are
accessed by but not maintained by this system, however,
these are often shown as extends
This level (level 1) shows all processes at the first level of

numbering, data stores, external entities and the data
flows between them. The purpose of this level is to show
the major high-level processes of the system and their
interrelation. A process model will have one, and only
one, level-1 diagram. A level-1 diagram must be balanced
with its parent context level diagram, i.e. there must be
the same external entities and the same data flows, these
can be broken down to more detail in the level 1, example
the "inquiry" data flow could be split into "inquiry
request" and "inquiry results" and still be valid.[5]
ENTITY RELATION DIAGRAM
In software engineering, an entity-relationship model
(ERM) is an abstract and conceptual representation of
data. Entity-relationship modeling is a database modeling
method, used to produce a type of conceptual schema or
semantic data model of a system, often a relational
database, and its requirements in a top-down fashion.
Diagrams created by this process are called entity-
relationship diagrams, ER diagrams, or ERDs.
Overview
The first stage of information system design uses these
models during the requirements analysis to describe
information needs or the type of information that is to be
stored in a database. The data modeling technique can be
used to describe any ontology (i.e. an overview and
classifications of used terms and their relationships) for a
certain area of interest. In the case of the design of an
information system that is based on a database, the
conceptual data model is, at a later stage (usually called
logical design), mapped to a logical data model, such as
the relational model; this in turn is mapped to a physical
model during physical design. Note that sometimes, both
of these phases are referred to as "physical design".
There are a number of conventions for entity-relationship
diagrams (ERDs). The classical notation mainly relates to
conceptual modeling. There are a range of notations
employed in logical and physical database design, such as
IDEF1X.
The building blocks: entities, relationships, and

attributes
Two related entities
An entity with an attribute
A relationship with an attribute
Primary key
An entity may be defined as a thing which is recognized
as being capable of an independent existence and which
can be uniquely identified. An entity is an abstraction
from the complexities of some domain. When we speak of
an entity we normally speak of some aspect of the real
world which can be distinguished from other aspects of
the real world.[3]
An entity may be a physical object such as a house or a
car, an event such as a house sale or a car service, or a
concept such as a customer transaction or order. Although
the term entity is the one most commonly used, following
Chen we should really distinguish between an entity and
an entity-type. An entity-type is a category. An entity,
strictly speaking, is an instance of a given entity-type.
There are usually many instances of an entity-type.
Because the term entity-type is somewhat cumbersome,
most people tend to use the term entity as a synonym for
this term.
Entities can be thought of as nouns. Examples: a
computer, an employee, a song, a mathematical theorem.
A relationship captures how two or more entities are
related to one another. Relationships can be thought of as
verbs, linking two or more nouns. Examples: an owns
relationship between a company and a computer, a
supervises relationship between an employee and a
department, a performs relationship between an artist and
a song, a proved relationship between a mathematician
and a theorem.
The model's linguistic aspect described above is utilized
in the declarative database query language ERROL,
which mimics natural language constructs.
Entities and relationships can both have attributes.
Examples: an employee entity might have a Social
Security Number (SSN) attribute; the proved relationship
may have a date attribute.
Every entity (unless it is a weak entity) must have a
minimal set of uniquely identifying attributes, which is
called the entity's primary key.
Entity-relationship diagrams don't show single entities or
single instances of relations. Rather, they show entity sets
and relationship sets. Example: a particular song is an
entity. The collection of all songs in a database is an
entity set. The eaten relationship between a child and her
lunch is a single relationship. The set of all such child-
lunch relationships in a database is a relationship set. In
other words, a relationship set corresponds to a relation in
mathematics, while a relationship corresponds to a
member of the relation.
Certain cardinality constraints on relationship sets may be
indicated as well.
Diagramming conventions
Entity sets are drawn as rectangles, relationship sets as
diamonds. If an entity set participates in a relationship set,
they are connected with a line.
Attributes are drawn as ovals and are connected with a
line to exactly one entity or relationship set.
Cardinality constraints are expressed as follows:
• a double line indicates a participation constraint,
totality or surjectivity: all entities in the entity set
must participate in at least one relationship in the
relationship set;
• an arrow from entity set to relationship set indicates a
key constraint, i.e. injectivity: each entity of the
entity set can participate in at most one relationship
in the relationship set;
• a thick line indicates both, i.e. bijectivity: each entity
in the entity set is involved in exactly one
relationship.
• an underlined name of an attribute indicates that it is
a key: two different entities or relationships with this
attribute always have different values for this
attribute.
Attributes are often omitted as they can clutter up a
diagram; other diagram techniques often list entity
attributes within the rectangles drawn for entity sets.

8 Medical Transcription

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

8 Medical Transcription

Uploaded by

Copyright:

Available Formats

PROBLEM STATEMENT

A problem statement is a class concise designation

In this srs of Medical Transcription, the problem

This process is requires less time if answers for

This is the document of the development life cycle

Medical transcription can also used to describe the

To create an online portal that provides a platform

• Uploading of encrypted voice files to a ftp site

• To view / approve the transcriptions

• To Batch print, convert to PDF

1.3 Definitions Acronyms & Abbreviations:

Interface: A connection between two devices or

Network: Describes the physical hardware and

Project: The combined resources (people, machines,

HTML: Hyper Text Markup Language

CN: Computer Network

TCP: Transport Communication Protocol

IP: Internet Protocol

UDP: User Data gram Protocol

Practice for Software Requirements

Specifications. IEEE Computer Society, 1998.

The rest of the SRS contains general description of

2.1 Product Perspective:

The Functions are:

• Login: This function takes the username and

• Functionality: This function contains the

As the every new system, users are strictly reluctant

2.4 General constraints:

The system must implement the constraints like

The system must complete the operation with in the

2.5 Assumptions & Dependencies:

3.1 Functional Requirements

3.1.1 Functional Requirement number 1:

3.1.3 Functional Requirement Number 3:

3.1.4 Functional Requirement Number 4:

3.1.4 Functional Requirement Number 5:

3.1.4.4 Output: The doctor will receive the answer

3.2 External Interface Requirements:

3.2.1 User Interface:

3.2.2 Hardware Interface:

3.2.3 Software Interface:

3.2.4 Communication Interface:

3.3 Performance Requirements:

• Throughput: Throughput is the rate at which

• Response Time: Response time is the elapsed

• Concurrent Users: The number of concurrent

• Portability: Portability is the ease with which

• Reliability: Reliability is the ability of the

• Availability: It is a measure of the time the

• Accuracy: It is qualitative assessment of

In internet medical transcription, security is a

The maintainability of this software is very easy.

The product on medical transcriptions must undergo

UML CLASS DIAGRAMS

A Unified Modeling Language (UML) class diagram

Unified Modeling Language (UML) classes are

You can use additional compartments to display

UML class diagrams

A Unified Modeling Language (UML) class diagram

In Unified Modeling Language (UML) class

C/C++ source code UML visualization

You can show, hide, or collapse the attribute

Operations in UML class diagrams