advanced systems analyis design (uml)

HND ICT: Advanced Systems Analysis & Design

1 [email protected]

What is Systems Analysis & Design?

In business, systems analysis and design refers to the process of examining a business situation with the intent of improving it through better procedures and methods.

Overview of Systems Analysis and Design

Systems development can generally be thought of as having two major components:

systems analysis and systems design. Systems design is the process of planning a new business system or one to replace or complement an existing system. Before this planning

can be done the old system must be thoroughly understood before we can determine how

computers can best be used (if at all) to make its operation more effective. Systems Analysis, is then, the process of gathering and interpreting facts, diagnosing problems and using that information to recommend improvements to the system. This is the job of the

systems analyst.

Systems Analysts do more than solve current problems. They are frequently called upon to

help handle the planned expansion of a business. Analysts assess what the future needs of

a business will be and what changes should be considered to meet those needs. Analysts will generally suggest a number of alternative solutions for improving the situation with

recommendations as to which solution is the most applicable.

To summarize, analysis specifies what the system should do. Design states how to

accomplish the objective.

What Systems Analysis is NOT

Having looked at what systems analysis is - studying business systems to learn current

methods and assess effectiveness. It may also be helpful to know what systems analysis is

NOT:

It is NOT:

Studying a business to see which existing processes should be handled by computer and which should be done by non computerised methods. The emphasis is on understanding the details of a situation and deciding whether

improvement is desirable or feasible. The selection of computer and non computer methods

is secondary.

It is NOT:


2 [email protected]

Determining what changes should be made. The intent of the systems investigation is to study a business process and evaluate it.

Sometimes, not only is change not needed, it is not possible. Change should be a result not

an intent.

It is NOT:

Determining how best to solve an information systems problem Regardless of the organisation, the analyst works on business problems. It would be a

mistake to distinguish between business and system problems, since there are no systems

problems which are not first business problems. Any suggestions should be first

considered in the light of whether it will improve or harm the business. Technically

attractive ideas should not be pursued unless they will improve the business system.

Systems Analysts' Work

The description above gives an overview of what analysts do. However, the responsibilities

of analysts, as well as their titles, vary among organisations. Listed below are the most common sets of responsibilities assigned to systems analysts. (Other titles given to

analysts are given in parentheses.)

1. Systems analysis only. The analysts' sole responsibility is conducting systems studies to learn relevant facts about a business activity. The emphasis is on gathering

information and determining requirements. Analysts are not responsible for systems

design. (information Analysts).

2. Systems Analysis and Design. Analysts carry out complete systems studies but have added responsibility for designing the new system.

3. Systems analysis, design and programming. Analysts conduct the systems investigation, develop design specifications and program software to implement the design.

(programmer analysis)

None of these roles are superior to the other. Organisations often dictate the nature of

analysts work. In smaller firms, analysts take on more roles than in larger firms, which

hire people to specialise only in, for example, systems design. In many organisations, the

actual programming is performed by applications programmers, who specialise in this part

of the systems development effort. Many analysts start as programmers and then become systems analysts after gaining experience.


3 [email protected]

The Traditional Systems Development Lifecycle (SDLC)

An Historical Perspective

We begin by considering the period from the 1950s and covering the 1960s when there

was no well-accepted formalised methodology to develop data processing systems Early

uses of computing concentrated on scientific or mathematical applications Later, when

computers were installed in business environments, there were few practical guidelines

which gave help on their use for commercial applications. These business applications were

oriented towards the basic operational activities of the company and may include keeping

files, producing reports and documents.

Typical examples would include:-

· customer records

· sales records

· invoice production

· payroll

Applications which involve the basic data processing processes of copying, retrieving,

filing, sorting, checking, analysing, calculating and communicating.

These early systems were implemented primarily by computer programmers who were not

necessarily good communicators nor understood the user’s requirements. Their main

expertise lay in the technological aspects of the systems. Standard practices and

techniques were not in general use leading to an ad hoc approach to each project.

Problems associated with these developments were:

· difficulties in the communication of user needs to system developers

· developments were frequently delivered late, over cost and did not meet the users needs

· projects were viewed as short term solutions rather than long-term, well-planned

implementation strategies for new applications.

· changing the system was problematic and generally introduced new problems into the

system. Therefore it appeared to take an inordinately long time to make relatively

trivial changes.

· documentation, if it existed, was usually out of date and programmers rarely had time

to update it.


4 [email protected]

· documentation standards were resisted by programmers as they were viewed as

restricting creativity, increasing workloads and thus increasing overall development

time. (true, but the time spent documenting a new system could pay dividends in

reducing the maintenance time for systems).

· companies were reliant on a few experienced programmers, new programmers found it

difficult to take over because of the lack of documentation, uniform practices and

techniques.

In answer to the problems outlined above the Software Development Lifecycle was

adopted and adapted from a general development model common in other ‘engineering’

industries.

The general model has six stages:-

Feasibility Study

System Investigation System Analysis

System Design

Implementation

Review & Maintenance

However, we now consider the slightly improved model which is still in common use today

and covers all aspects of systems development from the initial business problem to the

maintenance of the developed computer systems.

Diagrammatically:

Business Problem Definition

Feasibility Study

Systems Analysis

Systems Design

Physical DesignTesting

Implementation

Post Implementation Review

Maintenance


5 [email protected]

It is interesting to note that the maintenance phase of the systems development life-cycle

typically accounts for up to 80% of the effort required for a given system.

Let us briefly consider each of the steps of the cycle in turn.

1. Business Problem Definition.

(Sometimes known as Requirements Definition) is the job of identifying and

describing what is required of the new information system. i.e. it provides the

terms of reference for the development process. Techniques used in this

stage include interviews and questionnaires.

2. Feasibility Study

Is an investigation of alternative solutions to the business problem with a

recommended solution chosen out of the alternatives? The technique of cost

benefit analysis is used in this stage.

3. Systems Analysis

Is the detailed investigation and analysis of the requirements of a system to fulfill

a given business problem. The techniques used in this stage include:

Dataflow diagrams

Entity modeling

Functional Analysis

Decision Trees

Decision Tables

4. Systems Design

Is the process of constructing a design for a system to fulfill a given business

requirement. The techniques used in this stage include:

Dataflow diagrams Entity modeling

Functional Analysis

Decision Trees

Decision Tables

Structured English

Prototyping

Sometimes the systems design stage is broken down into:

a) Logical Design


6 [email protected]

b) Physical Design

Logical Design is the production of a design far a system that ignores the physical

characteristics of the system. That is we look at what the system logically does, not how it

is physically done.

The logical design stage provides an opportunity to rationalise the design and any

duplication or unnecessary functions would be removed.

Physical Design is the production of a design for the physical system, that is we are

concerned with how the system will physically operate.

5. Coding

Is the production of machine comprehensible instructions. Techniques used here

include:

Structured programming techniques

Coding may be performed in one of 4 types of languages:

i. First generation languages - machine code i.e. 1’s and 0’s

ii. Second generation languages - simple instructions such as arithmetic

functions e.g. assembly language

iii. 3rd generation languages - languages which use more English or more

scientific constructs. e.g. COBOL, PL1, FORTRAN

iv. 4th generation languages - languages which use powerful commands to

perform multiple operations. e.g. FOCUS, POWERHOUSE

6. Testing.

There are 6 types of testing that are performed.

a. Unit testing - testing of individual modules

b. Link testing - testing of communications between modules

c. System testing - testing of the system as a whole d. d) Volume testing - testing that the system can cope with the anticipated

volumes of data.

e. User-acceptance testing - letting the users try the system.

f. Regression testing - used during the maintenance phase to ensure that changes

do not corrupt other parts of the system.


7 [email protected]

7. Implementation.

Actually implementing the live system. There are four methods of implementing a

system

i. Direct changeover - scrap the old system and start using the new system

immediately.

ii. b) Parallel running - running both the old system and the new system until

the new system has ‘proved itself’.

iii. c) Pilot - implementing the whole system in just a part of the organization or

part of the system in the whole organization.

iv. d) Phased implementation - implementing the system in stages. e.g. for an

integrated ledger package we might implement just the sales ledger first, then at a later date implement the purchase ledger and then later

still the nominal ledger.

8. Post-implementation Review.

After 6 months or 12 months the implementation and performance of the system

is reviewed to determine how successful the exercise has been.

9. Maintenance. Enhancements, error corrections and minor changes are made to the system until

we reach the point where the system becomes obsolete and then we start the whole

systems lifecycle again with a new business problem definition.

These stages are frequently referred to as ‘conventional systems analysis’, traditional

systems analysis’, ‘the systems development lifecycle’ or the waterfall model’. The term

lifecycle indicates the iterative nature of the process as when the system becomes

obsolete the process begins again.

Potential Strengths of the Traditional SDLC

This conventional systems analysis methodology has a number of features to commend it.

a. It has been well tried and tested

b. deadline dates are more closely adhered to c. unexpectedly high costs and lower than expected benefits are avoided

d. progress can be reviewed at the end of each stage


8 [email protected]

� By dividing the development of a system into phases, each sub-divided into more

manageable tasks, along with improved communication techniques gives much better

control over the development of computer applications than before.

Potential Weaknesses of the Traditional SDLC

Although this approach represents a significant improvement over earlier more ad hoc approaches there are, at least potentially, some serious limitations to the SDLC. These

criticisms can be summarized as follows:-

a. Failure to meet the needs of management b. Unambitious systems design

c. Instability

d. Inflexibility

e. User dissatisfaction

f. Problems with documentation

g. Lack of control

h. Incomplete systems i. Application backlog

j. Maintenance workload

k. Problems with the ‘ideal’ approach

Failure to meet the needs of management

Payroll Production Control

Sales OrderProcessing

Ledger

Invoicing SupplierOrder

processing

Stock Control

Top (Strategic)Management

Middle (Tactical)Management

OperationsManagement

Computerdata

processing

Largely ignoredby computer

As can be seen from the diagram above, systems developed by this method can

successfully deal with operational processing, middle management and top management

were/are sometimes ignored by computer data processing. Information needed to make


9 [email protected]

strategic decisions is poorly targeted, if it exists at all. Although some information may

filter up in the form of summary or exception reports, the computer is being used to

service routine or repetitive tasks.

Unambitious Systems Design

Computer systems usually replace manual systems, which have proved inadequate in

changing circumstances. Instead of improving on those systems, the computerised system

mirrors the original system.

Models of Processes are unstable

The conventional methodology attempts to improve the way that processes in business are

carried out. However, business’s change and processes need to change frequently and

adapt. As computer systems model processes, they have to be modified and changed

frequently. Computer systems which model processes are unstable because the processes

themselves are unstable.

Output driven design leads to inflexibility

Outputs to be produced by the system are determined at a very early stage in

development. Once the outputs are agreed, inputs, file contents and processing are

designed to fit. However, changes to outputs are frequent, designing from outputs

backwards can cause large changes throughout the system, in turn causing lengthy delays

in maintenance.

User Dissatisfaction

A feature of many computer systems. Systems can be rejected as soon as they are

implemented! This may be the first time users see the results of their decisions. Decision

which analysts have assumed to be firm. Users cannot always be expected to be fully

conversant with computing technology and its full potential and so find it difficult to

contribute effectively to developing better systems.

Problems with documentation

Documentation tends to be completed reluctantly by computing personnel and generally it

has been poorly done. Modifications to the system are rarely reflected in the

documentation making it an unreliable reflection of the actual system.

Lack of control

Despite a more methodological approach enabling time and resource estimations to be

made, these estimates are unreliable because of the complexity of the task and the

inexperience of the staff.

Incomplete Systems


10 [email protected]

Computers are good at processing large amounts of data quickly. However, this does rely

on data being ‘standardized’ and to some extent structured. Exceptional conditions may be

expensive to implement and may be ignored. Manual intervention can be required to make

up the deficit (or it too is ignored).

Application Backlog

There can be a substantial delay in bringing a development project to fruition,

consequently several systems may be awaiting development for a considerable length of

time. Users may postpone requests for new systems (or maintenance requests) because

they know the delay involved will be extensive.

Maintenance Workload

‘Quick and dirty’ solutions are necessary to meet deadlines. 60% to 80% of computing

resources in this field are committed to maintenance task exacerbating the applications

workload problem.

Problems with the ‘ideal’ approach

The SDLC model assumes a step-by-step, top-down approach. This is somewhat naive,

iteration is the process is inevitable when, for example new requirements are discovered.

It also assumes a tailor made solution for each problem rather than a possible ‘packaged’

solution. The approach is aimed at large or medium scale computing machinery, with the

growth of PC usage this approach may be inappropriate.

These criticisms are to some extent ‘potential’ as many organisations using this approach have not fallen into the traps mentioned. Many successful systems have been developed

using this methodology and a large number of successful methodologies in use today are

based heavily on this approach.



What is a Methodology?

Before continuing it would be appropriate to clarify the term methodology. The term is not

well defined either in the literature or by practitioners. A reasonable definition could be:-

‘a collection of procedures, techniques, tools and documentation aids which will help the system developers in their efforts to implement a new information system. A methodology will consist of phases, themselves consisting of sub-phases, which will guide the system developers in their choice of the techniques that might be appropriate at each stage of the project and also help them plan, manage, control and evaluate information systems projects’ But a methodology is more than a collection of tools. It is usually based on some ‘philosophical’ view, otherwise it is merely a method, like a recipe. Methodologies may

differ in the techniques recommended or the contents of each phase, but sometimes their

differences are more fundamental.

To illustrate how the underlying philosophy adopted by a methodology can fundamentally

alter the system produced we shall briefly review the philosophies of two well known

methodologies, namely Object Oriented Analysis & Design (OOAD) and Structured Systems Analysis & Design Methodology (SSADM).

Object Oriented Analysis & Design (OOAD)

First of all we must define an ‘object’. This is essentially any item of interest to the

system i.e anything you may want to store information about. An object is constructed by

deriving a data structure capable of storing the required data necessary to that object.

For example, in constructing an ‘EMPLOYEE’ object, the data structure would have to be capable of storing elements such as: Name, Age, D.O.B., Home Address, Dept., Pay-rate

etc. (In entering data regarding a specific employee, a new object is created, the object

definition acting as a template, this is termed an instance of that object.

The object is then ‘surrounded’ by code segments called ‘methods’ which protect the

internal data structure from illegal operations by providing an interface which controls

access to the object. This situation is illustrated in the figure below:-



Methodse.g. Change Pay_rate Change Address Change Dept. etc.

Employee Object

Data Structure

The approach now relies on three main principles which govern the view of the given

system, these are:-

a. generalisation

b. inheritance

c. polymorphism

Generalisation

Generalisation concerns organising object types into a hierarchy or structure, the higher

in the hierarchy the more ‘general’ an object becomes, (conversely, the lower in hierarchy

the more specialised the object becomes). An example is given in the figure below:-

Person

Employee

TechnicianLecturer

Student

A Generalised object hierarchy of type person

Inheritance

Inheritance makes the data structure and operations (methods) physically available for

reuse by its sub-type. Inheriting the operations from a supertype enables code sharing,

Inheriting the data structure enables structure reuse.

Polymorphism

When a request for an operation is received by a sub-class, its list of permissible

operations is checked. If that operation is found, then it is invoked. If not the parent

classes are examined to locate the operation. Polymorphism allows the ability to override



the inherited methods of an object type. For example, while both Lecturers and

Technicians are both Employees and therefore share some basic characteristics, there will

be slight differences in details such as payment methods. An inherited pay method from

Employee is tailored through polymorphism to suit the individual differences of both sub-

types.

Structured System Analysis & Design Method (SSADM)

SSADM relies on 3 views of system data, representing function, structure and the effects

of time, as illustrated in the figure below:-

System Data

StructureFunction

Seq

uen

ce

DFD LDS

ELH

The three views of system data assumed by SSADM

Function

In this view the functionality of the system is explored using techniques such as Data Flow

Diagrams to investigate the transformation of system data as a result of inputs from

outside the system boundary.

This can be seen as a form of information plumbing, with pipelines (or data flows) carrying

the data from sources to sinks, via stations that carry out some form of transformation on

that data.



Structure

This view, the data analysis view considers the underlying structure of the data. To

understand that, entity models (or in SSADM terms, a Logical Data Structure) are built.

This is built to some extent on the belief that the majority of change in the system is

concerned with the procedures and functions of the system while the data required

remains constant. (This seems a fairly questionable view!).

Sequence

This view recognizes that it is necessary to identify the data structures used and

determining how data is carried around the system., but these models are static giving

snapshots of systems. Accordingly, the effects of time on our modeled and show how each

item can be created, how it is amended and how it is removed from the system. This third

view gives us the Entity Life History (ELH).

SSADM gives equal importance to each of these views and makes them complement each

other. A series of cross-validation checks between them ensures that at the end of

analysis, as rich a picture is gained of the system.

The Data Flow Diagram (DFDs) act as a check on the Logical Data Structure (LDS), to

show that each data item is created and amended at some time. The LDS ensures that the

data is present in the system, to allow the function processing shown on the DFD. The ELH

subsequently identifies all of the events that impact on the system, causing changes to the

state of the data. At this point, omissions from earlier investigations are frequently

uncovered. Integrity rules for making amendments to data are discovered and built in.

SSADM Structural Model

SSADM comprises a hierarchy of activities. From the top down, the hierarchy is Module

→→→→ Stage →→→→ Step →→→→ Task . There are five modules ranging from Feasibility through to

Physical Design. In each module there are one or more stages, with defined activities and

producing defined products.

The Modules are:



K Feasibility Study

K Requirements Analysis

K Requirements Specification

K Logical System Specification

K Physical Design

Projects are essentially linear and so Modules are sequenced to allow the natural project

lifecycle to be followed. However, each module is a self contained set of activities and can

be managed as a discrete project. It is possible in an I.T. project for each module to

become a separate contract so a different supplier may be employed on each. This

indicates the importance of ensuring the end of every activity is a set of products, to the

required quality, then another contractor may take them as a starting point and continue

the project.

Diagrammatically SSADM is as follows:-

Feasibility

Module

Requirements

Analysis

Module

Requirements

Specification

Module

Logical

System

Specification

Module

Physical

Design

Module

Project Procedures

Module and Stage Outline Activities K Feasibility Study

Feasibility -prepare for the feasibility study

-define the problem

-select feasibility options

-create feasibility report

K Requirements Analysis

Investigation of the Current System -establish analysis framework

-investigate and define requirements

-investigate current processing

-investigate current data

-derive logical view of current services

-assemble investigation results

Business System Options -define Business System Options



-select Business System Option

-define requirements

K Requirements Specification

Definition of Requirements -define required system processing

-develop required data model

-derive system functions

-enhance required data model

-develop specification prototypes

-develop processing specifications

-confirm system objectives

-assemble requirements specification

K Logical System Specification

Technical Systems Options -define technical systems options

-select technical system option -define physical design module

Logical Design -define user dialogues

-define update processes

-define enquiry processes

-assemble logical design

K Physical Design

Physical design -prepare for physical design

-create physical data design

-create function component implementation map

-optimise physical data design

-complete function design

-consolidate process data interface

-assemble physical design

These modules cover the lifecycle from feasibility study to design but not program design.

How the actual system is produced depends on the target language. In the case of 4th

Generation languages, the specifications produced are presumed to be complete enough to

create the system. If the target language is 3rd generation then the methodology is expected to feed into Jackson Structured Programming techniques.



Advantages of Systems Development Methodologies

It can be seen from the above comparison that differing philosophies can produce radically

different views of a system. Nevertheless, both produce valid working systems.

We conclude this section by considering the advantages which can be derived from the use

of systems methodology, namely:-

1. It provides a standard framework for all staff & projects e.g. work can be shared

between staff and work can be started by one member of staff and completed by

another.

2. Training Systems Analysts is easier - i.e. no mysterious art to systems analysis, just

follow the procedures.

3. Makes project control easier by providing a desired set of tasks and deliverables. i.e. If

you know what steps are to be taken, it is easier to estimate small individual steps rather

than the overall activity.

4. Incorporates the best techniques in a standardized way. e.g. If entity modeling is the

most useful technique used in your I.T. department, ensure it is used in a standard way.

5. Improves systems development productivity - if this is a tried and trusted approach,

productivity should follow.

6. Improves the quality of the final computer system - without a systematic approach

aspects of the required system may be overlooked or misunderstood.

7. Makes it easier to provide automated support with software tools - if all I.T. staff ‘does

their own thing’ only an extremely flexible support tool would be able to deal with this.

Disadvantages

1. Cost of introduction and use - methodologies can be expensive.

2. Time for introduction and use - when tight project deadlines are present the

methodology may ‘slow things down’ too much.

3. Staff resistance to introduction and use - why change the way we work now.



Requirements Determination and Fact-Finding Techniques.

Tutorial Questions

1. What is a system requirement? How are requirements determined?

2. Why are systems analysts often at a disadvantage compared with managers of

departments when systems investigations are being conducted?

3. What is a trigger? Why is it of concern to systems analysts? What role does it play in a

systems study?

4. What type of information is best obtained through interview?

5. What role does observation play in systems investigations?

Structured Analysis

Structured analysis is a development method for the analysis of existing manual or automated systems, leading to the development of specifications for a new or modified

system. The underlying objective in structured analysis is to organise the tasks associated

with requirements determination to provide an accurate and complete understanding of a current situation.

The word structure in structured analysis means:

1. the method attempts to structure the requirements determination process, beginning

with documentation of the existing system.

2. the process is organised in such a way that it attempts to include all relevant details that describe the current system.

3. it is easy to verify when relevant details have been omitted.

4. the identification of requirements will be similar among individual analysts and will

include the best solutions and strategies for systems development opportunities.

5. the working papers produced to document the existing and proposed systems are

effective communication devices.

This method of analysis has become synonymous with data flow analysis which provides a

tool for documenting an existing system and determining information requirements in a

structured manner.



Data Flow Analysis

Data analysis attempts to answer four specific questions:

• What processes make up a system?

• What data are used in each process?

• What data are stored?

• What data enter and leave the system?

Data drive business activities and can trigger events (e.g. new sales order data) or be

processed to provide information about the activity. Data flow analysis, as the name suggests, follows the flow of data through business processes and determines how

organisation objectives are accomplished. In the course of handling transactions and

completing tasks, data are input, processed, stored, retrieved, used, changed and output.

Data flow analysis studies the use of data in each activity and documents the findings in

data flow diagrams, graphically showing the relation between processes and data.

Data flow diagrams are used in a number of methodologies (SSADM and I.E.) to name two) and have the advantage of being able to be used in a number of contexts within the

analysis and development framework, representing models of the system during its various

stages of refinement. i.e.:

Current physical How the existing system works

Current logical What the current system accomplishes

Required logical What the new system is required to accomplish

Required physical How the required system will be implemented

Physical and Logical DFDs

There are two types of data flow diagrams, namely physical data flow diagrams and logical data flow diagrams and it is important to distinguish clearly between the two:

Physical Data Flow Diagrams

An implementation-dependent view of the current system, showing what tasks are carried

out and how they are performed. Physical characteristics can include:

Names of people

Form and document names or numbers

Names of departments



Master and transaction files

Equipment and devices used

Locations

Names of procedures

Logical Data Flow Diagrams

An implementation-independent view of the a system, focusing on the flow of data between processes without regard for the specific devices, storage locations or people in the

system. The physical characteristics listed above for physical data flow diagrams will not

be specified.

Data Flow Notation

Although the use of data flow diagrams is common to a number of analysis and design

methodologies the notation used in each instance varies slightly. The notation in use here is drawn from SSADM and is recommended for use on this course.

There are generally five symbols used to construct data flow diagrams:

1. Data Flow. Data move in a specific direction from an origin to a destination in the form of a document, letter, telephone call or virtually any medium. The data flow can be

thought of as a 'packet' of data.

sales order

At the highest level DFD, one arrow may represent several data flows, which may be

decomposed into individual flows at the lower levels.

There are some validation rules about where data flows may or may not travel.

• Data stores may not be linked by data flows: flows must travel from one to another

via a process.

• External entities may not send or receive data flows directly to or from a data

store: they must communicate via a process.

• Data cannot be generated by a process, or be swallowed by a process; documents

may be swallowed or generated, but there must be an output that is related directly to all inputs to the process.

2. Physical flow. Used to represent the flow of physical items in the system. Goods



3. External Entities. External sources or destinations of data, which may be people, programs, organisations or other entities which interact with the system but are

outside its boundary. They may be external to the whole company, such as customers,

Inland Revenue etc. or just external to the application area. Thus if we are modelling a

Sales Office system, Accounts & Despatch areas would be shown as external entities.

Each external entity communicates in some way with the system, so there is always a

flow of data shown between a process in the system and an external entity.

Supplier

Supplier

It may be desirable for the sake of clarity to duplicate an external entity on the

diagram, rather than have arrows from all points converging on one entity. If that is

the case, put a small line along the top of the entity.

4. Data Store. Here data are stored or referenced by a process in the system. The data store may represent computerised or non computerised devices. It may be a filing cabinet, an in-tray, a card index, a reference book or a computer file. Anywhere that

data is stored and retrieved is a data-store.

The notation is simple: a long, open-ended rectangle. with a box at the left end. The

box is labelled with an alpha pre-fix and a number. The alpha is either D (for an

automated data store) or M (for a manual/card data store). The number has no

significance; it is purely a reference. The rectangle is labelled with a description of the

contents of the data store.

D1 Stock file

D1 Stock File

Again, for the sake of tidiness, you wish to show the data store in more than one part

of the diagram, add a bar o the left hand box. Each occurrence of the box should

display the additional bar.

5. Process. A process is an activity that receives data and carries out some form of transformation or manipulation before outputting it again. The activity may be carrying out calculations , creating a new document from information that triggered the

process, or amending the document . It is depicted by a box divided into three parts:

the upper left position is given a number. This has no significance other than as a



reference number; it does not imply priority or sequence. The longer top rectangle

beside it names the location where the processing takes place; this may on an overview

DFD, be a broad term, Sales Accounts etc. As the DFDs become more detailed so do

these descriptions.

The rest of the box describes what is happening in the process. The rule here is to

keep the description as concise and meaningful as possible. Use an imperative verb with

an object, but make the verb specific. 'Process...' and 'Update...' are too vague and give

little clue as to what is meant. 'Calculate...', 'Add...' or 'Validate...' give a clearer

picture of what is happening.

Calculate VAT

6 Sales

Developing Data Flow Diagrams

The most comprehensive and useful approach to developing an accurate and complete

description of the current system begins with the development of a physical data flow diagram. The use of physical data flow diagrams is desirable for three reasons:

1. Analysts initially find it easier to describe the interaction between physical

components than to understand the policies used to manage the application. Identifying

people, what they do, which documents and forms trigger which activities and what

equipment is used in the processing. The movement of people, documents and

information between departments and locations is also identified.

2. Physical data flow diagrams are useful for communicating with users. Users relate

easily to people, locations and documents as they work with these each day. Users may

consider logical DFDs abstract as they do not contain these familiar components,

however, with physical DFDs users can quickly identify incorrect or missing steps.

3. Physical DFDs provide a way to validate or verify the user's current view of the system

with the way it is actually operating. If there are differences, they will be noted and discussed. It is not unusual to find that what a users thinks is happening differs in an important way from what actually occurs.



Drawing a Context Diagram

The first diagram developed is the context diagram (Level 0). It contains a single process and plays an important role in studying the current system in that it defines the system

under investigation by determining the boundaries of the system. So anything that is not

inside the process identified will not be part of the systems study. The manner in which

other organisation or external elements function is out of our control and so are not

studied in detail.

An example context diagram.

Sales System

Supplier

Customer

Goods

Ord

er

G.R

.N

Customer Order

Dispatch Note

Returned Goods Note

Supplie

r Invo

ice

Supplie

r Paym

ent

The Level 0 (Context Diagram) can be drawn by following three steps:-

Step 1 - List the documents used in the system.

Step 2 - List all the sources & recipients

Step 3 - Draw a box representing the system and show the flow of documents from these

sources and recipients. Those areas which are known to be inside the system are hidden

within the box.

Exploding the Process to produce a Top-level (1) DFD

In order to extend the study it is necessary to ‘explode’ the context diagram to show the

processes which achieve the transformation of the entire system. Initially we must identify the major functional areas within the system, transform those entities into

processes and label them accordingly.

E.g.



Context Diagram

0 Process 0

System

External

Entity 1

External

Entity 2

Dataflow 1 Dataflow 2

Level 1 Diagram

1.0 Process 1 2.0 Process 2

3.0 Process 3

M1 Datastore 1

External

Entity 1Dataflow 1

External

Entity 2

Dataflow 2

Flow

M1,1

Flow

1,3

Flow

2,1

Flow

3,D1

Level 2 Diagram

1.1 Process 1.1 1.2 Process 1.2

1.3 Process 1.3

External

Entity 1

Flow 2,1

Flow 1,3

Flow 1.1, 1.3

M1 Datastore 1

Flow

M1, 1.1



Hence, we have the overall process of the system on the context diagram being broken

down into processes 1.0, 2.0 and 3.0 on the level 1 diagram and then process 1.0 broken

down into processes 1.1, 1.2 and 1.3 on the level 2 diagram.

The high-level DFD is not yet complete: we have not identified how many processes each

of these functional areas perform, and what data stores are used. As we are describing a

physical system, we must consider the types of data moving through the system. As a rule

of thumb, we can consider the following types of data store:

1. Standing data, used for the day-to-day functioning of the system and is kept updated.

2. Historical data that is required to be maintained for reference and enquiry purposes,

but is no longer 'live'.

3. Temporary data stores, which will cease to exist when the need for their data is

exhausted.

4. Extracted data that is retrieved from different sources for the purpose of preparing

reports, statistics and so on.

We can now consider the data flows which cross boundaries into processes/functional

areas and determine what actions are carried out on them. Each process will probably

require one data store. Our initial investigations will identify all such data stores and their

access, so what ever is unclear at this point can be clarified.

Validating the DFD

Before moving on from this initial high-level DFD, we must ensure it is consistent. Below is

a checklist of points to watch out for before moving on to a detailed investigation which

will take us to lower levels.

1. Has each process a strong imperative verb and object?

2. Are data flows in related to data flows out? Data should not be swallowed up by a

process, only transformed in some way. A data store is the only place data is allowed to

rest. Similarly, data cannot be generated by a process. A document may be, but the

data on the document comes from a data flow into that process.

3. Can the flows be reduced? If a process is too busy, it can perhaps be broken down into

two or more processes: six data flows in or out of a process should be enough.

4. Do all data stores have flows both in and out? A one-way data store is of little use, unless it is a reference file. If the Current Physical DFD should identify such a data

store, confirm with the User that you have correctly understood the procedures.

5. Are symbols correctly labelled and uniquely referenced?

6. Do all external entities communicate with a process? No entity should be allowed direct

access to data, either to read or to update it.



When these checks are complete we can verify the diagram with the user. On being

satisfied that the diagram is a faithful reflection of the business area, we can proceed to

decompose the diagram.

Decomposition of top-level DFDs

The Level 1 DFD presents us with an overview of the system, a description that could come

from a preliminary interview with departmental managers, perhaps. Now we must examine

each process in more detail and break it down into other processes. The following steps

explain how this is done.

Step 1. Make each process box the system boundary. All data flows to or from that

process are now flows across the lower-level system boundary.

Step 2. Draw, outside the new boundary, the sources and recipients of these flows, as shown on the higher level DFD, (these can be external entities, data stores or other

processes. Ensure the labelling is consistent with the higher level.

Step 3. Identify and draw the processes at the lower levels that act on these data flows. Number the sub-processes with a decimal extension of the higher level number. i.e. Level 1,

Process 3 will break down to processes 3.1, 3.2, 3.3 etc. Those processes that cannot be

decomposed further, mark with an asterisk in the bottom right-hand corner.

Step 4. Carry out consistency checks as before. Step 5. Make sure that all lower level DFDs map onto the Level 1 diagram, by checking data

flows.

Step 6. Review the lower levels with the User to be sure that every activity performed by the system is depicted.

When the DFD has progressed as far as it is possible to go, the details must be recorded

on an Elementary Process Description (EPD) using a concise and precise narrative. If more

than four or five sentences are required, perhaps the process has still to be broken down

to another level.

Supporting documentation

A data dictionary, either paper or automatic, should be maintained at every stage of DFD

production. The dictionary should contain the following descriptions.



External Entity Description This describes all the external entities shown on the diagram. Included will be such details as the functions of the entity and constraints on how it is to

interface to the system.

Input/Output Description A list of all data flows, the contents and the start and end references for each flow crossing the system boundary.

It is important that this dictionary is maintained for the current system and for the

required system. The details will grow with each iteration, of course the first attempts

are not expected to be more than a guide.

Some Additional Notes on DFD Production.

All activities, data flows and data stores used in this lower-level view of the system must

be included within the previous data flow diagram. The lower-level diagrams must be

consistent with the higher-level view.

In general the following rules apply:

All data flows that appeared on the previous diagram explaining the process are included in

the lower level diagram.

New data flows and data stores are added if they are used internally in the process to link

processes introduced for the first time in the explosion at this level.

Data flows and data stores that originate within the process must be shown.

No entries should contradict the descriptions of the higher level data flow diagrams (if

they do, one or the other is either incorrect or incomplete and a change must be made).

How far should the explosion of detail be carried out? Because the nature and complexity

of systems vary, it is inadvisable to fix a specific number of levels. In general, we should

go as far as necessary to understand the details of the system and the way it functions.

Deriving the Logical View

Physical DFDs are a means to an end, not an end in themselves. They are drawn to describe

an implementation of the existing system for two reasons:

K to ensure a correct understanding of the current implementation (users are generally

better able to discuss the physical system as they know it through people, workstations

and days of the week.)



K the implementation itself may be a problem or limiting factor; changing the

implementation, rather than the system concept may provide the desired results.

A logical view steps back from the actual implementation and provides a basis for

examining the combination of processes, data flows, data stores, inputs and outputs

without concern for the physical devices, people or control issues that characterise the

implementation.

A logical data flow diagram is derived from the physical version by doing the following:

K Show actual data needed in a process, not the documents that contain them.

K Remove routing information; that is, show the flow between procedures, not between people, offices or locations.

K Remove references to physical devices.

K Remove references to control information

K Consolidate redundant data stores.

K Remove unnecessary processes, such as those that do not change the data or data

flows.

General Rules for Drawing Logical Data Flow Diagrams

. Any data flow leaving a process must be based on data input to the process.

. All data flows are named; the name reflects that data flowing between processes, data

stores, sources and sinks.

. Only data needed to perform the process should be an input to the process.

. A process should know nothing about, that is, be independent of any other process in

the system; it should depend only on its own input and output.

. Processes are always running; they do not start or stop. Analysts should assume a

process is always ready to function or perform necessary work.

. Output from processes can take one of several forms:



a) An input data flow with information added by the process (for example, an

annotated invoice).

b) A response or change of data form (such as a change of £’s profit to profit

percentage.

c) Change of status (from unapproved to approved status).

d) Change of content (assembly or separation of information contained in one or

more incoming data flows).

e) Change in organisation (e.g. the physical separation or rearrangement of data).

Rapid Application Development

The need to develop information systems more quickly has been driven by rapidly changing

business needs. The general environment of business is seen as increasingly competitive,

more customer-focused and operating in a more international context. Such a business

environment is characterized by continuous change, and the information systems in an

organization need to be created and amended speedily to support this change.

Unfortunately, information systems development in most organizations is unable to react

quickly enough and the business and systems development cycles are substantially out of

step. In such a situation, the notion of rapid application development (RAD) is obviously

attractive.



The following are the most important characteristics of RAD.

1. It is not based upon the traditional life-cycle but adopts an evolutionary/prototyping approach.

2. It focuses upon identifying the important users and involving them via workshops at

early stages of development.

3. It focuses on obtaining commitment from the business users

4. It requires a CASE tool with a sophisticated repository.

TYPES OF CASE TOOLS



Requirements Planning

JRP Workshop

User Design

JAD Workshop

Prototyping

CASE

Construction

Prototyping

CASE

Key

Tools

TechniquesJAD

Phases

As the figure above illustrates, RAD phases.

RAD PHASES

1. Requirements Planning



2. User Design

3. Construction

4. Cutover

1. Requirements Planning

RAD devotes a lot of effort to the early stages of systems development. This concerns

the definition of requirements. There are two techniques used in this phase, both of which

are really workshops or structured meetings. The first is joint requirements planning (JRP)

and the second is joint application design (JAD).

The role of JRP is to identify the high level management requirements of the system at a

strategic level. The participants in JRP are senior managers who have a vision and

understanding of the overall objectives of the system and how it can contribute to the

goals and strategy of the organisation. If this understanding does not already exist, the

workshop may be used to help determine such an understanding. The JRP is a creative workshop that helps to identify and create commitment to the goals of the system, to

identify priorities, to eliminate unnecessary functions and so on.

In JRP, the participants need to have a combination of overall business knowledge and

specific knowledge about the area that the proposed system is addressing along with its

requirements. They also need to have the necessary authority and seniority to be able to

make decisions and commitments. Applications often cross traditional functional

boundaries and ensuring the right people are present at the meetings are absolutely critical.

The details of the workshops will be discussed in the next section as they are the same as

JAD workshops.

2. User Design

JAD is the main technique of the User Design phase, indeed, it appears to contain little

else. User Design is in reality both analysis and design. JRP workshops may be combined

with JAD in situations where the overall requirements are already well-established.

Normally, however, JAD would follow on from JRP. JAD adopts a top-down approach to

user design and is based on the recognition that user requirements are difficult to understand and define, and that the traditional requirements analysis techniques of

observation, interviews and questionnaires are inadequate. In JAD, the user design is

achieved via the good combination of the right people, the right environment and the use

of good prototyping tools.



The prototyping tool allows the quick exploration of processes, interfaces, reports,

screens, dialogues and so on. Prototyping may be used for the overall system or be used to

explore particular parts of the system that are contentious or present particular

difficulties. The user design is developed and expressed using four diagramming

techniques, i.e.

� entity modeling

� data flow diagramming � functional decomposition

� action diagrams (pseudocode)

The participants in the workshop need to be familiar with these techniques, but the

emphasis is on getting the requirements as correct as possible and to reflect the business

needs.

The results of the User Design are captured in a CASE Tool which checks internal

consistency. Where necessary the terminology used should be defined and stored in the

repository of the tool. The use of CASE tools enables the speedy, accurate and effective

transfer of the results into the next phase, the construction phase.

It is possible to use JAD outside of RAD and it can make a useful technique for

requirements analysis in its own right.

The typical characteristics of a JAD workshop are as follows:

i. An intensive meeting of business users (managers and end users) and information systems people: There should be specific objectives and a structured agenda, including rules of behaviour and protocols. The IS people are usually there to assist on technical matters, i.e. implications, possibilities and constraints, rather than

decision-making in terms of requirements. One of the most crucial participants is

the executive owner of the system.



ii. A defined length of meeting: This is typically one or two days, but can be up to five. The location is usually away from the home base of the users and away from

interruptions. Telephones and e-mail are usually banned.

iii. A structured meeting room: The layout of the room is regarded as crucial in helping to meet objectives. Walls are usually covered with whiteboards etc. CASE and

other tools should be available in the room.

iv. A facilitator: Who leads and manages the meeting. They are independent of the

participants and specialises in facilitation (i.e. experienced in group dynamics etc.)

A facilitator is responsible for the process and outcomes in terms of documentation

and deliverables and will control the objectives, agenda, process and discussion.

v. A scribe: Responsible for documenting the discussions and outcomes of meetings.

Key Characteristics of JAD

a. Intensive meetings significantly reduce the elapsed time to achieve the

design goals.

b. Getting the right people to the meeting, i.e. everyone with a stake in the

system, including those who can make binding decisions reduces the time

taken to achieve consensus.

c. JAD engenders commitment. Traditional methods encourage decisions to be

taken off the cuff in small groups. Here all decisions are in the open.

d. the presence of a senior executive sponsor can encourage fast development

by cutting through bureaucracy and politics

e. the facilitator is crucial to the effort. A facilitator is able to avoid and

smooth many of the hierarchical and political issues that frequently cause

problems and will be free from organisational history and past battles.

3. Construction Phase

The construction phase in RAD consists of taking the user designs through to detailed

design and code generation. This phase is undertaken by IS professionals using CASE

tools. Thus the screens and designs of each transaction are prototyped and approved by

users. If no approval is forthcoming, this stage iterates until an acceptable solution is

found. By prototyping and using CASE tools these iterations are achieved quickly and

testing is enabled.



Construction is performed by small teams of three or four experts in the use of CASE

tools. Using this approach, it is argued that the core of a system can be built relatively

quickly, typically in four to six weeks and then it is progressively refined and integrated

with other aspects developed by other team members.

Once the detailed designs have been agreed, the code can be generated using the CASE

tool and the system tested and approved.

4. Cutover

The final phase is cutover, and this involves further comprehensive testing using realistic

data in operational situations. Users are trained on the system, organizational changes,

implied by the system are implemented and finally the cutover is effected by running the

old and new systems in parallel, until finally the new system has proved itself and the old

system is phased out.

RAD adopts an evolutionary approach to development and implementation. Typically it

recommends implementation of systems in 90 days. The objective is to have the easiest

and most important 75% of the system functionality in the first 90 days, and the rest in

subsequent 90 day chunks



There are four types of information systems prototyping:

1. Feasibility Prototyping

Used to test feasibility of a specific technology that might be applied for an information system.

2. Requirements Prototyping (Discovery Prototyping)

Used to discover the users business requirements. It is intended to stimulate users

thinking. "The concept assumes that the users will recognise their requirements when they

see them.”

3. Design Prototyping (behavioural Prototyping) This is used to simulate the design of the final information system. Whereas requirements

prototyping focuses on content only, design prototyping focuses on form and operation of

the desired system. When an analyst creates a designed prototype, users are expected to

evaluate that prototype as if it were part of the final system. Users should evaluate the

user friendliness of the system and the "look and feel" of the screens and reports.

4. Implementation Prototyping - sometimes called production prototyping This is an extension of the designed prototyping where the prototype evolves directly into

a production system; implementation prototyping became popular with increased

availability of

4th generation languages and application generators. These database languages and

generators provide a powerful tool for quickly generating prototypes of files, databases,

screens, reports and the like. 4GLs tend to be less procedural than traditional languages

like COBOL, BASIC etc. By less procedural we mean that the code is more English like and

in many ways allows you to specify "what” the system should do without specifying "how"

to do it.



Unified Modeling Language (UML) The Unified Modeling Language (UML) is a graphical language for visualizing,

specifying, constructing, and documenting the artifacts of a software-intensive system.

The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as

programming language statements, database schemas, and reusable software

components."

The important point to note here is that UML is a 'language' for specifying and not a

method or procedure. The UML is used to define a software system; to detail the

artifacts in the system, to document and construct - it is the language that the blueprint

is written in. The UML may be used in a variety of ways to support a software development

methodology (such as the Rational Unified Process) - but in itself it does not specify that

methodology or process.



UML defines the notation and semantics for the following domains:

i. - The User Interaction or Use Case Model - describes the boundary and

interaction between the system and users. Corresponds in some respects to a

requirements model.

ii. - The Interaction or Communication Model - describes how objects in the system

will interact with each other to get work done.

iii. - The State or Dynamic Model - State charts describe the states or conditions

that classes assume over time. Activity graphs describe the workflows the

system will implement.

iv. - The Logical or Class Model - describes the classes and objects that will make

up the system.

v. - The Physical Component Model - describes the software (and sometimes

hardware components) that make up the system.

vi. - The Physical Deployment Model - describes the physical architecture and the

deployment of components on that hardware architecture.

How do you use the UML?

The UML is typically used as a part of a software development process, with the support

of a suitable CASE tool, to define the requirements, the interactions and the elements of

the proposed software system. The exact nature of the process depends on the

development methodology used. An example process might look something like the

following:

1. Capture a Business Process Model. This will be used to define the high level business

activities and processes that occur in an organization and to provide a foundation for

the Use Case model. The Business Process Model will typically capture more than a

software system will implement (ie. it includes manual and other processes).

2. Map a Use Case Model to the Business Process Model to define exactly what

functionality you are intending to provide from the business user perspective. As each

Use Case is added, create a traceable link from the appropriate business processes to

the Use Case (ie. a realisation connection). This mapping clearly states what

functionality the new system will provide to meet the business requirements outlined in

the process model. It also ensures no Use Cases exist without a purpose.



3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and

scenarios. This information unambiguously describes what the Use Case does, how it is

executed and the constraints on its execution. Make sure the Use Case still meets the

business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user

acceptance test scripts to define how the user will test this functionality and what the

acceptance criteria are.

4. From the inputs and outputs of the Business Process Model and the details of the use

cases, begin to construct a domain model (high level business objects), sequence

diagrams, collaboration diagrams and user interface models. These describe the

'things' in the new system, the way those things interact and the interface a user will

use to execute use case scenarios.

5. From the domain model, the user interface model and the scenario diagrams create the

Class Model. This is a precise specification of the objects in the system, their data or

attributes and their behaviour or operations. Domain objects may be abstracted into

class hierarchies using inheritance. Scenario diagram messages will typically map to

class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class

define unit tests and integration tests to thoroughly test i) that the class functions as

specified internally and that ii) the class interacts with other related classes and

components as expected.

6. As the Class Model develops it may be broken into discrete packages and components. A

component represents a deployable chunk of software that collects the behaviour and

data of one or more classes and exposes a strict interface to other consumers of its

services. So from the Class Model a Component Model is built to define the logical

packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software

elements.

7. Concurrent with the work you have already done, additional requirements should have

been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc.

Collect these within the model and keep up to date as the model matures.

8. The Deployment model defines the physical architecture of the system. This work can

be begun early to capture the physical deployment characteristics - what hardware,

operating systems, network capabilities, interfaces and support software will make up

the new system, where it will be deployed and what parameters apply to disaster

recovery, reliability, back-ups and support. As the model develops the physical



architecture will be updated to reflect the actual system being proposed.

9. Build the system: Take discrete pieces of the model and assign to one or more

developers. In a Use Case driven build this will mean assigning a Use Case to the

development team, having them build the screens, business objects, database tables,

and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component

driven build may see discrete software components assigned to development teams for

construction.

10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc.

Track any changes against the related model elements to manage 'scope creep'.

11. Update and refine the model as work proceeds - always assessing the impact of changes

and model refinements on later work. Use an iterative approach to work through the

design in discrete chunks, always assessing the current build, the forward requirements

and any discoveries that come to light during development.

12. Deliver the complete and tested software into a test then production environment. If a

phased delivery is being undertaken, then this migration of built sofware from test to

production may occur several times over the life of the project.

� Note that the above process is necessarily brief in description, leaves much unsaid and may not be how you work or follow the process you have adopted. It is given as an example of how the UML may be used to support a software development project.



Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and

contents using design elements such as classes, packages and objects. Class

diagrams describe three different perspectives when designing a system,

conceptual, specification, and implementation. These perspectives become

evident as the diagram is created and help solidify the design. This example is only meant as an introduction to the UML and class diagrams. If you would

like to learn more see the Resources page for more detailed resources on

UML.

Classes are composed of three things: a name, attributes, and operations.

Below is an example of a class.



Class diagrams also display relationships such as containment, inheritance, associations and others.2 Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of

classes. For example, the class Order is associated with the class

Customer. The multiplicity of the association denotes the number of

objects that can participate in then relationship. For example, an Order

object can be associated to only one customer, but a customer can be

associated to many orders.

Another common relationship in class diagrams is a generalization. A

generalization is used when two classes are similar, but have some

differences. Look at the generalization below:



In this example the classes Corporate Customer and Personal Customer have

some similarities such as name and address, but each class has some of its

own attributes and operations. The class Customer is a general form of both

the Corporate Customer and Personal Customer classes. This allows the

designers to just use the Customer class for modules and do not require in-

depth representation of each type of customer.

When to Use: Class Diagrams

Class diagrams are used in nearly all Object Oriented software

designs. Use them to describe the Classes of the system and

their relationships to each other.

How to Draw: Class Diagrams

Class diagrams are some of the most difficult UML diagrams

to draw. To draw detailed and useful diagrams a person would

have to study UML and Object Oriented principles for a long

time. Therefore, this page will give a very high level overview

of the process. To find list of where to find more information

see the Resources page.



Before drawing a class diagram consider the three different perspectives of the system the diagram will present;

conceptual, specification, and implementation. Try not to

focus on one perspective and try see how they all work

together.

When designing classes consider what attributes and

operations it will have. Then try to determine how instances

of the classes will interact with each other. These are the

very first steps of many in developing a class diagram.

However, using just these basic techniques one can develop a

complete view of the software system.

This example is only meant as an introduction to the UML and

use cases. If you would like to learn more see the Resources page for more detailed resources on UML.

UML class diagrams (Object Management Group 2003) are the mainstay of object-

oriented analysis and design. UML 2 class diagrams show the classes of the system, their

interrelationships (including inheritance, aggregation, and association), and the operations

and attributes of the classes. Class diagrams are used for a wide variety of purposes,

including both conceptual/domain modeling and detailed design modeling. Although I

prefer to create class diagrams on whiteboards because simple tools are more inclusive



most of the diagrams that I’ll show in this article are drawn using a software-based

drawing tool so you may see the exact notation.

In this artifact description I discuss:

• Conceptual class diagrams • Design class diagrams

• How to create UML class diagrams

• Suggested reading

Conceptual Class Diagrams

Figure 1 depicts a start at a simple UML class diagram for the conceptual model for a

university. Classes are depicted as boxes with three sections, the top one indicates the

name of the class, the middle one lists the attributes of the class, and the third one lists

the methods. By including both an attribute and a method box in the class I’m arguably

making design decisions in my model, something I shouldn’t be doing if my goal is

conceptual modeling. Another approach would be to have two sections, one for the name

and one listing responsibilities. This would be closer to a CRC model (so if I wanted to take

this sort of approach I’d use CRC cards instead of a UML class diagram). I could also use

class boxes that show just the name of the class, enabling me to focus on just the classes

and their relationships. However, if that was my goal I’d be more likely to create an ORM

diagram instead. In short, I prefer to follow AM’s Apply the Right Artifact(s) practice

and use each modeling technique for what it’s best at.

Figure 1. Sketch of a conceptual class diagram.



Enrollment is an associative class, also called a link class, which is used to model

associations that have methods and attributes. Associative classes are typically modeled

during analysis and then refactored into what I show in Figure 2 during design (Figure 2 is

still a conceptual diagram, albeit one with a design flavor to it). To date, at least to my

knowledge, no mainstream programming language exists that supports the notion of

associations that have responsibilities. Because you can directly build your software in this

manner, I have a tendency to stay away from using association classes and instead resolve

them during my analysis efforts. This is not a purist way to model, but it is pragmatic

because the other members on the team, including project stakeholders, don’t need to

learn the notation and concepts behind associative classes.

Figure 2 depicts a reworked version of Figure 1, the associative class has been resolved. I

could have added an attribute in the Seminar class called Waiting List but, instead, chose

to model it as an association because that is what it actually represents: that seminar

objects maintain a waiting list of zero or more student objects. Attributes and

associations are both properties in the UML 2.0 so they’re treated as basically the same

sort of thing. I also showed associations are implemented as a combination of attributes

and operations – I prefer to keep my models simple and assume that the attributes and

operations exist to implement the associations. Furthermore that would be a detailed

design issue anyway, something that isn’t appropriate on a conceptual model.



Figure 2. Initial conceptual class diagram.

The on waiting list association is unidirectional because there isn’t yet a need for

collaboration in both directions. Follow the AM practice of Create Simple Content and

don’t over model – you don’t need a bi-directional association right now so don’t model it.

The enrolled in association between the Student and Enrollment classes is also uni-

directional for similar reasons. For this association it appears student objects know what

enrollment records they are involved with, recording the seminars they have taken in the

past, as well as the seminars in which they are currently involved. This association would be

traversed to calculate their student object’s average mark and to provide information

about seminars taken. There is also an enrolled in association between Enrollment and

Seminar to support the capability for student objects to produce a list of seminars taken.

The instructs association between the Professor class and the Seminar class is

bidirectional because professor objects know what seminars they instruct and seminar

objects know who instruct them.

When I’m conceptual modeling my style is to name attributes and methods using the

formats Attribute Name and Method Name, respectively. Following a consistent and

sensible naming convention helps to make your diagrams readable, an important benefit of

AM’s Apply Modeling Standards practice. Also notice in Figure 2 how I haven’t modeled the

visibility of the attributes and methods to any great extent. Visibility is an important issue



during design but, for now, it can be ignored. Also notice I haven’t defined the full method

signatures for the classes. This is another task I typically leave to design.

I was able to determine with certainty, based on this information, the multiplicities for all

but one association and for that one I marked it with a note so I know to discuss it

further with my stakeholders. Notice my use of question marks in the note. My style is to

mark unknown information on my diagrams this way to remind myself that I need to look

into it.

In Figure 2 I modeled a UML constraint, in this case {ordered FIFO} on the association

between Seminar and Student. The basic idea is that students are put on the waiting list

on a first-come, first-served/out (FIFO) basis. In other words, the students are put on

the waiting list in order. UML constraints are used to model complex and/or important

information accurately in your UML diagrams. UML constraints are modeled using the

format “{constraint description}” format, where the constraint description may be in any

format, including predicate calculus. My preference is to use UML notes with English

comments, instead of formal constraints, because they’re easier to read.

How to Create Class Diagrams

To create and evolve a conceptual class diagram, you need to iteratively model:

• Classes

• Responsibilities

• Associations

• Inheritance relationships

• Composition associations

• Vocabularies

To create and evolve a design class diagram, you need to iteratively model:

• Classes

• Responsibilities

• Associations

• Inheritance relationships

• Composition associations

• Interfaces



Classes

An object is any person, place, thing, concept, event, screen, or report applicable to your

system. Objects both know things (they have attributes) and they do things (they have

methods). A class is a representation of an object and, in many ways, it is simply a

template from which objects are created. Classes form the main building blocks of an

object-oriented application. Although thousands of students attend the university, you

would only model one class, called Student, which would represent the entire collection of

students.

Responsibilities

Classes are typically modeled as rectangles with three sections: the top section for the

name of the class, the middle section for the attributes of the class, and the bottom

section for the methods of the class. The initial classes of your model can be identified in

the same manner as they are when you are CRC modeling, as will the initial responsibilities

(its attributes and methods). Attributes are the information stored about an object (or at

least information temporarily maintained about an object), while methods are the things

an object or class do. For example, students have student numbers, names, addresses, and

phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a

student does, which get implemented (coded) as methods. You should think of methods as

the object-oriented equivalent of functions and procedures.

An important consideration the appropriate level of detail. Consider the Student class

modeled in Figure 2 which has an attribute called Address. When you stop and think about

it, addresses are complicated things. They have complex data, containing street and city

information for example, and they potentially have behavior. An arguably better way to

model this is depicted in Figure 4. Notice how the Address class has been modeled to

include an attribute for each piece of data it comprises and two methods have been added:

one to verify it is a valid address and one to output it as a label (perhaps for an envelope).

By introducing the Address class, the Student class has become more cohesive. It no

longer contains logic (such as validation) that is pertinent to addresses. The Address class

could now be reused in other places, such as the Professor class, reducing your overall

development costs. Furthermore, if the need arises to support students with several

addresses during the school term, a student may live in a different location than his

permanent mailing address, such as a dorm information the system may need to track.

Having a separate class to implement addresses should make the addition of this behavior

easier to implement.



Figure 4. Student and address (Conceptual class diagram).

An interesting feature of the Student class is its Is Eligible to Enroll responsibility. The

underline indicates that this is a class-level responsibility, not an instance-level

responsibility (for example Provide Seminars Taken). A good indication that a

responsibility belongs at the class level is one that makes sense that it belongs to the class

but that doesn’t apply to an individual object of that class. In this case this operation

implements BR129 Determine Eligibility to Enroll called out in the Enroll in Seminar system

use case.

The Seminar class of Figure 2 is refactored into the classes depicted in Figure 5.

Refactoring such as this is called class normalization (Ambler 2004), a process in which you

refactor the behavior of classes to increase their cohesion and/or to reduce the coupling

between classes. A seminar is an offering of a course, for example, there could be five

seminar offerings of the course "CSC 148 Introduction to Computer Science." The

attributes name and fees where moved to the Course class and courseNumber was

introduced. The getFullName() method concatenates the course number, "CSC 148" and

the course name "Introduction to Computer Science" to give the full name of the course.

This is called a getter method, an operation that returns a data value pertinent to an

object. Although getter methods, and the corresponding setter methods, need to be

developed for a class they are typically assumed to exist and are therefore not modeled

(particularly on conceptual class diagrams) to not clutter your models.



Figure 5. Seminar normalized (Conceptual class diagram).

Figure 6 depicts Course from Figure 5 as it would appear with its getter and setter

methods modeled. Getters and setters are details that are not appropriate for conceptual

models and in my experience aren’t even appropriate for detailed design diagrams – instead

I would set a coding guideline that all properties will have getter and setter methods and

leave it at that. Some people do choose to model getters and setters but I consider them

visual noise that clutter your diagrams without adding value.

Figure 6. Course with accessor methods (Inching towards a design class diagram).

Associations

Objects are often associated with, or related to, other objects. For example, as you see in

Figure 2 several associations exist: Students are ON WAITING LIST for seminars,

professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor

LIVES AT an address, and so on. Associations are modeled as lines connecting the two

classes whose instances (objects) are involved in the relationship.



When you model associations in UML class diagrams, you show them as a thin line

connecting two classes, as you see in Figure 6. Associations can become quite complex;

consequently, you can depict some things about them on your diagrams. The label, which is

optional, although highly recommended, is typically one or two words describing the

association. For example, professors instruct seminars.

Figure 6. Notation for associations.

It is not enough simply to know professors instruct seminars. How many seminars do

professors instruct? None, one, or several? Furthermore, associations are often two-way

streets: not only do professors instruct seminars, but also seminars are instructed by

professors. This leads to questions like: how many professors can instruct any given

seminar and is it possible to have a seminar with no one instructing it? The implication is

you also need to identify the multiplicity of an association. The multiplicity of the

association is labeled on either end of the line, one multiplicity indicator for each direction

(Table 1 summarizes the potential multiplicity indicators you can use).

Table 1. Multiplicity Indicators.

Indicator Meaning

0..1 Zero or one

1 One only

0..* Zero or more

1..* One or more

n Only n (where n > 1)

0..n Zero to n (where n > 1)

1..n One to n (where n > 1)



Another option for associations is to indicate the direction in which the label should be

read. This is depicted using a filled triangle, called a direction indicator, an example of

which is shown on the offering of association between the Seminar and Course classes of

Figure 5. This symbol indicates the association should be read “a seminar is an offering of

a course,” instead of “a course is an offering of a seminar.” Direction indicators should be

used whenever it isn’t clear which way a label should be read. My advice, however, is if your

label is not clear, then you should consider rewording it.

The arrowheads on the end of the line indicate the directionality of the association. A line

with one arrowhead is uni-directional whereas a line with either zero or two arrowheads is

bidirectional. Officially you should include both arrowheads for bi-directional assocations,

however, common practice is to drop them (as you can see, I prefer to drop them).

At each end of the association, the role, the context an object takes within the association, may also be indicated. My style is to model the role only when the information

adds value, for example, knowing the role of the Student class is enrolled student in the enrolled in association doesn’t add anything to the model. I follow the AM practice Depict

Models Simply and indicate roles when it isn’t clear from the association label what the

roles are, if there is a recursive association, or if there are several associations between

two classes.

Inheritance Relationships

Similarities often exist between different classes. Very often two or more classes will

share the same attributes and/or the same methods. Because you don’t want to have to

write the same code repeatedly, you want a mechanism that takes advantage of these

similarities. Inheritance is that mechanism. Inheritance models “is a” and “is like”

relationships, enabling you to reuse existing data and code easily. When A inherits from B,

we say A is the subclass of B and B is the superclass of A. Furthermore, we say we have

“pure inheritance” when A inherits all the attributes and methods of B. The UML modeling

notation for inheritance is a line with a closed arrowhead pointing from the subclass to the

superclass.



Many similarities occur between the Student and Professor classes of Figure 2. Not only

do they have similar attributes, but they also have similar methods. To take advantage of

these similarities, I created a new class called Person and had both Student and Professor

inherit from it, as you see in Figure 7. This structure would be called the Person

inheritance hierarchy because Person is its root class. The Person class is abstract:

objects are not created directly from it, and it captures the similarities between the

students and professors. Abstract classes are modeled with their names in italics, as

opposed to concrete classes, classes from which objects are instantiated, whose names are

in normal text. Both classes had a name, e-mail address, and phone number, so these

attributes were moved into Person. The Purchase Parking Pass method is also common

between the two classes, something we discovered after Figure 2 was drawn, so that was

also moved into the parent class. By introducing this inheritance relationship to the model,

I reduced the amount of work to be performed. Instead of implementing these

responsibilities twice, they are implemented once, in the Person class, and reused by

Student and Professor.

Figure 7. Inheritance hierarchy.



Composition Associations

Sometimes an object is made up of other objects. For example, an airplane is made up of a

fuselage, wings, engines, landing gear, flaps, and so on. Figure 8 presents an example using

composition, modeling the fact that a building is composed of one or more rooms, and then,

in turn, that a room may be composed of several subrooms (you can have recursive

composition). In UML 2, aggregation would be shown with an open diamond.

Figure 8. Modeling composition.

I'm a firm believer in the "part of" sentence rule -- if it makes sense to say that

something is part of something else then there's a good chance that composition makes

sense. For example it makes sense to say that a room is part of a building, it doesn't make

sense to say that an address is part of a person. Another good indication that composition

makes sense is when the lifecycle of the part is managed by the whole -- for example a

plane manages the activities of an engine. When deciding whether to use composition over

association, Craig Larman (2002) says it best: If in doubt, leave it out. Unfortunately many

modelers will agonize over when to use composition when the reality is little difference

exists among association and composition at the coding level.



A Use Case description will generally include:

i. General comments and notes describing the use case.

ii. Requirements - The formal functional requirements of things that a Use Case must

provide to the end user, such as <ability to update order>. These correspond to the

functional specifications found in structured methodologies, and form a contract

that the Use Case performs some action or provides some value to the system.

iii. Constraints - The formal rules and limitations a Use Case operates under, defining

what can and cannot be done. These include:

a. Pre-conditions that must have already occurred or be in place before the use

case is run; for example, <create order> must precede <modify order>

b. Post-conditions that must be true once the Use Case is complete; for

example, <order is modified and consistent>

c. Invariants that must always be true throughout the time the Use Case operates; for example, an order must always have a customer number.

iv. Scenarios – Formal, sequential descriptions of the steps taken to carry out the use

case, or the flow of events that occur during a Use Case instance. These can include

multiple scenarios, to cater for exceptional circumstances and alternative

processing paths. These are usually created in text and correspond to a textual

representation of the Sequence Diagram.

v. Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios

but graphically portrayed. vi. Additional attributes, such as implementation phase, version number, complexity

rating, stereotype and status.



Activity diagrams describe the workflow behavior of a system. Activity

diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing

the sequence of activities performed. Activity diagrams can show activities

that are conditional or parallel.

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other

modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model

the workflow behind the system being designed. Activity

Diagrams are also useful for: analyzing a use case by

describing what actions need to take place and when they

should occur; describing a complicated sequential algorithm;

and modeling applications with parallel processes.

However, activity diagrams should not take the place of

interaction diagrams and state diagrams. Activity diagrams do

not give detail about how objects behave or how objects

collaborate.



How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the

system. Diagrams are read from top to bottom and have

branches and forks to describe conditions and parallel

activities. A fork is used when multiple activities are

occurring at the same time. The diagram below shows a fork

after activity1. This indicates that both activity2 and

activity3 are occurring at the same time. After activity2

there is a branch. The branch describes what activities will

take place based on a set of conditions. All branches at some

point are followed by a merge to indicate the end of the

conditional behavior started by that branch. After the merge all of the parallel activities must be combined by a join before

transitioning into the final activity state.

Below is a possible activity diagram for processing an order.

The diagram shows the flow of actions in the system's

workflow. Once the order is received the activities split into

two parallel sets of activities. One side fills and sends the

order while the other handles the billing. On the Fill Order

side, the method of delivery is decided conditionally.

Depending on the condition either the Overnight Delivery

activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.



State diagrams

State diagrams are used to describe the behavior of a system. State

diagrams describe all of the possible states of an object as events occur.

Each diagram usually represents objects of a single class and tracks the

different states of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object

through many use cases of the system. Only use state

diagrams for classes where it is necessary to understand the

behavior of the object through the entire system. Not all

classes will require a state diagram and state diagrams are not

useful for describing the collaboration of all objects in a use case. State diagrams are other combined with other diagrams

such as interaction diagrams and activity diagrams.

How to Draw: State Diagrams

State diagrams have very few elements. The basic elements

are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity

section of the state symbol depicts what activities the object

will be doing while it is in that state.

All state diagrams being with an initial state of the object.

This is the state of the object when it is created. After the

initial state the object begins changing states. Conditions

based on the activities can determine what the next state the

object transitions to.



Below is an example of a state diagram might look like for an

Order object. When the object enters the Checking state it

performs the activity "check items." After the activity is

completed the object transitions to the next state based on

the conditions [all items available] or [an item is not available].

If an item is not available the order is canceled. If all items

are available then the order is dispatched. When the object

transitions to the Dispatching state the activity "initiate

delivery" is performed. After this activity is complete the

object transitions again to the Delivered state.

State diagrams can also show a super-state for the object. A

super-state is used when many transitions lead to the a certain



state. Instead of showing all of the transitions from each state to the redundant state a super-state can be used to

show that all of the states inside of the super-state can

transition to the redundant state. This helps make the state

diagram easier to read.

The diagram below shows a super-state. Both the Checking

and Dispatching states can transition into the Canceled state,

so a transition is shown from a super-state named Active to

the state Cancel. By contrast, the state Dispatching can only

transition to the Delivered state, so we show an arrow only

from the Dispatching state to the Delivered state.



Physical diagrams There are two types of physical diagrams: deployment diagrams and

component diagrams. Deployment diagrams show the physical relationship

between hardware and software in a system. Component diagrams show the

software components of a system and how they are related to each other.

These relationships are called dependencies. 1

When to Use: Physical Diagrams

Physical diagrams are used when development of the system is

complete. Physical diagrams are used to give descriptions of

the physical information about a system.

How to Draw: Physical Diagrams

Many times the deployment and component diagrams are

combined into one physical diagram. A combined deployment

and component diagram combines the features of both

diagrams into one diagram.

The deployment diagram contains nodes and connections. A

node usually represents a piece of hardware in the system. A

connection depicts the communication path used by the

hardware to communicate and usually indicates a method such as TCP/IP. See Diagram Below.

The component diagram contains components and

dependencies. Components represent the physical packaging

of a module of code. The dependencies between the

components show how changes made to one component may

affect the other components in the system. Dependencies in a

component diagram are represented by a dashed line between two or more components. Component diagrams can also show

the interfaces used by the components to communicate to

each other.

The combined deployment and component diagram below gives

a high level physical description of the completed system. The

diagram shows two nodes which represent two machines

communicating through TCP/IP. Component2 is dependant on



component1, so changes to component 2 could affect component1. The diagram also depicts component3 interfacing

with component1. This diagram gives the reader a quick overall

view of the entire system.

Components

Componet1

Componet2



The Component Model The component model illustrates the software components that will be used to build the

system. These may be built up from the class model and written from scratch for the new

system, or may be brought in from other projects and 3rd party vendors. Components are

high level aggregations of smaller software pieces, and provide a 'black box' building block

approach to software construction.



Component Notation

A component may be something like an ActiveX control - either a user interface control or

a business rules server. Components are drawn as the following diagram shows:

The Component Diagram

The component diagram shows the relationship between software components, their

dependencies, communication, location and other conditions.



Interfaces Components may also expose interfaces. These are the visible entry points or services that

a component is advertising and making available to other software components and classes.

Typically a component is made up of many internal classes and packages of classes. It may

even be assembled from a collection of smaller components.

Components and Nodes

A deployment diagram illustrates the physical deployment of the system into a production

(or test) environment. It shows where components will be located, on what servers,

machines or hardware. It may illustrate network links, LAN bandwidth & etc.

Requirements

Components may have requirements attached to indicate their contractual obligations -

that is, what service they will provide in the model. Requirements help document the

functional behaviour of software elements.



Constraints

Components may have constraints attached which indicate the environment in which they

operate. Pre-conditions specify what must be true before a component can perform some

function; post-conditions indicate what will be true after a component has done some work

and Invariants specify what must remain true for the duration of the components lifetime.

Scenarios

Scenarios are textual/procedural descriptions of an object's actions over time and

describe the way in which a component works. Multiple scenarios may be created to

describe the basic path (a perfect run through) as well as exceptions, errors and other

conditions.

Traceability

You may indicate traceability through realisation links. A component may implement

another model element (eg. a use case) or a component may be implemented by another

element (eg. a package of classes). By providing realisation links to and from components

you can map the dependencies amongst model elements and the traceability from the

initial requirements to the final implementation. An Example

The following example shows how components may be linked to provide a conceptual/logical

view of a systems construction. This example is concerned with the server and security

elements of an on-line book store. It includes such elements as the web server, firewall,

ASP pages & etc.

Server Components

This diagram illustrates the layout of the main server side components that will require

building for an on-line book store. These components are a mixture of custom built and purchased items which will be assembled to provide the required functionality.



Security Components

The security components diagram shows how security software such as the Certificate

Authority, Browser, Web server and other model elements work together to assure

security provisions in the proposed system.

advanced systems analyis design (uml)

Education

business systems

systems analysts

systems design

systems problems

overview of systems

systems investigation

systems studies

design systems development