Coroba a multi mobile robot control and simulation framework by fiona_messe

VIEWS: 8 PAGES: 6

									                        CoRoBa, a multi mobile robot control and
                        simulation framework

                        Eric Colon; Hichem Sahli & Yvan Baudoin
                        Royal Military Academy, Department of Mechanics, Brussels, Belgium
                        Vrije Universiteit Brussel, Department of Electronics & Information Processing, ETRO, Brussels, Belgium
                        eric.colon@rma.ac.be



                        Abstract: This paper describes on-going development of a multi robot control framework named CoRoBa.
                        CoRoBa is theoretically founded by reifying Real Time Design Patterns. It uses CORBA as its communication
                        Middleware and consequently benefits from the interoperability of this standard. A multi-robot 3D simulator
                        written in Java3D integrates seamlessly with this framework. Several demonstration applications have been
                        developed to validate the design and implementation options.
                        Keywords: Distributed control, Middleware, CORBA, Design Patterns, 3D simulation




1. Introduction                                                           (Peterson, L.; Austin, D.; Christensen, H. 2001) has been
                                                                          developed to control a mobile manipulator. It relies on a
Robotic systems are inherently multi-disciplinary and for                 process-algebra for specifying tasks. The main drawback
such applications software aspects are of prime                           in GenoM, DCA and MCA2 are their proprietary
importance. Even a single robot application generally                     communication mechanism. Some frameworks solve the
implies the use of external hardware and sensors having                   aforementioned limitation by building up on
each their own control system and has de facto a                          communication middleware. Miro (Enderle, S & all, 2001)
distributed architecture.                                                 is a distributed object-oriented framework developed in
Many searchers in robotics have been faced with the                       C++ for Linux that is based on CORBA technology. It
difficulty to integrate existing systems into new projects                offers synchronous and asynchronous communication
and to recycle existing code that has been produced by                    and configuration capabilities through XML files. MARIE
preceding projects. What is consequently needed in                        (Mobile and Autonomous Robotics Integration
robotics is software architectures based on state-of-the-art              Environment) is a programming environment which aim
computer engineering techniques that greatly improve                      is to develop an integration framework based on the
software reusability like object-oriented languages,                      mediator design pattern for distributed systems. MARIE
software components and software design patterns. This                    uses ACE (Schmidt, D. C. & Huston, & S. D., 2003) as its
paper describes on-going developments which goal is to                    communication library. All interactions between
design, implement and evaluate performances of a multi-                   applications are done asynchronously. Orca (Brooks, A. &
robot control framework. To validate the chosen                           all, 2005) is an emerging open-source suite of tools for
approach, we developed and integrated several modules                     developing component-based robotic systems (available
required to build typical robotic applications. The                       at http://orca-robotics.sourceforge.net). The Miro weak
Framework name is CoRoBa, which stands for                                point is its behaviour engine and the lack of remote
Controlling Robots with CORBA.                                            management. MARIE’s approach, as mentioned in (Côté,
It is evident that this effort is not unique and that other               C. & all, 2004) suffers from many drawbacks, namely,
laboratories have faced similar frustrations when                         overhead, complexity and system resource management.
implementing their control software and have                              CoRoBa tries to merge the strong points of the
consequently developed frameworks based on similar                        frameworks mentioned above while minimizing weak
requirements. One of the best-known examples is                           points. But as in all real projects, compromises have to be
certainly the module generator GenoM. It is a tool that                   made and a perfect solution will never exist.
helps building real-time software architectures and                       Because having a simulator is essential when developing
corresponds to the functional level of the architecture                   robot control software we have developed a 3D multi-
developed at the LAAS-CNRS (Alami, R & all, 1998).                        robot simulator, whose name is MoRoS3D, that integrates
MCA2 is a software framework with real-time capabilities                  seamlessly in the control framework. A similar project is
that is rapidly gaining in popularity (available at                       GSV (Graphical Simulation and Visualisation) that has
http://mca2.sourceforge.net). The DCA framework                           been developed at the University of Auckland by the



International Journal of Advanced Robotic Systems, Vol. 3, No. 1 (2006)
ISSN 1729-8806, pp. 073-078                                                                                                       073
                                                                    International Journal of Advanced Robotic Systems, Vol.3, No.1 (2006)



Robotics Research Group as a module of their robot           communication library is clear. A communication
programming environment. Like in MoRoS3D simulation          Middleware lies somewhere between the low level
services are exposed as CORBA interfaces. However, this      system API and the application and automates many
simulator does not meet one of the guidelines specified in   operations by abstracting low-level function calls. Among
section 2 because of its commercial 3D engine.               all existing Middlewares, CORBA has been selected
Section 2 presents the software requirements that must be    because of its language and platform independence. As
satisfied by the framework. In section 3 we discuss the      such a Middleware is quite complex and brings some
selection and usability of Middleware for distributed        overheads, one could ask the question if it is really usable
robot control system and detail Design Patterns that         for implementing robot control applications. The network
guided the software development. Section 4 covers            performance can be expressed by the following relation:
Component design and implementation and gives some
examples of existing components including the simulator.     Message Transmission Time = latency + length / data transfer
Section 5 describes the current state of the work and        rate
obtained results. Section 6 concludes with comments on
further research directions.                                 On one hand, the operations added by CORBA increases
                                                             the latency (that is independent of the message length).
2. Requirements                                              On the other hand, the extra information contained in a
                                                             CORBA frame is quite constant (a few hundreds of bytes)
Two different approaches have been considered when           and has therefore a larger influence for small data packets
identifying requirements for the framework. The first        We typically have a 20 to 30% overhead in comparison
approach took into account the functionality of typical      with raw socket communication. This result is confirmed
applications that would be built with the framework          by a comparative performance experiment reported by D.
whereas the second one considered the needs of potential     Gill in (Gill, C. & Smart, W., 2002). However, with
users. This analysis resulted into the following             increasing computing power and communication
requirements list:                                           bandwidth, the overhead introduced by CORBA becomes
     •   Integration of different robotic systems,           every day less and less significant. In (Gowdy, J. 2000) J.
     •   Concurrent control of several robots,               Gowdy         qualitatively      compares         Interprocess
     •   Platform independent GUI,                           Communications Toolkits for Robotics and concludes
     •   Shared control between several users,               that: “If the project is a long-term project ..., then a more
     •   Easy integration of user's algorithms.              flexible and standard ... communication infrastructure
     •   Flexibility (Distribution, Modularity,              such as CORBA may be called for ...”.
         Configurability, Portability, Scalability,          Among different CORBA implementations, we have
         Maintainability)                                    chosen ACE_TAO because it is widely adopted and
     •   Performance and efficiency                          supported, it implements most of the CORBA
It is obvious that some requirements conflict with each      specifications (including Notification Service, AMI, and
other: performance and efficiency for instance have to be    RT-CORBA) and is free open-source software. But we are
traded with flexibility. However, as we do not target hard   not limited to this implementation for developing
real-time applications, we can accept some performance       components and other ORB's (Objects Request Broker)
degradations due to extra-communication overheads. The       that have links to C++ or other languages like Java and
following guidelines have also been considered during        Python can be used too. In (Colon, E. & Sahli, H., 2003)
the development of the framework: Open source                we showed that our Middleware selection helps fulfilling
software, standard tools and technologies (UML, C++...)      the requirements listed in section 2.
and Design Patterns.
                                                             3.2. Framework design
3. Framework design and implementation                       3.2.1. Framework and control architecture
                                                             A framework is a set of cooperating classes that make up
3.1. Low-level communication API and Middleware              a reusable design for a specific class of software. The
The first decision when developing distributed               framework architecture defines how components are
application concerns the choice of the communication         integrated into the framework and how they are
library. Some framework developers have opted for the        interrelated. Reuse on this level leads to an inversion of
low-level socket library. While this is a good choice with   control between the application and the software on
regard to performance, it is a bad one concerning            which it is based: components written by the programmer
portability and maintenance. One solution is to use a        are called back by the framework in response to events.
multi-platform wrapping communication library like           A control architecture on the other hand specifies which
ACE. It is a very powerful library that can eliminate some   components are used and how they collaborate. The
of the drawbacks listed above but that leaves much work      framework architecture must be flexible enough to allow
to the programmer. The need for a higher-level               different logical control paradigm to be build using the




074
Eric Colon; Hichem Sahli & Yvan Baudoin / CoRoBa, a multi mobile robot control and simulation framework



same components: direct control, telecontrol, assisted                             between components. The event architecture greatly
telecontrol, autonomous robots (deliberative and                                   facilitates the implementation of Reliability Patterns.
reactive), multirobot applications, etc. Framework                                 CoRoBa implementation: Data are sent as events
components fall into two categories: structural                                    between the components that process and forward them
components that offer basic services used by other                                 to the next component(s). Components are lose coupled
components and application components that are the                                 by the events whose data structures are declared in
building blocks of an application.                                                 CORBA IDL (Interface Definition Language) structures.

3.2.2. Design Patterns and framework                                               Distribution, which is an essential aspect of architecture,
Design Patterns (DP) bring a theoretical foundation to the                         comes in two primary forms: asymmetric and symmetric.
software development. A DP describes a recurring                                   In asymmetric distribution systems, the binding of objects
programming problem and the core of the solution to that                           to the address space is known at design time while in
problem. It also lists the consequences of its use and gives                       symmetric distribution system is not known until run-
implementation hints. We now have a look at the                                    time. Symmetric distribution is more flexible and allows
Architecture and Distribution DP, which are used by the                            dynamic load balancing. The patterns presented below
CoRoBa framework. Most of the patterns are directly                                deal with the collaboration architecture, which focuses on
implemented by CORBA or its services.                                              how the objects find and communicate with each other.

Name: Component-based Architecture Pattern.                                        Name: Remote Method Call Pattern.
Problem: We need an architecture that is robust in the                             Problem: The programming model used to invoke
presence of maintenance and is highly reusable in a                                services locally is very well understood and what is
variety of circumstances.                                                          needed is a means to do the same think even when the
Solution: The Component-based Architecture Pattern                                 client and server do not reside in the same address space.
organises system into replaceable units with opaque                                Solution: The Client does not communicate directly with
interfaces.                                                                        the Server but via a Client Stub that contacts the Server
Consequences: Systems may be constructed via                                       Stub, which invokes the specified method on the Server.
assembly; we select at run-time which components we                                The low-level network operations are hidden to the Client
want to use. Opaque interfaces hiding implementation                               and Server.
details can be seen as an advantage or a disadvantage.                             Consequences: this pattern simplifies the process of
Components tend to be heavy in terms of required                                   client-server communication over a network. There are
resources (memory, size on disk).                                                  many middleware implementations that reify this DP.
CoRoBa implementation: We don't use components as                                  Most of them propose a compiler that automatically
known in the computer engineering literature (ActiveX,                             generates the stubs.
Bean...) but the framework consists of replaceable                                 CoRoBa implementation: CoRoBa relies on IDL
execution units (processes) that are independently and                             (Interface Definition Language) compilers to generate
remotely managed. Components can be added,                                         stubs for clients and servers.
(re)moved, discovered and located at run-time thanks to
the Name Service.                                                                  Name: Broker pattern.
                                                                                   Problem: A limitation of most of the distribution patterns
Name: Channel Architecture Pattern.                                                is that they require a priori knowledge of the location of
Problem: We would like an architectural structure that                             the servers. This limits their use to asymmetric
improves throughput capacity with the replication of                               distribution architectures. Ideally, the solution should
units allowing efficient processing of multiple data in                            provide a means to locate and then invoke services at the
different stages of processing. We also would like an                              request of the client.
architecture that improves reliability and safety through                          Solution: The Broker Pattern may be though of as a
the simple addition of redundant processing.                                       symmetric version of the Proxy Pattern. It provides a
                                                                                   Proxy Pattern in situations where the location of the
Solution: The Channel Architecture Pattern is useful
                                                                                   clients and servers are not known at design time. The
when data within a stream is sequentially transformed in
                                                                                   Broker is an "object reference repository" globally visible
a series of steps. A channel can be thought of as a pipe
                                                                                   to both clients and the servers.
that sequentially transforms data from an input value to                           Consequences: The Broker Pattern is a very effective
an output value. It is possible to find multiple elements of                       means for hiding remoteness of clients and servers. While
the data stream in different parts of the channel at the                           not completely successful in hiding all the details, it
same time.                                                                         nevertheless greatly simplifies the creation of systems
Consequences: The Channel Architecture Pattern                                     with symmetric distribution architectures.
improves the flexibility provided by the Component-                                Commercial ORB’s do require a minimum amount of
based Architecture Pattern by lowering the coupling level                          resources that may exceed those available in smaller



                                                                                                                                         075
                                                                    International Journal of Advanced Robotic Systems, Vol.3, No.1 (2006)



systems. For those cases, it may be possible to use           Solution: The Hierarchical Control Pattern uses two
smaller, less capable ORB’s or write one from scratch that    types of interfaces: control interfaces that monitor and
includes only the desired capabilities. In the Broker         control how the behaviours are achieved and functional
Pattern, the clients may dynamically discover the             interfaces, which provide the services controlled by the
relations. This makes the Broker Pattern more scalable        other set of interfaces. This pattern is based on
than the Proxy Pattern but also somewhat more                 composition.
heavyweight.                                                  Consequences: The use of separate control and functional
CoRoBa implementation: This pattern is definitively           interfaces provides a simple and scalable approach when
implemented by CORBA, which is the middleware                 the system must be highly configurable.
CoRoBa is based on. The communication model proposed          CoRoBa implementation: We define at the top level of
by CORBA is a synchronous one. Blocking calls are not         the hierarchy the Service interface that contains the
the most appropriate way to communicate in control            declaration of generic management operations as well as
software. The Data Bus Pattern provides a better solution.    types definition and exceptions. The operations defined
                                                              in the Service interface are implemented in the Service
Name: Data Bus Pattern.                                       class, which, once compiled, forms the Service library. A
Problem: Many systems need to share many different            service is composed of a main thread in which run the
data among a mixture of servers and clients, some of          ORB and a service thread. The service thread can be
whom might not be known when the client or data is            remotely managed by invoking operations defined in the
designed                                                      Service interface (Fig. 1). Using a controller interface
Solution: The Data Bus Pattern further abstracts the          defined and implemented at the top level of the class
Observer Pattern by providing a common (logical) bus to       hierarchy allows managing the run cycle of all
which multiple servers post their information and where       components easily with unchanged CORBA invocations.
multiple clients come to get various events and data          A CoRoBa Service admits the following commands: start,
posted to the bus. The Data Bus Pattern is basically a        pause, wakeup, and stop. It has 3 working modes that can
Proxy Pattern with a centralized store into which various     be remotely selected by the set_mode(...) operation:
data objects may be plugged along with metadata that          synchronous (process data when available), periodic
describes its contents. It serves to further decouple the     (whose period can be changed) and external
client implementation from the server's. The pattern          (synchronized on an external trigger). The normal
comes in both "push" and "pull" versions.                     synchronous 2-way can also be used by calling additional
Consequences: The Data Bus pattern offers a single            methods declared in the IDL interfaces of derived
location for clients to go and acquire data and for servers   components.
to publish their data. The Data Bus is extensible; it does
                                                                                                        Run cycle events
not have to understand the semantics of the data. New
servers and clients can be added and, with the help of a
Name Server, located at run-time.                                                  Main                Svc
                                                                                  Thread              Thread
CoRoBa implementation: Asynchronous communication
in CoRoBa is based on the Event Service and its extended
and improved version, the Notification Service that reify                 Management events                        Application events

this pattern. Components are connected through Event
Channels provided by the Notification Service.                                      Main               Svc
                                                                                   Thread             Thread

4. Component design and implementation
                                                              Fig.1 Events communication between components
This section presents the DP implemented by the
component architecture. It also reports on integration of     Name: Message Queuing Pattern.
existing systems into the framework.                          Problem: In most multithreaded systems, threads must
                                                              synchronise and share information with others.
4.1. Mechanistic design                                       Solution: The Message Queuing Pattern provides a
The component architecture implements the Hierarchical        simple means for threads to synchronise and
Control Pattern and the Message Queuing Pattern               communicate information among one another using
explained below.                                              asynchronous communications implemented via queued
                                                              messages.
Name: Hierarchical Control Pattern.                           Consequences: This pattern has many advantages and is
Problem: We desire separate the interfaces for the control    supported by virtually all real-time operating systems.
and configuration of the objects and the actual               The primary disadvantages are that it is a relatively
functionality provided by the object.                         heavyweight approach to information passing among




076
Eric Colon; Hichem Sahli & Yvan Baudoin / CoRoBa, a multi mobile robot control and simulation framework



threads and information must be shared by value instead                            contains the robot kinematics information but also the
of by reference.                                                                   motion commands are exchanged via sockets. As only
CoRoBa implementation: All CORBA objects are                                       one client is allowed to connect to the robot, the CoRoBa
implemented by servants inheriting from the Service base                           wrapper component breaks with the design standard
class. This class itself inherits from the ACE class                               presented above that separates sensors from actuators. It
ACE_TaskBase that eases the creation of portable                                   is actually a processor that receives motion commands
multithreaded applications. When the thread is started,                            via events, propagates the commands via sockets to the
the inherited svc() method is executed and calls the                               Robudem server, receives the kinematics data as the reply
virtual method process_data() declared in the Service                              from the socket server and finally forwards the
base class and that must be implemented in subclasses.                             kinematics information via the output event channel. The
The loop is run conditionally and flags allow pausing or                           control of the robot is implemented by CoRoBa processor
stopping it. These flags are set and reset by Service                              components.
methods implementing the CoRoBa Service interface
operations that can be remotely invoked by                                         4.3.2. Sensor integration
administration tools.                                                              We take as example a metal detector (MD) that we use for
                                                                                   detecting mines in humanitarian demining projects. This
4.2. Actuator, Processor, Sensor                                                   MD has a serial interface for configuring the system and
We have defined three interfaces, Sensor, Processor and                            for reading sensor signals. Two solutions are possible: the
Actuator that inherit from the Service interface. The classes                      sensor component communicates directly with the serial
implementing these interfaces are considered as abstract                           port or the serial port is wrapped into a generic
and may not be instantiated and consequently real                                  component that simply propagates messages received as
services interfaces are derived from these ones. The code                          events to the serial port and sends the response back. The
is actually organised in two parallel hierarchies: the IDL                         second solution adds one unnecessary communication
interfaces and the CoRoBa classes implementing these                               step. Both solutions have to be implemented as a
interfaces. Sensors have connections with the physical                             processor because they realise duplex communication
world and they output data to one Event Channel.                                   and must consequently have an in and an out Event
Processors get their inputs from one Event Channel; they                           Channel connection.
transform data and send the result to another Event
Channel. Actuators have output connections with the                                4.3.3. Simulator integration
physical world and received data from one Event                                    The 3D simulator allows multiple mobile robots to be
Channel                                                                            simulated at the same time (Fig. 2). It is based on Java3D
                                                                                   that imports VRML models. Multiple virtual cameras are
4.3. System integration                                                            available (fixed, onboard, tracking) that can be selected
While new services are designed from scratch, existing                             via the GUI. The user can also (re)set the robots position,
applications and systems will need to be integrated in the                         and erase the trajectory markers.
framework. Depending on the communication and API
available this integration can be a trivial or a tricky job.
Integration is usually made by providing a facade, aka an
object wrapper following the Wrapper Facade pattern.
When wrapping libraries, we need to pay attention to
serialize data access if existing libraries are not thread-
safe.

4.3.1. Robot integration
In the case of our Nomad200, it comes with an API that is
available for the Linux OS. We have written an actuator
component that translates CORBA method invocations to
motion command functions of the API and a sensor
component that reads the different sensors' values and
propagates them as events. The operations listed in the
Nomad interface keep the same signature as the original                            Fig 2. MoRos3D simulator showing 8 identical robots in
functions of the Nomad200 API.                                                            indoor environment
The integration of the second robot (Robudem) is simpler
because we do not have to wrap any existing API. On the                            As the simulator has been designed to provide CORBA
Robudem main computer runs a server that transfers data                            interfaces for all robots and sensors, its integration in the
via shared memory between the Linux and the RT-Linux                               framework is straightforward. Two possibilities exist for
side of the control application. The data structure that                           a CoRoBa component to communicate with the simulator:



                                                                                                                                           077
                                                                     International Journal of Advanced Robotic Systems, Vol.3, No.1 (2006)



via Event Channels or via CORBA synchronous calls. In         6. Further research
the first case the simulator acts directly as sensors and
actuators. The second solution requires developing            In order to further validate the framework, we need more
CoRoBa sensor and actuator components that                    demonstration applications; some could be simply build
communicate with the Simulator (via asynchronous calls        up by combining existing components in different ways
or events). The advantage is that we keep the same            while others will require the development of new
application structure as in the case where we use real        components. We are also working on a general
robots and sensors for which we necessarily have              distributed    Behaviour      engine   for   multi-robots
wrapper components.                                           applications. In the next future, we will integrate other
                                                              robots (Melexis developed at the VUB, a Cartesian
5. Status and results                                         scanner at the RMA) and real sensors (Laser, GPS, US,
                                                              MD...).
The CoRoBa framework has been used to implement
components of the three categories. Following                 7. References
components are currently available:
   • Simulator: 3 robots (Nomad, Robudem, Melexis),           Alami, R.; Chatila, R.; Fleury, S.; Ghallab, M. &. Ingrand,
        Laser distance, US distance, GPS.                         F. (1998), An Architecture for Autonomy, International
   • Actuators: Nomad, Robudem and the 3 simulated                Journal of Robotics Research, special issue on "Integrated
        robots,                                                   Architectures for Robot Control and Programming",
                                                                  1998
   • Sensors: Joystick, components wrapping simulated
                                                              Brooks, A.; Kaupp, T.; Makarenko, A.; Orebäck, A. &
        distance sensors and simulated robot encoders,
                                                                  Williams, S. (2005). Towards Component-Based
   • Processors: Fuzzy logic Goal navigation, Goal                Robotics. Proceedings of IEEE/RSJ International
        provider, Goal scheduler, Simple Obstacles                Conference on Intelligent Robots and Systems (IROS
        Avoidance Behaviour.                                      2005). In Press.
Based on these components, following typical                  Colon, E. & Sahli, H. (2003), Software Modularity for
applications have been tested (simulation and/or real             Mobile Robotic Applications, Proceedings of
systems):                                                         Clawar2003, Sep 2003, Catania, Italy
   • Direct joystick control of robots,                       Côté, C.; Létourneau, D.; Michaud, F.; Valin, J.-M.;
   • Shared autonomy obtained by combining the direct             Brosseau, Y.; Raievsky, C.; Lemay, M.; Tran, V. (2004).
                                                                  Code Reusability Tools for Programming Mobile
        control and the obstacle avoidance components,
                                                                  Robots, Proceeding IEEE/RSJ International Conference
   • Goal navigation with fuzzy logic control,                    on Intelligent Robots and Systems (IROS), 2004.
   • Sequence of Goals,                                       Enderle, S.; Utz, H.; Sablatnön, S.; Simon, S.;
   • Distributed simulation.                                      Kraetzschmar, G.; Palm, G. (2001). MIRO: Middleware
Real applications typically require one actuator per robot,       for autonomous mobile robots, in Proceedings of
one sensor per physical (or simulated) sensor and some            Telematics Application, pp 149-154, July 2001,
processors. Most of the time sensors and actuators are            Weingarten, Germany
constrained by physical connections while the location of     Gill, C. & Smart, W. (2002). Middleware for Robots?, In
the processors can be freely chosen.                              Intelligent Distributed and Embedded Systems,
                                                                  Papers from the 2002 AAAI Spring Symposium,
Thanks to the modular architecture, developing a new
                                                                  Gaurav S. Sukhatme and Tucker Balch (Ed.), pages 1-
empty component takes less than 15 minutes. The total
                                                                  5, 2002.
time required to implement the functional code depends        Gowdy, J. (2000). A Qualitative Comparison of
on the type of component. Integrating a new robot or              Interprocess Communications Toolkits for Robotics,
sensor is off course more complicated than just coding            Internal report CMU-RU-TR-00-16, the Robotics
some processing algorithms.                                       Institute, Carnegie Mellon University, Pittsburgh, PA
Concerning the simulator performances, typical figures        Peterson, L.; Austin, D.; Christensen, H. (2001) DCA: A
for 8 robots with 16 laser distance sensor is 90% processor       Distributed Control Architecture for Robotics,
activity (Centrino 735) and a memory usage of 40MB,               Proceedings IROS 2001 - IEEE International Conf. on
image refresh period in this configuration is 80 ms.              Intelligent Robots and Systems, 29 Oct. – 3 Nov., 2001,
CORBA has a steep learning curve and several months               Hawaï, USA,
were required for understanding and mastering                 Schmidt, D. C. & Huston, & S. D. (2003). C++ Network
programming subtleties. In comparison students were               Programming: Systematic Reuse with ACE and
able to develop new components with CoRoBa in a few               Frameworks, ISBN 0-201-79525-6, Addison-Wesley
weeks, what demonstrated the efficiency of the proposed           Longman
framework.




078

								
To top