Topics in Metacase Developments

 

 

1 Generating Real-Time Systems Development Environment Using Metaview [3]

Metaview is a metasystem approach which can generate many kinds of software specification environments and support graphics-based design. To implement this flexibility, Metaview uses three levels of specifications: the meta level, the environment level and the user level.

In the meta level, Metaview defines a meta model-EARA/GE model to support the description of a large class of development environment. EARA/GE (Entity-Aggregate-Relationship-Attribute with Graphical Extension) model is based on EARA model which includes the abstraction mechanisms of classification, aggregation and generalization. These features are needed to adequately model the sophisticated nature of the relationships in the environment level. There are no constraints in the EARA model, so a special language for expressing the constraints, ECL(Environment Constraint Language) is designed. In order to support graphics-based design, a graphical extension is provided. This GE extension uses diagrams, icons, edges, labels, handles, properties and pictures to represent different concepts of EARA. The meta level also contains tool definer for creating the generic tools. By specializing routines and definitions in the Tool Components Library, the Metaview Tools Library is created for tools configuration in environment level.

At the environment level, the environment definer uses the meta model to define the environment model. The environment model definition is expressed in an Environment Description Language (EDL). An environment definer can define different environments for different methodologies. After EDL is compiled and each tool in the environment is configured by the tool definer, the environment is ready to be used at the user level.

At the user level, the user (system developer) selects a particular specification environment which includes an environment model analyzer and environment tools. All of these facilities are used to store and analyze specifications for the system the user wants to define.

The flexibility of Metaview makes users use different environments in one CASE system easily. However, defining different environments in Metaview by EARA/GE model is not an easy task. EARA/GE model is simple to use but may be difficult to represent some complex environments. Under such conditions, good skills of definers are needed to model the environment in a efficient way.

2 Transformations Using a Meta-system Approach To Software Development [2]

There are many stages in software development life-cycles. Different models are used to represent different stages in most software development methodologies. However, only informal guidelines are provided to the transformations occurring from one phase to the next. This paper tries to develop a new approach that formalizes transformations between phases of the development life-cycle. As an example, transformation from the analysis model data-flow diagram (DFD) to the design model structure chart (SC) is analysed.

The source and target environments for transformation should be defined by a meta-model description. Here they are defined by the EARA model. This makes the transformation approach more general and easier to be modified. The rules of transformation are defined in a environment transformation language(ETL). When executing the transformation rules, the source environment is analysed, and source objects are mapped to the target environment, then the target environment is analysed and completed. During these steps, interventions of designer are needed.

After the target environment is transformed, the designer can improve and optimize it. Much information which does not exist in the source environment should also be specified.

3 Complexity Metrics For Systems Development Methods and Techniques [6]

This paper proposes a systematic approach for measuring relative complexities of different methods. To be able to compare and analyze techniques of all methods, the metamodel OPRR (Object, Property, Relationship, Role) is used as a common language to represent them. To eliminate the possible bias caused by human factors, all techniques have been modeled by one experienced method engineer.

Two sets of metrics, which measure the complexity of single techniques, and of complete systems development methods, are proposed. These metrics provide a relatively fast and simple way to analyze the descriptive capabilities of a technique or method.

The measure of relative complexity of methods and techniques based on metamodels is significant because it can affect the learnability and ease of use of a method. Generally speaking, the more expressive method may be harder to learn, whilst being more effective for experienced users if the method's conceptual complexity does lead to greater expressive power. However, some limitations still exist in this method. First, OPRR can not represent constraints of some techniques. Second, OPRR can not deal appropriately with the interconnection among techniques. Third, the metrics by themselves can not be used to judge the ``goodness'' or the appropriateness for the task of the method, they should be combined with the values of other measurement methods.

4 Software Metrics Using a Metasystem Approach to Software Specification [1]

The goal of this paper is to develop a metric-driven system for software development with the principal characteristic of immediate feedback of system measurements to designers through software metrics. Metrics are fedback to the designer to review parts of the project that may require some type of reorganization, according to some predefined standards. Moreover, the metrics can be used in a more active role during development, particularly in controlling the complexity of specifications.

This paper focuses on how metrics can be incorporated into software specification environments. With this approach, new metrics computations can be easily added and existing metrics can be easily altered, as part of the specification environment.

This paper uses a metasystem Metaview for specifying a particular specification environment. The metrics for the environment are defined using an extended version of ETL, and are associated with the basic objects of the Metaview's meta-metamodel-EARA model, namely entities, relationships and attributes. Metrics are also stored in the specification database as attributes. When each of the objects of the model is created or changed, the associated metrics are updated automatically. Next, working in a bottom-up fashion, aggregate metrics are updated at the aggregate level, and finally project metrics are updated at the project level.

Future research includes integrating product and process metrics during development, using metrics to help the transformational approach in forward and reverse software development, integrating top-down definitional approaches in Metaview, and the analysis of composite metrics.

5 MetaEdit-A Flexible Graphical Environment for Methodology Modelling [7]

MetaEdit is a flexible, graphical environment for methodology modelling. It is aimed to be a general metamodelling environment where new methodologies can be easily supported after the specifications of the methodologies are defined by a metamodel. Different metamodels e.g. E-R, OPRR can be selected when defining methodologies.

MetaEdit is a multilingual environment offering a changeable methodology modelling language. This is achieved by offering a meta-meta model over the meta-model. OPRR(Object-Property-Role-Relationship) is selected as the meta-meta model of MetaEdit because of its good express power and simplicity. In the OPRR model, object is a thing which exists on its own, property is a describing characteristic associated with other meta types(object, relationship, or role), role is a link between an object and a relationship, and relationship is an association between two or more objects.

The design principles of MetaEdit is to separate the conceptual content of a methodology and its representation form. The type level and the instance level should also be separated. Based on these principles, MetaEdit support flexible graphical representation of a specific concept.

6 MetaEdit+ A Fully Configurable Multi-User and Multi-Tool CASE and CAME Environment [4]

MetaEdit+ is a multi-method, multi-user, multi-tool, multi-level platform for both computer aided software engineering (CASE) and computer aided method engineering (CAME). It can support changeable methodology specifications. It can allow several users to operate concurrently on the repository and different tools. It can support multiple-representations such as text, matrix or graph to the same conceptual object. It also provides an open architecture which separates the conceptual specification of the repository and the view adopted in different tools.

Three design principles ensure MetaEdit+ achieving the above goals: data independence, representation independence, and level independence. Data independence is defined in a similar way as in traditional database theory i.e. tools operate on design information without ``knowledge'' of its physical organization, or logical access structure. Representation independence allows conceptual design objects to exist independently of their alternative representations as text, matrix or graphical representations. Based on this principle, new tools can be added because each one is only responsible for its own paradigmatically different view on the same repository data. Level independence means that the environment follows a symmetrical approach in its treatment of data and meta data. Accordingly, the specifications of methods and their behaviours can be managed and manipulated in a similar way to any other objects in the environment.

A multi-level and Client/Server architecture is used in MetaEdit+ to support the three design principles. The lowest level, repository is on server side. It holds all the data contained in models and metamodels, in addition to user and locking information. All concurrency control is also processed in the repository. The middle level, MetaEngine, is on client side, which handles all operations on the data in repository through a service protocol. Tools manipulate repository data and communicate with each other only via the MetaEngine. The highest level, tools level, implements all concrete works such as environment management, model editing, model retrieval, and method management.

MetaEdit+ uses the GOPRR conceptual data model as a universal and generic meta-metamodel i.e. as a sole language to specify methods. GOPRR extends OPRR, allows multiple representations of the same conceptual object and even different graphical representations of the same object in the same representation paradigm. Aggregations are also supported by graph notation in GOPRR model.

To ease the effort of new tool generation, method management tools support alternative ways of method engineering such as creation from scratch, or reuse existed components or methods.

7 Modelling Requirements For Future Case: Issues and Implementation Considerations [5]

In this paper general requirements for the next generation CASE environment and a general architecture to support these requirements are discussed.

The next generation CASE environment should support flexible models by a meta-metamodel. The GOPRR is a good candidate for this requirement because of its express power and simplicity.

Three interrelated levels of modelling requirements are proposed. First, when data of Information System (IS) are represented by a single method, the method should have enough power to express complex relationships among objects such as classification, generalization and recursive structure. Domain knowledge and operational semantics are also needed in the method representation. Second, when data of IS are represented by multiple connected methods, different checks like verification and validation are important to ensure the consistency among different representations. Third, to support multiple users, CASE is required to describe and maintain knowledge of their environments such as user role models, method usage knowledge, guidelines for different situations. Communication models should also be provided to support user-to-user communications.

A three-level architecture is proposed to support the above requirements. They are meta-meta level, ME level (meta level) and ISD level (design level). Different methodologies and mechanisms to integrate them are defined in the meta-meta level. In the meta(ME) level, three models are described. Meta-datamodel contains specifications of techniques of a methodology concept space. Activity model guides the users through the development phases and helps the transformations and checking. Agent model defines the access to the models and coordinates tasks among users. In the design(ISD) level, the IS model represents the design information of an existing IS. In addition to the design data, the guidance for design, the user configuration and the organization are also included in the IS model.

8 Personal Thoughts

8.1 Development of CASE design principles

If we compare the development of CASE design principles with that of the database theory, we can get interesting results. In the early age of CASE, a CASE environment can only support one design model and one tool is designed only for this model. This is like before databases were used, every application has its own data format and can only access data by physical addresses.

Metacase development changes this situation. The meta-model of a metacase environment can be used to represent many methodologies [3][4][7]. Users can select a preferred methodology in their work. The tools that operate on design information need not have the ``knowledge'' of its physical organization, or logical access structure [4]. The uniform and formal representations of methodologies by a meta-model make the verification, validation and transformation possible and easy to implement. This is like after a database is used, applications can operate and share data easily.

MetaEdit+ [4] also proposes the representation independence which means the conceptual design objects exist independently of their alternative representations as text, matrix or graphical representations. The same design data can be operated by different tools. A user can select the tools that he needs and does not care about details in the design model. This is like the three model structure (user model, logical model and physical model) of database theory. The user model is independent of the logical model. Application can select a needed user model and does not care about the details of the logical model.

The level independence of MetaEdit+ means that the environment follows a symmetrical approach in its treatment of data and meta data. The specifications of methods and their behaviours can be managed and manipulated in a similar way to any other objects in the environment. Similarly, there is only one concept in a relational database-table. Information of tables in the database and all user data are all stored in tables. Accordingly, the system data and user data can be managed and manipulated in a similar way.

From the similarity of the past, we can expect that there would have further similarities between them in the future. For example, database theory has developed toward an distributed and object-oriented database. So we can try to describe how CASE can also develop toward these two directions.

8.2 Supplement requirements of the future CASE

A meta CASE environment provides flexible support to different meta-models and methodologies. But many of these advanced technologies [5] are for method engineers, not for end users - the designers. From the point of a designer, the following requirements are also needed in the future CASE.

8.2.1 Methodology & Tool Base

Although a meta CASE environment has powerful ability to represent different methodologies, the designer has no time, experience and does not like to define a new methodology. All he wants is to use a familiar methodology and associated design tools. A methodology and tool base which contains numerous methodologies and tools is important to meet this requirement.

8.2.2 Documentation

As the number of available methodologies and tools increases, the complexity of the future CASE environment will also increase greatly. Well organized documentation is very important to reduce the complexity to master a CASE environment. Multi-level documentation, e.g., samples, descriptions and formal definitions are all needed for designers of different levels and with different needs.

8.2.3 Verification of models

Many supports have been provided by CASE environments when a designer designs an IS: different methodologies and tools can be selected, metrics can be calculated automatically, some transformations can be done, concurrent control is supported, user-to-user communication is provided. However, the very basic thing of a model-correctness is neglected to some extent. After the designer finishes the design in a stage, he can not know whether it is right or not because he can not ``run'' it. Therefore, some extent of verification of models in the early design stages are very valuable. The earlier a error is detected, the less effort and cost to correct it is needed. This verification may be achieved by defining semantics, constraints and other specified rules in the model. 

References

[1] Germinal Boloix, Paul G. Sorenson. Software Metrics Using a Metasystem Approach to Software Specification

[2] Germinal Boloix, Paul G. Sorenson, J. Paul Tremblay. Transformations Using a Meta-system Approach To Software Development

[3] Dinesh Gadwal, Piotr S. Findeisen, Paul G. Sorenson, J. Paul Tremblay, L. Beth Millar. Generating Real-Time Systems Development Environment Using Metaview

[4] Steven Kelly, Kalle Lyytinen, Matti Rossi. MetaEdit+ A Fully Configurable Multi-User and Multi-Tool CASE and CAME Environment

[5] Pentti Marttiin, Kalle Lyytinen, Matti Rossi, Veli-Pekka Tahvanainen, Kari Smolander, Juha-Pekka Tolvanen. Modelling Requirements For Future Case: Issues and Implementation Considerations

[6] Matti Rossi, Sjaak Brinkkemper. Complexity Metrics For Systems Development Methods and Techniques

[7] Kari Smolander, Kalle Lyytinen, Veli-Pekka Tahvanainen, Penttl Marttiin. MetaEdit-A Flexible Graphical Environment for Methodology Modelling.  



Cool Links

Please report any problems with this document to wew036@cs.usask.ca
This page is last modified on Sunday March 14, 1999