diff --git a/assets/images/abstract_models_detailed_representations.png b/assets/images/abstract_models_detailed_representations.png new file mode 100644 index 0000000..cfae889 Binary files /dev/null and b/assets/images/abstract_models_detailed_representations.png differ diff --git a/assets/images/ac_mdsd_mde_application.png b/assets/images/ac_mdsd_mde_application.png new file mode 100644 index 0000000..d83037c Binary files /dev/null and b/assets/images/ac_mdsd_mde_application.png differ diff --git a/assets/images/ac_mdsd_problem_domain_decoupling.png b/assets/images/ac_mdsd_problem_domain_decoupling.png new file mode 100644 index 0000000..4b64062 Binary files /dev/null and b/assets/images/ac_mdsd_problem_domain_decoupling.png differ diff --git a/assets/images/application_development_domain_architecture_development.png b/assets/images/application_development_domain_architecture_development.png new file mode 100644 index 0000000..222530f Binary files /dev/null and b/assets/images/application_development_domain_architecture_development.png differ diff --git a/assets/images/cooperative_tool_development.png b/assets/images/cooperative_tool_development.png new file mode 100644 index 0000000..6b03b04 Binary files /dev/null and b/assets/images/cooperative_tool_development.png differ diff --git a/assets/images/example_feature_model.png b/assets/images/example_feature_model.png new file mode 100644 index 0000000..9b97ee8 Binary files /dev/null and b/assets/images/example_feature_model.png differ diff --git a/assets/images/feature_modeling_symbols.png b/assets/images/feature_modeling_symbols.png new file mode 100644 index 0000000..cb70041 Binary files /dev/null and b/assets/images/feature_modeling_symbols.png differ diff --git a/assets/images/negative_positive_variability.png b/assets/images/negative_positive_variability.png new file mode 100644 index 0000000..19f946e Binary files /dev/null and b/assets/images/negative_positive_variability.png differ diff --git a/assets/images/typical_mde_application.png b/assets/images/typical_mde_application.png new file mode 100644 index 0000000..2f4dc67 Binary files /dev/null and b/assets/images/typical_mde_application.png differ diff --git a/assets/images/variability_domain_application_engineering.png b/assets/images/variability_domain_application_engineering.png new file mode 100644 index 0000000..fb57198 Binary files /dev/null and b/assets/images/variability_domain_application_engineering.png differ diff --git a/bibliography.bib b/bibliography.bib index e49d1b3..8b721a0 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -659,3 +659,370 @@ @book{czarnecki1998generative year={1998}, publisher={Computer Science Department, Technical University of Ilmenau} } + +@article{despa2014comparative, + title={Comparative study on software development methodologies}, + author={Despa, Mihai Liviu}, + journal={Database Systems Journal}, + volume={5}, + number={3}, + pages={37--56}, + year={2014}, + publisher={Directory of Open Access Journals} +} + +@article{awad2005comparison, + title={A comparison between agile and traditional software development methodologies}, + author={Awad, MA}, + journal={University of Western Australia}, + year={2005} +} + +@article{svits2012comparative, + title={A Comparative Analysis of Different types of Models in Software Development Life Cycle}, + author={SVITS, IM}, + journal={International Journal}, + volume={2}, + number={5}, + year={2012} +} + +@article{davis1988strategy, + title={A strategy for comparing alternative software development life cycle models}, + author={Davis, Alan M. and Bersoff, Edward H. and Comer, Edward R.}, + journal={IEEE Transactions on software Engineering}, + volume={14}, + number={10}, + pages={1453--1461}, + year={1988}, + publisher={IEEE} +} + +@book{elliott2004global, + title={Global business information technology: an integrated systems approach}, + author={Elliott, Geoffrey}, + year={2004}, + publisher={Pearson Education} +} + +@article{ramsin2008process, + title={Process-centered review of object oriented software development methodologies}, + author={Ramsin, Raman and Paige, Richard F}, + journal={ACM Computing Surveys (CSUR)}, + volume={40}, + number={1}, + pages={3}, + year={2008}, + publisher={ACM} +} + +@article{avison2003now, + title={Where now for development methodologies?}, + author={Avison, David E and Fitzgerald, Guy}, + journal={Communications of the ACM}, + volume={46}, + number={1}, + pages={78--82}, + year={2003}, + publisher={ACM} +} + +@article{omg2017uml, + title={Unified Modeling Language (UML) 2.5.1 Specification}, + author={Object Management Group - OMG}, + journal={Final Adopted Specification (December 2017)}, + year={2017} +} + +@article{brinkkemper1996method, + title={Method engineering: engineering of information systems development methods and tools}, + author={Brinkkemper, Sjaak}, + journal={Information and software technology}, + volume={38}, + number={4}, + pages={275--280}, + year={1996}, + publisher={Elsevier} +} + +@incollection{ambler2008agile, + title={Agile software development at scale}, + author={Ambler, Scott W}, + booktitle={Balancing agility and formalism in software engineering}, + pages={1--12}, + year={2008}, + publisher={Springer} +} + +@inproceedings{guta2009lightweight, + title={A lightweight mdsd process applied in small projects}, + author={Guta, G{\'a}bor and Schreiner, Wolfgang and Draheim, Dirk}, + booktitle={Software Engineering and Advanced Applications, 2009. SEAA'09. 35th Euromicro Conference on}, + pages={255--258}, + year={2009}, + organization={IEEE} +} + +@inproceedings{madsen2010unified, + title={A unified approach to modeling and programming}, + author={Madsen, Ole Lehrmann and M{\o}ller-Pedersen, Birger}, + booktitle={International Conference on Model Driven Engineering Languages and Systems}, + pages={1--15}, + year={2010}, + organization={Springer} +} + +@article{ambler2007agile, + title={Agile Model driven development (AMDD)}, + author={Ambler, Scott W}, + journal={XOOTIC MAGAZINE, February}, + year={2007} +} + +@inproceedings{groher2007expressing, + title={Expressing feature-based variability in structural models}, + author={Groher, Iris and Voelter, Markus}, + booktitle={In Workshop on Managing Variability for Software Product Lines}, + year={2007}, + organization={Citeseer} +} + +@misc{schaefer2012software, + title={Software diversity: state of the art and perspectives}, + author={Schaefer, Ina and Rabiser, Rick and Clarke, Dave and Bettini, Lorenzo and Benavides, David and Botterweck, Goetz and Pathak, Animesh and Trujillo, Salvador and Villela, Karina}, + year={2012}, + publisher={Springer} +} + +@inproceedings{roth2015towards, + title={Towards product lining model-driven development code generators}, + author={Roth, Alexander and Rumpe, Bernhard}, + booktitle={Model-Driven Engineering and Software Development (MODELSWARD), 2015 3rd International Conference on}, + pages={539--545}, + year={2015}, + organization={IEEE} +} + +@misc{dijkstra1970notes, + title={Notes on structured programming}, + author={Dijkstra, Edsger Wybe}, + year={1970}, + publisher={Technological University Eindhoven Netherlands} +} + +@book{clements2002software, + title={Software product lines: practices and patterns}, + author={Clements, Paul and Northrop, Linda}, + volume={3}, + year={2002}, + publisher={Addison-Wesley Reading} +} + +@article{czarnecki2002domain, + title={Domain engineering}, + author={Czarnecki, Krzysztof}, + journal={Encyclopedia of Software Engineering}, + year={2002}, + publisher={Wiley Online Library} +} + +@inproceedings{bosch2001variability, + title={Variability issues in software product lines}, + author={Bosch, Jan and Florijn, Gert and Greefhorst, Danny and Kuusela, Juha and Obbink, J Henk and Pohl, Klaus}, + booktitle={International Workshop on Software Product-Family Engineering}, + pages={13--21}, + year={2001}, + organization={Springer} +} + +@phdthesis{stoiber2012new, + title={A new approach to product line engineering in model-based requirements engineering}, + author={Stoiber, Reinhard}, + year={2012}, + school={Ph. D. thesis, University of Zurich} +} + +@article{sinnema2007classifying, + title={Classifying variability modeling techniques}, + author={Sinnema, Marco and Deelstra, Sybren}, + journal={Information and Software Technology}, + volume={49}, + number={7}, + pages={717--739}, + year={2007}, + publisher={Elsevier} +} + +@inproceedings{chen2009variability, + title={Variability management in software product lines: a systematic review}, + author={Chen, Lianping and Ali Babar, Muhammad and Ali, Nour}, + booktitle={Proceedings of the 13th International Software Product Line Conference}, + pages={81--90}, + year={2009}, + organization={Carnegie Mellon University} +} + +@article{muthig2004gophone, + title={GoPhone-a software product line in the mobile phone domain}, + author={Muthig, Dirk and John, Isabel and Anastasopoulos, Michalis and Forster, Thomas and D{\"o}rr, J{\"o}rg and Schmid, Klaus}, + journal={IESE-Report No}, + volume={25}, + pages={1--104}, + year={2004}, + publisher={Citeseer} +} + +@inproceedings{schmid2011comparison, + title={A comparison of decision modeling approaches in product lines}, + author={Schmid, Klaus and Rabiser, Rick and Gr{\"u}nbacher, Paul}, + booktitle={Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems}, + pages={119--126}, + year={2011}, + organization={ACM} +} + +@inproceedings{haugen2013cvl, + title={CVL: common variability language.}, + author={Haugen, {\O}ystein and Wasowski, Andrzej and Czarnecki, Krzysztof}, + booktitle={SPLC}, + pages={277}, + year={2013} +} + +@techreport{kang1990feature, + title={Feature-oriented domain analysis (FODA) feasibility study}, + author={Kang, Kyo C and Cohen, Sholom G and Hess, James A and Novak, William E and Peterson, A Spencer}, + year={1990}, + institution={Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst} +} + +@inproceedings{batory2003tutorial, + title={A tutorial on feature oriented programming and product-lines}, + author={Batory, Don}, + booktitle={Software Engineering, 2003. Proceedings. 25th International Conference on}, + pages={753--754}, + year={2003}, + organization={IEEE} +} + +@article{czarnecki2005formalizing, + title={Formalizing cardinality-based feature models and their specialization}, + author={Czarnecki, Krzysztof and Helsen, Simon and Eisenecker, Ulrich}, + journal={Software process: Improvement and practice}, + volume={10}, + number={1}, + pages={7--29}, + year={2005}, + publisher={Wiley Online Library} +} + +@article{czarnecki2005staged, + title={Staged configuration through specialization and multilevel configuration of feature models}, + author={Czarnecki, Krzysztof and Helsen, Simon and Eisenecker, Ulrich}, + journal={Software Process: Improvement and Practice}, + volume={10}, + number={2}, + pages={143--169}, + year={2005}, + publisher={Wiley Online Library} +} + +@inproceedings{czarnecki2007feature, + title={Feature diagrams and logics: There and back again}, + author={Czarnecki, Krzysztof and Wasowski, Andrzej}, + booktitle={Software Product Line Conference, 2007. SPLC 2007. 11th International}, + pages={23--34}, + year={2007}, + organization={IEEE} +} + +@inproceedings{batory2005feature, + title={Feature models, grammars, and propositional formulas}, + author={Batory, Don}, + booktitle={International Conference on Software Product Lines}, + pages={7--20}, + year={2005}, + organization={Springer} +} + +@inproceedings{czarnecki2005mapping, + title={Mapping features to models: A template approach based on superimposed variants}, + author={Czarnecki, Krzysztof and Antkiewicz, Micha{\l}}, + booktitle={International conference on generative programming and component engineering}, + pages={422--437}, + year={2005}, + organization={Springer} +} + +@inproceedings{groher2008using, + title={Using Aspects to Model Product Line Variability.}, + author={Groher, Iris and Voelter, Markus}, + booktitle={SPLC (2)}, + pages={89--95}, + year={2008} +} + +@book{filman2004aspect, + title={Aspect-oriented software development}, + author={Filman, Robert and Elrad, Tzilla and Clarke, Siobh{\'a}n and Ak{\c{s}}it, Mehmet}, + year={2004}, + publisher={Addison-Wesley Professional} +} + +@inproceedings{constantinides2004aop, + title={AOP considered harmful}, + author={Constantinides, Constantinos and Skotiniotis, Therapon and Stoerzer, Maximilian}, + booktitle={1st European Interactive Workshop on Aspect Systems (EIWAS)}, + year={2004} +} + +@inproceedings{steimann2006paradoxical, + title={The paradoxical success of aspect-oriented programming}, + author={Steimann, Friedrich}, + booktitle={ACM Sigplan Notices}, + volume={41}, + number={10}, + pages={481--497}, + year={2006}, + organization={ACM} +} + +@inproceedings{clauss2001generic, + title={Generic modeling using UML extensions for variability}, + author={Clau{\ss}, Matthias}, + booktitle={Workshop on Domain Specific Visual Languages at OOPSLA}, + volume={2001}, + year={2001} +} + +@inproceedings{ziadi2003towards, + title={Towards a UML profile for software product lines}, + author={Ziadi, Tewfik and H{\'e}lou{\"e}t, Lo{\"\i}c and J{\'e}z{\'e}quel, Jean-Marc}, + booktitle={International Workshop on Software Product-Family Engineering}, + pages={129--139}, + year={2003}, + organization={Springer} +} + +@inproceedings{possompes2010uml, + title={A UML Profile for Feature Diagrams: Initiating a Model Driven Engineering Approach for Software Product Lines}, + author={Possomp{\`e}s, Thibaut and Dony, Christophe and Huchard, Marianne and Rey, Herv{\'e} and Tibermacine, Chouki and Vasques, Xavier}, + booktitle={Journ{\'e}e Lignes de Produits}, + pages={59--70}, + year={2010} +} + +@inproceedings{possompes2011design, + title={Design of a UML profile for feature diagrams and its tooling implementation}, + author={Possomp{\`e}s, Thibaut and Dony, Christophe and Huchard, Marianne and Tibermacine, Chouki}, + booktitle={Software Engineering \& Knowledge Engineering}, + pages={693--698}, + year={2011} +} + +@article{greifenberg2016modeling, + title={Modeling variability in template-based code generators for product line engineering}, + author={Greifenberg, Timo and M{\"u}ller, Klaus and Roth, Alexander and Rumpe, Bernhard and Schulze, Christoph and Wortmann, Andreas}, + journal={arXiv preprint arXiv:1606.02903}, + year={2016} +} diff --git a/docs/acronyms.org b/docs/acronyms.org index 874b315..8853912 100644 --- a/docs/acronyms.org +++ b/docs/acronyms.org @@ -49,7 +49,7 @@ | MT | [[id:707BD590-1E59-56B4-D333-33525E43A78A][Model Transformation]] | | OMG | Object Management Group | | OO | Object-Oriented | -| OVM | Orthogonal Variability Modeling | +| OVM | [[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][Orthogonal Variability Modeling]] | | PCL | Product Configuration Language | | PDM | Platform Description Model | | PIM | Platform Independent Model | diff --git a/docs/mde_and_the_software_development_process.org b/docs/mde_and_the_software_development_process.org new file mode 100644 index 0000000..cd96b2c --- /dev/null +++ b/docs/mde_and_the_software_development_process.org @@ -0,0 +1,387 @@ +:properties: +:id: E5EA2B40-5526-0E44-B6D3-8F817E21C984 +:end: +#+title: MDE and the Software Development Process +#+options: <:nil c:nil todo:nil ^:nil d:nil date:nil author:nil toc:nil html-postamble:nil +#+startup: inlineimages +#+cite_export: csl +#+bibliography: ../bibliography.bib + +/[[id:11F938FF-2A01-4424-DBE3-16527251E747][Back to home page]]/ + +#+begin_quote +One of the more controversial concepts in Agile Modeling is that agile models +and agile documents are sufficient for the task at hand, or as I like to say +they are "just barely good enough". For some reason people think that just +barely good enough implies that the artifact isn't very good, when in fact +nothing could be further from the truth. When you stop and think about it, if an +artifact is just barely good enough then by definition it is at the most +effective point that it could possibly be at. --- Ambler [cite:@ambler2007agile] +#+end_quote + +[[id:C29C6088-B396-A404-9183-09FE5AD2D105][Model Driven Engineering]] is deeply intertwined with the software development +lifecycle; and the shape of the software development lifecycle is a function of +the prevailing [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][Software Development Methodology (SDM)]].[fn:sdlc] The present +document provides and overview of this complex relationship, pointing out +implications of this interleaving. [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] and related processes have themselves +been treated extensively in the software engineering literature, including +numerous comparative studies and surveys [cite:@despa2014comparative] +[cite:@awad2005comparison] [cite:@svits2012comparative] +[cite:@davis1988strategy] [cite:@estefan2007survey]. In the interest of +maintaining focus, the objective of the present section is not to perform an +exhaustive review across this vast field but to: a) supply a set of conceptual +building blocks to be used within our research; and b) to investigate the +relationship between [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] and [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s --- including a characterisation of the +general challenges posed by [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] to the development process and vice-versa. + +The document is organised as follows. It begins by defining more precisely what +is meant by an [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] (Section [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][Software Development Methodologies]]). We then attempt +to determine if [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] has a "preference" towards certain types of [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s on Section +"[[id:9A171CD4-61C9-07E4-8D63-221C63B374B5][Iterative or Structured?]]". The document concludes by looking at /[[id:CA10BF3B-5F12-D0B4-5C4B-32E4B0B87BBC][two-track +development]]/, an approach commonly employed when in the presence of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]. + +[fn:sdlc] A distinction has been preserved in this document between the +"software development lifecycle" and "SDLC (Software Development Life-Cycle)". +The SDLC is considered a [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] by many authors such as Elliot +[cite:@elliott2004global] (p. 86-87), who calls it the "oldest formalised +methodology for building information systems". He states (/emphasis his/): + +#+begin_quote +The traditional approach to information systems development was known as the +/waterfall/ approach or /systems development life cycle/ approach --- the SDLC +approach. [...] This methodology pursues the development of information systems +in a very deliberate, structured and methodical way, requiring each stage of the +life cycle, from inception of the idea to the delivery of the final system, to +be carried out rigidly and sequentially." +#+end_quote + +Conversely, this document employs "software development lifecycle" in a more +informal manner, meaning /any/ lifecycle model --- often a property of the +underlying [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]. For those interested in a more rigorous approach, Estefan /et +al./ [cite:@estefan2007survey] provide a detailed discussion on the subject, +defining these and other related terms. In particular, see Section 2 --- +"Differentiating Methodologies from Processes, Methods, and Lifecycle Models". + + +* Software Development Methodologies + :properties: + :id: 8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A + :custom_id: ID-8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A + :roam_aliases: SDM + :end: + +[[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s have had a important role to play in the development of software systems +from as early as the 1960's [cite:@elliott2004global] (p. 86). According to +Ramsin and Paige, "[an] [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] is a framework for applying software engineering +practices with the specific aim of providing the necessary means for developing +software-intensive systems." [cite:@ramsin2008process] For their part, Avison +and Fitzgerald see it as "a recommended collection of phases, procedures, rules, +techniques, tools, documentation, management, and training used to develop a +system." [cite:@avison2003now] Based on their analysis of earlier work, +including that of OMG [cite:@omg2017uml], as well as Avison and Fitzgerald +themselves [cite:@avison2003now], Ramsin and Paige decomposed an [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] into three +main parts: + +- *Philosophy*: a set of assumptions and beliefs made by the authors of the + methodology, as part of its motivation or with the intent of supporting and + rationalising it. +- *Modeling conventions*: a set of modeling conventions designed to work + together as a modeling language. Within this dissertation, we choose to + interpret /modeling language/ in the sense defined by [[id:C807836B-B1D6-1024-86E3-7D49BCF20D74][Models and + Transformations]] --- though perhaps Ramsin and Paige's intention is to use the + term in a less formal manner. +- *Processes*: a set of processes that provide guidance as to the activities to + take place, their order, the role played by different actors in those + activities and ways in which to monitor and evaluate the results of performing + them. + +Within this framework, the modeling language contains the vocabulary with which +to model aspects of the development of the system, the processes cater for the +temporal characteristics of how entities interact --- /i.e./ /who/ performs what +activities /when/ --- and the philosophy supplies a overarching narrative that +harmonises and justifies both. These three components come together as a +/methodology/, providing a unified perspective from which to accomplish +prescribed objectives.[fn:methodology_term] Therefore, an [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] can be thought of +as an /abstraction/ that orchestrates activities related to the development of +software systems; and does so with the objective of making them easier to +understand for all involved. + +[fn:methodology_term] There are those like as Brinkkemper +[cite:@brinkkemper1996method] who vehemently disagree with how software +engineers employ the terms /method/ and /methodology/. Though the points +presented by Brinkkemper and others are valid, we have decided to remain aligned +with the traditional software engineering usage, given that the meaning is now +widely understood amongst practitioners. See also Estefan /et al./ +[cite:@estefan2007survey] for a thorough discussion of these and related terms. + + +It is difficult to overestimate the importance of [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s in modern software +development. Ramsin and Paige [cite:@ramsin2008process] go as far as considering +them an enabler of the software engineering discipline /itself/ (/emphasis +ours/): + +#+begin_quote +Software development methodologies are therefore considered an integral part of +the software engineering discipline, since methodologies provide /the means for +timely and orderly execution/ of the various finer-grained techniques and +methods of software engineering. +#+end_quote + +Whilst [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s exact importance may be argued, what should nonetheless be clear +from this exposition is that their organisational properties are simultaneously +orthogonal and complementary to the characteristics of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] described thus far. +It is for this reason that we sided earlier on with those that argue that [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] +/by itself/ cannot be considered a methodology, but methodologies can be +developed with model-driven characteristics for particular purposes. Asadi and +Ramsin [cite:@asadi2008mda] tackled this subject in an MDA context, but +presented an argument which, in our opinion, is directly applicable to [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] +(/emphasis ours/): + +#+begin_quote +[...] /MDA is not a methodology/, but rather an approach to software +development. This fact forces organizations willing to adopt the MDA to either +transform their software development methodologies into Model-Driven Development +(MDD) methodologies, or use new methodologies that utilize MDA principles and +tools towards the realization of MDA standards. +#+end_quote + +It is for this reason that one finds numerous examples of model-driven +methodologies in the literature, with differing characteristics +[cite:@matinnejad2011agile] [cite:@ambler2008agile] [cite:@ambler2007agile] +[cite:@guta2009lightweight] [cite:@estefan2007survey]. However, rather than +delve into the specifics of each of these, the more pertinent question --- at +least for the purposes of this dissertation --- is to determine whether [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] +/demands/ a particular type of software development methodology, or has no +sensitivity to it. + +* Iterative or Structured? + :properties: + :id: 9A171CD4-61C9-07E4-8D63-221C63B374B5 + :custom_id: 9A171CD4-61C9-07E4-8D63-221C63B374B5 + :end: + +The literature reveals a range of views with regards to the relationship between +[[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] and [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]. Ambler appears to suggest [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] is more amenable to a structured +environment, declaring that (/emphasis ours/) "MDD is an approach to software +development where extensive models are created /before/ source code is written. +With traditional MDD a serial approach to development is often taken where +comprehensive models are created early in the lifecycle." +[cite:@ambler2008agile] Stahl /et al./ are instead of the view that [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] +requires, by its very nature, an iterative process: + +#+begin_quote +The iterative, dual-track process of [[id:7FCC54A3-D2C3-0254-1C0B-103976AA8D87][MDSD]] [...], in which the infrastructure is +developed in parallel to the application(s), must be clearly distinguished from +traditional waterfall methods that are based on a 'big design up-front' +philosophy. [cite:@volter2013model] (p. 375) +#+end_quote + +Unfortunately, the disagreement may stem, at least in part, from imprecise +definitions rather than due to profound ideological differences. + +A third view, and one which we align ourselves with, is that of Brambilia /et +al./, who declare [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] to be /process-agnostic/, claiming "it neither provides +nor enforces any specific development process but it can be integrated in any of +them." [cite:@brambilla2012model] (p. 53) To be clear, Brambilia /et al./ are +not suggesting that [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] does not have a significant impact on a project's +software development methodology and vice-versa. Instead, their argument is that +the principles in the [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] body of knowledge are compatible with /all/ [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] --- +"traditional development processes" in their parlance --- and the onus is +therefore on the [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] practitioner to unify them into a whole, for any particular +application. + +These integration efforts are not insignificant, so the literature has been +active in developing specific strategies --- especially for iterative +methodologies [cite:@matinnejad2011agile] [cite:@ambler2008agile] +[cite:@ambler2007agile] [cite:@guta2009lightweight]. It is also important to +understand that this stance does not have any implications with regards to the +merits (or demerits) of structured versus iterative development methodologies, +as these can be analysed independently of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]. However, since models "are +considered equal to code" [cite:@volter2013model] and, somewhat more arguably, +since "programming is a modeling activity" [cite:@madsen2010unified], it is not +surprising that many of the engineering practices that foster the development of +high-quality code are equally desirable when the engineering is driven by +modeling. + +It is then for these reasons that iterative methodologies should be preferred to +structured methodologies, rather than due to any intrinsic property or +requirement of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]. The idea can be neatly summarised with the following dictum: +"what is good for code is (generally) also good for models". Nonetheless, +regardless of whether the approach is iterative or structured, there are +specific factors related to model-driven software engineering that must be +catered for, as the next section will explain. + +* Two-Track Development + :properties: + :id: CA10BF3B-5F12-D0B4-5C4B-32E4B0B87BBC + :custom_id: CA10BF3B-5F12-D0B4-5C4B-32E4B0B87BBC + :end: + +One of the most striking differences between traditional software development +and the model-driven approach is the additional work required to develop the +modeling infrastructure --- that which Stahl /et al./ call the /domain +architecture/ [cite:@volter2013model] (p. 253); /i.e./ the set of modeling +languages and their associated [[id:707BD590-1E59-56B4-D333-33525E43A78A][MT]]s, as well as the platforms upon which they +depend on, in order to translate a set of instance models into a software +system. The development of the domain architecture poses a challenge which +straddles theory and application because there is a circular dependency between +exploring problem and solution spaces /and/ creating the vocabulary with which +to perform that exploration. + +Stahl /et al./ tackled the issue by proposing a two-track development process, +composed of the following +threads:[fn:two_track_stahl]^{,}[fn:analysis_simplicity] + +[fn:two_track_stahl] Interestingly, Stahl /et al./ first introduce the approach +in the context of AC-MDSD [cite:@volter2013model] (p. 21) but later on +generalise it to make it widely applicable to [[id:7FCC54A3-D2C3-0254-1C0B-103976AA8D87][MDSD]] [cite:@volter2013model] +(Chapter 13, p. 253). + +[fn:analysis_simplicity] For simplicity, we are not making the customary Domain +Engineering separation between analysis and development (/cf./ Section FIXME +ssec:sple). We do so partially because we take the iterative approach --- fusing +development and analysis together --- but also because we believe the same +argument applies to analysis and development. + + +- *Domain Architecture Development Thread*: Responsible for developing all of + the modeling infrastructure that makes up the domain architecture. Abstracts + and generalises the requirements produced by the application thread into + infrastructure that can be reused for a number of similar applications. +- *Application Development Thread*: Concerned with producing a concrete product + to satisfy the requirements of end users. Provides exemplars of needed + functionality to the domain architecture development thread to help shape its + direction and consumes the tooling it produces to implement the product. + +#+caption[Two-track development.]: Two-track development. /Source/: Author's drawing based on Stahl /et al./'s image [cite:@volter2013model] (p. 262). +#+name: fig-application_development_domain_architecture_development +#+attr_latex: :scale 0.3 +[[../assets/images/application_development_domain_architecture_development.png]] + +The relationship between these two threads is illustrated in Figure +[[fig-application_development_domain_architecture_development]]. Two-track +development is very useful as an idealised model because the approach evokes a +clear separation of concerns. Nonetheless, our own personal experience has +taught us that matters are not quite as clear cut in practice. On one hand, the +basic principles are very easy to convey to experienced engineering teams --- +even where [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] knowledge is lacking. On the other hand, many dangers +lie in wait of a naïve application: + +- the before-mentioned circular nature of the problem is extremely challenging + --- and never more so than during the initial stages of development; +- the development of the domain architecture ultimately demands a + /multidisciplinary skill-set/, entailing both good software engineering skills + as well as a mastery of the [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] cannon; +- there is great difficulty in demonstrating to management the need for + continued investment in domain architecture development and maintenance as the + project reaches maturity, and the lack of investment has severe consequences + for the long term; +- there is a great difficulty in avoiding a disconnect between domain and + architecture development teams, and there are far-reaching repercussions when + such a disconnect occurs. + +The last factor is of great importance because it may lead to a phenomena we +named /problem domain decoupling/, and which happens as the disconnect grows in +size. In our opinion, this problem manifests itself more evidently with the +application of AC-MDSD, but we do not believe it is solely limited to this use +case. Figure [[fig-ac_mdsd_problem_domain_decoupling]] illustrates the issue by +looking at four hypothetical /scenarios/ covering the application of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] to +infrastructural code, which we shall now enunciate. + +#+caption: Problem domain decoupling. +#+name: fig-ac_mdsd_problem_domain_decoupling +#+attr_latex: :scale 0.3 +[[../assets/images/ac_mdsd_problem_domain_decoupling.png]] + +Scenario 1 typically happens at the first brush with [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]], where developers +create a solution hard-wired to the core problem domain they are exploring, and +is closely related to our own personal experiences [cite:@marco_craveiro_2021]. +From Scenario 2 to Scenario 4 there is a quest for /generalisation/, accompanied +by a corresponding /growth in scope/ of the infrastructure problem domain. +Scenario 2 represents a small decoupling of the infrastructure domain to make it +useful to more than one product, though still fairly hard-wired. With Scenario 3 +we are now looking at providing infrastructure for a larger grouping of software +products and their diverse needs, with a resulting ballooning in infrastructural +scope. Finally, with Scenario 4, the infrastructure domain becomes a product on +its own right, much larger than any one core problem domain; at this stage we +are now considering products supplied by external vendors rather than in-house +development. + +The /quantitative change/ in the size of the infrastructure problem domain +produces /qualitative changes/ that may not be readily apparent to engineers, as +they develop a system with a dual-track approach. This /phase transition/ is +particularly problematic as one transitions from Scenario 1 through to +Scenario 3. Let us perform a comparison between these two scenarios at the [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]] +level to better understand the problem. Figure [[fig-typical_mde_application]] +illustrates the /state of the world/ for Scenario 1 via a two-track approach; +the bold arched arrows represent the understanding of the problem as it +materialises onto the domain and application development tracks and the dashed +line represents the /synchronisation points/ between the two tracks. Though not +obvious, the most noteworthy aspect of this diagram is the /natural alignment/ +between the two tracks and the problem domain. + +#+caption: Typical [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] application. +#+name: fig-typical_mde_application +#+attr_latex: :scale 0.3 +[[../assets/images/typical_mde_application.png]] + +This property is made clearer by performing a similar exercise for Scenario 3, +as does Figure [[fig-ac_mdsd_mde_application]]. Even without a detailed analysis, it +should be noticeable that the picture becomes /considerably more complex/; the +previous natural alignment now gives way to a far more intricate set of +relationships --- many of which bidirectional. The figure depicts the separation +between the infrastructure problem domain and the /core/ problem domain, and the +effect each of these have on each other as the exploration of both domains takes +place. In hindsight, the increase in complexity should not be surprising +because, as the scope of the infrastructural domain grows, it becomes a software +product in its own right. Thus, there is an attempt to simultaneously engineer +/two tightly interlocked/ software products, each already a non-trivial entity +to start off with. + +#+caption: [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] application with AC-MDSD. +#+name: fig-ac_mdsd_mde_application +#+attr_latex: :scale 0.2 +[[../assets/images/ac_mdsd_mde_application.png]] + +At this juncture one may consider the ideal solution to be the use of vendor +products as a way to insulate the problem domains. Unfortunately, experimental +evidence emphatically says otherwise, revealing that isolation may be necessary +/but only up to a point/, beyond which it starts to become detrimental. We name +this problem /over-generalisation/. In our opinion, what is lacking is the /deep +synchronisation/ needed between the two development tracks --- an ingredient +that Stahl /et al./ had already identified as being crucial to the success of +the entire endeavour. On the other hand, adoption literature shows that this +close collaboration can be found in abundance within in-house development, but +there we suffer from the opposite problem of /under-generalisation/. That is, +solutions are /too specific/, catering only for internal use cases. + +What is called for is a highly cooperative relationship between infrastructure +developers and end-users, in order to foster feature suitability --- a +relationship which is not directly aligned with traditional customer-supplier +roles; but one which must also maintain a clear separation of roles and +responsibilities --- not the strong point of relationships between internal +teams within a single organisation, striving towards a fixed goal. Any proposed +approach must therefore aim to establish an /adequate/ level of generalisation +by mediating between these actors and their diverse and often conflicting +agendas. We named this generalisation sweet-spot /barely general enough/, +following on from Ambler's footsteps [cite:@ambler2007agile][fn:barely_general], +and created Figure [[fig-cooperative-tool-development]] to place the dilemma in +diagrammatic form. + +[fn:barely_general] Ambler states that (/emphasis ours/) "[...] if an artifact +is just /barely good enough/ then by definition it is at the most effective +point that it could possibly be at." [cite:@ambler2007agile] + + +#+caption: Different approaches to infrastructure development. +#+name: fig-cooperative-tool-development +#+attr_latex: :scale 0.3 +[[../assets/images/cooperative_tool_development.png]] + +and now that the need for the generalisation has been made clear, we must change +our focus towards the machinery needed to implement it. and, at this juncture, +the /management of variability/ takes centre stage. + +* bibliography + +#+print_bibliography: diff --git a/docs/mde_and_variability_modeling.org b/docs/mde_and_variability_modeling.org new file mode 100644 index 0000000..c305c11 --- /dev/null +++ b/docs/mde_and_variability_modeling.org @@ -0,0 +1,488 @@ +:properties: +:id: 3DD5C3FF-5BC2-F8A4-2A6B-4F037A78D8E6 +:end: +#+title: MDE and Variability Modeling +#+options: <:nil c:nil todo:nil ^:nil d:nil date:nil author:nil toc:nil html-postamble:nil +#+startup: inlineimages +#+cite_export: csl +#+bibliography: ../bibliography.bib + +/[[id:11F938FF-2A01-4424-DBE3-16527251E747][Back to home page]]/ + +#+begin_quote +Despite their crucial importance, features are rarely modularized and there is +only little support for incremental variation of feature functionality. --- +Groher and Völter [cite:@groher2007expressing] +#+end_quote + +The employment of model-driven techniques for the engineering of software +systems is often accompanied by a shift in focus from /individual/ software +products to /groups/ of products with similar characteristics. This may happen +tacitly --- because the modeling process reveals these commonalities as +abstractions (/cf./ [[id:7D92A620-ED3E-D264-46A3-2A2597C59DC7][Why Model?]]) and good software engineering practices such as +modularity and reuse create the conditions for their sharing across products --- +or by explicit design. + +Whichever its origins, this type of engineering presents challenges of a +/different kind/, as Stahl /et al./ note: + +#+begin_quote +[...] [[id:7FCC54A3-D2C3-0254-1C0B-103976AA8D87][MDSD]] often takes place not only as part of developing an entire +application, but in the context of creating entire product lines and software +system families. These possess very specific architectural requirements of their +own that the architects must address. [cite:@volter2013model] (p. 5) +#+end_quote + +Thus, much stands to be gained by making the approach systematic, an aim often +achieved in the literature by recourse to software diversity techniques such as +variability modeling.[fn:software_diversity] + +The chapter is organised as follows. Section [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][Software Product Line Engineering]] +introduces the notion of /product lines/ and connects it to domain engineering. +Variability proper is then tackled ([[id:C9E5C482-E37B-AF14-4E3B-4FF92BB86C50][Variability Management and Variability +Models]]), followed by a brief introduction on feature modeling ([[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][Feature +Modeling]]). The chapter then concludes with Section [[id:7D780B3E-2821-2674-8F4B-AE29097B739D][Integrating Feature Modeling +with MDE]], where feature modeling is then integrated with [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]. + +[fn:software_diversity] For a comprehensive analysis on the state of the art in +software diversity, see Schaefer /et al./ [cite:@schaefer2012software]. There, +they defined software diversity as follows: "In today’s software systems, +typically different system variants are developed simultaneously to address a +wide range of application contexts or customer requirements. This variation is +referred to as software diversity." + + +* Software Product Line Engineering + :properties: + :id: C1172AEA-F94B-73D4-FDAB-A105D7FEA389 + :custom_id: ID-C1172AEA-F94B-73D4-FDAB-A105D7FEA389 + :roam_aliases: SPLE + :end: + +The idea of abstracting commonalities between sets of programs has had a long +history within computer science, starting as early as the 1970s with Dijkstra's +notion of /program families/.[fn:program_families] A modern and systematised +embodiment of Dijkstra's original insights can be found in [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][SPLE]] +[cite:@pohl2005software] [cite:@clements2002software], which is of particular +significance to the present work because its principles and techniques are often +employed in an [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] context [cite:@groher2007expressing] [cite:@roth2015towards] +[cite:@groher2009aspect]. + +[fn:program_families] In [cite:@dijkstra1970notes], Dijkstra states: "If a +program has to exist in two different versions, I would rather not regard (the +text of) the one program as a modification of (the text of) the other. It would +be much more attractive if the two different programs could, in some sense or +another, be viewed as, say, different children from a common ancestor, where the +ancestor represents a more or less abstract program, embodying what the two +versions have in common." + + +Pohl /et al./ define [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][SPLE]] as "a paradigm to develop software applications +(software-intensive systems and software products) using platforms and mass +customization." [cite:@pohl2005software] Roth and Rumpe add that "SPLE focuses +on identifying commonalities and variability (the ability to change or customize +a system in a predefined way) to create components that are used to develop +software products for an area of application." [cite:@roth2015towards] + +The mechanics of [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][SPLE]] bring to mind Stahl /et al./'s dual track process (/cf./ +[[id:CA10BF3B-5F12-D0B4-5C4B-32E4B0B87BBC][Two-Track Development]]), in that /Domain Engineering/ is used to create a set of +/core assets/ and /Application Engineering/ is applied to those core assets in +order to develop a family of related products, called a /product line/ or a +system family.[fn:domain_engineering] In this light, Domain Engineering defines +the variation space available to all products within the product line, opening +up possibilities in terms of variability, whereas the role of Application +Engineering is to create specific /configurations/ or /variants/ for each +product, reducing or eliminating variability. Figure +[[fig-variability_domain_application_engineering]] illustrates this idea. + +[fn:domain_engineering] In Czarnecki's words (/emphasis his/) +[cite:@czarnecki2002domain]: + +#+begin_quote +/Domain engineering/ (DE) is the systematic process of collecting, organizing, +and storing past experience in building systems in a particular domain. This +experience is captured in the form of reusable assets (/i.e./, reusable work +products), such as documents, patterns, reusable models, components, generators, +and domain-specific languages. An additional goal of DE is to provide an +infrastructure for reusing these assets (/e.g./, retrieval, qualification, +dissemination, adaptation, and assembly) during application engineering, /i.e./, +the process of building new systems. [...] Similar to the traditional +single-system software engineering, DE also encompasses the three main process +components of analysis, design, and implementation. In this context, however, +they are referred to as /domain analysis/, /domain design/, and /domain +implementation/." +#+end_quote + + +#+caption[Variability management in time.]: Variability management in time. /Source/: Author's drawing based on Bosch /et al./'s image [cite:@bosch2001variability] +#+name: fig-variability_domain_application_engineering +#+attr_latex: :scale 0.3 +[[../assets/images/variability_domain_application_engineering.png]] + +The importance of managing variability within [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][SPLE]] cannot be overstated, nor can +the challenges of its management, as Groher and Völter make clear (/emphasis +ours/): "The effectiveness of a software product line approach directly depends +on /how well feature variability within the portfolio is managed/ from early +analysis to implementation and through maintenance and evolution." +[cite:@groher2007expressing] The central question is then how to integrate a +model-driven approach with the management of variability. + +* Variability Management and Variability Models + :properties: + :id: C9E5C482-E37B-AF14-4E3B-4FF92BB86C50 + :custom_id: ID-C9E5C482-E37B-AF14-4E3B-4FF92BB86C50 + :end: + +Like the /program families/ described in the previous section, variation itself +has long been a going concern in software development; but, traditionally, it +has been handled by programmatic means via techniques such as configuration +files, design patterns, frameworks and polymorphism --- that is, at a low-level +of abstraction --- and scattered across engineering +artefacts.[fn:inadequate_variability_modeling] [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][SPLE]] promotes instead /explicit +variability management/, which Groher and Völter define as "the activity +concerned with identifying, designing, implementing, and tracing flexibility in +software product lines (SPLs)." [cite:@groher2007expressing] The idea is to +promote variability to a first-class citizen within the engineering process. + +[fn:inadequate_variability_modeling] Czarnecki denounced this historically +"inadequate modeling of variability", stating that "[the] only kind of +variability modeled in current OOA/D is intra-application variability, /e.g./ +variability of certain objects over time and the use of different variants of an +object at different locations within an application." + + +A variability management approach that resonates particularly with [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] is +/variability modeling/ --- that is, the use of [[id:1D15099E-7294-6724-3343-A6C71CB05BF9][DSL]] designed for expressing +variability --- for much the same reasons [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] promotes model use in general +(/cf./ [[id:7D92A620-ED3E-D264-46A3-2A2597C59DC7][Why Model?]]). Stoiber puts variability modeling in context: + +#+begin_quote +[[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][SPLE]] allows maximizing the reuse of commonality (/i.e./, by developing all +products on a common product platform) and of variability (/i.e./, by a more +modular development of variable functionality that can be added to or removed +from the product more easily). This requires a variability model, though, to +support an efficient specification and development of both the software product +line as a whole and of individual application products. [cite:@stoiber2012new] +#+end_quote + +The benefits alluded to by Stoiber are more clearly identified by Czarnecki, +who, in [cite:@czarnecki1998generative] (p. 68), sees three main advantages +resulting from the explicit modeling of variability: + +- *Variability Abstraction*: By having a model of variability across the system + --- "a more abstract representation", in Czarnecki's words --- it is now + possible to reason about it independently of implementation mechanisms, which + facilitates the work of Domain Engineering. +- *Variability Documentation*: From the perspective of Application Engineering, + the variability space is made explicit and concise, therefore simplifying + decisions around use and reuse. +- *Variability Traceability*: Engineers can also have a better understanding of + the inclusion or exclusion of functionality because the variability model can + answer those questions independently of the implementation. + +These benefits help explain the abundance of variability modeling languages and +notations in the literature, including AND/OR Tables [cite:@muthig2004gophone], +Decision Modeling [cite:@schmid2011comparison], OVM (Orthogonal Variability +Modeling) [cite:@pohl2005software], the CVL (Common Variability Language) +[cite:@haugen2013cvl] and many others. A survey of all of these approaches lies +beyond the scope of our work, given our needs --- which only makes use of a set +of high-level concepts in the variability domain --- so we shall focus instead +on only one approach: /feature modeling/.[fn:chen_variability] + +[fn:chen_variability] The interested reader is directed to Chen /et al./'s +[cite:@chen2009variability] systematic literature review of 34 approaches to +variability management, which also provides a chronological background. In +addition, Sinnema and Deelstra [cite:@sinnema2007classifying] authored a broad +overview of the field, including surveys of [[id:1D15099E-7294-6724-3343-A6C71CB05BF9][DSL]] and tooling, as well +as performing a detailed analysis of six variability modeling approaches. + + +* Feature Modeling + :properties: + :id: 76DC5C70-AAC0-86A4-3EEB-4187367002BA + :custom_id: ID-76DC5C70-AAC0-86A4-3EEB-4187367002BA + :roam_aliases: SPLE + :end: + +Feature modeling was originally introduced by Kang /et al./'s work on FODA +(Feature-Oriented Domain Analysis) [cite:@kang1990feature] and subsequently +extended by Czarnecki and Eisenecker [cite:@czarnecki2000generative], amongst +many others.[fn:feature_orientation] As the name indicates, the concept central +to their approach is the /feature/, which Groher and Völter define in the +following manner: "[products] usually differ by the set of features they include +in order to fulfill /(sic.)/ customer requirements. A feature is defined as an +increment in functionality provided by one or more members of a product line." +[cite:@groher2009aspect] Features are thus are associated with product lines --- +each feature a cohesive unit of functionality with distinguishable +characteristics relevant to a stakeholder[fn:stakeholder] --- and the interplay +between features then becomes /itself/ a major source of variability, as Groher +and Völter go on to explain: "Variability of features often has widespread +impact on multiple artifacts in multiple lifecycle stages, making it a +pre-dominant (/sic./) engineering challenge in software product line +engineering." + +[fn:feature_orientation] Feature orientation attracted interest even outside the +traditional modeling community, giving rise to approaches such as FOP +(Feature-Oriented Programming), which is "[...] the study of feature modularity +and programming models that support feature modularity." +[cite:@batory2003tutorial] + +[fn:stakeholder] Note that we use the term /stakeholder/ rather than customer or +end user, taking the same view as Czarnecki /et al./ +[cite:@czarnecki2005formalizing] (/emphasis ours/): "[...] we allow features +with respect to /any stakeholder/, including customers, analysts, architects, +developers, system administrators, etc. Consequently, a feature may denote /any/ +functional or non-functional characteristic at the requirements, architectural, +component, platform, or any other level." + + +#+caption[Symbols used in cardinality-based feature modeling.]: Symbols used in cardinality-based feature modeling. /Source:/ Author's drawing, based on Czarnecki and Helsen [cite:@czarnecki2006feature] +#+name: tab-cardinality_fm +#+attr_latex: :scale 0.3 +[[../assets/images/feature_modeling_symbols.png]] + +Features and their relationships are captured by /feature diagrams/ and /feature +models/, as Czarnecki /et al./ tell us [cite:@czarnecki2005formalizing]: "A +feature diagram is a tree of features with the root representing a concept +(/e.g./, a software system). Feature models are feature diagrams plus additional +information such as feature descriptions, binding times, priorities, +stakeholders, /etc./" Feature diagrams have found widespread use in the +literature since their introduction, resulting on the emergence of several +different extensions and variations.[fn:feature_variations] For the purposes of +the present chapter we shall make use of cardinality-based feature models, as +described by Czarnecki /et al./ in [cite:@czarnecki2005formalizing] and whose +notation Figure [[tab-cardinality_fm]] summarises. + +[fn:feature_variations] An in-depth analysis of these variants would take too +far afield with regards to the scope of the present work. The interested reader +is directed to Czarnecki /et al./ [cite:@czarnecki2005staged], Section 2.2 +(Summary of Existing Extensions), where a conceptual analysis of the main +variants is provided. + + +The notation is perhaps made clearer by means of an example (Figure [[tab-car_fm]]), +which builds on from the example in [[id:1405A531-73F5-E094-04A3-F08451EC02BC][Metamodelling Hierarchy]]. The top-most node +of the feature diagram (/i.e./ =Car=) is called the /root feature/. Nodes +=Body=, =Engine=, =Gear= and =Licence Plate= describe mandatory features whereas +node =Keyless Entry= describes an optional feature. =Engine= contains a set of +grouped features that are part of a /xor-group/, whereas =Gear= contains a set +of features in a /or-group/. Or-groups differ from xor-groups in that they +require that at least one feature from the group needs to be selected whereas +xor-groups allow one and only one feature to be selected. + +#+caption[Sample feature model.]: Sample feature model. /Source:/ Author's drawing, modified from a Czarnecki and Wasowski diagram [cite:@czarnecki2007feature]. +#+name: tab-car_fm +#+attr_latex: :scale 0.3 +[[../assets/images/example_feature_model.png]] + +Feature diagrams have the significant property of being trivially convertible +into Boolean logic formulas or to a CNF (Conjunctive Normal Form) +representation, making them amenable to solving using established solvers such +as BDD (Binary Decision Diagram) [cite:@czarnecki2007feature] and SAT +[cite:@batory2005feature]. + +Importantly, feature modeling also has known shortcomings, and these were +considered during our review of the literature. Most significant were those +identified by Pohl /et al./ [cite:@pohl2005software], namely that feature models +mix the modeling of features with the modeling of variability and do not provide +a way to segment features by intended destinatary --- /i.e./ it is not possible +to distinguish between features meant for internal purposes from those meant for +end-users. With OVM, Pohl /et al./ propose instead a decomposition of +responsibilities. Clearly, there is validity to their concerns, as demonstrated +by the fact that concepts that OVM brought into attention such as /variation +points/ --- "delayed design decision[s]" [cite:@bosch2001variability] that +"[...] allow us to provide alternative implementations of functional or +non-functional features" as well as documentation --- are now commonly used in +the literature, even in the context of feature modeling. Nonetheless, since +features provide an adequate level of granularity for our needs, we need not +concern ourselves with Pohl /et al./'s criticism. We do, however, require a +clearer pictured of the relationship between feature models and the kinds of +models that are typically found within acrshort:mde. + +* Integrating Feature Modeling with MDE + :properties: + :id: 7D780B3E-2821-2674-8F4B-AE29097B739D + :custom_id: ID-7D780B3E-2821-2674-8F4B-AE29097B739D + :end: + +The crux of the problem is then on how to integrate ACRshortpl:mde modeling +techniques with variability management --- or, more specifically for our +purposes, with feature modeling. Clearly, having a feature model simply as a +stand-alone artefact, entirely disconnected from the remaining engineering +activities is just a form of acrshort:mbe, as Czarnecki and Antkiewicz explain +(/emphasis ours/): "Although a feature model can represent commonalities and +variabilities in a very concise taxonomic form, /features in a feature model are +merely symbols/. Mapping features to other models, such as behavioral or data +specifications, gives them semantics." [cite:@czarnecki2005mapping] + +Therefore, the availability of concise and interlinked representations of +variability across models is a prerequisite to attain this semantically rich +view of features. For their part, Groher and Völter argue that integrating +variability directly within models has important advantages: "[...] due to the +fact that models are more abstract and hence less detailed than code, +variability on model level is inherently less scattered and therefore simpler to +manage." [cite:@groher2008using] (/cf./ Figure +[[fig-abstract_models_detailed_representations]]). + +#+caption[ Mapping abstract models to detailed representations.]: Mapping abstract models to detailed representations. /Source:/ Author's drawing from Groher and Völter's image [cite:@groher2008using] +#+name: fig-abstract_models_detailed_representations +#+attr_latex: :scale 0.3 +[[../assets/images/abstract_models_detailed_representations.png]] + +Whilst delving into the conceptual machinery of this integration, Groher and +Völter [cite:@groher2007expressing] [cite:@groher2009aspect] analysed the types +of variability found in models and proposed dividing it into two kinds, +/structural/ and /non-structural/, defined as follows: "Structural variability +is described using creative construction DSLs, whereas non-structural +variability can be described using configuration languages." We name these two +kinds /input variability/ since they reflect variation within the input models. +In their view, the feature model becomes a metamodel for the product +line[fn:feature_model_as_meta_model], and their instances are the configuration +models for products, with the final aim being to "[...] use a configuration +model to define variants of a structural model." According to them, these +variants can be generated in two ways: + +[fn:feature_model_as_meta_model] A view that aligns well with Czarnecki /et +al./'s idea of a feature model as the description of the set of all possible +valid configurations within a system family [cite:@czarnecki2005formalizing]. + + +- *Positive Variability*: The assembly of the variant starts with a small core, + and additional parts are added depending on the presence or absence of + features in the configuration model. The core contains parts of the model that + are used by all products in the product line. +- *Negative Variability*: The assembly process starts by first manually building + the "overall" model with all features selected. Features are then removed + based on their absence from the configuration model. + +Since these two types of variability are related to generation, we classify them +as /generational variability/. Figure [[fig-negative_positive_variability]] +illustrates these two techniques, applied to sample features =A=, =B= and =C=. + +#+caption[Positive and negative variability techniques.]: Positive and negative variability techniques. /Source:/ Author's drawing based on images from Groher and Völter [cite:@groher2009aspect] +#+name: fig-negative_positive_variability +#+attr_latex: :scale 0.3 +[[../assets/images/negative_positive_variability.png]] + +Given the cross-cutting nature of feature related concerns, Groher and Völter +proposed using AOP (Aspect Oriented Programming) [cite:@filman2004aspect] +techniques to implement positive and negative variability, to which they gave +the perhaps overly-descriptive name of AO-MD-PLE (Aspect-Oriented Model Driven +PLE). AO-MD-PLE has the advantage of considering all stages of software +engineering, from problem space to solution space, including models, +transformations (both [[id:93400D0B-2E1E-7244-D07B-DD8BCA98277A][M2M]] and [[id:93400D0B-2E1E-7244-D07B-DD8BCA98277A][M2T]]) and manually crafted code. In our opinion, +its main downside is complexity, not only due to challenges inherent to AOP +itself [cite:@constantinides2004aop] [cite:@steimann2006paradoxical], but also +because it uses several different tools to implement the described functionality +and, understandably, requires changes at all levels of the stack. + +Undertakings of a less ambitious nature are also present in the literature. The +simplest approach is arguably to integrate variability modeling directly with +UML via a UML Profile, as suggested by Clauß's early work +[cite:@clauss2001generic], which focused on concepts such as variation points +and variants. Ziadi /et al./ [cite:@ziadi2003towards] build on from this idea, +expanding the focus to product line concepts. More recently, in +[cite:@possompes2010uml] [cite:@possompes2011design], Thibaut /et al./ created a +UML Profile for feature modeling concepts. Extending acrshort:uml is +advantageous due to its universal nature, but alas, it also inherits all of the +challenges associated with the modeling suite. + +Others have looked elsewhere. In [cite:@czarnecki2005mapping], Czarnecki and +Antkiewicz propose a template-based approach to map feature models to different +kinds of models. There, they outline a technique of /superimposed variants/, in +which a /model template/ is associated with a feature model to form a /model +family/. The model template is written in the [[id:1D15099E-7294-6724-3343-A6C71CB05BF9][DSL]] of the target model, and can +be thought of as a superset of all possible models, containing model elements +that are associated with features by means of /presence conditions/. Model +templates can be instantiated given a feature configuration: "The instantiation +process is a model-to-model transformation with both the input and output +expressed in the target notation." The approach is reminiscent of Groher and +Völter's positive variability, in that the template provides the overall model +and [[id:707BD590-1E59-56B4-D333-33525E43A78A][MT]] are then responsible for pruning unwanted model elements on the basis of +the evaluation of presence conditions. + +An interesting feature of superimposed variants are IPC (Implicit Presence +Conditions): + +#+begin_quote +When an element has not been explicitly assigned a PC by the user, an implicit +PC (IPC) is assumed. In general, assuming a PC of true is a simple choice which +is mostly adequate in practice; however, sometimes a more useful IPC for an +element of a given type can be provided based on the presence conditions of +other elements and the syntax and semantics of the target notation. +#+end_quote + +IPC facilitate the job of the modeler because they infer relationships between +features and model elements based on a deep understanding of the underlying +modeling language. For example, if two UML model elements are linked by an +association and each element has a presence condition, a possible IPC is to +remove both modeling elements if either of their presence conditions evaluates +to false. Overall, Czarnecki and Antkiewicz's approach is extremely promising, +as demonstrated by their prototype implementation, but in our opinion it hinges +largely on the availability of good tooling. Asking individual [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] practitioners +to extend their tools to support superimposed variants is not feasible due to +the engineering effort required. + +As part of our review of the literature we also investigated the application of +variability management techniques to code generators. In +[cite:@roth2015towards], Roth and Rumpe motivate the need for the application of +product line engineering techniques to code generation. Their paper provides a +set of conceptual mechanisms to facilitate the product-lining of code +generators, and outlines a useful set of requirements: "The main requirements +for a code generator product line infrastructure are support for incremental +code generation, specification of code generator component interfaces, support +for validation of generated code, and support for individual semantics of a +composition operator." + +For their part, Greifenberg /et al./ [cite:@greifenberg2016modeling] reflected +on the role of code generators within [[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][SPLE]] --- particularly those that are +implemented as product lines /themselves/: "[...] a code generator product is a +SPL on its own, since it generates a variety of software products that are +similar, and thus shares generator components potentially in different +variants". Their work also introduces the concept of /variability regions/: + +#+begin_quote +Variability regions (VRs) provide a template language independent approach to +apply concepts of FOP to code generators. A VR represents an explicitly +designated region in an artifact that has to be uniquely addressable by an +appropriate signature. +#+end_quote + +Variability regions are accompanied by two [[id:1D15099E-7294-6724-3343-A6C71CB05BF9][DSL]]: LDL (Layer Definition Language) +and PCL (Product Configuration Language). The LDL is used to define +relationships between variability regions, whereas the PCL defines individual +configurations to instantiate variants. Variability regions and their modeling +is certainly an interesting idea, but it is somewhat unfortunate that +Greifenberg /et al./ did not link them back to feature models or to higher-level +modeling in general. + +Finally, Jörges' [cite:@jorges2013construction] take on code generation, +modeling and product lines is arguably the most comprehensive of all those +analysed, given he advocates the development of code generators that take into +account variant management and product lines as one of its core requirements +[cite:@jorges2013construction] (p. 8). /Genesys/, the approach put forward by +Jörges in his dissertation, hinges on a service-oriented approach to the +construction and evolution of code generators, anchored on the basis of models: +"Both models and services are reusable and thus form a growing repository for +the fast creation and evolution of code generators." + +Unfortunately, there were several disadvantages with his approach with regards +to own purposes; namely, the reliance on a graphical notation for the design of +code generators and, more significantly, the tool-specific nature of Genesys +which cannot be considered outside of jABC.[fn:jabc] As we have seen, these are +in direct conflict with our own views on fitting with existing developer +workflows rather than imposing new ones. Nonetheless, Jörges' work was very +influential to our own, and we've carried across several features of his +argument such as a clear outline of a set of requirements in order to guide the +model-driven solution. + +[fn:jabc] As per Jörges' [cite:@jorges2013construction] (p. 43): "jABC is a +highly customizable Java-based framework that realizes the tenets of XMDD +[Extreme Model-Driven Development] [...] jABC provides a tool that allows users +to graphically develop systems in a behavior-oriented manner by means of models +called Service Logic Graphs (SLGs)." + + +* bibliography + +#+print_bibliography: diff --git a/docs/models_and_transformations.org b/docs/models_and_transformations.org index 1616f13..6513a2e 100644 --- a/docs/models_and_transformations.org +++ b/docs/models_and_transformations.org @@ -240,8 +240,7 @@ exception: it too must conform to a /metametamodel/. The metametamodel provides a generalised way to talk about metamodels and exists at a layer above that of the metamodel. Though in theory infinite, the layering process is typically curtailed at the metametamodel layer, since it is possible to create a -metametamodel that conforms to -itself.[fn:reflexive_metamodel],[fn:metalevels] +metametamodel that conforms to itself.[fn:reflexive_metamodel],[fn:metalevels] #+caption[OMG four-layer metamodel architecture]: OMG four-layer metamodel architecture. /Source/: Author's drawing based on a diagram by Bézivin [cite:@bezivin2004search]. #+name: fig-metamodel_archecture @@ -344,6 +343,7 @@ operations performed on models have become key to the modeling approach. :properties: :id: 707BD590-1E59-56B4-D333-33525E43A78A :custom_id: ID-707BD590-1E59-56B4-D333-33525E43A78A + :roam_aliases: MT :end: The second most significant component of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] , after models, are Model @@ -371,6 +371,7 @@ only type of [[id:707BD590-1E59-56B4-D333-33525E43A78A][MT]] found in the litera :properties: :id: 93400D0B-2E1E-7244-D07B-DD8BCA98277A :custom_id: ID-93400D0B-2E1E-7244-D07B-DD8BCA98277A + :roam_aliases: M2M M2T :end: The taxonomy of [[id:707BD590-1E59-56B4-D333-33525E43A78A][MT]] has been investigated in great detail in the literature, @@ -465,6 +466,7 @@ with traditional programming languages. :properties: :id: 1D15099E-7294-6724-3343-A6C71CB05BF9 :custom_id: ID-1D15099E-7294-6724-3343-A6C71CB05BF9 + :roam_aliases: GPML DSL :end: The literature commonly distinguishes between two classes of modeling languages, @@ -526,8 +528,8 @@ Engineering (MBE). :end: One of the first decisions faced by practitioners when when modeling a problem -is the choice between using GPML or DSL. Mohagheghi and -Aagedal's analysis highlights the kinds of trade-offs that must be considered +is the choice between using GPML or DSL. Mohagheghi and Aagedal's analysis +highlights the kinds of trade-offs that must be considered [cite:@mohagheghi2007evaluating]: #+begin_quote diff --git a/docs/towards_a_definition_of_mde.org b/docs/towards_a_definition_of_mde.org index 322ecb7..c522973 100644 --- a/docs/towards_a_definition_of_mde.org +++ b/docs/towards_a_definition_of_mde.org @@ -64,8 +64,7 @@ models/.[fn:translation], [fn:nature_of_model] author. The reader is advised to consult the primary source. [fn:nature_of_model] The nature of models within [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]], as well as that of -transformations, is analysed in greater detail on FIXME Chapter -models-transformations. +transformations, is analysed in greater detail in [[id:C807836B-B1D6-1024-86E3-7D49BCF20D74][Models and Transformations]]. On the other hand, formal definitions are found wanting. To make matters worse, @@ -109,8 +108,8 @@ the term paradigm altogether; and, whilst agreeing with the notion of [[id:C29C6 The matter does not rest here, though, for there are additional viewpoints that must be taken into account when attempting to characterise [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]. -[fn:mde_as_methodology] This matter is argued further on Section FIXME -soft-methodology, where we address the relationship between [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] and the software +[fn:mde_as_methodology] This matter is argued further in [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][Software Development +Methodologies]], where we address the relationship between [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] and the software development process, and articulate a stronger argument as to why [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] should not be considered to be a methodology. Furthermore, we also provide additional context on software development methodologies. @@ -152,6 +151,7 @@ structure. :properties: :id: 79EC741E-8818-3494-8B1B-2B27C182B160 :custom_id: ID-79EC741E-8818-3494-8B1B-2B27C182B160 + :roam_aliases: MBE MDD :end: One common method of overlaying structure into [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] is by way of classifying the @@ -216,6 +216,7 @@ role: they are at least as important as source code." [cite:@volter2013model] :PROPERTIES: :id: 7FCC54A3-D2C3-0254-1C0B-103976AA8D87 :custom_id: ID-7FCC54A3-D2C3-0254-1C0B-103976AA8D87 + :roam_aliases: MDSE MDSD MD* MIC MOP MBSE "MDE Variant" :end: Matters are further complicated by the existence of a number of additional @@ -275,9 +276,9 @@ Our review of the literature did not uncover any adequate solutions to this thorny problem. Though by no means authoritative, our approach was to include in the present analysis all of the concepts that are relevant to our purposes and to use the notion of /integrations/ where the concepts are more obviously -external to [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] --- /e.g./, "Agile integration" (/cf./ Part FIXME integrations). -But all the difficulties discussed thus far point out there may be a deeper -malaise with the discipline itself. +external to [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] --- /e.g./, "Agile integration" (/cf./ [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][Software Development +Methodologies]]). But all the difficulties discussed thus far point out there may +be a deeper malaise with the discipline itself. * Pragmatism in a Fuzzy Discipline :PROPERTIES: @@ -310,10 +311,9 @@ to it as the /Pragmatism Principle/, albeit restated in a slightly different form:[fn:pragmatism] [fn:pragmatism] The term /pragmatism/ was chosen as an allusion to one of -Stachowiak's fundamental model properties (/cf./ Section FIXME why model) -because we see [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] /as a model too/. Alas, a detailed discussion of the topic -would take us too far afield, befitting the philosophy of modeling in software -development. +Stachowiak's fundamental model properties (/cf./ [[id:7D92A620-ED3E-D264-46A3-2A2597C59DC7][Why Model?]]) because we see [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] +/as a model too/. Alas, a detailed discussion of the topic would take us too far +afield, befitting the philosophy of modeling in software development. #+begin_quote @@ -360,12 +360,12 @@ requiring a /high-level of mastery/ of a large and complex cannon.[fn:when_to_model] [fn:when_to_model] Take the decision to use modeling in the first place. Whilst -the enumeration of choices presented in Section FIXME modeling-approach appears -to convey simplicity, experience says otherwise. In order to make an informed -decision, one must first master /both/ the theory of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] /as well as/ the thorny -practical aspects of its application, and these only reveal themselves when -applied to a /sufficiently large/ project during /sufficiently long/ timescales ---- as we ourselves discovered. +the enumeration of choices presented in [[id:774F10EF-88EA-8054-A5E3-FB2FBCACA2D2][Determining the Modeling Approach]] +appears to convey simplicity, experience says otherwise. In order to make an +informed decision, one must first master /both/ the theory of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] /as well as/ +the thorny practical aspects of its application, and these only reveal +themselves when applied to a /sufficiently large/ project during /sufficiently +long/ timescales --- as we ourselves discovered. At this juncture we can now sketch out our understanding of the discipline, @@ -376,8 +376,8 @@ which is as follows: - [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] promotes the /[[id:EF8AB73B-F189-7AE4-CD4B-9713E34AC63E][pragmatic]] application/ of a /family of related approaches/ to the development of software systems, with the intent of /generating automatically/ a part or the totality of a software product, from one or more - /formal models/ and associated /transformations/ (/cf./ Section FIXME - models-transformations). + /formal models/ and associated /transformations/ (/cf./ [[id:C807836B-B1D6-1024-86E3-7D49BCF20D74][Models and + Transformations]]). - [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] is best understood as a /vision/ rather than a /concrete destination/. A vision /guides/ the general direction of the approach, but does not dictate the solution, nor does it outline the series of steps required to reach diff --git a/index.org b/index.org index 5a70873..efecc89 100644 --- a/index.org +++ b/index.org @@ -43,12 +43,14 @@ Academic Papers]]. MASD is based on [[id:C29C6088-B396-A404-9183-09FE5AD2D105][Model Driven Engineering (MDE)]], so its important to understand the basic concepts of this field and why we found it necessary to extend it. -| Page | Description | -|--------------------------------------+----------------------------------------------------------------------------| -| [[id:4B0DC013-F222-5BB4-33DB-C53414604801][Acronyms]] | List of commonly used TLAs. | -| [[id:C29C6088-B396-A404-9183-09FE5AD2D105][Towards a Definition of (MDE)]] | Exploration of the literature towards attaining a definition of this term. | -| [[id:C807836B-B1D6-1024-86E3-7D49BCF20D74][Models and Transformations]] | Definition of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]'s core concepts, and rationale for their usage. | -| [[id:CA232302-65F9-6DE4-AD4B-6D24EE3E9D39][From Problem Space to Solution Space]] | Characterisation of problem space and solution space. | +| Page | Description | +|------------------------------------------+----------------------------------------------------------------------------| +| [[id:4B0DC013-F222-5BB4-33DB-C53414604801][Acronyms]] | List of commonly used TLAs. | +| [[id:C29C6088-B396-A404-9183-09FE5AD2D105][Towards a Definition of (MDE)]] | Exploration of the literature towards attaining a definition of this term. | +| [[id:C807836B-B1D6-1024-86E3-7D49BCF20D74][Models and Transformations]] | Definition of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]]'s core concepts, and rationale for their usage. | +| [[id:CA232302-65F9-6DE4-AD4B-6D24EE3E9D39][From Problem Space to Solution Space]] | Characterisation of problem space and solution space. | +| [[id:E5EA2B40-5526-0E44-B6D3-8F817E21C984][MDE and the Software Development Process]] | How [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] integrates with [[id:8E4D171C-1FAE-FA74-0EA3-97F1125B8A2A][SDM]]s. | +| [[id:3DD5C3FF-5BC2-F8A4-2A6B-4F037A78D8E6][MDE and Variability Modeling]] | How [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] integrates with variability modeling approaches. | ** Models