Metamodeling and method engineering ComputerAided support

1
Metamodeling and method engineering
Computer-Aided support

• Juha-Pekka Tolvanen
• 15.3.2004
• Lecture 6 Computer-Aided Software Engineering
  and Computer-Aided Method Engineering
• Contents
• Defining CASE tools and metaCASE tools
• Reasons for selecting metaCASE tool
• Requirements for a metaCASE tools
• Available metaCASE tools

2
What is a CASE tool

• CASE tool provide automated support for the use
  of development methods
• CASE tools support methods with (Olle et al.
  1988)
• abstraction
• checking
• form conversion
• review
• When these structures can be modified easily we
  talk of metaCASE tool functionalities

3
1. Abstraction

• Support for capturing and representing aspects of
  object systems
• modeling languages/techniques
• model layers (e.g. submodels, model hierarchy)
• model integration principles
• Various forms
• formal, semi-formal, free text
• Various representations
• diagram, matrix, text, table, tree, etc.

4
Modeling transparency (Brinkkemper)

• Metric for CASE tool architecture evaluation
• Measures linking functionality between diagrams
• Can we open more than one diagram at once?
• Can we show several diagrams at once?
• Can we link between diagrams that follow each
  other?
• Can we link between diagrams that represent the
  same thing?
• Equates roughly to Ease of Use
• Scale 0-3, 0fancy drawing tool, 3any link you
  want
• Assumption single user, single environment

5
Vertical vs. horizontal integration

• Vertical integration (sequential dependency)
• Same area modeled at different phases
• E.g. requirements analysis of textphone, design
  of textphone
• Provides requirements tracking (hard without
  flexible and powerful linking mechanisms)
• Automation problem graph conversion hard
  computationally
• Horizontal integration (parallel dependency)
• Same area modeled at the same phase with
• Different modeling technique, e.g. UML vs.
  Rumbaugh
• Different model, e.g. interaction class diagram
• Different audience, e.g. programmers vs.
  customers
• Different view, e.g. matrix vs. diagram
• Automation problem update propagation hard for
  non-OO systems

6
Degree 0

• Not much more than a drawing program
• User manually remembers all dependencies
• No linking between graphs
• Only one graph open at a time

7
Degree 1 Many environments in 90's

• Repository open to all tools
• Only one graph open at once
• Standard repository for several vendors?
• Parallel all within one tool, tool-to-tool
  sequential

Repository
8
Degree 2 Many recent tools

• Direct switching between graphs
• Restricted by built in metamodel
• Show graphs side-by-side
• Linking model elements partial integrated

9
2. Checking

• Ensure that models are syntactically consistent
• Often consistency rules are not described
  complete
• if not at all....
• Checks the rules of the language
• some rules can be checked actively (run-time)
• other rules possible only when models ready
  (e.g. checking reports)
• Checking possible
• inside a model
• between models
• between models made by different users
• repository, lockings, availability of data?

10
Multi-user aspects

• Access rights (what data can I work on?)
• Locking (what data is hidden from me?)
• I dont want to lose my work Security, ability
  to write data to database
• I dont want to stop work because data isnt
  available Fine granularity
• I want to be able to undo changes Transaction
  abort
• I dont want to waste time working from old data
  Distribute updates
• I want to see others work Minimal locking

11
Multi-environment

• Integration of different environments
• (E.g. MetaEdit, Paradigm, Rose, even MS Word)
• Via common repository
• ISO IRDS, PCTE, IBM Repository
• Tool-to-tool import/export
• Only between certain manufacturers, O(n²)
• Federated CASE XML/XMI format
• tried already with CDIF standard
• Conversion to common format, O(n)
• Common data / messaging interface
• ECMA PCTE, CORBA
• Common platform/plug-in architecture
• Eclipse

12
3. Form conversion

• Transform results from one phase or task to
  another, e.g. analysis models to design models.
• Examples
• Code generation
• Reverse engineering
• Configuration data
• Component retrieval and use
• Testing and analysis
• Documentation
• Note all conversions can not be fully automated
• gt require human interaction

13
4. Review

• Deals with semantic validity of system
  descriptions
• whereas checking focus on syntactic properties
• Examples
• documents for end-users or domain experts
• documents for developers review meetings

14
CASE tool versus metaCASE tool

• CASE provides
• fixed methods
• methods in-coded
• MetaCASE provides
• metamodel open for method specifications
• usually the metamodeling level is fixed

15
Shortcomings of standard CASE

• Offer limited functionality
• mainly mechanize pen and paper -mentality of
  methods
• methods are fixed part of a tool limited
  modifications allowed
• only the data support model drawing and
  consistency checking tools
• Weak support for user-native methods
• neglect organization's own standards and methods
• no support for new areas or techniques of ISD
  (ecommerce, web-services, mobile applications)
• do not allow incremental adaptation
• Shortcomings of building own CASE
• Costs, time and resources needed

16
MetaCASE?

• Definition MetaCASE tool allows to modify or
  program new methods for CASE
• new concepts, rules, notations
• new generators, etc.

17
Tool production example MetaEdit
Use your method
Design your method
18
Reasons for selecting metaCASE

• 1. Support for specific application area
• 2. Add flexibility to existing methods, smooth
  configuration of ISD methodologies
• 3.Multiple methods needed (customers
  requirements, various kind of systems developed)
• 4.Technical platform ("test bench") for selecting
  appropriate methods
• 5.Functionality for incorporating all types of
  knowledge of system development method choice

19
Flexibility through metamodeling

• Modifications a metaCASE (should) offer
• Current focus on metaCASE is primarily on the
  first two to three levels
• 1. Repository "how to support different ISD
  techniques and notations?"
• 2. Activities and tasks "what process support
  tool should offer?"

20
Key functions for a metaCASE tool

• Definition of metamodels
• specify the concepts, rules, and symbols of
  individual modelling techniques as well as their
  interconnection rules.
• as complete as possible, and
• relatively easy and fast in comparison with
  programming a CASE tool from scratch.
• E.g. create a metamodel for Use Case in few
  hours.
• Creation of modelling tools
• different kinds of editors, toolbars, dialogs,
  online help, etc.
• the creation should be automatic, based on the
  metamodels
• Creation of repository
• to store the models based on the new method
• other repository administration tools

21
Key functions for a metaCASE tool, 2

• Definition for model reporting
• definition of various model analyses, checking,
  code generation and model documentation reports.
• Note that although a good metamodel includes all
  the rules of the method, checking them can not be
  fully automatic
• some rules can be checked only after models are
  considered complete.
• Metamodel management
• Metamodel management similar to the CASE tools
  functions for the model management.
• These include browsers, documentation tools,
  libraries for metamodels, backups, versioning,
  configuration management and access rights for
  method specifications or for their parts.

22
Key functions for a metaCASE tool, 3

• Management of method updates
• Transformation rules between method versions
  (e.g. UML 1.5 to UML 2.0, or to your own extended
  UML)
• Update designs (semi-)automatically to correspond
  to the new method version.
• This function usually necessitates an integrated
  metaCASE tool and CASE tool.
• Interchange format
• Importing and exporting of both models and
  metamodels.
• Importing should be incremental
• previously imported data from the same exporter
  should be updated automatically, rather than
  creating duplicates.

23
MetaCASE limitations

• MetaCASE offers guided or flexible method use,
  but has limitations in metamodeling (Hofstede
  Verhoef 1996)
• metaCASE based on relatively simple conceptual
  metametamodels,
• limited support for instantiation level and
  representational level constraints
• limited support for (meta)process models
• group and organization features are lacking
• Tradeoffs between representational, conceptual
  and process aspects needed
• parameterized generic solutions possible!

24
Some available metaCASE tools

• Research
• SREM and PSL/PSA (original)
• ConceptBase
• Metaview
• MetaPlex
• Kogge (ER-based)
• Dome
• GME
• Commercial
• MethodMaker
• Paradigm
• MetaEdit
• Alfabet