7 th ACS Workshop 2010 Antofagasta, Chile ACS Project Lifecycle Matias Mora (based on presentation by G. Chiozzi and J. Ibsen)

7th ACS Workshop 2010Antofagasta, Chile

ACS Project Lifecycle

Matias Mora

(based on presentation byG. Chiozzi and J. Ibsen)


Introduction

ACS related development: Short cycles Functionalities added incrementaly

Main steps during each cycle: Requirements capture Implementation Integration


Requirements Capture

Goal: group functionalities in high-level “components”, identified by their interfaces

Language independent Steps:

Requirements identification → Use cases Interfaces identification and component breakdown Subsystem/module creation


Implementation [1]

Steps: Interfaces implementation (language specific) Component simulation Component and high level tests implementation Component functionality implementation


Implementation [2]

Previous steps are not sequential! Tests are an integral part of the implementation

(test-driven development) Test layers:

Unit tests Component tests End-to-end/Subsystem tests


Implementation [3]

Unit tests: implementation language specific; written by component developer

Component tests: component interface specific; language independent; written by component developer or integration team

End-to-end/Subsystem tests: overall subsystem requirements related; written by the integration team


Integration

Deploy all the components together in an integrated configuration database (CDB)

Complexity depends on the number of components and interactions between components

Main focus on high-level/end-to-end test execution


Finally:

...start all over again!


Questions?


Software Engineering Basics

Matias Mora

(based on presentation byM. Zamparelli)


Software Module

Set of related files grouped together in a directory structure

Includes Makefile, implementation and tests Usually, a single component is stored in a

single software module


Directory Structure

<module>/idl Generic interface definition

<module>/include Language specific header files (C++)

<module>/src Source code

<module>/lib Application/test code libs*

<module>/bin Executables*

<module>/test Test code (separated from app. code)

…

(*) Populated by Makefile


ACS Makefile

Project wide set of rules, centrally managed ($ACSROOT/include/acsMakefile)

Each developer has to add only the module specific part → file names

Based on a normal Makefile Strictly correlated to the environment variables

and software module standards


IDL_FILES

Python StubsJava StubsC++ Stubs

ACE/TAOJacORB Omniorb

ACS XmlIdl compiler

Java Component Wrappers for

Container

XSDBIND (XSDBIND_INCLUDE)

Java Entity Classes

COMPONENT_HELPERS Java Component Helper Classes

ACSERRDEF

PythonJavaC++

Hierarchical Include

directories

Real Time Linux Kernel Modules

RTAI_MODULES

XML_IDL


Test directory

Place for all module specific test files Contains an own Makefile Usually contains a small CDB for component

testing (also deployment example)


ACSROOT

Default location of installed ACS binaries and libraries

Directory structure similar to module structure Reference through the $ACSROOT environment

variable Populated during build, if no INTROOT defined


INTROOT

Location for binaries and libraries for system parts under development

Directory structure almost identical to ACSROOT

Reference through the $INTROOT environment variable

Populated through Makefile build (make install)


Template Utility

Tool to create ACS directory structures Also provides templates for files according to

SE standards (Makefile, C++ headers and sources, etc.)

Executable: getTemplateForDirectory


Questions?

7 th ACS Workshop 2010 Antofagasta, Chile ACS Project Lifecycle Matias Mora (based on presentation by G. Chiozzi and J. Ibsen)

Documents

th acs workshop

chile implementation

chile requirements

chile integration

makefile slide

chile idl

single component

chile questions