Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of...
Transcript of Component Enabler Best Practices: SCA€¦ · Component Enabler Best Practices: SCA The place of...
Component Enabler Best Practices: SCAThe place of Zeligsoft Component Enabler
within the SCA software development process
Mark Hermeling, John Hogg, Francis Bordeleau
1 OVERVIEW
This paper illustrates how Zeligsoft Component
Enabler (CE) [ZSFT] can assist in a component-based
software development process for embedded systems.
To do this we will investigate the roles that participate
in a process and document the usage patterns and
benefits of using CE throughout the development process.
This paper focuses on the use of Zeligsoft Component
Enabler version 1.4.
2 INTRODUCTION TO COMPONENT ENABLER
Component-based development refers to both the
development environment and the deployment envi-
ronment of component-based systems. Component-
based systems consist of assemblies of components.
Developers work on components in isolation; they
build them, test them, and deploy them as individual
components. Once deployed, the individual components
are initialized, connected together, and started. The
connected components deliver the full functionality of
the entire system.
The Software Communications Architecture (SCA) [SCA]
is a deployment and configuration architecture for
Software Defined Radio (SDR) managed by the US
Department of Defense Joint Tactical Radio System
(JTRS) [JTRS] Joint Program Office (JPO). It specifies
how to define systems as assemblies of components and
how these assemblies can be deployed to platforms.
CE helps users overcome many of the challenges
associated with building SCA compliant systems [ZSFT-8].
CE enables users to graphically define the system platform
and the (waveform) applications that are deployed to
the system. The visual models give the development
team a clear, common understanding of the hardware
and software architectures, and the component and
device interfaces, including their relationships.
Communication and peer review are the first steps to
building a correct system, but informal descriptions can
still obscure many defects. Since CE graphical models
are semantically rich and precise, CE can automatically
validate them for compliance to the SCA standard. This
ensures that many types of errors cannot occur.
The visual model can also be used to automatically
generate the entire domain profile. The domain profile
is the set of XML descriptor files that are required for
an SCA compliant system.
Models are the basis of the software development effort.
CE allows team members to share model elements.
The model elements that are created at the beginning
of the development process are passed on. At each
step, more information is added to the models.
Component Enabler Best Practices: SCAThe place of Zeligsoft Component Enabler within the SCA software development process
Mark Hermeling, John Hogg, Francis Bordeleau
A software development process is vital for large-sized projects. Any project developing SCA compliant Waveforms
or Platforms falls in this category. Simply put, the process explains who does what when and how. Information
flow, artifact creation, and tool usage are important elements of a process, and this is where Zeligsoft Component
Enabler (CE) proves valuable. CE’s automation enables users to easily design, model, visualize, and author artifacts
which, if maintained manually, would be expensive and error-prone.
This paper demonstrates the use of CE in a software development process. Because every project defines its
own specific process, this paper does not attempt to describe the details of an overall process. It instead focuses
on the description of the different roles involved in a process and on how CE can be used to support these roles.
1
CE models focus on how components communicate.
They do not express how components should be
implemented. Implementation can be done by writing
source code by hand or through other modeling tools.
The SCA makes it easier to integrate COTS (Commercial
Off-the-Shelf) or third-party components. CE lets users
import these components into models through its XML
Import feature. The imported XML is automatically
checked for violations against the SCA standard in
the area of syntax and semantics.
The content of the CE models needs to be shared with
all the project stakeholders. This can be done through
the documentation generation capability of CE. This
capability generates documentation containing all the
content of the model. The documentation generation
is based on customizable templates.
3 PHASES, ROLES, AND RESPONSIBILITIES
Many software development projects already have their
own defined process. An example of a popular software
development process is the IBM Rational Unified Process.
This paper is intended to be process agnostic. We will
use high-level general development phases and roles
to illustrate the use of CE. The content of this paper
can be adapted to any software development process
for projects using CE.
The phases in our simplified process are requirements,
design, implementation, and testing. In an iterative
process, these phases are traversed multiple times
(once for each iteration) for a single release. Each
iteration brings the delivered product closer to the full
set of functionality required. See section 9 for a more
detailed discussion on the use of CE in an iterative
development workflow.
Work in each of the phases is done by the software
development team. People on the team have different
roles. Each role has responsibilities, and consumes
and creates artifacts. Figure 1 illustrates how the roles
relate to the phases in a specific iteration.
This paper focuses on the use of CE in the different roles
and phases. From an SCA perspective, the requirements
phase does not benefit from visual modeling. It is,
therefore, not covered here.
2
Figure 1: Phases and roles
system architect
application engineer
platform engineer
component developer
system tester
requirements design implementation test
Zeligsoft CE™ in Action
3.1 Design
The design phase prepares the blueprints for the
development of the software. It starts with a high-level
design where the responsibilities of the system are
divided into smaller, more manageable modules. The
system architect is responsible for this high-level
design model.
The high-level design or architecture model is then
given to the application engineer and the platform
engineer for further elaboration.
The platform engineer is responsible for the SCA plat-
form. The platform includes the actual system hard-
ware and the software environment required to use
this hardware: RTOSes (Real-Time Operating Systems),
device drivers, communication middleware (CORBA
ORBs), and the SCA Core Framework implementation,
which provides standard interfaces to the platform and
its components.
The application engineer is responsible for the SCA
application architecture. The application includes all the
components that provide functionality to the system,
including their interconnections and their connections
to devices on the platform.
3.2 Implementation
The component developer is responsible for the
implementations of the components and maintaining the
model with respect to those implementations. There are
usually two different teams of component developers,
one team for the application components and one
team for the platform components.
The component developers on the platform team
work at the hardware level. They write code for GPPs
(General-Purpose Processors), DSPs (Digital Signal
Processors), FPGAs (Field-Programmable Gate Arrays),
and the device drivers that can access these devices.
The component developers on the application team
work at higher levels of abstraction. Their code uses
the components delivered by the platform team and
builds upon their services. The components provide
the adaptable functional behavior for the system.
3.3 Testing
The system tester is responsible for verifying the
quality of the integrated system, which includes testing
of all valid deployments of application components to
the platform. The system tester tests the system as a
whole, as opposed to the component developer who
performs unit testing of functionality on a limited number
of components.
3
4 SYSTEM ARCHITECT
4.1 Role Introduction
The system architect is responsible for deciding on the
division of the application into components. The system
architect creates the layout for the main software
components (the application) and the main platform
components (the node, including the executable devices).
This results in an early high-level model of the run-time
architecture (see Figure 2). The run-time architecture
model covers who talks to whom while the system
executes. This model is used for discussions and
reviews. It communicates the ideas of the architecture
team to the rest of the development team.
This high-level design model is a preliminary model of
the software and hardware environment. The application
and platform engineers can evolve the high-level model
into a full fledged architecture.
In principle, an SCA waveform (application) is platform-
independent and its architecture does not depend on
the underlying hardware platform. In practice today, a
system architect has a very clear understanding of the
platform and may actually define it in parallel with
some sets of applications.
The system architect delivers the global architecture
document. This document describes the decisions
made in developing the architecture and is a critical
lifeline during the development of the system.
It is common to deliver the full functionality of the system
in different iterations. Each iteration adds extra pieces
of functionality to the system. The system architect
decides what parts of the functionality are delivered in
which iteration.
4.2 Workflows within CE
The system architect creates an early high-level
model of the run-time architecture in CE. This model
contains the components and some component
instances. If required, ports can be created on
components so communication can be indicated
between the component instances.
The model can be used as a basis for the architecture
document through the documentation generation facility.
A key part of the architect’s task is defining the protocols
between components. A protocol is an ordered set
of messages between two or more components. Each
message is defined by its operation, its parameters,
its return value, and whether it is synchronous or
asynchronous.
As discussed in section 9, the architect cannot and
should not attempt to define all details of every protocol,
except in the simplest of systems. Protocols evolve over
system development as new insights and requirements
are gained. However, the specification should be detailed
enough to guide the other roles in their evolution of
the protocols.
4
Figure 2: System Architect Responsibility
4.3 Activities in CE
The list of activities performed by the system architect
using CE includes
Creating components definitions
Creating ports with or without interfaces on
component definitions and device definitions
Creating applications and component instances
Connecting component instances together
Creating platforms, nodes and device instances
Connecting device instances together
Defining protocols
Creating documentation
Delivering the model to the application
and platform engineers
4.4 Benefits of CE
The architect benefits from using CE mostly because
it makes communication easier and facilitates the
dissemination of information.
Creating the model in CE ensures that the system
is SCA compliant even this early in the development
cycle. The model is not expected to be complete at
this stage, and may generate validation warnings due
to under-specification (such as missing interfaces).
However, everything that is specified should be valid
when the architecture model is delivered to the appli-
cation and platform engineers.
The first model is created by the system architect. The
model can be used by the system architect to discuss
the architecture with the application and platform engi-
neers. The model can also be used to generate docu-
mentation and to keep the documentation in sync with
the model.
This is the start of a Model Driven Architecture® (MDA®)
approach to system development, where the model is
the primary source of communication, documentation,
and development.
5 APPLICATION ENGINEER
5.1 Role Introduction
The system architect defines the broad shape of an
entire system, but is not responsible for fine details,
such as the exact interfaces or protocols between
communicating components. The application engineer
builds on the foundations the system architect built
and turns it into a full fledged run-time architecture
model for the application engineer.
The application engineer describes how the various
components work together to deliver the full functionality
of the software. The description includes the division
of the application into components, the interfaces on
these components, and the interconnections between
them. All these artifacts, and the decisions that were
made in designing them, should be documented in
the architecture document.
The application engineer – together with the platform
engineer and the architect – is responsible for over-
seeing the evolution of the protocols, the interfaces
between components. The system architect has
defined the protocols at a high-level. The application
engineer and platform engineer are responsible for
refining these and adding detail.
5
Figure 3 shows how the run-time architecture as defined
in CE is used. From the model, users can generate XML
that describes the application. The model can also be
used to derive the outline of the code that forms the
implementation. The code outline is the code that
glues the signal processing code and control code
into the SCA execution framework. The code outline is
delivered to the component developers, who use it to
build the SCA wrapper code. See also Figure 5.
After the application engineer has created the architecture
models, they can be handed down to the component
developers for further elaboration.
The application engineer is responsible for proper
integration of the application. Once the component
developer has created the implementations, the appli-
cation engineer needs to bring the entire system ‘up’.
This means the components need to be started within
the Core Framework on top of the platform. The inte-
grated components are used to prove functionality to
the system architect.
The application engineer plans the milestones that the
component developer needs to meet in delivering
capabilities. This is needed to ensure that the application
engineer can meet the milestones that were set for
him by the system architect.
5.2 Workflows within CE
The application engineer takes the SCA run-time
architecture part of the model from the system
architect and adds further detail to it, including
Creating components and instances
Defining the interfaces
Interconnecting the components
Creating inter-connections between the software
and the hardware architecture
Specifying attributes and relationships
The model can also be used to generate documenta-
tion, which needs to be integrated into the software
architecture document.
The application engineer – together with the architect –
may also decide to use existing components. Existing
components can be either legacy or COTS components.
Legacy components are components that were developed
for another project. COTS components are delivered
by a third party. These existing components can be
added to the model using the XML Import feature.
The application may need connections to platform ele-
ments. The platform elements are defined by the plat-
form engineer. The platform engineer should share
these model elements with the application engineer.
During the integration step, the application engineer
most likely integrates the components one by one into
a working system. The easiest way to do this is to
start with a partial application (a subset of the entire
application), and generate the descriptors. These
descriptors can then be downloaded to the target
and executed. Upon success the next component
can be added to the subset.
6
Figure 3: Application Engineer Responsibility
Activities in CE
The list of activities performed by the application
engineer using CE includes
Adding attributes and properties to component
definitions
Adding ports and supported interfaces on
components
Adding external ports to the application
Creating dependencies from components to other
components and devices
Creating usesdevice relationships
Creating connectors between ports on components
Creating connectors between component instances
and devices
Specifying attributes on instances
Setting the assembly controller for the application
Importing existing or third party components and
applications
Validating and generating
Creating documentation
5.3 Benefits of CE
The application engineer benefits from the use of CE
through refining model elements. In the absence of tools,
the application engineer creates an entire design from
the beginning, based on the documents and diagrams
delivered by the system architect. When all stakeholders
use CE, there is continuity. The application engineer’s
design simply evolves the architecture delivered by the
architect. This both speeds up the design task and
reduces errors due to miscommunication.
The model provides one source for information.
Modifications to the architecture should be done
through the model. CE ensures that the entire model
space remains consistent and that derived artifacts,
such as descriptor files and documentation, can be
regenerated.
XML Import is an effective way to add COTS
components to the model. As an added benefit,
it also verifies the correctness of the XML that
accompanies the components.
CE’s XML Import feature helps users visualize and bet-
ter understand how COTS components can be inte-
grated into a project.
Documentation generation alleviates the tedious task
of creating documentation manually and makes it easy
to keep the documentation in sync with the model.
CE makes it easy to create subsets of the entire appli-
cation and generate the application. This is needed for
the software integration phase.
5.4 XML Generated
The XML descriptor files generated from the model
element under the application engineer’s control include
a SAD for every application
an SCD for every (SCA-compliant) component
an SPD for every component
PRF files where needed
7
6 PLATFORM ENGINEER
6.1 Role Introduction
The responsibilities of the platform engineer are largely
the same as those of the application engineer, except
that the focus is on the platform. Only the major differ-
ences between the platform and application engineers
are indicated here.
The platform engineer is responsible for the correct
working of the execution environment. This includes
the physical hardware board, RTOS, CORBA, Core
Framework, board support package, the software
drivers – anything that makes the physical hardware
usable. The platform engineer gathers all the relevant
components for the platform and assembles them
into a node.
One big difference with the application engineer is that
in many projects, the hardware is obtained through a
third party vendor or a separate team. This means that
the platform engineer has a large number of third party
components to import, which need to be adapted for
the project.
The platform engineer is responsible for the logical
hardware elements. In the SCA these logical elements
are represented as devices. They are software repre-
sentations of the hardware elements. They communicate
with the other components in the system through well-
defined CORBA interfaces.
The platform engineer is also responsible for the Core
Framework and its configuration. The Core Framework
is typically delivered by a third party vendor or sepa-
rate team. The platform engineer is responsible for
integrating and configuring the Core Framework with
the rest of the system.
Once the component developer has created the
implementations for the platform, the platform engineer
is responsible for integrating them into a working platform.
This means that the devices need to be started together
with the Core Framework.
6.2 Workflows within CE
The platform engineer takes the platform part of the
model produced by the system architect and adds fur-
ther detail to it. The tasks of the platform engineer
include
Creating devices and instances
Defining the interfaces on devices
Instantiating devices onto the node
Interconnecting the devices
Specifying attributes and relationships
The model can also be used to generate documentation
for inclusion into the hardware architecture. Automated
generation makes it easy to keep the documentation,
the model, and the delivered XML synchronized.
The platform engineer is also responsible for choosing to
use existing or COTS components. These components
can be added to the model by importing existing XML.
8
Figure 4: Platform Engineer Responsibility
The platform engineer can use CE in the integration
phase to quickly create subsets of the entire platform.
This simplifies incremental integration of the platform
components. Incremental integration is much easier
and more predictable than a “big bang” integration of
all components near the end of the process.
6.3 Activities in CE
The activities performed by the platform engineer
using CE include
Adding attributes and properties to device
definitions
Adding ports and supported interfaces on devices
Creating dependencies from devices to other devices
Creating connectors between ports on devices and
set the attributes
Creating connectors between devices and services
and the Core Framework
Specifying attributes on instances
Configuring the Core Framework components
Importing existing or third party XML
Validating and generating
Creating documentation
6.4 Benefits of CE
The platform engineer and application engineer see
many of the same benefits. Like the application engi-
neer, the platform engineer can build on the system
architect’s work to deliver a better design faster, with
fewer communication errors. Automated generation of
documentation delivers accurate descriptions quickly
and simplifies documentation maintenance as designs
evolve. Importing existing XML allows precious IP to be
adapted, reused and even improved through validation.
6.5 XML Generated
The XML descriptor files generated from the model
element under the platform engineer’s control include
a DCD for every node
an SCD for every device
an SPD for every device
PRF files where needed
DMD, DPD files where needed
7 COMPONENT DEVELOPER
7.1 Role Introduction
There are a number of different responsibilities for the
component developer role; however, the role is primarily
responsible for implementation of the application and
platform components.
The source code for components consists of three
parts: the wrapper code that deals with the CORBA and
Core Framework functionality, the signal processing
code, and the control code that guards the operation
of the component.
In most SCA projects, a team of component developers
is responsible for platform components, while separate
teams deliver the application component. The application
and platform domains are quite different and require
different skill sets. Both teams are covered as one role in
this paper, as their roles are similar from a CE perspective.
9
Figure 5: Build up of an SCA component
Components can be implemented using modeling tools
such as Rational Rose or Microsoft Visio, in combination
with an object-oriented programming language such
as C++ for the application side. Alternatively, a Model-
Driven Architecture® (MDA®) tool such as IBM Rational
Rose RealTime, I-Logix Rhapsody or The MathWorks
Simulink can generate some or all of the source code.
The platform side would frequently rely on C for DSP
processors or VHDL for FPGAs.
During component implementation, protocols and
interfaces need to be revisited. The component developer
might discover inconsistencies or errors in the specifi-
cations. These need to be discussed with application
and platform engineers and resolved.
The component implementations must be unit-tested.
That is, the implementer of the functionality must
download the code to a test platform and run it. This
test platform can be an evaluation environment (such
as a Windows environment) or it can be the final target
environment.
Once the run-time architecture model and the imple-
mentations are complete, the component developer
is able to download and execute the application on
the target platform. A set of XML descriptors must
be generated for the domain profile. Users can either
generate XML descriptors for the entire model or for
a smaller subset.
The component developer is usually not responsible
for integration of the entire system. This is a task for
the application engineer, platform engineer and system
tester as discussed below. Integration is a team effort
as it spans multiple technologies. The platform and
application engineer are responsible for the integration
of all components into the SCA run-time framework.
They are responsible to get the application up and
running. The system integrator and tester is then
responsible for making sure the functionality of the
components match as designed in the architecture.
The component developer needs to create and main-
tain documentation. The documentation is needed by
many development processes to demonstrate how the
system is built and as input to design reviews.
7.2 Workflows within CE
The component developer takes the models from the
application engineer and platform engineer and builds
on them by adding detail for the implementations. The
detail that the component developer adds is related to
the specific properties of the implementation, including
stack size, entrypoint, and so forth.
To perform designer testing, the component developer
also creates test applications that contain a subsection
of the entire model space.
10
Figure 6: Artifacts for Component Developer
7.3 Activities in CE
The list of activities performed by the component
developer using CE includes
Creating component and device implementations
in the model
Creating dependencies, properties and attributes
for the implementations with other developers and
engineers
Creating the physical implementations for the
components and devices in source code
Creating smaller applications for unit test
Downloading and unit testing in simulation or target
Creating documentation
7.4 Benefits of CE
A key benefit of using CE for the component developer
is that it provides guidance on using the SCA. The
SCA standard is complex. CE guides the developer
through the workflow of creating correct descriptors,
making it a more enjoyable and less error-prone task,
which results in higher quality software. It guarantees
that the details of descriptors are correct by construction.
Correct descriptors are important: they are at the
core of the deployment process. Debugging incorrect
descriptors during deployment is a time-consuming and
painful experience because of the limited debugging
capabilities of target environments.
The increased performance and quality means that
developers spend more time focusing on implementing
functionality, rather then debugging descriptor files. More
design, implementation, testing, and debugging cycles
result in higher quality software.
Making smaller models for testing becomes easier.
Creating an application is a simple drag-and-drop of
the components that need to be assembled.
Discussions between the platform team and the soft-
ware team can also benefit from the modeling tool:
they have a common vocabulary and models to use
as a basis for discussion.
7.5 XML Generated
The XML descriptor file generated from the model ele-
ments under the component developer’s control include
an SPD with information about the implementations
the PRF files that contain particular attributes that
are of importance to the implementation
Of course, the full set of XML files used and generated
by developers includes the files created by all roles
discussed above.
8 SYSTEM INTEGRATOR AND TESTER
8.1 Role Introduction
The system integrator and tester (or just “system tester”)
should not be forgotten in discussions about SCA
compliant applications. The system tester takes the
integrated application and verifies that the entire system
operates as specified in the requirements.
To do this the system tester needs to test the entire
system as one unit. However, testing frequently starts
with smaller sub-units of the application to facilitate
integration and test work required.
Ideally, interfaces and protocols would be so perfectly
specified that all components would work together the
first time. Currently, software engineering has not
reached such a state. Inevitably, there are problems. If
system integration is left until all components are com-
plete, major rework may be required to resolve these
problems, resulting in major delivery slips late in the
schedule. For this reason the system tester should
work with the development teams as early as possible
in the development cycle to verify partial functionality
and identify issues as soon as possible.
11
System testers are usually not very familiar with the
SCA. They are focused on downloading software to
hardware and verifying that it is working. To do this,
they need to modify properties in the XML.
8.2 Workflows with CE
The system tester takes the executables and updated
models from the component developers for each
development milestone iteration and generates
descriptors. These descriptors are then downloaded
to the target and executed.
The test cases might require frequent XML modifica-
tions, which can be done through user-friendly, model-
based workflows.
8.3 Benefits of CE
CE helps system testers adhere to the SCA, so they
require less knowledge of it to accomplish their tasks.
The result is a reduction in the number of errors and
an increase in productivity.
The model also makes it easier for the system tester
to understand the pieces that participate in the func-
tionality under test.
9 ITERATIVE DEVELOPMENT
In highly structured development environments all
details of the application and platform designs – right
down to the details of interface operations and protocols –
could be the responsibility of the application and platform
engineers or even the system architect. In current
practice, the interfaces between communicating com-
ponents are often negotiated between the respective
component teams. This point deserves some discussion.
In a waterfall development process, each stage of
development is completed before handoff. In principle
this gives component development teams clear contracts
in the form of interfaces and protocols between these
interfaces. When teams deliver components that meet
these contracts they integrate immediately and smoothly.
While the vision is appealing, it does not reflect the
reality of complex systems. Architectures and designs
are driven by low-level reality. The details of a protocol
cannot be fully understood and specified until the details
of its participants’ behaviors are understood. For example,
when is a component ready to start receiving data?
The initialization steps may involve complex negotiations
with other components that are not visible in the system
architect’s high-level view. The component developers must
adapt protocols as system understanding progresses.
This is not a license for component developers to change
their interfaces at any time and without warning; late
interface churn is a clear symptom of a project in trouble.
Instead, industry-proven iterative approaches to interface
and protocol evolution should be applied. Interface and
protocol evolution should be monotonic, controlled,
and iterative.
12
“Monotonic” means that the elaboration of a protocol
should start from a minimal base. The base (in the
form of messages, their parameters, and their ordering
within a protocol) may be partial, but the parts that are
present should be correct at every stage and nothing
should be removed or changed later. This perfect
approach is not achieved in practice as errors are dis-
covered and resolved, but non-monotonic changes
should be seen as defect correction, not iterative
development.
“Controlled” means that the developers of communi-
cating components do not own their interfaces. That’s
the responsibility of the application and platform engi-
neers, who retain their role through to delivery of the
completed application. The component developers
negotiate protocol evolution with each other, but they
must then deliver their proposed changes to the appli-
cation or platform engineer who approves them and
evolve the overall design to include them. The application
and platform engineers are responsible for the archi-
tectural integrity of their designs. The designs evolve
over time, but they must remain coherent and clean.
“Iterative” means that integration is not a one-step
process that happens at the end of the development
cycle. The system architect defined milestones for
system-wide functionality. The application and platform
engineers then defined milestones for partial system
integration. The component developers are responsible
for delivering these integrations.
The first partial integrations can demonstrate two
components establishing basic communication while
running on a host development system test environment
instead of the deployment target platform. Each inte-
gration milestone demonstrates increasing functionality
and complexity. The communication between two
components may expand to include new functionality
or use cases, or additional components may be
brought into the integrated system.
Simple integrations may be done entirely by component
development teams as they test their components against
those of their peers. In other environments, the system
tester is brought in from the very first integration, especially
if it is to be done on the deployment target instead
of a host environment. Early stakeholder involvement
improves the final product, so system tester participa-
tion is recommended for all integrations.
At a finer level, component developers have full
responsibility for their parts of the system. The
component developer is responsible for modeling the
SCA representation of the monolithic implementations
of the components.
SCA components also include externally visible properties.
Like protocols, these are part of the “contract” of the
component. They may be initially specified by the system
architect or added by an application or platform engineer.
The component contract may then be evolved and
elaborated by the component developer. While per-
forming their tasks, component developers might discover
that some information is missing in the model. This
missing information would be discussed with the
application or platform engineer. Together they would
enhance the model to include the missing information.
13
10 EXAMPLE
As a sample workflow, consider an SCA compliant
Software Radio being developed by a company for
a third party customer. The customer has provided a
document containing the requirements for the radio.
These requirements are analyzed by the software
architect team, who come up with a number of possible
approaches to build the system. The team uses CE
to create a model for each of the approaches. CE’s
documentation generation feature can be used to
create documentation that details the benefits and
disadvantages of the different approaches.
In the end, the architect team decides on the best
architecture and picks one of the models as the seed
for further development. This model contains one
or more applications, a number of components and
component instances, a platform, one or more nodes,
a number of devices, and device instances. The
instances have some ports, likely without interfaces,
which are used to document who talks to whom
during runtime in the application. Further detail is
not required at this point.
The architecture team also comes up with a delivery
plan. The delivery plan documents the iterations that
the team needs to go through to deliver the full system
and the content that needs to be demonstrated at
each milestone.
The model and plan are then passed on to the appli-
cation and platform engineers. They evolve the model,
and add ports and properties to the components and
interfaces to the ports. They elaborate the application
and nodes to contain the proper connections. They
create properties on the components and devices and
relationships between them.
Where needed, the application and platform engineers
use the XML Import feature to integrate third party or
existing components into the model.
The application and platform engineers then create the
outline code that addresses the SCA and CORBA side
of the component and device functionality.
The architecture team keeps a close eye on the work
done by the application and platform engineers. They
frequently communicate and resolve conflicts; they
discuss the best way to push the project forward. The
model is used in this communication. By the end of
this stage, the model contains most of the content
needed for the system, with the exception of the infor-
mation for the implementations. The engineers ensure
that the information they enter into the model is SCA
compliant by using CE’s validation feature.
The application and platform engineers devise a delivery
plan for the component developers. This delivery plan
needs to be tuned to the delivery plan that was passed
down from the architects.
The application and platform engineers use CE’s
documentation generation feature to add information
about the work that they have delivered to the docu-
ments that the architect team started.
The component developers take the model and the
outline code delivered by the application and platform
engineers and they finalize them. They create the actual
core of the signal processing code and hook it up to the
CORBA and SCA wrappers. They provide the information
about the implementations (stack size, priority, entry-
point and so forth) into the model.
14
Once implementations are available, the component
developers need to test the implementations by down-
loading them to a target and executing. This step fre-
quently requires the creation of test applications that
need to be SCA compliant. CE helps here too: the
component developers can modify the application
without the risk of invalidating the XML. CE ensures
everything remains valid.
Once the component developers have unit tested and
integrated the application, they send the entire appli-
cation to the system testers. This team downloads
the application to the final system and verifies the
functionality of the entire system. This occasionally
results in the need to modify the model to test the
system with different variables.
All the activities above are executed once for each iter-
ation. That is, the architects make a plan for all iterations,
create the model for the iteration and pass this down to
the application and platform engineers. The engineers
refine the model and make a plan for the component
developers. The component developers deliver the
implementations, which are integrated and passed to
the system testers to execute a system testing step.
Every iteration executes all phases in the development
process exactly once.
After an iteration, the result is assessed and used to
plan the next iteration. The iterations are executed a
bit staggered. That is, while the application and plat-
form engineers are executing iteration N the system
architects are preparing iteration N+1.
11 CONCLUSION
Tool automation makes work easier for the development
team. Zeligsoft CE’s benefits start at the architect role.
The architects can perform their work at the model level,
enabling them to discuss, evaluate, and communicate
their artifacts easily.
The work of the architects is passed down to the
engineers for further refinement and elaboration. Ease
of communication continues as the engineers can
easily understand what the architects have laid out.
And the architects can stay in touch with what the
engineers have done.
Sharing of models between the different roles is especially
important in an iterative approach. Iterative development
puts a higher strain on the development team in their
sharing of artifacts. Zeligsoft CE simplifies the sharing
through model import/export. The team can evolve the
model throughout all of the iteration and generate
descriptors when needed.
This is what MDA is all about: instead of generating,
sharing, and reviewing code, the model is used as the
basis of all work. This means that all stakeholders see
and use the same artifacts. This increases mutual
understanding between the roles and minimizes mis-
communication.
The model is then used to generate the XML artifacts
needed. This increases productivity dramatically. Users
have reported productivity increases by a factor of 10
or more. The time saved through automation can be
used for quality increasing activities, such as more
design iterations or to reduce time-to-market.
15
XML generation from the model also reduces the
scope of knowledge that the individual team members
need to have of the SCA and its internal mechanics.
This reduced dependency on knowledge of the SCA
is especially important. Resources are scarce and
training is expensive. Certain development teams
may be conversant with the SCA, but many expert
engineers and component developers do not have
an in-depth knowledge of the SCA.
The XML generated from the model is correct by
construction. The tool-based approach provides
automatic validation of the adherence to the SCA
standard. This increase in quality is an important
aspect as correct XML files avoid significant time
loss during integration on the platform.
The XML Import feature facilitates understanding of
existing and third party XML. The XML can be brought
into the model, visualized, and then maintained from
there. During this process the XML is validated at the
syntax and semantic level.
The documentation generation feature eases the
documentation burden on the entire development
team. Documentation is a must in large projects.
Automation makes this feasible and enables the
development team to keep the documents up-to-date,
at minimum cost.
Zeligsoft CE delivers a modern automation environ-
ment to model, validate, and generate SCA compliant
applications.
12 REFERENCES
SCA
Software Communications Architecture
http://jtrs.army.mil/sections/technicalinformation/
fset_technical_sca.html
JTRS
http://jtrs.army.mil/
ZSFT-8
Developing SCA Compliant Systems
http://www.zeligsoft.com/papers/
zsft-008-Challenges.pdf
OMG
Object Management Group
http://www.omg.com
UML
Unified Modeling Language
http://www.uml.com
CORBA
http://www.corba.org
ZSFT
Zeligsoft Inc.
http://www.zeligsoft.com
RUP
IBM Rational Unified Process
http://www.ibm.com/software/awdtools/rup/
16
Zeligsoft, Zeligsoft CE and Waveform Builder are trademarks of Zeligsoft Inc. All other trademarks are the property of their respective companies.Version 1.0Printed in Canada © Copyright 2005.
About Zeligsoft Inc.
Founded in 2002, Zeligsoft is the market leader in tools, which enable the design, deployment and
configuration of component-based embedded software. With a history of active participation in
the development and evolution of key component standards, Zeligsoft tools ensure the customer’s
applications and platforms comply with rigorous industry- and company-defined standards. With
support for automated compliance testing directly in the tools, Zeligsoft users can stay focused on
what they do best. Eliminating labor-intensive and error-prone tasks throughout the development
cycle, Zeligsoft helps customers deliver high-quality products to market faster. Zeligsoft CE™
(Waveform Builder™) is a proven software development tool for projects targeting the SCA.
Contact Information
Website: www.zeligsoft.com
Email: [email protected]
Toll-free (North America): 1-800-ZELIGSW (1-800-935-4479)
Direct dial: +1 819-684-9639