7th ACS Workshop 2010Antofagasta, Chile
ACS Project Lifecycle
Matias Mora
(based on presentation byG. Chiozzi and J. Ibsen)
7th ACS Workshop 2010Antofagasta, Chile
Introduction
ACS related development: Short cycles Functionalities added incrementaly
Main steps during each cycle: Requirements capture Implementation Integration
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
Implementation [1]
Steps: Interfaces implementation (language specific) Component simulation Component and high level tests implementation Component functionality implementation
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
Software Engineering Basics
Matias Mora
(based on presentation byM. Zamparelli)
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
Test directory
Place for all module specific test files Contains an own Makefile Usually contains a small CDB for component
testing (also deployment example)
7th ACS Workshop 2010Antofagasta, Chile
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
7th ACS Workshop 2010Antofagasta, Chile
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)
7th ACS Workshop 2010Antofagasta, Chile
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
Top Related