System Models

(read ch. 6)

A system model is an abstraction of the system being developed.

System models capture some aspect of the system using a particular (often graphical) notation. Different notations are better suited for modeling different aspects.

Regardless of the notation, a data dictionary is often used to store information about the names used in the model.

Data-Flow Models

Data-flow models, also called Data Flow Diagrams (DFDs) or Structured Analysis (SA), depict how information flows and where it is processed in the system.

Notation:

data transforms
show where information is processed or transformed. Also called bubbles.
data sources and sinks
show where information is produced and consumed in the system. Also called terminators, they typically represent entities external to the system being modeled, and often are not strictly sources or sinks.
data stores
show where data is stored in the system. Stores are typically abstractions of databases or files.
data flows
show how information travels between bubbles, stores and terminators. When labeled with a name and type, the type is the type of data traveling on the flow.

Example: a (partial) data flow diagram for the doctor's office IMS.

Data flow diagrams are hierarchical - a data transformation (bubble) can be decomposed into another DFD. This allows "top down" modeling of the system.

Example: A DFD for the Query Processor

In such a sub-DFD, the "off page" flows (those lacking either a source or a sink) must match the flows whose source or sink is the bubble in the original DFD that is being decomposed.

Two different kinds of data dictionaries could be used for this system. One defines all of the types for values traveling on the flows:

type definition
apt_type tuple of (date: string, start_time:time_type, end_time:time_type, doctor:name_type)
name_type string
patient_type tuple of (patient_num:integer, name:name_type, doctor:name_type, address:string, phone_num:integer)
req_type tuple of (patient_num: integer, doctor: name_type)
time_type tuple of (hour: integer, minute:integer)

Another type of data dictionary describes all of the of the bubbles, terminators, stores and flows:

name type description
delete_apt flow carries requests to delete appointments from the query processor to the schedule
office staff terminator shows where office staff members can request service from the system
schedule data store stores all patient appointments
query processor bubble processes user input and makes changes or fetches information from data stores

Advantages of data-flow models:

Disadvantages of data-flow models:

Semantic Data Models

Relational Data Models

Example:

patient
patient_num name address phone
7 Linda E-258 6088
92 Tim E-258 6085
87 Pumba Dillsburg null

doctor
name speciality address office_num phone office_phone
Craig orthopedics Mechanicsburg null null null
Cheryl infectious disease Mechanicsburg null null null

appointment
patient_num doctor_name date start_time end_time
7 Craig 9/16/1996 10:00 a.m. 10:30 a.m.
87 Cheryl 9/20/1996 6:00 p.m. 6:15 p.m.

A data dictionary would be associated with this model to describe all tables and attributes.

Advantages of relational data models:

Disadvantages of relational data models:

Entity Relationship Models

In an inheritance relationship, the inheriting entity set has all of the attributes of the inherited from entity set.

Notation:

An E-R Diagram for the person information stored by the Doctor's Office IMS:

Advantages of entity relationship models

Disadvantages of entity relationship models