1 information systems development (is501) dr.doaa nabil
TRANSCRIPT
1
Information Systems Development
(IS501)
Dr.Doaa Nabil
Chapter (1)
System Development Life
Cycle (SDLC)
2
Systems Development Life Cycle (SDLC) : is a general term used to describe the method and process of developing a new information systemSDLC provides:
StructureMethodsControlsChecklist
Result of that: successful development Without that: risk for
missed deadline, low quality .3
SDLC Models
A framework that describes the activities performed at each stage of a software development project.
4
Build-and-fix model
Waterfall model
Rapid prototyping model
Incremental model
Spiral model
SDLC Models (cont.)
5
Build-and-fix modelBuild-and-fix modelBuilding without specifications or
attempt at designTotally unsatisfactory for large
projectsDifficult to maintain
6
7
Waterfall ModelWaterfall Model Requirements – defines
needed information, function, behavior, performance and interfaces( specification and planning).
Design – data structures, software architecture, interface representations, algorithmic details.
Implementation – source code, database, user documentation, testing, installation, and maintenance.
8
9
When to use the Waterfall When to use the Waterfall ModelModelRequirements are very well known (A set of high
quality, stable user requirements exist )
Product definition is stable
Technology is understood
New version of an existing product
The user require all complete system at once
Previous experience of building similar systems
exist
The duration of the project is two years or less
10
Waterfall StrengthsWaterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff,
track)
Works well when quality is more important
than cost or schedule
11
Waterfall DeficienciesWaterfall Deficiencies
All requirements must be known upfront
Deliverables created for each phase are considered frozen – inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software development – iterations of
phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until it may be too late)
12
Rapid Application Model Rapid Application Model (RAD)(RAD)
Requirements planning phase (a workshop
utilizing structured discussion of business
problems)
User description phase – automated tools capture
information from users
Construction phase – productivity tools, such as
code generators, screen generators, etc. inside a
time-box. (“Do until done”)
Cutover phase -- installation of the system, user
acceptance testing and user training
13
14
When to use RADWhen to use RADReasonably well-known requirementsUser involved throughout the life
cycleProject can be time-boxed Functionality delivered in incrementsHigh performance not requiredLow technical risks System can be modularized
15
RAD StrengthsRAD Strengths Reduced cycle time and improved productivity
with fewer people means lower costs
Time-box approach mitigates cost and schedule
risk
Customer involved throughout the complete
cycle minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code .
Uses modeling concepts to capture information
about business, data, and processes.
16
RAD WeaknessesRAD Weaknesses
Accelerated development process must give
quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be
committed to rapid-fire activities in an
abbreviated time frame.
17
Incremental SDLC ModelIncremental SDLC Model Construct a partial
implementation of a total system
Then slowly add increased
functionality
The incremental model prioritizes
requirements of the system and
then implements them in groups.
Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has been
implemented.
18
19
When to use the When to use the Incremental Model Incremental Model
Risk, funding, schedule, program complexity, or
need for early realization of benefits.
Most of the requirements are known up-front but
are expected to evolve over time
A need to get basic functionality to the market
early
On projects which have lengthy development
schedules
On a project with new technology
20
Incremental Model Incremental Model Strengths Strengths Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced
21
Incremental Model Incremental Model Weaknesses Weaknesses
Requires good planning and design
Requires early definition of a complete and
fully functional system to allow for the
definition of increments
Well-defined module interfaces are required
(some will be developed long before others)
Total cost of the complete system is not
lower
22
Spiral SDLC ModelSpiral SDLC ModelAdds risk analysis,
and 4gl RAD
prototyping to the
waterfall model
Each cycle involves
the same sequence of
steps as the waterfall
process model
23
24
When to use The spiral Model
Some user experience is required to refine and complete the
requirements
Some parts of the implementation may depend on future
technology
New user requirements are anticipated but not yet known
Some user requirements may be significantly more difficult to
meet than others, and it is decided not to allow them to delay a
usable delivery.
25
Spiral Quadrant
Determine objectives, alternatives and
constraints
Evaluate alternatives, identify and resolve risks
Develop next-level product
Plan next phase
Spiral QuadrantSpiral QuadrantDetermine objectives, alternatives and Determine objectives, alternatives and
constraintsconstraints
Objectives: functionality,
performance,hardware/software interface,
critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract,
etc.
Constraints: cost, schedule, interface, etc.26
Spiral QuadrantSpiral Quadrant
Evaluate alternatives, identify and Evaluate alternatives, identify and resolve risks resolve risks
Study alternatives relative to objectives and
constraints
Identify risks (lack of experience, new
technology, tight schedules, poor process,
etc.
Resolve risks (evaluate if money could be
lost by continuing system development
27
Spiral QuadrantSpiral QuadrantDevelop next-level productDevelop next-level product
Typical activities:◦ Create a design◦ Review design◦ Develop code◦ Inspect code◦ Test product
28
Spiral QuadrantSpiral QuadrantPlan next phasePlan next phase
Typical activities◦ Develop project plan◦ Develop configuration management plan◦ Develop a test plan◦ Develop an installation plan
29
Spiral Model StrengthsSpiral Model StrengthsProvides early indication of
insurmountable risks, without much costUsers see the system early because of
rapid prototyping toolsCritical high-risk functions are developed
firstThe design does not have to be perfect Users can be closely tied to all lifecycle
stepsEarly and frequent feedback from usersCumulative costs assessed frequently
30
Spiral Model Spiral Model WeaknessesWeaknesses
Time spent for evaluating risks too large for small or low-risk
projects
Time spent planning, resetting objectives, doing risk analysis and
prototyping may be excessive
The model is complex
Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development phase
activities
May be hard to define objective, verifiable milestones that indicate
readiness to proceed through the next iteration
31
32
Chapter (2)
Information Systems
Development Life Cycle Phases
33
The use of a methodology improves the practice of information
systems development. A methodology may include: A methodology may include:
Methodology
- A series of phases.
- A series of techniques.
- A series of tools.
- A training scheme.
- A philosophy.
Method consists of the collection of data through observation and
experimentation, and the formulation and testing of hypotheses.
What’s the Difference Between What’s the Difference Between “Method” and “Methodology”?“Method” and “Methodology”?
Method: Techniques for gathering
evidence The various ways of
proceeding in gathering information
Methodology: The underlying theory and
analysis of how research does or should proceed, often influenced by discipline
34
Assessing MethodsAssessing MethodsResearch Question(s) is/are keyMethods must answer the
research question(s)Methodology guides application
35
summarysummary
a research method is a technique for (or way of proceeding in) gathering evidence"
methodology is a theory and analysis of how research does or should proceed“
36
37
Techniques include ways to evaluate the costs and
benefits of different solutions and methods to
formulate the detailed design necessary to develop
computer applications.
Techniques
Examples:
- Flowcharts.
- An organization Chart.
- Manual documents specification.
- Grid chart.
- Discussion records.
38
Tools are software packages that aid aspects of
information systems development.
Tools
Examples:- MS Project.
- Power designer.
- Visio.
1-39
A Simple System A Simple System Development ProcessDevelopment Process
Simplified System Development Process
General Problem-Solving Steps
System initiation 1. Identify the problem.
System analysis 2. Analyze and understand the problem.3. Identify solution requirements or
expectations.
System design 4. Identify alternative solutions and choose the “best” course of action.
5. Design the chosen solution.
System implementation 6. Implement the chosen solution.7. Evaluate the results. If the problem is not
solved, return to step 1 or 2 as appropriate.
Systems Development Systems Development Process OverviewProcess Overview
40
System Development System Development Process OverviewProcess Overview
System initiation – the initial planning for a project to define initial project scope, goals, tasks schedule, and budget.
System analysis – the study of a business problem domain to recommend improvements and specify the business requirements and priorities for the solution.
System design – the specification or construction of a technical, computer-based solution for the business requirements identified in a system analysis.
System implementation – the construction, installation, testing, and delivery of a system into production, provide training for the system users.
41
42
1- Initiation (Planning)Phase
It involves determining a solid plan for developing your information
system. It involves the following three primary activities:
1- define the system to be developed
(determine which system is required to support the strategic goals
of organization)
2- set the project scope
( it defines the high level system requirements through writing
project scope document in one paragraph)
3- develop the project plan
( what , when, and who questions of systems activities to be
performed)
43
Chapter (3)
System Analysis
44
system analysis
It involves end users and IT specialists working together to gather, understand , and document the business requirements for the proposed system through writing (Joint Application Development report)
A requirement is a feature that the system must have or a
constraint that it must satisfy to be accepted by the client.
Requirements engineering aims at defining the requirements of
the system under construction.
45
Joint Application Development report
It is a highly structured workshop that brings together users,
managers, and information systems specialists to jointly define and
specify user requirements, technical options, and external
designs( inputs, outputs, and screen)
46
Joint Application Development report
There are numerous of benefits to JAD:
1- it tends to improve the relationship between users, management,
and information systems professionals ( increase confidence between
user and management)
2- it tends to improve the computer literacy of users and managers as
well as the business and application literacy of information systems
specialists
3- it places the responsibility for conflict resolution where it belongs
4- it decrease the total system development time by integrating and
getting multiple interviews into the structured workshop
5- it lowers the cost of the systems development by getting the
requirements correctly defined and prioritized the first time
47
System Analysis Phases
Systems analysis consists of three phases:
1- survey project feasibility ( survey phase)
2- study and analyze the current system ( study phase)
3- define and prioritize users’ requirements ( definition phase)
48
System Analysis Phases (survey phase)
It answer the question “ is this project worth looking at?”
The fundamental objectives of the survey phase are:
1- to identify the problem, opportunities , and ,or directives that initiated this project request
2- to determine if solving the problems exploiting the opportunities, and satisfying the directives will benefit the business
49
System Analysis Phases (survey phase) Survey Phase Activities:
1- Conduct initial interview ( 45-60 minutes) to record lists of people, data, activities, locations and networks, and existing technology, list of problems, opportunities, constraints, ideas, opinions ( fact finding techniques)
2- define the project scope ( of the proposed project through drawing context model that determine the boundaries and scope of the system – data scope- process scope- network scope –function point analysis)
3- classify problems , opportunities, and possible solutions ( a quick fix, enhancement, new development , visibility, priority, and solution in the matrix form)
4- established a proposed project plan
5- present survey findings and recommendations
50
System Analysis Phases (Study phase)
It answer the questions: “ are the problems really worth solving?” “ is a new system really worth building?” ( using JAD in one week and one – three day workshop)
The fundamental objectives of the study phase are:
1- to understand the business environment of the system2- to understand the underlying causes and effects of the problems3- to understand the benefits of exploiting opportunities4- to understand the implications of noncompliance with directives
51
System Analysis Phases (Study phase) Study Phase Activities:
1- assign project roles
2- learn about current system
3- model the current systems
4- analyze problems and opportunities
5- establish new system’s objectives
6- modify project plan and scope
7- review findings and recommendations
52
System Analysis Phases (Definition phase)
It answer the questions: “ What does the user need and want from a new system?”
The fundamental objectives of the definition phase are:
1- to define business ( nontechnical) requirements that address
problems identified with the current system
2- to define business requirements that discover opportunities
identified with the current system
3- to define business requirements that fulfill directives
53
Definition Phase Activities:
1- identify requirements
Requirements engineering includes two main activities:
Requirements elicitation, which results in the specification of
the system that the client understands. It requires the
collaboration of several groups of participants with different
backgrounds. (functional requirements, nonfunctional
requirements, use cases, and scenarios)
Requirements Analysis, which results in an analysis model
that the developers can unambiguously interpret
2- model system requirements through drawing:
* data model diagram to model data requirements for many
new systems that serve at the starting point for designing
files and databases
System Analysis Phases (Definition phase)
54
System Analysis Phases (Definition phase)
•Data flow diagram to model the processing requirements for most new systems that serve at starting point for designing computer based methods and application programs
•Connectivity diagrams that map the above people, data, and activities to geographical locations that serve at start point for designing the communication systems for distributing the data, activities, and people
•3- build discovery prototype ( if necessary)
•4- prioritize business requirements
•5- review requirements specifications
55
System Analysis Modeling and Techniques
1- Functional Decomposition Diagrams
2- Data Flows Diagrams
3- Unified Modeling Language ( Use Case Diagrams ,
Sequence Diagrams)
4- Fact - Finding
56
1- Functional Decomposition Diagrams(FDD)
It is a top –down representation of a function or process ( Structure chart)
Break main business functions down into lower – level functions and processes Course
Administration
Course Enrolment
Course Attendance
Course Completion
Course Assessment
Course Certification
Course Payment
Course Application
57
Functional Decomposition Diagrams(FDD) example
58
2- Data Flows Diagrams(DFD)
It show how the system stores, processes, and transforms data
59
DFD Very popular tool for describing functions of
a system in terms of processes and data used by
them
FDD may be done before DFD or we may
prepare DFDs directly
Have more contents than FDDs
Flow of data is shown, not flow of control
DFDs are simple pictorial representations; easily
understood by users and management.
facilitate top-down development
60
3- Unified Modeling Language ( Use Case Diagrams)
It is widely used method of visualizing and documenting
information systems from a user’s view point
It uses object oriented design concepts, but it is
independent of any specific programming language
It use to describes business processes and requirements
generally
It provides various graphical tools such as use case
diagrams and sequence diagrams
61
Use Case Diagrams
It represents the interaction between users and the information
systems
User becomes an actor, with specific role that describes how he
interacts with the system
Example of use case Example of use case diagramdiagram Web store
Find an item
Order an item
Check order
Customer
Registered customer
Order fast delivery
Free search
Structured search
<<include>>
<<extend>>
Actor (person)
62
63
Teacher
Student
Printing administrator
Grade system
Record grades
View grades
DistributeReport cards
Create report cards
Example of use case Example of use case diagramdiagram
64
Example of use case Example of use case diagramdiagram
65
Sequence Diagrams
It shows the timing of interactions between objects as they
occur
System analyst might use a sequence diagram to show all
possible outcomes or focus on a single scenario
66
getViolation(id)
Example sequence Example sequence diagramdiagram
Clerk
:ViolationsDialog
:ViolationsController
:ViolationsDBProxy
lookupviewButton()
id=getID()
v:TrafficViolation
display(v)
<<create>>
v
Lookup Traffic Violation
May be a
pseudo-method DB is queried
and the result is returned as an object
67
4- Fact -Finding Techniques
It involves answers to five familiar questions: who,
what ,where, when, and how
For each question you must ask another very important
question : why
68
Chapter (4) Part One
System Analysis Models and
Techniques (Data Flow Diagram)
69
System analysts use many graphical models and techniques to
describe an information systems such as:
•Data Flow Diagram (Process and data Modeling)
•Unified Modeling Language (object oriented modeling)
70
System ModelsSystem Models
A model is a representation of reality. Just as a
picture is worth a thousand words, most system
models are pictorial representations of reality.
71
What is Process Modeling?
Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes.
◦ A business user, when questioned will usually focus on the processes of that operation.
◦ A process may be defined as an action or series of actions which produce a change or development.
The process view of a system may be modeled by a Data Flow Diagram
72
A A data-flow diagramdata-flow diagram ( (DFDDFD) is a graphical ) is a graphical representation of the flow of data through an representation of the flow of data through an Information Systems. Information Systems.
*DFD is a Systems Analyst’s Toolkit to describe an *DFD is a Systems Analyst’s Toolkit to describe an information system in a graphical techniques.information system in a graphical techniques.
* * Graphical descriptions of the sources and Graphical descriptions of the sources and destinations of data. They show:destinations of data. They show:Where data comes fromWhere data comes fromHow it flowsHow it flowsThe processes performed on itThe processes performed on itWhere it goesWhere it goes
Data Flow Diagram (DFD)
Advantage
A major advantage of a DFD is a graphical nature that makes a good communication tool between: ◦User and analyst ◦Analyst and System designer
Users are able to visualize:◦ How the system will operate. ◦ What the system will accomplish .◦ How the system will be implemented .
73
Disadvantage A DFD becomes difficult to understand
when it has more than 7 to 9 processes.
◦A DFD does not provide an
information about the timing or ordering of processes whether processes will operate in
sequence or in parallel.
74
Data Flow Diagram Symbols
A data flow diagram consists of four basic elements:External entities (Data sources and
destinations –sink)Data flowsProcessesData stores
75
DFD Symbols (DFDs use four basic symbols)Gane and Sarson
SymbolsSymbols Name Yourdon Symbols
APPLY PAYMENT
ProcessContain Business logic
Identify a specific function
Verb & Adjective
APPLY PAYMENT
BANK DEPOSITData Flow
Represents one or more data item
Noun & Adjective
BANK DEPOSIT
STUDENTS
Data StoreMust be connected to a process with data flow
Noun & Adjective
STUDENTS
CUSTOMER
External EntitySource: supplies data to the system.
Sink: receives data from the system.
Must be connected to a process with data flow
CUSTOMER
76
Data Flow Diagram Symbols
1- External Entities Data sources and destinations (or sink)
◦ Appear as squares◦ Represent organizations, individuals, or organizational units
that send or receive data used or produced by the system An item can be both a source and a destination Used to define system boundaries Named with a noun
77
Data Flow Diagram Symbols
2-Data flows◦ Appear as arrows, named with nouns◦ Represent the flow of data between sources
and destinations, processes, and data stores
◦ A data flow can be used to represent the creation, reading, deletion, or updating of data in a file or database (data store).
◦ At least one end of every data flow should either come from or go to a process.
78
Data Flow Diagram Data Flow Diagram
If two data elements flow together, then the use of one data flow line is appropriate.
CustomerProcessPayment
Cash Rec’t & Remittance Slip
79
Data Flow DiagramData Flow Diagram
If the data elements do not always flow together, then multiple lines will be needed.
CustomerProcessPayment
Customer Inquiry
Customer Payment
80
Data Flow DiagramData Flow Diagram
3-Processes◦ Appear as circles◦ Represent the transformation of data◦ Must be numbered and labeled with a single
action verb and an object◦ Avoid the use of the word “and” in the process
name
81
1.0
Process
Combinations that must be avoidedSpontaneous generation process
Black hole process
Gray hole process
DATA OF BIRTH CALCULATE FINAL GRADE GRADE
1.0
1.0
1.0
Process
Process
82
DATA FLOW DIAGRAMSDATA FLOW DIAGRAMS
4- Data stores◦ Appear as two horizontal lines, named with a noun◦ Represent a temporary or permanent data
repository◦ Flow out of a data store = retrieval◦ Flow into a data store = inserting or updating ◦ Data stores on a DFD are related to entities on an
ERD
83
Data StoreD1
84
Guidelines for Drawing DFDs1. Draw the context diagram so it fits on one
page.2. Use the name of the information system as
the process name in the context diagram.3. Use unique names within each set of
symbols.4. Don’t cross lines.
1. In order to keep the diagram uncluttered, you can repeat Data Stores or External Entity on a diagram.
5. Provide a unique name and reference number for each process, you should not have more than 9 process symbols.
6. Obtain as much user input and feedback as possible.
85
Continue Guidelines for Drawing DFDs
Step 1:Draw the Context Diagram ◦It is a top-level view of an information
system that shows the system’s boundaries and scope.
Step 2: Draw DFD Level-0 ◦It represents a system’s major processes,
data flows and data stores at a high level of detail.
Step 3: Draw the Lower-Level Diagram◦ DFD level 1,2,….
86
Context Diagram
The highest level of DFD is called a context diagram.◦It provides a summary-level view of
the system.◦It depicts a data processing system
and the external entities that are: Sources of its input Destinations of its output
◦The process symbol is numbered with a “0”
87
Context Diagram example
Data store are not shown in the context diagram.
88
DATA FLOW DIAGRAMSDATA FLOW DIAGRAMS
PayrollProcessing
System
Depart-ments
HumanResources
Govt.Agencies
Employees
Bank
Manage-ment
Time cards
New employee form
Employee change form
Tax report &
payment
Employee checks
Payroll checkPayroll report
• This is the context diagram for the S&S payroll processing system .
0
89
DATA FLOW DIAGRAMSDATA FLOW DIAGRAMS
1.0Updateempl.
Payrollfile
2.0Pay
Employ-ees
5.0UpdateGen.
Ledger
4.0Pay
taxes
3.0Preparereports
Employee/Payroll file
GeneralLedger
HumanResources
Depart-ments Employees
Bank
Govt.Agencies
Manage-ment
EmployeeChange
form
New employeeform
Timecards
Employeechecks
Payrollcheck
PayrollDisburse-ment data
Payroll taxdisb. voucher
Tax report& payment
Payrollreport
This diagram shows the next level of detail for the context diagram
90
DATA FLOW DIAGRAMSDATA FLOW DIAGRAMS
1.0Updateempl.
Payrollfile
2.0Pay
Employ-ees
5.0UpdateGen.
Ledger
4.0Pay
taxes
3.0Preparereports
Employee/Payroll file
GeneralLedger
HumanResources
Depart-ments Employees
Bank
Govt.Agencies
Manage-ment
EmployeeChange
form
New employeeform
Timecards
Employeepaychecks
Payrollcheck
PayrollDisburse-ment data
Payroll taxdisb. voucher
Tax report& payment
Payrollreport
Suppose we exploded Process 2.0 (pay employees) in the next level. The sub-processes would be numbered 2.1, 2.2, 2.3, etc.
91
Data Flow Diagram example
Diagram 0 provides an overview of all the components that interact to form the overall system
92
DFD BalanceDFD Balance
CUSTOMER
Transform Customer
Food Order
1.0
Management Report
KITCHEN
RESTAURANTMANAGER
Food OrderCustomer Order
Receipt
UpdateInventory
UpdateGoods Sold
2.03.0
INVENTORYD2GOODS SOLDD1
GoodsSold Data
Inventory Data
Formatted Goods Sold Data
Formatted Inventory Data
Daily InventoryDepletion AmountsDaily Goods
Sold AmountsProduce
ManagementReport
4.0
93
Level 1 DiagramLevel 1 Diagram
ProcessCustomer
Order
1.1
Customer Order
PROCESS 1 ON THE LEVEL 0 DIAGRAM
SUB PROCESS 1 THIS LEVEL 1DIAGRAM
TransformOrder to KitchenFormat
1.3
Customer Order Food Order
GenerateCustomer
Receipt
1.2
Customer Order
Generate Inventory
Decrements
Customer Order
Customer Order
1.5
1.4Generate Good SoldIncrements
InventoryData
Goods Sold Data
ReceiptNOTE HOW WE HAVE THE SAME INPUTS AND OUTPUTS AS THE ORIGINAL PROCESSSHOWN IN THE LEVEL 0 DIAGRAM
94
Another Level 1 DiagramAnother Level 1 Diagram
Management Report
Daily InventoryDepletion Amounts
Daily GoodsSold Amounts Produce
ManagementReport
4.0
4.1Access
Goods Soldand Inventory
Data
Daily GoodsSold Amounts
Daily InventoryDepletion Amounts
Inventory Data
Goods Sold Data
4.2Aggregate
Goods Soldand Inventory
Data
PrepareManagement
Report
4.3 Management Report
ORGINAL LEVEL 0 PROCESS
LEVEL 1 PROCESSES
PROCESSES 2.0 AND 3.0 ON THE LEVEL 0 DIAGRAMDO NOT NEED FURTHER DECOMPOSTION
95
Balancing DFDsBalancing ensure that the input
and output data flows of the parent DFD are maintained on the child DFD.
96
Unbalancing exampleContext Diagram
DFD
97
Data Flow Diagram Rules
Let’s step through some guidelines on how to create a DFD.
RULE 1: Understand the system. Observe the flow of information and interview people involved to gain that understanding.
RULE 2: Ignore control processes and control actions (e.g., error corrections). Only very critical error paths should be included.
RULE 3: Determine the system boundaries—where it starts and stops. If you’re not sure about a process, include it for the time being.
98
Data Flow Diagram Rules
RULE 4: Draw the context diagram first, and then
draw successively greater levels of detail.
RULE 5: Identify and label all data flows.
RULE 6: Data flows that always flow together should
be grouped together. Those that do not flow together
should be shown on separate lines.
RULE 7: Show a process (circle) wherever a data flow
is converted from one form to another. Likewise,
every process should have at least one incoming data
flow and at least one outgoing data flow.
99
Data Flow Diagram Rules
RULE 8: Processes that are logically related or occur
simultaneously can be grouped in one process.
RULE 9: Number each process sequentially. A
process labeled 5.0 would be exploded at the next
level into processes numbered 5.1, 5.2, etc. A
process labeled 5.2 would be exploded into 5.2.1,
5.2.2, etc.
RULE 10: Process names should include action
verbs, such as update, prepare, etc.
100
Data Flow Diagram RulesData Flow Diagram RulesRULE 11: Identify and label all data stores.
RULE 12: Identify and label all sources and
destinations. An entity can be both a source
and destination. You may wish to include such
items twice on the diagram, if needed, to avoid
excessive or crossing lines.
RULE 13: As much as possible, organize the
flow from top to bottom and left to right.
101
Data Flow Diagram RulesData Flow Diagram RulesRULE 14: You’re not likely to get it beautiful
the first time, so plan to go through several
iterations of refinements.
RULE 15: On the final copy, lines should not
cross. On each page, include:
◦ The name of the DFD
◦ The date prepared
◦ The preparer’s name
102
Data Flow Diagram : an Data Flow Diagram : an exampleexample
The first paragraph of the narrative for the payroll process reads as follows:◦ When employees are hired, they complete a new
employee form. When a change to an employee’s payroll status occurs, such as a raise or a change in the number of exemptions, human resources completes an employee change form. A copy of these forms is sent to payroll. These forms are used to create or update the records in the employee/payroll file and are then stored in the file. Employee records are stored alphabetically.
103
DATA FLOW DIAGRAMSDATA FLOW DIAGRAMS
1.0Updateempl.
Payrollfile
2.0Pay
Employ-ees
5.0UpdateGen.
Ledger
4.0Pay
taxes
3.0Preparereports
Employee/Payroll file
GeneralLedger
HumanResources
Depart-ments Employees
Bank
Govt.Agencies
Manage-ment
EmployeeChange
form
New employeeform
Timecards
Employeepaychecks
Payrollcheck
PayrollDisburse-ment data
Payroll taxdisb. voucher
Tax report& payment
Payrollreport
104
Data Flow Diagram Data Flow Diagram SummarySummary
The data flow diagram focuses on the logical flow of data.
Inputs to a process are always different than outputs
Objects always have a unique nameData cannot move directly from a
source to a sink
105
106
Chapter (4) Part two
System Analysis Models and
Techniques (Data Dictionary)
107
A tool for recording and processing information (metadata)
about the data that an organization uses.
A central catalogue for metadata.
Can be integrated within the DBMS or be separate.
May be referenced during system design, programming,
and
by actively-executing programs.
Can be used as a repository for common code (e.g. library
routines
Data Dictionary
108
it is a central store of information about the database (a summary of the
structure of the database).
improved documentation and control
consistency in data use
easier data analysis
reduced data redundancy
simpler programming
the enforcement of standards
better means of estimating the effect of change.
helps DBA manage the database
informs users of database scope
Facilitates communication between users and database administrators
Allows the DBMS to manage the creation, access, and modification of
tables and their components
Benefits of a DDS
109
DDS Facilities
A DDS should provide two sets of facilities:
To record and analyze data requirements independently of
how they are going to be met - conceptual data models
(entities, attributes, relationships).
To record and design decisions in terms of database or file
structures implemented and the programs which access them -
internal schema.
One of the main functions of a DDS is to show the relationship
between the conceptual and implementation views. The mapping
should be consistent - inconsistencies are an error and can be
detected here.
Typical DD ContentsTypical DD ContentsData elements
◦ names, data typeTables
◦ owner, creation date, access specifications, size
Indexes◦ name, attributes involved, creation date
Authorized users◦ names, type(s) of access
Integrity Constraints
110
111
Chapter (4) Part three
System Analysis Models and
Techniques (UML)
112
UML DiagramUML Diagram – – What is UML?What is UML?
The Unified Modeling Language (UML) is a standard language for modeling object-oriented anlyasis
Specifying Visualizing Constructing Documenting
Business Modeling Communications
113
UML Different Diagrams
*Use case diagramsDescribe the functional behavior of the system as seen by the user.
*Class diagramsDescribe the static structure of the system: Objects, Attributes, and Associations.
*Sequence diagramsDescribe the dynamic behavior between actors and the system and between objects of the system.
*State chart diagramsDescribe the dynamic behavior of an individual object as a finite state machine.
*Activity diagramsModel the dynamic behavior of a system, in particular the workflow, i.e. a flowchart.
114
Example of UML
115
A Use Case is a scenario y of using a system that
describes limited interaction between a system and
actors in the field
Use case represents the steps in a specific
business functions or process
It is a complete description of the functionality of the
system and its environment
1- Use Case Diagram
116
The purpose for using use cases is to:
Uncover and describe all tasks that need doing in a
system (of both human and system actors)
To analyse what functionality that need developing
for the system
The use of use cases must mean that the right
functional requirements are made of the IT system
(the requirements of the business)
Purpose of Use Case Diagram
117
Use case strengths:It works well as an analytical tool to represent
external behavior
It is simple and easy to pick up
It is easy to understand, both for the business and
from the technological aspect
It is a widely recognised market standard
customer and supplier – or operators and technicians
– can jointly work out and understand the operational
functionality
It brings structure, and ensure complete analysis
Use cases are documented in two waysUse cases are documented in two waysUse Case diagrams
oGive an overview of visible use scenarios in the system
oDescribes what actors that interact with the system
oDescribes any linkages between use cases
Verbal descriptionoDescribes the content of each use
case oTypically uses a pre-defined template
118
119
Components of Use Case Diagram
1- Actor: external entity represents actor roles, that is, a type of user of the system with stick figure and specific label
2- Use cases: represent a sequence of interaction for a type of functionality ( actor request s the system to perform a specific function with certain label)
3- Association: line from actor to use case
Passenger
Purchase Ticket
120
Example of Use Case DiagramExample of Use Case Diagram
student
registration
updatinggrades
outputgenerating
faculty
Student resisted in a specific course and faculty update student grades and output generating
121
Note that:
Use case can also interact with
other use cases, when the out
comes of one use case is
incorporated by another use case
122
Relationships between Use Cases
1. Generalization - use cases that are specialized versions of other use cases.
2. Include - use cases that are included as parts of other use cases. Enable to factor common behavior.
3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.
123
1. Generalization
The child use case inherits the
behavior and meaning of the
parent use case.The child may add to or
override the behavior of its parent.
parent
child
124
registration
graduateregistration
non-graduateregistration
More about GeneralizationMore about Generalization
125
Example:Draw use case diagram for library system as follow:1- the main actors of the system are : client, supervisor, and employee
2- client can request the system to borrow a certain book or make reservation for it
3- client fine payment for the system
4- employee can also borrow book or order a certain title for the client5- supervisor check orders and fine payment
126
Use Case Diagram Use Case Diagram –– Example1 Example1 (Library)(Library)
A Library System.
client employee
supervisor
library system
borrow
reserve
Order title
Fine payment
127
Use Case Diagram for Student Use Case Diagram for Student Assessment Management Assessment Management System System
Teacher
Student
Printing administrator
Grade system
Record grades
View grades
DistributeReport cards
Create report cards
128
2. Include
The base use case explicitly incorporates
the behavior of another use case at a
location specified in the base.
The included use case never stands alone.
It only occurs as a part of some larger base
that includes it.
base included<<include>>
129
More about IncludeMore about IncludeEnables to avoid describing the
same flow of events several times by putting the common behavior in a use case of its own.
updatinggrades
outputgenerating
verifyingstudent id
<<include>>
<<include>>
130
Passenger
PurchaseSingleTicket
PurchaseMultiCard
NoChange
<<extend>>
Cancel
<<extend>>
<<include>>
CollectMoney
<<include>>
More about Include
131
Use Case – Example (self Use Case – Example (self service machine)service machine)
Close Machine
Restock
Close Machine
Open Machine
<<includes>>
<<includes>>
Collect
Open Machine
<<includes>>
<<includes>>
Buy a product
Restock according to sales
customer
supplier
Self Service Machine
132
3. Extend
The base use case implicitly incorporates the
behavior of another use case at certain
points called extension points.
The base use case may stand alone, but
under certain conditions its behavior may be
extended by the behavior of another use
case.
base extending<<extend>>
133
More about ExtendMore about ExtendEnables to model optional
behavior or branching under conditions.
Exam copy request
Exam-grade appeal
<<extend>>
134
Passenger
PurchaseTicket
TimeOut
<<extend>>
NoChange
<<extend>>OutOfOrder
<<extend>>
Cancel
<<extend>>
More about More about ExtendExtend
135
ExampleExample
placephone call
cellularnetwork
user
receivephone call
placeconference
call
receiveadditional
call
usescheduler
<<extend>>
<<extend>>
Cellular Telephone
Other examplesOther examples
OpenIncident
AllocateResources
HelpDispatcher<<include>>
<<include>>
OpenIncident
AllocateResources
ConnectionDown<<extend>>
<<extend>>
Authenticate
Authenticate
Authenticate
WithPassword
WithCard
136
Use Case Diagram (Narrative Description)
Name: Purchase ticketDescription:
Entry condition: Passenger standing in
front of ticket distributor.
Passenger has sufficient money to purchase ticket.
Exit condition: Passenger has ticket.
Event flow:
1. Passenger selects the number of zones to be traveled.
2. Distributor displays the amount due.
3. Passenger inserts money, of at least the amount due.
4. Distributor returns change.
5. Distributor issues ticket.
137
Use Case Diagrams: SummaryUse case diagrams represent external
behaviorUse case diagrams are useful as an
index into the use casesUse case descriptions provide meat of
model, not the use case diagrams.All use cases need to be described for
the model to be useful.
138
139
University Record System University Record System (URS)(URS)A University record system should keep
information about its students and academic staff.Records for all university members are to include
their id number, surname, given name, email, address, date of birth, and telephone number. ◦ Students and academic staff each have their own unique
ID number: studN (students), acadN (academic employee), where N is an integer (N>0).
In addition to the attributes mentioned above: ◦ Students will also have a list of subjects they are enrolled
in. A student cannot be enrolled in any more than 10 subjects.
◦ Academic employees will have a salary, and a list of subjects they teach. An academic can teach no more than 3 subjects.
140
Some Actions Supported Some Actions Supported by URSby URS The system should be able to
handle the following commands.◦ Add and remove university
members (students, and academic staff)
◦ Add and Delete subjects◦ Assign and Un-assign subjects to
students◦ Assign and Un-assign subjects to
academic staff.
141
Use Case Diagram - URS SystemUse Case Diagram - URS System
systemuser academic
student
URS
delete member
add member
add subject
del subject
assg subject
unass subject
enrol subject
unenrol subject
142
Example. Automatic teller machine (ATM)Withdraw money using a Visa cardSummary: This use case allows a Visa card holder, who is not acustomer of the bank to withdraw money if his/her daily limit allows it.1. The Visa CardHolder inserts his/her smart card in the ATM’s cardreader.2. The ATM verifies that the card that has been inserted is a smartcard.3. TheATM asks the Visa CardHolder to enter his/her pin number.4. The Visa CardHolder enters his/her pin number.5. The ATM compares the pin number with the one that is encodedon the chip of the smartcard.6. The ATM requests an authorisation from the Visa authorisation system7. The Visa authorisation system confirms its agreement and indicatesthe daily withdrawal limit.8. The ATM asks the Visa CardHolder to enter the desiredwithdrawal amount.9. The Visa CardHolder enters the desired withdrawal amount.10. The ATM checks the amount against the daily withdrawal limit.
143
11. The ATM asks the Visa CardHolder if he/she would like a receipt.12. The Visa CardHolder requests a receipt.13. The ATM returns the card to the Visa CardHolder.14. The Visa CardHolder takes his/her card.15. The ATM issues the banknotes and a receipt.16. The Visa CardHolder takes the banknotes and the receipt.Variations: Temporarily incorrect pin numberAt step 5, the Visa CardHolder fails to enter a correct pin number6. The ATM informs the CardHolder that the pin is incorrect for thefirst or second time.7. The ATM records the failure on the smartcard.The scenario goes back to step 3.Variations: The amount requested is greater than the dailywithdrawal limit
2-Class Diagrams
Class diagrams represent the structure of the system.
It represents a detailed view of a single use case
shows the classes that participate in the use case and
documents the relationship among the classes
144
145
Class diagrams are used:during requirements analysis to model
problem domain concepts
during system design to model
subsystems and interfaces
during object design to model classes.
Note that DFD and class diagram is a logical model ( each of them evolve into code modules, data objects)
146
Components of Class Diagram
1- Class : rectangle class name at the top followed by class attributes and methods
2- lines : relationships between classes through label
3- Cardinality: describes how instance of one class relate to instance of another class
0….* zero or many0….1 zero or one1 One and only one1….* one or many
Table zone2priceEnumeration getZones()Price getPrice(Zone)
TariffSchedule
Attributes and operations Attributes and operations visibilityvisibilityAttributes visibilityThey should always be private ( information
hiding)◦Other classes can access an attribute value using get
and set methods
Operation visibility+ : public (the operation is part of the class
interface)- : private (the operation can only be accessed
by the class itself)#: protected (in abstract classes, operations
that can be used by subclasses only). ◦This visibility constraint, in abstract classes, can also
be used for attributes
147
InstancesInstances
An instance represents a phenomenon.The name of an instance is underlined and
can contain the class of the instance.The attributes are represented with their values.
zone2price = {{‘1’, .20},{‘2’, .40},{‘3’, .60}}
tariff_1974:TarifSchedule
Actor vs. InstancesActor vs. InstancesWhat is the difference between an actor and a class and an instance?
Actor: ◦A coherent set of roles that users of use cases play
when interacting with these use cases. An actor has one role for each use case with which it communicates. (UML 1.5 definition)
◦An entity outside the system to be modeled, interacting with the system (“Pilot”) (text book definition)
Class: ◦An abstraction modeling an entity in the problem
domain, inside the system to be modeled (“Cockpit”)
Object: ◦A specific instance of a class (“Joe, the inspector”).
149
AssociationsAssociations
Associations denote relationships between classes.
The multiplicity of an association end denotes how many objects the source object can legitimately reference.
Enumeration getZones()Price getPrice(Zone)
TarifSchedule
* pricezone
TripLeg
*
1-to-1 and 1-to-Many 1-to-1 and 1-to-Many AssociationsAssociations
1-to-1 association
1-to-many association
*
draw()
Polygon
x:Integery:Integer
Point1
Has-capital
name:String
Country
name:String
City11
151
AggregationAggregation
An aggregation is a special case of association denoting a “consists of” hierarchy.
The aggregate is the parent class, the components are the children class.
1
Exhaust System
Muffler Tailpipe
0..2
CompositionComposition
A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate.
3
TicketMachine
ZoneButton
GeneralizationGeneralization
Generalization relationships denote inheritance between classes.
The children classes inherit the attributes and operations of the parent class.
Generalization simplifies the model by eliminating redundancy.
Button
ZoneButtonCancelButton
154
From Problem Statement to From Problem Statement to CodeCodeProblem Statement
A stock exchange lists many companies. Each company is identified by a ticker symbol
Class Diagram
Java Codepublic class StockExchange { public Vector m_Company = new Vector();};public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector();};
*StockExchange
tickerSymbol
Company*lists
155
156
URS - High Level Class URS - High Level Class DiagramDiagram
URSDataBase
UniversityMember
AcademicStaff Student
Subject
1
*has
1
*
has
teaches
0..3
1
takes *
0…10
157
UML Sequence DiagramsUML Sequence Diagrams Used during requirements
analysis◦ To refine use case descriptions◦ to find additional objects
(“participating objects”) Used during system design
◦ to refine subsystem interfaces Classes are represented by
columns Messages are represented
by arrows Activations are represented
by narrow rectangles Lifelines are represented by
dashed lines
selectZone()
pickupChange()
pickUpTicket()
insertCoins()
PassengerTicketMachine
158
UML Sequence Diagrams: UML Sequence Diagrams: Nested MessagesNested Messages
The source of an arrow indicates the activation which sent the message
An activation is as long as all nested activations
selectZone()
PassengerZoneButton TarifSchedule Display
lookupPrice(selection)
displayPrice(price)
price
Dataflow
…to be continued...
Sequence Diagram Sequence Diagram ObservationsObservationsUML sequence diagram represent
behavior in terms of interactions.Complement the class diagrams
which represent structure.Useful to find participating
objects.Time consuming to build but
worth the investment.
160
161
Use case diagramUse case diagram
Online C2C shopping
• overview the usage requirements• presentations project stakeholders• "the meat" of the actual requirements
Actor
Actor:
An actor is a person, organization, or external system that plays a role in one or more interactions with your system
Use case
Use case:
A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse
System boundary
System boundary:
indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not
162
Class DiagramClass Diagram
Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.
Name
Attributes
Operations
Relations
• Associations• Aggregation
• Generalization
163
Relationships between Class Relationships between Class DiagramsDiagrams
Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.
Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole.
Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass.
164
Sequence DiagramSequence Diagram
A sequence diagram is An interaction diagram that
details how operations are carried out.
What messages are sent and when.
Sequence diagrams are organized according to time
Object: Class
Lifeline
Operations
Message
165
Activities DiagramActivities Diagram
Activity diagrams describe the workflow behaviour of a system
Start
Fork
Branch
MergeJoint
End
166
State Machine DiagramState Machine Diagram
A State Machine diagramshows the possible states ofthe object and the transitionsthat cause a change in state.
? What is different between activities and Statemachine diagram
167
System Design
System design is the transformation of an analysis model into a
system design model ( build a technical blueprint of how the
proposed system will work).
Project team turns its attention to the system from a physical to
technical point of view
Developers also select strategies for building the system, such as:
◦ The hardware/software strategy.
◦ The persistent data management strategy.
◦ The global control flow.
◦ The access control policy.
◦ The handling of boundary conditions.
168
The result of system design is a model that includes a subsystem
decomposition and a clear description of each of these strategies.
System design is not algorithmic. Developers have to make trade-
offs among many design goals that often conflict with each other.
They also cannot anticipate all design issues that they will face
because they do not yet have a clear picture of the solution
domain.
System Design Output
169
System Design Phases
1- design the technical architecture ( hardware, software, telecommunications equipment
2- design the system models
170
System Design Activities
System design is decomposed into several activities, each
addressing part of the overall problem of decomposing the
system:
◦ Identify design goals. Developers identify and prioritize the
qualities of the system that they should optimize.
◦ Design the initial subsystem decomposition. Developers
decompose the system into smaller parts based on the use case
and analysis models. Developers use standard architectural
styles as a starting point during this activity.
◦ Refine the subsystem decomposition to address the design goals.
The initial decomposition usually does not satisfy all design
goals. Developers refine it until all goals are satisfied.
171
Implementation “Mapping Models to Code”
Now, We could implement a system that realizes the use cases specified during requirements elicitation and system design.
However, as developers start putting together the individual subsystems developed in this way, they are confronted with many integration problems.
Different developers have probably handled contract violations differently. Undocumented parameters may have been added to the API to address a
requirement change. Additional attributes have possibly been added to the object model, but are not handled by the persistent management system, possibly because of a miscommunication. As the delivery pressure increases, addressing these problems results in additional improvised code changes and workarounds that eventually yield to the degradation of the system.
The resulting code would have little resemblance to our original design and would be difficult to understand.
We describe a selection of transformations to illustrate a disciplined approach to implementation to avoid such a system degradation. These include
◦ optimizing the class model
◦ mapping associations to collections
◦ mapping operation contracts to exceptions
◦ mapping the class model to a storage schema.
172
Testing Testing is the process of finding differences between the expected behavior
specified by system models and the observed behavior of the implemented system.
Unit testing finds differences between the object design model and its corresponding component.
Structure testing finds differences between the system design model and a subset of integrated subsystems.
Functional testing finds differences between the use case model and the system.
Performance testing finds differences between nonfunctional requirements and actual system performance.
When differences are found, developers identify the defect causing the observed failure and modify the system to correct it. In other cases, the system model is identified as the cause of the difference, and the model is updated to reflect the state of the system.
The goal of testing is to design tests that exercise defects in the system and to reveal problems.
Testing is usually accomplished by developers that were not involved with the construction of the system.
TerminologyTerminologyReliability: The measure of success with
which the observed behavior of a system confirms to some specification of its behavior.
Failure: Any deviation of the observed behavior from the specified behavior. Error: The system is in a state such that further processing by the system will lead to a
failure. Fault (Bug): The mechanical or algorithmic
cause of an error.
There are many different types of errors and different ways how we can deal with them.
173
Dealing with ErrorsDealing with ErrorsVerification:
◦Assumes hypothetical environment that does not match real environment
◦Proof might be buggy (omits important constraints; simply wrong)
Modular redundancy:◦Expensive
Declaring a bug to be a “feature” ◦Bad practice
Patching◦Slows down performance
Testing (this lecture)◦Testing is never good enough
174
Another View on How to Deal Another View on How to Deal with Errorswith ErrorsError prevention (before the system is released):
◦Use good programming methodology to reduce complexity ◦Use version control to prevent inconsistent system◦Apply verification to prevent algorithmic bugs
Error detection (while system is running):◦Testing: Create failures in a planned way◦Debugging: Start with an unplanned failures◦Monitoring: Deliver information about state. Find performance
bugsError recovery (recover from failure once the system is
released):◦Data base systems (atomic transactions)◦Modular redundancy◦Recovery blocks
175
Some ObservationsSome ObservationsIt is impossible to completely test
any nontrivial module or any system◦Theoretical limitations: Halting
problem◦Practial limitations: Prohibitive in
time and costTesting can only show the
presence of bugs, not their absence (Dijkstra)
176
Testing Activities Testing Activities
Tested Subsystem
SubsystemCode
FunctionalIntegration
Unit
TestedSubsystem
RequirementsAnalysis
Document
SystemDesign
Document
Tested Subsystem
Test Test
Test
Unit Test
Unit Test
User Manual
RequirementsAnalysis
Document
SubsystemCode
SubsystemCode
All tests by developerAll tests by developer
FunctioningSystem
IntegratedSubsystems
177
GlobalRequirements
Testing Activities Testing Activities continuedcontinued
User’s understandingTests by developerTests by developer
Performance Acceptance
Client’s Understanding
of Requirements
Test
FunctioningSystem
TestInstallation
User Environment
Test
System inUse
UsableSystem
ValidatedSystem
AcceptedSystem
Tests (?) by userTests (?) by user
Tests by clientTests by client
178
Types of TestingTypes of TestingUnit Testing:
◦Individual subsystem◦Carried out by developers◦Goal: Confirm that subsystems is correctly coded and
carries out the intended functionalityIntegration Testing:
◦Groups of subsystems (collection of classes) and eventually the entire system
◦Carried out by developers◦Goal: Test the interface among the subsystem
179
System TestingSystem TestingSystem Testing:
◦The entire system◦Carried out by developers◦Goal: Determine if the system meets the
requirements (functional and global)Acceptance Testing:
◦Evaluates the system delivered by developers◦Carried out by the client. May involve executing
typical transactions on site on a trial basis◦Goal: Demonstrate that the system meets customer
requirements and is ready to use
Implementation (Coding) and testing go hand in hand
180
Unit TestingUnit TestingInformal:
◦Incremental codingStatic Analysis:
◦Hand execution: Reading the source code◦Walk-Through (informal presentation to others)◦Code Inspection (formal presentation to others)◦Automated Tools checking for
syntactic and semantic errors departure from coding standards
Dynamic Analysis:◦Black-box testing (Test the input/output behavior)◦White-box testing (Test the internal logic of the
subsystem or object)◦Data-structure based testing (Data types
determine test cases)
181
Black-box Testing Black-box Testing Focus: I/O behavior. If for any given input,
we can predict the output, then the module passes the test.◦Almost always impossible to generate all
possible inputs ("test cases")Goal: Reduce number of test cases by
equivalence partitioning:◦Divide input conditions into equivalence
classes◦Choose test cases for each equivalence class.
(Example: If an object is supposed to accept a negative number, testing one negative number is enough)
182
Black-box Testing Black-box Testing (Continued)(Continued)Selection of equivalence classes (No rules, only
guidelines):◦Input is valid across range of values. Select test cases from 3
equivalence classes: Below the range Within the range Above the range
◦Input is valid if it is from a discrete set. Select test cases from 2 equivalence classes: Valid discrete value Invalid discrete value
Another solution to select only a limited amount of test cases: ◦Get knowledge about the inner workings of the unit being
tested => white-box testing
183
White-box TestingWhite-box Testing Focus: Thoroughness (Coverage). Every statement in the
component is executed at least once. Four types of white-box testing
◦ Statement Testing◦ Loop Testing◦ Path Testing◦ Branch Testing
184
Integration Testing: Big-Bang Integration Testing: Big-Bang ApproachApproach
Unit Test F
Unit Test E
Unit Test D
Unit Test C
Unit Test B
Unit Test A
System Test
Don’t try this!
185
Bottom-up Testing Bottom-up Testing StrategyStrategyThe subsystem in the lowest layer of
the call hierarchy are tested individuallyThen the next subsystems are tested
that call the previously tested subsystems
This is done repeatedly until all subsystems are included in the testing
Special program needed to do the testing, Test Driver:◦ A routine that calls a subsystem and passes
a test case to it
SeatDriver(simulates VIP)
Seat Interface(in Vehicle Subsystem)
Seat Implementation
Stub Code Real SeatSimulated
Seat (SA/RT)186
Bottom-up IntegrationBottom-up IntegrationAB C D
GFE
Layer I
Layer II
Layer III
Test F
Test E
Test G
Test C
Test D,G
Test B, E, F
Test A, B, C, D,
E, F, G
187
Pros and Cons of bottom up Pros and Cons of bottom up integration testingintegration testing
Bad for functionally decomposed systems:Useful for integrating the following
systems◦ Object-oriented systems◦ real-time systems◦ systems with strict performance requirements
188
System TestingSystem TestingFunctional TestingStructure TestingPerformance TestingAcceptance TestingInstallation Testing
Impact of requirements on system testing:◦The more explicit the requirements, the easier
they are to test.◦Quality of use cases determines the ease of
functional testing◦Quality of subsystem decomposition determines
the ease of structure testing◦Quality of nonfunctional requirements and
constraints determines the ease of performance tests:
189
Structure TestingStructure TestingEssentially the same as white box testing.Goal: Cover all paths in the system
design◦Exercise all input and output parameters
of each component.◦Exercise all components and all calls
(each component is called at least once and every component is called by all possible callers.)
◦Use conditional and iteration testing as in unit testing.
190
Functional TestingFunctional Testing.
.
Essentially the same as black box testingGoal: Test functionality of systemTest cases are designed from the
requirements analysis document (better: user manual) and centered around requirements and key functions (use cases)
The system is treated as black box.Unit test cases can be reused, but in
end user oriented new test cases have to be developed as well.
191
Performance TestingPerformance Testing Stress Testing
◦ Stress limits of system (maximum # of users, peak demands, extended operation)
Volume testing◦ Test what happens if large
amounts of data are handled Configuration testing
◦ Test the various software and hardware configurations
Compatibility test◦ Test backward compatibility with
existing systems Security testing
◦ Try to violate security requirements
Timing testing◦ Evaluate response times and
time to perform a function Environmental test
◦ Test tolerances for heat, humidity, motion, portability
Quality testing◦ Test reliability, maintain-
ability & availability of the system
Recovery testing◦ Tests system’s response to
presence of errors or loss of data.
Human factors testing◦ Tests user interface with user
192
Acceptance TestingAcceptance TestingGoal: Demonstrate
system is ready for operational use◦ Choice of tests is made by
client/sponsor◦ Many tests can be taken
from integration testing◦ Acceptance test is
performed by the client, not by the developer.
Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:
Goal: Demonstrate system is ready for operational use◦ Choice of tests is made by
client/sponsor◦ Many tests can be taken
from integration testing◦ Acceptance test is
performed by the client, not by the developer.
Majority of all bugs in software is typically found by the client after the system is in use, not by the developers or testers. Therefore two kinds of additional tests:
Alpha test:◦ Sponsor uses the software
at the developer’s site.◦ Software used in a
controlled setting, with the developer always ready to fix bugs.
Beta test:◦ Conducted at sponsor’s site
(developer is not present)◦ Software gets a realistic
workout in target environ- ment
◦ Potential customer might get discouraged
Alpha test:◦ Sponsor uses the software
at the developer’s site.◦ Software used in a
controlled setting, with the developer always ready to fix bugs.
Beta test:◦ Conducted at sponsor’s site
(developer is not present)◦ Software gets a realistic
workout in target environ- ment
◦ Potential customer might get discouraged
193
194
Object Design (1/2) During analysis, we describe the application objects.
During system design, we describe the system in terms of its
architecture, such as its subsystem decomposition, global control flow,
persistency management, and hardware/software platform on which we
build the system. This allows the selection of off-the-shelf components
that provide a higher level of abstraction than the hardware.
During object design, we close the gap between the application objects
and the off-the-shelf components by identifying additional solution
objects and refining existing objects. Object design includes:
◦ reuse, during which we identify off-the-shelf components and design patterns
to make use of existing solutions
◦ service specification, during which we precisely describe each class interface
◦ object model restructuring, during which we transform the object design
model to improve its understandability and extensibility
◦ object model optimization, during which we transform the object design model
to address performance criteria such as response time or memory utilization.
195
Object Design (2/2) During object design, we identify and refine solution objects to realize the
subsystems defined during system design.
During this activity, our understanding of each object deepens:
◦ we specify the type signatures and the visibility of each of the operations.
◦ we describe the conditions under which an operation can be invoked and those
under which the operation raises an exception.
The focus of object design is on specifying the boundaries between objects.
At this stage in the project, a large number of developers concurrently refines
and changes many objects and their interfaces. The focus of interface
specification is for developers to communicate clearly and precisely about
increasingly lower-level details of the system.
The interface specification activities of object design include:
◦ identifying missing attributes and operations
◦ specifying type signatures and visibility
◦ specifying invariants
◦ specifying preconditions and postconditions.