APMTool Home Page

General Description

The APMTool is the software implementation of the Aspectual Predesign technique allowing to convert non-functional requirements into a model residing between requirement analysis and conceptual design and to map this model into the conceptual model. More complete information about this technique can be found in the following paper:

Shekhovtsov, V.A.; Kostanyan, A.V.: Aspectual Predesign. In: Kaschek, R.; Mayr, H.C.; Liddle, S. (eds.): Information Systems Technology and its Applications - ISTA'2005. Lecture Notes in Informatics P-63, GI-Edition, 2005, pp. 216-226. (pdf version).

Architecture

The main requirement for the architecture of the predesign tool is its flexibility and extensibility. To meet this requirement, it is necessary to develop the format for internal representation of aspectual predesign model. This format is based on XML, we call it Predesign Exchange Format (PEF). It was designed based on the glossary representation of the model but it is flexible enough to be able to represent other external representations (e.g. the semantic network representation). All the data exchange inside the system is performed using the PEF.

The APMTool has extensible three-tier architecture based on the Java platform. It consists of the following parts:

  1. System kernel. The APMTool kernel is responsible for transferring the information between other parts of the system and coordinating their work. It is implemented using the Spring lightweight container. The main component of the kernel is a PEF-processing engine that parses PEF structures into the core objects trees. Core system components correspond to the instances of the APM artifacts such as thing-types, connection-types, and operation-types. These components are plain Java objects, their integration into the system infrastructure is supported with Spring extensibility mechanisms based on dependency injection pattern. This pattern implies that the intercomponent dependencies are not built into the code but rather specified into the separate configuration file so to add support for the new kind of object or alter the dependencies no code changes are necessary. The kernel delivers events for the different parts of the system. For example, obtaining new requirements from the requirements engine leads to firing an event that will force the presentation layer to update the view and the data access layer - to start the database transaction.
  2. Requirements engines. The requirements engine is responsible for processing the requirements specifications. It can be done via natural language processing techniques or by other means. All these engines must present the results of their analysis in PEF format. They will be transferred to the core for further processing. The system can contain several different requirements engines implementing different approaches to requirement analysis. For now, only the interface with requirements engines is specified along with the Java library for creating PEF documents that can be used in their code. This part of Aspectual predesign is a target of future research.
  3. Mapping modules. The APMTool has to support different AOSD design notations such as aSideML, Theme/UML, and AODM, and allow the user to easily add support for the new notations. The reason for this requirement is the relative unstability of the AOSD design standards. Currently there are no official standard for the AOSD design notation and it would be unwise to tie the implementation to one particular notation. The mapping rules for the particular aspectual design notations are implemented in the mapping modules. This module obtains the PEF data as its input, after that the mapping rules for the corresponding design notation are applied to this data. As a result, the conversion into the format specific for this notation is performed (in most cases, the target format for this conversion is XMI, but proprietary formats can also be used). No diagram-specific information is supposed to be added to the XMI data.
  4. Data access layer. The APMTool data access layer consists of the two base components. First component (APMWriter) converts PEF-representation into the relational format and stores it into the database, second component (APMReader) obtains the data from the database and performs reverse conversion. In the current version of the system, both these components use pure JDBC, as a result APMTool can be used with any DBMS that has JDBC driver. The system architecture does not require DBMS-specific code (stored procedures, triggers etc.), the database is supposed to be used exclusively for storing the data. The requirements for DBMS are flexible because it is not currently expected to use APMTool under heavy load or with large amount of data. APMTool currently uses MySQL 5 for storing the data.
  5. Presentation/verification layer. This layer allows the user (business analyst or system administrator) to look at the APM artifacts in the user-friendly format and to perform the verification of the model. This layer obtains the PEF-data from the kernel, performs their parsing, shows their representation to the user, interact with the user, and send the verified data back to the kernel. The presentation/verification layer is not tied to one particular implementation, the only requirement for its code is the PEF support. In fact, the system can use several such implementations at the same time. In the current version of the system AWT-based interface is implemented, it is planned to add web-based interface in future, in this case XSLT can be used to map PEF into XHTML.

Developers

  1. Vladimir A. Shekhovtsov
  2. Arkady V. Kostanyan
  3. Eugene Gritskov
  4. Yury Litvinenko
Contact: shekvl@yahoo.com

Downloads

  1. APMTool-0.0.1
    Prototype of the presentation/verification layer (AWT/Spring)
  2. PEF XML schema
  3. Sample PEF file
SourceForge.net Logo