Metamodeling and method engineering Method Engineering process

1
Metamodeling and method engineering Method
Engineering process

• Juha-Pekka Tolvanen
• 29.3.2004 (31.3.2004)
• Lecture 8 Method Engineering process
• Contents
• Architecture of DSM
• The process for building a DSM
• Defining the DSM
• Identifying domain concepts
• Identifying domain rules
• Constructing the DSM

2
DSM environment

• Three things are required for a complete DSM
  environment
• Domain-specific modelling language
• Metamodel (of the language) maps to application
  domain (not to coding concepts)
• Models describe only allowed design space
• Code generator(s)
• Generators read the instance models to produce
  code
• Provide variation for output formats
• Domain framework
• Include common aspects used as primitives/componen
  ts/platform services
• Called by the generated code
• No single place to put the automation rules!

3
DSM environment in use

• Few experts define the DSM environment
• Many application engineers use it for product
  development
• Less work to write
• Code generated
• Models easier to read and change
• Safer process

4
The process for building a DSM

• Analysis and design of the DSM
• Gather the domain knowledge and user requirements
  and analyze them
• Design the first version of the language
• Prototyping the DSM
• Build and test prototypes of the DSM (both the
  visual modeling language and tool support) until
  suitable solution is found
• Reasons to choose prototyping approach
• DSM will change and evolve significantly during
  this phase
• Development process is usually the first of its
  kind within the organization
• Finalizing and deploying the DSM
• Finalize the DSM and test it with real-life cases

5
Defining a DSM

• Defining a DSM is basically the task of
  identifying
• The domain concepts the DSM should support
• The rules that guide the use of domain concepts
• How to construct the DSM according to the
  concepts and rules
• Requirements for a DSM
• General high-level requirements
• Productivity improvements by order of magnitude
• Faster learning curve
• The leverage of domain expertise among the
  developers
• Practical situational and domain-specific
  requirements
• Set the goals for the development ? define early
  and accurately
• Make the development objectives measurable to be
  able to evaluate outcomes and progress
• Intended usage of the DSM should guide the
  development

6
Identifying domain concepts 1/10

• Domain concept capture the essential ideas,
  semantics, behavior or physical constructs found
  within the domain
• Defining the domain concepts capturing the
  essence of the domain
• Identifying domain concept as a task is
• very laborious and error-prone
• very critical (as everything else is depending on
  it)

Identifying domain concepts must be carried out
very thoroughly, the results must be evaluated
very critically and one must prepare for
inevitable future changes!
7
Identifying domain concepts 2/10
PRODUCT CONCEPTS
DOMAIN-SPECIFIC TERMS
DESCRIBES
IMPLEMENTS
EXISTING CONCEPTS
CODE CONCEPTS
P L A T F O R M
DOMAIN FOLKLORE
PRODUCES
SUPPORTS
DEFINES
ARCHITECTURE CONCEPTS
DOMAIN KNOWLEDGE
ARCHITECTURE
Sources for domain concepts
8
Identifying domain concepts 3/10

• Domain terminology
• Study the terminology used in the documentation
  and by the domain experts and end-users
• Find terms that are used frequently or that seem
  to capture the essence of the domain
• Product concepts
• Product concepts capture the structure, semantics
  and behavior of the final product.

9
Identifying domain concepts 4/10

• Product concepts (continued)
• Three categories of product concepts
• Physical product concepts represent physical
  elements of the product like mechanical devices,
  panels, buttons, displays, widgets
• Logical product concepts represent logical
  constructs like sub-applications and services
  within the product
• Behavioral product concepts capture the basic
  functionality and operational aspects of the
  product
• Process
• Analyze the use of the product ? behavioral
  concepts
• Map the functionality with the physical
  interfaces of the product to find out which parts
  are associated with given functionality ?
  physical concepts
• Analyze the mappings between behavioral and
  physical concepts and group tasks to higher-level
  entities ? logical concepts

10
Identifying domain concepts 5/10

• Architecture concepts
• Capture the architectural semantics of the
  platform
• Represent certain logical, semantic or physical
  construct ? easy to identify
• Modular architectural elements like components,
  objects or data structures usually make good
  architecture concepts
• Code concepts
• Capture the semantics of the actual code that
  implements the product
• Programming language constructs and data
  structures make good code concepts

11
Identifying domain concepts 6/10

• Existing models and descriptions
• Analyze the existing descriptions of the product
  to understand the structure of the product and
  translate it to a conceptual schema
• If there are no existing descriptions for the
  product, try to create them yourself
• A good way for less-experienced developers to
  gain understanding of the domain
• Requires nearly always a detailed domain analysis
  which often reveals possible concept types
• The example descriptions can be used later when
  defining the representational aspects of a DSM
  (like diagrams and symbols)
• Descriptions support and promote communication
• Concepts found this way are valuable because they
  have been already used in some form and should
  thus be included into the DSM

12
Identifying domain concepts 7/10

• End-user semantics
• End-user semantics are important because they
  capture the end-users point of view ? DSM must
  support them as much as possible
• The better the support for end-user semantics,
  the better is the acceptance of the DSM
• Capturing this information may be difficult, as
  it usually exists as folklore among the
  end-users
• Techniques for capturing this information
• Interview the end-user
• Observe their work routines
• Understand the principles used by the experienced
  end-user
• End-user semantics are usually good source for
  domain rules

13
Identifying domain concepts 8/10

• Domain expert semantics
• Domain expert semantics should provide the final
  answers to all questions related to DSM ? All
  domain concepts identified by other techniques
  and the DSM definitions must comply with domain
  expert semantics!
• The key success factor in capturing domain expert
  knowledge is to find the proper source of domain
  expertise
• The best possible solution would be that the
  person(s) possessing the domain expertise could
  define the DSM
• In most cases the development of the DSM is a
  group effort with domain expert as a member of
  the development group
• The size of the team and amount of the sources of
  domain expertise are critical smaller teams
  perform better

14
Identifying domain concepts 9/10

• Similarities and variability
• Analyze the commonalities and variability of
  domain concepts to see if there are common
  denominators that can be used to classify new
  concept types
• Differences among the elements often provide
  valuable categorizing information for making
  distinction between different concept types
• It is important to apply this kind of analysis to
  the larger sets of domain concepts
• For example, if certain patterns of domain
  concepts occur repeatedly, it may be possible to
  define a separate domain concept with higher
  level of abstraction as shorthand for the pattern

15
Identifying domain concepts 10/10

• Sub-domains
• Decompose the domain into sub-domains and study
  each sub-domain individually, applying other
  proposed techniques and combine the outcomes to
  gain the understanding about the whole domain
• This approach is very useful when the size and
  the complexity of the domain make it difficult to
  understand the domain as whole at first

16
Identifying domain rules 1/3

• The important behavioral aspects of DSM are not
  usually captured by the domain concepts ? The
  domain rules that guide the use of the language
  must be identified and implemented
• The domain rules
• Capture such domain knowledge that cannot be
  expressed as domain concepts
• Typically characterize or limit the use of the
  domain concepts
• Are informal by nature (and thus hard to gather)

17
Identifying domain rules 2/3

• The best sources for domain rules are the domain
  expertise and end-user folklore
• To capture domain rules
• Look for the issues that guide or restrict the
  use of the DSM
• Dos and donts related to certain procedures in
  development lifecycle or on how the product is
  described
• Constraints and rules related to the descriptions
  (for example, what kinds of relationships are
  allowed between different kinds of concepts, how
  many times a concept or its instance may be used
  in a relationship or a model, what are the
  cardinalities of relationships, etc.)
• Possible pre- and post-conditions related to
  certain procedures
• Consistency and completeness of the models.

18
Identifying domain rules 3/3

• Defining and implementing the domain rules ? two
  options
• The traditional way write the rules down as a
  part of documentation
• Advantage it is possible to define all kinds of
  domain rules this way
• Disadvantage the enforcing of the rules can
  never be complete as there is no way to make sure
  that they are followed by the end-users
• Build the rules as a part of the DSM tool support
• Advantage ensures that the domain rules are
  followed, as the tools do not allow breaking the
  rules
• Disadvantage only formal rules can be
  implemented, first approach is still required for
  less formal rules
• Rules regarding naming conventions (like
  propagation) should always be implemented as part
  of the tool support by a reuse mechanism

19
Constructing the DSM 1/5

• Constructing the DSM is a task of allocating and
  assembling the identified domain concepts into a
  complete modeling language specification
• Typically this is done at least partially
  simultaneously with the tool support
  implementation
• Assembling the DSM
• Three possible levels for problem allocating
  concepts
• Modelling language
• (Code) generator
• Platform

20
Constructing the DSM 2/5

• Assembling the DSM (continues)
• On which level one should solve a specific
  problem?
• Domain usually fixed but modifications may still
  be possible (like new domain rules, etc.)
• Modelling language and generators many various
  solutions usually possible, easy to change
• Platform usually fixed and hard to change
• There are often many ways to solve a specific
  problem
• Good results usually require solutions on more
  than one level

21
Constructing the DSM 3/5

• Properties and Relationships
• Properties with their values define the contents
  of concept instances (e.g. the names of
  individual instances)
• Important mechanism to include information into
  the models
• Relationships provide additional semantics by
  defining how concepts are interacting
• Relationships can be categorized by type
• Relationships can have properties of their own
• Properties and relationships extend the
  expressive power of the DSM but also introduce
  additional complexity
• It is not trivial to decide if an element should
  be a concept, a relationship, a property or a
  combination of all of them
• Emphasize simple structures when possible but
  prepare also to introduce complex ones when needed

22
Constructing the DSM 4/5

• Complex Structures and Model layering
• Two ways to integrate domain concepts and models
• A domain concept may appear as a part of another
  domain concept (may be a reuse of an existing
  concept or the concept may exist only as part of
  another concept)
• A domain concept may explode or decompose to a
  set of another domain concepts (typically when
  there is more than one level of details a
  concept of higher level of abstraction has more
  detailed definition on a lower level)
• Reuse issues
• Promote and ease the reuse
• The best way is to use some kind of incremental
  approach ? it is ok to invest more effort in
  defining something that can be extensively reused
  later

23
Constructing the DSM 5/5

• Modeling language issues
• Create declarative modeling languages to present
  static aspects
• Create functional modeling languages to present
  dynamic aspects
• Tool support issues
• The tools support is often build simultaneously
  as we are defining the DSM
• The tools support issues should not guide the
  definition of the DSM but it often has influence
  on the implementation of the DSM (good or bad?)
• Use tool support to automate the functionality
  that developers do not need to consider (ie. put
  it into the generators)