systematic research of combinatorial effects at requirements engineering level
DESCRIPTION
Systematic research of Combinatorial Effects at Requirements Engineering Level . Jan Verelst Alberto Rodrigues Silva Herwig Mannaert David Almeida Ferreira Philip Huysmans. Overview. Introduction Normalized Systems Theory Identifying Combinatorial Effects BPMN UML Use Cases - PowerPoint PPT PresentationTRANSCRIPT
Systematic research of Combinatorial Effects at Requirements Engineering Level
Jan VerelstAlberto Rodrigues SilvaHerwig MannaertDavid Almeida FerreiraPhilip Huysmans
2
Overview• Introduction• Normalized Systems Theory• Identifying Combinatorial Effects
- BPMN- UML Use Cases- “Real World”- UML Domain Models- DEMO/EO
• Conclusions• Research agenda
3
Introduction • The origin: Sabbatical Alberto Silva, specialized in
Requirements Engineering (RE)• The idea: to apply Normalized Systems Theory (NS) to RE.
Can RE be considered in terms of modular structures ? Or is this too technical and therefore inappropriate ?- Jorge Sanz’ talk: bring EE to mainstream management !- “Together with communications theory-based approaches, such as
DEMO, this would suggest that the real world is first and foremost an area of human behavior, which should therefore not predominantly be studied by theories based on computer science and/or automation. We agree with this point of view. Nevertheless, in modern society, human behavior increasingly takes place in highly structured, process- based contexts. Therefore, we argue that it is relevant to study these aspects of reality based on concepts such as modularity, while at the same time making an abstraction from purely human and communication aspects.”
4
Software Requirements Specs• Software Requirements Specification (SRS)
- A requirements specification is used throughout different stages of the project life-cycle, namely to help sharing the system vision among the main stakeholders, as well as to facilitate their communication, the overall project management, and system development processes.
• Benefits- Establishes the basis for agreement between the customers
and the suppliers on what the system is expected to do; - reduces development efforts; - provides a basis for estimating costs and schedules;- provides a baseline for verification and validation; facilitates
the system deployment;and - serves as a basis for future maintenance activities
5
Business and System Level• Business level
- Constructs• Terminology, goals, stakeholders, business processes, business use cases
- Languages/Models• Goal-oriented languages (i*, KAOS), UML, BPMN, RUP Business Modeling, DEMO/EO, Archimate
• System level- Context models
• Constructs- System, subsystem, componenents, nodes, external actors
• Languages- SysML Block Diagrams, UML Deployment Diagrams, Data Flow Diagrams
- Domain Models• Constructs
- Entities, classes, …• Languages
- UML Class Diagrams, Entity Relationship Diagrams- Functional requirements models
• Constructs- Actors, functional requirements, use cases, scenario’s, user stories
• Languages- Natural language enriched with metadata (priority, risk levels…), UML Use Case diagrams, SysML Requirements Diagrams
- Quality attribute models• Constructs
- Qualities, metrics, utility values, • Languages/Models
- lists of quality attributes, quality-attributes scenario’s
6
Why study CE at RE-level ?• In theory
- The importance of evolvability in RE is sometimes overlooked
• OO: anthropomorphism • Simsion et al.: analysis = creative design activity
• In practice- Inability to evolve may lead to misalignments
between requirements and information systems• Requirements often constitute documentation => out-of-
date- RE requires considerable resources => inefficient
7
About NS Theory• A theoretical framework investigating Modular
Structures under Change- Based on Systems Theoretic concepts
• Completely independent of any framework, programming language, package, …
• Has shown to be able to deal with the challenge of increasing complexity- E.g. hardware, Internet, space industry…
- Initial scope: Modular Structures in Software Architectures- Publications: book, >50 conference proceedings, (invited)
lectures at different universities…- Education: undergraduate, postgraduate…
8
NS @ software level
Struct Invoice
- Nr
- Date
- …
Struct Customer
- Name
- Address
- VATnr
- …Func computeInvoice Func inviteCustomer Func sendInvoice
Struct
Func
IMPACT
IMPACT IMPACT N
N
IMPACT
9
NS Principles• Modularity x Change Combinatorial Effects (CE) !
- CE = (hidden) coupling or dependencies, increasing with size of the system !
- NS Principles identify CE at seemingly orthogonal levels• SoC: Which tasks do you combine in a single module ?
- “An action entity can only contain a single task.”• DVT: How do you combine a data and action module ?
- “Data entities that are received as input or produced as output by action entities, need to exhibit version transparency.”
• AVT: How do you combine 2 modules ?- “Action entities that are called by other action entities, need to exhibit version
transparency.”• SoS: How do you combine modules in a workflow ?
- “The calling of an action entity by another action entity needs to exhibit state keeping.”
• CE explain Lehman’s Law of Increasing Complexity !
10
NS SummaryAssumption:
Modular Structures:
Complexity ↑
X
Change ↑
Current Practice
1. Modularity
- Combinatorial Eff.
- White-box reuse
- Lehman
2. Standardization
- No expansion
NS-Determinism
1. Modularity
- No Combinatorial Eff.
- Black box reuse
- Lehman controlled
2. Standardization
- ExpansionFine-grained/
No Combinatorial Eff.
Expansion
Black-box reuse/
Lehman controlled
Lehman
11
NS as a simple transformation over F/C gap
Data
Tasks
Customer
-Name
-Address
-VATnr
…
Invoice
-Nr
-Date
-…
Struct Invoice
- Nr
- Date
- …
Struct Customer
- Name
- Address
- VATnr
- …
computeInvoice inviteCustomer sendInvoice
Func computeInvoice Func inviteCustomer Func sendInvoice
Struct
Func
F
C
Change:
addAttribute
IMPACT
IMPACT
N
IMPACT NIMPACT
14
The concern trapezoid
Business
ICT
Examples of concerns:
“Want innovative invoicing”
High-level business
- Strategy (innovation vs cost)
- Internationalisation
High-level ICT
- Stick with current package
- Commodity ICT
Human
- Stakeholder issues (political…)
- Communication, negotiation
Concerns are additive (?)
#concerns ↑↑ Examples of concerns:
Low level ICT:
- Performance of an algorithm or call to package
- Interface stability
- Internationalisation libraries present
- Technical security details
- …
F
C
15
Bridging a F/C gap• An ill-structured (or wicked) design problem
- Incomplete and ambiguous specification of the problem;- No deterministic path to solution;- Knowledge of several domains needs to be integrated in order
to find a solution;- No clear criteria te compare and evaluate possible solutions.
• Characteristics- M:N, not 1:1- Integration = Fragile/Non-lineair behavior: 5% extra reliability
totally different architecture- Integration = sometimes all-or-nothing
• ALL concerns need to be separated at compile/deploy/runtime, or the remaining coupling
- May make the artifact totally useless in practice !- Solving this requires a white box-perspective without complexity reduction !
16
NS as a complex transformation over F/C gap
Invoice
Element IMPACT
IMPACT
IMPACT
Customer
Element
invite
Customer
Element
compute
Invoice
Element
send
Invoice
Element
F
C
Customer
-Name
-Address
-VATnr
…
Invoice
-Nr
-Date
-…
computeInvoice inviteCustomer sendInvoice
Data
Tasks
Change:
addAttribute
Action
Elements
Data
Elements
26
Enterprise = n F/C gaps
Strategy
PPM/EA
PM
RE/Analysis
(Alberto Silva’s group)Design
Implementation
Maintenance
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
RW
DEMO/EO
Use Cases
BPMN
Domain Models
Increasing
modular
structure
NS@
Software
F
C
F
C
F
C
F
C
F
C
27
Enterprise = n F/C gaps
Strategy
PPM/EA
PM
RE/Analysis
(Alberto Silva’s group)Design
Implementation
Maintenance
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
RW
DEMO/EO
Use Cases
BPMN
Domain Models
Increasing
modular
structure
NS@
Software
F
C
C
F
C
F
BPMN models
29
BPMN-createExpenseReimbursement
30
BPMN
Real World
createBonusPayment
BPMN Task
F
C
Change:
checkAccountExistence v2
IMPACT
N
IMPACT N
createExpenseReimbursement createBonusPayment
IMPACT
Real World
createExpenseReimbursement
checkAccountExistence is shared
N
31
BPMN-with separated Task
BPMN Task
F
C
createExpenseReimbursement createBonusPayment N
checkAccountExistence
IMPACT
Real World
createBonusPayment
Change:
checkAccountExistence v2
Real World
createExpenseReimbursement
checkAccountExistence is shared
N
Remark:this is NOT an
NS element !
32
BPMN• PhD Dieter Van Nuffel contains examples of CE
regarding SoC and 25 guidelines to eliminate them• Modular structure ?
- “Easy, obvious !”- Constructs ?
• All BPMN constructs…- CE ?
• Violations of SoC, SoS may occur• application of AvT and Dvt is less clear
• Implications- Evolvability of BP is limited
• popular claim of BPM-engines, even though they do add evolvability at the software-level !
UML Use Cases
34
UML Use CasesUse Case createExpenseReimbursement3. checkAccountExistence
4. createAccount…7. reimburse
Use CasecreateBonusPayment3. checkAccountExistence
4. createAccount5. executePayment
35
UML Use Cases
Real World
Interviews (oral)
Interview transcripts
Use Cases
F
C
Change:
checkAccountExistence v2
IMPACT IMPACT
createExpenseReimbursement createBonusPayment N
IMPACT N
36
UML Use Cases-with hypertext construct
Real World
Interviews (oral)
Interview transcripts
Use Cases
F
C
Change:
checkAccountExistence v2
createExpenseReimbursement createBonusPayment N
checkAccountExistence
IMPACT
Remark:this is NOT an
NS element !
37
Use Cases• Modular structure ?
- Constructs ?• YES
- Name of the use case => primitive interface of the module- Pre- and post-conditions => delineate functionality of the module- Workflow (tekst) => functionality details of the module- Other: A scenario, an exception, a trigger, a stakeholder, …
• NO- Text-based use cases allow for GOTO’s, ambiguities…- Hypertext construct not always available in tooling !
- CE ?• Use cases are usually too underspecified to allow detailed analysis of CE• Violations of SoC may occur• application of AvT and Dvt is less clear: do use cases have interfaces ?
• Implications- Evolvability of Use Cases is limited
• This is a well-known issue, particularly in large projects, - Maintaining documentation becomes expensive- Use Cases does not necessarily document the code (when the code itself is changed)
Real World
39
Example 1: createExpenseReimbursement
Real World
Interviews (oral)
Interview transcripts
Manually
Executed
BP & IS (=paper)
F
C
Change:
checkAccountExistence v2:
“Use NL bank only from now !”
IMPACT IMPACT
Actor 1:
createExpenseReimbursement
Actor 2:
createBonusPayment
N
IMPACT N
40
Example 1: createExpenseReimbursement
• This example can be 100% manual !• Modular structure ?
- Constructs ?• Human actors executing formal/informal procedures
- CE ?• Visible at runtime (resources): Violation of SoC ?
41
Example 2: Exam Marks
Real World
Procedure: ‘our university applies
… rounding’
Decentralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT IMPACT
Professor 1 Professor 2N
IMPACT N
42
Example 2: Exam Marks• Modular structure ?
- Constructs ?• Human actors executing formal/informal procedures
- CE ?• Visible at runtime (resources): Violation of SoC ?
43
Example 2: Exam Marks – Compile Time Model
Real World
Procedure: ‘our university applies
… rounding’
Decentralized
Execution of
BP & IS
F
C
Change:
Procedure v2
INVISIBLE
IMPACT !!!
Procedure
Executed
by all Professors
N
44
Example 2: Exam Marks
Real World
Procedure: ‘our university applies
… rounding’
Centralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT
Student
Office
45
Example 3: Mail distribution
Real World
Procedure: ‘our university allows
physical mail’
Decentralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT IMPACT
Secretary 1 Secretary 2N
IMPACT N
46
Example 3: Mail distribution• Modular structure ?
- Constructs ?• Human actors executing formal/informal procedures
- CE ?• Visible at runtime (resources): Violation of SoC ?
47
Example 3: Mail distribution
Real World
Procedure: ‘our university applies
… rounding’
Centralized
Execution of
BP & IS
F
C
Change:
Procedure v2
IMPACT
Centralized &
virtual e-mail office
N
48
Real World• Modular structure ?
- Constructs ?• Manual: actors, departments, manual databases, manual
procedures, …• (IT-based execution):
- CE ?• Violations of SoC may occur
- Violations of SoC are close to discussions in management literature on » ‘decentralization vs centralization’ » ‘the need for matrix organizations on top of departments’» ‘the need for business processes on top of departments’» => EE and Organizational Sciences meet !
» Remark: Organizational Sciences have swinging preferences over time for many of these topics…
• Implications- Enterprises, even manual ones, have limited evolvability
UML OO Domain Models
50
UML OO Domain Models
51
OO Domain Models• Modular structures
- See OO programming… YES !• CE
- Data:• Codd’s normalization… but is this sufficient ?
- Functions:• Violation of DvT: use of atomic data types• Violation of SoS: Use of sync pipelines
• Coupling- Is high coupling the reason that domain models
are not in widespread use in practice ?
DEMO/EO
53
• Are DEMO/EO models modular structures ?- A few indications, but we did not focus on DEMO/EO specifically
in this paper !• Similarities between DEMO and NS
- Separation of State in NS => P- and C-facts !- Workflows in NS => structured aggregations of actions into
transactions- Expansion in NS => instantiating transaction pattern in DEMO
• Do DEMO/EO-models contain CE ?- Possibly…- In production acts…- In implementation, but is this DEMO/EO ?- In runtime behavior, but is this DEMO/EO ?
• Nevertheless, we should find out… see conclusion !
54
DEMO transactions
• The production act of a transaction seems to be a module consisting of a number of tasks, detailed in the action models.
• However, for each production act, there are 4 coordination acts transactions are aimed at coordination-intensive problems, like enterprises consisting of human actors.
• Actually, such transactions define the interfaces of the modules !
- Reminds of negotiation at operational level, but also project level (~IS acceptance problems)
- This is why DEMO/EO works so well: it is human modularity, which is used to control complexity, and…
55
DEMO transactions• Reduce complexity by 70-90 %• By using the transaction pattern, with the same internal
structure, for all transactions• = similar approach to NS expansion !
Conclusion
61
CE exist at all these levels !
Strategy
PPM/EA
PM
RE/Analysis
(Alberto Silva’s group)Design
Implementation
Maintenance
NS @ Enterprise=
Normalized
Transformation
Over the
F/C gaps
RW
DEMO/EO
Use Cases
BPMN
Domain Models
Increasing
modular
structure
NS@
Software
F
C
C
F
C
F
62
Conclusions• Examples of CE’s are relatively straightforward but
- they are sufficient to illustrate the omnipresence of instabilities in a domain that is sometimes considered to be about "identification of objects in the real world”.
- at the software, heuristics have shown to be insufficient to control the large number of highly complex CEs that are responsible for the symptoms of Lehman’s law.
- Some examples of CE’s correspond to technical advances • Eg. The shift from physical to e-mail• => this CE is no marginal detail !
• Implications- Initially, when the system is small, the CE’s would probably not be
problematic, but over time their effects would grow and slowly but surely increase the rigidity of requirements models and specifications (which are sometimes used as the technical documentation of the information system, or a component in a legal contract concerning the system).
63
Conclusions - Research Agenda1. Identification of CE at each enterprise level at
compile-, deployment- and runtime, as well as entropy-related issues
2. Mechanisms to control CE1. Expansion/tooling (hypertext support in RE-tool?)2. (semi-)manual mechanisms at E-level ?
3. Appropriate levels of control at each enterprise level1. The examples show that these CE exist, and many employees will
feel that they should be removed => NS perspective on Enterprises is not ‘too technical’, but
2. at the same time: Enterprises remain human entities, and it is extremely unlikely that they should be normalized to the same extent as software !
64
Conclusions - Research Agenda• Approach: domain-dependent artifacts, such as
in classical engineering !- “loosely coupled artifacts need to be developed in areas
such as finance, accounting, transport, human resources, or in subareas such as invoicing, staffing, project management, mail distribution, payments, etc.”
- Then: “When these artifacts are developed using a modular structure which exhibits control of coupling issues (such as a low number of CE), they can be aggregated into higher-order structures such as an invoice.”
- Ex: PhD Els Vanhoof: simple problem, no solution in 2013 !
65
Link to Business Meeting…This paper illustrates how Antwerp and Lisbon were able to collaborate, in the context of Alberto Silva’s sabbatical ! Let’s continue this, and do more, because…
“In this way, we support the call by Dietz et al. for the area of Enterprise Engineering to be developed [33]. The amount and complexity of issues that need to be solved to achieve the next generation of truly agile enterprises both in the service and industrial sector, both in the for-profit and not-for-profit sector, is such that a scientific basis focusing on structural issues (including coupling) will be required.”
Thank you for your attention !