chapter 9: structuring system requirements: conceptual data modeling conceptual data modeling 1.1...

CHAPTER 9:CHAPTER 9:Structuring System Requirements:Structuring System Requirements:

Conceptual Data ModelingConceptual Data Modeling

1.11.1

MSIS 5653MSIS 5653Advanced Systems DevelopmentAdvanced Systems Development

Dursun Delen, Ph.D.Dursun Delen, Ph.D.Department of ManagementDepartment of ManagementOklahoma State UniversityOklahoma State University

D. Delen MSIS 5653 – Advanced Systems Development

Learning ObjectivesLearning Objectives Define key data modeling terms

Entity type Attribute Multi-valued attribute Relationship Cardinality Business Rule Associative entity Trigger Super-type, Subtype

10.210.2


Learning ObjectivesLearning Objectives Learn to draw Entity-Relationship (E-R) Distinguish between unary, binary, and ternary

relationships, and give an example of each Define four basic types of business rules in an

E-R diagram Explain the role of CASE technology in the

analysis and documentation of data required in an information system

Relate data modeling to process and logic modeling as different views describing an information system

10.310.3


Structuring System Requirements Structuring System Requirements in SDLCin SDLC


Conceptual Data ModelingConceptual Data ModelingConceptual Data Model: “A detailed model that captures

the overall structure of organizational data” Purpose is to show rules about the meaning and the interrelationships among dataEntity-Relationship (E-R) diagrams are commonly used to show how data are organizedMain goal of conceptual data modeling is to create accurate E-R diagramsMethods such as interviewing, questionnaires and JAD are used to collect informationConsistency must be maintained between process flow, decision logic and data modeling descriptions

10.510.5


Process of Process of Conceptual Data ModelingConceptual Data Modeling

First step is to develop a data model for the system being replaced

Next, a new conceptual data model is built that includes all the requirements of the new system

In the design stage, the conceptual data model is translated into a physical design

Project repository links all design and data modeling steps performed during SDLC

10.610.6


Relationship between Data Relationship between Data Modeling and the SDLCModeling and the SDLC


Deliverables and OutcomeDeliverables and OutcomePrimary deliverable is the entity-relationship (E-R) diagrams

There may be as many as 4 E-R diagrams produced and analyzed during conceptual data modeling:

1. Covers just data needed in the project’s application

2. E-R diagram for system being replaced

3. An E-R diagram for the whole database from which the new application’s data are extracted

4. An E-R diagram for the whole database from which data for the application system being replaced is drawn

10.810.8


Figure 10-3Figure 10-3Sample conceptual data model diagramSample conceptual data model diagram

10.910.9


Deliverables and OutcomeDeliverables and OutcomeSecond deliverable is a set of entries about data objects to be stored in repository or project dictionary

Repository links data, process and logic models of an information system

Data elements that are included in the DFD must appear in the data model and visa versa

Each data store in a process model must relate to business objects represented in the data model

10.10

10.10


Gathering Information for Gathering Information for Conceptual Data ModelingConceptual Data Modeling

Two perspectives1. Top-down

Data model is derived from an intimate understanding of the business

10.1110.11


Gathering Information for Gathering Information for Conceptual Data ModelingConceptual Data Modeling

Two perspectives (Cont.)2. Bottom-up Data model is derived from the process of reviewing business

documents

10.1210.12

ORDER NOCUSTOMER NO

NAMEADDRESSCITY-STATE-ZIP

ORDER DATEPROMISED DATEPRODUCT NO

DESCRIPTIONQUANTITY ORDREDUNIT PRICE


Introduction to Entity-Relationship Introduction to Entity-Relationship (E-R) Modeling(E-R) Modeling

Notation uses three main constructs Data entities Relationships Attributes

Entity-Relationship (E-R) Model A detailed, logical representation of the data

entities, associations and data characteristics for an organization

Entity-Relationship (E-R) Diagram A graphical representation of an E-R model

10.1310.13


E-R E-R NotationNotation


Entity-Relationship (E-R) ModelingEntity-Relationship (E-R) ModelingKey TermsKey Terms

Entity A person, place, object, event or concept in the user

environment about which the organization wishes to maintain data

Represented by a rectangle in E-R diagrams

Entity Type A collection of entities that share common properties or

characteristics

10.1510.15



Naming and Defining Entity Types An entity type name

Is a Singular Noun (CUSTOMER, STUDENT) Should be descriptive and specific to organization

(PURCHASE ORDER, CUSTOMER ORDER) Should be concise (REGISTRATION vs. STUDENT

REGISTRATION FOR CLASS) (for Event Entity Type) should be the result of the event,

not the activity or process of the event (ASSIGNMENT) An entity type definition should

Include unique characteristics for each instance Make it clear what entities instances are included/not-incl When an instance of the entity type is created/deleted

10.1610.16


Attribute A named property or characteristic of an entity that

is of interest to an organization




Naming and Defining Attributes An attribute type name

Is a noun (Customer_ID, Age, Minimum_Qty) Should be unique Should follow a standard format (Student_GPA, not

GPA_of_Student) An attribute definition should

State what attribute is and why it is important Make it clear what entities instances are included/not-incl

in the attribute’s value List all aliases/alternative names Specify if the value is Required/Optional

10.1810.18



Candidate keys and identifiers Each entity type must have an attribute or set of

attributes that distinguishes one instance from other instances of the same type

Candidate key Attribute (or combination of attributes) that uniquely

identifies each instance of an entity type Identifier

A candidate key that has been selected as the unique identifying characteristic for an entity type

10.1910.19



Selection rules for an identifier1. Choose a candidate key that will not change its

value

2. Choose a candidate key that will never be null

3. Avoid using intelligent keys

4. Consider substituting single value surrogate keys for large composite keys

(e.g., use Game_ID instead of Home_Team and Visiting_Team for the entity GAME)

10.2010.20



Multi-valued Attribute An attribute that may take on more than one value

for each entity instance Represented on E-R Diagram in two ways:

1. double-lined ellipse 2. weak entity

10.2110.21



Relationship An association between the instances of one or more entity

types that is of interest to the organization Association indicates that an event has occurred or that

there is a natural link between entity types Relationships are always labeled with verb phrases

10.2210.22


Degree of RelationshipDegree of RelationshipDegree

Number of entity types that participate in a relationship

Three cases Unary (recursive)

A relationship between two instances of one entity type Binary

A relationship between the instances of two entity types Ternary

A simultaneous relationship among the instances of three entity types

Not the same as three binary relationships

10.2310.23


Figure 10-6Figure 10-6Example relationships of different degreesExample relationships of different degrees

10.2410.24


CardinalityCardinality

The number of instances of entity B that can be associated with each instance of entity A

Minimum Cardinality The minimum number of instances of entity B that may be

associated with each instance of entity A

Maximum Cardinality The maximum number of instances of entity B that may be

associated with each instance of entity A

10.2510.25


CardinalityCardinality


Naming and Defining Relationships Relationship name is a verb phrase Avoid vague names (e.g., Has, Is_related_to) Guidelines for defining relationships

Definition explains what action is being taken and why it is important

Give examples to clarify the action Optional participation should be explained Explain the reason for any explicit maximum cardinality Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship

instance can transfer participation to another relationship instance

10.2710.27



Associative EntityAssociative EntityAn entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances

10.2810.28


Associative Entity: ExampleAssociative Entity: Example

10.2910.29

Ternary Relationship


Associative Entity: ExampleAssociative Entity: Example

10.3010.30


Representing Representing Supertypes and SubtypesSupertypes and Subtypes

Subtype: A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationshipsSupertype: A generic entity type that has a relationship with one or more subtype


Representing Representing Supertypes and SubtypesSupertypes and Subtypes

Business Rules for Supertype/Subtype Relationships: Total Specialization rule: Specifies that each entity

instance of the supertype must be a member of some subtype in the relationship ( represented with || )

Partial Specialization rule: Specifies that an entity instance of the supertype is allowed not to belong to any subtypes ( represented with | )

Disjoint rule: Specifies that if an entity instance of the supertype is a member of one subtype, it cannot be a member of any other subtype ( represented with ”d” )

Overlap rule: Specifies that an entity instance can simultaneously be a member of two or more subtypes (represented with ”o” )


Example: Example: Supertype / Subtype HierarchySupertype / Subtype Hierarchy


Business RulesBusiness RulesSpecifications that preserve the integrity of a conceptual data model

1. Entity integrity (each instance of an entity type must have a unique non-null identifier)

2. Referential integrity (rules concerning the relationships between entity types)

3. Domains (constraints on valid values for attributes)

4. Triggering operation (business rules that protect the validity of attribute values)

10.3410.34


DomainsDomainsThe set of all data types and ranges of values that an attribute can assumeSeveral advantages:

1. Verify that the values for an attribute are valid2. Ensure that various data manipulation operations are logical3. Help conserve effort in describing attribute characteristics

10.3510.35


Triggering OperationsTriggering OperationsAn assertion or 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)

10.3610.36


Triggering OperationsTriggering Operations

*** Responsibility for data integrity lies within scope of database management system, not individual applications

10.3710.37


The Role of CASE The Role of CASE in Conceptual Data Modelingin Conceptual Data ModelingCASE tools provide two important functions:

Maintain E-R diagrams as a visual representation of structured data requirements

Link objects on E-R diagrams to corresponding descriptions in a repository

Usually supports more than one E-R diagramming notations

Most tools do not support drawing ternary or higher relationships

10.3810.38


Example: HB’s Inventory Example: HB’s Inventory Management SystemManagement System

++ ==


Example: HB’s Inventory Example: HB’s Inventory Management SystemManagement System


SummarySummaryProcess of conceptual data modeling

Deliverables Gathering information

Entity-Relationship Modeling Entities, Attributes, and Relations Candidate keys and identifiers Multivalued attributes

Degree of relationshipCardinalityAssociative entitiesDomains and Triggering OperationsRole of CASE

10.4110.41

CHAPTER 11:CHAPTER 11:

Selecting the Best Alternative Selecting the Best Alternative Design StrategyDesign Strategy

2.422.42


Learning ObjectivesLearning Objectives Describe different sources of software Learn to assemble the various pieces of an

alternative design strategy Learn how to generate at least three alternative

design strategies Discuss selecting the best design strategy using

both qualitative and quantitative methods Learn how to use the results of the analysis phase

to update a Baseline Project Plan (BPP) Discuss design strategies and how they are applied

to the Internet

11.43

11.43


Alternative Generation and Alternative Generation and Selection in SDLCSelection in SDLC



Two basic steps1. Generate a comprehensive set of alternative design

strategies

2. Select the one design strategy that is most likely to result in the desired information system

Process Divide requirements into different sets of capabilities Enumerate different potential implementation environments

that could be used to deliver the different sets of capabilities

Propose different ways to source or acquire the various sets of capabilities for the different implementation environments

11.45

11.45



Deliverables1. At least three substantially different system design

strategies for building the replacement information system

2. A design strategy judged most likely to lead to the most desirable information system

3. A Baseline Project Plan (BPP) for turning the most likely design strategy into a working information system

11.46

11.46


Generating Generating Alternative Design StrategiesAlternative Design Strategies

Best to generate three alternatives Low-end

Provides all required functionality users demand with a system that is minimally different from the current system

High-end Solves problem in question and provides many extra

features users desire Midrange

Compromise of features of high-end alternative with frugality of low-end alternative

11.47

11.47


Drawing Bounds Drawing Bounds on Alternative Designson Alternative Designs

Minimum Requirements Mandatory features versus desired features Forms of features

Data Outputs Analyses User expectations on accessibility,response time and

turnaround time

11.48

11.48


Drawing Bounds Drawing Bounds on Alternative Designson Alternative Designs

Constraints on System Development Date when system is needed Financial and human resources Elements of the system that cannot change Legal and contractual considerations Dynamics of the problem

11.49

11.49


Issues to Consider Issues to Consider in Generating Alternativesin Generating Alternatives

Outsourcing The practice of turning over responsibility of some

to all of an organization’s information systems applications and operations to an outside firm

Can provide a cost effective solution

Why would an organization outsource its information systems operations?

Why would an organization dissolve its entire IS unit to bring in an outsider to manage it?

11.50

11.50


Issues to Consider Issues to Consider in Generating Alternativesin Generating Alternatives

Sources of Software Hardware manufacturers Packaged software producers Custom software producers Enterprise solution software Application Service Providers In-house development

11.5111.51


……Sources of Software …Sources of Software …


Comparison of Software SourcesComparison of Software Sources


Criteria for Choosing Criteria for Choosing Off-the-Shelf SoftwareOff-the-Shelf Software

Cost In-house versus purchased

Functionality Mandatory, essential and desired features

Vendor Support Installation Training Technical Support

Viability of Vendor

11.5411.54


Criteria for Choosing Criteria for Choosing Off-the-Shelf SoftwareOff-the-Shelf Software

Flexibility Ease of customization

Documentation User documentation Technical documentation

Response Time

Ease of Installation

11.5511.55


Validating Validating Purchased Software InformationPurchased Software Information

Information from vendor Request For Proposal (RFP) or Quote For

Proposals (QFP) A document provided to vendors to ask them to propose

hardware and system software that will meet the requirements of your new system

Software evaluation period

Customer references from vendor

Independent software testing service

Trade publications

11.5611.56


Hardware and Software IssuesHardware and Software Issues

Existing Platform1. Lower costs

2. Information system staff is familiar with operation and maintenance

3. Increased odds of successfully integrating system with existing applications

4. No added costs of converting old systems to new platform or transferring data

New Hardware and System Software1. Some software

components will only run on new platform

2. Developing system for new platform gives organization opportunity to upgrade technology holdings

3. New requirements may allow organization to radically change its computing operations

11.5711.57


Implementation and Implementation and Organizational IssuesOrganizational Issues

Implementation Issues Technical and social aspects of implementation

need to be addressed Training Disruption of work

Organizational Issues Overall cost and availability of funding Management support User acceptance

11.5811.58


Hoosier Burger’s Hoosier Burger’s New Inventory Control SystemNew Inventory Control System

Replacement for existing system

11.5911.59



11.6011.60

Three alternatives

A. Low-end

B. Midrange

C. High-end


Hoosier Burger’s New Inventory Hoosier Burger’s New Inventory Control SystemControl System

Selecting the most likely alternative Weighted approach can be used to compare the

three alternatives Left hand side of table contains decision criteria

Constants and requirements Weights are arrived at by discussion with analysis

team, users and managers Each requirement and constraint is ranked

1 indicates that the alternative does not match the request well or that it violates the constraint

5 indicates that the alternative meets or exceeds requirements or clearly abides by the constraint

11.6111.61



QuantitativeMeasures:

Weights?

Rankings?

11.6211.62

According to the weights used, alternative C appears to be the best


Updating the Baseline Project Updating the Baseline Project Plan (BPP)Plan (BPP)

The Baseline Project Plan (BPP) was developed during project initiation and planning

Baseline Project Plan (BPP) can be used as an outline of a status report at analysis phase

Schedule will be updated to reflect actual activities and durations

An oral presentation of project status is typically made at this phase

11.6311.63


Internet Development: Selecting the Internet Development: Selecting the Best Alternative Design StrategyBest Alternative Design Strategy

Pine Valley Furniture WebStore Requirements and constraints were compiled by

consultant and team (see Table 11-8)

11.6411.64



11.6511.65



Proposed system is a scalable, three-tier approach

Scalable The ability to seamlessly upgrade the system through

either hardware upgrades, software upgrades or both Three-tier

Web Server Provides connection to the internet and presentation of

HTML page Applications Server

Middle layer of software and hardware that lies between Web server and corporate network

Corporate network Existing organizational computing infrastructure

11.6611.66



11.6711.67


SummarySummarySources of Software

Identifying requirements and constraints

Generating alternative design strategies

Selecting the best design strategy

Updating a Baseline Project Plan (BPP)

Selecting the best design strategy for Internet applications

11.6811.68

chapter 9: structuring system requirements: conceptual data modeling conceptual data modeling 1.1...

Documents

data store

documentation of data

data objects

data modeling descriptions

data modeling steps

new conceptual data

new applications data

delen msis