Goals of System Modeling: - PDF Free Download

Goals of System Modeling: 1. To focus on important system features while downplaying less important features, 2. To verify that we understand the user s environment, 3. To discuss changes and corrections to the user s requirements at low cost and with minimal risk, 4. To verify that we have documented our understanding in a way that would allow others to construct/maintain the system. 1

Characteristics of Good Models: 1. Graphical, with support for detailed text descriptions: Picture is worth a thousand words à picture links to a thousand words. 2. Top- down partitionable: Globe à Continents à Countries à etc 3. Minimally redundant: Make changes in just one place in the model. 4. Transparent: Requires no expertise in model building to understand the model. 2

PFD vs. DFD vs. STD vs. ERD STD turns on DFD, Causes PFD to execute Start ERD Object A Activity 1 Object C Control Flow 1 Object A Function X Object B Decision? Object C Object C Activity 3 Activity 2 Objects C Object B Activity 4 ERD End 3

Modeling tools we will be using in this course: Context Diagram: Scope and boundaries of model. Data Flow Diagram: Movement of data and materials What? State Transition Diagrams: Transitions between system wait states - When? Process Flow Diagrams: Actions and decisions How? Entity Relationship Diagram: Information stores Which? Causal Loop Diagram: System cause and effect relationships. IBIS Analysis: Description of fuzzy decisions. Monte Carlo Simulation: Entity flow and resource utilization. Why do we need all these models?! 4

Different models reveal different aspects of the system we are modeling. Some are not as useful as others, but you may not know which is most useful when you start. 5

Where do we start?! An experienced system analyst approaching a new system is confronted with the same dilemma that a new system analyst faces: Where to start the analysis? This course introduces a number modeling and analysis tools and processes suitable for application to a wide range of systems. In terms of an optimal sequence of application of these approaches, the best answer is, of course: Apply them all at once! 6

Start With Genchi Genbutsu: Genchi genbutsu is a principal of lean thinking which roughly translates to: Go and see for yourself. A good place to start your system analysis is to go out and talk to current or perspective system users to see how things get done. As you interview people, you will be taking notes on what you hear and see. In this course, we capture this info in a basic process flow diagram, to which we add detail as we apply other modeling techniques to the system. The entity relationship diagram is another excellent tool for capturing this information. 7

Where should you start?! As you gain experience using different system modeling tools, you will, in fact, apply them all at the same time to capture a description of the system you are analyzing. However, with experience, you may find it beneficial to entity relationship diagrams first. This tool helps to systematically capture the information obtained through interviews in a standardized format. The tool also reveals gaps and inconsistencies in your description of the system that you will want to correct early in your analysis. But the ERD can be difficult to grasp, so we have delayed discussing it until after presenting some more (hopefully!) intuitive tools. 8

Simple Example Hospital System Model Here is a portion of your notes taken while interviewing staff in a hospital: Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. This simplified narrative description of a hospital system is derived from http://www.umsl.edu/~sauter/analysis/er/er_intro.html We will use the description to illustrate the primary elements of entity relationship (ER) models. 9

Simple Example Hospital System Model Here is a portion of your notes taken while interviewing staff in a hospital: Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. When creating an ER model, your primary focus is on on: Things (entities) in the system about which the system needs to store information, and What information needs to be stored for each entity. 10

Common types of entities about which systems need to store information: Tangible objects - MRI machine, lab report Roles played - Patient, doctor Organizational units - Ward, admissions Sites/locations - Factory, warehouse Events - Purchase, payment Relationship to DFD: - DFD models flow of data and materials, - ERD models stored information about data and materials. 11

Identifying Entities - Generally speaking, entities are nouns, so lets find some nouns in the text description of the hospital Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. That was easy! What next? 13

Attributes: We said that entities are elements of our system for which we need to store information. An entity s attributes are the individual items of information that we need to store. For example, a patient in the hospital has: Name Birth date Gender Height Weight Note that a patient also has a particular eye color, but this hospital system doesn t need to store this information, so it is not an attribute of this entity. 14

Key Attributes Often, different entities will have the same types of attributes. So, both patients and doctors have birth days, And a patient may even have the same birthday as their doctor. But every entity must have one attribute that uniquely identifies the entity. So, both patients and doctors may have social security numbers, But they never have the same social security number. Thus, for this system, social security number is a key attribute. It can t be that simple! What else do we need? 15

Relationships: Relationships describe how entities are related to one another, e.g. a doctor examines a patient, and a patient is examined by a doctor. To find relationships, just look for the verbs in your text description Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. 16

Note: Arena simulation software also uses the concepts of entity and attribute. Also, Arena resources are a kind of entity in ER diagrams. Don t worry about this stuff for now, let s just keep going Entities are the things that flow through the process we are modeling. They are the things that get worked on by the process. Different types of entities can be flowing through the process. Attributes are characteristics that are common to all entities of the same type. Entities may have many different characteristics, but attributes are just the ones that we care about in the model. For now, our entities have just two attributes: arrival time and service time. Resources are the things that do the work on the entities. Just as there can be multiple types of entities in a model, there can be multiple types of resources. More than one resource or one type of resource may be needed to work on an entity. 17

So what we know so far is that entity relationship models consist of: Entities, which have attributes, Relationships, which describe how entities are related to one another. All we need to do now is to convert all this into a diagram. So let s do it! 18

You may have already seen a simple form of ER diagram Structured (Indented) Bill- Of- Materials: Assembly Sub- Assembly 1 Component A Sub- Assembly 2 Component B Component C Assembly uses Sub- Assemblies 1, 2. Sub- Assembly 1 uses Components A, B, C This diagram simply describes the uses relationship between assemblies, sub- assemblies, and components. 19

Here s another simple form of ER diagram Org Chart: CEO Vice President of Marketing Vice President of Engineering Northeast Regional Sales Manager Southeast Regional Sales Manger VPs report to CEO Sales Managers report to VP of Marketing The org chart shows the report to relationships among staff positions. 20

Here s What Goes Into an ER Diagram: Entity (Object) Noun, things often grouped into sixclasses: Roles, events, locations, physical items, devices, organizational units. May be termed object. Relationship Verb (verb phrase) which describes how entities (objects) are related to one another, e.g. a doctor examines a patient, and a patient is examined by a doctor. Attribute Noun, which characterizes an entity, e.g. a doctor has a name, and examines a patient with a name. 21

Here is the General Form of an ER Diagram: Attribute 1.1 Entity 1 Relationship Entity 2 Attribute 2.1 A Attribute 1.2 Attribute 2.2 ER Diagrams have Entities, Relationships, and Attributes. Often times, Entities are termed Objects. 22

Here is an Example: Simple model of a patient- doctor relationship: Name* Name* Condition Patient Examined By Examines Doctor Specialty * Indicates a key attribute 23

Relationships are always bi- directional: Name Patient is examined by a Doctor Name Condition Patient Examined By Examines Doctor Specialty Doctor examines a Patient There is a simpler way to show this 24

Simplified notation: Name Arrow shows how to read relationship Name Condition Patient Examined By Doctor Specialty Patient is examined by a Doctor The arrow simply shows how to read the relationship. The arrow has nothing to do with flow, since nothing flows in an ER diagram. 25

Simplified notation: Name Arrow shows how to read relationship Name Condition Patient Examines Doctor Specialty Doctor examines Patient This diagram is exactly equivalent to the diagram on the previous slide. 26

Here is an even more simplified ER notation that we will use: Entity Relationship Attributes Doctor - Name* - Specialty Examines Patient - Name* - Condition Direction * Indicates a key attribute 27

In Visio, go here for ER diagrams It s convenient to draw simplified ER diagrams in Visio 28

My favorite ER shapes Entity 1 Attribute 1 Attribute 2 Relationship Entity 2 Attribute 1 Attribute 2 29

So now we know what the basic elements of an ER model are, And also the basic components of an ER diagram. Let s walk through the construction of a diagram using our hospital example 30

Identifying Entities - Noun, things often grouped into six classes: Roles, events, locations, physical items, devices, organizational units. May be termed object. Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. To help keep track of things, let s put this into a matrix format 31

Entity- Entity Matrix Step 1: Entities Patients Doctors Nurses Wards Beds Meds Patients Doctors Nurses Wards Beds Meds All we need to do here is go back to the narrative, pull out all the entities, and put them on the axes of the matrix. 32

Identifying Relationships: Relationships describe how entities are related to one another. To find relationships, just look for the verbs in your text description Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. 33

Entity- Entity Matrix Step 2: Relationships Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Dispense Now, we go back to the narrative, pull out all the verbs, and put them in the appropriate cells in the matrix. Note: We are just showing the relationships in one direction, so only half the matrix needs to be filled in 34

Here s our basic ER diagram in matrix form with entities and relationships: Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Dispense Patients are assigned to a ward, and are treated by doctors. Wards contain beds occupied by patients. Nurses work in a ward, where they attend to patients. Patients consume medications dispensed by nurses. 35

Here s our basic ER diagram in matrix form with entities and relationships: Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Dispense Hey! What s with these blank cells?! Are Doctors related to Meds? Are Wards related to Meds? What about all the other blank cells? 36

Entity- Entity Matrix Step 3: Validation Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Perscribe Dispense Stock Missed in original verbal description! Here are two relationships missed in the initial system description. An advantage of the matrix approach is that it allows thorough examination of all potential relationships. Now let s build the diagram! 37

Building the Diagram: Just for fun, let s pretend the doctor- patient relationship is the most important part of our system, so let s start there Patient Treated by Doctor Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Perscribe Dispense Stock 38

Building the Diagram: Nurses are pretty important, too, so let s add them next Patient Treated by Doctor Nurse Attended by Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Perscribe Dispense Stock 39

Now let s throw in Wards Assigned to Patient Treated by Doctor Ward Attended by Works in Nurse Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Perscribe Dispense Stock 40

Now add Beds Occupies Bed Contain Assigned to Patient Treated by Doctor Ward Attended by Works in Nurse Patients Doctors Nurses Wards Beds Meds Patients Doctors Treated by Nurses Attended by Wards Assigned to Work in Beds Occupy Contain Meds Consume Perscribe Dispense Stock 41

Now add Medications Bed Occupies Contains Assigned to Patient Treated by Doctor Ward Attended by Consumes Works in Nurse Dispenses Prescribes Stocks Medication So, that completes our basic ER diagram for our hospital system analysis. 42

This is the basic idea behind ER diagrams, now let s add some detail: Entity dictionary, Cardinality, Logical model vs. physical model, ER diagram rules, Many- to- many relationships. 43

Entity Dictionary: Earlier, we introduced a matrix notation to keep track of entities and relationships. You can see that showing attributes on an ER diagram can get quite cumbersome, so you may choose to show an entities attributes in a separate entity dictionary: Doctor - S.S. No* - Name - Specialty Hospital System Entity Dictionary Doctor S.S.No.* Name Specialty Patient S.S.No.* Name Condition 44

Cardinality Bed is occupied by only 1 patient at a time. We need to show cardinality of relationships Bed Contains Assigned to Occupies Patient Patient occupies only 1 bed at a time. Treated by Doctor Ward Attended by Consumes Works in Stocks Nurse Dispenses Medication Prescribes 45

Cardinality: In order to keep things clear and well- defined, a detailed ER diagram will include cardinality notation Entity Entity Entity Entity Exactly 1 (mandatory) One or more (mandatory) Zero or more (optional) Zero or one (optional) Here s an example 46

Example of Cardinality: Department Runs Supervisor Supervisors run departments. Staffed by Departments are staffed by employees. Employees work on projects. Employee Works on Project Now lets add cardinality 47

Here is an Example: Department Runs Supervisor One and only one supervisor runs one and only one department. Staffed by Can t have more than one supervisor running a department. Supervisor can t run more than one department. Employee Works on Project 48

Here is an Example: Department Runs Supervisor One or more departments are staffed by one or more employees. Staffed by Works in There is at least one person in each department. A person can work in more than one department, but must be assigned to at least 1 department. Employee Works on Project 49

Here is an Example: Department Runs Supervisor One or more employees work on zero or more projects. Every project has at least one employee. Staffed by Works in Some employees don t work on any projects. Employee Works on Project 50

Logical Vs. Physical Models Here is a good time to distinguish between logical and physical models. The logical model shows what could be, The physical model shows what actually is for a particular instance. For ER diagrams, cardinality converts logical models into physical models. What does that mean?! 51

Cardinality is Implementation Specific: Department Runs Supervisor One and only one supervisor runs one and only one department. Can t have more than one supervisor running a department. Supervisor can t run more than one department. Here, the business rules of a particular organization dictate that a supervisor can not run more than one department, so the physical model must reflect this cardinality. But in a logical model, the logical relationship between supervisors and departments doesn t specify how many supervisors run how many departments., so cardinality is not included. 52

Adding Cardinality to Hospital Model Bed Occupies Patient Treated by Doctor Contains Assigned to Consumes Prescribes Attended by Ward Works in Nurse Dispenses Stocks Medication 53

Cardinality Matrix: Showing cardinality on an ER diagram can get confusing, but, again, a matrix representation can help. Patients Doctors Nurses Wards Beds Meds Patients 0 or more 0 or more 0 or more 0 or 1 0 or more Doctors 1 or more 0 or more Nurses 1 or more 1 or more 0 or more Wards only 1 only 1 only 1 0 or more Beds only 1 1 or more Meds 0 or more 0 or more 0 or more 0 or more Note that we must show both ends of the relationship in this matrix: A bed can be occupied by 0 or 1 patients. A patient occupies only 1 bed at a time. 54

Some Rules for ER Diagrams: The entities in an ER diagram are things that you must store information on in order for the system to work. If you don t need the entity to make the system work, get rid of it. Do you really need to include information about janitorial services in your hospital ER? Entities can have many attributes, but you really only need to include the essential attributes relevant to entity- entity relationships. A patient s driver s license number is an attribute that probably doesn t effect the doctor- examines- patient relationship. Every entity must have a unique key attribute, that allows individual cases (instances) of the entity to be identified. If you can t tell individual cases apart, then whatever it is that you have identified is not an entity. 55

Some Rules for ER Diagrams: If you only have one specific case (instance) of an entity, you don t need to include it in the ER model. For example, if the hospital has only one doctor, you do not need to include Doctor in the ER model. If an entity has just one attribute, it may be that the entity can be included as an attribute of a different entity. Check all single- attribute entities for this possibility. 56

Some Rules for ER Diagrams: When identifying entities, eliminate: Synonyms (multiple names for the same entity) Homonyms (same name used for different entities). Synonym: Service Department calls them customers, and Help Desk calls them contacts, but they are the same people. Homonym: Market can be a geographical area to Sales Department and a demographic designation to Marketing Department. 57

Some Rules for ER Diagrams: Attributes and Relationships A natural way to decompose ER diagrams is to look for groups of entities which are not related to each other Entity A Entity B Entity C Entity X Entity Y Entity Z 58

Some Rules for ER Diagrams: Self- Referencing Relationships OK, well, what if a doctor examines themself? Wouldn t the doctor and patient have the same key attribute? Here s how to show self- referencing relationships: Doctor - S.S. No.* - Name - Specialty Examines Patient - S.S. No.* - Name - Condition 59

Some Rules for ER Diagrams: Multiple Relationships Entities may have multiple relationships. Here is an example: Examines Doctor Operates on Patient Many other rules for building good ER models exist. These can be found in the references and supplemental reading for this lecture. We will discuss one additional complication of ER diagrams 60

Multiple Relationships Between Multiple Entities Buyer Negotiates price Seller Real Estate Agent negotiates price with Buyer and Seller Real Estate Agent Buyer s Attorney Negotiates terms Seller s Attorney Real Estate Agent negotiates terms with Buyer s and Seller s Attorneys Many other rules for building good ER models exist. We will discuss one additional complication of ER diagrams 61

Critical Aspect of ER Diagrams: Many- to- Many Relationships It is necessary to eliminate many- to- many relationships in the model. A prime example is seen in our patient/doctor relationship in our hospital ER model Doctor - Name - Specialty Examines Patient - Name - Condition One or more doctors examine one or more patients. So, who examines who? 62

Resolving Many- To- Many Relationships The literature shows several ways to model many- to- many relationships, none of which is particularly elegant. But let s just reason this out how we could resolve this. The problem is that if you just say many doctors examine many patients you don t know which doctor examines which patient. One result of this is that the doctors don t know which patient to invoice! (Or just invoice them all and let the insurance companies sort things out, since they ll just deny coverage anyway). So, what must we add to the model to determine which doctor is examining which patient. 63

Resolving Many- To- Many Relationships: Old: Many doctors examine many patients Doctor - Name* - Specialty Examine Patient - Name* - Condition New: One or more doctors perform one and only one examination on a particular date and time. One and only one patient receives one and only one examination on the date/time. Add an Examination entity Doctor - Name* - Specialty Perform Examination - Date/Time* - Room Receives Patient - Name* - Condition 64

Resolving Many- To- Many Relationships: Doctor - Name* - Specialty Examine Patient - Name* - Condition In essence, we turned a relationship into an entity by giving it attributes. By adding the key attribute of Date/Time to the relationship Examine, we now know exactly which doctors examine which patients. Doctor - Name* - Specialty Perform Examination - Date/Time* - Room Receives Patient - Name* - Condition 65

Resolving Many- To- Many Relationships: Doctor - Name* - Specialty Perform Examination - Date/Time* - Room Receivies Patient - Name* - Condition Note that doctors in the hospital probably do not randomly walk around the hospital examining any patient they run across (how could they bill for that?!). Rather, they do probably examine patients at some specific time, but this was not shown in our original ER diagram. The point is that the identification of a many- to- one relationship in our model alerted us to a shortcoming to the model, which we subsequently corrected. 66

So why all the fuss over resolving many- to- many relationships? Well, if you have them in your model, this means one of two things: 1. Your model isn t complete and accurate, so you need to fix it. 2. The system you are modeling isn t well- designed. Consider the following 67

Many- To- Many Relationships Can Be Dangerous! Bed Occupies Patient Treated by Doctor Contains Assigned to Consumes Prescribes Attended by Ward Works in Nurse Dispenses What patients are consuming what medications?! Stocks Medication 68

So What?! Your initial introduction to the system that you are modeling will probably consist of interviews with system users. You need a way of systematically documenting this information and checking it for accuracy. ER diagrams provide one good way to accomplish these objectives, so constitute a tool that can assist in your early modeling efforts. That s why you may choose to apply this tool first. 69