APPLYING SOFTWARE FACTORIES TO PERVASIVE SYSTEMS:

A PLATFORM SPECIFIC FRAMEWORK

Javier Mu

noz

Technical University of Valencia

Cam

ı de Vera s/n, E-46022, Spain

Vicente Pelechano

Technical University of Valencia

Cam

ı de Vera s/n, E-46022, Spain

Keywords:

Pervasive systems, frameworks, MDA, software factories, templates, model transformation.

Abstract:

The raise of the number and complexity of pervasive systems is a fact. This kind of systems involves the

integration of physical devices and software components in order to provide services to the inhabitants of

an environment. Current techniques for developing pervasive systems provide low-level abstraction primitives

which makes difﬁcult the construction of large systems. Software Factories and the Model Driven Architecture

(MDA) are two important trends in the software engineering ﬁeld that can provide sensible beneﬁts in the

development of pervasive systems. In this paper, we present an approach for building a Software Factory for

pervasive systems, focusing in the deﬁnition of a product line for this kind of systems. We introduce a software

architecture for pervasive systems, which is supported by a software framework implemented using the OSGi

technology. Then, we integrate the framework into the MDA standard deﬁning the framework metamodel and

providing tool support for the automatic code generation.

1 INTRODUCTION

Pervasive systems try to build environments where

computation elements disappear from the user point

of view but their functionality is still provided. This

vision was initially described by Weiser (Weiser,

1991) in the early 90s and it is based on the con-

struction of computing-saturated environments prop-

erly integrated with human users.

The application of model driven approaches to this

ﬁled can provide many beneﬁts (Fernandes et al.,

2004). Software Factories (Greenﬁeld et al., 2004)

and the Model Driven Architecture (MDA) (Object

Management Group, 2003) provide strategies for rais-

ing the abstraction level in the software development

process and making affordable the development of

complex systems. The application of the guidelines

deﬁned in these approaches to pervasive systems de-

velopment can help to build better systems in an easier

way than applying traditional methods.

This paper presents an approach for building a Soft-

ware Factory for pervasive systems development, fo-

cusing in the deﬁnition of a product line for this kind

of systems. The structure of the paper is the follow-

ing: Section 2 brieﬂy introduces our application of

Software Factories and MDA to Pervasive Systems

Development. Section 3 describes Pervasive Systems

main characteristics and it presents our point of view

for developing this kind of systems. Based on the pre-

vious analysis, section 4 proposes an architecture for

implementing pervasive systems. This architecture is

supported by a framework which is introduced in sec-

tion 5. In order to integrate this framework into an

MDA environment, section 6 shows the framework

metamodel and templates for generating code from

the metamodel. All these contributions constitute a

practical application of the Software Factories and

MDA approaches to a speciﬁc domain: the pervasive

systems. Finally, section 7 includes some conclusions

and further work.

2 A SOFTWARE FACTORY FOR

PERVASIVE SYSTEMS

The development of a pervasive system implies the

use of many different technologies in order to sat-

isfy all users’ requirements. Usually these technolo-

gies provide low abstraction level constructs to the

developer. Therefore, applying a MDA approach to

pervasive systems supposes jumping a very wide ab-

straction gap that must deal with the heterogeneity

337

Muñoz J. and Pelechano V. (2006).

APPLYING SOFTWARE FACTORIES TO PERVASIVE SYSTEMS: A PLATFORM SPECIFIC FRAMEWORK.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 337-342

DOI: 10.5220/0002457603370342

 SciTePress

of the technology. Fig. 1 describes three strategies

for ﬁlling this abstraction gap: (Fig.1.1) generating a

large amount of code, (Fig.1.2) building a framework

that raises the abstraction level of the target technol-

ogy and then generating a minimum amount of code,

(Fig. 1.3) manually reﬁning the model in order to de-

crease their abstraction level until achieve the abstrac-

tion level of the target technology and then generating

a minimum amount of code.

Platform

Generated Code

Model

Platform

Framework

Generated Code

Model

Platform

Generated Code

Model

Figure 1: Strategies for ﬁlling the abstraction gap. Ex-

tracted from (Greenﬁeld et al., 2004).

The Software Factories approach follows the second

strategy. A framework for pervasive systems should

be developed applying domain engineering princi-

ples. This framework raises the abstraction level

of the target platform and, therefore, the amount

of code is sensiblely reduced. Thus our proposed

methodological approach to pervasive systems de-

velopment, which was presented in (Mu

noz and

Pelechano, 2005), is based on:

• the construction of a domain speciﬁc language for

the description of pervasive systems.

• the construction of a framework that raises the ab-

straction level by providing similar constructs to

those deﬁned by the domain speciﬁc language.

• the deﬁnition of rules for the transformation of

models, that are built using the domain speciﬁc lan-

guage, to code that fulﬁlls the deﬁned framework.

Following this strategy, ﬁrst we have deﬁned Perv-

ML (Pervasive Modeling Language), a Domain Spe-

ciﬁc Language (DSL) for specifying pervasive sys-

tems in a technology independent fashion (Mu

noz

et al., 2004). Perv-ML promotes the separation of

roles where developers can be categorized as analysts

and architects.

Systems analysts capture system requirements and

describe the pervasive system at a high level of ab-

straction using the service metaphor as the main con-

ceptual primitive. Analysts build three graphical

models that constitute what we call the Analyst View.

In these models the analyst describes (1) the kinds of

services (by means of their interfaces, their relation-

ships, their triggers and a Protocol State Machine for

specifying the behavior of each service), (2) the com-

ponents that are going to provide the deﬁned services

and (3) how these components interact to each other.

On the other hand, system architects specify what

COTS devices and/or existing software systems im-

plement the system services. We call binding

providers to the elements that are responsible of bind-

ing the software system with its physical and logi-

cal environment. For instance, a lighting sensor is

in charge of measuring a physical feature of the en-

vironment, whereas an e-mail server allows sending

information to agents that are out of the scope of the

system. Architects build other three models that con-

stitute what we call the Architect View. We need to

build a detailed speciﬁcation of the lower level arti-

facts that realize system services in order to have a

complete and operative pervasive system description.

In order to achieve this goal, the architect describes

(1) every kind of binding provider (their interfaces

and their relationships), (2) the binding providers

which are used by each system component, and (3)

which actions should be executed when a component

operation is invoked.

The development process starts from a Perv-ML spec-

iﬁcation which is transformed using our model-to-

model transformation tool (we are currently working

with the AGG

graph grammars engine) into a model

(PSM) that is built using implementation concepts.

This paper is focused in the PSM building block. In

the context of MDA, the implementation framework

for pervasive systems can be considered a platform,

since it provides an implementation environment for

our platform independent language. The construction

of the framework has followed the Software Factories

guidelines. This approach proposes a product line like

strategy, which is composed, in short, by the follow-

ing steps (Greenﬁeld et al., 2004, chapter 11):

1. Product Line Analysis. Its purpose is to decide

what kind of systems the product line will develop.

In order to achieve that goal, the scope of the sys-

tems to be developed should be speciﬁed.

2. Product Line Design. Its purpose is to decide how

the product line will develop the software products.

In order to achieve that goal, an architecture for the

systems to be developed should be speciﬁed.

3. Product Line Implementation. Its purpose is to

supply the implementation assets required by the

product line architecture. In our case, we are go-

ing to implement a framework for supporting the

speciﬁed architecture.

Next sections give an overview of each step.

3 PRODUCT LINE ANALYSIS

Requirements for current and future pervasive sys-

tems involve a great diversity of types of services.

http://tfs.cs.tu.berlin.de/agg/

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

338

Such different services as multimedia, communica-

tion or automation services need hardware devices

that different manufacturers provide and external soft-

ware systems. These elements live in several net-

works running on different technological platforms,

but they can not satisfy isolatedly all system require-

ments. In this context, our approach to pervasive sys-

tem development consists of:

• The selection of the suitable COTS devices or ex-

ternal software systems. These elements should

provide the services that users require either isolat-

edly or interacting with other elements.

• The development of the software system that in-

tegrates the external elements in order to pro-

vide the services that users require. The devel-

opment of that software may imply the use of dif-

ferent technologies but some gateway technology

should exist.

In order to provide a software architecture that cor-

rectly ﬁts the requirements of this kind of systems,

we should determine the scope of our applications and

we should identify some basic non functional require-

ments that must be satisﬁed by the assets (the software

architecture and the implementation framework) that

are produced for supporting the product line.

• Support to the conceptual primitives that are

provided by the modeling language. As intro-

duced in section 2, a key goal of our framework is

to rise the abstraction level of the implementation

technology in order to make easier the code genera-

tion from our DSL. Therefore, supporting the Perv-

ML conceptual primitives is a very important issue.

• Integration with external software systems. Ser-

vices provided by pervasive systems can be sup-

plied by physical devices and also by existing soft-

ware systems (multimedia servers, contacts man-

agement software, etc.). Therefore, the integration

with external software systems should be supported

by our framework

• Isolation of the manufacturer-dependent com-

ponents. As outlined above, we consider that a per-

vasive system is built from several COTS elements.

But, on the other hand, our framework should sup-

port the DSL for pervasive systems. Therefore,

in order to integrate these two requirements, the

framework should clearly isolate the manufacturer-

dependent parts from the parts that can be automat-

ically generated.

• Support to multiple user interfaces. Pervasive

systems emphasize new ways of Human-Computer

Interaction (HCI). Different kind of devices and

platforms could be used. Therefore, our systems

should be ready to provide support to several kinds

of user interfaces.

4 PRODUCT LINE DESIGN:

DEFINITION OF A SOFTWARE

ARCHITECTURE

Our proposed architecture for pervasive systems has

been designed in order to support the requirements

introduced in the above section. We apply the Layers

and Model-View-Controller (MVC) architectural pat-

terns (Buschmann et al., 1996) for providing a multi-

tier architecture for the pervasive systems (see Fig. 2).

Interface

Layer

Logical

Layer

Services Layer

WAP

View

Voice

View

Communications Layer

HTML

View

Drivers Layer

Figure 2: Overview of the proposed architecture.

The Drivers Layer is the lowest layer in the archi-

tecture. It is in charge of managing the access to the

devices and to the external software services. In order

to achieve the goals of this layer, drivers should be

manually developed for dealing with manufacturer-

dependent issues. Following this strategy, the drivers

adapt the speciﬁc mechanisms for using the binding

providers (the drivers or APIs supplied by the man-

ufacturers), so a common interface is provided for

every kind of binding provider. This means that, for

instance, all the lamp devices must be adapted to a

generic interface.

The Communications Layer provides a representa-

tion of the binding providers that can be used by the

Services Layer, so it provides a bridge between these

two layers. There is a one-to-one relationship be-

tween the elements in the communication layer and

the elements in the Drivers Layer. Concretely, this

layer holds the manufacturer-independent part of the

binding providers whereas the Drivers Layer holds

the manufacturer-dependent issues. For instance, if

there is a driver in the Drivers Layer for accessing a

light sensor which is located in a particular technol-

ogy control network (like EIB or LonWorks in home-

automation systems), there will be too a light sensor

element in the Communications Layer. The driver

would be in charge of dealing with the speciﬁc issues

of the control technology, whereas their representa-

tion in the Communications Layer would be in charge

of logging the operations calls, updating an icon im-

age representing the state of the device, etc.

The Services Layer provides the functionality as it is

required by the users of the system. The components

APPLYING SOFTWARE FACTORIES TO PERVASIVE SYSTEMS: A PLATFORM SPECIFIC FRAMEWORK

339

that implement the services make use of the elements

in the communications layer or other services in the

same layer. Moreover, interactions between services

which are triggered by some condition can occur.

Finally, the Interface Layer manages the access to

the system by human or software users. We apply

the Model-View-Controller pattern in this layer. Fol-

lowing this strategy, the components of the Services

Layer could be seen as the model whereas speciﬁc

controller and viewers for every supported interface

should be implemented.

Other architectures for pervasive systems have been

proposed (Grimm et al., 2004; Kirby et al., 2003).

Some of them are focused on providing very inter-

esting capabilities like dynamic services discovery or

high robustness. We are very interested in those ad-

vanced features and we plan to extend in the future

our software factory for adding new characteristics,

but they are out of the scope of this version.

5 PRODUCT LINE

IMPLEMENTATION:

BUILDING AN

IMPLEMENTATION

FRAMEWORK

In order to provide support to the architecture that

has been introduced in the above section, we have

developed an implementation framework. We have

selected the middleware OSGi (The Open Services

Gateway Iniatite, 2003) as the implementation tech-

nology, since it has bridges to many of the technolo-

gies used in pervasive systems and provides high-

level implementation constructs. This middleware

help us notably for ﬁlling the abstraction gap between

the domain speciﬁc language and the target imple-

mentation technology.

5.1 An Implementation Framework

for Pervasive Systems

This section brieﬂy describes the implementation

framework for pervasive systems that has been de-

veloped in order to support the proposed architecture.

We do not implement the Drivers Layer because its

software components should be manually developed

in order to deal with manufacturer dependencies.

5.1.1 The Logic Layer

Fig. 3 shows the design classes diagram that repre-

sents the framework classes of the system logic layer.

Classes in this layer can be classiﬁed in three func-

tional groups:

BProvider()

context : BundleContext

bProviderId : String

driverPID : String

driverClassName : String

BProvider

ComponentActivator()

ComponentActivator

Component()

«abstract» enabledOperations()

«abstract» changeState()

«abstract» checkTriggers()

context : BundleContext

componentId : String

state : String

Component

BProviderActivator()

driverPID : String

BProviderActivator

Consumer

Producer

BundleActivator

ServiceListener

producersConnected()

updated()

consummersConnected()

polled()

«abstract» buildProps()

notifyProducers()

notifyConsumers()

wiresProducer : Wire []

wiresConsumer : Wire []

WireParticipant

log()

infoLog()

errorLog()

Logger

getFrameworkElement()

getComponent()

getBProvider()

getDriver()

FrameworkSearcher

serviceChanged()

«abstract» start()

«abstract» stop()

createWire()

«abstract» createAllWires()

serviceClassName : String

serviceSequenceID : String

servicePID : String

location : String

context : BundleContext

FrameworkActivator

LogicElement

Interaction()

«abstract» checkTriggers()

«abstract» executableActions()

context : BundleContext

InteractionId : String

Interaction

InteractionActivator()

InteractionActivator

For mapping

Perv-ML

Components

For encapsulating

OSGi functionality

For life-cycle

management

Figure 3: Design classes for the system logic layer of the

framework.

• Classes for mapping the Perv-ML conceptual

primitives. This functional group is composed

by the classes Component, BProvider and

Interaction. These classes deﬁne several ab-

stract methods which should be fulﬁlled for provid-

ing support to the Perv-ML execution strategy.

• Classes for encapsulating OSGi-related func-

tionality. The goal of this group is to isolate some

OSGi-related functionality that is inherited by the

classes in the previous functional group. Classes

in this group provide facilities for logging events

(Logger), for searching services in the OSGi

framework (FrameworkSearcher) and for par-

ticipating in the event notiﬁcation mechanism sup-

plied by OSGi (WireParticipant).

• Classes for dealing with the system life-

cycle. This functional group is composed

by the classes ComponentActivator,

BProviderActivator and

InteractionActivator.Anactivator

is an OSGi concept which describes the class that

is in charge of registering and unregistering the

services in the OSGi framework when a bundle in

started or stopped.

5.1.2 The Interface Layer

In order to provide support to interfaces in multiple

devices, the Abstract Factory design pattern has been

applied. Moreover, abstract classes have been in-

cluded for making easy the fulﬁlment of two critical

user tasks:

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

340

• The ServiceListing class provides mecha-

nisms for accessing the services. Users can index

the services by the kind of service that they provide,

by their location or ordered by their last use.

• The ServiceUI class supports the creation of in-

terfaces for the management of a kind of service.

This interface shows (1) general information about

the service, like their location or their last use; (2)

speciﬁc information about that kind of service (eg.

the current state of a multimedia service); and (2)

the mechanism (buttons, textboxex, etc.) for using

the functionality provided by that kind of service.

6 INTEGRATING THE

FRAMEWORK INTO MDA

OSGi Code

Perv-ML

Model

Graph Grammars

Framework

Model

Templates

AGG

Framework

Model

FrameworkMM

EMF Library

EMF

Framework

Model

OSGi Code

FreeMarker

Templates

Step 1 Step 2

Figure 4: Integrating the framework into MDA. Tools and

Techniques.

Fig. 4 shows the techniques and tools provided in or-

der to integrate the framework into MDA. The initial

step for developing an application using the complete

Software Factory is the speciﬁcation of the platform

independent model using Perv-ML. Then, our model-

to-model transformation tool converts a XML/XMI

representation of a Perv-ML model into a XML ﬁle

which represents a model built using concepts of

the implementation framework. Then, the generated

XML ﬁle is loaded into a Java data structure which

is used as input to FreeMarker, the templates engine.

As result of the application of the templates, the ﬁnal

source code is obtained. Next subsections describe

the techniques related to the integration of the imple-

mentation framework in this process.

6.1 Platform Metamodel

The MDA standard proposes the construction of

metamodels for deﬁning (the abstract syntax of) new

modeling languages. Therefore, we have built a meta-

model of our implementation framework for perva-

sive systems, which is shown in Fig. 5.

The models generated by our model-to-model trans-

formation tool conforms to this metamodel. The

model-to-model transformation tool performs the

Component

package : String

componentId : String

location : String

BProvider

package : String

bProviderId : String

driverId : String

Interaction

triggerEvaluation : String

PerMLService

package : String

name : String

0..n

-implements_11

-usesBProvders 0..*

0..*

-usesComponents

0..*

-requiredComps1..*

ServiceOperation

name : String

signature : String

returnType : String

-operations

0..*

Method

body : String

-methods0..*

0..*

BProviderInterface

package : String

name : String

BProviderOperation

name : String

signature : String

returnType : String

0..*

-implements1

0..*

State

name : String

isInitial : Boolean

-states0..*

0..*

-enabledOperations 0..*

Transition

-source1

0..*

-destination

0..n

0..*

-operation

Actions

body : String

0..*

Trigger

trigerEvaluation : String

operationCall : String

0..*

-operationActivated1

-triggers

0..*

-specializes

0..*

-specializes

Figure 5: Framework metamodel.

jump of the abstraction gap between the DSL and the

implementation framework.

6.2 Templates for Code Generation

Using the metamodel introduced above we have a

graph-like representation of the pervasive systems

but, in order to automatically obtain the source code

of the ﬁnal application, we need to transform that rep-

resentation into Java ﬁles (since our aim is to pro-

duce OSGi code) and other textual resources (mani-

fest ﬁles, build ﬁles, etc.).

In order to put in practice our product line, we have

used the FreeMarker

template engine. FreeMarker is

a free software engine that works on Java data struc-

tures, and provides a powerful syntax for specifying

templates. We have speciﬁed a set of templates for the

main metamodel elements. These templates navigates

through the metamodel structure (which has been im-

plemented using the EMF plugin for Eclipse

)inor-

der to obtain the needed data for ﬁlling the gaps.

Next, a FreeMarker template for generating a

Component element of the framework is introduced.

This template receives a Component metamodel el-

ement in the comp variable.

<#assign packageName =

"${comp.getPackage()}.${comp.getImplements().getName()}

${comp.getComponentId()}">

package ${comp.getPackageName()};

//Imports here

public class Component extends

org.oomethod.framework.Component

implements ${getImplements().getName()} {

<#list comp.getUsesBProviders() as bProv>

public static String bProvider${bProv.getBProviderId()}

PID ="${bProv.getImplements().getName()}$

{bProv.getBProviderId()}";

http://freemarker.sf.net

http://www.eclipse.org/emf/

APPLYING SOFTWARE FACTORIES TO PERVASIVE SYSTEMS: A PLATFORM SPECIFIC FRAMEWORK

341

</#list>

<#list comp.getMethod() as meth>

public ${meth.getServiceOperation().getReturnType()}

${meth.getServiceOperation().getName()}

${meth.getServiceOperation().getSignature()} {

//Searching the BindingProviders

<#list comp.getUsesBProviders() as bProv>

${bProv.getBProviderInterface().getName()}

bProvider${bProv.getBProviderId()};

bProvider${bProv.getBProviderId()} =

(${bProv.getBProviderInterface().getName()})

this.getBProvider(

${bProv.getBProviderInterface().getName()}.

class.getName(),

bProvider${bProv.getBProviderId()}PID

);

</#list>

<#if meth.getServiceOperation().getReturnType()!="void">

${meth.getServiceOperation().getReturnType()} result;

</#if>

${meth.getBody()}

this.changeState("${meth.getServiceOperation().

getName()}");

this.log("Operation

’${meth.getServiceOperation().getName()}’

invoked on Component ${getPackageName()}");

<#if meth.getServiceOperation().getReturnType()!="void">

return result;

<#else>

this.notifyConsumers();

</#if>

}

</#list>

//constructor, checkTriggers, changeState,

enabledOperations and buildProps definition here. }

Templates like the one presented above have been de-

veloped for the Interaction and BProvider elements.

Moreover, templates for generating their correspond-

ing activators have been developed too, using the data

of the main elements (the ComponentActivator

using the Component data, etc.).

7 CONCLUSIONS AND FUTURE

WORK

In this paper, we have presented and approach for

building a Software Factory for pervasive systems, fo-

cusing in the deﬁnition of a product line for this kind

of systems. We have previously experimented the

beneﬁts of the application of similar approaches. Our

research group have developed a model driven de-

velopment method (called OO-Method (Pastor et al.,

2001)) with full code generation capabilities that has

been implemented in the OlivaNova Model Execu-

tion System

. Our aim is to apply these successful

ideas to pervasive systems development. Concretely,

we are working with a speciﬁc kind of pervasive sys-

tems: home automation systems.

Currently our future work is focused on four impor-

tant tasks: (1) specifying and implementing the rules

http://www.care-t.com/

for automatically transforming the Perv-ML models

into models built using the metamodel introduced

in this work, (2) extending the architecture and the

framework in order to support advanced capabilities

like dynamic evolution or high robustness, (3) provid-

ing new interfaces for accessing the system by means

of new devices, like PDAs, or directly using natural

language, and (4) providing industrial tool support for

the application of the software factory.

REFERENCES

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,

and Stal, M. (1996). Pattern-Oriented Software Ar-

chitecture, volume 1: A System of Patterns. Wiley.

Fernandes, J. E., Machado, R. J., and ao

Alvaro Carvalho,

J. (2004). Model-Driven Methodologies for Pervasive

Information Systems Development. In I International

Workshop on Model-Based Methodologies for Perva-

sive and Embedded Software (MOMPES), pages 15 –

23. Turku Centre for Computer Science.

Greenﬁeld, J., Short, K., Cook, S., and Kent, S. (2004).

Software Factories. Wiley Publising Inc.

Grimm, R., Davis, J., Lemar, E., MacBeth, A., Swanson,

S., Anderson, T., Bershad, B., Borriello, G., Gribble,

S., and Wetherall, D. (2004). System Support for Per-

vasive Applications. ACM Transactions on Computer

Systems, 22(4):421–486.

Kirby, G., Dearle, A., Morrison, R., Dunlop, M., Connor,

R., and Nixon, P. (2003). Active architecture for per-

vasive contextual services. In International Workshop

on Middleware for Pervasive and Ad-hoc Computing

(MPAC 2003). Rio de Janeiro.

noz, J. and Pelechano, V. (2005). Building a Software

Factory for Pervasive Systems Development. In Os-

car Pastor and Joo Falco e Cunha, editor, Advanced

Information Systems Engineering: 17th International

Conference, CAiSE 2005, Porto, Portugal, June 13-

17, volume 3520 of Lecture Notes in Computer Sci-

ence, pages 329–343. Springer-Verlag GmbH.

noz, J., Pelechano, V., and Fons, J. (2004). Model

Driven Development of Pervasive Systems. In I In-

ternational Workshop on Model-Based Methodologies

for Pervasive and Embedded Software (MOMPES),

pages 3 – 14. Turku Centre for Computer Science.

Object Management Group (2003). Model Driven Archi-

tecture Guide.

Pastor, O., G

omez, J., Insfr

an, E., and Pelechano, V. (2001).

The OO-Method Approach for Information Systems

Modelling: From Object-Oriented Conceptual Model-

ing to Automated Programming. Information Systems,

26(7):507–534.

The Open Services Gateway Iniatite (2003). OSGi Service

Platform (Release 3). IOS Press.

Weiser, M. (1991). The Computer for the 21st Century.

Scientiﬁc American, 265(3):94–104.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

342