PROCESS CENTERED SOFTWARE ENGINEERING ENVIRONMENT - INFORMATION MANAGEMENT
ABSTRACT:
Software engineering environments have a history of about 2 decades. The Process centered software engineering environments are acknowledged tools that help in the planning, management and execution of various software projects. The (PSEE) devote a great amount of significance to the information stored in these environments. Every PSEE has its own way of storing the information. The information stored is of such high interests because it contains both the product data and process enactment data. The PSEE can store this information either using extensions of commercial database technologies or they can be store in a repository for quick retrieval. This paper gives an overview of Process Centered Software engineering and deals with the problem of effective information management.
INTRODUCTION:
Software engineering environments (SEEs) are meant to support software development. Most of them are focused on a certain type of software processes. Most SEEs are based on a hard-wired (or predefined) software process model. They support exactly that type of software process and no other processes. Either a user accepts that process or he cannot use the SEE.
Process-centered software engineering environments (PCSEEs) give up the notion of a predefined process model[1]. They support a wider variety of processes. A PCSEE provides modeling, monitoring and measurement of software development. Thus it supports concurrent team work. The objective of this paper is to provide a comprehensive understanding of PCSEEs and means to manage project information.
Process-centered environments are distinguished from the other environments by the fact that they automate, guide and enforce a specific software process according to a formal model of the process. The PCSEE include a component called PROCESS ENGINE, which interprets with the process model and automates process fragments, invoke tools, enforce policies etc. Process-centered environments typically handle two separate functions: Process model production and enactment.
A process centered software engineering environment uses one of the following for maintaining data.
a) A relational database management system
b) An object oriented database management system
c) A hybrid database management system
c) A special purpose repository
Architecture of a Process Centered Software Engineering Environment:[1]
The architecture of a PCSEE consists of three components
a) Multi-user Interface component
b) Process Support Component
c) Information Management Component
The architecture of a standard PCSEE is shown in FIGURE 1
The multi-user interface supports multiple, possibly distributed, user clients and programs. The process support component (PS) contains one or more process enactment engines, each of which provides one or more process modeling formalisms. All process enactment and process execution activities pass through the PS.
The information management component (IM) is responsible for maintaining the consistency and availability of the information needed by the other PSEE components. It stores this information in a REPOSITORY, by which we mean a container of data. The repository may be composed of multiple database systems and/or collections of files that are managed by the underlying file system. In the case of a heterogeneous repository, there is a need for an INTEGRATION LAYER to manage activities that span multiple databases, integrity constraints across database boundaries, and so on. The IM interacts directly with the multi-user interface to allow querying and browsing of the data stored in the repository. The PS communicates information about enactment transition, user requests, and activity executions to the IM. The ACCESS MANAGEMENT LAYER of the IM uses the information from the PS to create transactions, determine permissions, and obtain locks, and so on. It provides the requested information to the PS only if the request does not violate the specification for consistent access to the repository.
The PSEEs can help automate, enforce, and monitor aspects of the software process with this concrete architecture. As we look into the Information management component, we have certain requirements that every data management system should satisfy for an ideal PCSEE. But, in most cases these are not completely satisfied by the current database systems.
The following are the Information Management requirements categorized.
· Data Composition and structure
· Consistent Access to Data
· Abstraction and views
· Evolution
· Distribution
· Tool Integration and Interoperability
ARCHITECTURE OF A TYPICAL PSEE
FIGURE 1 [1]
The PSEEs can help automate, enforce, and monitor aspects of the software process with this architecture.
1.1 Data Composition and Structure
A software development project typically generates many different forms of data_ like product data, process data, organizational data etc.
The IM in a PSEE must efficiently handle the storage and retrieval of all the data forms. For example, it must implement schemes for disk layout and clustering of data that are commonly accessed together, and it must implement schemes for transforming data items from their main memory representations to their persistent memory representations (and vice versa) while maintaining relationship information among them.
1.2 Consistent Access to Data
An important function of the IM is to guarantee consistency in the repository data across repeated and concurrent access.
We describe three mechanisms to preserve data integrity:
1.2.1 Data encapsulation:
Preserves consistency at the granularity of a method (i.e., for a single access to a single object)
1.2.2 Transactions and sessions
In traditional data management systems, a transaction is the unit of interaction between an application and the system. It consists of a series of accesses to the database together with some computation. The systems tend to be optimized toward supporting transactions with the following characteristics:
Short duration of execution and limited scope
Completeness
Consistency
Independence
To guarantee consistency at a coarser granularity (i.e., across multiple accesses to one or more objects), a larger unit of synchronization is required, such as a transaction. A session is a lengthy activity that is typically interactive (e.g., an edit and debugging session).
Long-lived interactive execution
Partial completeness
Partial consistency
Interdependence and collaboration
1.2.3 Triggers
A general mechanism for enforcing constraint maintenance is a facility for triggers. A trigger is a three-tuple < event condition action >, where the action executes upon the occurrence of the event if the condition holds. A triggering and notification mechanism is also useful for coordinating the collaborative development of a software project. For example, a triggering mechanism can be used to send notifications to a developer whenever another developer performs a specific action that affects the first developer’s work.
1.3 Abstraction and Views
A schema describes the data in a repository at a fine granularity and with great detail. An abstract view hides certain details of data, and provides a layer for accessing only the part of the data that is visible under the abstraction.
1.4 Evolution
If there is a constant that is common to every software system, it is this: the system is bound to evolve. Managing change is primarily a problem of managing dependencies. There are two kinds of change that a PSEE must manage: changes in the application data and changes in the schema (meta data).
1.5 Distribution
Typically, PSEE users are on different workstations, and they are connected by either a local area network (e.g., Ethernet) or a wide area network (e.g., Internet. The IM must provide support for distribution, such as management of distributed sessions, location transparency, and a protocol for data replication and/or caching.
1.6 Tool Integration and Interoperability
The aim of a PSEE is to support the development of large-scale software[2]. Currently, there are numerous tools in widespread use that automate parts of the software development process and manage information A more feasible PSEE architecture is one in which the repository may incorporate a combination of different storage systems, including files and either commercial or proprietary databases, and in which the IM provides an extensible interface that facilitates integration of existing and new software tools. An open architecture can therefore accommodate data that are not in a single location under the control of a single tool, and it can interoperate with applications written in a variety of programming languages.
The database Systems that were initially used for a PCSEEs were either a Relational Database Management System or an Object Oriented Database management System. Both of these had their advantages and disadvantages. These were not widely preferred because they had too many shortcomings. Let us analyze these database systems to find what exactly urged the engineers to invent newer ways of information management.
The RDBMS and ODBS –an overview: Reason for ineffectiveness:
The RDBMS is very popular database system. They have steadily been progressing and improving their model according to the needs. They adopt a query language called Structured Query Language (SQL), which helps in fast retrieval of database. A major development in RDBMS models is the emergence of client/server computing model.
The Object database system was proposed to solve some of the limitations of the RDBMS. The ODBS combines object-oriented programming with database technology. These database systems deals with objects and attributes. Every object has an attribute, which in turn leads to sub-objects for class objects and thus form a composite object hierarchy.
Both the ODBS and RDBMS had a few shortcomings. A PCSEE was never complete with the use of a single database management system. Every system lacked something. Some of the limitations with the use of RDBMS in an information management system are,
They do not support user defined types.
They do not support data encapsulation.
They do not support versioning at all.
They do not provide sufficient support for maintaining general forms of data.
The limitations involved with ODBS are,
They lack a standard query language like SQL
Integration of applications written in other programming languages (other than the one used) is complicated.
So, the engineers came up with the concept of a hybrid system combining both the goods of both ODBS and RDBMS. But, these hybrid systems were not as stable as the individual ones .So that again turned out to be a limitation.
THE NEXT STEP TOWARDS INFORMATION MANAGEMENT
Information management is an integral part for any PCSEE. Since all of the databases systems reviewed so far haven’t produced the desired management, the PCSEEs are being developed with a special purpose repository which is maintained according to the need of the environment. These are called “home grown” repositories.
We will initially look at the use of repositories in a PCSEE. We will then move over to the examples of special purpose repositories. Then we switch over to PCSEE with Network Centric Computing and analyze the information repositories used in those cases. We also look at the implementation of an information repository for a software process to be mobile. These software processes use distributed repositories. Further, we look at Repository based approach for PSEE
DEFINING SOFTWARE ENGINEERING REPOSITORIES:
Practically all the PSEEs rely on a repository. Although each PSEE has its own characteristics that can result in different requirements for the repository it is nevertheless interesting to consider the storage systems used by some of the outstanding PSEEs. The overview is organized according to the following classification of the storage systems:
· File system;
· Ad-hoc repositories;
· Commercial repositories, further distinguished according to the data model.
File system based PSEEs In general, a PSEE has to allow the usage of traditional development tools. These tools are usually file-based programs, i.e. the read data
from files and write results into files. Therefore, many PSEEs store data in the file-system
The successful construction of a software repository depends largely on the data model implemented by the underlying database system. While the relational data model is generally not considered powerful enough for the modeling of software repositories, the object-oriented and more recently the object-relational data model have been successfully used for this purpose. Special-purpose data models have also been developed. The evolution of a software repository can be supported by meta level mechanisms (i.e., metadata and meta-object protocols as implemented in some object-oriented DBMS) which operate on the types of the stored artifacts.
Probably the most important and comprehensive standardization effort in defining a software repository is the Portable Common Tool Environment PCTE [53]. PCTE defines a set of open interfaces that can be used by software engineering tools thus, enabling their seamless data, presentation, and control integration. The interfaces provide
§ object lifecycle management
§ Schema management
§ Program execution and communication
§ Concurrency and integrity control
§ Security policy enforcement and auditing
§ Physical data distribution management
§ Resource accounting.
A PCTE-compliant repository supports a graph-based data model that can be used to describe typed design, implementation, execution and documentation objects, as well as the relationships (links) between them
Despite its functionality, PCTE has only been used in relatively few PCSEE (e.g., ALF [12]) as it is hampered by a number of important deficiencies, including the lack of support for object-oriented modeling and triggers. A number of extensions to PCTE have been developed, such as H- PCTE [37] and P-RooT [13] which overcome these limitations. Therefore the information management is starting to become easier with such repositories.
Distribute PSEE-An overview over distributed process repositories:
Software processes tend to be distributed. Another trend for PSEE is that software processes become more and more mobile and federated. Thus, PSEEs should not assume that software processes are central processes to be carried out by a single team at a single site. Instead they have to offer infrastructure for processes which take place at many places. Therefore, PSEEs and addition to the process specific services will also have to provide typical middleware services
If a process is distributed, then the software process repository should also be distributed. Consistency of a distributed software process repository is difficult to maintain. Even though processes may differ substantially, the basic mechanisms for repository consolidation and consistency preserving are more or less the same. It has to be defined, which kind of objects can be duplicated and for which it is crucial that unique master versions are available and accessible from all sites, which intervals of inconsistency between duplicated objects are acceptable etc. These are the kinds of repositories for mobile software processes.