UML class diagrams (or equivalent) are used to build a structural model of the system under design, including constraints captured using OCL. Being more focused on design, UML lacks support to make sure the model systematically captures the relevant domain concepts and properties in a traceable way, which is crucial for the subsequent design or testing steps. This paper shows how to apply goal-oriented requirements engineering techniques (GORE) to build UML class diagrams that are as complete as possible and consistent w.r.t. system goals and requirements captured using OCL. A mapping between both representations is de ned and implemented based on the KAOS meta-model and USE textual syntax. In addition, the GORE process also enables to consider di erent alternatives before selecting a speci c one and deriving specialised strengthenings of pre and post-conditions operations to enforce the system properties. The proposed approach is illustrated on excerpts of a railway system.
Model-Driven Engineering (MDE) has become popular for developing
softwarebased systems and is widely adopted to various extents in the industry [
UML and SysML are not perfect, of course. Their latest evolutions have
improved by providing better de ned notations and related semantics using the
UML superstructure. More formal semantics have also been de ned for a
number of diagrams. In addition, the Object Constraint Language (OCL) improved
expressiveness to state richer properties that cannot be captured using the
graphical syntax [
Nevertheless, a weak point of UML is its limited support for requirements engineering: { about notations, UML has the concept of requirement. The Use Case diagram enables a partial capture of main functionalities with limited structuring and only coarse grained interactions between the system and its environment. The class Diagram enables to capture the domain model and a number of related properties, possibly with OCL. The dynamic behaviour of a system can be speci ed using more speci c diagrams such the sequence, activity or state machine diagrams, but those are already directed towards solution design. SysML improves slightly over UML by providing a Requirements diagram with limited structuring capabilities. { about the modelling process, a number of methods have been de ned and can be driven by use cases, business processes or a domain analysis. However, such methods usually fail to precisely record the rationale that triggered the identi cation of a concept which should be related to the expression of some properties, either descriptive (i.e. domain properties) or prescriptive (i.e. requirements).
In the scope of this paper, we will show how to achieve systematic identi
cation and speci cation of requirements using standard UML class diagrams. Such
diagrams can be used to build a domain model (i.e. at problem level) and/or
a conceptual design of the information system (i.e. at solution level). In both
cases, a key point is to model the relevant concepts without unnecessary noise.
Our focus is on building high quality UML class diagrams (or equivalent)
integrating a rich set of descriptive and prescriptive properties in a consistent way
with pre and post-conditions. For this purpose, we will rely on goal-oriented
requirements engineering (GORE) de ned in languages like KAOS [
The structure of our paper follows a model construction process. We assume the reader is familiar with UML/OCL. Section 2 rst introduces the GORE modelling notations and presents the requirements of a small underground transportation system used as running example. Section 3 explains our mapping and implementation through USE. Section 4 and 5 respectively detail how to deal with operations and alternatives. Section 6 discusses the bene ts and limitation of our approach in the light of related work. Finally Section 7 concludes and present our future work. The whole paper will rely on di erent excerpts of a railway system in order to illustrate the proposed approach.
Goals capture, at di erent levels of abstraction, the various objectives the
system under consideration should achieve. GORE is concerned with the use of
goals for eliciting, elaborating, structuring, specifying, analysing, negotiating,
documenting, and modifying requirements [
The di erent abstraction levels to express goals can range from high-level strategic goals like \Maintain[Underground Safety] " down to more operational goals such as \Avoid[travellers falling on tracks] " or \Avoid[train collisions] " as depicted in Figure 2. High-level goals can be progressively re ned into more concrete and operational ones through relationships linking a parent goal to several sub-goals, with di erent ful lment conditions using either \AND-re nement" (all sub-goals need to be satis ed) or \OR-re nement" (a single sub-goal is enough, i.e. possible alternatives). For example, to avoid train collision di erent design can be used like xed block systems or moving block systems. Later in the paper, we will also see how to address the problem of a train that is longer than the platform (modelled as an obstacle in Figure 2).
The \WHY" and \HOW" questions can be used to conveniently navigate to parent and sub-goals, respectively. The goal decomposition stops when reaching a goal controllable by an agent, i.e. answering the \WHO" questions about responsibility assignment. These goals are either requirements on software or hardware components to design, or expectations on the behaviour of agents in the environment (e.g. the train driver). Domain properties can also be involved in a re nement. Such properties are intrinsically valid, like \A train can only be at one location at a time" or be assumed like the fact that the train length is shorter than the length of all platforms. In this case they need to be challenged about their validity.
Based on properties expressed in the goal model, one can start identifying concepts and structuring them into the relevant concepts of the object model (i.e. UML class diagram). Analysing the requirement Maintain[Door Closed While Moving] will result in the identi cation of a Train entity. Moreover the Train entity will be bound to a Door entity through a composition relationship with obviously at least one door. The modelling approach is minimalist: only what is strictly needed is modelled. For instance, at this point there are no other concept identi ed and only two attributes are necessary the Door state (e.g. a Boolean to represent a Door is closed) and the Train movement state (e.g. a Real representing its speed). The resulting object model is depicted in Figure 2. Note that a trace link between the Train entity and requirements involving it is added using the \Concerns" link. This also allows to formalise that requirement in the context of that Entity using the following OCL statement (also depicted has pop-up property in Figure 2):
InformalDef: The train doors must be kept closed while it is moving FormalDef: (self.speed <> 0) implies self.doors->forAll (closed)
An agent is a software, device, or human component of the system that plays some speci c role in goal satisfaction. It controls behaviours by performing operations and run concurrently with each other. An agent is modelled by responsibility links to goals. As stated earlier requirements di er from expectation based on the fact the responsibility is on the system or the environment. In our case, the Train Controller System (TCS) will be responsible of the \Maintain[Doors Closed While Moving]] " requirement based on its capability to operate the OpenDoors operation. Operations control state transitions and can be speci ed using trigger/pre/post conditions either unconstrained or required to enforce a speci c requirements. This will be further detailed in Section 4. 3
UML Speci cation Design Environment (USE) was mainly designed to validate
and verify speci cations consisting of class diagrams together with OCL
invariants and pre- and postconditions [
Table 1 de nes how to map a GORE object model into a UML class
diagram. This mapping covers the various constructs like entities, associations,
inheritance, di erent kind of goal concepts (Requirement, DomProp,...) and
operations. It was implemented using a Java plug-in for the Objectiver tool that
supports the KAOS method [
Applying the above mapping to the KAOS object model of Figure 2 yields the following UML model. At this point, traceability is ensured by the same naming convention, although more speci c identi er could also be added later to guarantee a better and round-trip model synchronisation.
Model UndergroundTransportationSystem class Train attributes
speed : Integer end class Door attributes
closed : Boolean end composition Rel_1 between
Train[
Door[1..*] role doors end class TCS operations openDoors (tr: Train) -- <operation will be defined in section 4> end constraints context Train -- train doors must be kept closed while the train is moving. inv DoorsClosedWhileMoving:
(self.speed <> 0) implies self.doors->forAll(closed) 4
A KAOS operation is a state transition inside the system that can be controlled by some agent. The unconstrained operation is speci ed using domain preconditions (i.e. necessary condition) and post-conditions (resulting state). Note that we will not consider trigger conditions (i.e. su cient conditions) because it is not supported by UML. For the OpenDoors operation, the domain pre and postconditions are: tr.doors->forAll(closed) and tr.doors->forAll(not closed)
We need to be sure that the operation ful ls all the invariant properties dened (through the requirements). Hence, each time we introduce an operation with its domain pre- and postconditions into a formal system, we need to be sure that the operation execution will preserve the system invariant in any circumstances. This can induce to specify complementary conditions that must be ful lled before the operation execution (additional preconditions) and/or specify complementary conditions that must be ful lled by the result of the operation to be compliant with the requirements. In those cases, the conditions are named required pre- and postconditions.
Such required conditions can actually be computed using speci c reasoning
techniques called goal regression detailed in [
post: tr.doors->forAll(not closed) (2) As there is at least one door in the train, we can assert:
tr.doors->forall(not closed) implies tr.doors->exist(not closed) (3) Hence, when TCS performs an OpenDoors operation for a train tr, we get a state in which the following assertion is veri ed:
tr.doors->forAll (not closed) (4) Due to (3), this implies that:
tr.doors->exist (not closed) (5) And in order to preserve Requirement 1, we need to have: pre DoorsClosedWhileMoving: tr.speed = 0 (6)
The resulting UML operation corresponding to the KAOS operation (as dened in the mapping of Table 1) is described below. It is bound to the T CS UML class which is mapped on the T CS agent in KAOS. Note that the rationale for this additional precondition is explicitly traced in the OCL speci cation. Model 2 Strengthened OpenDoors Operation openDoors (tr: Train) pre: tr.doors->forAll (closed) -- DoorsClosedWhileMoving: The train must be stopped. pre DoorsClosedWhileMoving: tr.speed = 0 post: tr.doors->forAll (not closed) 5
Now let us focus on a more speci c safety goal that our system should enforce in the case the train is stopped at a station.
InformalDef: Passenger should never be allowed to step out of the train on the tracks when the train is stopped at the station.
Obstacles analysis can be applied to enforce this goal with a maximal level of safety, Figure 2 shows how when starting from the negation of the goal, di erent problems can be identi ed, such as the train being longer than the platform length or being stopped at the wrong place. In the rest of this section, we will reason about the platform length problem assuming the driving is stopping at the right place. We will explore two possible alternative designs that can address the problem. A few extra concepts are required and will enrich our KAOS object model and the corresponding USE/UML class diagram, like the association at between a train and a station as well as the platformLength of a station. Those are depicted in Figure 3 and 4. 5.1
Let us assume the length is standard on all stations. A domain invariant could be the following one (both in natural language and in OCL):
InformalDef: Platforms are always 100m long FormalDef: Context Station inv: self.platformLength = 100
We could also assume the train length is compliant with this.
InformalDef: Train length is always less than platform length FormalDef: Context Train inv: self.at<>NULL implies (self.length <= self.at.platformLength) Such an assumption could become a requirement on another agent, i.e. the agent that is responsible for assembling the trains. For example, the enforced rule might be the following one:
InformalDef: All trains are between 55m and 75m long FormalDef: Context Train inv: self.length >= 55 and self.length <= 75
The resulting model is depicted in Figure 3 without considering the \No doors opening outside of platform" at this point. We can see the object model was enriched with a few attributes like Station.platformLength and Train.length. The resulting (right) re nement is easy to manually prove correct as the maximum length is less than 100. The translation into the USE tool can also check the invariant but on a speci c instantiation, thus acting more as a runtime monitor.
The previous example is based on the hypothesis that all trains are between 55m and 75 m long. What happens if we rule out this hypothesis, by not requiring any maximal train length? As trains can now be more than 100m long, we need to nd another way to guarantee the No passenger going out on track at station requirement. With such a train stopped in a station, according to the fact that, so far, all train doors are either all opened or closed, passengers being in the part of the train out of platform could go down on the tracks. We need therefore to forbid opening doors in the out of platform part of the train. In the Figure 4, an alternative re nement and a new requirement have been introduced to this aim.
This second design is more complex but can actually be stated in a single requirement:
InformalDef: When a part of a train stopped at a platform is not within the platform length, then those doors should not open
FormalDef: Context Train inv: self.doors->forAll (d:Door |
d.position > self.at.platformLength implies d.closed)
Using similar regression techniques than in section 3, one can show that in this case the strengthened operation is the following one:
OpenDoors (tr: Train, selectedDoors: Set(Door)) pre AllClosed: tr.doors->forAll(closed) pre Consistency: tr.doors->includesAll(selectedDoors) pre ZeroSpeed: selectedDoors->notEmpty implies tr.speed = 0 pre OutOfPlatform: tr.doors->forAll(d:Door | not selectedDoors->includes(d)
implies d.position > tr.at.platformLength) post: tr.doors->forAll(d:Door | d.closed
implies not selectedDoors->includes(d))
Looking at the resulting model, one can see both designs are overlapping: the Door.position attribute of the second design is not required in the rst design. This is not altering the behaviour but just introducing some noise. The problem is di erent if we consider the OpenDoors operation has other sets of additional preconditions involved. Generating a consistent UML diagram requires to make a decision about one of the alternatives. This process can be error prone but can be automated by computing the recursive closure of all related concepts of a design, except those that are shared. Such an alternative selection mechanism is supported by the developed plugin. Visually, the discarded concepts are greyed out. Actually in Figure 4, the rst design presented in Figure 3 is greyed out except for shared concepts like the PlatformLength assumption and the Station entity. 6
Previous work has already considered how to bridge the gap between
requirements and UML. As stated in the introduction, use cases are quite popular and
usually combine the Use Case diagram with more speci c templates with
approaches like Cockburn's explicitly capturing relevant goals [
Another approach is to try to develop a GORE approach directly inside UML
through the stereotype-based extension mechanisms provided by UML. Such an
approach was proposed by Heaven and Finkelstein [
Problem Frames, another famous requirements based approach, has also
considered an UML mapping [
Interestingly, the problem frame mapping does not consider OCL for
formalising properties but OTL Object Temporal Logic. This removes our limitation
of only addressing invariants (i.e. safety requirements in our running example).
However this extension is not standard; actually, other temporal extensions for
OCL have been proposed, e.g. TOCL [
For fully dealing with formalised requirements, it is still possible to carry
out the reasoning at the GORE level. A number of frameworks have developed
speci c tool support for temporal logic for example Formal Tropos [
Building high quality UML class diagrams is a di cult task because modelling needs to be carried out with a speci c purpose in mind. Without analysing the requirements while building the model, it is easy to miss important concepts or introduce irrelevant ones. In this paper, we have shown how to conduct such a process guided by a speci c goal-oriented requirements engineering method and relying on the USE framework for easing the mapping. However, we believe the methods and guidelines detailed here can be applied more widely with the limitation they only consider safety properties. A key point is that the explicit capture of properties helps to expose their degree of robustness and to decide how to improve the design. Using obstacle analysis, a systematic questioning can be applied, e.g. what is the doors would not close (due to mechanical failure), how should the system react in this case, what information is required, etc. This will result in an update of the UML model in terms of its structure and operations.
Our mapping has been implemented as a plugin for the Objectiver tool. However, it is currently limited to the export from a requirements to UML while it would be interesting to retro-engineer existing UML models or more tightly integrate both approaches for a full roundtrip engineering. This would also enable the use of veri cation and validation tools available at both levels. Dealing the larger set of progress properties would also be interesting but would require nonstandard temporal extensions to OCL and add more complexity, reducing the interest of the approach. This work was also limited to functional requirements and dealing with non-functional requirements (NFR) can also be investigated, for example in the way they drive the identi cation of alternatives. Although less easy to manage in a model, OCL can be helpful to query model characteristics than can drive the evaluation of some categories of NFR. Last but not least, we plan to conduct a comparative validation experiment to assess the quality of the resulting model with and without the use of the proposed technique and plugin. This will take place in the scope of the training and coaching the authors are organising both at academic and industrial levels in Belgium and France.