Design and Development of Information Systems (Part 1)

1
Design and Development of Information
Systems(Part 1)

• Yung-Fu Chen, Ph.D.
• Department of Health Services Management, China
  Medical University

2
Learning Objectives

• Discuss the stages
• Evaluate the strengths and
• Describe methodologies that
• State the purpose of data modeling
• Discuss the benefits of using
• Define the customary steps
• Describe the differences between

• Differentiate
• List and describe
• Describe he purpose
• Distinguish the various
• Describe two techniques for process modeling
• Identify the differences between
• Discuss the concept and benefits of
  object-oriented modeling

3
Outline

• Design and Development of Information Systems
• Systems Development Life Cycle
• New Approaches and New Tools
• Use of New Approaches for Analysis and Design
• Developing Data Model Diagrams

4
Systems Development Life Cycle

• Four stages for traditional SDLC
• System planning
• System development
• System implementation
• System operation

Table 5-1. SDLC
Initiation planning Request for system development Feasibility and cost benefits
Development System analysis and design Specification of functions Coding of computer program Testing of system
Implementation Development of system documentation User training System conversion
operation Operation of the system System maintenance System change/upgrade
5
Systems Development Life Cycle

• System analysis and design methodologies
• Model-driven approach
• Structure analysis
• Waterfall methodology
• Information engineering
• Object-oriented analysis
• Accelerated analysis technique
• Prototyping to identify user information and
  system needs

6
Systems Development Life Cycle

• Waterfall methodology
• One of the first approaches for information
  systems analysis and design
• Follows the SDLC in sequence, like water
  cascading over a waterfall
• A structured, model-driven, and process-oriented
  approach
• Documented by models such as data flow diagram
  (DFD) describing the system processes and their
  associated inputs, outputs, and storage needs

• Drawbacks
• Not including the development of IS based on an
  enterprise information model
• Extremely time-consuming. Using prototyping and
  RAD tools to help reduce the drawback
• Not sufficient emphasis on end-user input in the
  development process. Use of rapid prototyping,
  scenario-based development and JAD to help
  minimize this drawback
• Application development is performed with little
  or no consideration of the overlap between other
  existing applications and current projects

7
New Approaches and New Tools

• Information engineering
• Based on a holistic view of an enterprises
  information requirements, hence it is flexible
  and able to accommodate changes in organizational
  structure and/or changes in emphasis of the
  external environment.
• The modeling process considers the goals of the
  enterprise, identifies data requirements,
  identifies processes to be supported, and sets
  priorities for implementation
• Information models are represented in entity
  relationship diagram (ERD)

8
New Approaches and New Tools

• An outpatient clinic treats several patients per
  day. Each patient is seen by a primary-care
  provider. Each patient may also have ancillary
  services performed including laboratory,
  radiology, or other types of test

• Identify the various processes and groups of data
  required to support each process
• Processes include patient registration, patient
  examination, performance of diagnostic tests
• Various groups of data about
• the patient to support the registration,
  examination, and diagnostic processes, such as
  patients name, birthday, medical record number,
  and sex
• the visit, such as date of visit, time of the
  visit, chief complaint, final diagnosis, and
  disposition of the patient
• The primary-care provider who saw the patients,
  such as clinician name and clinician ID number
• The tests that the patient received, such as name
  of the tests, ID number of the test

• Represent information model in entity
  relationship diagram (ERD)
• An entity in defined as a person, place, thing,
  or concept about which data are gathered, such as
  patient, patient visit, primary-care provider,
  and tests
• Each ERD shows relationships between entities.
  For example, patient is related to patient visit
  (Figure 5-1)
• Data independent
• Data do not dependent on a specific application
  that all the data can be used by all applications

9
Figure 5-1 Simple Entity Relationship Diagram
The entity Patient is related to the entity
Patient Visit because every patient coming to the
clinic, hospital, or physicians office has a
patient visit.
10
New Approaches and New Tools

• Computer-aided software engineering tools
• Development of IS relies heavily on charts and
  graphics, such as DFD, ERD, data dictionaries,
  and other types of tables and schematics
• CASE tools are used to help with system analysis
  and design and the creation of such diagrams and
  models

11
New Approaches and New Tools

• Object-oriented (O-O) analysis
• The waterfall method is a structured method
  focusing on modeling and organizations processes
• IE modeling focuses on modeling the
  organizations data
• O-O analysis integrates modeling the
  organizations processes and data into objects
  that each integrates individual processes and data

12
New Approaches and New Tools

• Object-oriented (O-O) analysis
• An object include the operations or processes to
  perform on the data (properties), which an entity
  contains only data
• All objects are assigned to a class with the
  benefit that the subclass of objects inherits the
  properties of the high class

• Object models use the unified model language
  (UML) to provide standardized diagram techniques,
  syntax, and notation to make it easy to document
  system development
• Rational Rose (Rational Software)
• Visible Analyst (Visible System)
• Visual Studio (Microsoft)

13
Figure 5-2. Object-Orient Model

1. The objects Patient and Physician are assigned to
   the class Person.
2. One benefit of O-O analysis is that attributes
   and methods are not repeated separately for each
   object in a class. This makes updating or
   changing attribute and methods for a particular
   class or subclass much easier and ensures better
   consistency of data.

Object Class
Attributes
Methods/Behaviors
Physician
Patient
Provider Credentials Insert Provider Insert
Credentials Delete Provider Delete Credentials
Medical Record Insurance Co. Insert Medical
Record Insert Insurance Co. Delete Insurance Co.
14
New Approaches and New Tools

• Rapid application development
• Attempt to address the weaknesses of the
  traditional structured waterfall approach by
  using an interactive prototype approach to
  development and engaging end user in all parts of
  the process
• By using the following techniques, RAD can
  develop IS quickly
• JAD and other CASE tools and 4G visual language
• Getting the critical essentials of a project
  developed within a limited time period
• Adjusting the SDLC phases, RAD methodology

• Joint application development
• Provide an opportunity for substantial end-user
  input and speeds the development process
• Team consists of a group of end-users, analysts,
  and technique development professionals
• A trained facilitator develops the agenda (Table
  5-2) for the session and guides the discussion
• A report is presented by including all of the
  findings the as-is system, conformation of the
  to-be system goals and objectives, identification
  of new system functions, and determination of
  development phases and the timeline

15
Table 5-2. JAD Agenda

• Joint Application Design Session
• Nov. 8, 9_ _
• Clinical Registration and Application Scheduling
  System
• Facilitator Y. F. Chen Scribes A. M. Williams
• J. M. Ludwig
• R. J. Johns

Time Activity
Monday Monday
830 a.m. Welcome Overview of JAD session purpose Introduction of participants
900 a.m. Review of JAD agenda and group rules
930 a.m. Review of context and what we know
1030 a.m. Break
1050 a.m. Review of current as-is system
1230 p.m. Lunch
130 p.m. Continue with review of current as-is system
245 p.m. Break
300 p.m. Continue with review of current as-is system
430 p.m. Recap days session
500 p.m. Adjourn
Tuesday Tuesday
16
New Approaches and New Tools

• Phased approach
• A primary element is determining the phase of
  system development and priority
• Break the whole system into a series of smaller
  versions
• 1st version the most critical and fundamental
  requirements such as the admission-registration-tr
  ansfer (ADT) system
• 2nd version an order entry system
• 3rd version a results reporting system
• A strict time frame is placed on each phase

17
New Approaches and New Tools

• Prototyping
• allows for maximal user input and helps to speed
  up development process
• is an interactive process to develop the external
  features, such as design of screen, interaction
  between screens, and reports, of a system
• does not usually include a working database or
  actual program code, but only provides the touch
  and feel of the system to be designed

• needs CASE tools, such as 4GL, screen generators,
  code generators, and program templates, to speed
  up the development process
• has several benefits
• It increases end user involvement in the analysis
  and development process
• It can be developed quickly
• It provides the look and feel of the real system
  to be designed

18
Administrator
Practitioner
Patient
Client
Policymaker
Physician
Health Information Manager (Information Broker)
Chapter 4
Information Services

• Information Engineering
• Strategic Planning
• Data Modeling
• Process Modeling
• Data Administration
• Interface Design
• Screen
• Reports

• Information Retrieval
• Search Strategies
• Database Languages
• DSS Development
• DSS Use

• Information Analysis
• DSS Use
• Statistical Analysis
• Data Presentation

• Policy Development
• Security
• Information Engineering
• Information Retrieval
• Information Use

Chapter 5
Figure 4-1. Information Engineering Function
19
Use of New Approaches for Analysis and Design

• Data modeling
• Once the strategic planning efforts are
  completed, the process of data modeling will
  follow
• An example which describes the outcomes of the
  strategic planning for 350-bed acute-care
  hospital
• CSFs
• Provide quality care
• Have efficient operations
• Develop good physician relations
• Obtain optimal reimbursement and care mix
• Have a high perception of efficiency and service
  by various constituents
• Following the strategic planning process, the
  hospitals IS committee started to integrate the
  long-range IS plan with the business plan by
  developing IS that supported the monitoring and
  achievement of the CSFs
• Table 5-3 show a sample of IS matrix for the
  quality-of-care CSFs

20
Table 5-3. Quality-of-Care CSF and IS Matrix
CSF Measures Information System Functional Requirement
1. Quality of Care Complications Diagnostic index Tracking Trends Calculations Analysis
Incident report Tracking Trends Calculations Analysis
Mortality Morbidity Rates Diagnostic index Tracking Trends Calculations Analysis Projections
Infection control Tracking Trends Calculations Analysis Projections
Incident reports Tracking Trends Calculations Analysis Projections
Adverse patient event Diagnostic index Tracking Trends Calculations Analysis Projections
Incident report Tracking Trends Calculations Analysis Projections
Patient complaints Satisfactory survey Tracking Trends Calculations Analysis Projections
Incident reports Tracking Trends Calculations Analysis Projections
21
Use of New Approaches for Analysis and Design

• A definition of data modeling
• A model is defined as a small copy or imitation
  of an existing object
• Data model is used as the plan for building
  complex organization database.
• The models should describe how data flow, the
  requirements and usage of the data, and the
  attributes of the data
• Data modeling is the first essential step in
  ensuring successful database and application
  development
• Figure 5-3 represents data requirements of an
  emergency department encounter

• Categories of data models
• Conceptual data model (schema)
• defines the database requirements of the
  enterprise in a single database description
• is used as the basis for development of external
  and internal models
• External (logical) data model
• is the view of the data by a specific group of
  users or a processing application, such as
  admitting personnel, nursing service, HIM
  department, human resources, and central supply
  (Figure 5-4)
• Internal (physical) data model
• depicts how the data are physically represented
  in the database
• whose development concerns with data structures,
  file organizations, and mechanisms and techniques
  to most efficiently store data and make use of
  the DS

22
Figure 5-3. Conceptual Data Model of Emergency
Department
Patient
MR NO LName FName Gender DOB Street
Address Apartment City State Insurance No ZIP
Project Emergency Room
Encounter. Model ER_PROJECT Author John
Version 1 02/28/--
Conceptual Data Model
Professional Staff
Employed ID
Encounter
Encounter NO TimeArrival DateArrival ArrivalMode
ChiefComplaint Disposition DateDisposition TimeDis
position DischDX
Test-Treatment
Accession NO Test ID DTime Order DTime
Collect DTime Complete
Physician
DrNumber
23
Figure 5-4. Relationship Between Conceptual and
External Views
24
Use of New Approaches for Analysis and Design

• Content of a conceptual or business data model
• A business data model usually contains the
  following elements
• Diagram provides a picture of the data needs of
  the enterprise
• Glossary defines every name that is documented on
  the data diagram (Figure 5-5)
• Narratives help explain what the diagram and
  glossary mean, which are useful adjuncts to
  communicate to both users and developers what the
  data model diagram is trying to convey
• Access pattern is important for the physical
  database developer to know what data are
  accessed, how often these data are accessed, and
  in what order they are accessed

25
Figure 5-5Glossary Description
Name Patient Patient Patient
Code Pt Pt Pt
Description This entity describes the demographics of a patient treated by the Emergency Department This entity describes the demographics of a patient treated by the Emergency Department This entity describes the demographics of a patient treated by the Emergency Department
Attribute Name Code Type Length
Last Name LName Character 20
First Name FName Character 20
Middle Initial Minitial Character 1
Birth Date Bdate Date 6
26
Use of New Approaches for Analysis and Design

• Regardless of methodology, there are several
  common concepts shared
• All information is based on entities and
  relationships among them
• Additionally, an attribute is a fact or piece of
  information describing an entity
• The data model diagram names each entity, defines
  each entity by its attributes, and show
  relationships among various entities (Fig. 5-7)

• Data modeling methods and styles
• Popular data modeling methods (Figure 5-6)
• Chen entity relationship (ER)
• Information engineering (IE)
• Nijssens information analysis methodology (NIAM)

27
Figure 5-6Comparison of Conceptual Data Model
Notations
CHEN-ER Diagram
Information Engineering Diagram
Bubble Diagram
28
Figure 5-7Relationship Between Patient and
Emergency Encounter
Entity
ENCOUNTER NO ENCOUNTER DATE CHIEF
COMPLAINT ATTENDING MD NO
Emergency Department Encounter
Relationship
Attribute
29
Use of New Approaches for Analysis and Design

• Steps in the data modeling process
• Formation of the data modeling/planning team
• Determination of the planning tools that will be
  used
• Studying user requirements and defining these
  through the use of data modeling diagrams
• Development of the database design

30
Use of New Approaches for Analysis and Design
Steps in the data modeling process

• Formation of the data modeling/planning team
• The team will be composed of user
  representatives, IS analysts, and database
  specialists
• Must have support of top management
• Must have a clear understanding about the
  purpose, expected outcomes, and benefits of the
  projects

• 2. Determination of the planning tools that will
  be used
• CASE software helps create and compile various
  types of analysis tools, such as data flow
  diagrams (DFDs, see Fig. 5-8), data dictionaries
  (DDs), entity relationship diagrams (ERDs), and
  other charts, tables, and schematics
• CASE provides an convenient and effective
  mechanism to update data model diagrams, charts,
  and tables
• CASE imposes standardization
• CASE allows for automatic consistency checks

31
Figure 5-8Sample Data Flow Diagram
RegisterPatient
Transformation orOperation
Patient
External entity
Registration Data
RegisterPatient
Data flow
Admit Data
RegisterPatient
RegisterPatient
Order Sheet
History and Physical Progress Notes
Test Results
Patient File
Database
32
Use of New Approaches for Analysis and Design
Steps in the data modeling process

• 3. Defining user requirements
• Identify the scope of the project
• Collect data about the user requirements
• Adjuncts and aids in identifying user
  requirements
• Document data flows, data relationships, uses,
  and requirements

• 4. Development of the database design
• See the following Section and the following
  Chapter

33
Part 2Developing Data Model Diagrams
34
Developing Data Model Diagrams

• As mentioned in the previous section, Chen-ER,
  NIAM, and IE methods are popular methods for
  development of data model diagrams
• In this section IE method developed by James
  Martin is used to illustrate how a data model
  diagram may be developed because of its
  popularity, ease of use, and concept of top-down
  development

35
Developing Data Model DiagramsOutline

• Martin IE style
• Stage of the Martin IE method
• IE concepts and methods of notation
• Identifying primary entities
• Identifying relationships among entities
• Determining primary and alternate identifiers
• Determining non-key attributes
• Validating the model through normalization
• Determining alternate business rules
• Integrating the model with existing models
• Analysis for stability and growth

• A sample data modeling diagram project
• Translation of the conceptual data model to a
  physical data model
• Process modeling techniques
• Data flow diagrams
• Data flow diagram hierarchy
• Use cases
• Object-oriented modeling
• O-O modeling concepts
• Unified modeling language
• Benefits of O-O modeling

36
Martin IE style

• Stages of the Martin IE method
• 1. Information strategy planning
• Concerns how IS can support the strategic goals
  and how IT can be used to improve competitive
  position
• Technological opportunities are identified to
  support CSFs
• ISP includes the basic functions of the
  enterprise and produces an overview ERD of the
  enterprise, its departments, and its functions
• 2. Business area analysis
• CSFs determine (1) which business areas should be
  the top priorities for analysis (2) what are the
  processes and data necessary to make these unit
  operate optimally and (3) how do the work
  processes and data interrelate

• 3. System design stage
• Decomposition diagrams, DFDs, data structure
  diagrams, as well as screen and report layout are
  used at this stage
• 4. Construction of the system
• Use of code generator to generate computer code
• Supervision and control of transforming logical
  and physical design specifications to
  implementation of the physical system design
• Tasks include (1) developing an implementation
  schedule, monitoring and controlling
  implementation, creating programs and data
  structures, and developing user and program
  documentation

37
Martin IE style
IE concepts and methods of notation

• There are several mechanical steps in the
  development of a data model. Each should be done
  in sequence to help in developing a robust model
• Identifying primary entities
• Identifying relationships among entities
• Determining primary and alternate identifiers
• Determining all non-key attributes
• Validating the model through normalization
• Determining attribute business rules
• Integrating the model with existing models
• Analyzing the model for stability and growth

38
Martin IE style
IE concepts and methods of notation

• Identifying primary entities
• To develop a data model, entities must be
  identified, their attributes must be defined, and
  relationships between entities must be described
• An entity is anything about which data can be
  stored, which is usually a noun (Figure 5-9)

Figure 5-9. Entity Representation
39
Martin IE style
IE concepts and methods of notation

• Identifying relationships among entities
• Relationships are usually verbs
• Many different types of relations among data
• One-to-one (Fig. 5-10)
• One-to-many (Fig. 5-11)
• Many-to-many (Fig. 5-12)
• One-many-none (Fig. 5-13)
• One and only one (Fig. 5-14)

Figure 5-10. One-to-One Relationship
ID Number Name Sex Birthdate Address
Bed Number
Patient
Bed
40
Figure 5-12. Many-to-Many Relationship
Figure 5-11. One-to-Many Relationship
ID Number Name Sex Birthdate Address
Order ID Date Time
Patient
Order
ID Number Name Sex Birthdate Address
Order ID Date Time
Patient
Order
41
Figure 5-14. One and Only One Relationship
Figure 5-13. One-Many-None Relationship
ID Number Name Sex Birthdate Address
Test ID Test Name
Patient
Test
ID Number Name Sex Birthdate Address
Clinic ID Clinic Name
Patient
Clinic
42
Martin IE style
IE concepts and methods of notation

• Determining primary and alternate identifiers
• Primary key
• An attribute (or a set of attributes) that
  uniquely identify a particular occurrence of an
  entity (i.e. Medical Record in Table 5-4)
• Secondary key
• Attributes chosen as alternatives for identifying
  specific instances of an entity (i.e.
  LNAMEBDATESEX)

• Determining non-key attributes
• After primary and secondary attributes are
  identified, non-key attributes are identified
• Non-key attributes are descriptions that are
  associated with the entity
• Example STREET, ADDRESS, etc.

43
Table 5-4. Example of Entity Patient
Primary key
Primary key
Non-key attributes
Medical Record LNAME FNAME MINITIAL BDATE STREET ADDRESS CITY STATE ZIP SEX
893456 Brown John W 05-21-56 434 Oak Sunshine Ca 45678 Male
762345 Smith Mary J 03-21-60 8752 Palm Sunshine Ca 45678 Female
435678 Jones Susan J 01-03-72 7734 Citrus Sunshine Ca 45678 Female
256709 Castle Joseph E 04-08-66 7734 Citrus Sunshine Ca 45678 Male
44
Martin IE style
IE concepts and methods of notation

• Validating the model through normalization
• Normalization refers to how data items are
  grouped together
• Examining groups of data to determine structural
  redundancies or inconsistencies due to wrong
  assignments (i.e. associate lab test to
  patient rather than lab test

• Determining attribute business rules
• Business rules
• govern the integrity of an entity and determine
  certain properties or values that an attribute
  may have. For example, data type, length, format,
  uniqueness of value, allowable values, and
  default values
• Also refer to triggering operations which are
  rules that determine the correctness or
  incorrectness of data values

45
Martin IE style
IE concepts and methods of notation

• Integrating the model with existing models
• In practice, data models for different functions
  are developed in parallel or sequentially, hence
  inconsistencies and overlaps will occur during
  consolidation
• Consolidation of data model consists of comparing
  mappings and definitions of the models and the
  business conceptual schema

• Analysis for stability and growth
• Future significant changes should be incorporated
  into the data model so that it will need to be
  changed frequently and thus remain stable while
  still allowing for growth

46
A sample data modeling diagram project

• Mt. Pleasant Hospital has completed its strategic
  planning process and has identified five CSFs
• Provide quality care
• Have efficient operations
• Develop good physician relations
• Obtain optimal reimbursement and care mix
• Have a high perception of efficiency and service

• The Emergency Department was identified as a
  priority area because it was associated with all
  five CSFs
• There was room for improvement in the QOC
  provided in the ED
• The operations of ED were less than efficiency
• Attending physicians has complained on numerous
  occasions about ED inefficiencies
• Data for patient bill generation were not
  satisfactory
• Patient satisfaction surveys has indicated that
  patients who used the ED were less than favorable
  about wait times

47
A sample data modeling diagram project

• Steps in evaluating the ED
• To form a team of users, analysts, and database
  specialists to identify data flow in the
  department and result in the DFD appears in
  Figure 5-15
• To collect some demographic information about the
  patient care and flow in the ED
• To design the IS needed for ED support by
  reviewing the enterprise data model diagram, as
  shown in Figure 5-16
• The shaded part in Figure 5-17 shows the entities
  of interest for developing the ED IS
• Figure 5-18 provides a schematic of the principal
  entities, their relationships, and attributes
  that represent the ED functions

48
Figure 5-15 Data Flow of ED Process
Patients arrive either by walk-in or some other
ways (helicopter, ambulance, etc.)
1.0, 2.0, 3.0, 4.0, 5.0 indicates five department
entities represented with Level 0 DFD
49
Figure 5-16 Enterprise Data Model ED Conceptual
Schema
ED is an entity with a one-to-one relationship
with Mt. Pleasant hospital
Other entities related to the ED
50
Figure 5-17 Patient Encounter Relationships
The shaded parts show the entities of interest
for developing the ED IS
51
Figure 5-18 Conceptual ED Data Model

• Six entities
• Patient
• Payer
• Encounter
• Professional staff
• Physician
• Test/treatment

52
Interpretation of data model
Entity Interpretation of attributes and relationships
Patient The key attribute is medical record numbers. Other attributes include name, gender, birthdate, street address, apartment, city, state, insurance no., and zip. For each patient, there can be many encounters. For each patient, there can be many payers
Payer The key attribute for payer is payer ID. For each payer, there can be many patients. There is a domain table for payer that defines the acceptable values of the payer ID attribute.
Encounter The key attribute is encounter number. Other attributes include arrival date, arrival time, mode of arrival, chief complaint, disposition, discharge diagnosis, disposition date, and disposition time. For each encounter there is only one patient. For each encounter there may be none, one, or many professional staff. For each encounter there may be none, one, or many physicians. For each encounter there may be none, one, or many tests. For each encounter there may be none, one, or many treatments
Professional Staff The key attribute is staff ID number. There is a domain table associated with professional staff. For each professional staff there may be none, one, or many encounters.
Physician The key attribute is physician ID number. There is a domain table associated with physician. For each physician there may be none, one, or many encounters.
Test/Treatment The key attribute is test/treatment ID number. Other attributes include time ordered, time collected, and time completed. For each test/treatment there is only one encounter. There is a domain table associated with test.
53
Translation of the conceptual data model to a
physical data model

• Once the conceptual model diagram has been
  developed, it can be translated into a physical
  database design
• Translation steps
• Creating relationships in the physical design
• Translating into records, fields, and sets
• Implementing primary and secondary keys
• CASE tools can be used for this translation
• Figure 5-19 represents the physical database
  design for the ED example

54
Figure 5-19 Physical Data Model
55
Translation of the conceptual data model to a
physical data model

• Process modeling techniques
• In addition to data model, process model such as
  DFDs and use cases are needed for the technical
  development team.
• Data flow diagram
• Figure 5-15 is used to explain how a DFD is
  constructed and how it is used in the system
  development
• DFDs are used to analyzed and design the inputs,
  processes, outputs, storages, and control
  requirements of an IS
• Data flow diagram hierarchy
• All business processes are too complex to be
  defined in one DFD, hence most process models are
  composed of a set of DFDs
• Use cases

56
Translation of the conceptual data model to a
physical data model
Process modeling techniques

• Data flow diagram
• Logical DFD
• Models the processes that must be performed but
  does not tell how to be performed
• Physical DFD
• Specifies the details of a systems
  implementation
• DFD symbols and notation
• External entities
• Process
• Data store
• Data flow

External Entity
Process
Data Store
Data Flow
Figure 5-20. DFD Symbols and Notation
57
Translation of the conceptual data model to a
physical data model
Process modeling techniques

• Data flow diagram hierarchy
• DFDs successively break down the process until
  the most atomic parts of the process are
  described
• Context level The first DFD since it provides a
  summary of the overall system (Figure 5-21)
• Level 0 The next level of DFD. It shows all the
  processes at the first level (Fig. 5-15
• Level 1 Each process on the level 0 diagram is
  decomposed further in a level 1
• Level 2 process can be further broken into level
  2 and even level 3 diagrams
• Balancing principle information presented in a
  DFD at one level is accurately represented in the
  next DFD

58
Figure 5-21. Data Flow Context Diagram
Patient Data
Patient Data
Follow-up and Discharge Instruction
Current Patient Data
59
Translation of the conceptual data model to a
physical data model
Process modeling techniques

• Data flow diagram hierarchy
• Data flow diagramming
• Fig. 5-21 shows emergency room treatment at the
  context level
• Figure 5-15 is a Level 0 DFD, which is an
  exploration of the context level
• The DFD in Figure 5-15 would need to be exploded
  to a Level 1 diagram for each of various
  processes
• In constructing DFDS, there are a few conventions
  that must be considered (Figure 5-22)

• Combining DFDs and ERDs
• The ERDs define the nature and structure of the
  data base while DFDs defines the processes that
  must be supported by the IS
• Absence of the DFDs, it would not have the
  necessary information to write the software
  program code that would run the IS

60
Figure 5-22. Illegal DFD Construction
Data may not flow directly from an external
entity to a date store. A process that transforms
the data in some way must intervene.
Data may not flow from one store to another. A
process that transforms the data in some way must
intervene.
Data may not flow from an external entity to
another external entity. If no internal process
is performed on the data, the data flow should
not be represented in the DFD.
Data may not flow from a store to an external
entity. A process that transforms the data in
some way must intervene.
A black hole is a process or data that receives
input data but produces no output data. All
processes must have both input and output.
61
Translation of the conceptual data model to a
physical data model

• Use Cases
• A type of process modeling that originated in
  object-oriented modeling
• A set of activities that the system performs to
  produce some output result
• Scenarios of all the activities that are
  necessary to support a process
• In some instances, user case is developed instead
  of a DFD, while in others, as an adjunct to the
  DFD, providing more specific information

• Elements of the user case
• Descriptive name
• Identification number, which can correspond to
  the process number in the DFD
• Short description
• Trigger or event that causes the process or user
  case to begin
• Major input and outputs
• Major steps that need to be performed for each
  process
• Figure 5-23

62
Figure 5-23. Use Case Example
Use Case Name Register Patient Use Case ID Number 1.0 Use Case Name Register Patient Use Case ID Number 1.0
Short description The process registers a walk-in patient to the Emergency Department Short description The process registers a walk-in patient to the Emergency Department
Trigger Individual presents to the Emergency Department for Treatment Type External XX Temporal Trigger Individual presents to the Emergency Department for Treatment Type External XX Temporal
Major Input Major Output
Description Source Description Destination
Patient Demographic Data Patient Patient Demographic Data Patient
Patient Data Patient File Patient Insurance Data Patient File
Patient Insurance Data Patient Chief Complaint Patient File
Chief Complaint Patient Encounter Form Trigger Process
Major Steps Performed Major Steps Performed
1. Take the patients demographic data and check the Patient File to make sure that the patient has not been seen before in the Emergency Department 1. Take the patients demographic data and check the Patient File to make sure that the patient has not been seen before in the Emergency Department
2. If the patient has been seen before in the Emergency Department, then check demographic and insurance data to be sure that they are correct, and update as necessary 2. If the patient has been seen before in the Emergency Department, then check demographic and insurance data to be sure that they are correct, and update as necessary
3. If the patient has not been to the Emergency Department before. Then add patient demographic data and insurance and chief complaint data to the Patient file 3. If the patient has not been to the Emergency Department before. Then add patient demographic data and insurance and chief complaint data to the Patient file
4. Print out Encounter Form from the Patient File and place in the triage input box. 4. Print out Encounter Form from the Patient File and place in the triage input box.
63
Object-Oriented Modeling

• Incorporate both data and processes as the
  building blocks for systems analysis and design
• Object-oriented modeling concepts
• Object contain attributes (properties) and
  behaviors (methods or processes)
• Encapsulation addition of behaviors to an entity
  object
• Class is a template by which specific instances
  of an object can be created
• Inheritance subclasses inherit attributes and
  methods from their superclass
• Messages are information sent among objects that
  trigger behaviors
• Polymorphism means a specific behavior may be
  completed differently for different objects

• Unified modeling language
• Includes nine types of diagram user case, class,
  object, sequence, collaboration, state, activity,
  component, and deployment
• Process for performing O-O modeling
• Modeling functions
• Identify all business objects
• Develop a class diagram
• Model behavior of the objects
• Benefits of O-O modeling
• Integrates both data and processes
• Modularity allows the analyst to break the
  system into small, manageable pieces that can be
  combined to create a total system