Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Model Oriented Domain Analysis - Industrialized Software Specifications


Published on

Published in: Technology
  • Be the first to comment

Model Oriented Domain Analysis - Industrialized Software Specifications

  1. 1. Model Oriented Domain Analysis industrialized software specifications The First International Workshop on Domain Engineering 9 June 2009 @ CAiSE Amsterdam, The Netherlands
  2. 2. The challenges • Those who have been disillusioned by UML and those who are not yet disillusioned by UML • Those who have discovered the power of model driven generation in the last five years ★ focus on amount of code generated, not quality ★ low quality input specifications (models, config files, ...) ★ ignorance of best practices for modelling language design ★ some of the same people sold objects as a silver-bullet in the 90s ... • Love affair of software professionals with complexity & technologies • Underestimating the value of true domain expertise 2 Model Driven Software Product Line Engineering
  3. 3. The process-driven organization B 12 A 13 L 14 L 15 B 1 6 L U 7 8 E F 10 A 11 S 13 T 14 H 2 A 5 6 L O 9 C 10 A 11 R 15 19 I O 20 N 21 1 T 3 E 4 V 16 A 17 C 18 T workflow steps = the ritual that works, more or less ... 3 The problem
  4. 4. Weaknesses of workflow-centric requirements analysis • Which areas of knowledge are required to run a specific business? • Can all knowledge be documented in the form of a process? • Is the role of software limited to supporting/enforcing a process? • Where are the use cases that elaborate configurability? • Is there a clear distinction between using and producing applications? • Are humans really working by following sequential processes? • What is a suitable notation for describing work products (artefacts)? 4 Observations
  5. 5. Process outputs B A L L B L U E F A S T H A L O C A R I O N T E V A C T artefact components 5 Where is the bigger picture?
  6. 6. Local semantics of process output B A L L B L U E F A S T H A L O C A R I O N T E V A C T artefacts at different levels 6 Modularity and granularity of artefacts matters a lot
  7. 7. Global semantics of process output B A L L B L U E F A S T H A L O C A R I O N T E V A C T semantics across levels => understanding the purpose of the business 7 The bigger picture requires deeper analysis
  8. 8. work products / artefacts A1 A2 A3 B1 B2 B3 A areas of knowledge B 8 Manifestation of knowledge
  9. 9. Solving the minor issues is easy • If the overlap between two disciplines is large, the common denominator can be treated as a distinct discipline • As a result, some artefacts belong to this new discipline • Disciplines are best described by associating them with corresponding role names A1 A C C1=A2 B3 B areas of knowledge 9 Minor issues
  10. 10. Solving the real problems • Overlapping artefacts need to be replaced with non-overlapping artefacts • Disentangling the overlap comes down to investigating decision making processes that occur when applying knowledge: ★ Who makes a decision? ★ When is the decision made? ★ Where (in which artefact) is the decision made? ★ What are the possible choices? ★ What heuristics apply? ★ How often does a decision require revision? 10 The heart of domain analysis
  11. 11. Think of artefact definitions as language definitions • The quality of the terminology is of paramount importance ★ familiarity, precision, low risk of misinterpretation • For production use, the tool used to create/maintain artefact instances needs to have “product” quality - usability is king • The language should be quite stable over time, but each sentence is different • If sentences contain obvious patterns in content (not grammar), then the level of abstraction can be raised further (and the sentences become shorter and simpler) • The objective is clear and unambiguous communication between domains! 11 Raising the importance of domain knowledge
  12. 12. Language design cheat sheet 12 Breaking down complexity into manageable modules
  13. 13. Examples of real-world use case steps • Instantiation links are not always as simple as OO theory suggests ... under-specified instance of the VWGolf product line nearly fully-specified instance only here the instance is fully-specified 13 Partial, incremental instantiation is common in product lines
  14. 14. Use cases vs. meta modelling? • If deep domain expertise is available: ★ Start with the definition of meta models ★ Validate meta models with a sufficient number of sample models ★ Validate the domain terminology by using it to write use cases for modelling language users ★ Validate modelling languages and sample models by using them to generate a working implementation • If deep domain expertise is lacking: ★ Start with writing use cases to identify candidate domain terminology ★ Validate use cases by manually developing a first implementation ★ Use a second and third implementation to incrementally identify patterns, and use MODA to distill first meta models 14 How to start depends on the domain
  15. 15. Modelling languages differ from coding languages Observation: Given that in the context of software the term coding is often used interchangeably with programming, it is instructive to compare the dictionary definitions of to code and to model to understand the not-so-subtle difference in intent: • to code: express (a statement or communication) in an indirect or euphemistic way • to model: devise a representation, especially a mathematical one of (a phenomenon or system) Coding can be viewed as having to deal with someone else’s representation (program notation or otherwise). This is exactly what happens when we work with third party implementation technologies and when mapping to such technologies in a template language. Modelling can be viewed as dealing with a representation that is fit for purpose. This is what happens when we capture knowlegde in a domain specific language that is grounded in established domain terminology. 15 Terminology matters much more than technology
  16. 16. Separation of concerns 1 1 1 * Domain Language Artefact Problem language artefacts Space 1 1 * 1 language element 1 element value sub domains * 1 * reference code segments Reference code segment 1 Pattern Control * * Template Glue Implementation 1 implementation Logic Statement Variable pattern * usage pattern instance 1 logical sequence 1 implementation technology * target language text part Solution Framework or Space Syntactic Sugar Component Code Template 16 Language Engineering
  17. 17. Today’s platforms are defined relative to the user Application Web Service Operating System Hardware Platform Abstraction Abstraction Abstraction Commoditized Technologies Value Added Applications Era 2010 1990 1970 Application Web Enterprise Embedded Development Apps Apps Apps 1,000s < 10 < 50 Paradigm shift: of relevant relevant relevant One person’s application frameworks operating systems processor families is the next person’s platform! 17 Increasingly higher levels of abstraction
  18. 18. 1. Achieving and preserving modularity in-the-large Web Service Operating System Hardware Abstraction Abstraction Abstraction In popular implementation languages (Java, C#) modularity constructs are second class citiziens ... Modularity 18 Qualities that are only scalable when using models
  19. 19. 2. Clear separation of application & platform Web Service Operating System Hardware Abstraction Abstraction Abstraction Frameworks break the clean separation of the problem space from the solution space Separation of Apps & Platform 19 Qualities that are only scalable when using models
  20. 20. 3. Systematic exploitation of commoditized technologies Web Service Operating System Hardware Abstraction Abstraction Abstraction Configuring open source frameworks mostly requires a certain level of knowlegde about the solution space Strategic use of Open Source 20 Qualities that are only scalable when using models
  21. 21. Best Practices for Modelling Language Design (1) 1. A domain is partitioned into well-defined areas of knowledge, each of which relates to exactly one role 2. All artefacts (work products) are based on information produced by a specific role as a result of capturing a specific kind of knowledge or requirements 3. A modelling language is developed for each kind of instantiable artefact (leading to modular meta models) 4. The meta model of a modelling language has exactly one root node that relates to the modeled artefact 5. Variants of artefacts are expressed as extensions of a common root 6. Artefacts are the only granularity at which versioning is applied 21 From conventions to tool features
  22. 22. Best Practices for Modelling Language Design (2) 7. Artefacts can only be edited by one user at a time 8. An explicit modularization mechanism is required within a modelling language (leading to modular models) 9. No limit on the number of meta levels (instantiation levels), meta models are models that define the instantiation semantics (including structure and constraints) for a group of models 10. Two meta models may be joined via references between concepts in both meta models 11. No circular or bi-directional dependencies between meta models 12. The set of models associated with a meta model is recorded as part of the meta model artefact or via a reference to the meta model within each model artefact 22 From conventions to tool features
  23. 23. One little language for each kind of artefact 1. In this example the modelling languages are much more domain specific than a general purpose feature modelling language 2. Sometimes a general purpose feature modelling language is a good fit - but even then it is not necessarily the “leading dimension” for modularizing the domain 23 Example of a domain supply chain: Hardware device networks
  24. 24. Best Practices for Modelling Language Design (1) 1. A Meta Model is partitioned into well-defined .ecore files, each of which relates to exactly one producer role, and one or more consumer roles. A Model is partitioned into well-defined .xmi files, each of which relates to exactly one producer role, and one or more consumer roles. 2. All .ecore and .xmi files are based on information produced by a specific role as a result of articulating or clarifying specific knowledge or requirements. 3. A modelling language is developed for each kind of model based Artefact. Adhering to this principle in Ecore relies 4. The .ecore file that defines the Abstract Syntax of a modeling language entirely on (the meta model) has exactly one instantiable Root Class, a Class that following relates to the modeled Artefact. conventions. 5. Variants of a Root Class are expressed as Specializations of a shared Generalization. 6. .ecore and .xmi files are the only granularity at which versioning is applied. 24 Assessment of EMF Ecore
  25. 25. Best Practices for Modelling Language Design (2) Adhering to these ... 7. .ecore and .xmi files can only be edited by one user at a time but can be read by any number of users. principles in 8. References between .ecore files in conjunction with References between .xmi files Ecore relies provide the basis for modularization of modelling language designs and models entirely on ... (leading to modular meta models & models). 9. Only .ecore files can be used in the role of a meta model. Limitation! following ... 10. Two .ecore files may be joined via one or more References that connect Classes in the two .ecore files. conventions. 11. No circular or bi-directional References between .ecore files and between .xmi files 12. The instantiation links between .xmi files & their meta model .ecore file is part of the .xmi files. 25 Assessment of EMF Ecore
  26. 26. Notation design elements and options • Textual syntax • Form based representation • Tree based representation • Boxes (shapes) and lines paradigm • Nested boxes or element to child-diagram “drill-down” • Two dimensional arrangements of domain-specific symbols • Animated diagrams • Combinations of the above 26 Best practices for concrete syntax design
  27. 27. Domain Analysis & Design Validate Validate languages Design languages Analyse decisions reference application Develop Extract templates reference implementation Develop platform Domain Implementation 27 Domain engineering process
  28. 28. 28 Domain engineering roles
  29. 29. Difference between a model editor & an ordinary application • The user of a model editor is always aware that (s)he is manipulating a model • The model conforms to a formal notation that the user is familiar with • The model has well-defined semantics which are provided via a generator, an interpreter, or other component that relies on the meta model corresponding to the formal notation to navigate the model • When using and/or implementing an “ordinary” application ★ the user relies on a fuzzy mental model of what the application does, he is not dealing with a familiar/intuitive formal notation ★ the application developer relies on a fuzzy mental model of the concepts that constitute the terminology of the user ★ hence the implementation can’t contain any formal mapping between problem space and solution space 29 Conclusions
  30. 30. Any difference between user and software developer? • The user of a modelling language is a domain expert, he/she needs “power user” functionality • Power user functionality is delivered via appropriate model editors • Models are automatically translated into corresponding software • Domain experts create/define software behaviour • That’s what’s usually called software development! • Domain experts and software developers are both using and producing “model driven software”. 30 Conclusions
  31. 31. Any difference between software development & configuration? • Traditionally software configuration has been the poor cousin of software development • Often, software product configurability is extended in haste, at the last minute, when a new customer is screaming for a new feature • Over the years this results in configuration tables and files that rival the complexity of legacy source code • The quality of configuration files and traditional software source code almost inevitably degrades over time • Model oriented domain analysis treats software development and software configuration on an equal footing right from the start ★ Usable model editors for all work products that are created by software professionals and/or domain experts ★ The only difference between development & configuration is binding time, and nothing more 31 Conclusions
  32. 32. Unlocking the full potential of model driven software • Using model driven techniques to implement applications conceived via a traditional requirements analysis process only requires a paradigm shift in software engineering ★ software development productivity typically increases by a factor of 2 or more ★ Quality rises as whole classes of defects can be eliminated systematically • Using model oriented domain analysis to uncover deep domain knowledge and conceive model driven applications requires a paradigm shift in business modeling and requirements engineering ★ Potential productivity and quality improvements by an order of magnitude 32 Potential
  33. 33. Knowldege Industry Survial Strategy (KISS) • ★ Reaching a strong consensus on fundamental values and principles for designing and using DSLs ★ Progress towards interoperability between tools • Upcoming conference events ★ 16 June, Code Generation 09, Cambridge, UK ★ 25 or 26 October, OOPSLA 09, Orlando, Florida ★ 16 or 17 November, Automated Software Engineering 09, Auckland, NZ • For a powerful message on simplicity, visit 33 Keep it sweet and simple
  34. 34. Thank you! Jorn Bettin jbe @ Skype jorn_bettin +41 62 891 0987