Reuse, Standardization, and Transformation of ... - Semantic Scholar

Reuse, Standardization, and Transformation of Requirements Miguel A. Laguna, Yania Crespo University of Valladolid, Spain

Oscar López Tech. Institute of Costa Rica

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

2

Agenda Introduction „ „

Software reuse and Requirement Engineering Product Lines and Requirements

Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

3

Requirements and Reuse Software Engineering Software Reuse Productivity and quality Increase

Requirements Reuse Requirement Engineering

Requires Asset Model Reuse Process Tool Support

10-jul-04

Users needs

ICSR 2004-Madrid

4

Software reuse Improves the software development process… „

in restricted and well-understood domains

The Product Line approach increases productivity and reduces the development cost for each product, improving its quality 10-jul-04

ICSR 2004-Madrid

5

Our approach… Based on coarse grain reusable elements, or mecanos Mecanos are complex structures made up of fine grain elements (assets) of different levels of abstraction: „ „ „

Requirements Design Implementation 10-jul-04

• The requirements are the access gate to the other elements • The success of software reuse depends on the requirements

ICSR 2004-Madrid

6

Requirements assets With different degrees of formalization Declarative (rules) and procedural (scenarios) requirements Aims (goals and soft-goals) and means to reach them Varying granularity Functional and non-functional requirements User requirements and developer requirements 10-jul-04

ICSR 2004-Madrid

7

Perspective of reuse User Functional Fine or medium granularity Procedural or declarative format Low level of formalization

10-jul-04

ICSR 2004-Madrid

8

In short... We must standardize the requirements stored in the repository But if the requirement format is not suitable for this repository, a transformation mechanism is needed The base for this mechanism must be a common model of requirements that integrate most concepts from the requirements engineering discipline 10-jul-04

ICSR 2004-Madrid

9

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

10

Agenda Introduction Standardization of functional requirements „ „

General Framework Petri net based formalism

A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

11

General framework

User Level

Software Engineer Level CG

Generate CG

Administrative Workflow (dDT)

Generate BUC Get User’s Approval BUC

Requirements Engineering

BUC Approval Approval

Generate UC

Get User’s Approval UC BUC Approval Generate Assets Assets

10-jul-04

Approval Mecano Management

ICSR 2004-Madrid

Analysis Assets

12

Petri net based formalism Generate CG

A Case Graph: Is a four-tuple (D,T,A,E): ƒD is a finite set of documents ƒT is a finite set of tasks (D∩ ∩T=∅ ∅). ƒTP is a disjointed partition of T, TP= {T(AA), T(AO), T(OO), T(OA)} ƒA is a set of arcs, A ⊆ ((DxT) ∪ (TxD)) ƒE: D∪ ∪T→ →∑+ is a label function.

CG Generate BUC

Requirements Engineering UC

BUC

Generate UC

OA

AA

Tasks

AO

OO

2.A. The four kind of tasks for CG modeling Preconditions

Time Event Parallel Actions

#. Name of Task - Kind of Task - Subtasks

Sequential Action

Conditional Action

Iterative Action

? Postconditions Responsible 2.B. Graphical representation for tasks in CG

ACTION

AA

AA

AA

AO

AA

AA

AA

AA

OA

AO

2.C. The four kind of basic routing for CG modeling

10-jul-04

ICSR 2004-Madrid

13

PN formalism: normalization Generate CG

CG

normalization

Generate BUC

Requirements Engineering UC

OA

AA

AA

AO

AA

AA

OO

AA

BUC

Generate UC

Petri Nets: •Formal semantics •Graphical language •Analysis Techniques •Workflow modeling •Universality 10-jul-04

AA

AA

AA

2.D. Standardization for OA, AO and OO tasks in CG

ICSR 2004-Madrid

14

PN formalism: BUC and UC Generate CG

CG Generate BUC

Requirements Engineering UC

BUC

BUC Graph: Graph: G is a BUC Graph if: –It It contains all the possible case sequences for an input document from an external actor.

Generate UC

UC Graph: Graph: G is a UC Graph if: –It It contains case sequences which correspond to an internal actor inside a BUC Graph. Graph. –All All the tasks of G are of the AA kind. kind. That is, is, T= T(AA) so satisfied.. (T(AO) ∪ T(OO) ∪ T(OA) )=∅ )=∅ is satisfied

Case1 Case2

Internal Actor

Case3 CaseM

10-jul-04

ICSR 2004-Madrid

15

Summarizing....User Level Software Engineer Level CG

Administrative Workflow (dDT)

Generate CG

Generate BUC Get User’s Approval

Requirements Engineering

BUC

BUC Approval Approval

Generate UC

Get User’s Approval UC BUC Approval Generate Assets Assets

–System Description •Quick elicitation •Precise description –Modeling techniques •Use Cases •Petri Nets •Workflow –Reusable assets

Approval Mecano Management

10-jul-04

Analysis Assets

ICSR 2004-Madrid

16

Case study: IBERDROLA Particular Customer Area Agent

REQUEST D1 D2

EXECUTION

D5

T11-AA

T1-OO

Op

CC

Requester

T2-OA CC

D3 D10

D27

D26

T12-AA

T10-AA

D6

Op

Op

D7

Security Committee

T3-AO D28

CC

D8

Particular Customer

D4

D9

D19

Affected customer

D12

T4-AA

D11

CC

T5-AO

D16P

T6-AA

CC

D13

D14

D31 T13-AA

D15

D16

Requester

Op

D25 D18 D17

Requester

Area Agent

D29

CC

D15

Enterprise Organizations Tax Organizations

10-jul-04

T7-AO

T14-AA T8-AA

CC

CC

D20

D21

D22

D30

Op

T9-AA CC

D23

D24

RESOLUTION ICSR 2004-Madrid

D32 D33

T15-AA Op

REFUND 17

Case study: BUC Graphs Particular Customer

Area Agent Requester

Requester

D3

Security Committee

Affected Customer

D2

D1

D5

T1

Tax Organizations

Area Agent

D4 D18

D7

D8

D17

T3 D9

D10

T2

T2

T2

D6

D6

D6

T3

T3

T3

D9

D10

D9

D10

D29

D32

T9

T13

T15

D25

D30

D24

D9

D33

D10

T14

T7 T4

T4

T4

D13

T4

D31 D11

D12

D11 D16P

T5

D15

D12

D11 D16P

T5

D15

D16

T8 D20

T10 D28

D23

D16

D21 D22 D26 T12

D23

D16

D26

T10

D27

D28

10-jul-04

T12

T11

D20

D27

D23

D28

D16

T12

T11 D27

D23

D28

D14 D16

D21 D22 D26

T10

T12

ICSR 2004-Madrid

D15 T6

D19

T8 D20

D16P

T5

D15

D14

D21 D22 D26

T10

D16P

T6 D19

T8

D12

T5

D15

D14

D20 D21 D22

T11

D16P

T6 D19

T8

D11

T5

D15 T6

D14

D12

T11

D23

D28

D16

D21 D22 D26

T10 D27

D19

T8 D20

T6 D14

T12

T11 D27

T8

D20 T10

D19 D23

D21 D22

D26 D28

T11

T12

18

D27

Case study: UC Graphs Tax Organizations

Fill out requests

Area Agent

D2

Particular Customer

D3

T1 D4

D24

D1

D29 T2 D6

Security Committee D7

D5

Receive requests

T3

Requester

D17

T9

D9

D10

T4

D12

GRAPH H

T5

GRAPH D

D13 D14

D20 D21 D22

Communicate decisions

T10

D26 GRAPH F

ICSR 2004-Madrid

T6

D19

Dicision making

D23 GRAPH E

D31

D16P

GRAPH G

T8

D33

Affected Customer

D15

Modify unloadings

T14

D25

Receive legal GRAPH I GRAPH J autorizations Document Record data Timetables

Request Study T7

T15

D30

D11

GRAPH C

D16

T13

GRAPH B

D8

10-jul-04

D32

GRAPH A

Requester

D18

Area Agent

T11 D28

D27 T12

Execute decisions

19

Case study: Use Cases GRAPH C GRAPH G GRAPH A GRAPH B Control Centre

GRAPH E GRAPH D

GRAPH F GRAPH I

Local Operator

10-jul-04

GRAPH J GRAPH H

ICSR 2004-Madrid

20

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

21

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation „ „

Requirements Meta-model Transformation process

Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

22

Meta-model integration MOF Meta-meta Level

(Meta Object Facility)

Requirements Meta-model Use cases

Scenarios

DFD

dDT

Meta Level

...

Model Level

Data Level 10-jul-04

ICSR 2004-Madrid

23

Requirement typology RE Product

Dependency

Specification

Representation

Negotiation

Semiformal

Not Formal

Formal

Structure 10-jul-04

Behavior ICSR 2004-Madrid

Structure and Behavior 24

Meta-model for Requirements Compulsory

Optional

Alternative

1..*

characterize > 1 0..1

Unit Model Relationship

*

1..*

1 parent * child

Domain Objective

Subset

Exception

Project

Model Relationship 1 *

Complement

Multiple

Equivalence

Dependency

*

1

Extension

Association

Inclusion

Generalization

1

Requirements Representation

*

Modeling Unit

2..*

source 1 * target 1

Unit Relationship

*

Meta Level Semiformal

Behavioural Model

Structural Model

Behavioural and Structural Model

Constraint

Temporal Constraint

Physical

Connector

Resource Constraint

Data

Linear

Goal

From User

Joint

State

From System

Split

*

Subject

Action

Job

Person

Company Unit

Autonomous System

Activity

Model Level Workflow Diagram

Use Cases Diagram

10-jul-04

Scenarios Diagram

Sequence Specification Template

ICSR 2004-Madrid

Activity Diagram

DocumentTask Diagram

Data Flows Diagram

25

Metamodel Compulsory

Optional

Alternative

1..*

characterize > 1 0..1

Unit Model Relationship

*

1..*

1 parent * child

Domain Objective

Subset

Exception

Project

Model Relationship 1 *

Complement

Multiple

Equivalence

Dependency

*

1

Extension

Association

Inclusion

Generalization

1

Requirements Representation

*

Modeling Unit

2..*

source 1 * target 1

Unit Relationship

*

Meta Level Semiformal

Behavioural Model

Structural Model

Constraint

Behavioural and Structural Model

Temporal Constraint

Physical

Use Case Diagram

Actor

Connector

Resource Constraint

Data

Linear

Goal

From User

Joint

State

From System

Split

*

Subject

Action

Job

Person

Company Unit

Autonomous System

Activity

Use Case 1

Use Case 2

10-jul-04

ICSR 2004-Madrid

26

Transformation of requirements Equivalences between instances of each meta-class: „

workflow activities and use-cases are related by the Sequence Specification Template

These equivalences has been automated and used in the transformation of a requirements asset into another format „

some times with the final decision of an requirements engineer 10-jul-04

ICSR 2004-Madrid

27

Steps of the transformation 1. 2. 3. 4. 5.

Get a Requirements diagram Model this diagram using a Case Graph Analyze this Case Graph (CG) Generate BUC Graphs and UC Graphs Refine the Graphs, transforming all the AA, OA, and OO task into AA tasks 6. Factorize the Case Graph 7. Extract the requirements assets 10-jul-04

ICSR 2004-Madrid

28

Transformation of requirements Activity

R2 R2

Doc. Task

WorkFlow

Case Graph

BUC/UC

Doc. Task

Modular CG

Use Case

Repository Repository

Activity 10-jul-04

WorkFlow

ICSR 2004-Madrid

DFD

Scenarios 29

Steps of the transformation 1. 2. 3. 4. 5.

Get a Requirements diagram Model this diagram using a Case Graph Analyze this Case Graph (CG) Generate BUC Graphs and UC Graphs Refine the Graphs, transforming all the AA, OA, and OO task into AA tasks 6. Factorize the Case Graph 7. Extract the requirements assets 10-jul-04

ICSR 2004-Madrid

30

The second step... Correspondence between meta-classes of the meta-model and the elements of the Case Graph: „

Subject Æ Actors

„

Activity ÆTransitions

„

Constraint and Connector Æ Places 10-jul-04

ICSR 2004-Madrid

activity doc1 31

The second step... Activity diagrams into Case Graph

Linear flow

Alternate flow

Concurrent flow 10-jul-04

ICSR 2004-Madrid

32

The second step... WorkFlow into Case Graph

Bifurcation connector

Union connector 10-jul-04

ICSR 2004-Madrid

33

Steps of the transformation 1. 2. 3. 4. 5.

Get a Requirements diagram Model this diagram using a Case Graph Analyze this Case Graph (CG) Generate BUC Graphs and UC Graphs Refine the Graphs, transforming all the AA, OA, and OO task into AA tasks 6. Factorize the Case Graph 7. Extract the requirements assets 10-jul-04

ICSR 2004-Madrid

34

The last step.... Extract the requirements assets to be visualized, edited, or stored in a repository It is specific for every type of diagrams.

10-jul-04

ICSR 2004-Madrid

35

Activity diagram from a BUC Graph An Activity diagram is obtained from a BUC Graph with the corresponding equivalences: „ „ „

Swimlanes are generated from Actors, Activities are generated from Transitions, Connectors (Linear, Joint, or Split) are generated from Places, depending on the type of Place 10-jul-04

ICSR 2004-Madrid

36

Activity diagram from a BUC Graph

10-jul-04

ICSR 2004-Madrid

37

Use cases from a Modular Case Graph An Use Case diagram is obtained from a Modular Case Graph: „

„ „

Every UC Graph is transformed in a use case of the a global use case diagram Actors are generated from Actors Activities of the Sequence specification Template are generated from transitions

10-jul-04

ICSR 2004-Madrid

38

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

39

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support „

R

2

Transformation of diagrams Conclusions and future work „

10-jul-04

ICSR 2004-Madrid

40

2

The R tool Es estratégico el soporte de herramientas.... Requirements Reuse

Translator

Quality Metrics

Editor

Data Manager

Lexical Module

Data Exchange

GUI

10-jul-04

ICSR 2004-Madrid

Meta-Model Meta-Model

XML

Repository Repository

Design/CPN Design/CPN

41

10-jul-04

ICSR 2004-Madrid

42

2

R

10-jul-04

ICSR 2004-Madrid

43

2

R and diagram transformations

10-jul-04

ICSR 2004-Madrid

44

2

R and diagram transformations

10-jul-04

ICSR 2004-Madrid

45

2

R benefits 1.

Integration of diverse techniques Use Cases, DFDs, WF, ...

Meta-Model Meta

2.

Transformation Some manual work

3.

Model

UC

Quality metrics

AD

WF

dDT

80 70 60 Proy1 Proy2 Proy3

50 40 30 20 10

Syntactic verification

0

Diag1

Diag2

Diag3

CPN

Low level of formalism 10-jul-04

Sc

90

Some internal attributes 4.

DFD

ICSR 2004-Madrid

46

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

47

Agenda Introduction Standardization of functional requirements A Model of Requirements for Transformation Tool Support Conclusions and future work

10-jul-04

ICSR 2004-Madrid

48

Conclusions Semi-automatic generation of requirements assets guarantees their standardization in the repository The proposed meta-model describes modeling information on the Requirements Reuse context This Meta-model supports the transformation of several types of Requirements formats 10-jul-04

ICSR 2004-Madrid

49

Future work Empirical research must be be conducted to evaluate the approach „

We are applying our model and tool to the generation of new requirements specifications in a specific domain

We expect: „

„

Reusing requirements will provide better requirements specification Requirements engineers will focus on decisions regardless of the details 10-jul-04

ICSR 2004-Madrid

50

ICSR 2004 - Madrid

Reuse, Standardization, and Transformation of Requirements Miguel A. Laguna, Yania Crespo University of Valladolid, Spain

Oscar López

Tech. Institute of Costa Rica

…Thank you