THE REPORT ENTITLED

HOSPITAL MANAGEMENT
Submitted By:
B. Bharath Kumar

HOSPITAL MANAGEMENT

Introduction to UML:
A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that we can understand

the system we are modeling. The main reasons for the modeling are: 1 2 3 4 5 Capture structure and technique. Show how system elements fit together. Keep design and implementation consistent. Hide or expose details as appropriate. Promote unambiguous communication.

Building blocks of UML:

*Things* *Relationships* *Diagrams*

Things in UML:
Structural things: things *Classes* *Interfaces* *Collaborations* *Use cases* *Active Classes* *Components* *Nodes Classes* Behavioral things: : *Interactions* *State machines* Grouping things: things *Packages* Annotational things: things *Notes*

Relationships in UML:
1. Dependency 9 2

2. Association 3. Generalization

Diagrams in UML:
The diagrams are the actual graphs that show model element symbols of a system. There are different types of diagrams to represent the systems functionality and behavior. system. Use Case Diagram: Diagram Class Diagram: software. Object Diagram: Diagram To illustrate the user intersection with the To illustrate logical structure. To illustrate the physical structure of the To shows the mapping of the To illustrate

Deployment Diagram: Diagram software- hardware. behavior.

Interaction Diagram = Sequence &Collaboration Collaboration: State Chart & Activity: :

To illustrate flow of event diagram.

Use-case Diagram: A use case diagram shows interactions of actors with a system in terms of functions called use-case. A use case is description of a functionality that the system provides. The actors are external to the system but who interacts with the system; they may be external persons, external system and hardware. Class Diagram: A class diagram shows the static structure of classes in the system. The classes represent the things that are handled in the system. Class can be related to each other in a number of ways: associated, dependent, specialized or packaged. Class represents attributes and operations. Object Diagram: An object diagram is a variant of the class diagram and uses almost identical notation. The difference between the two is that an object diagram shows a number of object instances of classes, instead of actual classes. Objects are written in rectangular box with their names. State Diagram: A state diagram is typically a component to the description of a class. It shows all possible states that the object of the class can have and which events cause the state to change. An event can be another object that sends a message to it. A change is called a transition. Sequence Diagram: A sequence diagram shows a dynamic collaboration between a numbers of 9 3

objects and shows an interaction between objects. Collaboration Diagram: It is similar to a sequence diagram however the relationships are only shown. If time or sequence of events is important then sequence diagrams are more relevant. Activity Diagram: An activity diagram shows a sequential flow of activities. This is typically used to describe the activities performed in an operation. Component Diagram: A component diagram shows the physical structure of the code in terms of code components .a component can be a source code component, a binary component or an executable component. A component contains information about logical class or classes it implements. Deployment Diagram: A deployment diagram serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components.

Software Requirement Specification

9 4

1. INTRODUCTION: 1.1. Purpose: -The purpose is for automation of Hospital Management. -It maintains two levels of users -Admission level -User level -Software includes -Maintaining patient details. -Providing prescription, Precautious and Diet advice. -Providing and maintaining all kinds of tests for a patient. -Billing and report generation. 1.2. Scope: It can be used in any hospital, clinic, dispensary or pathology labs for maintaining patient details and other test results. 1.3. Technology to be used It is a desktop application to be developed in VB6.0 having MS Access as background -Database Design (MS Access). -Form design (VB6.0).

2.OVERALL DESCRIPTION 2.1. Goals of proposed system: 1: Planned approach towards working: The working in the organization will be well planned and organized. The data will be stored properly in data stores, which will help in retrieval of information as well as its storage. 2: Accuracy: The level of accuracy in the proposed system will be higher. All operation would be done correctly and it ensures whatever information is coming from the center is accurate. 3:Reliability:The reliability of proposed system will be high due to the above stated reasons.The reason for increased reliability of system is that now there would be proper storage of information. 4: No Redundancy: In the proposed system utmost can would be that no information is repeated anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data stored. 5: Immediate Retrieval of information: The main objective of proposed system is to provide for a quick and efficient retrieval of information. Any type of information would be available whenever the user requires. 9 5

6: Immediate storage of information: In manual system there are many problems to store the largest amount of information. 7: Easy to operate: The system should be easy to operate and should be such that it can be developed with in a short period of time and fit in the limited budget of the user. 2.3. User Characteristics: Every user should be -Comfortable of working with computer. -He must have knowledge in medical field. -He must have basic knowledge of English too. 2.4. General Constraints : -GUI is only in English -login and password is used for identification of user and there is no facility of guest. 3. SPECIFIC REQUIREMENTS 3.1. External interface requirements: 3.1.1. User Interfaces : HTML 3.1.2. Hardware Interfaces: Keyboard, mouse. 3.1.3. Software Interfaces: Rational Rose, Windows. 3.2. Functional Requirements: 3.2.1. Login: The User needs to login providing there ID and password. 3.2.2. Edit Personal Info: Allows users to modify their details. 3.2.3. Search: Allows users to search for Doctors information and other people in the Hospital. 3.2.4. Logout: Allows the users to logout. 3.3 Non-Functional Requirements: 3.3.1 Performance Requirements: Static requirements: Any number of users can login and access. Dynamic requirements: Query processing time is 10ms. 3.3.2 Design Constraints: 1 Page is only in English. 9 6

2 Login and password is used for the identification of the user and there is no facility for the guest. 3 Limited to HTTP/HTTPS. 4 This system is working for a single server. 3.3.3 Attributes: System is reliable, dependable and interoperable.

USECASE DIAGRAM
DEFINITION: Use case Diagram is a collection of use cases, actors and relationships that exists between them. 9 7

Use-case diagrams graphically depict system behavior (use cases). These diagrams present a high level view of how the system is used as viewed from an outsiders (actors) perspective. A use-case diagram may depict all or some of the use cases of a system.

CONTENTS: A use-case diagram can contain: 1.Actors ("things" outside the system) Actors represent system users. An actor is someone or something that: *Interacts with or uses the system *Provides input to and receives information from the system

actor

2use cases (system boundaries identifying what the system should do) A more detailed description might characterize a use case as: A pattern of behavior the system exhibits A sequence of related transactions performed by an actor and the system Delivering something of value to the actor

usecase
3. Interactions or relationships between actors and use cases in the system including the associations, dependencies, and generalizations. Association Relationship: An association provides a pathway for communication. The communication can be between use cases, actors, classes or interfaces. Associations are the most general of all relationships and consequentially the most semantically weak. Association:

actor

usecase1

Generalization Relationship: A generalize relationship is a relationship between a more general class or use case and a more specific class or use case. A generalization is shown as a solidline path from the more specific element to a more general element.

actor1 actor3

a ctor2

Dependency Relationship:A dependency is a relationship between two model elements in which a change to one model element will affect the other model element.

<<include>>

place order

full customer order

<<extend>>

reorder stock

Use-Case Diagram for Hospital Management

< < e x te n d > > a d m is s io n s < < e x te n d > > B e d A llo tm e n t In c o m e d o c to r a p p o in tm e n t s R e c e p t io n is t t e s t a p p o in t m e n ts E x p e n d itu re U n d e rg o O p e ra t io n s F in a n c e M a n a g e m e n tS y s t e m

L o g in R e c o rd s S y s te m A d d D o c to r/s t a ff S t a ff/ N u rs e D ra w S a la ry D e le t e d o c to r/s t a ff

In H o u s e

E d it D o c to r/s t a ff

W a rd W is e B e d S ta t u s

In fo rm a t io n S y s te m D o c to rs P re s c rib e Te s ts A d m is s io n / d is c h a rg e R e p o rts

C o n s u lt a n t s P a t ie n tIn fo rm a t io n

USECASE DESCRIPTION

10

Usecases: 1. Admissions 2. Doctor Appointments 3. Tests Appointments 4. Bed Allotment 5. Undergo Operation 6. Login 7. Draw Salary 8. Add Doctor/Staff 9. Delete Doctor/Staff 10. Edit Doctor/Staff 11. Prescribe Tests 12. Ward Wise Bed Status 13. Admission/Discharge Reports 14. Patient Information

Actors: 1. Receptionist 2. Doctors 3. Staff/Nurses 4. Income 5. Expenditure 6. Records System 7. Information System
9 11

ADMISSIONS: This Module helps in registering information about patients and handles patients query. A unique ID is generated for each patient after registration. This helps in implementing customer relationship management and also maintains medical history of the patient. DOCTOR APPOINTMENTS: This Module Deals with, when the ID is generated the patient receives the Appointment time & number from the Receptionist and accordingly visit the doctor. TESTS APPOINTMENTS: This Module Deals with, when the ID is generated the patient receives the Appointment time & number from the Receptionist and accordingly undergoes the tests. BED ALLOTMENT: This Module handles with allotting the Bed to various patients by checking their ID. UNDERGO OPERATION: This Module handling with undergoes the various operations by diagnosing the patients. LOGIN: This Module checks whether the person is a Doctor/Staff and handles various activities such as draw Salary and give Salary. DRAW SALARY: This Module checks whether the person is a Doctor/Staff and draws salary based on the information. ADD DOCTOR/STAFF: This Module handles the activities such as adding Doctor/Staff information into the database. DELETE DOCTOR/STAFF: This Module handles the activities such as deleting Doctor/Staff information into the database. 9 12

EDIT DOCTOR/STAFF: This Module handles the activities such as editing Doctor/Staff information into the database. PRESCRIBE TESTS: This Module handles various activities such as Doctor Diagnoses the patient, gives treatment & gives suggestions to the patients, & prescribes laboratory tests & medicines. WARDWISE BED STATUS: This Module takes care of medical equipment, doctor visit, vitals recording, patient case sheet, diet ordering, blood requisition, transfer intimation and discharge intimation etc. It also deals with the maintenance of the wards, interand intra-ward transfers. ADMISSION/DISCHARGE REPORTS: This Module helps in generating patients discharge summary, which includes patients health at the time of discharge, medical history, various diagnosis and drug prescriptions, history of present illness and course in hospital. PATIENT INFORMATION: This Module helps in generating the patient information which is provided by doctor.

INTERACTION DIAGRAM
1. SEQUENCE DIAGRAM DEFINITION: 9 13

A sequence diagram is a graphical view of a scenario that shows object interaction in a time based sequencewhat happens first, what happens next. Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. There are two main differences between sequence and collaboration diagrams: Sequence diagrams show time-based object interaction; while collaboration diagrams show how objects associate with each other. The following tools located on the sequence diagram toolbox enable you to model sequence diagrams: Object: An object has state, behavior, and identity. The structure and behavior of similar objects are defined in their common class. Each object in a diagram indicates some instance of a class. An object that is not named is referred to as a class instance.

Message Icons: A message icon represents the communication between objects indicating that an action will follow. The message icon is a horizontal, solid arrow connecting two lifelines together.

1:

Focus of Control: Focus of Control (FOC) is an advanced notational technique that enhances sequence diagrams. It shows the period of time during which an object is performing an action, either directly or through an underlying procedure.

14

Sequence Diagrams for HospitalManagement

ADMISSIONS:

Patient

Registration

Incom e

Appointm ent

1 : create()

2 : inpatient()

3 : register()

4 : addApptCharges()

5 : date() 6 : tim e()

15

DOCTOR APPOINTMENTS:

Patient

Incom e

Appointm ent

TestsOperations

1 : ispatient() 2 : addApptCharges()

3 : date()

4 : tim e()

5 : docappt()

TESTS APPOINTMENTS: 16

Patient

Incom e

Appointm ents

TestsOperations

1 : inpatient()

2 : addTestCharges() 3 : date()

4 : tim e()

5 : testappt()

BED ALLOTMENT:

17

Registration

Incom e

Ward

Reports

1 : addWardCharges()

2 : allotBed()

3 : getnam e()

4 : dispWardStatus()

UNDERGO OPERATION:

18

Patient

Incom e

TestsOperations

1 : ispatient()

2 : addoprcharges()

3 : getOpr()

LOGIN:

19

Edit

DoctorStaff

Expenditure

1 : isDoctor()

2 : isStaff()

3 : drawSalary()

4 : giveSalary()

DRAW SALARY:

20

Edit

DoctorSatff

Expenditure

Incom e

1 : isDoctor()

2 : isStaff()

3 : drawSalary()

4 : giveSalary()

ADD DOCTOR/STAFF:

21

Edit

DoctorStaff

1 : isDoctor()

2 : isStaff()

3 : addDoctor()

4 : addStaff()

DELETE DOCTOR/STAFF:

22

Edit

DoctorStaff

1 : isDoctor()

2 : isStaff()

3 : delDoctor()

4 : delStaff()

EDIT DOCTOR/STAFF:

23

Edit

DoctorStaff

1 : isDoctor()

2 : isStaff()

3 : editDoc()

4 : editStaff()

PRESCRIBE TESTS:

24

DoctorStaff

TestsOperations

Reports

1 : addTestsCharges()

2 : getTests()

3 : AddisReport()

WARDWISE BED STATUS:

25

Patient

Ward

Reports

1 : isPatient() 2 : allotBed()

3 : bedStatus()

4 : dispWardStatus()

ADMISSION/DISCHARGE REPORTS:

26

Patient

TestsOperations

Reports

1 : isPatient()

2 : getTests()

3 : getOper()

4 : dispWardStatus()

5 : dispAddisReport()

PATIENT INFORMATION:

27

Patient

Registration

Reports

1 : isPatient()

2 : dispWardStatus()

3 : dispAddisReport()

4 : dispPattinfo()

2. COLLABORATION DIAGRAMS:
DEFINITION: Collaboration diagrams and sequence diagrams are alternate representations of an interaction. A collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction. A sequence diagram shows object interaction in a time-based sequence. Object: Definition: An object has state, behavior, and identity. The structure and behavior of similar objects are defined in their common class. Each object in a diagram indicates some instance of a class. An object that is not named is referred to as a class instance. Graphical Depiction

The object icon is similar to a class icon except that the name is underlined 9 28

Link: Definition Objects interact through their links to other objects. A link is an instance of an association, analogous to an object being an instance of a class. Adornments: You can document how objects see one another by specifying a visibility type on the general tab of the Link Specification or by selecting an item from the shortcut menu. Message/Event: Definition: A message is the communication carried between two objects that triggers an event. A message carries information from the source focus of control to the destination focus of control. Message Icons: Overview: A message icon represents the communication between objects indicating that an action will follow. The message icon is a horizontal, solid arrow connecting two lifelines together. Collaboration

Diagrams for Hospital Management::

ADMISSIONS:

1 : create() Patient Registration

3 : register()

2 : inpatient() 4 : addApptCharges()

5 : date() Appointm ent Incom e

6 : tim e()

DOCTOR APPOINTMENTS:

29

1 : ispatient() Patient Incom e

2 : addApptCharges() Appointm ent

3 : date() 4 : tim e()

5 : docappt()

TestsOperations

TESTS APPOINTMENTS:

3 : date() 1 : inpatient() Patient Incom e 2 : addTestCharges() Appointm ents 4 : tim e()

5 : testappt()

TestsOperations

BED ALLOTMENT:

30

2 : allotBed() Incom e Ward

3 : getnam e()

1 : addWardCharges()

4 : dispWardStatus()

Registration

Reports

UNDERGO OPERATION:

2 : addoprcharges() Incom e

1 : ispatient()

3 : getOpr()

Patient

TestsOperations

LOGIN:

31

3 : drawSalary() DoctorStaff

2 : isStaff() 4 : giveSalary()

1 : isDoctor() Edit Expenditure

DRAW SALARY:

3 : drawSalary() DoctorSatff Expenditure Incom e

4 : giveSalary() 2 : isStaff()

1 : isDoctor()

Edit

ADD DOCTOR/STAFF:

32

DoctorStaff

4 : addStaff()

3 : addDoctor()

2 : isStaff()

1 : isDoctor()

Edit

DELETE DOCTOR/STAFF:
D octorStaff

4 : delStaff()

3 : delD octor()

2 : isStaff()

1 : isD octor()

Ed it

EDIT DOCTOR/STAFF:

33

DoctorStaff

4 : editStaff()

3 : editDoc()

2 : isStaff()

1 : isDoctor()

Edit

PRESCRIBE TESTS:

Reports 3 : AddisReport()

TestsOperations

2 : getTests()

1 : addTestsCharges()

DoctorStaff

WARDWISE BED STATUS: 9 34

Reports

4 : dispWardStatus() 3 : bedStatus() Ward

1 : isPatient()

2 : allotBed()

Patient

ADMISSION/DISCHARGE REPORTS:

3 : getOper() 5 : dispAddisReport() TestsOperations Reports

4 : dispWardStatus() 2 : getTests()

1 : isPatient()

Patient

PATIENT INFORAMTION: 9 35

1 : isPatient() Patient Registration

2 : dispWardStatus()

3 : dispAddisReport() 4 : dispPattinfo() Reports

CLASS DIAGRAMS
DEFINITION: A class diagram shows the existence of classes and their relationships in the logical design of a system. CONTENTS: A class diagram contains: 1. Classes 2. Relationships 3. Interfaces 1) Classes: Definition: A class is a set of objects that share a common structure and common behavior (the same attributes, operations, relationships and semantics).

class
2) Relationships: Aggregate Relationship: 9 36

Definition: Use the aggregate relationship to show a whole and part relationship between two classes. The class at the client end of the aggregate relationship is sometimes called the aggregate class. An instance of the aggregate class is an aggregate object. The class at the supplier end of the aggregate relationship is the part whose instances are contained or owned by the aggregate object.

suplier A
Association Relationship:

cli ent

suplier B

An association provides a pathway for communication. The communication can be between use cases, actors, classes or interfaces. Associations are the most general of all relationships and consequentially the most semantically weak.

class1

association

class2

Dependency Relationship: A dependency is a relationship between two model elements in which a change to one model element will affect the other model element.

full order

place order

Generalize Relationship: Definition:A generalize relationship between classes shows that the subclass shares the structure or behavior defined in one or more super classes.

super class

subclass1

subclass2

37

Realize Relationship Definition: A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element.

class
operat ion()

interface

3) Interfaces Definition: An interface specifies the externally-visible operations of a class and/or component, and has no implementation of its own. An interface typically specifies only a limited part of the behavior of a class or component.

Class Diagram for Hospital Management

38

P a t ie n t id : In t e g e r n a m e : S t r in g a g e : In t e g e r a d d re s s : S t rin g s e x : S t ri n g a p p D a te : D a te

E d it a d d D o c t o r( a rg n a m e ) : In t e g e r d e lD o c t o r(i d : In t e g e r ) 1 ..* a d d s t a ff() : In t e g e r d e ls t a ff(id : In t e g e r ) e d it S t a ff(i d : In t e g e r)

E x p e n d it u r e a m o u n t : F lo a t B ill N o : In t e g e r g ive S a la ry (id : In t e g e r) E x p e n d i t u re () 1

1 ..*

C r e a t e (id : In t e g e r ) : In t e g e r Is p a t ie n t ( ) : B o o le a n 1 1 p a t ie n t R e g is t e r s 1 R e g is t ra t io n r e g is t e r( ) : In t e g e r a ll o t B e d (i d : In t e g e r) R e g is t ra t io n () 1

d ra w S a l a ry d o c t o r I n f o E d i t in g A p p o in t m e n t d t : D a te t m : T im e A p p o in t m e n t () 1 1..* T e s t O p e r a t io n s p a t i e n t Id : In t e g e r id : In t e g e r fl a g : In t e g e r 0 ..* I s s u e B i ll 1 D o c t o r S t a ff id : In t e g e r n a m e : V a rC h a r a g e : In t e g e r a d d re s s : V a r C h a r sex : Char s a la ry : F lo a t d ra w S a l a ry ( ) D o c t o r S t a ff( ) 1 g e n e ra t e s D is c h a rg e R e p o rt

T a k e s A p p o in t m e n t 1..* W a rd w a r d N o : In t e g e r n o B e d s : In t e g e r n a m e : V a rC h a r

o p a p p t () 1 t e s t a p p t () d o c A p p t() g e t t e s t s (i d : In t e g e r) : In t e g e r g e t O p e r (i d : In t e g e r) : In t e g e r T e s t O p e r a t io n s ( )

+ th e R e p o rts 1 R e p o rt s d is p W a rd S t a t u s () d is p A d d is R e p o rt (i d : In t e g e r) d is p p a t In fo (id : In t e g e r) R e p o rt s () 1

b e d S t a t u s ( ) : In t e g e r g e t N a m e (b e d N o : In t e g e r) : V a rC h a r W a rd ()

1 In c o m e a m o u n t : F lo a t b il N o : In t e g e r a d d T e s t C h a rg e s () : F l o a t a d d O p rC h a rg e s (id : In t e g e r) : F l o a t a d d A p p t C h a rg e s (id : In t e g e r) : F lo a t a d d W a r d C h a r g e s (id : In t e g e r) : F lo a t In c o m e ( )

d is p la y s P a t i e n t I n f o

39

ACTIVITY DIAGRAMS
DEFINITION: Activity diagrams provide a way to model the workflow of a business process. You can also use activity diagrams to model code-specific information such as a class operation. CONTENTS: Activity Diagram Tools: You can use the following tools on the activity diagram toolbox to model activity diagrams: Activities:An activity represents the performance of task or duty in a workflow. It may also represent the execution of a statement in a procedure.

Decisions: A decision represents a specific location on an activity diagram or state chart diagram where the workflow may branch based upon guard conditions.

End State:An end state represents a final or terminal state on an activity diagram or state chart diagram.

Start State:A start state (also called an "initial state") explicitly shows the beginning of a workflow on an activity diagram or the beginning of the execution of a state machine on a state chart diagram.

Swim lanes:9 40

Swim lanes are helpful when modeling a business workflow because they can represent organizational units or roles within a business model. Swim lanes are very similar to an object because they provide a way to tell who is performing a certain role. Swim lanes only appear on activity diagrams. Forks and Joins:A fork construct is used to model a single flow of control that divides into two or more separate, but simultaneous flows. Every fork that appears on an activity diagram should ideally be accompanied by a corresponding join. A join consists of two of more flows of control that unite into a single flow of control.

Activity Diagram for Hospital Management

status activity:

log-in

biometric scan

update dba about employee presence

employee log-out , giving his info. to dba

Login act: 9 41

start

enter id,password wrong id n password validating id n password

correct id n password

login

stop

Salary: 9 42

login

access database and get working hours of each employee

calculate salary of indivisual

transfer money to indivisual employee's account

Activity using swimlane diagram:

43

44

STATE CHART DIAGRAM

DEFINITION: State chart diagrams model the dynamic behavior of individual classes or any other kind of object. They show the sequences of states that an object goes through, the events that cause a transition from one state to another and the actions that result from a state change. States: A state represents a condition or situation during the life of an object during which it satisfies some condition or waits for some event. Transitions:A state transition indicates that an object in the source state will perform certain specified actions and enter the destination state when a specified event occurs or when certain conditions are satisfied. Each state represents a named condition during the life of an object during which it satisfies some condition or waits for some event. A state chart diagram typically contains one start state and multiple end states.

Start States: A start state (also called an "initial state") explicitly shows the beginning of a workflow on an activity diagram or the beginning of the execution of a state machine on a state chart diagram.

45

State Chart Diagrams for Hospital Management

PATIENT:

Enter Hospital

Takes Appointm ent

Undergo Diagnosis

Takes Treatm ent

not cured

Undergo lab Tests& Buy Medicines

gets cured

RECPTIONIST: 9 46

T a ke s De ta ils o s p a tie nt

C h e cks a v a ila b ilty o f do cto r

giv e s a pp o in tme n t

giv e s b ill

ta ke s b ill a mo un t

DOCTOR: 9 47

Diagonise patient

Gives Treatment

Prescribes Medicines & tests

Cures the patient

Overall:

48

A p p t . / a d m is s io n e n t ry / c h e c k i n g fo r a d m i s s io n o r a p p o in t m e n t a p p o in t m e n t a d m is s io n c h e c k in g d o c t e r s t a t u s fo r a p p o in t m e n t is s u e e ve n t re c e p t io n is t c h e c k in g d o c s t a t u s / d o c t e r a p p t . a va il a b l e B e d s ta tu s e ve n t re c e p t io n i s t c h e c k in g t h e fre e b e d o r lo b. b.y s t a t u s fo r a d m is s io n / . ( e m p ty be d s = 0 ) g ivin g a p p t . d o / c h e c k d o c te r s ta t u s ( E m pty beds = "N O N E " ) g ivin g a d m is s io n d o / g ive a d m i s s io n d a t a b a s e u p d a t in g e x it / u p d a t e c h a n g e .s. . t o d a t a b a s e

COMPONENT DIAGRAM
DEFINITION: 9 49

Component diagrams provide a physical view of the current model. A component diagram shows the organizations and dependencies among software components, including source code components, binary code components, and executable components. Component diagrams contain: Component packages: Component packages represent clusters of logically related components, or major pieces of your system.

Components: A component represents a software module (source code, binary code, executable, DLL, etc.) with a well-defined interface.

Interfaces:An interface specifies the externally-visible operations of a class and/or component, and has no implementation of its own. An interface typically specifies only a limited part of the behavior of a class or component. Dependency relationships: A dependency is a relationship between two model elements in which a change to one model element will affect the other model element.

Component Diagram for Hospital Management

50

E d it P a t ie n t

E xpen d it u re

D o c to r S t a ff

R e g is t r a tio n

A p p o in tm e n t T e s tO p e r a t io n s

W a rd In c o m e

R e p o rt s

DEPLOYMENT DIAGRAM::
DEFINITION: A deployment diagram shows processors, devices, and connections. Each model contains a single deployment diagram which shows the connections between 51 9

its processors and devices, and the allocation of its processes to processors. CONTENTS:Processor:A processor is a hardware component capable of executing programs.

Devices:A device is a hardware component with no computing power. Each device must have a name. Device names can be generic, such as "modem" or "terminal."

Connections:A connection represents some type of hardware coupling between two entities. An entity is either a processor or a device.

Deployment Diagram for Hospital Management

52

It a c c e p t s t h e re q u . .. a c ts a s G U I a n d a ls o . . .

c o n t a in s in fo o f p a t ie . . .

IS P s e rve r os

D a ta B a se

U s e rS y s te m

P r in t e r M e m o ry M o n it o r In p u t d e vi c e

E-R Diagram

53

age name

se x Addre ss

Seek appointmen t

Timin gs

Patient

Receptionist age salar y se x

Emp id

nam e

Working staff Checku p IS A Dra w sala ry

Doctor

Other staff timing s

Finance manager

Doc id

dept

Ente r stat us

Db admin

updat e

Data base

54