Advanced Systems Analyis Design (UML)

HND ICT: Advanced Systems Analysis & Design
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:
rmmakaha@gmail.com 1
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:

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.

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.

· 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:-
Maintenance
Post Implementation Review
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
Implementation
Testing Physical Design

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

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. 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

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
Invoicing Supplier
Payroll Production Control
Largely ignored
by computer
Sales Order
Processing
Ledger
Order
processing
Stock Control
Top (Strategic)
Management
Middle (Tactical)
Management
Operations
Management
Computer
data
processing
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

HND ICT: Advanced Systems Analysis Design
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

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:-

Methods
e.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
Lecturer Technician
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:-
Function Structure
System Data
DFD LDS
Sequence
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.
6 Sales
Calculate VAT
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.
Dispatch Note
Sales System
Supplier
Customer
Goods Order
G.R.N
Customer Order
Returned Goods Note
Supplier Invoice
Supplier Payment
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 1
Dataflow 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
Flow
M1, 1.1
M1 Datastore 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

Phases
JAD Techniques
Requirements Planning
JRP Workshop
User Design
JAD Workshop
Prototyping
CASE
Construction
Prototyping
CASE
Key
Tools
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)

More Related Content

What's hot (20)

Similar to Advanced Systems Analyis Design (UML) (20)

More from Makaha Rutendo (20)

Recently uploaded (20)

Advanced Systems Analyis Design (UML)