![]() ![]() |
||||
|
||||
When you work in Eclipse/OSATE you access files in your file system through workspaces.
You can set up multiple workspaces, but you can only work in one workspace at a time. You
can use “File > Switch Workspaces…” to switch between workspaces.
A workspace can be any folder in your file system. The workspace is organized into projects.
Each project can be version controlled separately. Projects can be sub-structured through
folders.
OSATE also provides support for large-system modeling through separately developed AADL
models and for teams of people developing such models. OSATE makes use of the Eclipse
workspace and projects to allow large AADL models to be split into multiple files and to
support the team support services of Eclipse that interface with version control systems.
OSATE provides an automatic build capability that maintains consistency between AADL text
files and AADL XML files by regenerating one when the other is changed by the modeler. It
does so by propagating changes to AADL packages and property sets to other AADL files
that potentially are affected. Furthermore, it automatically regenerates any AADL instance
model that is potentially affected by changes to AADL models. |
||||
An AADL project can be created through the AADL Project wizard by invoking “New >
Project…” in the “File” menu or the context menu of the Navigator, and then selecting “Aadl
Wizards > Aadl Project”. The wizard is also available as a button (
![]() ![]() Figure 6: The "New Aadl Project" wizard button in the OSATE toolbar.
AADL text files are kept in an “AADL text” folder and AADL XML files are kept in a “model
folder.” (This is similar to the Eclipse Java IDE keeping Java text files in a folder called “src”
and the class files in a folder called “bin”.) By default these folders are called “aadl” and
“aaxl”. You can change these directories using the “AADL Build Path” panel in the project’s
“Properties” dialog as shown in Figure 7. In this document we assume the directories have the
default names “aadl” and “aaxl”. In general, there is a one-to-one correspondence between the
contents of the two directories, and they have a parallel structure. AADL instance models,
however, are stored as object models only in the “aaxl” directory.
![]() Figure 7: Changing the aadl text and xml model folders in the project "Properties" dialog box.
There are two special directories, exemplified in Figure 8, named “packages” and
“propertysets” in the “aadl” and “aaxl” directories. It is expected that files containing package
declarations be kept in the “packages” folder, and that files containing property set declarations
be kept in the “propertysets” folder. The names of these folders must not be changed.
![]() Figure 8: AADL projects have special "packages" and "propertysets" directories in both the text and
model folders. |
||||
Note: In Eclipse, files are referred to as “resources”.
OSATE understands three file extensions as AADL file types:
The following conventions are expected by OSATE:
There is a one-to-one correspondence between AADL text files and AADL declarative model
XML files. In other words, each AADL text file is converted into a single AADL XML file
and vice versa. |
||||
In AADL, packages and property sets reside in a global namespace. This means that
components and properties declared in them can be referenced by other packages and
property sets. In addition, each AADL specification has an anonymous namespace. Items
declared in an AADL specification are accessible within that AADL specification only.
In OSATE an Eclipse workspace represents a global namespace. An AADL PropertySet file
or an AADL Package file, i.e., a file with a single property set or package, is considered to
reside in the global name space. Each Eclipse workspace can only contain one globally visible
property set or AADL package with the same name and file name.
Aadl packages or property sets contained in an AADL Specification file are “locally” declared,
i.e., only visible within that AADL Specification file. Members of a globally declared package
or property set may be referenced by any AADL specification/property set/package in the
workspace. Members of a locally declared package or property set may only be referenced
from within the same file, thus the “local” appellation. A locally declared package or property
set in an AADL Specification file takes precedence over any global package or property set
with the same name. In other words, a user can place multiple AADL Specification files into
the same workspace or even the same project without causing name conflicts. |
||||