CA228 Software Specification1 Three Main Viewpoints of the Structured Systems Analysis Approach...

CA228 Software Specification 1

Three Main Viewpoints of the Structured Systems Analysis Approach

• Process/functional view:Data flow diagrams

• Data structures:Entity-relationship diagrams

• Time-dependent behavior:State-transition diagrams


Data Flow Diagrams (DFDs)• A DFD is a graphical representation of

– the processes of a system,– the data being transformed and stored

• A DFD gives a very good overview of what is happening in the system

• A DFD represents– the process view of a system (processes are

actions or sets of actions)– the functional view (processes as functions)– (workflow model)


Components of a DFD

• DFD is very easy to read since it is a graphical model and

• there are only four symbols to learn:– Processes– Data Flows– Data Stores– External Agents


Process

• Processes transform a data flow by changing its structure or by generating new information from it

• A process must have at least one data flow into it and one data flow out of it

• A process cannot exist independently

Validate Customer

Order

<processtitle>


Data Flows• A data flow is represented

by an arrow and depicts the fact that some data is flowing from one process to another

• Data moved is sometimes called a packet of data

• The name of data flows should be different if the data is changed on entering the process

verified_order

<flow name>

customer_address

zip_code

phone_#

street_address


Data Stores• When a process needs other

data other than what it receives from another process, to perform its function, this ‘other’ data can be retrieved from data stores

• A data store is a collection of related information for example, a telephone book, student records held in a filing cabinet

Orders

<store name>


Sources and Sinks

• External agents exist in the system’s environment and can:

– provide data to the system (i.e. a source or input) or

– receive data from the system (i.e. a sink or output)

• External entities include people like customers, managers, and include places like departments and suppliers

• The boundaries of a system determine what entities are external

• External agents are also referred to as terminators

Customer

<externalagent

name>


Components of a DFD Put Together

Orders

order

part_numbernew_order

Customer

Validate Order

Stock


Please note...• A DFD does not represent any control flow aspect in

your system• Therefore, no sequencing information can be read

from a DFD• However, this lack of control flow is not a drawback of

DFD, because what we are modeling using DFDs are requirements and not how those are implemented

• Note: In general, a DFD is not a dependency diagram (where a process produces output whenever all inputs are available)


Direct data flow vs. data store• The analyst may

decide if intermediate data needs to be stored persistently– implied by the

user’s needs– implicates

development cost


An alternative notation...

Customer

CustomersD1

ID

Sales Clerk

Validate Customer Order

2

Location

validate_order

Process(rectangle instead a circle!)

Data flow

Data store

External agent(an oval instead of a rectangle)


A few comments about notation...

• The modeling notation being used should be appropriate and efficient for the task at hand

• Beyond that it’s a matter of taste– Circle, rectangle, a cloud...

• Use a standard whenever a standard available

• In any case, be consistent• Underlying concepts matter

– Surface syntax can be learned quickly...


DFD Leveling

• DFDs allow the analyst to look at the system at different levels of detail

• Even quite small systems can be made up of many processes– To include all processes in a single diagram can:– make it look cluttered,– make it difficult to see in detail what a process does

• To overcome this, we can ‘break down’ a single diagram, into a number of diagrams

• This process is known as leveling


Context Diagrams (Overview or Level 0)

• Represents the system at the highest level of detail.

• Comprised of– A single process representing the entire system

modeled– External entities– The data flows that pass between the external

entities and the system

• Purpose is– to identify and examine the interfaces between the

external entities and the system


Example of a context diagram


Context diagram for a telephone system


Guidelines for drawing a Context Diagram

• List potential external entities (people, places). Look for entities that– give data to the system without explaining the

process that creates that data– take data from the system without explaining what

it does with that data

• Establish what flows are sent to and from the system from the external entities

• Draw the context diagram


Level 1 Diagram• Show

– the system in more detail– how data enters the system– how these data items are transformed by the processes– how they leave the system

• A level 1 diagram must have the same number of inputs and outputs as its context diagram

• The flows are connected to and from the actual processes which create, receive or change them

• Processes represent a breakdown of the activities which make up the system


Refinement of “Telephone System” processing element in the context

diagram


Guidelines for drawing a Level 1 Diagram

• Take one sentence at a time and try to identify potential processes (look for verbs)

• Group potential processes so you end up with (minimum) 3 to (maximum) 10

• Identify and list the data flows (generally documents but could also be physical items). A data flow is really anything that moves around the system

• Identify and list the data stores• Draw the level one diagram


Refinement of “PBX” processing element


DFD Fragments

• A DFD fragment is created for each event in the event list

• A DFD fragment is a self-contained model showing how the system responds to a single event

• As an analyst, you create DFD fragments one at a time


DFD fragment corresponding to the “off hook”


Bottom Level

• Continue decomposing a DFD into lower levels until the processes get so simple that you can describe them using:– Process specifications in pseudocode– Decision tables


Example of a process specification using pseudocode

1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $10,000 THEN:

a. Give a photocopy of the invoice to the appropriate salesperson who is to call the customer.

b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.

c. Refile the invoice in the file for examination two weeks from today.

2: OTHERWISE IF more than four overdue notices have been sent THEN:a. Give a photocopy of the invoice to the appropriate salesperson to call the

customer.

b. Log on the back of the invoice that a copy has been given to the salesperson, with the date on which it was done.

c. Refile the invoice in the file to be examined one week from today.

3: OTHERWISE (the situation has not yet reached serious proportions):

...


Example of a decision table


Data in data flow diagrams

• Data and data stores defined using Entity Relationship Diagrams and data dictionaries


Entity Relationship Diagrams (ERD)

• ER diagrams describe things and relationships between them

• They were first proposed by Chen in 1976– Unify different approaches to database design

(hierarchical, network and relational)– Original reference: Peter Pin-Shan Chen. The entity-relationship model—

toward a unified view of data . ACM Transaction on Database Systems. Vol. 1, No 1, 1976, pp 9-36

• Different ERD notations in use, but basically the same underlying concepts


Components of ERDs• Entities: Things about which we want or need

to maintain information– E.g., students, courses, suppliers, parts

• Attributes: Properties of entities– E.g. student ID, Course #, course name

• Relationships: – Associations between two or more entities– Students take courses

• ERDs can represent real world (or even imaginary worlds) in a diagram


Example

Student

FName

LName

Address

Course

C#CName

CDescription

takes

Entity(or more precisely: entity set or type)

Entity attribute

Relationship


Relationships• How two or more entities are related (if at

all…)• Cardinality

– 1:1(wife-husband)– 1:N (mother-children)– N:M (grandparents-grandchildren)

• Participation– Total participation

• Every child has a mother

– Partial participation• Not every person has a child


Meaning of ER diagrams

wife husband

Entitiesrepresentobject types

Associationsbetweenindividualobjects

1 1


One-To-Many Relationship

mother children1 n


Many-To-Many Relationship

grandparents

grandchildren

4 m


Partial participation

1


Attributes• Atomic: e.g. SSN• Compound: e.g. address (contain other atomic

attributes: street, zip, state. Can expand it to several attributes )

• Multi-valued: e.g. hobbies ( can have more than one hobby. Can expand to a relationship)

• Derived: e.g. age (can be derived from date of birth. You can decide whether you want to store the derived attributes in the database or not)

• Key: An attribute that uniquely identifies a thing


ERD Notation

• Different notations– No single standard notation

• Some variations– Using diamond to denote relationships or

not– Providing cardinality or not– Way of specifying cardinality


Summary of Diagrams in the Traditional Approach

• Three main viewpoints:– Data flow diagrams - process/functional viewpoint– Entity-relationship diagrams - viewpopint of data structures– State-transition diagrams - viewpoint of time-dependent

behavior

• Two additional detailed viewpoints:– Data dictionary - detailed structure of data– Process specification - detailed structure of processes


Data Dictionary & Process Specs

Example Data Dictionary

Mailing Label = customer_name + customer_address

customer_name = customer_last_name + customer_first_name + customer_middle_initial

customer_address = local_address + community_address + zip_code

local_address = house_number + street_name + (apt_number)

community address = city_name + [state_name | province_name]

Example Data Dictionary

Mailing Label = customer_name + customer_address

customer_name = customer_last_name + customer_first_name + customer_middle_initial

customer_address = local_address + community_address + zip_code

local_address = house_number + street_name + (apt_number)

community address = city_name + [state_name | province_name]

Source: Adapted from Svoboda, 1990, p262-4

Example Mini-Spec

FOR EACH Shipped-order-detail

GET customer-name + customer-address

FOR EACH part-shipped

GET retail-price

MULTIPLY retail-price by quantity-shipped

TO OBTAIN total-this-order

CALCULATE shipping-and-handling

ADD shipping-and-handling TO total-this-order

TO OBTAIN total-this-invoice

PRINT invoice

Example Mini-Spec

FOR EACH Shipped-order-detail

GET customer-name + customer-address

FOR EACH part-shipped

GET retail-price

MULTIPLY retail-price by quantity-shipped

TO OBTAIN total-this-order

CALCULATE shipping-and-handling

ADD shipping-and-handling TO total-this-order

TO OBTAIN total-this-invoice

PRINT invoice


Structured

Systems

Analysis and

Design

Method


What is SSADM?

• Structured Systems Analysis and Design Method

• SSADM is sometimes thought of as a ‘cookbook’ approach to the analysis and design stages of the systems development lifecycle


What is SSADM?

• Developed to standardise many UK governmental IT projects

• Data driven – concentration on the data rather than processes.

• Highly structured with rules, guidelines and standards

• Documentation is crucial to all aspects of the system project development


Background Idea

Smaller stages lead to:

– Improved planning– Better scheduling– Early identification of problems– Better quality– Flexibility and ease of change


5. Physical Design5. Physical Design

4. Logical System Specification4. Logical System Specification

2. Requirements Analysis2. Requirements Analysis

1. Feasibility Study1. Feasibility Study

How is SSADM Structured?

Each step follows on from the previous complete step

Stage 0: Feasibility

Stage 1: Investigation of Current Environment

Stage 2: Business Systems Options

3. Requirements Specification3. Requirements SpecificationStage 3: Definitions of

Requirements

Stage 4: Technical System Options

Stage 5: Logical Design

Stage 6: Physical Design


Feasibility Study

• Examine whether project is technically, financially and socially feasible

• In other words – whether it is in concordance with the current business model

• Determine whether the project is cost-effective (benefits vs. costs)

1. Feasibility Study1. Feasibility Study Stage 0: Feasibility


Requirements Analysis

• Stage 1: Investigation of current Environment – Learn the terminology and function of the users’ environment– The current system forms the basis– Understand the data required– Set the system boundary clearly– Model the current system in terms of processes (DFD) and data

structures (LDS)– Analyse the business operations for problems etc.– Users are involved in walk-through at the end of this stage

• Stage 2: Business System Options – A decision is made by users as which option best meet their needs

2. Requirements Analysis2. Requirements AnalysisStage 1: Investigation of Current Environment

Stage 2: Business Systems Options


Requirements Specification

• A detailed specification of the required system is built up and checked extensively.

• Requirements are defined for processes and data structures modelled in the previous step.

• Both functional and non-functional requirements are defined

• The selected way to go is developed and refined, ELHs introduced

3. Requirements Specification3. Requirements SpecificationStage 3: Definitions of

Requirements


Logical System Specification

• Stage 4: Selection of technical optionsCost/benefit analysis is performed for each of the system’s hardware

and software options

• Stage 5: Logical designThe specification developed in stage 3 is expanded to a high level of

detail:– Define the logic of databases, user dialogues etc– Define update and operations processes– Define how enquiries are processed– Define the sequence of logical processes

4. Logical System Specification4. Logical System Specification Stage 4: Technical System Options

Stage 5: Logical Design


Physical Design

• The complete logical design - both data and processing is converted into a design that will run on the target environment.

• Logical and Technical Specifications are used to produce a physical database design and a set of program specifications, i.e. how the programs should work

• Create function component implementation map (FCIM) to document the logical to physical mapping

• Optimise physical data design• Complete function specification• Consolidate process data interface• Assemble physical design

5. Physical Design5. Physical Design Stage 6: Physical Design


Major SSADM Viewpoints

Modelling of:1 Underlying structure of the data in the

system: entities and their relationships (LDS s)

2 Data flows in / out of the system and any data transformation (DFD s)

3 The way in which data in the system changes over time by events acting on entities (ELH s)

These 3 models are used to cross check for consistency & completeness


Viewpoint 1: Logical Data Modelling


Order_LineOrder_Line

PartPartOrderOrder

CustomerCustomer

Logical Data Modelling

• Modelling and documenting the data requirements

• These requirements are then separated into entities (objects) and relationships (between entities).


Entities

• Entity - A thing that is of interest to an organisation about which information is stored

• The items of interest are called ATTRIBUTES

Example• System = University• Entity = Student• Example = Fred Smith• Attributes ?????


Logical Data Structure

• A diagram to show RELATIONSHIPS between entities

• e.g. A TUTOR teaches many STUDENTS

Tutor Studentsteaches

• Alternative names– Data Model

– Entity-Relationship Model

– Bachman Diagram


Building an LDS

• Identify the entities• Find the

RELATIONSHIPS between them

• Decide the CARDINALITY University Student

University Student

University Student

1 Many


Optionality

• Must, Must

• May, Must

• Must, May

• May, May

Doctor Patient

Doctor Patient

Doctor Patient

Doctor Patient


Relationship Link Phrases

• Each…[must be/may be]….[one or more/one and only one]

• e.g. Each DOCTOR may be responsible for one or more PATIENTS


To Make a Good LDS

• Do not create ENTITIES from Attributes e.g. A Human has 2 ARMS (These are attributes)

• Do not put in unnecessary links• Avoid Many-to-Many relationships

These cause problems as it is difficult to trace which example of entity A refers to which of entity B. Put an extra entity in between.

Flight Ticket Passenger


Example

• CUSTOMERS make sales ORDERS• A single order has several PRODUCTS• Each customer is in one of 621 AREAS• Each customer is serviced by one of 20

DEPOTS• Each customer is allocated a depot depending

on their customer location• All products are stocked in depots

Depot

Customer

Area

Order Product


Example




Depot

Customer

Area

Order ProductOrder Line


Example




Depot

Customer

Area

Order ProductOrder Line

Stock Item


More Advanced Notations

Account

Bank Building Society

School

PublicSchool

PrivateSchool

Exclusivity

Sub Types


SSADM LDM

A Logical Data Model consists of:

• Logical Data Structure

• Entity description

• Relationship description

• Attribute descriptions


Viewpoint 2: Data Flow Modelling


D1 OrdersD1 Orders

1 Accounts

Check Customer Details and Create Order

1 Accounts

Check Customer Details and Create Order

CustomerCustomer

Data Flow Modeling

Customer andOrder Details

Valid Order Details

• Modelling the way that data flows within a system

• Looks at data in terms of– Processes (which transfer

data from one form to another)

– Data Stores (which are places where data is held)

– External Entities (objects from which data comes, or objects which receive data)

– Data Flows (routes by which the data can flow)


Data Flow Diagram (DFD)

• Maps the route of data around a system

Data Source and Sink

Data Store

Flow Line

Process

• is easy to understand and communicate

• does not show procedures and control as a flowchart does


Representing the Process

Process customerorder

2.3.4 Sales

Person or entityresponsible for process

Process descriptor

Processnumber


Customer Payment Process

Process Payment1Bank

Credit manager

CustomerPayment

Remittance data

Deposit

Receivablesinformation

Customer

1

Update receivables2Accounts

receivable2


Basic Rules for a DFD

• Data does not flow directly between processes

• Data does not flow directly between data stores

• Data cannot be transferred directly from store to sink or source to store


Method by Tom De Marco1. Identify all net input and output data flows of the system

2. Work your way from inputs to outputs, backward from outputs to inputs, or from the middle out

3. Label all the interface data flows4. Label all the functions/processes

How to Construct a DFD

From, input to output

From output to input

What are the inputs?

What are the outputs?

From middle out


Method by Geoff Cutts1. Create a physical document flow diagram

Use ‘Ellipse’ to represent a person or department/section


Dispatch note

WarehouseCustomer

Invoice

Cheque

Order form

AccountsDept.

Sales Dept. Picking notes


2. Identify the boundary of the system. Draw dotted line to indicate the boundary. Anything outside the boundary will be the external entities (source and receipt of data).


Dispatch note

WarehouseCustomer

Invoice

Cheque

Order form

AccountsDept.

Sales Dept. Picking notes


3. Create the current physical DFD. Make processes of the ‘Ellipses’ inside the boundary


Dispatch note

WarehouseCustomer

Invoice

Cheque

Order form Picking notesProcess Order

1 Sales Dept.

Prepare Invoice2 Accounts Dept.


4. Create the context diagram (Level 0), which shows the external interfaces with the outside world, i.e. the global view of a system.


Dispatch note

WarehouseCustomer Invoice

Cheque

Order form Picking notes

Sales & Accountancy

System

0


5. Create lower level diagrams. Each process can be expanded (decomposed) into lower levels and lower

level DFDs show more details


Level 1 12

After further investigations, process 1 may become

Level 2 – Reference ID is 1.1, 1.2 ….

1.1

1.3

1.2 Ensure inputs & outputs match


• A system may have a set of DFDs with levels 0 to level N (3 to 4 is common).

• Each level should have at the most 7 processes (easy to digest & to remember)

• Those processes (functions) at the bottom level, which cannot be decomposed further, are called Primitive functions.



6 Ensure all data flows are given a name

“A DFD cannot be considered to be completed unless all data flows and functions have been given a meaningful name”

7. Add Data Stores where needed



• Information sink – No output form a process

• Write-only-files – File becomes larger

• Overly complex interfaces - Octopus

• Unnamable data flows• Unnamable processes

Signs of problems


• A physical DFD represents HOW things are happening. It contains the problems of the current system, and is people or machine dependent. It tends to contain redundant data stores/ processing.It tends to mention names of departments, people, forms, devices used and where data is stored

• A logical DFD is extracted from a physical DFD. It is a logical representation of the system, which indicates WHAT the system accomplishes. It is implementation-independent: it focuses on the flow of data between processes without regard to the specific devices, storage location or people in the system.

Types of DFDs


LogicalPhysical

Clerk

Receive order and write out an

order file

Receive order

Typist

Type invoice Produce invoice

Order form

Order form Order Order

Dispatch note

Price fileInvoice

Invoice

Price information

Dispatch details

Examples


Sequence of Building DFDs

How the current system worksCurrent Physical DFD

What the current system accomplishes

Required Logical DFD

Requirements for

New System

Current System

Problems

Current Logical DFD

What the new system is required to accomplish


Required Logical DFDWhat the new system is required to accomplish

Technical System

Option chosen

New Physical DFDHow the new system will work

Sequence of Building DFDs


• Logicalise the data flowWhat data contents are required, remove physical descriptions e.g form/card

• Remove time dependencies due to implementatione.g. The orders are not to be processed until the number is bigger than 20

• Logicalise the functionsRemove unnecessary processes, remove control information, functions which perform only physical tasks

• Logicalise the data storesFor the data flows from or to a data store (physical), replace the data flow with the entity or entities referenced, and replace the physical data store with a logical data store

From Physical to Logical DFD

CA228 Software Specification1 Three Main Viewpoints of the Structured Systems Analysis Approach...

Documents

Transcript of CA228 Software Specification1 Three Main Viewpoints of the Structured Systems Analysis Approach...