requirements engineering-based conceptual modelling from: requirements engineering e. insfran, o....
TRANSCRIPT
Requirements Engineering-Based Requirements Engineering-Based Conceptual ModellingConceptual Modelling
From: Requirements EngineeringFrom: Requirements Engineering
E. Insfran, O. Pastor and R. WieringaE. Insfran, O. Pastor and R. Wieringa
Presented by Chin-Yi TsaiPresented by Chin-Yi Tsai
2
OutlineOutline
IntroductionIntroduction
TRADE and OO-MethodTRADE and OO-Method
A Requirements Engineering-Based Conceptual A Requirements Engineering-Based Conceptual Modelling ApproachModelling Approach
Conclusions and Further WorkConclusions and Further Work
3
IntroductionIntroduction Software development processSoftware development process
Requirement AnalysisRequirement Analysis System AnalysisSystem Analysis System DesignSystem Design Implementation Implementation TestingTesting MaintenanceMaintenance
To provide a set of techniques and methodsTo provide a set of techniques and methods To capture software requirementsTo capture software requirements
To provide a way To provide a way to move from requirement to a conceptual schema in a to move from requirement to a conceptual schema in a traceable traceable
wayway
improve the improve the qualityquality of the software production process of the software production process
Translation(iterative, incremental)
Translation(iterative, incremental)
Requirement ModelRequirement Model
SA ModelSA Model
SD ModelSD Model
traceability
traceability
4
Full model-based code generationFull model-based code generation
Introduction (cont’d)Introduction (cont’d)
The approach combines a framework for The approach combines a framework for requirements engineering (requirements engineering (TRADETRADE) and a graphical ) and a graphical object-oriented method for conceptual modelling object-oriented method for conceptual modelling and code generation (and code generation (OO-MethodsOO-Methods).).
Providing a precise methodological guidanceProviding a precise methodological guidance
User requirement (TRADE)User requirement (TRADE)
Conceptual schema (OO-Methods)Conceptual schema (OO-Methods)
Final software produceFinal software produce
5
Introduction (cont’d)Introduction (cont’d)
Quality of the software production processQuality of the software production process Provide predictabilityProvide predictability Improve productivityImprove productivity
traceabilitytraceability
6
TRADE and OO-MethodTRADE and OO-Method
The TRADE is a set of The TRADE is a set of techniquestechniques and and heuristicsheuristics based on an analysis of structured and object-based on an analysis of structured and object-oriented specification methods.oriented specification methods.
Specifying external interaction s and their Specifying external interaction s and their properties in TRADEproperties in TRADE Mission statementMission statement Function refinement treeFunction refinement tree Context diagramsContext diagrams Use case diagramsUse case diagrams Scenario diagramsScenario diagrams
Requirement ModelRequirement Model
7
TRADE and OO-Method (cont’d)TRADE and OO-Method (cont’d)
The OO-Method is an object-oriented method that The OO-Method is an object-oriented method that provides a set of well-defined and complementary provides a set of well-defined and complementary graphical techniquesgraphical techniques to build a conceptual schema to build a conceptual schema of the system.of the system.
8
A Requirements Engineering-Based Conceptual Modelling ApproachA Requirements Engineering-Based Conceptual Modelling Approach
9
Requirements Modelling PhaseRequirements Modelling Phase The purpose of the RM is to accurately and precisely The purpose of the RM is to accurately and precisely
capture what the customer wants to have built.capture what the customer wants to have built. Without high-level training in the notation can understand and Without high-level training in the notation can understand and
review themreview them
The Objectory method introduces use case-driven analysis The Objectory method introduces use case-driven analysis (UCDA)(UCDA) Actor and use casesActor and use cases
UCDA is simple, and use case descriptions are based on UCDA is simple, and use case descriptions are based on natural conceptsnatural concepts
Two disadvantages of using UCDATwo disadvantages of using UCDA The difficulty in finding the correct abstraction level to specify the The difficulty in finding the correct abstraction level to specify the
use caseuse case Finding a process to analyze and translate the use case Finding a process to analyze and translate the use case
specification into a conceptual modelspecification into a conceptual model
10
RM techniquesRM techniques
Mission statementMission statement Describe the purpose of the system in one or two Describe the purpose of the system in one or two
sentences.sentences.
Function refinement treeFunction refinement tree Deals with external interaction partitioning according to Deals with external interaction partitioning according to
the different business areas or business objectives.the different business areas or business objectives.
Use case modelUse case model Include the use case specification to specify the Include the use case specification to specify the
composition of external interaction and the use case composition of external interaction and the use case diagram to show communication between the diagram to show communication between the environment (actors) and the system.environment (actors) and the system.
11
Mission Statement and Function Refinement TreeMission Statement and Function Refinement Tree
12
Use CasesUse Cases
Use cases were introduced in OOSE to represent Use cases were introduced in OOSE to represent external system functionality.external system functionality.
A use case is an interaction between the system A use case is an interaction between the system and an external actor.and an external actor.
The purpose of use case specification is to The purpose of use case specification is to describe the describe the flow of events in detailflow of events in detail, including how , including how the use case starts, ends, modified the system and the use case starts, ends, modified the system and interacts with actors.interacts with actors.
13
14
Conceptual Modelling PhaseConceptual Modelling Phase
The purpose of the conceptual modelling phase is to The purpose of the conceptual modelling phase is to represent use requirements in a specification of represent use requirements in a specification of whatwhat the the system does as if there were a perfect implementation system does as if there were a perfect implementation technology available.technology available.
The OO-MethodThe OO-Method Object modelObject model
Simple class diagramSimple class diagram Dynamic modelDynamic model
State diagramState diagram Collaboration diagramCollaboration diagram
Functional modelFunctional model Textural model used to capture the semantic that is attached to any Textural model used to capture the semantic that is attached to any
change of an object state as a consequence of a service occurrencechange of an object state as a consequence of a service occurrence
15
Requirements Analysis Process (RAP)Requirements Analysis Process (RAP)
In order to evaluate whether that use case has In order to evaluate whether that use case has been provided, we should show what functionality been provided, we should show what functionality was allocated to which class or classes for each was allocated to which class or classes for each use case.use case.
Identify the responsibilityIdentify the responsibility
Allocate the identified responsibilityAllocate the identified responsibility
Use Case Use Case …
16
Notation and TechniqueNotation and Technique
The deal with the activity of identifying The deal with the activity of identifying responsibilities within the use case specification responsibilities within the use case specification and allocating them into class componentsand allocating them into class components Use sequence diagramUse sequence diagram Specify detailed behavior and low-level specificationSpecify detailed behavior and low-level specification
There is at least one sequence diagram per use There is at least one sequence diagram per use case, one for the basic course of action, and one case, one for the basic course of action, and one for each alternative course of action (if any).for each alternative course of action (if any).
17
18
Validation, Verification and TraceabilityValidation, Verification and Traceability
The purpose of the RAP is to obtain a consistent The purpose of the RAP is to obtain a consistent first version of the conceptual schema.first version of the conceptual schema. Validation, verification and traceability are key issues.Validation, verification and traceability are key issues.
The traceability model we use is the structural and The traceability model we use is the structural and cross-reference-based model.cross-reference-based model.
The validation consists of reviewing each one of The validation consists of reviewing each one of the use cases and its corresponding sequence the use cases and its corresponding sequence diagrams with the user to see that they provide the diagrams with the user to see that they provide the behavior implied in the use case specification.behavior implied in the use case specification.
19
Validation, Verification and Traceability (cont’d)Validation, Verification and Traceability (cont’d)
Object ModelObject Model The verification we carry out involves looking at all The verification we carry out involves looking at all
the identified the identified classesclasses and their services in the and their services in the sequence diagramssequence diagrams..
To re-examine the use cases and the To re-examine the use cases and the corresponding sequence diagram to find that corresponding sequence diagram to find that missing behavior.missing behavior.
For traceability purposes, we can represent the For traceability purposes, we can represent the allocation and flowdown of use cases to classes by allocation and flowdown of use cases to classes by means of a means of a function decomposition tablefunction decomposition table..
20
Validation, Verification and Traceability (cont’d)Validation, Verification and Traceability (cont’d)
21
Conclusions and Further WorkConclusions and Further Work
Research in the requirements engineering area Research in the requirements engineering area should be oriented towards properly embedding should be oriented towards properly embedding requirements engineering into the software requirements engineering into the software production process as a whole.production process as a whole.
The integration providesThe integration provides Start from generally accepted notational standards and Start from generally accepted notational standards and
techniques to specify user requirementstechniques to specify user requirements Gives methodological guidance to convert these Gives methodological guidance to convert these
requirements into a precise conceptual schemarequirements into a precise conceptual schema Links this conceptual schema with model-based code Links this conceptual schema with model-based code
generation techniques of the OO-Methodgeneration techniques of the OO-Method