Download - System Design
SYSTEMS ANALYSIS AND DESIGN
Cutajar & Cutajar
SYSTEM ANALYSIS 2
INTRODUCTION
� System analysis and design covers the activities involved in developing a new system.
It is the process of analysing particular systems (scientific, business or control), to see if replacement (or upgrading) would yield a more useful, productive and profitable way of performing the businessoperations.
� System analysis and design involves System Analysts.System Analysts are deeply involved:-
� Analyse the data processing requirements of an organisation, in whole or in part;
� Decide what, in consequence, the computing system should do;
� Specify the tasks of the computing system in detail, so that the technical specialists (programmers) can do their work;
� Ensure that the developed computing system works efficiently.
SYSTEM ANALYSIS 3
WHAT IS A SYSTEM?
� A system is a collection of interrelated components that work together to achieve some objective
� Different components making up a system include:� Hardware
� Software
� Collection of data
� Work of a number of people.
� Different components making up the software component of a system include: � inputs
� processes
� stored data
� outputs
� human communication interface (HCI)
SYSTEM ANALYSIS 4
SYSTEM ELEMENTS
� A commercial or industrial enterprise can be defined in terms of system elements:
�Physicale.g. Buildings, raw materials, finished product;
�Procedurale.g. Order processing routines, credit checking procedures;
�Conceptuale.g. Statement of policy, material for products;
�Social e.g. Workers, departments.
SYSTEM ANALYSIS 5
SYSTEM ENVIRONMENT
� The system operates in an environment and relates to that environment, which itself includes various elements.
� Elements relating to the environment include:
�Physicale.g. transport routes;
�Procedurale.g. codes of practice, legal requirements;
�Conceptuale.g. monetary system, political ideologies;
�Sociale.g. trade unions, suppliers, customers.
SYSTEM ANALYSIS 6
SUB-SYSTEMS
� An enterprise can be divided into a number of SUBSYSTEMS defining the functional areas. These include:
�Those dealing with the environment: marketing and purchasing subsystems;
�Those dealing with transformation functions: the production subsystem;
�Those acting in a supportive role: accounting, personnel, and management services subsystems.
SYSTEM ANALYSIS 7
BUSINESS SUBSYSTEMS
� These subsystems are all interconnected. The diagram shown is a ‘simple’ model of business subsystems:
Customers
Marketing
Accounting
ManagementControl
ProductionPersonnel
Purchasing
Suppliers
GoodsOrdersPurchases
Staffingrequired
Payments
OrdersGoods
Deliveries
Deliveries
Schedules
Budgetsand plans
BudgetsFinancial analysis
Budgets
Manpoweranalysis
Payments
Invoices
Orders
� This diagram illustrates the INTERFACES within the business, and hence the type of difficulty that can arise in defining boundaries. Henceforth the difficulties of the system analyst to analyse, design, help implement and review.
SYSTEM ANALYSIS 8
OBJECTIVES OF COMPUTERISATION
� To reduce costs
� Take advantages of the facilities offered by computers
� To increase volume of business
� Better management of information
� Enable long-term forecasts
� Enable better planning.
SYSTEM ANALYSIS 9
TYPES OF DATA PROCESSING SYSTEMS
1. Systems where processing is done periodically (Batch Systems or File Processing Systems)� Large volume of data coming in at regular intervals but where
processing does not have to be done immediately.e.g. Payroll System, Gas billing system, …
2. Database systems (On-Line Systems)� An on-line system is one in which information is available to all
users at their own terminals, although they may not be able to update the information.
� Independent of any individual application
� Store of information to support other data processing systems.
� Remark: In many instances, the above types then use a data communication system to transmit data from one place to another.
SYSTEM ANALYSIS 10
TYPES OF DATA PROCESSING SYSTEMS (cont…)
3. Real time systems� The computer has to keep pace with some external operation,
processing the received data more or less instantaneously and producing results immediately.
a. Process control
e.g. oil refining process which is computer controlled
b. Information storage and retrieval
e.g. medical records system
Though shared data files, by nature of application, a single record is not accessed by more than one user at the same time
c. Transaction processing
e.g. online reservation system
By nature of application, the same record may be accessed by different users at the same time; hence need of data locking
SYSTEM ANALYSIS 11
THE SYSTEM LIFE CYCLE (SLC)
� The development and maintenance of a new software system involves a series of stages - the SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) or simply the SYSTEM LIFE CYCLE (SLC).
� The term ‘life-cycle’ indicates that the process of development and maintenance never ends.
� The development of a system may take from a few weeks to a few years.
� The SLC is a model which tries to maximize the chance of successful project development.
‘7 out of 10 IT projects “fail” in some respect’(OASIG study)
SYSTEM ANALYSIS 12
THE WATERFALL MODEL
� This SLC model consists of a number of stages
� The stages may be characterized and divided in different ways
Project Definition
System study and analysis
Feasibility Study
System Design
Implementation (Coding)
Testing & Integration
Control & Review
SYSTEM ANALYSIS 13
THE WATERFALL MODEL
� The waterfall model is a very rigid model – “a sequence of stages where the output of each stage becomes the input to the next”.
� In a rapidly changing environment and where up-to-date software systems are required, this model does not work
� The model assumes that all system requirements can be identified in advance - in practice, most often, this is not the case.
� This model assumes that users are only to be involved in order to specify system requirements
SYSTEM ANALYSIS 14
THE SPIRAL MODEL
� This method allows the development team to progressively complete a project by repeatedly going through the stages of analysis, design and implementation.
Analysis
Implementation
Design
Analysis
Implementation
Design
Analysis
Implementation
Design
SYSTEM ANALYSIS 15
THE INCREMENTAL-ITERATIVE MODEL
Analysis Design Implementation
Component A Component CComponent B
Analysis
Implementation
Design
Analysis
Implementation
Design
Analysis
Implementation
Design
SYSTEM ANALYSIS 16
THE INCREMENTAL-ITERATIVE MODEL
� The project is divided into subprojects and then the waterfall method is performed on each subproject. Instead of completing functionality of the entire application with each pass, the incremental-iterative method completes components.
� Each component does not necessarily become a deliverable that isusable by a client (though at milestones the components are joined together to create a usable product).
� This approach to project development promotes the development ofreusable code. It promotes the separation of functionality required into different components (e.g. GUI controls, data access …) and it helps clarify exact functionalities required.
SYSTEM ANALYSIS 17
THROW-AWAY PROTOTYPING
The objective is to understand the customer’s requirements and hence develop a better requirements definition for the system
� Mock-up
A ‘mock-up' of the proposed system is produced for demonstration purposes. Prototype has appearance of the final system but lacks any real processing or storage capabilities.
� Trial Prototyping
A simplified working model of proposed system serves for demonstration purposes and also provides an opportunity to try out ideas and investigate specific points of interest.
SYSTEM ANALYSIS 18
RAPID PROTOTYPING
�Also known as Evolutionary PrototypingThe objective is to work with the customer to explore their requirements and deliver the final system. The development starts with the parts of the system which are understood . The system evolves by adding new features as they are proposed by the customer.
� Rapid prototyping is particularly suitable for:
� For small scale systems which are required urgently and which have a limited life.
� When it is difficult to establish a detailed system specification. E.g. AI systems which attempt to emulate human capabilities.
SYSTEM ANALYSIS 19
RAPID PROTOTYPING
Evolutionary development:
Specification
development
validation
Initial version
Intermediateversions
Final version
Outline projectdescription
Concurrent activities
SYSTEM ANALYSIS 20
COMPARISON OF PROTOTYPING STRATEGIES
Remarks re prototyping:
� Throw-away methods aid work done in analysis and design by being incorporated into the development life-cycle
� Evolutionary methods provide short term gains – rapid results but, on long term can become costly, difficult to maintain and tend to be less reliable
SYSTEM ANALYSIS 21
PROJECT DEFINITION
� This initial stage of project development is an attempt to formulate project requirements in broad terms by identifying exact reasons for project selection.
� A steering committee is set up to monitor project progress
� Top management and all users are involved to gain their support and participation.
� Output: An assignment brief i.e. clear definition of problem and objectives
SYSTEM ANALYSIS 22
FEASIBILITY STUDY
� Preliminary survey to determine whether a project should proceed.
� The feasibility study should be conducted quickly and in broad terms but must be sufficiently detailed for management to draw proper conclusions.
� Feasibility study must include consideration of:� TECHNICAL aspects
� ECONOMICAL aspects (incl. COST-BENEFIT ANALYSIS)
� OPERATIONAL (incl. LEGAL) aspects
� SOCIAL aspects
� Hence the main aim at this stage is to rule out bad ideas Example: Proposed project technically possible but too expensive to implement.
SYSTEM ANALYSIS 23
FEASIBILITY REPORT
� The resultant feasibility report should include:
� Recommendations
� Options considered
� Economic justification for the choice (cost-benefit analysis)
� Resource implications on staff, premises, etc…
� Development plans and time-table for introduction
� If, on the basis of the feasibility report, the project is acceptable to the steering committee, a written go-ahead is given to proceed to next stage.
SYSTEM ANALYSIS 24
SYSTEM STUDY AND ANALYSIS – PART I
� This stage covers a review of the existing system leading to a design specification for a new system. (Can help develop ideas for new system) It is a detailed study of current practices, files, documents, working methods, etc.
� Tasks falling within this stage:
1. Define and identify the objectives of the current system
2. Establish sources and types of information
3. Decide on method and collection of data
a. Interviews,
b. Questionnaires,
c. Observation,
d. Documentation study
4. Record, store and retrieve information - collection of current system data.
SYSTEM ANALYSIS 25
SYSTEM STUDY AND ANALYSIS – PART II
5. Process, adapt and present information - Documenting the existing system (if any,) involves the use of charts and other techniques to help understanding and presentation
6. Analyze information (Who What Why When Where How)
a. Are current system objectives valid? And are they being met?
b. Identification of key activities and interrelationships within the current system
c. Identification of strengths and weaknesses of the current system
d. Opportunities and constraints of the current system
e. Establishing the resource use of the current system
SYSTEM ANALYSIS 26
SYSTEM STUDY AND ANALYSIS – PART III
7. Statement of requirements: This is the output report from the current stage of the system life cycle. Ideally, it should be prepared jointly by the users and analysts for management approval. The SOR should include:
a. criticisms of the existing system
b. the findings of the analysis stage and how the system can be improved
c. the objectives of the proposed system
d. a design specification including main interfaces with other systems
e. constraints and sample outputs
f. user responsibilities
g. an update of costs and development plan, and time-tables for introduction
SYSTEM ANALYSIS 27
SYSTEM DESIGN
� This stage is essentially a process of moving from a general outline to a detailed final product. System design leads to a SYSTEM SPECIFICATION that should:
� Provide a basis of agreement and a source of reference between management, users and analysts.
� Serve as a specification of software programs, dialogues and manual procedures within the system.
� The system specification should be presented to the steering committee for approval.
� Structure of system specification:
SYSTEM ANALYSIS 28
CODING STAGE
� Most time-consuming stage of system development life-cycle.
� Program development stage involves programming techniques.
� Modules coded are tested, during coding, according to the test plan designed earlier (during the design stage)
� This stage is complete when all code is written, documented and successfully compiled.
SYSTEM ANALYSIS 29
CODING
� Most time-consuming stage
� Requires a lot of effort (hence expensive)
� Choice of programming language is important
� Aids to save time and money� Use of higher level languages, visual languages …
� Facilitative IDEs (Integrated Development Environments)
� Code reuse - existing library subroutines or classes, existing modules, …
� other RAD (Rapid Application Development) tools such aso screen painting software,
o report generators,
o application generators …
SYSTEM ANALYSIS 30
SELECTION OF PROGRAMMING LANGUAGE
When a program needs to be written for a particular application, selection of the language may be based on:
�Which languages have special features most appropriate to the application area
�Whether the choice of a particular language would substantially reduce development time
�Whether the programmers have the time and/or expertise to master a new language
�Whether a suitable compiler exists for the hardware the system being developed is intended to use
SYSTEM ANALYSIS 31
PROGRAM ERRORS
� Program Errors : A program may have any or all of four types of errors:
� Syntax Errors: A statement in the program violates a rule of the language,
� Semantic Errors: Violating rules of language, semantic errors are concerned with the meaning of language statements (semantics).
� Logical Errors: The program runs to completion but gives wrong results or performs wrongly in some way.
� Runtime Errors: Program crashes during execution.
� The translator detects syntax and semantic errors but the translator does NOT detect Logical and Run-time errors. These require rigorous testing for detection and correction possibly with the aid of a debugger.
SYSTEM ANALYSIS 32
PROGRAM TESTING
� There are two ways of approaching testing :
�Functional Testing (Black box testing)
Based on typical, extreme and invalid data values that are representative of those covered by the specification.
�Logical Testing (White box testing)
Based on examining the internal structure of the program and selecting data which gives rise to the alternative cases of control flow.
� Remarks:� Functional testing is not adequate by itself.
� Logical testing by the programmer during program development is most effective.
SYSTEM ANALYSIS 33
TEST DATA AND TEST CASES
�Test data must include:
�Valid values,
�Invalid values
� limit values
�Select test cases such that:
�Every statement in the program is executed at least once.
�The effectiveness of all sections of code that detects invalid input is tested.
�The accuracy of all processing is verified.
�The program operates according to its original design specifications.
SYSTEM ANALYSIS 34
THE TESTING PROCESS
� Except for small programs, systems should not be tested as a single unit. Large systems are built out of sub-systems, which are built out of modules, which are composed of object classes (or procedures and functions – depending on the design (and language) paradigm adopted. The testing process should therefore proceed in stages where testing is carried out incrementally in conjunction with system implementation.
� In general, the sequence of activities is:
COMPONENT TESTING INTEGRATION TESTING USER TESTING
SYSTEM ANALYSIS 35
TESTING STAGES
� As defects are discovered at any one stage, they require programmodifications to correct them and this may require other stages, in the testing process to be repeated. (regression testing)
Unittesting
Moduletesting
Sub-systemtesting
Systemtesting
Acceptancetesting
ComponentTesting
IntegrationTesting
UserTesting
SYSTEM ANALYSIS 36
UNIT AND MODULE TESTING
� Unit testing Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components.
� Module testing A module is a collection of dependent components such as an object class, an abstract data type or some looser collection of procedures and functions. A module encapsulates related components and so can be tested without other system modules.
SYSTEM ANALYSIS 37
SYSTEM TESTING
� Sub-system testing : This phase involves testing collections of modules which have been integrated into sub-systems. Sub-systems may be independently designed and implemented. The most common problems which arise in large software systems are sub-system interface mismatches. The sub-system test process should therefore concentrate on the detection of interface errors by rigorously exercising these interfaces.
� System testing: The sub-systems are integrated to make up the entire system. The testing process is concerned with finding errors which result from un-anticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its requirements.
SYSTEM ANALYSIS 38
ACCEPTANCE TESTING
� Acceptance testing the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system client rather than simulated test data.
� Acceptance testing may reveal errors and omissions in the system requirements definition because the real data may ‘exercise’ the system in different ways from the test data. Acceptance testing may also reveal that the system facilities provided do not meet the exact users’ needs or the system performance is unacceptable.
� Acceptance testing is sometimes called alpha testing. Bespoke systems are developed for a single client. The alpha testing process continues until the system developer and the client agrees that the delivered system is an acceptable implementation of the system requirements.
� When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the developers. After this feedback, the system is modified and either released for further beta testing or for general sale.
SYSTEM ANALYSIS 39
TEST PLANNING
� Careful test planning is needed to get the most out of testing and to control testing costs.� Test planning is concerned with setting out standards for the testing process.� The major components of a test plan are as follows:
� The testing process.A description of the major phases of the testing process. (maybe as described earlier)
� Requirements traceability.Users are most interested in the system meeting its requirements and testing should be planned so that all requirements are individually tested.
� Test Items.The products of the software process which are to be tested should be specified.
� Testing Schedule.An overall testing schedule and resource allocation for this schedule. This, obviously, is linked tothe more general project development schedule.
� Test recording procedures.It is not enough simply to run tests. The results of the tests must be systematically recorded. It must be possible to audit the testing process to check that it has been carried out correctly.
� Hardware and software requirements.This section should set out software tools required and estimated hardware utilisation.
� Constraints.Constraints affecting the testing process such as staff shortages should be anticipated in this section.
SYSTEM ANALYSIS 40
TESTING STRATEGIES
� A testing strategy outlines the general approach to the testing process. Different testing strategies may be adopted depending on the type of system to be tested and the development process used.
� Some types of testing strategies:
1. Top-down testing where testing starts with the most abstract components and works downwards.
2. Bottom-up testing where testing starts with the fundamental components and works upwards
3. Thread testing which is used for systems (usually real-time) with multiple processes where the processing of a transaction threads its way through these processes
4. Stress testing which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.
5. Back-to-back testing which is used when versions of a system are available. The systems are tested together and their outputs compared.
SYSTEM ANALYSIS 41
IMPLEMENTATION : CROSS-OVER TECHNIQUES
� A complete replacement at one go usually taking place during a slack period.
� It is cheap, simple, clear-cut method but risky because there is no fallback position.
� Used when� Users have previous experience of computerisation
� The new system is not directly comparable with the old
� The time scale is tight
� Resources are limited e.g. no extra staff
� The system is small
Old System
New System
�Straight (Direct) Changeover
SYSTEM ANALYSIS 42
IMPLEMENTATION STAGE
� Project Management
The planning and scheduling of resources, staff, equipment, …
� Staff training and education
Without interrupting flow of work, good courses and manuals
� File conversion
Reformatting files for the new system
� Documentation check
Ensuring comprehensive and up-to-date systems
� Deciding on method of changeover
Switching over from the old system to the new system
� Handover
SYSTEM ANALYSIS 43
IMPLEMENTATION : CROSS-OVER TECHNIQUES
� Parallel Changeover
� Includes a period when the old and the new system run in parallel until everyone is satisfied that the new system is running successfully and then the old system is dropped.
� Expensive changeover – involves more work
� Difficult to make comparisons between the results obtained by both systems
� Less risky – standby facilities, useful cross check, gradual changeover.
Old System
New System
SYSTEM ANALYSIS 44
IMPLEMENTATION : CROSS-OVER TECHNIQUES
� Phased (Incremental) Changeover
� The changeover is in a number of stages rather than all at once.
� The division may be based on:� Location – say, one branch of a retail group each month
� Subsystem –say, sales order processing system, then payroll system, then accounting system, …
� Subfile – say, in a customer account file, names beginning A – F, then G-L, …
� Spreads the burden of the workload over time
� Presents an opportunity to learn from problems of a previous phase
� Takes longer than other changeover methods
� Difficult to control a system working in two modes
New SystemOld System
SYSTEM ANALYSIS 45
IMPLEMENTATION : CROSS-OVER TECHNIQUES
� Sometimes a part of the system which can be treated as an entity is upgraded. E.g. the stock control system of a single shop which forms part of a whole retail chain.
� The changeover of the entity is done using direct or parallel changeover.
�When the pilot implementation is satisfactory, the project to upgrade the whole system is undertaken.
Old
New
Old
New
Pilot
SYSTEM ANALYSIS 46
CONTROL AND REVIEW STAGE
� Control
� Setting and redefining standards against which performance can be compared.
� Measuring planned against actual performance
� Taking corrective action where necessary so that system meets its objectives
� Review
� At predefined intervals of time, system should be reviewed to give overall picture of progress made
� Findings help any subsequent system analysis
SYSTEM ANALYSIS 47
SYSTEM MAINTENANCE
�System maintenance implies another system life cycle.
�MAINTENANCE may be:
�Adaptive maintenance due to identified new requirements
�Corrective maintenance due to identified errors
�Perfective maintenance due to identified improvements to the existing set up.
�Aids to maintenance:�Modular design�Use of structured system development techniques�Readable Code�Good Documentation
17%
18%
65%
Corrective Adaptive Perfective
SYSTEM ANALYSIS 48
DOCUMENTATION
Documentation may be presented in different forms:
� Manuals
� Online help
Documentation types:
� User Manual
� Operations Manual
� Technical Manual
(program listing includes inline documentation)
SYSTEM ANALYSIS 49
USER MANUAL
Typical information:
� Overview of options available
� Guidance on the sequence of operations to follow
� Screen shots showing screen input forms
� Instructions on how to enter data
� Sample report layouts
� Error messages that may be displayed and what action to take
SYSTEM ANALYSIS 50
OPERATIONS MANUAL
The operations manual includes all the procedures necessary to run the system.
Typical information:
� System setup procedures, including details for each application of the files required and consumables requirements
� Security procedures
� Recovery procedures in the event of system failure
� A list of system messages that might appear on the operator’s console and what action to take
SYSTEM ANALYSIS 51
TECHNICAL MANUAL
Typical information included in the technical manual:
� Overall system plan
� Data organisation and flow
� Full annotated listing
� Details of test data and results
SYSTEM ANALYSIS 52
DECISION TABLES
� A DECISION TABLE is a tabular representation of expressing process (decision) logic.
� Decision tables are used to analyze problems.
� Conditions applying to the particular problem are identified; and the actions to be taken as a result of any combination of the conditions arising are set out.
ACTION ENTRIES
ACTIONS
CONDITION ENTRIES
(Outcome)
CONDITIONS
(Questions)
SYSTEM ANALYSIS 53
DECISION TABLES - EXAMPLE
Example: Discounts allowed on customers’ order are required to comply with the following policy:“Any order from a credit-worthy customer attracts a discount of 5% if the order amounts to €500 or more, and a discount of 3% if the order amounts to less than €500. Other circumstances must be referred to the supervisor for a decision.
XXRefer to supervisor
XAllow discount of 5%
XAllow discount of 3%
Actions
NYNYIs credit-worthy customer?
NNYYIs order €500 or more?
4321Conditions
Rules
SYSTEM ANALYSIS 54
DECISION TABLES - EXERCISE
Use a decision table to represent the following system logic:
A credit union pays interest to its depositors at the rate of 6% per year. A number of constraints to this policy are:
� Accounts of less than €100 are not paid interest.
� Accounts of less than €1,000 are paid the normal 6%,
� Accounts of €1,000 or more that have been with the union for more than one year get paid the normal 6%, plus a bonus of 1%.
SYSTEM ANALYSIS 55
MODULARITY
A module is a self-contained subprogram, which performs independently one specific task.
Advantages in using modules� Re-usability
� Easier to read, debug and maintain (update)
� Natural division of work
Remarks� Modules can be compiled separately
� Driver program is required to further test modules
PROCESSINGInput
ONE entry point
Output
ONE exit point
SYSTEM ANALYSIS 56
TOP-DOWN MODULAR APPROACH
� Problem is broken down into a number of components modules. Each component is progressively decomposed into smaller, more manageable components until each component (or module) can be easily comprehended.
Problem
Module A
Module A [1] … Module A [n]
Module B
Module B [1] … Module B [n]
Module A1 [1] … Module B1 [1] …
SYSTEM ANALYSIS 57
BOTTOM-UP MODULAR APPROACH
� Individual manageable modules are initially identified; progressively these are combined to form larger modules until the original problem is fully addressed.
� Method recommendable only in the case of experienced programmersand the existence of a library of previously developed modules
Module A[1] Module A[2] Module B[1] Module B[2]
Module A Module B
Original Problem
SYSTEM ANALYSIS 58
STRUCTURE CHARTS
� Structure charts are used to represent the high level modular design of a programming project.
� Consider the following structure chart for solving a teacher’s examination results processing problem:
Process Examination Results
Input Details Process Details Output Details
InputResults
Validate input
Determine Grade
Category
Determine Grade Counts
Print Individual Results
Print Statistical Summary
Print Error Listing
Exercise: Draw a structure chart to representing the issuing of reminder
letters for borrowers in a book library system
SYSTEM ANALYSIS 59
DATA FLOW DIAGRAMS
� Data Flow Diagrams (DFDs) provide a pictorial representation for recording:
o Where the data originates
o What processing is performed on it (data) and by whom
o Who uses the data
o What data is stored and where
o What output is produced and who receives it.
SYSTEM ANALYSIS 60
DFD SYMBOLS
Source/destination
Process
Data store
Data flow
An operation performed on the data.A process will use or alter the data in some wayE.g. sorting, using data to print a report.
A data source or destination which is extended to the system. E.g. people/departments who provide data or receive output
Data store denotes object where the data is stored. E.g. data file, transaction file, input document, report
The arrow represents the movement of data between entities, processes or data stores.Arrows should be clearly labelled to show what data is being transferred. Do not draw data flow directly between data stores and external entities - there should be a process box between them to show the operation performed
SYSTEM ANALYSIS 61
LEVELLED DFDs
� Since it is often impossible to represent a complete system in a single diagram, two or three levels of data flows may be used each showing progressively more detail.
� Consider the following example:
The payroll system of ABC LTD:-
At the end of each week, time sheets are collected and sent to the salaries department. Here, the payroll data is entered via a key-to-disk system, verified and validated, producing a new valid transaction file on disc and an error report. This file is used to update the employees master file , issue payslips and electronically transfer payment to employees’ bank accounts.
SYSTEM ANALYSIS 62
PAYROLL SYSTEM:- TOP-LEVEL DFD
Process Payroll
Time sheets
Payroll summary data
Cheque and payslip data
Employees
Employees
AccountsDepartment
Top level showing a single process:
SYSTEM ANALYSIS 63
PAYROLL SYSTEM :- SECOND LEVEL DFD
Employee number, hours worked, batch control total
Employee number, total pay, deductions… for all employees
Rate of pay, tax code…
Batch time
sheets
Time sheets Time sheet data and batch control totals
Verify and
validate
Valid weekly transaction file
Invalid data batch and control totals
Prepare payroll
Employee number, name, total pay, deductions…
Cheques and payslips
Employee number, hours worked
Print Payroll
Summary
Print and distribute cheques
and payslips
Employee number, total pay, deductions… for all employees
Employee
AccountsDepartment
Employee
Error Report
Employeefile Year-to-date pay…
validated data
SYSTEM ANALYSIS 64
STOCK CONTROL SYSTEM QUERY:- TOP-LEVEL DFD
� In relation to this query, the user provides the stock number and the system outputs the item’s description and quantity of item in stock.
� Top-level DFD to this query:
Stock ReportRequest
Stock Number
Stock description and
quantity in stock
Stock fileEnd User
Query request input
Unformatted query request output
SYSTEM ANALYSIS 65
STOCK CONTROL SYSTEM QUERY:-SECOND LEVEL DFD
Validation process Stock file
Description of stock report
Stored output formats
Stock number
Stock file processing
Select report output format
Stock Description
Valid Stock Data
User
SYSTEM ANALYSIS 66
DFD EXERCISE
� A student can register by mail for a college course by submitting a registration form with their name, ID number and the number of courses they wish to take. The system verifies that the course is not full and enrolls the student on each course for which a place is still free. The course file and student master files are updated and a confirmation letter is sent to the student to notify them of their acceptance or rejection for each requested course.
� Draw a DFD diagram illustrating how data flows through this student registration system.
Second level DFD Solution: Heathcote& Langfield, “‘A’ level Computing”, 5th ed. p.319
SYSTEM ANALYSIS 67
FLOW CHARTS
� A FLOWCHART is a graphical representation of the sequence of operations in a system or program.
� A SYSTEM FLOWCHART is used to show how data flows from source documents through the computer (system) to final output distribution – it gives a complete overview of a system. E.g. Sequential file processing diagram
� A PROGRAM FLOWCHART shows the sequence of instructions to achieve a particular task (algorithm).
SYSTEM ANALYSIS 68
FLOW CHARTS SYMBOLS
Printed output Communications links
Data preparation
Manual operation
Tape/sequential access medium
Sort processManualInput
Off-page connector
DiskDirect Access
storage
Start/end Process Input/Output DecisionPre-defined Process
Connector Flow
SYSTEM ANALYSIS 69
SYSTEM FLOWCHARTS
Update Process
MF
OldMF
NewMF
SEQUENTIAL FILE UPDATE PROCESS
Data validation
Display input data
Data Entry
Collection ofDocuments
ErrorReport
TransactionFileKEY-TO-DISK
INPUT SYSTEM
Example 1:
Example 2:
SYSTEM ANALYSIS 70
PROGRAM FLOWCHART
Y
Start
Read inputName,index,
Mark
IsMark = -1?
PrintIndex number
IsMark<40?
IsMark<70?
Print “FAIL” Print “PASS” Print “CREDIT”
Total CountT = F+P+C
Print F/T*100% P/T*100%C/T*100%
IncrementCredit countC=C+1
IncrementPass countP=P+1
IncrementFail countF=F+1
End
NY
N
N
Y
EXAMINATION RESULTS PROCESS
SYSTEM ANALYSIS 71
PROGRAM FLOWCHART (Another Example)
Start
Input N
F = 1M = 1
End
F = F * M
M = N ?
M = M + 1
Print F
COMPUTING FACTORIAL N (N!)
N! = 1*2*3* … *N
ExerciseDraw the flowchart for the algorithm which generates the first N terms of the fibonaccisequence where N is specified by the user.
Fibonacci Sequence 0 1 1 2 3 5 8 …
SYSTEM ANALYSIS 72
PSEUDOCODE
� PSEUDOCODE represents a way how we can express the sequence of instructions to achieve a particular task (algorithm) independently of any programming language.
� Pseudocode consists of English-like statements very close to the target programming language to be used for developing the software.
Examples:
SWAP TWO INTEGER VARIABLES
Assume swap integer variables X, YDeclare integer Temp
Temp = XX = YY = Temp
CHECK WHETHER AN INTEGER VARIABLE IS EVEN OR ODD
Assume Integer variable Xif (X modulo 2 == 0)output message “even”else output message “odd”
EXERCISE: Use pseudocode for expressing the algorithm which generates factorial n (n!)
SYSTEM ANALYSIS 73
ENTITY-EVENT MODELLING
� An ENTITY-EVENT MODEL is an abstract representation of how the entities of a system are effected by business events - business events trigger processes which in turn affect entities.
� An Entity-Event Model identifies business events and defines the effects which these events have on the system’s entities. It also defines the order in which these events take place.
� Entity-event modeling (similar to Jackson System Development techniques), is a technique used in relation to the SSADM standard.
SYSTEM ANALYSIS 74
ENTITY-EVENT MODEL
� An entity-event model consists of
� A set of entity life histories (ELH),
� A set of effect correspondence diagrams (ECD)
� An Entity Life History shows the sequence of effects which business events cause on a particular entity type.
� An Effect Correspondence Diagram shows the effects of business events from the event’s point of view – shows which entities are effected by a particular event.
SYSTEM ANALYSIS 75
ENTITY LIFE HISTORIES
A is a structural component which shows that effect B is followed by effect C
A
B C
SEQUENCE
A
B° C°
A is a structural component which shows that either effect B takes place or effect C but not both
SELECTION
A
B*
A is a structural component which shows that effect B takes place 0 or more times
ITERATION
PARALLELISM
A
B
D*
C
E*
A is a structural component which shows that either, both (in any order and any number of times), or neither of effects D and E may occur
� Entity life histories are drawn using the structured design (orprogramming) constructs of sequence, selection, iteration and parallelism
SYSTEM ANALYSIS 76
ELH EXAMPLE
BOOK
New Book Acquisition Book DiscardedLibrary Book Life
Book details changes
Book State°
Book available changes
Book details change* Book available change*
Book Borrowed° Book Returned°
The top node represents the entity, the next level nodes denote the organization of events, the next level nodes denote the individual events which change the entity, and the lowest level nodes denote the tasks which achieve the higher level nodes.
SYSTEM ANALYSIS 77
EFFECT CORRESPONDENCE DIAGRAMS
� Effect Correspondence Diagram are drawn in relation to ELH. All entities effected by an event are listed.
Book borrowed
Loan
Book
The event ‘book borrowed’ effects the LOAN and
BOOK entities
Place order
Order
Orderline
Set of orderlineoccurrences*
The event ‘place order’ effects several occurrences of the
ORDER entity
Booking
Booking
Provisional°
The event ‘booking’ can effect the booking entity in
different ways
Confirmed°
SYSTEM ANALYSIS 78
ELH – Another Example
� Draw the EHL diagram for the entity Borrower in the context of a book library system
BORROWER
New Membership End MembershipLibrary Member Life
Borrower detail changes
Borrower’s address°
Borrower detail change*
Borrower’s Tel.No.°
SYSTEM ANALYSIS 79
USE CASE DIAGRAMS
� The USE CASE diagram is used to give a high level view of the system, depicting who will use the system and what they will be able to do with it.
� There are four basic components to USE CASE diagrams:
actorUse case
relationshipupdate
inventory
administrator
system
Prepare report
administrator manager
updateinventory
View report
SYSTEM ANALYSIS 80
USE CASE DIAGRAMS : GENERALISATION
� GENERALIZATION is a technique used to indicate inheritance of an item. Generalization can be applied to both actors and use cases to indicate inheritance of functionality from parents.
The generalized actor plays a more specific role in the system
phone order sale
generalized actor generic actor walk-in sale
sales persontelephone operator
sale
phone order
SYSTEM ANALYSIS 81
USE CASE DIAGRAMS : RELATIONSHIPS
� INCLUDE and EXTEND are two ways of relating use cases which are highly related to each other.
� These relationships help you to identify where you can reuse functionality during system design.
updateinventory
loadinventory
saveinventory
<<include>>
<<include>>
verifycredit card
sale<<extend>>
The EXTEND relationship is used to identify when a use case can optionally be extended by functionality in another use case
SYSTEM ANALYSIS 82
CREATING USE CASE DIAGRAMS
� Steps to follow in creating USE CASE diagrams:
� identify the actors and use cases in the system
� Prioritize the use cases
� Detail each use case
� Structure the case model
� Prototype user interfaces
� Example:
A system is required to:� Allow teachers to record and update students’ results; and notify guardians if individual students’ results are not satisfactory
� Allow teachers, students and the administrator to view results recorded
� Enable the administrator to generate students’ reports
SYSTEM ANALYSIS 83
“STUDENTS’ RESULTS” USE CASE DIAGRAM
� Recording students’ results:
update grades
teacher
student
record grades
view grades
save grades notify guardian
<<include>>
<<include>><<extend>>
load grades<<include>>
administrator
generatereports
<<include>>
SYSTEM ANALYSIS 84
EXERCISE
� Create a use case diagram for the following business requirements of a point-of-sale (POS) system:� The system will allow the administrator to run inventory reports by loading inventory data from disk
� The administrator can update the inventory by loading and savingthe inventory data to and from a disk
� A sales clerk records walk-in sales
� A telephone operator is a special type of sales clerk who handles phone orders
� Any kind of sale must update the inventory
� A sale may need to verify a credit card if the purchase is a credit card purchase
� A sale may need to verify a check if the purchase is a check purchase.
SYSTEM ANALYSIS 85
SOLUTION
Updateinventory
administrator
telephone operator
run inventoryreports
phone-insale
save inventory
verify credit card
<<include>>
<<include>>
<<extend>>
load inventory
<<include>>
sales clerk
sale
<<include>>
walk-insale
verify check<<extend>>
SYSTEM ANALYSIS 86
CLASS DIAGRAMS
� A CLASS DIAGRAM consists of classes and their relationships to each other.
� The main components of a class are attributes and operations.
� Formal notation of a class:
ClassName
- attribute 1- attribute 2- attribute 3
+ operation 1 ()+ operation 2 ()+ operation 3 ()
Visibility:plus (+) signifies that the member is visible.minus (-) signifies that the member is private.hash (#) signifies that the member is visible only to classes of the same system – protected.
Remarks:•Depending on the detail you want to communicate, only the first compartment is a must. •Note the difference between a hidden compartment and an empty compartment
SYSTEM ANALYSIS 87
RELATIONSHIPS
� Two classes can relate to each other with a line and an association name:
Teacher Classteaches >
� Multiplicity allows us to indicate how many objects of one class relate to one object of another class.
Teacher Classteaches >
1 1..*
Exercise: Extend the above class diagram to include another class named “Student” where a given student may take from four to six classes at any one time and a class includes fifteen or thirty students.
SYSTEM ANALYSIS 88
INHERITANCE
� Inheritance is a way of allowing one class to gain the functionality of another class
Animal
Feline Bird
Vehicle Weapon
Tank
� Say, classes LION and TIGER, in turn, inherit the functionality of the class FELINE - inheritance hierarchies
� Classes can be derived from more than one superclass –multiple inheritance
SYSTEM ANALYSIS 89
POLYMORPHISM
� Polymorphism is the ability of two or more abstract classes to have the same interface but operate on their data differently because each has its own section of code.
Animal
NumberOfEyesNumberOfLegs
+Eat()+Sleep()
Feline
+Run()+Sleep()
Bird
+Fly()+Sleep()
Say, we use polymorphism to model the fact that each animal sleeps differently – felines sleep lying down while birds sleep standing up
SYSTEM ANALYSIS 90
EXERCISE
Create a Class Diagram using the following information:
� A student can be an undergraduate or a graduate student
� An undergraduate student can be a type of tutor
� A tutor tutors a student
� A teacher and a professor are two types of instructors
� A teacher assistant can assist a teacher and a professor, but a teacher can be assisted by only one assistant, while a professor can be assisted by up to five assistants
� A teacher assistant is a type of graduate student
SYSTEM ANALYSIS 91
SOLUTION
Tutor Instructor
Teacher
Student
Undergraduate Graduate
tutors>
Professor
Teacher Assistant
<assists assists>
0..1
1
0..5
1
SYSTEM ANALYSIS 92
SOME SDLC STANDARDS: UML & SSADM
� Both UML and SSADM are standards within the SDLC study field.
� Each has its own strengths and weaknesses
� A comprehensive overview SSADM
� A comprehensive UML tutorial (overview)
� A comparison of SSADM and UML