Scribd
Upload
57 views12 pages

Design Document (SDA) Sec A

This design document outlines the software design and architecture for a hospital management system. It includes domain models, system sequence diagrams, sequence diagrams, collaboration diagrams, operation contracts, design class diagrams, state transition diagrams, and a data model. Key artifacts described include a system sequence diagram for patients getting appointments, sequence diagrams for patient flows, collaboration diagrams, operation contracts for taking appointments, checking vitals, and consulting doctors, design class relationships including composition, inheritance, and aggregation, and state transition diagrams for processes like taking appointments and consulting doctors. The document provides details on the object-oriented design for the system.

Uploaded by

Muhammad Taha Ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
57 views12 pages

Design Document (SDA) Sec A

This design document outlines the software design and architecture for a hospital management system. It includes domain models, system sequence diagrams, sequence diagrams, collaboration diagrams, operation contracts, design class diagrams, state transition diagrams, and a data model. Key artifacts described include a system sequence diagram for patients getting appointments, sequence diagrams for patient flows, collaboration diagrams, operation contracts for taking appointments, checking vitals, and consulting doctors, design class relationships including composition, inheritance, and aggregation, and state transition diagrams for processes like taking appointments and consulting doctors. The document provides details on the object-oriented design for the system.

Uploaded by

Muhammad Taha Ali
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

[DESIGN DOCUMENT]

[Software Design and Architecture]

Submitted By: Muhammad Taha Ali


Roll No: 20011598-004
Course code: SE-226 / SE-228
Semester: BSSE 4th Semester Section A
Submitted to: Ma’am Reema

AUGUST 14, 2022


BSSE
[email protected]
3.1. Introduction:
Third deliverable is all about the software design. In the previous deliverable, analysis of the
system is completed. So we understand the current situation of the problem domain. Now we are
ready to strive for a solution for the problem domain by using object-oriented approach. Following
artifacts must be included in the 3rd deliverable.

1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model

Now we discuss these artifacts one by one as follows:

3.2. Domain Model


Domain models represent the set of requirements that are common to systems within a product
line. There may be many domains, or areas of expertise, represented in a single product line and a
single domain may span multiple product lines.
3.3. System Sequence Diagram

The UML system sequence diagram (SSD) illustrates events sequentially input from an external
source to the system. The SSD will define the system events and operations. System sequence
diagrams are a timeline drawing of an expanded use case. Events are related by time with the top
events occurring first. System events are the important items. These are events that cause a system
response.

3.3.1. System Sequence Diagram of patient getting appointment

3.4. Sequence Diagram

A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of
methods in each object, and the order in which the invocation occurs is captured in a Sequence
diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic
behavior of a system.
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the
object that it represents, while on the vertical axis, it shows the sequence of the creation or
invocation of these objects.
Because it uses class name and object name references, the Sequence diagram is very useful in
elaborating and detailing the dynamic design and the sequence and origin of invocation of objects.
Hence, the Sequence diagram is one of the most widely used dynamic diagrams in UML.
3.4.1. Patients go to nursing staff Sequence diagram

3.4.2. Patient Consult Doctor & Doctor treat Patient Sequence Diagram
3.5. Collaboration Diagram
A collaboration diagram describes a pattern of interaction among objects; it shows the objects
participating in the interaction by their links to each other and the messages that they send to each
other.

3.5.1. Collaboration Diagram Taking Appointment and Checking Vitals


3.5.2. Collaboration Diagram Consult Doctor

3.6. Operation Contracts


A UML Operation contract identifies system state changes when an operation happens.
Effectively, it will define what each system operation does. An operation is taken from a system
sequence diagram. It is a single event from that diagram. A domain model can be used to help
generate an operation contract.
3.6.1. Contract: Take Appointment
Operation takeappointment()

Responsibilities Patients take appointment from receptionist

Cross Reference Use case: UC_take_appointment

Pre-condition Patient must have ID card. Patients need an appointment

Post-condition 1. Appointment confirmed (Instance Creation)


2. Add patient details at database (modification)
3. Patient go to nursing staff for vitals (Instance formed)

3.6.2. Contract: Check vitals


Operation checkvitals()
Responsibilities Nursing staff check vitals of patients
Cross Reference Use case: UC_check_vitals
Pre-condition Patient must have appointment.
Post-condition 1. Check vitals (Instance Creation)
2. Enter triage / vitals details at database (modification)
3. Assign doctor (Instance formed)

3.6.3. Contract: Consult Doctor


Operation consultdoctor()
Responsibilities Doctor treat patient
Cross Reference Use case: UC_consult_doctor
Pre-condition Vitals of patients will be checked.

Post-condition 1. Doctor treat patient (Instance Creation)


2. Doctor prescribe medicine and enter details on database
(modification)
3. Admit serious patient (Instance formed)

3.7. Design Class Diagram


Classes are the work-horses of the design effort—they actually perform the real work of the
system. The other design elements—subsystems, packages and collaborations simply describe
how classes are grouped or how they interoperate.
3.7.7. Design Class Relationships
Composition Relationship
Each instance of type Circle seems to contain an instance of type Point. This is a relationship
known as composition. It can be depicted in UML using a class relationship. Figure shows the
composition relationship.
Inheritance Relationship
A peculiar triangular arrowhead depicts the inheritance relationship in UML.
Aggregation / Association

3.8. State chart diagram


For some operations, the behavior of the operation depends upon the state the receiver object is in.

3.8.1. Take Appointment


3.8.2. Go for Vitals

3.8.3. Consult Doctor


3.9. Data Model

You might also like