Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie
¾
Domain Models and Product Lines
¾
Prof Dr U Aßmann
¾
Prof. Dr. U. Aßmann
¾
Technische Universität Dresden
¾
Institut für Software- und Multimediatechnik
¾
Gruppe Softwaretechnologie
Object-Oriented Analysis vs Object-Oriented Design
requirements specification t t l textual requirements (stories) analysis model business model analysis model domain domain model use cases architectural designExtended to Model-Driven Architecture (MDA)
requirements specification textual specification requirements (stories) business model analysis model (CIM) analysis model domain d l use cases Platform independent d l model model Platform-1 specific model Platform-(1,.., n) specific modelAdding Platform-Specific Extensions to Platform-Independent Models
Platform-1 specific t i (PSE) Platform independent
d l (PIM) extension (PSE) model (PIM) Model weaving Platform-1 specific model (PSM) Platform-2 specific extension (PSE) Model Model weaving
Feature Models
¾
From product configuration to product instantiation
¾
Feature models are used to express
variability in Product Lines
¾
alternative,
¾
mandatory,
¾
optional features, and
p
,
¾
their relations
¾
A variant model represents a concrete product from the
product line
product line
Feature Models
¾
Feature Tree Notation
Concept
Concept
Group of
Mandatory
Optional
Group of
Group of
Alternative Features
Mandatory
Feature
Group of
OR Features
Optional
Feature
FeatureA
FeatureB
FeatureC
FeatureD
PhD Thesis, Czarnecki (1998)
Beispiel
¾
A1 und A2 und A3
¾
B1; B2 xor B3
;
¾
B1; optional B3
¾
B1; B2
A1
A2
A3
A1
A2
A3
[c1]
[1]
Ein Featuremodell für computergestützte
kognitive Reha
¾
[K. Lehmann, Diplomarbeit]
FM FM K J E S CE CU NO NM . . . A/K gE gZ IS IT T A IS IT gE gZ T A gE gZ IS IT T A gE gZ IS IT T A [1-2] [1-2] [1-2] [1-2] K J E S CE CU NO NM . . . gE T A IS IT [c1] T A [c1] gE gZ IS IT T A [c1] IS IT T A [c1] IS IT IS IT [1-2] [1-2] [1-2] [1-2] [1 2] [1 2] [1-2] [1 2]Mapping Features to Model Fragments (Model Snippets)
¾
Bridging the gap between configuration and solution space
¾
Need for mapping of features from feature models to artefacts of
the solution space
¾
Possible artefacts
¾
Models defined in DSLs
¾
Model fragments (snippets)
¾
Architectural artefacts (components, connectors, aspects)
¾
Source code
¾
Source code
¾
Files
¾
B t ho can e achie e the mapping ?
¾
Different Approaches of Variant Selection
¾
Additive approach of modelling the variant space
¾
Map all features to model fragments (model snippets) and
compose them with a core model based on the presence of the
feature in the variant model
feature in the variant model
¾
Pros:
¾
conflicting variants can be modelled correctly
¾
strong per-feature decomposition
¾
strong per feature decomposition
¾
Cons:
¾
traceability problems
¾
increased overhead in linking the different fragments
¾
increased overhead in linking the different fragments
¾
Different Approaches of Variant Selection (2)
¾
Subtractive approach of modelling the variant space
¾
Model all features in one model and remove elements based on
absence of the feature in the variant model
¾
Pros:
¾
no need for redundant links between artifacts
¾
short cognitive distance
¾
Cons:
¾
conflicting variants can't be modelled correctly
A Process Architecture for PLE
¾
Chose one variant on each level
¾
Feature Tree als Input für die Varianten-Steuereingaben
¾
Feature Tree als Input für die Varianten Steuereingaben
A Process Architecture for PLE
¾
Goal: a staged MDSD-framework for PLE where each stage
A Process Architecture for PLE
¾
Characteristic feature 1:
¾
Variability on each stage
¾
A Process Architecture for PLE
¾
Characteristic feature 2:
¾
different modelling languages, component systems and
¾
different modelling languages, component systems and
A Process Architecture for PLE
¾
Characteristic feature 3:
¾
different composition mechanisms per stage
A Process Architecture for PLE
¾
Characteristic feature 4:
¾
composition mechanisms are driven by variant selection
Mapping Features to Models (2)
¾
FeatureMapper - a tool for mapping features to modelling artefacts
developed at the ST Group
¾
Screencast and paper available at
http://featuremapper.org
¾
Advantages:
¾
Advantages:
¾
Configuration of large product lines from selection of variants in feature trees
¾
Customers understand
¾
Consistency of each product in the line is simple to check
y
p
p
Einbau von Ontologien In Produktlinien
Domain Model
¾
Als Design-Constraints, als Produkt-Constraints, als Domänenmodell
Domain Model
(Domain ontology)
Configuration
Constraints
(FeatureModel)
Analysis Model
Design
Constraints
(
)
Variants
Variants
Product Line Design Model
(Framework)
Design
Variants
P d t D i
M d l
Product
Constraints
Variants
Product Design Model
Variants
¾
Eine Ontologie als Ober-Modell
Teacher Teaching ontology Company
Student Course Business ontology Analysis model extensions Teacher Company Course Exercise extensions Teacher Student Company Course teaches() Part Exam attends() countStudents() Consultance PayedCourse Teacher getSalary() book() Exercise Solution FreeCourse Teacher beg() lookup() Student PayedCourse pay() getSalary() payCourse() Student FreeCourse donate() beg() payCourse() p y() ()
Finding a Place for Domain Ontologies in the
Model-Driven Architecture
History of This Work
¾
Invited Paper on „Ontologies, Metamodels, and the
Model-Driven Paradigm“
g
¾
for Handbook on „Ontologies in Software Engineering“ 2006 (Ruiz, Calero)
¾
Uwe Aßmann, Steffen Zschaler, TU Dresden
¾
Gerd Wagner, BTU Cottbus
¾
Gerd Wagner, BTU Cottbus
¾
How do ontologies and system models relate?
¾
Ontology
¾
M t
d l
¾
Metamodels
¾
Model-Driven Engineering (MDE)
¾
Model-Driven Architecture (MDA)
The IRDS/MOF Metamodelling Hierarchy
Metamodelling concepts¾
aka
metapyramid
M3 metametamodel Metamodelling concepts M4 level = M3 validInstanceOf describes level Modelling concepts MOF, UML-core, OWL, AG, NSvalidInstanceOf describes
M2 metamodel level
Language descriptions OWL, UML, CWM,ER Of
M1 model level Types, programs, models domain ontologies validInstanceOf describes Software objects domain ontologies model instances validInstanceOf describes Software objects
describing world objects M0 Object level
The MDA Embedded in the IRDS Metapyramid
M3 metametamodel
level
Modelling concepts
MOF
MetaMetamodels
M2 metamodel
level
CIM-MM
PIM-MM
Language specifications
<<instance-of>>PSM-MM
Metamodels
(languages)
<<instance-of>>M1 model level
CIM
PIM
PSM
Models
Instance specifications
Models vs Ontologies
¾
How can we find a place for ontologies in the world of MDA?
A model is an external and explicit representation of a part of reality as seen by the
people who wish to use that model to understand, change, manage, and control that
part of reality [Pidd]
A model of a system is a description or specifiation of that system and its environment for some
t i
[MDA G id ]
part of reality. [Pidd]
certain purpose. [MDA Guide]
Ontologies are formal explicit specifications of a shared conceptualization.[Gruber]
Usually....
O o og es a e o
a e p c spec ca o s o a s a ed co cep ua a o [G ube ]
but....
Models vs Ontologies – A Big Difference
Description or Control
A model can be descriptive
or prescriptive.
[Seidewitz CACM 03]
A model can be descriptive
or prescriptive.
[Seidewitz CACM 03]
Models describe or control reality.
If they describe they monitor reality and form true or faithful abstractions (Analysis Reengineering)
[Seidewitz CACM 03]
[Seidewitz CACM 03]
If they describe, they monitor reality and form true, or faithful, abstractions (Analysis, Reengineering)
If they control, they prescribe reality (Construction, Specification)
►
Ontologies need the
open-world
assumption
A l i
ti
►
System models need
closed-world
assumption
Design perspective
■
Analysis perspective
■
Anything not explicitly expressed
is unknown
■
Design perspective
■
Anything not explicitly expressed
is wrong
■
Ontologies use a form of partial
description to abstract
Analysis with Ontologies,
Specification with System Models
An
ontology:
a standardized
A
system model:
a non-standardized
a standardized,
descriptive model,
representing reality
b
t f
t th i
a non standardized,
prescriptive model,
representing a set of systems
b
t f
t th i
by a set of concepts, their
interrelations, and constraints
under
open-world assumption.
by a set of concepts, their
interrelations, and constraints
under
closed-world assumption.
What to Do with What
¾
With Closed World Assumption (Reasoning)
¾
Querying
¾
needs CWA to exclude erroneous data
¾
Metamodeling:
¾
needs CWA to exclude erroneous programs
¾
Integrity constraints
¾
needs CWA to exclude erroneous models
¾
With Open World Assumption
¾
Domain modeling
Integration with a Universal Metalanguage
Analysis Problem Domain Descriptive Design Solution Domain Prescriptive (Specifications) M3 metametamodellevel Universal CWA Ontology
Metamodeling language M2 metamodel level Metamodels <<instance-of>> <<instance-of>> level
Upper ontologies Metamodels
(languages, language concepts)
M1 model level Domain ontologies
Models <<instance-of>> <<is-a>>
Software objects M0 object level Real world objects
<<instance-of>> <<described-by>>
Software objects M0 object level Real world objects
Embedding Ontologies into the IRDS Metapyramid and MDA
Analysis Problem Domain Descriptive Design Solution Domain Prescriptive (Specifications) M3 metametamodel level Metametamodels (specification concepts) M2 metamodel level U t l i CIM RM MM <<instance-of>> <<instance-of>>Upper ontologies CIM-RM-MM
PIM-MM
PSM-MM <<described-by>>
M1 model level Domain ontologies CIM-DO
PIM
PSM CIM-RM
CIM-BO
<<instance-of>>
Conclusions
¾
Ontologies are advantageous in PLE for
¾
domain ontologies
¾
integrity constraint ontologies in product lines
¾
but...
¾
Ontologies should not be misused as system models
g
y
¾
Ontologies
complement
system models
¾
Ontologies in OWA for domain modeling, CWA for the rest
¾
Integration technology and tools needed!
¾
Integration technology and tools needed!
¾
MOST project (Marrying Ontologies and Software Technology)
