Modeling Approach Comparison Criteria for the CMA Workshop at MODELS 2012

Transcription

1 Modeling Approach Comparison Criteria for the CMA Workshop at MODELS 2012 Geri Georg 1, Shaukat Ali 2, Betty H.C. Cheng 3, Benoit Combemale 4, Robert France 1, Jörg Kienzle 5, Jacques Klein 6, Philippe Lahire 7, Markus Luckey 8, Ana Moreira 9, Gunter Mussbacher 10 1 Computer Science Department, Colorado State University, Fort Collins, Colorado, USA 2 Simula Research Laboratory, Norway 3 Dept. of Computer Science and Engineering, Michigan State University, East Lansing, Michigan, USA 4 Ecole Supérieure d Ingénieurs de Rennes, Université de Rennes, Rennes, France 5 School of Computer Science, McGill University, Montreal, Canada 6 Computer Science and Communications Research Unit, Université du Luxembourg, Luxembourg 7 Département d Informatique, Université de Nice - Sophia Antipolis, Nice, France 8 Institut für Informatik, Universität Paderborn, Paderborn, Germany 9 CITI/Departamento de Informática, FCT, Universidade Nova de Lisboa, Lisbon, Portugal 10 Dept. of Systems and Computer Engineering, Carleton University, Ottawa, Canada October, 2012 The comparison criteria described in this document represent a work-in-progress, begun at the Bellairs AOM 1 workshop in April 2011, continued at the first CMA 2 workshop in October 2011, and further discussed at the Bellairs AOM 3 workshop in April/May The purpose of the criteria is to provide a basis for understanding, analyzing, and comparing various modeling approaches. Two groups of criteria are presented: Criteria related to general modeling dimensions (see Section 1) and those related to key modeling concepts (see Section 2). The modeling dimensions criteria characterize a modeling approach by (i) the development phases and activities for which it is most applicable and (ii) the languages or notations used. The key modeling concepts criteria are used to classify a modeling approach in terms of the modeling building blocks, attributes, or qualities targeted for optimization or improvement by the approach. These criteria are intended to play a particularly important role in situating existing approaches in the current body of work, and in identifying the considerations that must be made when developing new modeling approaches. In order to fulfil their role, it is important that the criteria be defined in terms that are widely and precisely understood by the modeling community. We have identified the following as central key modeling concepts: modularity, first class entities including units of encapsulation, and composability including composition rules and composition operators. The key modeling concepts criteria can be applied to either an approach or to the models that are produced using the approach. The focus of this document, however, is the assessment of modeling approaches, and not the models they produce. Furthermore, key modeling concepts can conceivably be interpreted differently depending on which modeling dimension is being considered. While we recognize this fact, we present the modeling dimensions and key modeling concepts in a more orthogonal view. August, and

2 Figure 1 Metamodel for Modeling Approaches Where possible, the description of a modeling dimension or key concept contains generally agreed-upon definitions. In cases where such definitions are not available, we have 2

3 included examples that demonstrate our intent. Each description is followed by a set of questions that aim to assess a modeling approach against the modeling dimension or key modeling concept. Figure 1 structures modeling dimensions and key modeling concepts discussed in this document in a metamodel that can be used to characterize and instantiate modeling approaches. The main classes in the metamodel are ModelingApproach, Language, FirstClassEntity, EncapsulationUnit, and CompositionSpecification. Each of the following sections and subsections explains the applicable portion of the metamodel in more detail (indicated by sans serif italic font). Several additional key modeling concepts have been identified but have not yet been adequately discussed to be included in the metamodel. These key modeling concepts have been placed into a parking lot (see Section 3). Our goal is to continue to refine this document in order to address all key modeling concepts with a similar level of detail. Operator 1. Modeling Dimensions 1.1 General Questions: A. What is the name of the modeling approach? B. Which documents related to the modeling approach (e.g., standards, publications, technical documentation) and tools related to the modeling approach were used for this assessment? Provide references and version numbers wherever possible. C. What is the purpose of the modeling approach, why is the approach used, and what problem(s) does the modeling approach address? D. What are the usage scenarios for the modeling approach? What are the processes or methodologies that define the application of the modeling approach? Provide references wherever possible. is y s 1.2 Phase/activity Modeling approaches (ModelingApproach) may be applicable during certain phases of software development (DevelopmentPhase, PhaseType), or for specific activities of software development (Activity, ActivityType). They may also be useful during multiple phases or for multiple activities. For example, the early requirements phase focuses on stakeholder goals and the description and assessment of alternatives. During the architecture or high-level design phase, an architecture is created that describes the overall system structure as well as general rules and constraints imposed on that structure. Examples of architectures are 3-tier, layered, event-based, distributed client-server, distributed peer-to-peer, etc. Activities such as specification/modeling, analysis, validation, verification, and evolution tend to crosscut across development phases, although their purpose and targets may differ from one phase to another. For example, model checking can be used as a high-level design analysis technique, whereas performance analysis may be targeted towards low-level design or even implementation phases. Validation ensures that the system is what the stakeholder wants, while verification ensures that the system is built as specified in an artifact. Trade-off analysis investigates the 3

4 effect of simultaneous changes in one or more key factors in a decision, design, or project [1]. Trade-off analysis offers the ability to choose between a set of alternatives, based on a set of potentially conflicting criteria. Note that a modeling approach is applicable to a software development phase or a specific activity only if the modeling approach directly supports the phase or activity, e.g., indirect support by transforming a model of the modeling approach into a different model that does not belong to the modeling approach and is subsequently used for an activity during a phase does not count. Furthermore, note that in the metamodel the development phases (/phase) addressed by a modeling approach are a derived attribute, because the development phases can be deduced from the development phases of the activities of the modeling approach. Questions: A. During which software development phases is the modeling approach applicable? Early requirements Late requirements Architecture/High-level design Detailed/Low-level design Implementation Integration Deployment B. In which software development activities is the modeling approach applicable? Specification/Modeling describe what is modeled and in which phase: Validation describe what is validated and in which phase: Verification describe what is verified and in which phase: Evolution describe what is evolved and in which phase: Analysis describe what is analyzed and in which phase: Trade-off Analysis describe what trade-off is analyzed and in which phase: 1.3 Language/notation A model must be defined in a well-defined language or notation (Language). Models may be expressed in a single, general-purpose language, but there are certainly situations that can benefit from the use of languages that are specific to the model viewpoint (e.g., a domainspecific language to define security policies or other system-wide properties). A language for 4

5 an approach may be able to express the functional elements of a model or it may be able to specifically express quality or other non-functional attributes that are used as criteria to judge the quality of a system, rather than its specific behavior. This ability can aid the modeler when analyzing specific quality attributes. An example of an approach for specifying and measuring such quality attributes is one that uses the UML MARTE profile to model performance qualities and then uses the model as a means to perform system design performance analysis. A language of a modeling approach is based on a paradigm (SupportedParadigm), which is defined as the theories, rules, concepts, abstractions, and practices that constrain how activities and development artifacts are handled or represented. A paradigm imposes a decomposition criterion, which is then used to decompose and analyze a problem into smaller problems. Examples are the object-oriented, aspect-oriented, procedural, service-oriented, component-based, feature-oriented, goal-oriented, and logic-based paradigms. The choice of paradigm affects other concepts and dimensions, including tools. For example, in the objectoriented paradigm, modules are classes/abstract data types, while in the procedural paradigm modules are functional abstractions. Tools must be able to perform activities on these modules. A view (View, ViewType) is a projection of a model for a particular reason. For many models, while both structural and behavioral specifications are part of the model, there can be separate structural and behavioral views of the model, and these perspectives may be described using different languages (e.g., the structural perspective may be described using class diagrams while the behavioral perspective may be described using state machines or activity diagrams). A modeling approach may also use specific languages and their associated views for quality attributes such as performance, reliability, and safety to support focused modeling and analysis of these qualities. Furthermore, an intentional view shows the goals that are to be achieved by a system for its stakeholders. A language may be applicable or not applicable to a specific domain (Domain). Note that in the metamodel the attribute for general purpose (/generalpurpose) of a language is a derived attribute, because a language is general purpose if it does not have any supported or avoided domains (supporteddomain or avoideddomain, respectively). A language may use textual, or graphical, or both types of representational elements (ConcreteSyntax). A language may have formal semantics (Semantics), i.e., the language is based upon a formal domain that is well-understood and that allows proofs to be performed, e.g., mathematical logic or Petri nets, or it is possible to map the language to mathematical logic expressions, Petri nets, etc. A language with formal semantics is entirely expressed in mathematical terms. Such a language is machine analyzable, but this does not mean that all aspects of the language are machine analyzable (as there are theoretical limitations to theorem proving and model-checking). A language with a rigorous semantics is a language with semantics expressed in a form that allows language statements to be mechanically analyzed in a limited way (i.e., not all aspects of the language are formalized just enough to perform the types of analysis needed). Executable modeling languages fall into this category as they can be used to support simulations and testing, but one cannot use them to prove that all behaviors satisfy certain properties. Often, languages with a rigorous semantics are based on a welldefined metamodel. While this is usually sufficient to qualify as being rigorous, a welldefined metamodel by itself is insufficient to qualify as being formal. Finally, a language that is informal has none of the above characteristics (in particular, it is not machine analyzable). 5

6 Questions (Repeat B H for each language identified in A): A. List the language(s) used by the modeling approach: B. What is the standardization status of the language? Language is a standard. Language is based on standard(s) list standard(s): Language is not a standard and is not based on standard(s). C. For which application domains is the language applicable? Language is specific to application domain(s) list domain(s): Which application domains should be avoided? Language is general purpose. D. What are the paradigms supported by the language? Object-oriented Aspect-oriented Procedural Service-oriented Goal-oriented Component-based Feature-oriented Logic-based E. The semantics of the language is: Formal Rigorous None of the above (Informal) F. If the language is formal or rigorous, it is assumed to be executable, or machine analyzable, or both. What applies to the language? Executable Analyzable describe what can be analyzed (e.g., which quality attributes) 6

7 G. What views are supported by the language? Structural Behavioral Intentional Quality-based describe which quality attributes are supported: H. What types of concrete syntax are used by the language? Textual Graphical 2. Key Modeling Concepts 2.1 Modularity/first class entities/units of encapsulation/types of concerns The Separation of Concerns principle states that a good way of managing the complexity of developing an artifact associated with many different kinds of concerns, is to break it up into parts that can be handled in relative isolation. The parts may reflect one or more concerns and thus proper separation of concerns allows developers to focus on a subset of concerns at any given time. Effective support for the Separation of Concerns principle can lead to software systems that achieve required engineering quality factors such as robustness, adaptability, maintainability, and reusability. The ideal decision regarding which concerns must be separated from each other requires finding the right compromise for satisfying multiple (quality) factors. A multi-dimensional decomposition, or as it is called multidimensional separation of concerns [2], permits the clean separation of multiple, potentially overlapping and interacting concerns simultaneously, with support for on-demand remodularization to encapsulate new concerns at any time. A language of a modeling approach, however, is not required to support (or indeed may not need to support) the encapsulation of crosscutting concerns through advanced decomposition and composition mechanisms, but may rather be restricted to basic forms of composability suitable for non-crosscutting concerns. A language consists of first class entities (FirstClassEntity) that constitute the building blocks of the language. These first class entities may be combined with each other in various ways as specified in composition specifications (CompositionSpecification). A first class entity may be a module, i.e, a software unit of encapsulation (EncapsulationUnit) with welldefined interfaces which express the services that are provided by the module for use by other modules [3]. A module promotes information hiding by separating its interfaces from its internal design (often referred to as its implementation). Examples of well-defined interfaces are public/private OO-type interfaces, protocol state machines, or service-level agreements. Modularization [4] is decomposition into modules according to decomposition criteria imposed by the paradigm. A language of a modeling approach encapsulates some concepts as units, in order to easily reason about them, manipulate them, analyze them, etc. Examples of encapsulation units are activities, services, aspects, features, themes, concerns, classes, etc. For example, an aspect is a crosscutting unit of encapsulation. A feature is (usually) a functional unit of encapsulation, as in a feature model. A concern is a functional or non-functional unit of encapsulation. A theme [5] is an encapsulation of some functionality or crosscutting concern Modularization [3] is decomposition into modules according to decomposition criteria imposed by the paradigm. A is 7

8 in a system and is considered more general than an aspect. A class is the designated unit of encapsulation in the object-oriented paradigm. A file may also be considered a first class entity or a unit of encapsulation but only if it contains several other units, e.g., if the file contains several classes and a composition mechanism uses the whole file as input. Furthermore, the units may differ depending on the phase of software development. For example, units for a requirements phase could be use cases, quality attributes, and stakeholders, units for design could be classes, aspects, data definitions, and states, and units for implementation could be classes and packages. Finally, a first class entity may be shown in one or more views (see section 1.3). Questions (Repeat B G for each first class entity identified in A): A. List the first class entities used by a language of the modeling approach: B. If the modeling approach uses more than one language, to which language does the first class entity belong? unit of encapsulation F E unit of encapsulation unit(s) of encapsulation unit of encapsulation C. Which software development phases and their activities does the first class entity support? unit of encapsulation D. In which view(s) is the first class entity shown? unit of encapsulation E. Is the first class entity a unit of encapsulation? Yes No F. If the first class entity is a unit of encapsulation, which type of well-defined interface, if any, does the unit of encapsulation have? Public/private OO-type interface Protocol state machine Service level agreement E W No well-defined interface G. If the first class entity is a unit of encapsulation, what is hidden by the unit of encapsulation? 2.2 Composability: composition rules and composition operators In the context of this document, we are interested in composability in a rather general way. Composition is the act of creating new building blocks (i.e., first class entities) by using existing ones (e.g., by putting together several units of encapsulation). A composition is specified in some way (CompositionSpecification), may result in some output (outputs), and encompasses a wide array of composition rules (iscompositionrule) and composition operators (iscompositionoperator) that combine existing first class entities. A composition rule provides the specification of a composition but does not actually perform the / modules/units of encapsulation In the context of this document and assessment, the term composition applies to units of encapsulation 8

9 composition. A composition operator, on the other hand, results in a composed model. If the composed model only contains model elements that can also be found in the source models, then we consider this a particularly strong form of composition. However, composition rules and operators that introduce new model elements in the result of the composition, i.e., model elements that cannot be found in the source models, are still considered as a form of composition. Some composition rules and composition operators enable the structuring of modules through traditional means (e.g., association, generalization (inheritance), aggregation, and composition (as defined by UML), hierarchical decomposition (e.g., sub-activity diagrams), as well as grouping mechanism (e.g., a package)). More advanced forms of composition rules and composition operators are used for (i) the composition of crosscutting concerns through pattern matching, superimposition, aspect weaving, or other means and (ii) model transformations. For example, UML Generalization combines two classes with each other. UML Generalization is a composition rule as it defines which two classes from one or two models should be used to establish generalization between them but the composition is not actually performed at the time of specification. The signature of the composition rule is M x C 1 x M x C 2 M (where M are models that may or may not be the same, C 1 is the parent class, and C 2 is the child class that cannot be the same as C 1 ; the result is a new model M with a new model element for generalization added). Any analysis of the model has to take this new model element into account. However, there also exists a UML Generalization composition operator that is synonymous with the composition rule and performs the actual composition (i.e., adding elements and constraints to the classes so that the generalization composition rule is respected). Its signature is hence M x C 1 x C 2 M' (where C 1 is the parent class, C 2 is the child class that cannot be the same as C 1, and both are connected in the model M by a generalization as specified by the composition rule; the result is a new model M ). Just as the composition rule introduces a new model element (i.e., the generalization), the composition operator also introduces new model elements that are necessary to express the semantics of the generalization composition rule. The composition operator takes the composition rule and applies it. Therefore, there is no need for the composition rule anymore (i.e., it is not in the resulting model anymore). Because there exists a dedicated composition operator used only for the composition rule UML Generalization, UML Generalization is categorized as both, a rule and an operator. The second example is UML Association, combining two classes with each other. UML Association takes as input two classes from one or two models and adds the association between them. It is also a composition rule like UML Generalization with a synonymous composition operator the association is actually not implemented when the "line" is drawn. The rule s signature is M x C x M x C M (where M are models that may or may not be the same and C are classes that may or may not be the same; the result is a new model M with a new model element for association added). The operator's signature is M x C x C M' (where C are classes that may or may not be the same but are connected in the model M by an association; the result is a new model M ). As with UML Generalization, the UML Association rule and operator introduce new model elements, i.e., the association (which does not exist in either of the two source models) and those model elements necessary to express the semantics of the association composition rule, respectively. Another example is Control Flow Construct in a scenario notation such as UCM [6] which combines the building blocks of the scenario notation (i.e., responsibilities in UCM) in, e.g., sequence, parallel, or as alternatives. Control Flow Construct is only a composition s s Basic the composition specification Inheritance The Inheritance composition specification inheritance Inheritance child or any other way of implementing inheritance C 2 and that cannot be the same as C 1 This does not Inheritance the composition specification Inheritance the composition specification The composition specification Inheritance. M. are models that conform to the metamodel for UML class diagrams and C are classes; the two Ms may or may not be the same; the two Cs may or may not be the same In contrast to Inheritance s a, as it the composition specification 9

10 operator as the act of specifying the operator immediately results in the composition being performed. The inputs of the Control Flow Construct are a responsibility of a UCM map and another responsibility (optionally on the same UCM map). The operator results in an updated UCM map where both responsibilities have been connected. Hence, the signature of the Control Flow Construct is M x R x R M' (where M is a map and R are responsibilities which may or may not be the same). Control Flow Construct does add new model elements, i.e., those representing the control flow construct. Note that the distinction between Control Flow Construct (i.e., not a composition rule with a synonymous composition operator but rather just a composition operator) and UML Generalization (i.e., a composition rule with a synonymous composition operator) is not as clear as desired. We acknowledge this and have designed the questionnaire to further crystallize the differences, if any. At this point, a distinction is that the latter can be expressed by a set of other model elements, while the former cannot. In other words, generalization can be expressed in UML with already existing language concepts such as class attributes and constraints while the control flow construct cannot be expressed in UCM with other existing language concepts. Finally as an example of the second group of compositions, the RAM approach [7] uses Instantiation which is a composition rule as it only defines which model elements from two source models need to be composed together. Its signature is M x E 1 x M x E 2 M' (where M are models that may or may not be the same and E are model elements that are not the same; the result is a new model M that includes a new model element for instantiation). Instantiation is not a composition operator, as the composition operator used to realize Instantiation is the composition operator Merge and this operator is not specific to Instantiation. Merge, on the other hand, is only a composition operator. Its signature is M 1 x M 2 M' (where M are models) and it does not introduce any new modeling elements. The result of this composition operator contains only elements that exist in the source models. Merge is also a binary composition operator for which algebraic properties can be considered. For a composition to occur, one or more first class entities must first be identified as input to the composition. Input identification (InputSpecificationMethod) can be done explicitly (e.g., class A inherits from class B), by pattern matching (e.g., a regular expression identifies the model elements that need to be composed), or through a binding (i.e., a type of explicit input identification that maps one model element to another model element). Second, the composition operator needs to be defined. Implicit composition does not require the specification of a specific composition operator (e.g., the RAM [7] weaver assumes that the desired composition operator is merge ). On the other hand, explicit composition requires the specification of a composition operator, e.g., add, replace, wrap, merge, etc. A composition rule or composition operator may also be classified by whether it supports symmetric or asymmetric composition (InputInterpretation). A composition rule or composition operator is typically applied to two input models to specify how to create another model or to actually create another model. If both inputs are of the same type, then it is possible that symmetric composition is supported, in which case commutativity holds as the order of the inputs does not matter. If the input models are of different types (e.g., class and aspect), then asymmetric composition is probably supported by the approach, i.e., composition works if A is applied to B but does not work if B is applied to A. Furthermore, composition may be syntax-based or semantics-based [8] (DomainType). In syntax-based composition, the composition is based on syntactic references to the input models. In the context of the composition of crosscutting concerns, this may lead to the wellknown fragile pointcut problem, where structural changes in the base concerns may invalidate the compositions. This problem is tackled in semantics-based composition by relying on the. the composition specification It units of encapsulation probably and this 10

11 meaning of the input models and the relationships to be captured by the composition rather than the structure of the input models or specific naming conventions. Semantics-based composition may be applied to the identification of locations where composition is supposed to occur (e.g., identification of semantically equivalent patterns) or the composition itself (e.g., in simplifying complex results by recognizing redundant model elements; an example is composing inheritance classes that also have a direct relation simple composition will result in multiple direct relations, all except the first of which are redundant). The rules that govern semantics-based composition cannot be inferred by a machine unless the formalization of an approach goes beyond its abstract grammar, e.g., if an execution semantics is formally described then behavior equivalence may be determined. The precision of a composition rule or composition operator may be deterministic, probabilistic, or fuzzy [9] (PrecisionType). Probabilistic compositions are required if there are uncertainties in the specification of problems. Here, it may be preferable to define and optimize the solutions and the composition of solutions with respect to the probabilistic problem definitions [9]. Fuzzy compositions are required if a problem can be solved in a number of alternative ways, and it is not possible (or desired) to commit to a single alternative. Here, each alternative may be assigned to a fuzzy set that expresses the degree of relevancy of a solution. Special composition rules or composition operators are required, which can reason about fuzzy sets. Regardless of whether more advanced composition mechanisms are supported by a language or not, assessing the algebraic properties of binary composition operators (BinaryCompositionOperator) such as commutativity, associativity, and transitivity makes it possible to predict what the result of a composition will be. A language treats models uniformly if it facilitates decomposing a model into a set of cooperating, structurally compatible concerns, and it provides composition operators that manipulate such concerns without affecting their compatibility. The uniform treatment of the concerns helps to fulfil the closure property in the models. If a composition operator applied to any member of a set produces a model that is also in the set, then the set of models is closed under that operation [9]. For example, a language defined by a metamodel is closed under the operation if that operation applied to a model that conforms to the metamodel produces a model that again conforms to the metamodel. However, the set could also be a set of metamodels. Or quite differently, the set could be the set of regular languages and the operation might change the regular language. If the set of regular languages is closed under that operation, then the resulting language again is regular. The closure property is a way to standardize the decomposition mechanism and composition operators that are provided by a language. In addition, it helps to increase the abstraction level of concerns by forming a hierarchy of concerns in which the concerns at the higher levels of the hierarchy abstract from their lower level concerns. Whenever several composition rules or composition operators can be applied, one needs to consider interactions between these rules or operators. At a minimum, languages may support an explicit ordering of composition rules and composition operators (e.g., through precedence). A more detailed assessment of interactions, however, is deferred (see parking lot in Section 3). Finally, a composition rule or operator may be an intrinsic part of a first class entity or may be encapsulated in its own unit. Hence, the modularity of the composition rule or operator is also of interest, i.e., whether or not it is separated from the first class entities that are being composed. Questions (Repeat C U for each composition identified in B; A and B need to be answered only once): basic or some approaches allow units of encapsulation to be composed with the help of a composition specification. A unit units of encapsulation L T,, M, N, and O 11

12 A. If the modeling approach does not use composition to create new first class entities, how does it create new first class entities from existing first class entities? B. List the composition(s) used by a language of the modeling approach: C. To which language does the composition belong? D. Is the composition a: Composition Rule Composition Operator E. If the composition is a composition rule, what other compositions are used to realize the composition defined by the composition rule? F. To which first class entities can the composition be applied (i.e., what are the inputs of the composition)? G. What is the result of the composition (i.e., what are the outputs of the composition)? H. State the signature of the composition as explained in natural language in questions F and G in the form "input1 x input2 x... output". I. Does the result of the composition contain a modeling element that does not exist in the source models (i.e., does the composition add new model element(s) to the source models)? Yes No J. Does the composition realize one or more composition rules? If yes, list each realized composition rule and state whether the realized composition rule still exists in the resulting composed model. Yes provide details in this case: No K. What is the mechanism for identifying the inputs for the composition? Explicit Pattern Matching Binding s s units of encapsulation units of encapsulation units of encapsulation F D E unit(s) of encapsulation (s) If the composition specification is a composition operator, w E F for composition operators and in the form "input1 x input2 x..." for composition rules If the composition specification is a composition operator, d a J E defining 12

13 L. What is the mechanism for applying the composition? Explicit Implicit provide details in this case: M. Is the composition: Symmetric Asymmetric N. Is the composition: Syntax-based Semantics-based provide details in this case: O. Is the composition: Deterministic Probabilistic Fuzzy Other non-deterministic P. If the composition is a binary composition operator, what algebraic properties does the composition operator provide? Commutativity Associativity Transitivity Q. If the composition specification is a composition operator, does the composition operator produce models that are closed under the operator? Yes No R. Is the intent of the composition to address crosscutting concerns? Yes No S. Is it necessary for a language of the modeling approach to support an explicit ordering of the composition? Yes explain why this is needed: No K F defining L G M H N I f the composition specification is a composition operator, i I O J P K D Q L Can be used R M Does s s state which language(s) and how for each language 13

14 T. Is the composition itself separated from the specification of first class entities? Describe in detail how the composition is or is not separated from first class entities. Yes No Details: U. How is a composed model intended to be presented to the modeler by a tool? The composed model is intended to be shown with automatic layout. The composed model is intended to be shown without automatic layout. The original model is intended to be shown with annotations indicating the composition. The composed model is intended to be not shown. 2.3 Traceability Traceability is (i) the ability to chronologically interrelate uniquely identifiable entities in a way that is verifiable or (ii) the ability to verify the history, location, or application of an entity (e.g., a concern, a process, or an artifact such as a requirements model element or a module) by means of documented recorded identification [10]. Entities that are traced are generally model elements (FirstClassEntity). Traceability can be vertical or horizontal (TraceabilityType). Using requirements as an example, vertical traceability is the ability to trace requirements back and forth through the various layers of development, e.g., through the associated life-cycle work products of architecture specifications, detailed designs, code, unit test plans, integration test plans, system test plans, etc. It is possible to generalize this definition of vertical traceability to refer to abstraction levels above the requirements (e.g., system engineering or business process engineering) and below the requirements (e.g., architecture) [11]. Again using requirements as an example, horizontal traceability refers to the ability to trace requirements back and forth to associated plans such as the project plan, quality assurance plan, configuration management plan, risk management plan, etc. This definition can also be generalized. Horizontal traceability may be required during any phase of software development, e.g., at the design level (tracing across different design documents) and at levels above requirements (system engineering or product family domain analysis). Some traceability links may cross the boundaries of software development phases, while other links remain within such boundaries. From a composition point of view, traceability includes being able to identify elements in the composed model with their sources in the original models. More traditional uses of traceability include identification of refinements at lower levels of abstractions if not directly supported by the modeling language (e.g., through hierarchical decomposition). It may be argued that traceability is the concern of tools, however, some entities may be explicit in the modeling approach that are, or could be, targeted for traceability. Furthermore, modeling concepts may exist in the languages of the modeling approach primarily for the purpose of supporting traceability. S N the unit of encapsulation the unit of encapsulation T O If the composition specification is a composition operator, h H If the composed model is presented in a different way depending on the used composition operator, state the composition operator and explain the different approach: can either be units of encapsulations or ModelElementType within such units 14

15 Questions: A. What types of traceability are supported? (For each type, describe (i) the entities that are traced either in the modeling approach (i.e., as part of the process of applying the modeling approach or in models produced by the modeling approach), (ii) the purpose of the type of traceability, and (iii) whether the type of traceability spans more than one software development phase) Horizontal Vertical B. Which language concepts of the modeling approach exist primarily to support traceability? 2.4 Mapping from the previous and to the next phase of software development This property is about whether the concepts of one approach are compatible with another approach that precedes or follows the approach. It is hence not purely a traceability issue but rather a compatibility issue. The property describes the support of a modeling approach for the transition from one development phase to another. It may be necessary to coerce the concepts of one approach into those of another or to extend one approach to make it interface properly with another approach. Mappings may exist with first class entities, at the level of units of encapsulation, or at finer granularity, i.e., model elements within a unit of encapsulation (these model elements may be other first class entities or units of encapsulation). If a modeling approach supports more than one development phase, this question is about the handover to preceding and succeeding modeling approaches. Section 2.3 on traceability should cover the links between more than one development phase within the same modeling approach. Questions: A. How does the modeling approach address moving from the previous phase of software development and which model elements are connected? (ModelElementType) B. How does the modeling approach address moving to the next phase of software development and which model elements are connected? 2.5 Tool support Features (Feature) of tools (Tool) automate formalized parts of one or more activities within and across software development phases (e.g., requirements, design, code, verification & validation, deployment, runtime management, evolution). Questions: A. List the tool(s) that support the modeling approach: 15

16 B. Which features are supported by the tool(s) and by what degree? Specification/Modeling: Full Partial None Application of Composition Operators: Full Partial None Incremental Composition: Full Partial None Analysis: Full Partial None Trade-Off Analysis: Full Partial None Validation: Full Partial None Verification: Full Partial None Evolution: Full Partial None Model Consistency: Full Partial None Other: C. How is a composed model presented to the modeler by the tool(s)? The composed model is shown with automatic layout. The composed model is shown without automatic layout. The original model is shown with annotations indicating the composition. The composed model is not shown. D. How do tools help users understand relationships across first class entities? Which relationships are covered (e.g., unwanted interactions or conflicts, dependencies between units of encapsulation)? Unwanted interactions or conflicts describe how the tool(s) help: units of encapsulation Dependencies describe how the tool(s) help: 2.6 Empirical studies/evaluation Empirical studies are broadly classified into controlled experiments, case studies, and surveys [12]. A case study is an in-depth observational study, whose purpose is to examine projects or evaluate a system under study. Case studies are mostly used to demonstrate the application of an approach in a particular context. For example, in the context of software modeling, the goal of a case study could be to demonstrate the applicability of modeling non-functional behavior (e.g., security) of an industrial case study and reporting lessons learnt during this process. Surveys are normally conducted to evaluate a tool, methodology, or approach, which has been in use for a while. Usually, data is collected using questionnaires and interviews from a representative population. Once the data is collected, it is analyzed using appropriate descriptive statistics and possibly using statistical tests. Based on the analysis of results, conclusions are drawn and generalized. 16

17 A controlled experiment is performed in a controlled environment with the aim to manipulate one or more variables and maintain other variables at fixed values to measure the effect of change (outcome). Experiments usually have two or more treatments, whose outcomes are to be compared. For example, in the context of software modeling, an example of a controlled experiment could be to measure effort required by two approaches, which are developed to solve a particular modeling problem, such as modeling non-functional properties. Questions: A. Briefly describe empirical studies or evaluations that have been performed for the modeling approach (provide references wherever possible). B. How does the modeling approach measure the quality of a composition? Resulting model modularity Resulting model coupling/cohesion Quality of composition is not measured 3. Additional Key Modeling Concepts ( parking lot ) Several other potential comparison criteria have been identified but at this point have not been adequately discussed to be included in the assessment. During the workshops we ranked these criteria in order of importance. They are, in that order: reusability, scalability, inter-module dependency and interaction, abstraction, usability (readability, understandability), ease of evolution, reduction of modeling effort, completeness, and finally expressiveness. 4. References 1. Business Dictionary, Harold Ossher and P. Tarr: Multi-Dimensional Separation of Concerns and the Hyperspace Approach. In Software Architectures and Component Technology, M. Aksit (Ed.), Kluwer Academic Publishers, pp , Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, and Reed Little: Documenting Software Architectures: Views and Beyond. Addison-Wesley Professional, David Parnas: On the Criteria To Be Used in Decomposing Systems into Modules. In Communications of the ACM, vol. 15, pp , Siobhán Clarke and Elisa Baniassad: Aspect-Oriented Analysis and Design: The Theme Approach. Addison-Wesley Professional, International Telecommunication Union (ITU-T), Recommendation Z.151 (11/08): User Requirements Notation (URN) - Language Definition, Geneva, Switzerland, November Jörg Kienzle, Wisam Al Abed, and Jacques Klein: Aspect-oriented multiview modeling. Proc. 8th ACM International Conference on Aspect-oriented Software Development (AOSD 09), ACM, pp , March 2009, doi: /

18 8. Ruzanna Chitchyan, Phil Greenwood, Americo Sampaio, Awais Rashid, Alessandro Garcia, and Lyrene Fernandes da Silva: Semantic vs. syntactic compositions in aspect-oriented requirements engineering: an empirical study. In Proceedings of the 8th ACM international conference on Aspect-oriented software development, pp , Mehmet Aksit: The 7 C's for Creating Living Software: A Research Perspective for Quality- Oriented Software Engineering. In Turkish Journal of Electrical Engineering and Computer Sciences, vol. 12, pp , no. 2, ISO 9001:2008, Quality management systems Requirements, Tim Kasse: Practical Insight into CMMI, Artech House Publishers, ISBN: , pp , Claes Wohlin, Per Runeson, and Martin Höst: Experimentation in Software Engineering: An Introduction, Springer,