Wednesday 7 March 2012

SASSY Increment #5

This increment involved a lot of work on the ontologies and some tweaks to
interpreter.


Interpreter

The interpreter underwent a few updates as usage threw up a few issues. The
initial version required the programmer to put in the offsets as numbers for
the jumps, conditionals and loops. This got tedious very quickly. I enhanced
the language to use labels for the jump destinations, and this seemed satisfactory
for a while. However on larger scripts managing the labels started to get
tedious as well. I then modified the language so that all jumps were always for
a single statement which allowed the parser to remain a single pass design and
the need for labels was removed. This is a much cleaner looking language.


A final enhancement was to allow forward references. To retain a single pass design
meant that the forward reference is patched when the real function is processed.


: aFunction noop ; # forward reference

: usingFunction
aFunction
;

: aFunction
usingFunction
;


When the parser finds a function that has already been defined it assumes the
previous instance was a forward reference and replaces the first operator
with a call to the real function.


There is getting to be a need for some documentation on writing these scripts.


Ontologies

A lot of work for this increment consisted of developing examples for the
various views that have been identified. For each view it was necessary to
define the ontology classes and properties. Then individuals were added for
the SASSY architecture and a script written to produce the documentation.
Frequently it became obvious quickly that the class design was wrong and
it would be necessary to begin again.


The following views have been defined so far - I can think of a few more
that would be useful for large projects.

Requirements
This view lists the requirements for the system with a cross reference to the tactics used to implement it.
Tactics
This view relates each tactic to the responsibilities that the system must implement.
Concept Modules
This view describes the system components at the conceptual level. It focuses on assigning responsibilities to modules.
Methodology
This view describes the development process. It is a reference view.
Implementation Modules
This view shows the components of the system, such as specific programs, libraries and databases.
Interfaces
This view describes the interfaces between components of the system.
Data Flow
This view describes the flow of data through the system.
Use Cases
A view which shows the sequence of component activations for each use case.
Quality Attribute Scenarios
This view shows the test scenarios that are used to validate the architecture.
Task View
This view enumerates the development tasks that are undertaken in each increment of the development process.
Team View
This view shows the responsibilities of the team members of the project.
Execution Modules
This view shows the allocation of processes and threads to physical equipment.
Computer View
A view showing what is running on each machine.
License View
This view shows the licenses applicable to the components of the system.
Network View
This view shows the network connections between components of the system, and any external systems.

Planning

It is probably time to reconsider the plans for SASSY. During the development
of the ontologies it became clear that actual development and the architecture
defined in the ontology were beginning to drift apart. In addition the release
notes for Protege indicate that the next version, 4.2, will include a client
server architecture and support for a relational database - these are both
things we need if SASSY is to support teams of architects working on large
systems.



Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

No comments:

Post a Comment