Some Problems of Current Modelling Languages that Obstruct to Obtain Models as Instruments

Some Problems of CurrentMo delling Languages that Obstruct to Obtain Mo dels as Instruments JoseMiguelCa~nete Valdeon ? ,Francisco Jose Galan Morillo, and Miguel Toro E.T.S. de Ingeniera Informatica. Universidad de Sevilla. Avda. Reina Mercedes, S/N. 41012. Sevilla. Spain. Abstract. In this paper we reect on the usefulness of current mo delling languages. We defend that ob jects elaborated with such languages are instruments that pursue one or several typied purp oses, which include: (1) to representknowledge about some sub ject, whether real or imaginary; (2) to help in understanding and in answering questions ab out the prop erties of some sub ject; and (3) to stimulate the engineer's creativity in solving some problem. We reason that achieving this instrumental role in mo delling languages is a necessary condition for a Mo del-Driven Software Engineering. However, studying several languages of common use in practice, we claim that there are at least four problem categories that obstruct that useful mo dels as instruments can b e elab orated with current mo delling languages. Keywords: mo dels, mo dels as instruments, design of modelling languages, Mo del-Driven Engineering (MDE), Mo del-Driven Development (MDD). 1Intro duction Mo dels have b een used for years in Software Engineering by the main metho dologies and languages. From being secondary pro ducts of life cycles, they are currently b eginning to b e thoughtofascentral elements in leading the software development process. This idea is b eing explored by initiatives such as the Mo del Driven Architecture [13]. It has motivated the recognition of the need of a true Mo del-Driven Engineering, which admits the imp ortance of models not only in the architecture (as product) but also in the process [7]. We b elieve that a Mo del-Driven Software Engineering is only feasible if mo dels are understo o d as engineering instruments .From this persp ective, mo dels are much more than simple descriptions of sub jects: they are entities that can be used to assist the software engineer. We began to explore this idea in a previous p osition pap er [1], where we studied the instrumental role played in current Software Engineering by the conceptual ob jects that are elab orated with the so-called mo delling languages, as well as by models in the scientic sense (e.g. those to estimate cost and eort in the development process). ? For comments ab out this paper, please write to the address: [email protected] In this pap er we reect on some problems that obstruct current mo delling languages of pro ducing mo dels that can b e regarded as useful engineering instruments. From the results of our previous study,we p oint three broad categories of purp oses that ob jects created with such languages may pursue as aspiring engineering instruments. This sets a context in whichweidentify four types of problems that move these models away from their intended purp oses. Our objective is that these problems can be avoided in the design of future mo delling languages. Wehave detected the following categories of problems: 1. Existence of an inadequate ontology. 2. Inabilityofintro ducing and controlling uncertainty. 3. Lack of a precise constructive guide. 4. Lack of a forecast of reasoning roads. After having analysed these deciencies, we claim that there is an even more imp ortant problem: there is a shortage, in currentSoftware Engineering, of modelling languages capable of pro ducing mo dels as instruments of real usefulness. We illustrate our results with well-known examples taken from the mo delling bibliography, mainly from the Requirements Engineering eld: UML use-cases in the Unied Process [6], analysis mo dels in OMT [11], essential mo dels in Syntropy [2], and problem diagrams in Jackson's Problem Frames approach[5]. Wehave complemented the exp osition of some of the problems with additional notations as Co ckburn's approach to use cases [3] and UML state diagrams [12]. The rest of the pap er is organized as follows. Section 2 intro duces three broad categories of purp oses for mo delling languages, and it exp oses the intended purp oses of the case studies. Sections 3 to 6 elab orate on the four problems listed ab ove, illustrating each one with the appropriate case studies. Attheendofeach section we exp ose our partial conclusions. Section 7 presents overall conclusions extracted from our study, relating the obtained results with our reections ab out the role of models in a Mo del-Driven Software Engineering. We close in Section 8presenting related works. 2 Categories of purp oses and case studies 2.1 Mo dels as engineering instruments Mo dels have a consolidated role in mo dern Science. From the elds of Physics, Chemistry and Economics, Mary Morgan and Margaret Morrison [10] reasoned that scientic mo dels behave as instruments of investigation with three kinds of functionalities: (1) to assist in the construction of new theories and in the exploration of existing ones; (2) to structure and to show measurements ab out the world, as well as to serve as measurement and prediction to ols; and (3) to help in the design of new technologies and mechanisms to intervene in the world. We followed the spirit of the former authors in our previous paper [1], where we analysed the instrumental abilities of mo dels in current Software Engineering. We studied not only \mo dels" as ob jects created with mo delling languages, but also \models" in the scientic sense. In this pap er we fo cus on those ob jects in the rst sense. We can nd three, non-disjoint categories of purp oses that such ob jects may aspire to. The rst and most frequent purpose is to serveasa repositoryofknowledge ab out some sub ject, whether real or imaginary. The description language usually presents a graphical-textual form. As any narration, descriptive mo dels can come inavariety of levels of approximation towards the describ ed sub ject (precision) and of formality. The most commonly describ ed sub ject is the system under development itself; a extremely precise and formal descriptive mo del ab out the system is its program co de 1 ,asitcontains all the details needed to be executed by a computer, and it is written in a formal language. Another category of purp oses is the analytical one. This includes to help in understanding some sub ject, and to assist in answering questions ab out it (whether immediate or complex). To use the mo del is to reason with it, so the mo delling language must b e asso ciated with a suitable reasoning framework to be employed by the user (the software engineer). There must also exist an underlying theory ab out the sub ject under analysis; such a theory constitutes a basis on which the dierent reasonings can b e made. The third category of purp oses is the creative one. Such models are capable of stimulating the user to discover ideas or even to suggest her/him ideas ab out how a certain problem can b e solved. As in the preceding case, there must exist b oth a suitable reasoning framework and an underlying theory ab out the problem. 2.2 Case studies Belowwe present our selected case studies and we catalogue each language with resp ect to its intended purp ose/s. In the next sections we will reason if the intended purp oses are achieved in fact. UML use cases and the Unied Pro cess. The Unied Mo deling Language [12] is a collection of notations, in principle with no asso ciated guides of construction. The intended purp ose seems to b e descriptive; pg. 1-1 of [12] states: \The Unied Mo deling Language (UML) is a language for sp ecifying, visualizing, constructing, and do cumenting the artifacts of software systems, as well as for business mo delling and other non-software systems". However, the UML is b een used by many metho dologists as a basis to develop languages with analytical and creative purp oses; in some cases they keep the UML as is, and in others they explicitly mo dify it. An example is the proposal by Jacobson, Bo o chand Rumbaugh: the Unied Software Development Pro cess (UP) [6]. Their metho d contributes constructive guides aimed to elab orate UML mo dels that can be used not only as mere descriptions, but also as instruments for reasoning ab out the development of a software system, as well as for stimulating the mo deller with ideas about the comp osition of the system. To makethings concrete, let 1 It has b een with the recent adventof MDA that co de has also b een considered a mo del [13, 7, 9] us take the UML use-case notation. Wewillcentre on a claimed b enet of such mo dels: the capabilitytodrivethe development pro cess (chapter 3 of [6]). During the \Analysis workow", activity\ analyze a use case " (pp. 203{207) intends to identify analysis classes from use-cases, with the assistance of previously elaborated \domain mo dels". Therefore this activity is considering use-case mo dels as instruments with a creative purp ose: they are intended to help the engineer to solvethe problem of obtaining a set of analysis classes that are part of the essential architecture. OMT analysis mo dels. The Ob ject Mo deling Technique [11], aims in its rst phase, analysis, to elab orate three kinds of models 2 : ob ject, dynamic, and functional. With them, the authors pursue two purp oses: (a) (descriptive) to devise a precise, concise, understandable, and correct mo del of the real world (pg. 148); and (b) (creative) to serveastheskeleton of the design (pg. 227). For this second purpose, the authors provide a set of guidelines for using the three former mo dels, consisting in identifying design classes from those in the analysis mo dels (this is called \ob ject design", chapter 10 of [11]). From this p ersp ective, the three kinds of models elab orated during analysis play the role of helping the engineer in developing the software system: they have a creative purp ose. Syntropyessential mo dels. The Syntropy method [2] aims to elab orate three kinds of mo dels: essential, sp ecication, and implementation. Similarly to OMT mo dels in the analysis phase, essential models pursue two purposes: (a) (descriptive) to understand a situation, real or imaginary (pg. 12); and (b) (creative) to help in devising a system sp ecication, i.e., a sp ecication mo del (pp. 269{272). Jackson's problem diagrams. Problem diagrams were introduced by Michael Jackson as part of a wider framework [5] aimed to help the engineer to solvethe problem of designing a correct decomp osition for those real-world problems in which a software system (\machine") is required. These mo dels are intended to achieve purp oses in the three previously stated categories; some concrete purp oses in each category are: { Representative: the parts of the world where the problem is lo cated, the problem requirements, the machine sp ecication. { Analytical: to understand a real-world situation, to verify that aproposed machine sp ecication actually satises the requirements of a given subproblem. { Creative: to discover the main involved subproblems, to insert auxiliary subproblems whose intro duction may be useful to alleviate other subproblems. 2 The name of these OMT mo dels is \analysis mo dels". Do not confuse with mo dels that pursue the analytical purp ose, formerly intro duced. 3 Problem: existence of an inadequate ontology 3.1 Ontologies One of the ingredients that constitute a mo delling language is an ontology, i.e., a universe of concepts and relationships between them. A p ortion of the ontology is intended to b e used by the mo deller, so it has an asso ciated notation, whether graphical or textual. The problem is that some modelling languages include an ontology that is not adequate for the pursued purp oses. 3.2 Examples We nd a classical example of this in the case of ob ject-oriented languages that intend to describe the real world, where the software problem is lo cated, through ob ject-oriented ontologies. The inadequacy of suchontologies for the purp ose of describing the world has been noted by authors such as Cook and Daniels [2], and Jackson [5]. If we consider use-case mo dels with the purp ose of describing the problem domain of a system-to-b e, wehave another example of an inadequate ontology. It only contains one element to represent all the imp ortant asp ects in the world: the \actor" concept. This clearly results insuÆcient when we try to structure and describ e the part of world concerned with the system requirements. To this aim, use-case models need to b e accompanied in UP with domain mo dels. Domain mo dels in turn contain an excessively simple ontology (based on classes, asso ciations and generalizations), so it needs to b e sp ecialized for each application domain (e.g. the \business prole", [12]). In contrast, authors like Wieringa [14] prop ose a more adequate ontology for the same purp ose: physical domains, so cial domains, conceptual domains, and lexical domains. The ontology in Jackson's problem diagrams includes, among others, the ro ot concepts of \domain", \shared phenomenon", \interface" and \requirement". The rst two are subsequently rened in other concepts. This ontology allows the mo deller to acquire the relevantknowledge ab out a concrete real-world problem. Such knowledge, b esides covering the representational purp oses stated in the previous section, constitutes, on one hand, the input for a mental patternmatching pro cess, lo oking for what Jackson calls \problem frames": patterns of commonly found problems. To this end, the author has dened the frames with the same ontology of problem diagrams. Once identied, a problem frame provides the engineer with additional knowledge ab out concerns and diÆculties of that problem, and even suggests design ideas (e.g. to insert auxiliary subproblems whose intro duction may b e useful to alleviate other subproblems). On the other hand, problem diagrams are the basis for applying a number of reasoning schemes and strategies that, in turn, allow the application of the theoretical knowledge of eachproblem frame, thus achieving the analytical and creative purp oses stated b efore. Section 6.2 elab orates on such reasoning schemes and strategies. 3.3 Conclusions There are some mo delling languages whose ontologies are not adequate to their purp oses b ecause they are not able to acquire the suitable knowledge to describe what is required or b ecause they do not allow the construction of the reasonings that are needed to apply the underlying theory. 4 Problem: inability of intro ducing and controlling uncertainty 4.1 The need to intro duce and control uncertainty in Software Engineering mo dels Uncertainty is a natural companion of every engineer when devising an entity.As the development process goes on, uncertainty ab out the entity is ideally reduced. Therefore, it seems logic that a software engineer can have at her/his disp osal a collection of modelling languages that support a variety of uncertainty levels, so that s/he can cho ose the most comfortable one depending on the stage of the pro ject. Uncertaintymay presenttwo forms: (a) to state something ab out what we are not sure, and (b) to omit certain details we do not knowor we are in doubt. But allowing the intro duction of uncertainty in a mo del is not enough: a language should also provide some mechanism to control it. Control means: (1) to sp ecify exactly which mo del elements introduce uncertainty and howmuchit consists of; and (2) to have mechanisms for the mo deller to raise or to reduce the uncertainty at will. 4.2 Examples Co ckburn's approach to use cases. A place where uncertainty is particularly needed is the one constituted by the early phases of a pro ject, when the requirements are b eginning to b e discovered. In Alistair Co ckburn's b o ok ab out use cases [3], we observeseveral examples in which the author needs to express that some steps of the use cases were not known by the analyst at the moment of writing (e.g. step 4a1 in \ buy sto cks over the web " {pg. 4{ and step 3a1 in \ get paid for acar accident " {pg. 5). As Co ckburn's use cases are describ ed in natural language, the author resorts to interrogative sentences in the form \ what do we do here? ". Therefore, the language do es not oer any means to control uncertainty. Unied Mo deling Language. The UML is intended to serveasalanguage not only applicable to the phase of advanced design, but to all the development pro cess. However, we have not found almost anyelementin UML's ontology that allows the controlled introduction of uncertainty. The reason is that UML is a language primarily conceived to elab orate precise mo dels. The fact is that mo dellers often use UML with uncertainty semantics, b ecause that is what they need. However, the language metamo del do es not allow this. As an example, consider the mo del in gure 1(a). Its purp ose is to describ e the b ehaviour of a software system consisting of a controller of a lamp. Consider the LampOn state. What wewant to express with UML is the following: LampOn = state : a \click" order has been sent to the lamp, requesting for turning on, and the user has not issued any more \click" events. This description does not make explicit the detail ab out the comp osition of the LampOn state, perhaps because it was a design decision that the software engineer had not still taken at the moment of elab orating the model, or p erhaps b ecause s/he just did not want to indicate that information. However, when the mo del in gure 1(a) is interpreted in UML's metamo del, a metaclass must be chosen for LampOn : SimpleState or Comp ositeState . There is not a metaclass that allows the mo deller to express such uncertainty about the controller. If no more mo dels are provided, LampOn is interpreted as SimpleState . There is no chance of expressing uncertainty. Fig. 1: Mo delling the controller of a lamp. According to the UML metamo del, LampOn is a SimpleState in (a), and a Comp ositeState in (b). However, the mo d- eller wanted to leave such detail unspecied in (a). Figure 1(b) shows two mo dels. State LampOn in Mo del 2 renes state Lamp- On in Mo del 1 through a rene dep endency. Although LampOn in Mo del 1 has exactly the same iconic form than in gure 1(a), it is interpreted as b elonging to the Comp ositeState metaclass, due to the dep endency. The  rene  dep endency is a promising resource to work with dierent levels of uncertainty.Page 2-18 in [12] states that \(a rene dep endency) sp eci- es renement relationship b etween mo del elements at dierent semantic levels, such as analysis and design". This resource presents two problems. The rst one is that a theory must be established for dening which pairs of elements (or pairs of groups of elements) can b e legally related through this dep endency.The second one is that such related elements should allow \uncertainty" semantics. For example, supp ose that when we intro duced the op eration turnOn() in g. 1(a), the modeller did not sp ecify its parameters (b ecause they were unnecessary for the mo del purp oses or b ecause the mo deller had not still decided them). Assume the op eration is detailed in another mo del as turnOn (p: Integer) .UML interprets turnOn() as: \operation with zero parameters". However, if we connect both operations through a rene dependency, the intended semantics for turnOn() should be: \op eration that do es not specify the number and typeofits parameters, but they are detailed at the other side of the dep endency". The other promising resource to work with dierent levels of uncertaintyis the generalization ( Generalization metaclass). We can sp ecify some details ab out a class and later (or in another model) add more details through a sub class. In UML, the new details must b e additive wrt. the former ones, i.e., they cannot rene existing elements, with the exception of metho ds ([12], p. 2-70). UML do es not supp ort state machine generalization through the Generalization metaclass. Instead, the language just suggests an example of howthe  rene  dep endency could b e used to dene two kinds of state machine generalization: subtyping and strict inheritance (pp. 2-166 to 2-168), admitting that \these techniques are all based on practical experience" and \this topic is still the sub ject of research" (p. 2-166). We must warn that what is not a resource to vary the uncertainty level is the presentation option that allows to showmore or less details ab out mo del elements; e.g. suppress the type of an attribute in a class ([12], p. 3-43) or suppress the argument list and return typ e of an op eration (p. 3-46). These are just presentation issues, but the modeller is forced to decide the typ e of an attribute when dening it, as well as the parameters of an operation (as stated by the metamo del, p. 2-13). What we are lo oking for are resources that allowthe mo deller to b e intentionally imprecise ab out some topics b eing mo delled, while still constituting valid models. UML state diagrams contain some constructors with non-deterministic semantics. Such constructors constitute a \lightweight" mechanism to intro duce some uncertainty in a mo del. Some examples are [12]: (a) the indeterminacy ab out what transition is going to be red in a\choice" pseudostate when the guard conditions are true (p. 2-146); (b) the indeterminacy in the selection of the next event that is going to be pro cessed by a state machine when there are several candidates (p. 2-161); the uncertainty in the selection of one between several transitions that are ready to b e red (p. 2-161). 4.3 Conclusions The ability of describing with uncertainty is basic in an Engineering. Wehave found a shortage of this characteristic in commonly used mo delling languages. The intro duction of uncertaintyinamodelshould be accompanied bycontrol mechanisms provided by the language. 5 Problem: lack of a precise constructive guide This problem is presentin many languages that were designed with the intent of pro ducing analytical or creative purp oses. These languages provide aguide for using models as instruments, but in many cases it is just assumed that the mo dels are somehow elab orated, or at most some very general guides are given for that. Although the use guides may b e correct, these languages lackfrom a precise guide that explains how to construct these mo dels, taking into account the pursued purp oses. 5.1 Examples Recall the UML use-case mo dels in the Unied Process (section 2.2). As we reasoned b efore, they pursue a creative purpose: to help the engineer to solve the problem of obtaining a set of analysis classes that are part of the essential architecture. UP gives some pieces of advice to identify such classes, in the form of guidelines (pp. 204{205), providedthat the engineer has adequate use-case and domain models. Such guidelines constitute the prop osed use guide of the use-case model as an instrument with a creative purp ose. But to this purpose to b e successful, there should exist a constructive guide that precisely explains how to elab orate use-case models and domain mo dels; only then, they could b ehave as the creative instruments that the metho dologists had conceived, and the guidelines for identifying analysis classes would b e useful. The Unied Pro cess only provides with loose guides to elab orate use-case and domain mo dels. The authors explicitly admit that (pg. 204): \The use cases describ ed in requirements are not always detailed enough for identifying analysis classes [...] Thus to identify analysis classes you mayhave to rene the descriptions of the use cases with resp ect to the inside of the system". Regarding OMT analysis mo dels, there is not a realistic constructive guide for elab orating such mo dels. The prop osed guide dep ends on the existence of a preexisting \problem statement": a do cument where all the requirements are clear and the problem is correctly lo cated and b ounded in the real world. The constructive guide prop osed by the authors simply limits to identify model elements from such problem statement: ob ject classes, scenarios, state diagrams, etc (chapter 8 of [11]). Essential mo dels in Syntropy are constructed in a similar, lo ose way. Authors give a more precise constructive guide for essential mo dels than the one provided by OMT, but it also results insuÆcient to determine where the problem is lo cated and what are the imp ortantworld asp ects to capture into elements of sp ecication mo dels.