MetaCASE tool

Last updated

A metaCASE tool is a type of application software that provides the possibility to create one or more modeling methods, languages or notations for use within the process of software development. Often the result is a modeling tool for that language. MetaCASE tools are thus a kind of language workbench, generally considered as being focused on graphical modeling languages.

Contents

Another definition: MetaCASE tools are software tools that support the design and generation of CASE tools. In general, metaCASE tools should provide generic CASE tool components that can be customised and instantiated into particular CASE tools. The intent of metaCASE tools is to capture the specification of the required CASE tool and then generate the tool from the specification. [1]

Overview

Quick CASE tools overview

Building large-scale software applications is very complicated process which is not easy to handle. Software companies must have good system of cooperation throughout developing teams and good displicine is highly required.

Nevertheless, using CASE tools is modern way how to speed up software development and ensure higher level of application design. However, there are another issues which has to be kept in mind. First of all usage of these tools doesn't guarantee good results because they are usually large, complex and extremely costly to produce and adopt.

CASE tools can be classified as either front-end or back-end tools [2] depending on the phase of software development they are intended to support: for example, “Front-end’ analysis and design tools versus “Back-end” implementation tools. For a software engineers working on a particular application project, the choice of CASE tool would typically be determined by factors such as size of project, methodology used, availability of tools, project budget, and numbers of people involved. For some applications, a suitable tool may not be available or the project may be too small to benefit from one.

CASE tools support a fixed number of methodologies but software development organizations dynamically change their adopted methodologies.

Quick metaCASE tools overview

MetaCASE products are usually highly specialised, application development environments which produce a custom tool(set) from a high level description of the required tools. [3] [4]

So in other words metaCASE technology approaches the methodology automation from a dynamic perspective.

MetaCASE tools allow definition and construction of CASE tools that support arbitrary methodologies. A CASE tool customizer first specifies the desired methodology and customizes the corresponding CASE tool. Then software developers use that CASE tool to develop software systems. An advantage of this approach is that the same tool is used with different methodologies, which in turn, reduces the learning curve and consequently the cost. Any desired methodology can be automated or modified by the developing organization which provides a dynamic capability in today's dynamic and competitive world. From another perspective this technology can be used as a practical teaching tool considering the shortened length of development and learning times that suits academic course periods.

Differences between metaCASE and CASE tools

Most CASE tools for object-oriented modeling are heavily based on the UML method. A method also dictates other CASE tool functions, such as how models can be made, checked and analyzed, and how code can be generated. For example, a tool can generate CORBA IDL definitions only if the modeling language can adequately specify and analyze CORBA compliant interfaces. If the tool (and method) does not generate them, it offers very little, if any, support for work on interface design and implementation.

When using methods developers often face similar difficulties. They can not specify the domain and system under development adequately because the method does not provide concepts or notations for the task at hand. End-users may find the models difficult to read and understand because they are unfamiliar with the modeling concepts. Typically they also find it difficult to map the concepts and semantics used in the models to their application domain. After creating the models, which fail even to illustrate the application domain adequately, the tool does not provide the necessary reports nor does it generate the required code.

What is needed then is the ability to easily capture the specifications of any method and then to generate CASE tools automatically from these specifications. Later when the situation in the application domain evolves and the development environment changes you may incrementally update the method support in your CASE tool. This is exactly what metaCASE technology offers. [5]

How metaCASE works

Traditional CASE tools are based on a two-level architecture: system designs are stored into a repository, whose schema is programmed and compiled into the CASE tool. This hard-coded part defines what kind of models can be made and how they can be analyzed. Most importantly, only the tool vendor can modify the method, because it is fixed in the code. MetaCASE technology removes this limitation by providing flexible methods.

This is achieved by adding one level above the method level.

MetaCASE tools are based on a three-level architecture:

  1. The lowest, the model level, is similar to that of CASE tools. It includes system designs as models.
  2. The middle level contains a model of the method, i.e. a metamodel. A metamodel includes the concepts, rules and diagramming notations of a given method. For example, a metamodel may specify concepts like a class and an inheritance, how they are related, and how they are represented. However, instead of being embedded in code in the tool, as in a fixed CASE tool, the method is stored as data in the repository. The use of metamodels has recently become more popular. Many method books now include metamodels of their method, and several important innovations, such as XMI, are metamodel-based. Unlike a CASE tool, a metaCASE tool allows the user to modify the metamodel. Hence, metaCASE is based on the flexibility of the method specifications.
  3. This is achieved by having a third, higher level that includes the metamodeling language for specifying methods. This level is the hard-coded part of the metaCASE software.

All the three levels are tightly related: a model is based on a metamodel, which in turn is based on a metamodeling language. Clearly, no modeling is possible without some sort of metamodel. This dependency structure is similar to that between objects, classes and metaclasses in some object-oriented programming languages. [5]

metaCASE tools

This is a list of currently available metaCASE tools; many other modeling tools may also offer some measure of metamodeling functionality

Real benefits of using metaCASE tools

Jackson [6] recognises the vital difference between an application’s domain and its code: two different worlds, each with its own language, experts, ways of thinking etc. A finished application forms the intersection between these worlds. The difficult job of the software engineer is to build a bridge between these worlds, at the same time as solving problems in both worlds.

Empirical studies [7] [8] have consistently shown that only around half of all development projects use methods. Among those using methods, over 50% either modify the methods to better fit to their need or even develop their own methods [9] [10]

In a standard CASE tool, the method supported by the tool is fixed: it cannot be changed. In a metaCASE tool, there is complete freedom to change the method, or even develop an entirely new method. Both models and metamodels (method descriptions) are stored as first-class elements in the repository. This allows an organisation to develop a method that suits their situation and needs, and to store and disseminate that knowledge to all developers. The tool and method then guide developers, provide a common framework for them to work in, and integrate the work of the whole team. [11]

Research prototypes and even commercial metaCASE tools have existed for many years, but only recently have there been tools which are mature, user-friendly and stable for both the method developer and the method user. One of the most widely known and used metaCASE tools [12] [13] is MetaEdit+.

Following list represents several kinds of ways how these tools can be used within software development: [14]

These tools should also possess the following characteristics: [14]

See also

Related Research Articles

<span class="mw-page-title-main">Object-modeling language</span> Component in software development

An object-modeling language is a standardized set of symbols used to model a software system using an object-oriented framework. The symbols can be either informal or formal ranging from predefined graphical templates to formal object models defined by grammars and specifications.

<span class="mw-page-title-main">Unified Modeling Language</span> Software system design modeling tool

The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.

Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through to the final manifestation of the software, typically in a planned and structured process. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.

Model Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model Driven Architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

A domain-specific language (DSL) is a computer language specialized to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains. There are a wide variety of DSLs, ranging from widely used languages for common domains, such as HTML for web pages, down to languages used by only one or a few pieces of software, such as MUSH soft code. DSLs can be further subdivided by the kind of language, and include domain-specific markup languages, domain-specific modeling languages, and domain-specific programming languages. Special-purpose computer languages have always existed in the computer age, but the term "domain-specific language" has become more popular due to the rise of domain-specific modeling. Simpler DSLs, particularly ones used by a single application, are sometimes informally called mini-languages.

The common warehouse metamodel (CWM) defines a specification for modeling metadata for relational, non-relational, multi-dimensional, and most other objects found in a data warehousing environment. The specification is released and owned by the Object Management Group, which also claims a trademark in the use of "CWM".

<span class="mw-page-title-main">Metamodeling</span> Concept of software engineering

A metamodel or surrogate model is a model of a model, and metamodeling is the process of generating such metamodels. Thus metamodeling or meta-modeling is the analysis, construction and development of the frames, rules, constraints, models and theories applicable and useful for modeling a predefined class of problems. As its name implies, this concept applies the notions of meta- and modeling in software engineering and systems engineering. Metamodels are of many types and have diverse applications.

A UML tool is a software application that supports some or all of the notation and semantics associated with the Unified Modeling Language (UML), which is the industry standard general-purpose modeling language for software engineering.

Domain-specific modeling (DSM) is a software engineering methodology for designing and developing systems, such as computer software. It involves systematic use of a domain-specific language to represent the various facets of a system.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

In software engineering, behavior-driven development (BDD) is an agile software development process that encourages collaboration among developers, quality assurance experts, and customer representatives in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

Model-driven engineering (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing concepts.

MetaEdit+ is an environment for creating and using Domain-Specific Modeling languages.

Generic Eclipse Modeling System (GEMS) is a configurable toolkit for creating domain-specific modeling and program synthesis environments for Eclipse. The project aims to bridge the gap between the communities experienced with visual metamodeling tools like those built around the Eclipse modeling technologies, such as the Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF). GEMS helps developers rapidly create a graphical modeling tool from a visual language description or metamodel without any coding in third-generation languages. Graphical modeling tools created with GEMS automatically support complex capabilities, such as remote updating and querying, template creation, styling with Cascading Style Sheets (CSS), and model linking.

Knowledge Discovery Metamodel (KDM) is a publicly available specification from the Object Management Group (OMG). KDM is a common intermediate representation for existing software systems and their operating environments, that defines common metadata required for deep semantic integration of Application Lifecycle Management tools. KDM was designed as the OMG's foundation for software modernization, IT portfolio management and software assurance. KDM uses OMG's Meta-Object Facility to define an XMI interchange format between tools that work with existing software as well as an abstract interface (API) for the next-generation assurance and modernization tools. KDM standardizes existing approaches to knowledge discovery in software engineering artifacts, also known as software mining.

EAST-ADL is an Architecture Description Language (ADL) for automotive embedded systems, developed in several European research projects. It is designed to complement AUTOSAR with descriptions at higher level of abstractions. Aspects covered by EAST-ADL include vehicle features, functions, requirements, variability, software components, hardware components and communication. Currently, it is maintained by the EAST-ADL Association in cooperation with the European FP7 MAENAD project.

Domain-specific multimodeling is a software development paradigm where each view is made explicit as a separate domain-specific language (DSL).

Model Driven Interoperability (MDI) is a methodological framework, which provides a conceptual and technical support to make interoperable enterprises using ontologies and semantic annotations, following model driven development (MDD) principles.

<span class="mw-page-title-main">INGENIAS</span>

INGENIAS is an open-source software framework for the analysis, design and implementation of multi-agent systems (MAS).

References

  1. ↑ A rapid development model for metaCASE tool design, Conceptual Modeling — ER '97, Maokai Gong, Louise Scott, Yingping Xiao and Ray Offen, ISBN   978-3-540-63699-1
  2. ↑ Definition In: D. Schefstrom, System Development Environments: Contemporary Concepts in Schefstrom, D and van den Broek, G (eds) Tool Integration John Wiley and Sons (1993).
  3. ↑ IPSYS Toolbuilder Manual, Version 2.1 Lincoln Software Ltd (1996)
  4. ↑ G. Stumer, Oracle 7: A User’s and Developer’s Guide International Thomson Publishing (1995)
  5. 1 2 ABC TO METACASE TECHNOLOGY, WHITE PAPER, MetaCase, 5605 North MacArthur Blvd. 11th Floor, Irving, Texas 75038
  6. ↑ Jackson, M.A., Software requirement & Specifications A lexicon of practice, principles and prejudices Addison Wesley, ACM Press, 1995
  7. ↑ Necco, C.R., Gordon, C.L., Tsai, N.W. Systems Analysis and Design: Current Practices, MIS Quarterly, December, 1987.
  8. ↑ Fitzgerald, B., The use of system development methods: a survey. Paper ref 9/95, Univ. College Cork, 1995.
  9. ↑ Russo, N., Wynekoop, J., Walz, D., The use and adaptation of system development methodologies. Procs of International Conference of IRMA, Atlanta, May 21-14, 1995.
  10. ↑ Hardy, C., Thompson, J., Edwards, H., The use, limitations and customisation of structured systems development methods in the UK. Information and Software Technology, 37 (9), 1995.
  11. ↑ Visual domain-specific modelling: Benefits and experiences of using metaCASE tools, Steven Kelly, MetaCASE
  12. ↑ Isazadeh, H., Lamb, D.A., CASE Environments and MetaCASE Tools, Technical Report 1997-403, Queen’s University, Canada, February 1997
  13. ↑ Alderson, A., Cartmell, J.W., Elliott, A., ToolBuilder: From CASE Tool Components to Method Engineering, Peer Logic white paper, 1999
  14. 1 2 Principles of MetaCASE systems, Vivekanandan Suresh Kumar
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.