1. 1 Overview of the project: Requirement-Driven Development of Distributed Applications School of Information Technology and Engineering (SITE) University of Ottawa November 2002 through October 2005

2. 2 Investigators Gregor v. Bochmann Daniel Amyot Amy Felty Luigi Logrippo Bob Probert Stephane Somé Funding: NSERC strategic research grant

3. 3 Industrial partners klocwork Nortel Networks Telelogic Borland (TogetherSoft) Motorola Industry Canada Mitel Networks

4. 4 Objectives To develop the available notations for specifying requirements, such as Use Case Maps (UCM), UML Activity Diagrams and other scenario notations, by comparing their usefulness, proposing formalizations and improvements, and contributing to related standardization activities in ITU and OMG. To develop innovative methods and tools that can be used for the development of correct and secure system design models from a given specification of the requirements, considering in particular the possibilities for automating certain parts of this design process. To develop innovative formal validation and verification methods and tools appropriate for this process. To evaluate the notations, methods and tools by applying them to realistic examples of distributed systems, especially in the area of service development for Internet telephony, e-commerce, and standard protocols developed by the Internet Engineering Task Force (IETF).

5. 5 Previous work of participants Development of the Use Case Map Notation for requirement specification Using logics for requirement specification Using structured English for expressing requirements in terms of scenarios Using LOTOS Extended FSM and Petri Nets formalisms Cause-Effect Graphs

6. 6 Working hypothesis Scenario-based requirement specification techniques (such as Use Case Maps, and various components of the UML notation) appear attractive and user-friendly (as confirmed by our industrial contacts and by several studies) They are also amenable to formalization, which enables automation Finding the right balance between usability and formality is one of the core issues

7. 7 Research issues and methodology (1) Project area 1 (PA1): Notations for requirement specification What kind of formal semantics should be associated with the informal or semi-formal requirements notations, such as UCM and UML, in order to facilitate the automation of the derivation and verification of corresponding design models? Petri Nets, (abstract) state machine models, event structures, and process algebras such as LOTOS are possibilities that will be pursued. How can several (partial) requirements, each typically given as a scenario in the form of a UCM or an Activity Diagram, be combined to form a complete definition of the requirements? Can one define a unified notation for requirement scenarios combining the benefits of UCM and Activity Diagrams? How can we relate these notations to (structured) natural language requirements? How do these notations relate to other notations, such as UML Sequence, Collaboration or Statechart Diagrams, Message Sequence Charts or cause-effect graphs? Are the scenario-oriented notations suitable for describing the behavior of legacy components? How should existing and new standards for requirements, such as UCM, URN and UML, evolve? How can requirements models and notations be applied effectively and efficiently to generate a minimum set of representative scenarios?

8. 8 Research issues and methodology (2) Project area 2 (PA2): Derivation of design models from given system requirements, including reuse of components What methods can be used to generate (parts of) designs and implementations from very high-level specifications, possibly incomplete and semi-formal? A generation process such as the one envisaged here must be based on the use of available libraries of reusable components; how can their functional and non-functional behavior be taken into account during design development (e.g. [20])? How can we guide their composition? The concept of pattern is also useful here. A pattern is capable of describing in general terms design solutions to recurring problems. Subjects for study here include collecting, documenting, validating, applying and specializing patterns for reuse [A-B13][L-C02a,C01a]. How can we generate a design that is an instantiation of an architectural framework? How can the existing methods for protocol synthesis [29] be used in this context? - How can efficiency constraints be taken into consideration in the derivation process (our past research included already some results in this direction [37])? How can an appropriate architecture be determined for a system? We will consider the automatic selection of a number of candidate architectures based on functional and non-functional requirements, the required interfaces to legacy components, the distribution of the users, and the possible distribution of the required resources within the system. We will also investigate how such different architectural alternatives may be evaluated in order to arrive at a final selection [8]. Can the sub-module construction approach of [3] be used for determining the behavior of the remaining component if the overall system requirements and the dynamic behavior of a reusable component are given in terms of scenarios? Further theoretical work is needed, since an algorithm for this approach has only been given for the case that the behaviors are defined as state diagrams.

9. 9 Research issues and methodology (3) Project area 3 (PA3): Verification of a given design model against the requirements Dealing with incomplete designs and requirements: The verification should return potential design defects under various hypotheses. Some of these diagnostics may not identify real errors, but they all will identify situations where errors may be present, thus signaling to the designer that extra attention must be exerted in particular cases, similar to what we did in [9]. Can scenario requirements be used to systematically derive functional test cases? - We will consider an intermediate trace format suitable for conversion to various scenario and test representations, including standard testing languages such as the new TTCN-3. Can the semantics of scenario requirements be expressed in terms of formal logic in order to use a theorem proving approach to requirements validation and design verification? – By specializing these techniques to particular domains, it becomes possible to provide at least partial automation in the construction of proofs, rendering these techniques much more useable. We will examine how much of our methodology developed for the area of protocol verification [F-4] can be carried over to this domain, and then develop new techniques for the new domain. How can Proof-Carrying Code (PCC) [24][F-1] be used to assure that an independently developed software component satisfies the safety policies which rule out harmful behavior such as accessing private data, overwriting important data, accessing unauthorized resources, or consuming too many resources ? – Such carried proofs can be easily checked by the hosting server before a new component becomes operational. The challenge here will be to develop techniques for automating the generation of proofs in this new domain. How can our previous work on model checking for requirements consistency, completion, composition, and feature interactions [F-3,18] be extended to the context of scenario requirements ? - This may include building a tool which translates scenarios into linear temporal logic (LTL) and automatically detects feature interactions.

10. 10 Research issues and methodology (4) Project area 4 (PA4): Experimentation and case studies The purpose of case studies is to evaluate the feasibility of new design verification and derivation approaches and to evaluate the power and user-friendliness of new tools and notations that either are developed within our project or are made available from other research groups or industrial partners participating in our project. In many instances, these case studies will involve medium-size realistic examples of distributed applications. We will favor applications in the area of service development for Internet telephony, e- commerce applications, and new standards such as those of the IETF. Recognizing that their standards could be improved, the IETF is currently considering the creation of a working group on formal methods where our results could be shared. Some of the case studies will be performed in close collaboration with our industrial partners. In many cases, the realistic example applications may be proposed by industry. In some cases, the student working on the case study may work most of the time in an industrial office in order to facilitate the interaction with our industrial partners. The results of these trial applications of the new methods and tools should provide feedback to the research activities in the other project areas and thus contribute to ensure that our research is oriented towards finding methods and automation tools that could be applied in the practical context of industrial system development.

11. 11 Deliverables (Year 1) Comparative study and evaluation of UCM, UML Act. Diagrams (structured) natural language, MSC, Use Case Trees, and Extended Cause-Effect Graphing (PA1) [A*, B, P, S, S1, S2] Initial results about reconciling and combining the main aspects of requirements notations, and about their role in a unified software development process (PA1) [P*, all profs, S1, S2] Preliminary model of the formal semantics for some of the requirements and design notations for the purpose of formal verification (PA1-PA3) [A, B, F*, L, S, S3, S4] Preliminary new results on derivation of designs and executable prototypes from formal requirements and scenarios (PA2) [A, B*, L, P, S, S5] Adaptation of existing derivation methods for the synthesis of designs in the context of e-commerce and IP-telephony applications (PA2-PA4) [A, B, L*, P, RA, S6, S7] Selection of case studies in IP telephony with complex services, e-commerce applications, IETF standard (PA4) [S*, all profs, RA, S1, S7, SS1, with industrial collaborators] Continuous contributions to standardization bodies towards a formal model for Use Case Maps (in ITU) and UML Activity Diagrams (in OMG) (PA1) [A*, S2, all profs ]

12. 12 Deliverables (Year 2) Final results on reconciling and combining the main aspects of requirements notations, and about their role in a unified software development process (PA1) [A*, all profs, S2, S8, S10] Further results on the synthesis of design and executable prototypes from scenarios and formal requirements (PA2) [A, B*, L, P, S, S5, S6] Generation and validation of test cases from UCM/UML scenarios definitions (based on UCM path traversal mechanism), with tool support (PA3) [A*, L, S2, SS2] Verification of security and correctness properties of case studies using an existing theorem prover (PA3) [F, L*, B, S9] Initial design of a tool (theorem prover) for the verification of software designs against their requirements, possibly an adaptation or improvement of an existing prover (PA3) [F*, L, S3, SS3] Empirical results from case studies: IP telephony with complex services, e-commerce applications, and IETF standards (PA4) [S*, all profs, with S6, S8, S10 and RA, with industrial partners]

13. 13 Deliverables (Year 3) Final definition of proposed development process for distributed systems and related requirements notations (PA1) [P*, all profs, S2, S8] Tool supporting the semi-automatic synthesis of designs from requirements/scenarios (PA2) [A, B*, L, P, S, S5, S6, SS4] Verification tool for proving properties of requirements and designs (PA3) [F*, L, S3, S9, SS5] Experience with using new tools for the case studies considered earlier. Possibly new case studies. (PA4) [S*, all profs, with S5, S8, S10, and RA]

14. 14 Related Projects Scenario-Based Performance Engineering Woodside, Petriu, Amyot Integrating Scenarios with General Software Requirements Management Woodside, Amyot, Probert Others to come… (CITO)