MIS 3370 Exam 2

Written Use Cases

-Document containing detailed specifications for a use case -Contents can be written as simple text or in a specified format -Step-by-step description of what must occur in a successful use case

Rules for stopping decomposition

-When each process has been reduced to a single decision, calculation or database operation -When each data store represents data about a single entity -When the system user does not care to see any more detail -When every data flow does not need to be split further to show that data are handled in various ways -When you believe that you have shown each business form or transaction, online display and report as a single data flow -When you believe that there is a separate process for each choice on all lowest-level menu options

Functional decomposition

An iterative process of breaking the description of a system down into finer and finer detail, which creates a set of charts in which one process on a given chart is explained in greater detail on another chart. Continues until no sub-process can logically be broken down any further Primitive DFD is the lowest (Most specific) level of DFD

Context Diagram

An overview of an organizational system that shows the system boundaries, external entities that interact with the system, and the major information flows between the entities and the system It always contains ONE process and no data stores. Has a zero in the highlight section of the process symbol

Context of Process Modeling

Analysis (SDLC phase 2): SDLC phase in which system requirements are studied and structured • Involves determining how the current IS functions and assess what users would like to see in a new system Activities (parallel and iterative) - Requirements Determination (Chapter 6): Primarily factfinding - Requirements Structuring (Chapters 7-8): Creates a thorough, clear description of current business operations and new information processing service

Attributes

Attribute: Property or characteristic of an entity that is of interest to the organization • Examples for EMPLOYEE entity: Employee_ID, Employee_Name, Payroll_Address, Skill •Attribute names should be • Nouns • Unique • Standard format • Distinguishable from similar attributes of different entity types

Business Process Modeling

Business Process: Standard method for accomplishing a particular task necessary for an organization to function Business Process Modeling Notation (BPMN): Business process modeling approach established by the Object Modeling Group Always read left to right

Business Rules

Business rules: Specifications that preserve the integrity of the logical data model • Captured during requirements determination • Stored in CASE repository as they are documented • Implemented when creating the physical databases

Modeling Logic with Decision Tables

Decision table: Matrix representation of the logic of a decision which specifies the possible conditions for the decision and the resulting actions. • Best used for complicated decision logic. • Example given is a payroll system in an organization

Basic Notations

Event: Trigger that initiates the start of a process Activity: Action that must take place for a process to be completed Gateway: Decision point Flow: Shows the sequence of action in a process

Relationship Definition

Explain any optional participation • Explain the reason for any explicit maximum cardinality other than many Explain any restrictions on participation in the relationship Explain the extent of history that is kept in the relationship • Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

Type of messages

Simple message: Transfers control from the sender to the recipient without describing the details of the communication Synchronous message: Caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself Asynchronous message: Sender does not have to wait for the recipient to handle the message

Binary relationship example

Simplest relationship Degree n=2 Example: Captain Smith flies flight DL3412 • Captain Johnson flies flight UA443

Model

Simplified expression of observed or unobservable reality used to perceive relationships in the outside world. • A model is an approximation & entails assumptions -All models are wrong, but some are useful -A blueprint for designing databases

Gap Analysis

The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD Involves examining DFDs for 1. Redundant data 2. Data that are captured but not used 3. Data updated identically in more than one location DFDs of current logical system compared with DFDs of new logical system can show which processes need to be added or revised • DFDs in BPR: Help show inefficiencies in the existing system

Data Flow splitting

is when a composite data flow at a higher level is split and different parts go to different processes in the lower level DFD. The DFD remains balanced because the same data is involved, but split into two parts

Level-1 diagram

results from decomposition of Level-0 diagram The numbering in the process boxes differ from the N.0 state. Now they are N.1, N.2, N.3 example: Level - 0 has a process called 4.0 We dive deeper into that process and go to Level 1 which will use the 4.0 process. So now there will be multiple processes from the original 4.0 process to: 4.1, 4.2, 4.3 ..... These processes can be decomposed farther if necessary.

Remember

we go from Conceptual schema, logical schema and SQL code Data modeling happens throughout the SDLC

Naming and Defining Relationships

• A relationship name is a descriptive verb phrase • Avoid vague names • Ex: Assigned_to, not Assignment • A relationship definition: Explains what action is to be taken and possibly why it is important. Gives examples to clarify the action

Strong VS Weak entities

• A strong entity always exists • Professors (Dr. Skinner) always exist Subjects (SAD) always exist A weak entity only exists when based on a strong entity • A course - Section 1/3 of MIS 3360 - ONLY exists when a subject is taught by a professor •Represented by a double box

Naming and Defining Entity Types

• An entity type name should be a singular noun (STUDENT, not STUDENTS) Descriptive and specific to the organization (PURCHASE ORDER or CUSTOMER ORDER, not ORDER for both) • Concise Event entity type should be named for the result of the event, not the activity or process of the event (ASSIGNMENT for the event of a manager assigning an employee to a project)

Level-n diagram

A DFD that is the result of n nested decompositions from a process on a level-0 diagram Using example from above: This will be called Level 2 diagram. If we take process 4.3 and dig deeper into it we go into level 2. The processes would name numbered as 4.3.1, 4.3.2 and so on

For Conceptual Modeling, a noun is

A Data Entity

Model

All models are wrong, but some are useful Simplified expression of observed or unobservable reality used to perceive relationships in the outside world. • A model is an approximation & entails assumptions • Examples: • Model aircraft in wind tunnel testing • Mathematical models (econometric, optimization, etc.) • Computing models (e.g., analog models/directed graphs) • Data models, Process models, etc. • A blue print for designing databases

What three factors are in a concept model?

Data Entities Relationships Attributes

Deliverables and Outcomes

Entity-relationship Diagram (E-R-D): Entities (classes): They are the classes within a database

Object

: Entity with a well-defined role in an application domain with state, behavior, and identity characteristics (single occurrence of a class)

Object class

: Entity with a well-defined role in an application domain with state, behavior, and identity characteristics (single occurrence of a class)

Class Diagrams

: Shows the static structure of object classes, their internal structure, and the relationships in which they participate

Guidelines for Drawing DFD's

1. Completeness: Include all components necessary for the system Each component must be fully described in the project dictionary or CASE repository 2. Consistency: Information contained on one level of a set of nested DFDs should also be included on other levels Consistency Violation example: Level-1 DFD with no Level-0 DFD 3. Timing: Time is not represented well on DFD's Best to draw DFD as if the system has never started and will never stop 4. The iterative development: Expect to redraw diagram several times before reaching the closet approximation to the system being modeled Rule of thumb: Each DFD you draw should take about 3 revisions 5. Primitive DFDs: Stop drawing when you have reached the lowest logical level

What is the order for Data Modeling?

1. Conceptual Schema 2. Logical schema (logical) 3. SQL Code (Physical)

The level of DFD diagrams

1. Context DFD 2. Level 0 3. Level 1 4. Level 2 5. Level -n ....

Conceptual Data Modeling Process

1. Develop a data model for the current system (if system already exists) 2. Develop a new conceptual data model that includes all requirements of the new system 3. In the design stage, the conceptual data model is translated into a physical design via a logical design 4. Project repository links all design and data modeling steps performed during SDLC

Conceptual Data Modeling Process

1. Develop a data model for the current system (if system already exists) 2. Develop a new conceptual data model that includes all requirements of the new system 3. In the design stage, the conceptual data model is translated into a physical design via a logical design 4. Project repository links all design and data modeling steps performed during SDLC

Decision Table Procedure

1. Name conditions and values each condition can assume 2. Name all possible actions that can occur 3. List all possible rules 4. Define actions for each rule 5. Simplify the decision table

ER model purpose

Communication/presentation device used by a systems analyst to interact with the end-user community • A design tool at the highest level of abstraction to convey a deeper level understanding to the database designer to the users: what are the business rules? to the techies: How should the business rules be implemented in the database?

What are the three Data modeling stages?

Conceptual modeling Logical model/design Physical design

Modeling Logic with Decision Tables Vocab

Condition Stubs: The conditions relevant to a decision Action Stubs: The actions that result for a set of conditions Rules: Specifies which actions are to be followed for a set of conditions

Structuring System Data Requirements:

Definition/structure/relationships within the data • Entity-relationship diagrams • Class diagrams

Structuring System Data Requirements

Definition/structure/relationships within the data • Entity-relationship diagrams • Class diagrams

Ternary Relationship

Degree n = 3 example: Professor Knighton teaches the subject Database in course MIS3376.1 • Professor Knighton teaches the subject Database in course MIS3376.2 • Professor Skinner teaches the subject Database in course MIS3376.3 • Professor Skinner teaches the subject Database in course MIS3376.4 • Professor Parks teaches the subject Transaction Processing in course MIS4372.1

Unary Relationships

Degree n=1 aka recursive relationship A manager is just an employee that supervises other employees In this case, there is a "head nurse" that supervises other nurses • In relationships with 2+ degrees, multiple entities interact • With unary relationships, one entity interacts with itself Have the curve line

Degree of Relationships

Degree: the number of entity types that participate in a relationship Unary relationship: a relationship between the instances of one entity type • Also called a recursive relationship Binary relationship: a relationship between instances of two entity types • Most common type of relationship encountered in data modeling • Ternary relationship: a simultaneous relationship among instances of three entity types

Activity Diagram Purpose

Depicts the flow of control from activity to activity • Help in "use case" analysis to understand what actions need to take place • Help in identifying extensions to a "use case" • Model work flow and business processes • Model the sequential and concurrent steps in a computation process

Data Flow Diagram

Depicts the movement of data between external entities and the processes and data stores within a system

Conceptual Data Model

Detailed model that captures the overall structure of organizational data, independent of any database management system (DBMS) or other implementation considerations • First-cut model (starting point to building a database) • Typically occurs in parallel with other requirements analysis and structuring activities during systems analysis

Domains

Domain: Set of all data types and values that an attribute can assume Advantages • Verify that the values for an attribute are valid • Ensure that various data manipulation operations are logical • Help conserve effort in describing attribute characteristics

Benefits of Packaged Data Models

Dramatically reduced implementation times and costs • Starting point for asking requirements questions • Higher-quality models • Represents "best practice" data modeling techniques and data model components whose quality often exceeds that which can be achieved by internal development teams, given typical organizational pressures

Symbols for conceptual modeling

Entities are square boxes. Diamonds are relationships between entities. In a problem, identify nouns. These are your entities Then Identify verbs. These are your relationships Attributes can also be added into this diagram. It will give it more detail. Attributes symbols are circles and closed circles

Basic types of Busines RUles

Entity integrity: unique, non-null identifiers Referential integrity constraints: rules governing relationships between entity types Domains: constraints on valid values for attributes Triggering operations: other business rules that protect the validity of attribute values

Elements of ER modeling

Entity-Relationship data model (E-R model) • Detailed, logical representation of the entities, associations and data elements for an organization or business area • E-R Model is expressed in terms of: • Data entities in the business environment • Relationships or associations among those entities • Attributes or properties of both the entities and their relationships Entity-relationship diagram (E-R diagram) • Graphical representation of an E-R model • Purpose: To capture the richest possible understanding of the meaning of the data necessary for an information system or organization

Use case Relationships

Extend relationship: Association between two use cases where one adds new behaviors/actions to the other • Extends use case by adding new behavior/actions • Specialized use case extends the generalized use case • Arrow from use case X to use case Y indicates that X is a special case behavior of the more general process Y Include relationship: Association between two use cases where one uses the functionality contained in the other •Indicates a use case that is invoked by another • Links to general purpose functions, used by many other use cases • Arrow from use case X to use case Y indicates that X always involves at least one Y (X has a subtask Y) both use dotted arrows

DFD's vs. Flowcharts

Flowcharts: - Not very useful for depicting purely logical information flows - Criticized for being too physically oriented - Symbols primarily represent physical computing equipment DFD - Not as good as flowcharts for depicting the details of physical systems - Don't rely on symbols to represent specific computing equipment - Easier to use because they only involve 4 symbols

Supertype

Generic entity type that has a relationship with one or more subtypes

Process Modeling

Graphically representing the processes that capture, manipulate, store, and distribute information between a system and its environment and among system components Common form of process model: Data flow diagram

Data Model example

Horse : Entity type Name, color, Gender (lables): Attribute Name of horses: Entity Instances Entity class: Animal

Structuring System Process Requirements

How/where/when data is used/changed • DFDs • Use case diagrams • Activity diagrams • Sequence diagrams • BPMN

Structuring System Process Requirements:

How/where/when data is used/changed • DFDs • Use case diagrams • Activity diagrams • Sequence diagrams • BPMN

Deliverables of Process Modeling

Primary deliverable: Set of coherent, interrelated DFDs • Context DFD: Shows scope of system, indicating which elements are inside and outside the system • DFDs of the system (adequately decomposed): Show which processes move and transform data • Thorough description of each DFD component: Entries for all of the objects included in the DFDs

Guidelines for Defining Entity Types

Include a statement of the unique characteristic(s) for each instance of the entity type • Clarify what entity instances are included and not included in the entity type • Often includes a description of when an instance of the entity type is created and deleted • Some definitions must specify when an instance might change into an instance of another entity type • Some definitions must specify what history is to be kept about entity instances

Reduced Decision Table

Indifferent condition: A condition whose value does not affect which actions are taken for two or more rules. E.g. Hours worked for Salaried Employees

Activity Diagrams

Show the conditional logic for the sequence of system activities needed to accomplish a business process. Clearly show parallel and alternative behaviors. Can be used to show the logic of a use case.

Rule of thumb with DFD Decomposition

No DFD should have more than about 7 processes

DFD Symbols/ definitions

Process: Work or actions performed on data (inside the system). vertical square round shape with a highlight at the top Data store: Data at rest (inside the system), which may take the form of different physical representations. long rectangle shape with highlight at the left side Source/sink: External entity that is the origin or destination of data (outside the system). Just a rectangle. Sink receives data. Source gives data. Data flow: Data in motion, moving from one place in a system to another. arrows

Use Cases and Diagrams

Purpose: : Show a system's available top-level functions for different types of users Do not represent the order of system actions or the sequence of actions needed to complete a function

For conceptual modeling a verb is

Relationships

Other Attribute Types

Required attribute: an attribute that must have a value for every entity instance (symbolized by bold text) Optional attribute: an attribute that does not have to have a value for every entity instance (symbolized by normal text) Composite attribute: an attribute that has meaningful component parts (e.g. address(street, city, state, zip)) Derived attribute: an attribute whose value can be computed from related attribute values (e.g. [age] calculated from DOB)

What is the purpose Conceptual Data Modeling?

Show as many rules about the meaning and interrelationships among data as possible

Specialized Notations

Specialized event notation (such as from message, or at particular time) Specialized flow notation (sequence, default, or message flow Flow: sequence - arrow Flow: Default - Arrow with / Flow: Message - Dashed line with open circle

Elements of Activity Diagrams

Start: The beginning of a process (filled in circle ) Branch: A condition whose results provide transitions to different activity paths (diamond ) Activity: Behavior that an object carries out while in a particular state (rounded rectangle ) Merge: Where different paths converge (diamond) End: The end of a process (a filled in circle that has another circle around it )

Subtype

Subgrouping of the entities in an entity type • Meaningful to the organization • Shares common attributes or relationships distinct from other subgroupings

More elements Of Activity Diagrams

Swimlanes: Columns representing different organizational units of the system (vertical lines) Start: The beginning of a process (filled in circle) Activity: Behavior that an object carries out while in a particular state (rounded rectangle) Fork: Beginning of parallel activities (horizontal line with 2 arrows coming out of it) Branch: A condition whose results provide transitions to different activity paths (diamond) Merge: Where different paths converge (diamond) Join: End of parallel activities (horizontal line with 2 arrows coming into it) End: The end of a process (a filled in circle that has another circle around it)

More Terminology

System boundary: Includes all relevant use cases •Dividing line between the system and its environment •Use cases inside •Actors outside Connection: Depicts a usage relationship between an actor and use case •Does not indicate data flow •Actors connected to use cases with lines (not arrows) •Use cases connected to each other with arrows

DFD Guidelines

The inputs to a process are different from outputs of that process Objects on a dfd have unique names

Written Use Case Information definitions

Title: Descriptive name, matches name in use case diagram Primary actor: Usually a user role Stakeholders: Any group/individual with an interest in the function of the use case Precondition: Condition that must be satisfied in order to execute the use case Minimal guarantee: Outputs that can be expected if the service attempt fails Success guarantee: Outputs that can be expected if the service succeeds Trigger: Event/action that initiates a use case Main success scenario: Description of the sequence of interactions between an actor and a use case during the use case execution Extensions: Detailed description of how errors are handled

Types of Business Rules

Total specialization (double line): Each entity instance of the supertype must be a member of some subtype in the relationship. Partial specialization (single line): An entity instance of the supertype does not have to belong to any subtype, and may or may not be an instance of one of the subtypes. Disjoint rule (letter d): If an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype. Overlap rule (letter o): An entity instance can simultaneously be a member of two (or more) subtypes

Triggering Operations

Trigger: Assertion/rule that governs the validity of data manipulation operations such as insert, update and delete Includes the following components: -User rule: statement of the business rule to be enforced by the trigger -Event: data manipulation operation that initiates the operation -Entity Name: name of entity being accessed or modified -Condition: condition that causes the operation to be triggered -Action: action taken when the operation is triggered

Data modeling throughout the SDLC

True

Use Case Diagram Terminology

Use Case diagram: Depicts system behavior along with the key actors that interact with the system Actor: External entity that interacts with the system • Represents a single role, not a specific user • May represent many users • Most actors represent user roles, but some actors can be external systems Use case: Depiction of a system's behavior/functionality under various conditions as the system responds to requests from users Abstract use case: Type of use case that is initiated by another use case instead

Property Value Set

You define what the answer will be

Relationship

an association between the instances of one or more entity types that is of interest to the organization •Labeled with verb phrases

Cardinality of relationships

the number of entity instances associated with another entity • Optional participation: Minimum cardinality = 0 • Mandatory participation: Minimum cardinality > 0 Many: Maximum cardinality > 1 • Fixed number n (e.g., 1): Maximum cardinality = n example: • Professor Skinner teaches 0 to 1 classes - Optional participation with a maximum cardinality of 1. Optional One ("Prof Skinner teaches a minimum of zero classes and a maximum of 1 class") • SAD is taught by 1 to many professors - Mandatory participation with a maximum cardinality of many. Mandatory Many ("SAD is taught by a minimum of one professor and by a maximum of many professors")

Attribute Types

• Candidate key: Attribute (or combination of attributes) that uniquely identifies each instance of an entity type • Some entities may have multiple candidate keys Identifier: Candidate key that has been selected as the unique, identifying characteristic for an entity type - Identifiers are symbolized by a solid underline (Employee_ID) - Choose a candidate key that will not change its value - Choose a candidate key that will never be null • Multivalued attribute: May take on more than one value for each entity instance (example: {Skill})

Data Modeling Stages

• Conceptual modeling • Logical model/design • Physical design

Deliverables and outcomes of structing data modeling

• Entity-relationship (E-R) diagram (or UML class diagram) Entities (or classes) - categories of data, represented as rectangles •Relationships (or associations) - lines between the entities Set of entries about data objects to be stored in repository, project dictionary, or data modeling software •Repository links data, process, and logic models of an information system •Data elements included in the data flow diagram (DFD) must appear in the related data model and vice versa •Each data store in a process model must relate to business objects represented in the data model

Symbols for sequence Diagram

• Objects: Represented by boxes at top of diagram Lifeline: Time during which an object exists (dash line) Activation: Time period during which an object performs an operation (Vertical rectangle) Message: Means by which objects communicate with each other (horizontal line) Time: Early at the top of sequence diagrams and later at the bottom (vertical line on the side of the diagram)

Entities

• Person, place, object, event, or concept in the user environment about which the organization wishes to maintain data • Examples: EMPLOYEE, PRODUCT, REGISTRATION, ACCOUNT, COURSE, WAREHOUSE • Entity type (entity): Collection of entities that share common properties/characteristics (see examples above) • Entity instance (instance): Single occurrence of an entity type Symbol: square

Packaged Data Models

• Provide generic models that can be customized for a particular organization's business rules. • Universal data models are templates for • core subject areas (customers, products, accounts, documents) • and/or core business functions (purchasing, accounting, receiving) Industry-specific data models that are designed to be used by organizations within specific industries

Conceptual Data Modeling

• Purpose: Show as many rules about the meaning and interrelationships among data as possible • Conceptual data model: Detailed model that captures the overall structure of organizational data, independent of any database management system (DBMS) or other implementation considerations • First-cut model (starting point to building a database) • Typically occurs in parallel with other requirements analysis and structuring activities during systems analysis

Level

• Refers to degree of detail in the use case description • Suggested levels 1. White - as seen from clouds 2. Kite - "birds-eye view" 3. Blue - sea-level view 4. Fish - below sea-level 5. Black - bottom of the sea

Level-0 Diagram

• Represents a system's major processes (functions), data flows, and data stores at a high level of detail • Processes are labeled 1.0, 2.0, etc. • Processes will be decomposed into more primitive (lower-level) DFDs

Guidelines for defining attributes

• States what the attribute is and possibly why it is important • Should make it clear what is included and what is not included • Contains any aliases or alternative names • States the source of values for the attribute • Indicate: - If a value for the attribute is required or optional - If a value for the attribute may change - Any relationships that attribute has with other attributes

Types of BPMN Gateways

• XOR: Exclusive OR gateway; only one of the paths that exit the gateway can be followed AND: All of the paths that follow the gateway can be followed in parallel OR: At least one path out of the gateway must be followed, but all paths that leave the gateway can be followed

Sequence Diagrams

•Depicts the interactions among objects during a certain period of time • May be presented in either generic form or instance form: Generic form: Shows all possible sequences of interactions, corresponding to all scenarios of a use case Instance form: Shows the sequence for only one scenario

Interaction Diagrams

•Used to show interactions among objects for a particular use case Two types of interaction diagrams: • 1.Sequence diagrams: Show explicit sequencing of messages 2. Collaboration diagrams: Show relationships among objects

Balancing DFD's

•You must conserve inputs and outputs at the next level of decomposition • Example: Process 1.0 (in level-0 DFD) must have the same inputs and outputs when decomposed into a level-1 DFD • Balancing: Conservation of inputs and outputs when a process is decomposed to a lower level • Balanced means: 1. Number of inputs to lower level DFD equals number of inputs to associated process of higher-level DFD 2. Number of outputs to lower level DFD equals number of outputs to associated process of higher-level DFD