Academia.eduAcademia.edu

Figure 41 – uploaded by Mathieu Acher

See full PDFdownloadDownload figure
Figure 10.2: Excerpt of workflow and service metamodel.

Figure 10 2: Excerpt of workflow and service metamodel.

Related Figures (64)

Figure 2.1: Framework for SPL engineering: domain and application engineering, problem and solution space
Figure 2.1: Framework for SPL engineering: domain and application engineering, problem and solution space
Figure 2.2: Challenge for SPL engineering: decreasing the proportion of application engi- neering effort [Deelstra et al. 2004]
Figure 2.2: Challenge for SPL engineering: decreasing the proportion of application engi- neering effort [Deelstra et al. 2004]
Figure 2.3: Model, Metamodels, Modeling Language, SUS
Figure 2.3: Model, Metamodels, Modeling Language, SUS
Figure 3.1: A family of medical images described with a feature model Figure 3.1 gives a first visual representation of a feature model. Throughout the thesis, we will rely on the same graphical notation used in this figure, largely inspired by the one proposed in [Czarnecki and Eisenecker 2000]. Features are graphically represented as a rectangles while some graphical elements (e.g., unfilled circle) are used to describe the variability (e.g., a feature may be optional). Intuitively, the feature model depicted in Figure 3.1 compactly describes a family of medical images, where each member of the family is a medical image corresponding to an unique combination of features.
Figure 3.1: A family of medical images described with a feature model Figure 3.1 gives a first visual representation of a feature model. Throughout the thesis, we will rely on the same graphical notation used in this figure, largely inspired by the one proposed in [Czarnecki and Eisenecker 2000]. Features are graphically represented as a rectangles while some graphical elements (e.g., unfilled circle) are used to describe the variability (e.g., a feature may be optional). Intuitively, the feature model depicted in Figure 3.1 compactly describes a family of medical images, where each member of the family is a medical image corresponding to an unique combination of features.
Figure 3.2: feature model, set of configurations and propositional logic encoding
Figure 3.2: feature model, set of configurations and propositional logic encoding
Figure 3.3: Three logically equivalent feature models with different hierarchies
Figure 3.3: Three logically equivalent feature models with different hierarchies
Figure 3.4: Properties of feature models: core features and anomalies
Figure 3.4: Properties of feature models: core features and anomalies
Figure 4.1: From workflow design to selection of services.
Figure 4.1: From workflow design to selection of services.
Figure 4.2: Medical Imaging Service: Variability and Concerns
Figure 4.2: Medical Imaging Service: Variability and Concerns
Figure 4.3: Managing Multiple Feature Models: An Example
Figure 4.3: Managing Multiple Feature Models: An Example
Table 4.1: Multiple Feature Models (FMs) in the state-of-the-art: motivation, composition and decomposition mechanisms, tool and language support
Table 4.1: Multiple Feature Models (FMs) in the state-of-the-art: motivation, composition and decomposition mechanisms, tool and language support
Figure 5.1: Different ways of composing feature models
Figure 5.1: Different ways of composing feature models
Figure 5.2: Four insertions with different variability operators (optional, mandatory, Xor) and relationships between Base’,,, and Basery (generalization, refactoring)
Figure 5.2: Four insertions with different variability operators (optional, mandatory, Xor) and relationships between Base’,,, and Basery (generalization, refactoring)
Figure 5.3: Insertion and satifiability: the case of void feature model
Figure 5.3: Insertion and satifiability: the case of void feature model
Figure 5.5: Merging in strict union mode (fmms ®u, fmme = fmmse) and diff mode (fimms B\ fmme = fais p56)
Figure 5.5: Merging in strict union mode (fmms ®u, fmme = fmmse) and diff mode (fimms B\ fmme = fais p56)
Figure 5.6: Merging in intersection mode: (fimm3 ®@n fMma = fMm3a) An example is given in given in Figure 5.6: f7m3a (see Figure 5.6(c)) is the feature model resulting from the merge in intersection mode of fmm3 (see Figure 5.6(a)) and fimma (see Figure 5.6(b)).
Figure 5.6: Merging in intersection mode: (fimm3 ®@n fMma = fMm3a) An example is given in given in Figure 5.6: f7m3a (see Figure 5.6(c)) is the feature model resulting from the merge in intersection mode of fmm3 (see Figure 5.6(a)) and fimma (see Figure 5.6(b)).
Figure 5.7: Hierarchy and merge operations (strict union mode)
Figure 5.7: Hierarchy and merge operations (strict union mode)
Figure 6.1: Handling multiple variability inputs (e.g., for segmentation services)
Figure 6.1: Handling multiple variability inputs (e.g., for segmentation services)
Figure 6.2: Three feature models from different suppliers (adapted from [Hartmann et al. 2009]) of the set of products defined by its constituent SPLs, SPL,,5PL2,...,S5PL,. FMs are used to describe the set of products of an SPL, and thus the semantics of a multiple SPL can be defined as a relationship between the FM of the multiple SPL, FMy,,,,, and the FMs of the constituent SPLs, F.M,, FM, ..., FM,. We formally define the semantics of competing multiple SPLs below.
Figure 6.2: Three feature models from different suppliers (adapted from [Hartmann et al. 2009]) of the set of products defined by its constituent SPLs, SPL,,5PL2,...,S5PL,. FMs are used to describe the set of products of an SPL, and thus the semantics of a multiple SPL can be defined as a relationship between the FM of the multiple SPL, FMy,,,,, and the FMs of the constituent SPLs, F.M,, FM, ..., FM,. We formally define the semantics of competing multiple SPLs below.
olreusss uoyeoydde uy :f'9 ainsry
olreusss uoyeoydde uy :f'9 ainsry
Figure 6.5: Checking availability: a new feature model and suppliers’ feature model up- dates of Figure 6.2
Figure 6.5: Checking availability: a new feature model and suppliers’ feature model up- dates of Figure 6.2
Figure 6.6: Reference-based and merging techniques
Figure 6.6: Reference-based and merging techniques
Figure 7.2: feature model and its set of configurations
Figure 7.2: feature model and its set of configurations
Figure 7.3: Example of slice operations applied on the feature model of Figure. 7.2(a)
Figure 7.3: Example of slice operations applied on the feature model of Figure. 7.2(a)
Figure 7.4: Four possible feature models for the same slicing operation
Figure 7.4: Four possible feature models for the same slicing operation
Figure 7.5: Medical Imaging Service: Variability and Concerns
Figure 7.5: Medical Imaging Service: Variability and Concerns
Figure 7.7: Another decomposition strategy and set of views
Figure 7.7: Another decomposition strategy and set of views
features of fmpz and fmesoftware is not necessarily one-to-one.
features of fmpz and fmesoftware is not necessarily one-to-one.
Figure 7.9: Software and PL Variability (adapted from [Metzger et al. 2007]) is violated since some existing products of fmPL are removed in fmPLPrime and no product is added.
Figure 7.9: Software and PL Variability (adapted from [Metzger et al. 2007]) is violated since some existing products of fmPL are removed in fmPLPrime and no product is added.
Figure 7.10: Merge of three feature models, Jo, J; and I using the slicing operator
Figure 7.10: Merge of three feature models, Jo, J; and I using the slicing operator
Figure 8.1: Example of slice operations applied on the feature model of Figure. 8.1(a).
Figure 8.1: Example of slice operations applied on the feature model of Figure. 8.1(a).
Table 8.1: Merge: semantic properties and notation CHAPTER 8. A DOMAIN-SPECIFIC LANGUAGE FOR MANAGING FEATURE MODELS
Table 8.1: Merge: semantic properties and notation CHAPTER 8. A DOMAIN-SPECIFIC LANGUAGE FOR MANAGING FEATURE MODELS
Figure 8.2: Aggregated feature model using counting operations, i.e., the value of n is equal to [mi_sunion]. Aggregating feature models. Another form of composition can be applied using cross- tree constraints between features so that separated feature models are inter-related. The operator aggregate is used for producing a new feature model in which a synthetic root relates a set of feature models and integrates a set of propositional constraints.
Figure 8.2: Aggregated feature model using counting operations, i.e., the value of n is equal to [mi_sunion]. Aggregating feature models. Another form of composition can be applied using cross- tree constraints between features so that separated feature models are inter-related. The operator aggregate is used for producing a new feature model in which a synthetic root relates a set of feature models and integrates a set of propositional constraints.
We recall that in a competing multiple SPL, each constituent SPL describes a different fam- ily of products (e.g., services) in the same market segment (e.g., medical imaging domain) produced by competing suppliers (e.g., research teams). The example scenario that will be used to illustrate how FAMILIAR can be used to manage multiple SPLs is presented in Figure 8.3. The scenario involves three steps. In the first step the medical imaging ex- pert produces a feature model with no assumptions about the parts provided by external suppliers — see ©. In the next step, this family of workflow is viewed as an aggregation of 3In [Acher et al. 2011b], we have also shown how FAMILIAR can be applied using a "laptop" example.
We recall that in a competing multiple SPL, each constituent SPL describes a different fam- ily of products (e.g., services) in the same market segment (e.g., medical imaging domain) produced by competing suppliers (e.g., research teams). The example scenario that will be used to illustrate how FAMILIAR can be used to manage multiple SPLs is presented in Figure 8.3. The scenario involves three steps. In the first step the medical imaging ex- pert produces a feature model with no assumptions about the parts provided by external suppliers — see ©. In the next step, this family of workflow is viewed as an aggregation of 3In [Acher et al. 2011b], we have also shown how FAMILIAR can be applied using a "laptop" example.
Figure 8.4: Available suppliers and services. At this step, all services of original Reg can be provided by suppliers. For example, the relation holds considering the feature models depicted in Figure 8.4. Indeed, the set of configurations of original Reg is included or equal to the union of set of suppliers’ ser- vices since, according to set theory, the relation (C1) is equivalent to [originalReg] C ([Regspl_1] U | Regspl_2] U [| Regspl_3]). We check this property in line 27. Selecting Suppliers. At this point, the medical imaging expert needs to determine which suppliers can provide a subset of the services of original Reg (lines 28-40). Some suppli- ers cannot provide at least one service corresponding to any configuration of original Reg (lines 31-33) and so should not be considered. Figure 8.4 illustrates the situation: Suppliers is no longer available since the intersection between [originalReg] and [Regspl_3] is the empty set. Some suppliers offer services that correspond to a valid configuration of originalReg but also offer out-of scope services. To remove these services, a merge in intersection mode is systematically performed to restrict attention to the set of relevant supplier services (line 31). For example, the feature Multi is no longer included in the set of services of Supplier; and Supplier2 (see Regspl'_1 and Regspl'_2 in Figure 8.4) while Supplier2 is now able to deliver only one service.
Figure 8.4: Available suppliers and services. At this step, all services of original Reg can be provided by suppliers. For example, the relation holds considering the feature models depicted in Figure 8.4. Indeed, the set of configurations of original Reg is included or equal to the union of set of suppliers’ ser- vices since, according to set theory, the relation (C1) is equivalent to [originalReg] C ([Regspl_1] U | Regspl_2] U [| Regspl_3]). We check this property in line 27. Selecting Suppliers. At this point, the medical imaging expert needs to determine which suppliers can provide a subset of the services of original Reg (lines 28-40). Some suppli- ers cannot provide at least one service corresponding to any configuration of original Reg (lines 31-33) and so should not be considered. Figure 8.4 illustrates the situation: Suppliers is no longer available since the intersection between [originalReg] and [Regspl_3] is the empty set. Some suppliers offer services that correspond to a valid configuration of originalReg but also offer out-of scope services. To remove these services, a merge in intersection mode is systematically performed to restrict attention to the set of relevant supplier services (line 31). For example, the feature Multi is no longer included in the set of services of Supplier; and Supplier2 (see Regspl'_1 and Regspl'_2 in Figure 8.4) while Supplier2 is now able to deliver only one service.
Figure 9.1: Architecture of DSL processing
Figure 9.1: Architecture of DSL processing
Figure 9.3: Calculation time and space complexity (strict union merge) 132 CHAPTER 9. IMPLEMENTATION DETAILS AND PERFORMANCE EVALUATION
Figure 9.3: Calculation time and space complexity (strict union merge) 132 CHAPTER 9. IMPLEMENTATION DETAILS AND PERFORMANCE EVALUATION
Figure 10.3: Extracting variability concerns from F’ McatatogAf fineRegistratic
Figure 10.3: Extracting variability concerns from F’ McatatogAf fineRegistratic
Figure 10.4: Weaving variability concerns into services
Figure 10.4: Weaving variability concerns into services
Table 10.1: Specification and checking of constraints within the process.
Table 10.1: Specification and checking of constraints within the process.
Figure 10.5: Data compatibility between services.
Figure 10.5: Data compatibility between services.
Figure 10.7: Reasoning process: for each connected dataports in the workflow, we propa- gate variability choices within each service involved in the compatibility checking.
Figure 10.7: Reasoning process: for each connected dataports in the workflow, we propa- gate variability choices within each service involved in the compatibility checking.
Figure 10.8: An example: reiterating compatibility checking and constraints propagation.
Figure 10.8: An example: reiterating compatibility checking and constraints propagation.
Figure 10.9: Tool support and Domain-Specific Languages.
Figure 10.9: Tool support and Domain-Specific Languages.
Table 10.2: Experimental results on three scientific workflows.
Table 10.2: Experimental results on three scientific workflows.
Figure 11.1: A simplified video surveillance processing chain ~ At the implementation level, a typical VS processing chain ( Figure 11.1) starts with image acquisition, then segmentation of the acquired images, clustering, to group image regions into blobs, classification of possible objects, and tracking these objects from one frame to the other. The final steps depend on the precise task. Additional steps may be in- troduced, such as reference image updating (if segmentation steps case of multiple cameras) or even scenario recognition. All steps need it), data fusion (in correspond to software components that the designer must correctly assemble to obtain a processing chain. More- over, for each step, many variants exist, along different dimensions. For instance, there are various classification algorithms with different ranges of parameters, using different ge- ometrical models of physical objects, with different merge and split strategies to identify relevant image blobs. The situation is similar for the other algorithms.
Figure 11.1: A simplified video surveillance processing chain ~ At the implementation level, a typical VS processing chain ( Figure 11.1) starts with image acquisition, then segmentation of the acquired images, clustering, to group image regions into blobs, classification of possible objects, and tracking these objects from one frame to the other. The final steps depend on the precise task. Additional steps may be in- troduced, such as reference image updating (if segmentation steps case of multiple cameras) or even scenario recognition. All steps need it), data fusion (in correspond to software components that the designer must correctly assemble to obtain a processing chain. More- over, for each step, many variants exist, along different dimensions. For instance, there are various classification algorithms with different ranges of parameters, using different ge- ometrical models of physical objects, with different merge and split strategies to identify relevant image blobs. The situation is similar for the other algorithms.
Figure 11.2: VSAR, PFC feature models and transformation rules
Figure 11.2: VSAR, PFC feature models and transformation rules
Figure 11.3: From Requirements to Deployment and Runtime: Process
Figure 11.3: From Requirements to Deployment and Runtime: Process
Figure 11.4: An example of specialization and transformation.
Figure 11.4: An example of specialization and transformation.
Figure 12.1: An excerpt of a possible architectural feature model
Figure 12.1: An excerpt of a possible architectural feature model
Figure 12.2: Variability Modeling from Software Artifacts
Figure 12.2: Variability Modeling from Software Artifacts
feature of the extracted feature model (foot) corresponds to the main composite (root) of Arch59. The child features of f;-o.¢ are the first-level components of root, the latter being considered as the main system features. The lower-level child features are produced by the AddChildF eatures function (Algorithm 2). This recursive function looks for all the op- tional references r of component c and, for each of them, creates an optional child feature f,, itself further decomposed through a XOR or an OR group (depending on the multiplic- ity of r). The child features f., of the group correspond to all components c, providing a service compatible with r. Since the extracted architectural feature model should represent the variability of the system of interest, we focus on its extension points, typically materialized by optional ref- erences. Algorithm 1 summarizes the behavior of the feature model extractor. The root
feature of the extracted feature model (foot) corresponds to the main composite (root) of Arch59. The child features of f;-o.¢ are the first-level components of root, the latter being considered as the main system features. The lower-level child features are produced by the AddChildF eatures function (Algorithm 2). This recursive function looks for all the op- tional references r of component c and, for each of them, creates an optional child feature f,, itself further decomposed through a XOR or an OR group (depending on the multiplic- ity of r). The child features f., of the group correspond to all components c, providing a service compatible with r. Since the extracted architectural feature model should represent the variability of the system of interest, we focus on its extension points, typically materialized by optional ref- erences. Algorithm 1 summarizes the behavior of the feature model extractor. The root
Figure 12.3: Process for Extracting FM arch
Figure 12.3: Process for Extracting FM arch
Figure 12.4: Enforcing architectural FM using aggregation and slicing.
Figure 12.4: Enforcing architectural FM using aggregation and slicing.
Figure 12.5: Process for Refining FM arch 188 CHAPTER 12. REVERSE ENGINEERING ARCHITECTURAL FEATURE MODELS
Figure 12.5: Process for Refining FM arch 188 CHAPTER 12. REVERSE ENGINEERING ARCHITECTURAL FEATURE MODELS
Figure 14.1: Relationships between Models and Feature Models
Figure 14.1: Relationships between Models and Feature Models
Figure .2: Merging of feature models: a simple example Let us consider the merging of Fd, and F'M2 (see Figure .2) in strict union mode. The resulting merged feature model, F'M,., is also depicted in Figure .2. The following relation truly holds:
Figure .2: Merging of feature models: a simple example Let us consider the merging of Fd, and F'M2 (see Figure .2) in strict union mode. The resulting merged feature model, F'M,., is also depicted in Figure .2. The following relation truly holds:
Related topics:
Software EngineeringComputer VisionModel-Driven DevelopmentScientific WorkflowsDomain Specific LanguagesProgram SlicingDynamic Software AdaptationAdvanced Separation of ConcernsModel CompositionFeature Models
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved