Jump to content

User:Seluc/metaCaseTools test page

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Seluc (talk | contribs) at 12:29, 28 December 2008 (OpenSoul Metamodeler). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

metaCASE tool is application software that provides possibility to use more than one modelling metodics or notations within process of software development.

Another definition: MetaCASE tools are software tools that support the design and generation of CASE tools. In general, meta-CASE tools should provide generic CASE tool components that can be customised and instantiated into particular CASE tools. The intent of meta-CASE 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 keeped 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 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 todays 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.

File:MetaCASE.jpg
Structure of CASE and metaCASE tool.

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 list of available metaCASE tools:

- Alfabet

- ALLFUSION COMPONENT MODELER (formely known as Paradigm Plus) produced by Computer Associates

- ArgoUML

- ConceptBase

- Coral

- GME

- IPSYS TOOLBUILDER

- MetaEdit+

- Metamill

- MetaView

- OpenSoul Metamodeler

- Paradigm Plus

OpenSoul Metamodeler

OpenSoul Metamodeler is a MOF based metamodeling CASE tool. It is built on MDR (Netbeans Metadata Repository) and JGraph. It is a part of OpenSoul Project, which aims to be framework for sharing models between the metamodeling community members. <ref>

See also

References

  1. ^ A rapid development model for meta-CASE 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. ^ a b [1] ABC TO METACASE TECHNOLOGY, WHITE PAPER, MetaCase, 5605 North MacArthur Blvd. 11th Floor, Irving, Texas 75038