Supporting Concurrent Development of Requirements and Architecture

I held this talk at the 2014 MODELSWARD conference in Lisbon, Portugal

Transcript

1. Technische Universität München Supporting Concurrent Development of Requirements and Architecture: A Model-based Approach MODELSWARD 2014 January 08, 2014 Andreas Vogelsang1, Sebastian Eder1, Georg Hackenberg1, Maximilian Junker1, Sabine Teufl2 2 fortiss GmbH, Munich, Germany 1 Institut für Informatik Technische Universität München
2. Technische Universität München • Requirements engineering and architecture development is often not carried out in a sequential manner • A more realistic view of development: Requirements and Architecture 2 1 B. Nuseibeh: "Weaving Together Requirements and Architectures“, IEEE Computer, 2001 The Twin Peaks model1 Challenge: consistency between artifacts2 2 A. Etien and C. Salinesi: “Managing requirements in a co-evolution context”, RE 2005
3. Technische Universität München Approach 3
4. Technische Universität München Review and Analysis Procedures • Manual Review between Use Cases, Scenarios and MSCs – Validation of the formalization – Based on checklists • Automated MSC Feasibility Checks between MSCs and Formal Specifications – Transformation of MSC to temporal logic proposition – Model checking against formal specification • Automated Refinement Tests between Formal Specification and Architecture* – Test cases generated from the formal specification – Translation to test cases for the architecture – Execution on the architecture – Comparison to the results of the original test case 4 * D. Mou et al.: "Binding requirements and component architecture by using model-based test-driven development" International Workshop on the Twin Peaks of Requirements and Architecture, 2012
5. Technische Universität München Study Object: The CMCS • Canal Monitoring and Control System1 – controls a system of canals on which ships are cruising – canals are equipped with locks and bridges • Case documented by a requirements specification – 2 Use Cases (pass Bridge, pass Lock) – Domain Model – Hardware Topology 5 1 Case taken from the 2011 Workshop on Model-Driven Requirements Engineering (MoDRE 2011)
6. Technische Universität München Evaluation: Setting • Goal: How does MDE perform in a co-evolutionary dev. context? • CMCS system developed in master-level practical courses (2x) – Overall 15 students (8 + 7) – Divided into two groups: • Requirements engineers • Architects – Duration: 4 months – Reviews by course supervisors – Tool Support: AutoFOCUS31 6 Requirements Engineers Architects Project time Use Cases/ Scenarios MSCs Formal specifications Architecture 0 % 100 % 1 http://af3.fortiss.org
7. Technische Universität München Experiences • Feasibility – System was successfully developed and deployed 7
8. Technische Universität München Experiences • Correctness of Requirements – Uncovered misconceptions regarding the behavior of the environment 8
9. Technische Universität München Experiences • Concurrent Development of Requirements and Architecture – Consistent requirements and architecture artifacts 9 MSCs Formal Specification
10. Technische Universität München Experiences • Concurrent Development of Requirements and Architecture – Information flow from requirements to architecture and vice versa 10 Architecture (excerpt)
11. Technische Universität München Experiences • Explicit Design Decisions – Relation links document the design decisions – Abstract signals are translated to concrete logical signals 11 Formal Specification Architecture (excerpt)
12. Technische Universität München Experiences • Scalability – 2 use cases, 10 scenarios, 17 properties (14 formalized) – Analysis: • most time consuming MSC feasibility check (36 steps: ~100 sec.) • Problems – Formal Specifications and Architecture sometimes very similar • Potential for reuse 12
13. Technische Universität München Conclusions and Future Work Conclusions: 1. Detection of inconsistencies in requirements through (semi)formal approach 2. Continuous consistency checks facilitate concurrent development 3. Design decisions captured by artifact relations Future Work: – Integrate nonfunctional requirements into the formal specifications – Effort/Usage examination 13 Thanks for the attention. Special thanks to: The students of our master’s course and the AF3 developers at fortiss GmbH
14. Technische Universität München Backup
15. Technische Universität München Artifacts: Requirements 15
16. Technische Universität München Artifacts: Formal Specification 16
17. Technische Universität München Artifacts: Architecture 17