Service based Model of CASE

Environment, Properties and

Types of Integration Mechanism
Ali Haider
We will discuss
• Introduction to Service based Model of CASE Environment
• PSE Reference Model
• Description of Reference Model Services
• Uses of Reference Model
• Introduction to Properties and Types of Integration Mechanism
• Properties of Integration
• Relationship between data and control Integration
• Presentation Integration
Introduction to Service based Model of
CASE Environment-1
• Three level model is already discussed which consist of services,
mechanism and processes
• Now the core focus is the services of CASE Environment
• Reference Model is developed to reduce the complexity
• Project Support Environment Reference model developed by U.S.
Navy Next Generation Computer Resources (NGCR) Program
• The Project Support Environments Standards Working Group
(PSESWG) defined an environment reference model as its starting
point for selecting interface standards
Introduction to Service based Model of
CASE Environment-2
• A reference model is, however, intended to help understand integration issues in
an environment,
• and to provide a basis for identifying interface areas. Where possible, such
interfaces may be standardized, thus improving the ability to:
• understand, compare, and contrast available technology,
• relate users' requirements to actual implementations, and
• assess the ease (or otherwise) with which different software tools and products can be
integrated
• A service-based model avoids binding to any particular current environment
architecture.
• Finally, the PSESWG approach does not focus on a particular commercial tool,
product, or environment.
Importance of Interfaces
• PSESWG therefore also considered the concept of interfaces and
interface areas (i.e., collections of interfaces) as being of great
importance to tool integration.
• There are many interfaces that must be considered in tool integration,
not just the interface between two environment services.
• For example, the interface between a service and an end-user making
use of that service, interfaces internal to a service, and an interface
between an end-user service and the framework services that
support it must all be considered.
PSE Reference Model-1
• The PSE Reference Model is a conceptual description of the
functionality that may be provided by a CASE environment.
• The Centrality of Services in the Reference Model
• The central notion of the PSE Reference Model (and also of this
book's model of integration) is that of a service.
• In contrast to a service, we also can observe both the actual software
component that provides this service (often called a tool), and the
human work (often called a task) for which this service is necessary
PSE Reference Model-2
• Differences Between Conceptual Models and Actual Environments
• The conceptual viewpoint that governs the reference model provides
an abstract description of the functionality that may be found in an
environment.
• An actual viewpoint would describe a particular realization of the
conceptual view in terms of an environment architecture with specific
tools and standards.
Description of Reference Model Services-1
• The reference model is a catalog of service descriptions spanning the
functionality of a populated environment.
• The service descriptions are grouped in varying ways, either by
degrees of abstraction, granularity, or functionality.
• The highest-level division classifies services either as end-user or
framework services.
• The former includes services that directly support the execution of a
project (i.e., services that tend to be used by those who directly
participate in the execution of a project such as engineers, managers,
and secretaries).
Description of Reference Model Services-2
• Technical Engineering Services are subdivided by specific engineering
domains (e.g., software engineering).
• In addition to "traditional" engineering domains, the reference model
also considers life-cycle processes to be an area for which an
engineering discipline is appropriate, and services related to that
domain are included here as well.
• Within an engineering domain the processes used in the life cycle of a
project define a series of tasks, each requiring services for its support.
Description of Reference Model Services-3
• Project Management and Technical Management Services: There are two categories
of management services: project management and technical management.
• Services in the project management category include those relevant to planning and
executing a program or project.
• Services in the technical management category provide a managerial complement to
engineering activities in the areas of configuration management, reuse, and metrics.
• The following project management services are described in the reference model:
planning, estimating, risk analysis, and tracking.
• The following technical management services are defined in the reference model:
configuration management, change management, information management, reuse
management, and metrics.
Description of Reference Model Services-4
• Support Services include those associated with processing, formatting, and
disseminating human-readable data, including several common text and figure
processing services, as well more specialized publishing, user communication, and
presentation services.
• They also include administration services that provide support for use of the
environment itself.
• The reference model describes the following support services: common support
services (including text processing, numeric processing, figure processing, audio and
video processing, calendar and reminder, and annotation); user communication
services (including mail, bulletin boards, and conferencing); administration services
(including tool installation and customization, PSE user and role management, PSE
resource management, PSE status monitoring, PSE diagnostic, PSE interchange, PSE
user access, and PSE instruction).
Description of Reference Model Services-5
• Framework Services comprise the infrastructure of an environment.
• They include those services that jointly provide support for applications, for CASE
tools, and that are commonly referred to as "the environment framework."
• Since 1989, NIST has sponsored a series of workshops developing a reference model
specifically for environment frameworks.
• The product of that group is a document published jointly by NIST and the European
Computer Manufacturers’ Association (ECMA), and is commonly known as the
NIST/ECMA Frameworks Reference Model [62].
• This document contains detailed descriptions of 50 framework services.
• The reference model defines the following framework services: object management,
process management, communication, operating system, user interface, and policy
enforcement.
Description of Reference Model Services-6
• Rationale for the Service Groupings in the Model: In the widest sense, all users of the computer
system are ultimately participating in project execution.
• However, the reference model distinguishes end-user services as those that are directly related to
project execution.
• Using the example previously cited, i.e., tool installation versus engineering activities, installing a
• tool clearly can facilitate the eventual engineering process.
• However, services specifically related to tool installation are conceptually different enough from
• services that directly support high-level engineering activities that the reference model considers the
classification of tool installation appropriately as a framework service and not as an end-user service.
• There are other criteria by which services are grouped in the reference model.
• Often a collection of services provides the functionality needed to support a common resource.
Uses of Reference Model
• While our particular interest in the reference model is related to our
examination of CASE tool integration, there are also some immediate
and pragmatic uses for the reference model, particularly in defining or
characterizing an integrated environment.
• We now consider some of these, including: choosing interface areas for
potential standardization; producing mappings and comparisons based
on the reference model; describing the integration requirements of a
system; and defining tool and environment architectures.
• We briefly examine each of these potential uses of the reference model.
Choosing Interface Areas for Potential
Standardization
• To realize interaction among services we must distinguish both the semantic
aspects of the interface (i.e., the process aspects), and the mechanistic
aspects (i.e., the use of different services to provide those semantics).
• Interfaces among end-user services generally reflect the semantics of
interaction among those services.
• Typically, these interfaces can be expressed in a number of forms, such as
domain data models, service functions that can be requested by end-users
or by other services, or behavioral models describing the behavior of the
service based on external input.
• These interfaces may be provided by the framework services in different
ways, depending on the architecture of the environment.
Mapping Environment Implementations to
the Reference Model
• A key activity within the PSESWG work is the validation of the reference model through its
application either to an interface standard or to existing tools and environments.
• This activity is commonly called a mapping.
• Although producing a mapping is an extremely useful exercise, it is not a simple task.
• First, the complexity of most environments means that performing a mapping activity
• is a non-trivial undertaking.
• When done properly, the effort involved can consume several labor weeks.
• Second, both the system to be mapped and the reference model must be well understood by the
individual doing the mapping, and there are few people with the needed combined expertise.
• Third, based on the quality of existing mappings [66], it is evident that detailed mapping
guidelines, examples, and perhaps even training are fundamental to promoting consistency
across mappings.
Describing the Integration Requirements of a
System
• By defining a system's services, the reference model can be used as a
basis for describing the integration requirements of a system.
• The advantage of doing this is that these requirements can be
described in an abstract way, in terms of required services and the
interfaces necessary among and within those services.
• This is independent of particular implementation constraints, which
can then be examined in the light of the abstract requirements.
• As an example, when considering the integration of a number of tool
products with a particular framework product, the reference model
can help in a number of ways.
Defining Tool and Environment Architectures
• The implementation of services and their corresponding interfaces are an architectural
consideration.
• Since the reference model is explicitly a purely conceptual device, there is also the need to
analyze existing architectural models using the language and service categories of the
reference model as the common basis from which they can be described.
• By performing such analyses, common interfaces across a set of architectures will become
apparent, and details of the selections of interface standards at those interfaces can be
compared.
• Concurrent activities in examining the requirements for environment interfaces and in
collecting descriptions of candidate environment standards also contribute to this goal.
• The reference model and the interface areas identified by it should be able to
accommodate a number of different tool and environment architectures and tool
integration approaches.
References
• Principals of CASE Tools Integration Chapter (Service based Model of CASE Environment)