In this paper we are concerned with the degree to which modeling languages explicitly accommodate conceptual distinctions. Such distinctions refer to the precision and nuance with which a given modeling concept in a language can be interpreted (e.g., can an actor be a human, an abstraction, or a collection of things). We start by elaborating on the notion of conceptual distinctions, while also providing a list of common modeling concepts and related distinctions that are relevant to enterprise modeling. Based on this, we will then analyze a number of conceptual modeling languages to see whether they accommodate the explicit modeling of (potentially important) conceptual distinctions { that is, whether they have speci c language elements to model conceptually distinct entities with. We conclude by discussing what impact our ndings may have on the use (and creation) of modeling languages.
Most concepts common to conceptual modeling languages and methods (e.g., goal, process, resource, actor, etc.) can be interpreted in a number of conceptually distinct, yet equally valid, ways. For example, in the context of business processes, one may choose to interpret actors as being human beings who take decisions and execute actions. At the same time, however, interpreting them as being abstract agents or dedicated pieces of hardware might be equally valid in another context. One could also choose to interpret actors as being a collection of things that, together, execute some actions (e.g., an organizational department composed of many employees, a cluster of computers) instead of being a single thing executing an act. Depending on the context of the domain to be modeled, the stakeholders and other modelers we interact with, and the goal of the model itself, we often choose among the di erent possible interpretations. These di erent interpretations of the same concept can lead to a host of semantic considerations. For example, if an actor is a human being, one can never be as sure that s/he will behave as expected compared to, say, a computer.
It is important that such di erent interpretations can be modeled distinctly. It would not do well for the overall clarity and semantic quality of a model if we con ate semantically di erent interpretations (e.g., human beings, abstract entities and material objects) under the same banner (e.g., `actor') and pretend that they are one and the same thing. Yet, this is often the case with modeling languages. Frequently, the designers of a modeling language de ne a type (e.g., actor) and allow it to be instantiated with a wide diversity of entities (humans, hardware, abstract and mathematical entities) which have no common ontological basis. Sometimes modeling languages do accommodate (some) of these conceptual distinctions, but then do so only implicitly. That is, in their speci cation or meta-model they assume a particular interpretation. As such, all instantiations of a model are then implicitly assumed to abide by that interpretation (e.g., all actors in the given model are assumed to be human things, all goals are assumed to be hard goals). An example of a language doing so is the i* speci cation as found in the Aachen wiki [10], which de nes agents (the acting entities) as having \a concrete physical manifestation ". This implicitly makes it semantically incorrect to use abstractions (e.g., agents as they are commonly understood) and furthermore, perhaps ontologically incorrect to use composite agents { market segments { as the composition itself is not physically manifested.
It is more useful if a modeling language accommodates such conceptual
distinctions explicitly, to the extent needed in relation to its expected and planned
use. That is, instead of relying on the underlying semantics to de ne every
concept they allow (or perhaps require), to use a notation that explicitly encodes
information about our interpretation { and do so by providing distinct notational
elements for all the important di erent conceptual distinctions. This can mean
for instance, having exclusive (visual) elements to represent such distinct
concepts by (e.g., the amount of `stick puppets' in in ArchiMate actor type denoting
whether it is a single actor or a collection of them). This is important from a
cognitive point of view as it improves the quality of the notation by ensuring
there is no notational homonymy. These points (and more) were argued for by
e.g., Moody in his work on a general \physics of notation" [14]. Several modeling
languages have been analyzed to estimate their cognitive quality in terms of this
framework (e.g. i* [15], BPMN [7], UCM [
Thus, in this paper we will speci cally look at the cognitive quality of a number of modeling languages and methods in terms of the semiotic clarity of their semantic constructs. These constructs can be both visual (for visual notations) and textual (for textual notations), but both require a proper correspondence between semantic constructs and symbols used for them. To do so we will provide an initial (likely non-exhaustive) overview of di erent aspects of enterprises that are explicitly modeled today, and show to what degree relevant conceptual distinctions can be explicitly modeled in the languages and methods used for them. The goal of this work is not to provide detailed individual analyses of all the languages involved, but to explore whether there is a trend in modeling languages to support enough distinctions or not, and provide advice on basis of that for modeling language use and design in general. 2
Aspects of Enterprises and Associated Languages Enterprises are large socio-technical systems encompassing many aspects (e.g., business processes, value exchanges, capabilities, IT artifacts, motivations, goals), which themselves are often the domain of specialized (groups of) people. As these models are produced by di erent people, often using di erent languages, integration is a vital step in order to have a coherent picture of the enterprise [11]. Ensuring that di erent conceptual distinctions are modeled explicitly is thus especially important in this context, as much information can be lost in this integration step, leading to enterprise models that are no longer correct or complete in regards to the semantics intended to be expressed (and possibly only done so implicitly) in the models made of each of the distinct aspects. Traditionally processes and goals received a lot of attention in terms of explicit models and dedicated modeling languages and frameworks, while recently more and more aspects are being considered equally as important to deal with. Other aspects such as motivations and goals, value exchanges, deployment and decision making now have dedicated, often formally speci ed, modeling languages available. This increases the amount of languages (ideally) capable of explicitly supporting conceptual distinctions important to the individual aspects that are in use, but perhaps at the cost of fragmenting the modeling landscape itself. Table 1 gives a brief overview of some current languages and the aspects they are, or can be used for. 3
Conceptual Distinctions for Aspects & Languages
The di erent aspects that are focused on in enterprise modeling, typically have
a number of (not necessarily overlapping) speci c conceptual distinctions, which
are important to be aware of. For example, a motivational model describing the
things to be achieved by an enterprise and the reasons for wanting to achieve
Architecture ArchiMate [24] (1.0, 2.0), ISO/DIS 19440, ARIS
(Business) Processes BPMN [17], (colored) Petri nets, IDEF3, EPC [
Mate [24] 2.0's motivational extension, OMG BMM [16]
Management of IT artifacts ITML [
software) intentional Know whether an actor is con- Implicit in most languages, mensidered an explicit part of a sys- tioned as such in TBIM, depending tem, i.e., is expected to act or not on interpretation could be argued to on certain things, in contrast to be explicit in OMG BMM with difactors from outside the systems ferentiation between internal and exscope which may act but were ternal in uencer. not regarded or thought of to do so speci c
Knowing whether an actor is a Supported by some (e.g., Archispeci c thing (i.e., an instantia- Mate), through type/instantiation tion) or a general thing (i.e., a dichotomy, explicit in TBIM by role) the claim that an agent \represents a concrete organization or person" ArchiMate, implicit in e.g., e3Value and RBAC by automatic use of roles (types).
event intentional Distinguish between events that Arguably explicitly supported by should, or will happen given a BPMN through the use of `None' set of circumstances, and events type triggers for Start Events. that happen (seemingly) unprovoked. composed material necessary
goal Distinguish between complexity TBIM explicitly models composite level of goals, i.e., whether they goals as `business plan' types, implicit are an overarching strategy or di- in some other languages focused on rectly needed goals. strategy/tactics (e.g., OMG BMM). Distinguish between objects and their representations, i.e., is the goal to achieve an increment in the integer on a bank account, or to hold an n amount of currency.
Distinguish between goals that have to be attained and those that should.
Distinguish between goals for Most goal modeling lanwhich the victory conditions are guages/methods/frameworks (e.g., known and not, i.e., hard vs. soft i*, GRL, KAOS, AMORE) support goals. this explicitly.
Distinguish between (closed, singular) and (open, composed) boxes.
process black Arguable either way for BPMN with white the use of pools, which can function as black boxes, however, those do not allow for linking sequence ow to it, and are thus self-contained.
resource Know whether a resource re- Somewhat related, TBIM explicitly quires a `fabrication' process. models resource types as being either animate or not.
Know whether resources can act on their own and produce issues, e.g.., be unreliable, not always generate the same outcomes Distinguish between objects Explicit in ITML through the use of and their representations, i.e., hardware/software dichotomy. whether a given resource a collection of paper and ink blobs or the information contained within them.
restriction natural Distinguish between restrictions we cannot do anything about and those we can. intentional Distinguish between restrictions Some languages implicit, e.g., EA we stipulate from those that Anamnesis, and BPMN through use arise holistically (whether good of `Potential Owner'.
or bad). necessary Distinguish restrictions that can (supported by some GPML, e.g., be broken from those that can- ORM 2.0).
not. speci c Distinguish restrictions for which we know when they are broken and not.
result natural material Around half of the conceptual distinctions we analyzed were explicitly supported by at least one modeling language, with some cases being arguable either way. Languages used for speci c aspects do seem to explicitly accommodate some basic (and often widely accepted) necessary conceptual distinctions. For example, the de facto used language for process modeling, BPMN, has explicit support for di erentiating between human and non-human actors, which can be important to know for critical steps in a process. Most modeling languages used for motivations and goals also accommodate the distinction between goals with well-speci ed victory conditions and those with vague or unknown conditions by means of separate hard and soft-goal elements. These explicit distinctions in the notation are likely correlated with the conceptual distinctions being widely accepted as important and having become part of the basic way of thinking. However, taken overall, there does not seem to be a consistent or systematic pattern behind what language explicitly accommodates (or lacks) which conceptual distinctions.
As such, there are a number of conceptual distinctions for which we found no explicit support by any modeling languages. For example, we found no support for explicitly modeling goals and results as being material things. It also did not seem possible to explicitly model goals as being a logical necessity in the investigated languages. The distinction whether results were things that naturally occurred or fabricated was also not supported. When it comes to processes we found no support to model them explicitly as being intentional, and distinguishing between speci c (i.e., well-de ned) processes and processes more fuzzy in their structure. Modeling resources as being humans was also not supported, while this is likely not an unthinkable interpretation { e ective management of `human resources' being important for large enterprises. Finally, we found no explicit support for modeling restrictions as naturally occurring and speci c things. We will discuss some of these distinctions in more detail. 4.1
Some unaccommodated conceptual distinctions Surprisingly, we found no explicit support for di erentiating between goals with varying levels of necessity and obligation. While many common methodologies (e.g., the MoSCoW technique of dividing requirements into must, should could, and would haves) call for such distinctions, many modeling languages con ate them all into a single kind of goal. Arguably in certain aspects it would make sense to make an implicit choice, as in e.g., process modeling it is necessary for certain steps in a ow to be reached before the ow continues, which can be seen as an analog to logically necessary goals. However, goal models in dedicated languages seem to not make this distinction, even though there is a strong focus on di erentiating between hard and soft-goals, which seem correlated with di erent levels of necessity (e.g., one cannot as certainly rely on a soft-goal to be achieved compared to a hard-goal, especially for mission critical goals).
Another seemingly unaccommodated distinction is the necessity of restrictions, that is, whether some restriction (e.g., a rule, principle, guideline) is an alethic condition that cannot be broken or whether it is not and thus can be broken. While in the context of enterprise modeling there is a strong di erentiation of terminology used for di erent kinds of normative restrictions that can be considered breakable, or at least not strictly enforceable (e.g., principles, guidelines, best practice), these often seem to be used outside of modeling languages in their own approaches { e.g., architecture principles [20]. It seems problematic that many languages used for aspects of enterprises, and languages used to describe the actual enterprise architecture like ArchiMate do not have explicit notational support for these di erent kinds of restrictions. Many models that are analyzed a posteriori (e.g., when they are integrated in other models, and the original modelers are no longer involved or available) then become di cult to interpret, as the notation of di erent kinds of restrictions can be ambiguous and lead to situations where it is not clear whether a restriction can be relaxed or not. Surprisingly the only language that seems to support this conceptual distinction is ORM (in particular version 2), which supports the explicit modeling of restrictions as being either alethic or deontic conditions through its visual notation.
Thus, it seems necessary to stimulate a move towards more explicit focus on (formalization of) the semantics of the elements of meaning of modeling languages. The lack of coverage for some of the distinctions shown in Table 2 makes it clear that more work on extending the speci cation of relevant languages with the ability to explicitly distinguish between these di erent conceptual understandings. Given the existence of a large number of di erent dialects of modeling languages sometimes only di ering slightly (e.g., i*, GRL, TROPOS for goal modeling), it seems that supporting many di erent conceptual distinctions in a single notation would be welcomed by many. 5
Conclusion and Future Work We have discussed the importance of explicitly modeling conceptual distinctions and analyzed a number of modeling languages to investigate what kind of distinctions they support. We showed that, while some conceptual distinctions are explicitly supported by relevant modeling languages, there are still a large amount of potentially relevant distinctions that are not accommodated, or implicitly interpreted in a speci c way by modeling languages. We proposed that research should be done regularly to keep up to date with conceptual distinctions deemed relevant and important by modelers and stakeholders alike. Our future work will involve investigations into which distinctions are deemed important. Acknowledgements. This work has been partially sponsored by the Fonds National de la Recherche Luxembourg (www.fnr.lu), via the PEARL programme. 7. Genon, N., Heymans, P., Amyot, D.: Analysing the cognitive e ectiveness of the bpmn 2.0 visual notation. In: Malloy, B., Staab, S., Brand, M. (eds.) Software Language Engineering, Lecture Notes in Computer Science, vol. 6563, pp. 377{ 396. Springer Berlin Heidelberg (2011) 8. Giunchiglia, F., Mylopoulos, J., Perini, A.: The tropos software development methodology: processes, models and diagrams. In: Agent-Oriented Software Engineering III, pp. 162{173. Springer (2003) 9. Gordijn, J., Akkermans, J.: Value-based requirements engineering: Exploring innovative e-commerce ideas. Requirements engineering 8(2), 114{134 (2003) 10. Grau, G., Horko , J., Yu, E., Abdulhadi, S.: i* guide 3.0. Internet (August 2007), http://istar.rwth-aachen.de/tiki-index.php?page ref id=67 11. Lankhorst, M.M.: Enterprise architecture modelling{the issue of integration. Advanced Engineering Informatics 18(4), 205 { 216 (2004) 12. van der Linden, D.J.T., Hoppenbrouwers, S.J.B.A., Lartseva, A., Proper, H.A.: Towards an investigation of the conceptual landscape of enterprise architecture. In: T. Halpin et al. (ed.) Enterprise, Business-Process and Information Systems Modeling, LNCS, vol. 81, pp. 526{535. Springer Berlin Heidelberg (2011) 13. Moody, D., Hillegersberg, J.: Evaluating the visual syntax of uml: An analysis of the cognitive e ectiveness of the uml family of diagrams. Lecture Notes in Computer Science 5452, 16{34 (2009), cited By (since 1996) 0 14. Moody, D.L.: The physics of notations: Toward a scienti c basis for constructing visual notations in software engineering. IEEE Transactions on Software Engineering 35, 756{779 (2009) 15. Moody, D., Heymans, P., Matuleviaius, R.: Visual syntax does matter: Improving the cognitive e ectiveness of the i* visual notation. Requirements Engineering 15(2), 141{175 (2010), cited By (since 1996) 0 16. Object Management Group: Business motivation model (bmm), version 1.1. Internet (2010), http://www.omg.org/spec/BMM/1.1/ 17. Object Management Group: Business Process Model and Notation (BPMN) FTF
Beta 1 for Version 2.0. Internet (2010), http://www.omg.org/spec/UML/2.0/ 18. Patig, S.: Modeling deployment of enterprise applications. In: Proc. CAISE Forum,
LNBIP 72. pp. 253{256 (2010) 19. Plataniotis, G., de Kinderen, S., Proper, H.A.: EA Anamnesis: Towards an approach for Enterprise Architecture rationalization. In: Printing, S. (ed.) Proceedings of the The 12th Workshop on Domain-Speci c Modeling (DSM12). ACM DL (2012) 20. Proper, H.A., Greefhorst, D.: The Roles of Principles in Enterprise Architecture.
In: Proper, H.A., Lankhorst, M.M., Schoenherr, M., Barjis, J., Overbeek, S. (eds.) Trends in Enterprise Architecture Research. Lecture Notes in Business Information Processing, vol. 70, pp. 57{70. Springer Berlin Heidelberg (2010) 21. Quartel, D., Engelsman, W., Jonkers, H., Van Sinderen, M.: A goal-oriented requirements modelling language for enterprise architecture. In: Enterprise Distributed Object Computing Conference, 2009. EDOC'09. IEEE International. pp. 3{13. IEEE (2009) 22. Scott, J.: Business Capability Maps { The missing link between business strategy and IT action. Architecture & Governance 5(9), 1{4 (2009) 23. Sonnenberg, C., Huemer, C., Hofreiter, B., Mayrhofer, D., Braccini, A.: The rea-dsl: a domain speci c modeling language for business models. In: Advanced Information Systems Engineering. pp. 252{266. Springer (2011) 24. The Open Group: ArchiMate 2.0 Speci cation. Van Haren Publishing (2012)