Embed Size (px)
Citation preview
2004 by SEC
Chapter 3 Requirements Engineering
2
2004 by SEC
Chapter 3 Requirements Engineering
3.1 Requirements engineering3.1.1 Software requirements
3.1.2 Characteristics of requirements
3.1.3 Requirements engineering
3.1.4 Requirements elicitation
3.2 Requirements analysis 3.2.1 Software modeling
3.2.2 Use Case Diagrams
3.2.3 Entity-Relationship diagram (ERD)
3.2.4 Data Flow diagrams (DFD)
3.2.5 State diagrams
3
2004 by SEC
Chapter 3 Requirements Engineering (cont’d)
3.3 Object-oriented (OO) software engineering
3.3.1 Object Orientation
3.3.2 Object Orientation Development
3.3.3 Steps of Analysis: an Example Using OO Approach
3.3.4 A Modeling Example
3.4 Data modeling and OOA
3.4.1 Data modeling vs. OOA
4
2004 by SEC
3.1 Requirements Engineering
5
2004 by SEC
Requirement– Functional requirement describes system services or functions
– Non-functional requirement is a constraint or a goal on the system or on the development process
User (Customer) requirement– A statement in natural language plus diagrams of the services the system
provides and its operational constraints
Requirements specification– A structured document for detail description of the system services.
– Written as a contract between client and developer
Software Requirements
6
2004 by SEC
Incomplete Requirements– Most software systems are complex, that developer can never fully
captured during the system development, therefore, requirements are always incomplete.
Inconsistent Requirements– Different users have different requirements and priorities. There is a
constantly shifting compromise in the requirements.
– Prototyping is often required to clarify requirements.
Characteristics of Requirements
7
2004 by SEC
the problemthe problemrequirementsrequirements
elicitationelicitation
build abuild aprototypeprototype
createcreateanalysisanalysismodelsmodels
developSpecification ReviewReview
Requirement Engineering
Process
8
2004 by SEC
Requirements elicitation– Determine what the customer requires
Requirements analysis– Understand the relationships among various customer requirements
Requirements negotiation– Shape the relationships among various customer requirements to
achieve a successful result
– Research on requirements trade-off analysis (formulating as goals)
Requirements specification– Build a form of requirements
Requirements Engineering (cont’d)
9
2004 by SEC
Modeling– Build a representation of requirements that can be assessed for
correctness, completeness and consistency.
Requirements validation – Review the model and specification
Requirements management– Identify, control and track requirements and the changes.
Requirements Engineering (cont’d)
10
2004 by SEC
Requirements Elicitation
Two sources of information for the requirements elicitation– Users and organizations
– Application domains
11
2004 by SEC
Elicitation Techniques Asking
– Ask users what they expect from the system
– Interview, brainstorm, group meeting, questionnaire, and JAD (Joint Application Development)
Form analysis– A lot of information about the domain can be found in various forms and
manuals
– Forms provide us with information about the data objects of the domain, their properties, and their interrelations
Derivation from an existing system– Take the peculiar circumstances of the present situation into account
12
2004 by SEC
Elicitation Techniques (cont’d)
Observation
Prototyping
Task analysis– High-level tasks can be decomposed into sub-tasks
Scenario-based analysis– Study instances of tasks
– A scenario can be real or artificial
Description– Natural language
– with background information to be used in conjunction with other elicitation techniques such as interviews
13
2004 by SEC
Example of Requirements Elicitation
Use QFD to prioritize
requirements
informally prioritize
requirements
formal prioritization?
Create Use-cases
yes noElic it requirements
write scenario
define actors
complete template
draw use-case diagram
Conduct FASTmeetings
Make lists offunctions, classes
Make lists ofconstraints, etc.
14
2004 by SEC
3.2 Requirements Analysis
15
2004 by SEC
Build the analysis model– Data Modeling
– Functional Modeling
– Behavioral Modeling
– Scenario-based Modeling
– Class-based Modeling
Requirement Analysis
16
2004 by SEC
Purpose– Build a representation of requirements that can be assessed for
correctness, completeness and consistency.
– Abstract away those that are irrelevant.
Model: an abstraction for– Understanding before (actually) building
– Communication
– Visualization
– Reducing complexity
Methodology: build (analyze) a model of an application domain
Software Modeling
17
2004 by SEC
Application and Solution Domain
Application Domain (Requirements Analysis)– The environment in which the system is operating
Solution Domain (System Design, Object Design)– The available technologies to build the system
18
2004 by SEC
Information domain analysis– information flow: the flow of data through data transformations
– data content and relationship; data structure
– data modeling (data dictionary, ERD)
Functional and behavioral representation– function: process/transformation; functional modeling (DFD)
– behavior: behavioral modeling (state transition diagram)
Scenario-based Modeling– Use case Modeling: build use case diagrams
Class-based Modeling– OOA: class diagrams
The Analysis Model
19
2004 by SEC
Interface definition– function/process interface
Problem partition and abstraction– at different levels of abstraction
– classification and assembly structure
The Analysis Model (cont’d)
20
2004 by SEC
Use Case Modeling
Used to represent software requirements.
A collection of user scenarios that describe the thread of usage of a system.
Each scenario is described from the point-of-view of an “actor”.– actor: a person, device, or system that interacts with the software in
some way
21
2004 by SEC
Use Case Diagrams
homeowner
Arms/ disarms system
Accesses system via Internet
Reconfigures sensors and related
system features
Responds toalarm event
Encounters anerror condition
system administrator
sensors
actor actor
use case
22
2004 by SEC
Traditional Software Engineering
Software Systems
Data ModelFunctional Model Behavioral model
Entity-RelationDiagrams
Data FlowDiagrams
State TransitionDiagrams
23
2004 by SEC
Entity– Primary things an organization collects and records information
about. (noun) ( )
E.g. persons, products, places, etc.
Relationship– Linkage between entities. (verb) ( or )
E.g. Persons perform jobs, Jobs consist-of tasks
Cardinality– Identify how many instances of one entity are related to how many
instances of another entity.
Entity-Relationship Diagram
24
2004 by SEC
Examples
Persons
Jobs
Perform
Customers
Tasks
Serve
Consist-of
1:1 Persons
Jobs
1:N
consist_of
Jobs
Tasks
M:Nserve
Persons
Customers
Entity-Relationship Diagram (cont’d)
perform
Directionusing an arrow pointing to the object of the action
25
2004 by SEC
Attributes: Properties to describe an entity– key attribute (key, identifier) to characterize the specific entity (to
retrieve a single entity occurrence (instance))
unique: to ensure that no other record has the same identifier.
unchanging: to ensure that it always refers to the same thing.
Students Faculty
Courses
AssistAdvice
TeachTake
Entity-Relationship Diagram (cont’d)
26
2004 by SEC
– Student is an entity about which an university stores info such as the Student_id, name, and phone.
Compound keys: made up of a number of different subkeys to produce a unique identifier– e.g. course number + section number + term
50416938 Doakes, Jane 242-714771426006 Blough, JO 426-4141
Entity type Key attribute Attribute
real data
Student_id name phone
e.g.
Entity-Relationship Diagram (cont’d)
student
27
2004 by SEC
– Recursive relationships: an entity is related to itself
e.g.
Person
Is_Married_To
Is_Parent_of
Is_Child_of
Entity-Relationship Diagram (cont’d)
28
2004 by SEC
– N-ary relationships
e.g.
Entity-Relationship Diagram (cont’d)
29
2004 by SEC
Entity-Relationship Diagram (cont’d)
Location
Employee
Fname Lname
Name
Ssn
Bdate
Supervision
1 N
Works_for
Manages
Works_on
Dependent
Dependents_of
Sex
Address
Salary
Hours
Project
Department
Dname Dno
Controls
Pno Pname
Name Sex Bdate Relationship
StartDate
1
N
N
M
N
N
1
1
1 1
Lcations
30
2004 by SEC
Data Flow Diagrams (DFD)
Basic Notation:– : process (transformer of information)
– : external entity (procedure/consumer of information)
– : data item
– : data store (repository of data observed by processes)
31
2004 by SEC
Data Flow Diagrams (cont’d)
DFD can be used to represent a system at any level of abstraction by refinement. – level 0: context model (a single bubble)
– information flow continuity: I/O to each refinement must remain the same. (balancing)
No explicit indication of the sequence of processing is supplied by the DFD.– Control flow is not explicit. The truth is that control is excluded in DFD
intentionally.
– Explicit procedural representation is delayed until design.
32
2004 by SEC
Data Flow Diagrams (cont’d) processing narrative
– To specify the processing details in the bubble.
inputs to the bubble
algorithm applied to the input
Output
Restrictions & limitations imposed on the process.
Performance characteristics related to the process.
Design constraints
– usually by natural language
33
2004 by SEC
Data Flow Diagrams (cont’d)
Data represented by– data item
– data store
Content of data– a collection of data items:
data dictionary (DD); only content no relationship
– a need to represent relationship between complex collections of data:
E-R diagram (ERD) for data modeling; content and relationship
34
2004 by SEC
Data Dictionary precise, rigorous definitions of all data elements pertinent to
the system.
usually contain the following information:– Name, Alias, Where used/How used, Content description,
supplementary information.
– Content description notation
= / + / [ | ] / { }n / ( …) / *…*
composed of / and / selection / n repetitions of / option / comments
35
2004 by SEC
Data Dictionary (cont’d) Example of content description:
telephone number = [local number | long distance number]
local number = prefix + access number
long distance number = 1 + area code + local number
area code = [365 | 658 | 887]
prefix = *a three digit number that never starts with 0 or 1*
access = *any four number string*
36
2004 by SEC
DFD Example
useruserprocessing processing
requestrequest
videovideosourcesource NTSCNTSC
video signalvideo signal
digitaldigitalvideovideo
processorprocessor
requestedrequestedvideovideosignalsignal
monitormonitor
Level 0
37
2004 by SEC
PPaa bbxx yy
p1p1p2p2
p3p3p4p4 p5p5
aa
bb
cc
ddee
ff
gg
DFD Example (Cont’d)
Level 0Level 0
Level 1Level 1
iihh
DBDB
38
2004 by SEC
Balancing ERD against DFD Every data store on the DFD must correspond to an entity
type, or a relationship, or a combination of an entity type and relationship.– If there is a store on the DFD that does not appear on the ERD,
something is wrong.
– If there is an entity or relationship on the ERD that does not appear on the DFD, something is wrong.
39
2004 by SEC
State Transition Diagrams
Outsideworld
Application
events behavior
40
2004 by SEC
State Transition Diagrams (cont’d) state—a set of observable circumstances that characterizes the
behavior of a system at a given time
state transition—the movement from one state to another
event—an occurrence that causes the system to exhibit some predictable form of behavior
action—process that occurs as a consequence of making a transition
activity—process that occurs in a state
41
2004 by SEC
State Transition Diagrams (cont’d)
statestate
new statenew state
event causing transition (condition)event causing transition (condition)
action that occursaction that occursstate transition:
42
2004 by SEC
State Transition Diagrams (cont’d)
readingreadingoperatoroperator
commandscommands
making copiesmaking copies reloading paperreloading paper
problem stateproblem state
Not emptyNot emptyinvoke read-op-inputinvoke read-op-input
Not empty and startNot empty and startinvoke manage-copyinginvoke manage-copying
copies donecopies doneinvoke read-op-inputinvoke read-op-input
emptyemptyinvoke reload paperinvoke reload paper
jammedjammedinvoke problem-diagnosisinvoke problem-diagnosis
not jammednot jammedinvoke read-op-inputinvoke read-op-input
43
2004 by SEC
3.3 Object-oriented (OO) Software Engineering
44
2004 by SEC
Object-Oriented Software Engineering
Scenario-based Model
Software Systems
Functional ModelObject Model Behavioral Model
Data FlowDiagrams
ClassDiagrams
State Charts
Use CaseDiagrams
45
2004 by SEC
Why Objects? Real-world objects vs. Software objects
– communications
Applicationdomain
Solutiondomain
Object necessaryfor describing asolution - problemspace
Object requiredfor implementation a solution - solutionspace
software realizationof the real-worldproblem
46
2004 by SEC
Application and Solution Domain
UML Package
Application Domain Solution Domain
Application Domain Model System Model
Aircraft TrafficController
FlightPlan Airport
MapDisplay
FlightPlanDatabase
SummaryDisplay
TrafficControl
TrafficControl
47
2004 by SEC
Object Orientation Identity:
– each object is a discrete and distinguishable entity.
– each real-world object is unique due to its existence.
– each object has its own inherent identity, therefore, two objects are distinct even if all their attribute values are identical.
Classification:– objects with the same attributes and operations are grouped into a
class
– each object is said to be an instance of its
class
– e.g. Bicycle object -------> Bicycle class
Attributes:frame sizewheel size
Operations:shiftmove
48
2004 by SEC
Class Class:
– An abstraction in the context
– encapsulates both state (attributes) and behavior (methods)
– Can be defined in terms of other classes using inheritance
Criteria of selecting classes– Retained information
– Needed services
– Multiple attributes
– Common attributes
– Essential requirements
49
2004 by SEC
Inheritance Inheritance:
– the sharing of attributes and operations among classes based on a hierarchical relationship
– each subclass inherits all of the properties of its superclass and adds its own unique properties (called extension)
– reusability
© 1993 - 2003, Jonathan Lee, All Right Reserved.
50
2004 by SEC
Polymorphism Polymorphism:
– the same operation behaves differently on different classes
– an operation is an action or transformation that an object performs or is subject to
– method: a specific implementation of an operation
a polymorphic operation is an operation that has more than one method implementing it.
51
2004 by SEC
Polymorphism (cont’d)
Static polymorphism– Overloading: an invocation can be operated on arguments
of more than one type.
Class TimeOfDay {
public void setTime(char[8] time) {…};
public void setTme(int h, int m, int s) {…};
}
TimeOfDay aClock= new TimeOfDay( );
aClock.setTime(17,1,0);
aClock.setTime(“11:55:00”);
52
2004 by SEC
Polymorphism (cont’d)
Dynamic polymorphism:– object reference can refer to an instance of any of descendants of its class
– an instance of the subclass created, and is also an instance of each that subclass’s ancestor
– the same operation may behave differently on different classes
method: a specific implementation of an operation
a polymorphic operation is an operation that have more than one method implementing it.
53
2004 by SEC
Polymorphism (cont’d)
class Student extends Person {
void getName() { System.out.println(“Student”); }
class Employee extends Person {
void getName() { System.out.println(“Employee”); }
}
public static void main(String [ ] args) {
Person p;
BufferedReader in=new BufferedReader(
new InputStreamReader(System.in));
int num=Integer.parseInt(in.readLine());
if (num= =1) p = new Employee( );
else p = new Student( );
p.getName( );
}
54
2004 by SEC
Object-Oriented Development
Life-cycle– development:analysis,design,and implementation
– testing:
– maintenance:
modeling vs. implementationOOA/D: front-end conceptual issues
reduce cost.
OOP: back-end implementation issues.
restrict design choices.
55
2004 by SEC
Software Artifacts Problem statements:
– to describe the problem to be solved and providing a conceptual overview of the proposed system
Analysis:– to understand and model the application and the domain (usually called a
modeling activity)
– the output is a model capturing: functionality, behavior, and structure
Design:– Data Design:data abstraction;data structure;data modeling
– Procedural Design: iteration , conditional, sequence
– Architectural Design: program structure ( control hierarchy ); system organization ( software architecture )
Implementation:– Executable code
56
2004 by SEC
OMT Methodology Stages:
– Analysis:
Problem statement. (usually incomplete, incorrect)
– Design:
System design
Decision making
stage
object design
Analysis
-abstraction of what the desired system must do.-application-domain concepts NOT implementation concepts
Analysis model
System Design-organize the target system into subsystems-decide performance characteristics
object design-data structural & algorithm to implement each class.
depends onthe performancemeasure
problemstatements
57
2004 by SEC
OMT Methodology (cont’d)
Three models:– object model: the static structures of objects &
their relationships
object diagrams: object classes (node), relationships
(arc).
– dynamic model: interactions(control) among objects
state diagrams: states(node), transitions(arc) by events
– functional model: data transformation of objects
data flow diagrams: processes(node), dataflows(arc).
change over time
58
2004 by SEC
Basic Concepts Abstraction: focus on the essential, inherent aspects of entity
and ignoring its accidental properties.– e.g. Use of abstraction during analysis: deciding only with
application-domain concepts, not making design and implementation decisions.
Encapsulation: (OO) separate the external aspects of an object, which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects.
Sharing through inheritance (Reuse)– data structures and behaviors (design)
– code
59
2004 by SEC
Features of Object Orientation: Blair’s Version
Identify– The unique identification of every object is through the use of an
object identifier.
Encapsulation– The selection of properties to be encapsulated.
attributes, operations, representations, algorithms...
– The determination of visibility of these properties. (I.e. a well-defined interface)
Classification: group associated objects according to common properties– The Intent of a classification is the description of that classification
characteristics, therefore, the intent specifies a predicate.
60
2004 by SEC
Features of Object Orientation: Blair’s Version (cont’d)
– The extend of a classification is the set of objects in the current environment which features such behavior, that is, a population selected by applying a predicate.
Flexible sharing: The ability for an object to belong to more than one classification. and will require a flexible form of behavior sharing.– are based on the encapsulated properties, the considered classification
scheme, the relationship between classifications.
Interpretation: The resolution of the precise semantics of the shared item of behavior.– two steps involved in the resolution: type checking and binding.
typing checking: determination of whether operations are supported by a particular object
binding: locate the correct implementation of the operation.
61
2004 by SEC
Build the use case model: use case diagrams
Build the object model: class diagrams– Extract candidate classes
– Identify attributes for each class
– Establish basic class relationships
– Define a class hierarchy
– Specify methods that service the attributes
– Indicate how classes/objects are related
Build the behavioral model: state charts
Build the functional model: data flow diagrams
Steps of Analysis: An Example Using OO Approach
62
2004 by SEC
Classes Associations (Relations)
– Part of- Hierarchy (Aggregation)
– Kind of-Hierarchy (Generalization)
Attributes– Application specific
– Attributes in one subsystem can be classes in another subsystem, turning attributes to classes
Service– Domain Methods: Dynamic model, Functional model
– Operation: A function or transformation applied to objects in a class. All objects in a class share the same operations (Analysis Phase)
– Signature: Number & types of arguments, type of result value. All methods of a class have the same signature (Object Design Phase)
– Method: Implementation of an operation for a class (Implementation Phase), Polymorphic operation: The same operation applies to many different classes.
Object Model
63
2004 by SEC
Identify the boundaries of the system– What object is inside, what object is outside?
Identify the important entities in the system– Learn about problem domain: Observe your client
– Take the flow of events and find participating objects in use cases (Scenarios and use cases)
– Apply design patterns
– Nouns are good candidates for classes
Class Identification
64
2004 by SEC
Class Types
Entity Objects: represent the persistent information (Application domain objects, “Business objects”)
Boundary Objects: represent the interaction between the user and the system
Control Objects: represent the control tasks performed by the system
<<entity>>student
<<entity>>teacher
<<entity>>employee
<<control>>ChangeDateControl
<<boundary>>LCDDisplayBoundary
<<boundary>>ButtonBoundary
65
2004 by SEC
Requirement StatementsProper noun
Improper noun
Doing verb
being verb
having verb
modal verb
adjective
transitive verb
intransitive verb
Model componentobject
class
method
inheritance
aggregation
constraint
attribute
method
method (event)
Example
Jim Smith
toy, car
buy, recommend
is-a (kind-of)
has an
must be
3 years old
enter
depends on
Mapping Requirement Statements to Object Model Components
66
2004 by SEC
Behavioral Model
Indicate different states of the system
Specify events that cause the system to change state
Build State charts
67
2004 by SEC
A Modeling Example: A Banking System
Foo
Balance
CustomerId
Deposit()Withdraw()GetBalance()
Class Identification: Name of Class, Attributes and Methods
68
2004 by SEC
Naming
Foo
Balance
CustomerId
Deposit()Withdraw()GetBalance()
Account
Balance
CustomerId
Deposit()Withdraw()GetBalance()
“Dada”
Balance
CustomerId
Deposit()Withdraw()GetBalance()
69
2004 by SEC
Finding New Objects
Account
BalanceAccountId
Deposit()Withdraw()GetBalance()
Customer
NameCustomerId
Iterate on Names, Attributes and Methods
Bank
Name
70
2004 by SEC
Finding Associations
Account
BalanceAccountId
Deposit()Withdraw()GetBalance()
Customer
NameCustomerId
Bank
Name
•Iterate on Names, Attributes and Methods •Find Associations between Objects •Label the associations •Determine the multiplicity of the associations
Has*
71
2004 by SEC
Finding Generalization
MortgageAccount
Withdraw()
*Account
BalanceAccountId
Deposit()Withdraw()GetBalance()
Customer
NameCustomerId
Bank
Name
Has*
SavingAccount
Withdraw()
CheckingAccount
Withdraw()
72
2004 by SEC
Categorization
Don’t put too many classes into the same package:
72 or even 52
73
2004 by SEC
3.4 Data Modeling and OOA
74
2004 by SEC
OOA vs. Data Modeling Data modeling is for data-intensive applications
OOA:
E-R Diagram Semantic Data Modeling
OOA
OOPL
• Services• Message between objects• classification & inheritance
75
2004 by SEC
OOA vs. Data Modeling
Similarity ： describe relationships between objects
Differences：– data modeling does not concern how these relationships are
achieved
– data modeling without concern for the processing that must be applied to transform the data
in general, no concept of methods is considered
Data objects can be defined in terms of a set of attributes– encapsulates data only, that is , no reference within a data object to
operations that act on the data
76
2004 by SEC
OOA vs. Data Modeling (cont’d)
Data object attributes– data object tables : normalization result in minimum redundancy,
that is , the amount of information that we need to maintain to satisfy a particular problem is minimized.
Normalization rules
(1) only one value for each attribute
(2) attributes should contain no internal structure
77
2004 by SEC
Exercises Both SA and OOA offer the mechanism for the partition. Do
they support the interactions between the different levels?
Compare the similarity and differences between the data modeling and object-oriented modeling.
