Download PROCESS CENTERED SOFTWARE ENGINEERING

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 objectoriented 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.
Repository based PCEE
A Repository based Approach for Process Centered Engineering Environments, called
RAPCEE enables the different kinds of process support (guidance, control,
enforcement), the capturing of process traces, as well as the improvement of process
definitions based on the trace information. As depicted in figure, RAPCEE consists of
three parts, the process definition environment, the process repository, and the process
execution environment, which are briefly characterized below.
figure 2 RAPCEE BASED PCSEE[[4]
The process execution environment and process definition environment are managed by
the application engineer and the method engineer respectively. Let us look into the
process repository, the central storage unit.
Process repository:
The various kinds of data are recorded and interrelated in a central repository, which is
based on the central information. At the upper level (Definition Schema Layer), the
languages for representing concrete process models (Process Meta Model) and the
traceability models (Traceability Meta Model) respectively, are defined in figure 2.
Whereas these languages are domain independent, the process models and the trace
models defined at the middle level (Definition Layer) are domain dependent. For the
domain of requirements engineering, we have defined a traceability structure according to
the three dimensions of requirements engineering
A Brief look into the repositories used in NCC model of PCSEE
A process centered software engineering with network centric computing (NCC) is a
distributed environment that supports interoperability and cooperation. It has three layers.
A kernel, intermediate and user-interface layer. The intermediate layer consists of a web
data repository and the user interface layer consists the process repository. The web data
repository is accessed in cases where the request is a data retrieving message. It is
accessed by the web server through the file system. The process server in this system acts
as the process engine that manages the state of the process engines and selects the next
process to run. It does not directly access the process repository. It can have access to the
process repository only through an object server.
Architecture of PCSEE with NCC[3]
This approach of PCSEE with NCC overcomes the shortcomings of the client
server model.
The repositories are used to store data for information management in most of the present
day PCSEEs. The various kinds of usage of repositories in different environments sum up
the importance of information management.
Conclusion:
This paper explored the process centered environments and the various kinds of
information management problems in different PCSEEs. Initially, the paper described the
traditional database management systems that were used for process centered
environments. On further exploration, these database management systems were found to
be short of certain requirements for information management. Many PCSEEs were built
with special purpose repositories that either extend these databases or the ones that are
built to satisfy the requirements of the specific process.
The interest then shifted over to the repositories that store the data for PCSEE.
We then look into the most important and comprehensive standardization effort in
software repository, the Portable Common Tool Environment PCTE [53].The interest
then shifts over to the Repository Based Approach for Process Centered Software
Engineering Environment. Finally we, look into the PCSEE with Network Centric
Computing. We study the way the repositories function in such a distributed process
environment.
Mobile process support is the latest trend in process engineering. The distributed
software process repository is used effectively in a distributed e process. The use of the
repositories in such a versatile manner in different PCSEEs for distributed process
management has brought a real turnaround. The paper has summarized the information
management problems in PCSEEs and has gradually proceeded towards improving the
same in different Process Centered Software Engineering Environments.
References:
[1]NASSER.S.BARGHOUTI,
WOLFANG
EMERICH,WITHELMSCHAFER
Information Management in Process Centered Software Engineering Environment
[2]VOLKER GRUHN process centered software engineering environments- a brief
history and future challenges
[3]MING- FENG CHEN BIN SHJANG LIANG AND FENG -JIAN WANG a process
centered software engineering environment with network centric computing
[4] Klaus Pohl, Ralf D¨omges, Matthias Jarke decision oriented process modelling