comp1007 introduction to requirements analysis © copyright de montfort university 2002 all rights...
Post on 01-Apr-2015
216 Views
Preview:
TRANSCRIPT
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
COMP1007 Introduction to Requirements Analysis
Moving to Design
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Learning Objectives
Examine the issues that have to be addressed during design
Distinguish between System and Object Design
Consider the impact of implementation technology
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Analysis vs Design
Why separate analysis and design Project Management, Staff Skills and Experience, Client Decisions Choice of Development Environment.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
What makes a good analysis To provide a sound foundation for
design, analysis should meet the following four criteria:– correct scope,– completeness,– correct content, – consistency.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
What makes a good design
Functional BuildableManageable
MaintainableUsable ReusableEfficient EconomicalReliable SecureFlexible General
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Measurable Objectives
Information systems are built to satisfy an organisational need such as– provide better response to customers– but this is difficult to measure and thus determine
success Measurable objectives might include
– reduce invoice errors by a third– process 50% more orders
However not all objectives are quantifiable
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Logical vs Physical Design
One way of separating design by splitting it into – Logical design - implementation
independent– Physical design - implementation
dependent
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Logical vs Physical Design
Physical design is affected by– Hardware and its location e.g.
Large central computer Network of PCs
– Operating System– Development Language and
Environment– Database Management System used
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Logical vs Physical Design
Logical design is concerned – how objects interact determining
message signatures attribute type attribute and operation visibility operation design
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Logical vs Physical Design
The distinction permitted in theory one logical design leading various physical designs and thus implementations.
However the distinction is made much less these days
The choice of system architecture is used to enable different styles of implementation
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
System and Object Design
System Design is concerned with system wide issues that affect the whole system including the software architecture
Object Design is detailed design of the system and is performed within the context of the systems design decisions.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
System Design
Sub-systems and major components are identified.
Any inherent concurrency is identified.
Sub-systems are allocated to processors.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
System Design
A data management strategy is selected.
A strategy and standards for human-computer interaction are chosen.
Code development standards are specified.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
System Design
The control aspects of the application are planned.
Test plans are produced. Priorities are set for design trade-offs. Implementation requirements are
identified (for example, data conversion).
Architectural patterns may be used.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
System Design
Campaign Database
Campaign Domain
Advert Sub-system
Advert HCI Sub-system
Campaign Costs Sub-system
Campaign Costs HCI Sub-system
A single domain layer supports two application sub-systems.
Application layer
Presentation layer
A typical software architecture
Bennett, McRobb, Farmer, 1999
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
User Interface Package
Business Objects Package
JDBC
Java SQL
Java AWT Application Windows
Database Package Business Objects
Control Objects
Object to Relational
UML packages representing layers in the three-tier architecture
Bennett, McRobb, Farmer, 1999
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Detailed or Object Design
This involves making decisions regarding– attribute data type– operation signatures– attribute and operation visibility– association design– use of design patterns
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Object Design
BankAccount
-nextAccountNumber:Integer -accountNumber:Integer -accountName:String {not null} -balance:Money = 0 -overdraftLimit:Money
+open(accountName:String):Boolean +close():Boolean +credit(amount:Money):Boolean +debit(amount:Money):Boolean +viewBalance():Money #getBalance():Money -setBalance(newBalance:Money) #getAccountName():String #setAccountName(newName:String)
Bennett,McRobb,Farmer, 1999
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
RUP Phases
Inception– business case– plan
Elaboration– use cases– baseline architecture
Construction– product is built
Transition– beta release/testing/training
Rational Unified Process
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Design Activities
Centred around the software architecture– early iterations focus on its production/validation– represented by a number of architectural views
Production of the Design Model– classes structured into design packages with well
defined interfaces– how objects collaborate to perform the use cases
– check completeness and consistency of the design
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Implementation & UP
The purpose of implementation is: – to define the organization of the code, in terms of
implementation subsystems organized in layers, – to implement classes and objects in terms of
components (source files, binaries, executables, and others),
– to test the developed components as units, and – to integrate the results produced by individual
implementers (or teams), into an executable system.
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
Summary
Examine the issues that have to be addressed during design
Distinguish between System and Object Design
Consider the impact of implementation technology
COMP1007 Introduction toRequirements Analysis
© Copyright De Montfort University 2002 All Rights Reserved
References Bennett, S. et. al. “Object-Oriented
Systems Analysis & Design using UML” McGraw-Hill 1999
Jacobson, I., Booch, G. & Rumbaugh, J. (1999) “The Unified Software Development Process” Addison-Wesley
Rational Unified Process Best Practices for Software Development Teams White Paper, 1998 www.rational.com
Rational Unified Process 2000
top related