Overview of the project: RequirementDriven Development of Distributed Applications

1
Overview of the projectRequirement-Driven
Development of Distributed Applications

• School of Information Technology and Engineering
  (SITE)
• University of Ottawa
• November 2002 through October 2005

2
Investigators

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

3
Industrial partners

• klocwork
• Nortel Networks
• Telelogic
• Borland (TogetherSoft)
• Motorola
• Industry Canada
• Mitel Networks

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
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
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
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
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-B13L-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
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) 24F-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
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
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
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
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
Related Projects

• Scenario-Based Performance Engineering
• Woodside, Petriu, Amyot
• Integrating Scenarios with General Software
  Requirements Management
• Woodside, Amyot, Probert
• Others to come (CITO)