Development Architecture

This chapter describes the environment in which the development, testing and deployment occur.

In the worst case the developers are allowed to modify the production code, scripts or configuration. This is generally considered to be undesirable, but what is the preferred arrangement?

5 Levels

The proposal here is for a five level configuration environment where changes progress from development, through testing to deployment into the production environment.

Level 1

This level is for the software developers to create new software or to create patches for existing software. This level needs to be easy to configure by the programmers themselves since they may need to try various configuration alternatives in rapid succession.

Programmers should run their unit tests in the level 1 environment.

Level 2

The second level is for the integration of the software created in level 1. The only development at this level is for the build system and similar configuration elements. The software should be built on this level so that there is confidence that the correct supporting libraries are being used (and not something that is under development by some programmer).

Programmers should run tests to confirm that the software builds and runs as specified.

Development software, such as compilers should only be accessible from levels 1 and 2.

Level 3

The third level is for the formal testing of the software. The package created in level 2 should be installed in a controlled manner and then subjected to the testing specified for the system.

Level 4

The fourth level is for confirming that the new software will run in the production environment. Hence this level should be as close as possible in configuration, and size to production.

The software should be installed by the same system administrators responsible for the production system.

Level 4 is also the correct place for acceptance testing by the client to confirm that what has been delivered is what they are expecting.

Level 5

The last level is for the production system. Software should only be installed here after it has passed all tests and the client has agreed that it is OK to install.

Versions

It is typical for there to be more than one version of the software in existence at any one time. It would be wasteful to put the programming and testing teams on hold while the acceptance testing was being done, for example.

In a large project you may have several development teams working on different enhancements to the system at the same time as the test team is performing their test work, and the client might have a production version running while they are acceptance testing the next release.

It is also possible that there will be multiple versions of the software in production at the same time. A large distributed environment, for example, may not be able to promote all sites to the next production version simultaneously (or they may consider it unwise to do so).

If there are multiple clients for the software some may be constrained to old versions of the software for various reasons, both economic, and technical.

Increments and Releases

Modern software development practices emphasise the need to work on small, well defined and focused developments, rather than huge multi-year projects. Typically an increment to the development will take a few weeks to go through the analysis, design and programming phases.

On the other hand the client will find that performing acceptance testing is expensive and time consuming, and is not something that can be undertaken frequently.

To reconcile these two competing requirements we can keep most increments in the Level 1 through Level 3 environments, and only promote to Level 4 when the client is ready for the next round of acceptance testing.

This can be done by nominating a special increment to be a Release of the software.

Platforms

Sometimes it is necessary to support software on multiple platforms. These can range from different versions of Windows, to support across a variety of operating systems such as Windows, Linux, HPUX, Solaris, AIX, BSD, MacOS, etc. along with the multiple versions of each.

Support for different hardware is also becoming a much more common requirement as the ARM architecture is rapidly gaining prominence.

Finally support for different user interfaces is recently become a hot topic. It might be necessary to support a conventional desktop with keyboard and mouse, a touch screen device such as a touch enabled laptop or tablet, and perhaps even a smart phone. One should also not overlook the usefulness of a simple command line interface when it comes to remotely administering a computer.

Configurations

The software might be required to operate in a wide variety of different configurations. It may need to work on a simple stand-alone computer, to a large network within an organisation to a "cloud enabled" distributed system.

Different clients may also use different supporting software, such as databases, GUI libraries, and so on. These can be just different versions of, for example, Java, through to entirely different products.

Virtual Machines

If we multiply our five level deployment model by the number of supported versions of the software we can already get quite an unmanageable number. Multiply that again by the number of potential platforms and configurations and it becomes obvious that no one could have every combination ready to develop and test on.

The answer is, of course, to set up a collection of virtual machines with the most common combinations, and have some others that can be adapted to the more unusual arrangements.

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

Windows Future

As architects we need to have some understanding of what the future
might hold for the personal computing market. These devices form an
important component in most IT systems so its probably useful to
look at where they might be headed in the next few years.

Microsoft's Windows operating system has formed the basis for personal
computing for nearly two decades so this will be our focus. While
Apple have recently become the most valuable IT company they insist on
remaining hardware focussed, which ultimately means that they are limited
to about 10% of the total market purely because they are physically
unable to manufacture enough product by themselves. Microsoft products
however, can be installed on any computer so they have the potential
to be 10 times larger than Apple in terms of installed operating systems.

For this article I will define the term PC to refer to a machine that
has a keyboard and mouse. They are the laptop and desktop machines
that we are all familiar with. The term "tablet" will refer to a
machine that can be easily used without a keyboard or mouse, usually
because it has a touch sensitive screen.

The sales of PCs have grown almost exponentially for the last ten years
but are now showing signs that they will level off at about the 350 million
per year mark. Some analyses have shown a slight loss in market share
by Windows over the last few years. Combining these two pieces of
information and it looks likely that if Microsoft remained with just
PCs then it would have to report a decline in its sales. This would be
a major embarrassment for the management team at Microsoft.

Microsoft have, no doubt, been aware of this potential problem for some
time, and have been endeavouring to find some new source of income.
They tried a subscription system for Windows, but this sort of failed
when Vista was late being delivered. They are trying "Software as a
Service", (SaaS) but its likely that this is just eating into their
sales of Office. The products where SaaS works well are email and search
but they have a very strong competitor in the form of Google for
those markets.

Now Apple have shown them a new possibility - the App Store. The ability
to get a cut of every software sale would give Microsoft the income
stream they have wanted for so long.

The Apple tablet also demonstrated that it could be sold with a simple
smartphone style of interface rather than the desktop style that
Microsoft have been trying unsuccessfully for the last decade.
While the tablet sales are quite small in comparison to overall PC
sales, they are on a rapid growth trajectory that might be enough
to keep the total sales figures growing for a few more years.

The Metro interface, developed for the Windows smartphone, has been
adapted for the tablet. I will look at why it was also pushed into
the PC later.

The tablet needs to run on ARM since Intel have not been able to create
a sufficiently low power x86 device. This meant that there was no need
to be backward compatible - this machine could start with a clean slate.

The Windows tablet would need something to differentiate it from the
Android machines, and the most obvious solution was to include Office.
It would appear that the Office team was either unable or unwilling to
create a touch version, hence we have the rather awkward Metro-Desktop
switching which annoys the Windows-8 reviewers.

Microsoft almost certainly see the Android tablet as their number one
problem. Microsoft do not like it when something other than Windows
starts to get any sort of market share. We saw this with netbooks, the
first of which ran Linux, and did so quite well. MS responded by
bringing XP back so that there was a light weight Windows OS to use
on these small machines and, it's suspected by many, coercing the OEMs
into dropping Linux, probably by threatening to remove their OEM
discounts for Windows on their other machines.

Now we have Android tablets illustrating that you do not need Windows
to do computing. Microsoft is currently unable to coerce the OEMs
since they do not have an ARM version of Windows. This will change
with Windows-8.

I expect that Microsoft will use the X-Box strategy when they introduce
the Windows ARM tablets. The machine will most likely be sold at below
cost with the App store recouping the lost income. The use of UEFI to
lock down the machine so that no other operating system can be installed
supports this view. (You would not want to sell at a loss only to have
Ubuntu installed on it and not get any App store sales.)

Once the Windows ARM tablets become available I expect that they will
be priced below the corresponding Android equivalents. I guess that
Microsoft will hope that the lower price will make up for the lack of
available applications.

A price war among the tablets will spell the end for the laptop computer.
They will be squeezed from the bottom by tablets and from the top by the
ultrabook. This is sad for students that just need a cheap machine to get
work done. Prior to doing this analysis I thought that the ultrabook was
unlikely to succeed, but with the laptop being squeezed out I see that
it does have a future.

Will this work?

It is impossible to predict what the market will do.

It must be remembered that the tablet is not the most convenient
form factor. Its OK for things like recipes in the kitchen, browsing
the web from the coffee table or reading in bed, but for actually doing
any work its too big to be a phone and too small for the desktop.
The current rapid rise in sales might not last beyond those that
can afford it as a secondary device.

If Windows ARM tablets get ignored by the consumer then Microsoft
might do what they did with the Zune and the Kin - drop them
and go back to what they know - the PC. I am not so sure that this
would be their reaction since I think they can see too much potential
gain. I think they would advertise and price cut until the Android
tablets are overwhelmed.

If it does work and Android tablets follow Linux netbooks into
oblivion and Microsoft gets its new income stream via the App store,
what happens next? What can we expect from Windows-9?

Microsoft will want to extend the App store to the PC. It not only
provides an income stream, but it also allows them to screen out
malicious programs and viruses. I would expect that we will see
some API changes in Windows-9 designed to force developers to the
Metro and App store and away from the open desktop. This trend
will continue for subsequent releases of Windows since there is
so much to gain and so little to lose.

The PC's Future

With Microsoft moving to a Metro world what does that mean for
application developers? Basically the open desktop will become
deprecated. We will need to either build applications with a web
interface or pay Microsoft to distribute an app through their
store. Those dedicated business applications that you built using
.Net and other Windows APIs will eventually have to be rebuilt
for this new paradigm.

Many businesses are just now upgrading from XP to Windows-7 and
with the preview of 8 getting some quite hostile reviews perhaps
a lot more will move forward their upgrades so that 7 can be used
for the next few years.

Another factor to watch is the smartphone. Recently Ubuntu was
ported to an Android phone. This allows its user to use the device
as a phone while on the move and plug it into a proper keyboard
and display when in the office. You get the same applications
with all your data in both scenarios. There is enough power
in a modern smartphone for it run Linux well enough for office
use.

For docking to really take off though requires Google to define a
standard interconnect and protocol between the smartphone and
the desktop peripherals. Then an office could fit out with those
peripherals without worrying about which brand or model of phone
was going to be used and developers could write their software
to switch between the desktop and portable modes.

Conclusion

Windows-8 on the PC probably won't get much traction. They will get
their usual sales to consumers as they upgrade their hardware but
businesses will stay with Windows-7. On the tablet there will be a
fight until it displaces Android - might be quite nasty.

Windows-9 will attempt to push the Metro/App-Store model onto the
PC. Businesses will be forced to migrate their applications but
might well respond by moving to docked smartphones and web
applications.

While Microsoft has the resources to weather the storm that
Windows-8 brings, it is by no means certain that they will make
the correct decisions to return to a profitable path for
Windows-9.

Addendum - Jan 2014

I guess I underestimated the greed of Microsoft. They seem to have been mislead by thinking that just because everyone uses Windows it must actually be popular, and on that basis priced their tablet devices to be just barely competitive with Apple, rather than going after Android.

Given the extra resources that Windows needs above Android it will never be able to compete on price alone - the bill of materials is just too much larger. Additionally the other OEMs are having to pay for Windows licenses, making them even less competitive.

In the mean time Android have just about conquered the tablet market, with Apple falling steadily further behind. The prices for Android tablets have fallen to under $100 and are continuing to places that Microsoft can't follow.

My prediction now is that Microsoft will make a second attempt with the Surface line, but if it fails again, they will withdraw back to the rapidly shrinking PC market, with perhaps continued support for smartphones via Nokia.

This could mean the end of the "Devices and Services" model - the incoming CEO will have no attachment to that idea - and a focus on the business market. Businesses can expect to see a steady rise in the cost of using Windows as Microsoft try to keep the profits coming in a shrinking market.

There is a danger that Microsoft will be unable to manage its own downsizing and will collapse in some way.

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

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.

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

Copyrights

When developing a software system the issue of copyrights can have a significant
effect on the solution. You will need to get licenses for the proprietary
components of the system. You will need to arrange for the users of the system
to also get the appropriate licenses. I have seen discussions during the
architectural design phase where the licensing costs actually drove the design
of the system. The best solution, technically, was put aside in favour of an
alternative that would be cheaper to license.

Perhaps its time that the whole question of copyrights is revisited to examine
whether it is relevant to the modern world. I will look at a variety of media,
including books, clothing, music, film, and software.

Books

Copyrights were introduced to control the publishers of books. In return for
not printing anything the sovereign did not approve of, publishers gained
exclusive rights to certain titles. The current copyright laws can be traced back
to the English "Copyright Act of 1709", also known as the "Statute of Anne".
Quoting from Wikipedia, the central plank of the statute is a social quid pro
quo; to encourage "learned men to compose and write useful books" the
statute guaranteed the finite right to print and reprint those works. It
established a pragmatic bargain involving authors, the booksellers and the
public.

The role of the book publisher has been primarily the conversion of the author's
manuscript into a typeset format which can be easily printed in large numbers
and distributed to book stores. Given that we now have computers that allow an
author to produce high quality originals and the internet that allows the near
instant distribution of those works directly to the readers it is hard to make
much of a case for the continued role of book publishers. The remaining problem
is how to reward the author, how do we encourage "learned men to compose and
write useful books"? I will address this later.

Clothing

The fashion industry has never been under the umbrella of copyright protection.
However few could argue that it has not been vital and innovative despite this lack
of protection. Even though designs are widely copied and available to be bought
within hours of them appearing on the catwalks there seems to be no pressure to
bring this under any form of copy prevention. The leading fashion houses are
some of the most profitable and well known businesses on Earth - all without
the backing of copyrights.

Music

Prior to the invention of the gramophone, the music publishing industry roughly
paralleled the book publishing industry. The gramophone record was interesting
in that it could be sold to the public, but there was no means for anyone to
make a useful copy.

When radio came along the focus moved to using performance rights to get
payments from the radio stations. (It could be argued that the
music publishers made more from the playing of their products than the radio
stations, but never-the-less the radio stations were made to pay.) The aggressive
policing of performance rights is why you are banned from singing "Happy Birthday"
when you hold a party at McDonalds.

The tape and cassette recorders of the 1960s and 1970s which were used by most
people to make copies of the fragile records so that the music could be played
on portable devices was barely tolerated by the music industry, but there was
not much that they could do about it at the time.

The compact disc and personal computer was the game changer for the music
industry. It was now possible for the average person to make a perfect copy of the
original. Not just a noisy, poor quality copy - a perfect copy. Add in the
internet and it now possible for nearly everyone to have a copy of a musical
work within minutes of it being performed, and at near perfect quality.

The copyright laws which were originally designed to control publishing
businesses were now aimed at the individual consumer. Punishments that were
designed to prevent one publisher from copying a single work of another were
suddenly applied to individuals that made their collections available for
others to copy.

Film

The film industry is a little different from the others. While a book is normally
written by a single person; music, software and clothing by small teams, a film
requires dozens to hundreds of people to make. However, film is different in
another very important respect - they have the cinemas to display their works.
These days most films make most of their income in the cinemas on the first
weekend.

Given that modern cinemas get their movies in digital form, and that the
cinemas are under a business contract with the film distributors, it could be
argued that films remain in private control even after they are screened. It
is not until the movie is published on DVD is it open to the world in which
copyrights apply. (Of course, publishing a copy on the internet before it hits
the cinemas is likely to be a case where the full force of the law can be
applied.)

Software

Most software is developed "in-house" to satisfy the needs of the company for
which it is being written. The remaining 10% or so is software for sale - office
programs like Word, Excel, Photoshop; and entertainment software such as World
of Warcraft. The software industry has been quite successful at limiting copying
without resorting to suing its customers for copyright infringement.

Rewards

The clothing and software industries seem to be doing fine without resorting to
copyrights. The film industry would probably survive quite nicely if they only
got the income from the cinemas. This leaves books and music, and perhaps DVD
movies that need some new business model.

If we dropped copyright protection a work would have two states - it would
either be private and under contractual control only accessible to the
developers of the work, or it would be public where it could be copied about
indefinitely. Obviously once a work is public it has almost no intrinsic value
and trying to extract value from it would seem futile. The value of the work
during its private phase is also rather low - in fact it is a liability since
effort has been expended on its creation for no reward.

The trick then is to persuade the public to make some contribution in return for
the work making the transition from private to public. This is a one-time
opportunity to make money. It removes the rather silly effect of copyrights
where someone can make popular work and live off the income from it forever
- a situation which defeats the original intention of copyrights as an
encouragement.

One possibility is to have governments pay for the work. This might not be
sensible for pop music, but for school text books or works by the national
orchestra it might well be appropriate.

Another possibility is a system of patronage, where wealthy organisations or
people pay for the work to be released. This was the main means of support for
authors before the modern era. For example a university might pay for the works
of some authors.

A third possibility is for an auction system. A part of the work is made available
along with reviews of it. The work would be placed in a vault until some desired
amount was contributed by members of the public. When the amount was reached each
contributor would get a copy that they could then do with as they please.
Acting as agents for such a system would seem to be the logical thing for
the current distributors and publishers.

Conclusion

The desire to share stuff is one of humanities deepest emotions. It has been
one of our defining characteristics since we climbed out those proverbial trees.
When something we have can be shared immediately and at almost no cost the
desire to do so is almost overwhelming.

To attempt to make such sharing illegal is even dumber than trying to
stop people from drinking alcohol. It can only be attempted with the most
draconian laws and the removal of citizen rights that make our modern civilisations
tolerable.

Technology has passed the publishers by. It is time for them to find something
better to do.

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

SASSY - Increment #4

This increment has not gone well. I started off with trialling SPARQL-DL
as a query language for the OWL database. At first it seemed OK - it could run
some of the simple queries that paralleled the examples in its source code.

Getting the results out involved adding in a JSON parser. The only C++ one I
could find wanted to do everything using wide characters which added to the
complexity somewhat.

When I tried some of the more complex queries that will be needed for this
project things started to go awry. I contacted the author and he confirmed
that it was not capable of doing the queries I wanted. It could handle
relationships between individuals, but not those that involve
querying the relationships between classes.

Further research has not turned up any likely candidates for this problem,
so it appears that I will have to work up my own solution.

At about this time there have been some significant changes to my personal
life, employment and so on, which have been a bit distracting. I also invested
in a new computer with a bit more more performance, and it was a significant
distraction setting up all my favourite software on this new machine. Then
Christmas came along to further delay things. Anyway, I hope to be able to put a
lot more time and effort into this project for the next few months.

The break gave me time to reflect on the way forward. My decision was to build
a small interpreted language that could be used to query the ontology database
and construct the document. I chose a threaded interpreted language, similar to
Forth, as the basis since they a very easy to implement.

The interpreter deals with a range of objects, such as integers, strings,
and several complex structures used to return results from the database, plus
arrays of these objects. I wrapped them up and accessed them using a smart
pointer object so that they would be automatically managed and could be
placed onto a data stack.

The interpreter uses three stacks, a return address stack for subroutine calls,
a data stack for manipulating the results of the database queries, and an
object stack on which the document is constructed.

The runtime interprets a byte code array which consists of either indexes into
an array of function objects, or to the location of a subroutine within the byte
code array. The function objects are responsible for manipulating the stacks and
for making calls to the ontology database. The only other entries in the byte
code array are integer parameters used for jumps or indexing into the data stack
to load string constants.

A very simple, single pass parser is used to convert a textual version of the
program into the contents of the code array (and the string constants in the
data stack). This was mainly introduced as it was too tedious to hand calculate
the targets for jump statements.

Using this language I have been able to reproduce the architecture document, so
I am confident in using this as the basis for the remainder of the project.

The next phase will involve a significant overhaul of the ontology database for
the architecture. During my break I have been reading the "Description Logics
Handbook" and have been slowly gaining a better understanding of this subject.
The net result is that a lot of classes in the ontology need to be converted to
being individuals - so a lot of rewriting will be necessary.

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

SASSY - Increment #3

The aim of this round of development is to tidy up some of the rough edges
from the first round. Our first cut was done with the aim of getting
something done from which we could base the subsequent development. In the
rush it was easier to copy and paste similar code, and there were a few
bugs in the way diagrams were displayed.

To organise the work I used the Mantis bug tracker program and noted down
all the things that needed attention. Again, for this increment the aim
was not to extend the functionality, but rather to focus on the quality.

The following bugs were addressed:

Empty boxes in diagrams

The diagram building code got additional checks to ensure the diagrams were OK.

Diagrams the wrong size

The temporary file name given to the diagram's eps text turned out to be not unique. This resulted in some diagrams being scaled twice, and others not at all. A better file naming algorithm cured the problem.

Hyperlinks flowed into the margins

The LaTeX processor in dvips was not able to handle hyper-links adequately. I found, and installed a newer package, called dvipdfm, that could correctly break a hyper-link.

Table of Figures

The architecture document has a lot of diagrams, and it really needed a table of figures to appear after the table of contents. A few changes to the boiler-plate had that included easily.

Formatting Issues

Some paragraphs needed to be indented, so I constructed a LaTeX command to provide the required formatting. Also fixed the boiler-plate for things like the revision history and copyright notice. Finally I added a new SASSY logo.

Quality Attributes

The Requirements document was listing the quality requirements correctly, but these were worded in a way that referenced the corresponding quality attribute, which was not being shown. Some modifications to the code soon fixed that issue, and now the requirements are quite readable.

Requirement Priorities

I had put some support in for handling the priority of a requirement but it was unused. This meant that you could not separate the mandatory from the important or the "nice to have" requirements. I added a classification to each requirement, and added the code to display this information in the generated requirements document.

Code Refactoring

Common code was separated out, paramaterised where necessary, and placed into the appropriate parent classes.

Conclusion

The programs now form a solid basis for the rest of the project. We have
something from which we can build on and which will usually be in a working
state if we need to show it off.

My main concern is that the code to generate the documents is too
dependent on the structure of the ontologies. This is something we will
address in the next increment where that aim is to incorporate SPARQL-DL
into the design.

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

SASSY - The First Cut

In the previous round of development we demonstrated that it was possible
to generate a document from the content of an ontology. Now its time to do
an initial version of SASSY with a useful amount of functionality. The project
for this will be SASSY itself.

Requirements

The first step is to document the requirements. Eventually we will do this
using SASSY, but this time we will have to fall back to using a word processor.
The main requirements are:

• The system shall enable the user to maintain a set of reference ontologies.
• The system shall allow the user to maintain a set of project specific
  ontologies.
• The system shall allow the user to generate documents based on the reference
  ontologies.
• The system shall allow the user to generate documents based on the project's
  ontologies

Architecture

The system will use Protege to create the ontologies and save them to an
RDF/XML database. We access this database using the Java OWLAPI library,
and connect to the library using ICE from a C++ program. To keep things
simple, that C++ program is a command line program that accepts commands
on its input to perform various actions. A small GUI program, using Qt,
provides a graphical interface that runs the command line program when it
starts and passes the user commands to it. The GUI will have a tool bar
for launching Protege, a document viewer, the ontology viewer we built
previously, and Firefox for viewing help documentation.

In the final design we will have components for logging and tracing the
code, as well as administering the server processes. For this increment
we will not bother with this functionality.

User Interface Design

The Qt based GUI will have a tool bar and menus and a set of tabs with one
for each major action: Quality Attributes, Requirements, Data Dictionary
and Architecture. Other tabs will be added later for tracing and Configuration
Management. Each tab will allow the user to set parameters for the particular
action. Eventually we will get these actions from a configuration file and
the ontologies, but for this increment we will just hard code it.

Design

The ICE interface specification, for this cut, will have a separate module for
each action. Later we will re-factor the common components into a base module.

The Java code will have a server class that allows clients to connect using
the ICE protocol. For now we will just use a hard coded port for the comms.
Each ICE module results in a collection of Java classes that are automatically
generated from the ICE interface definition. We also need to create the server
implementation classes that use the OWLAPI to access the ontology databases.
It seemed prudent to keep the generated code separate from the hand built stuff,
and fortunately Eclipse is able to handle building in such a structure.

The C++ code for the ICE interface is accessed through an abstract class. This
keeps the implementation out of the remainder of the code, which does not even
need to include the ICE related header files.

The core set of classes manage the process, including interpreting the commands
from the GUI and running the filter programs that convert the LaTeX into PDF.
This core includes some base classes from which action specific classes are
derived. These include document and diagram modelling classes which builds an
internal representation of the document, and a formatting class which converts
the model into LaTeX.

Another set of classes handle the details of documents, sections, paragraphs
and diagrams. I added the ability to use hyper-links in the PDF which meant
that I had to design a mechanism to allow attributes to be assigned to the
text. For now it only handles the hyper-link references and targets, but it
could be extended to other attributes such as colour, underlining, italics
fonts, etc.

Development

For this first rough cut the focus is to get something working. Each action
was developed without much thought to the others, apart from finding bits of
code that could be copied. The result will need a fair amount of re-factoring
and cleaning up before its used as the basis for subsequent increments.

The Quality Attribute section was the simplest since it is reporting an
ontology that will just be used as a reference. Hence the code can have some
knowledge of the ontology hard coded into it. The focus was on developing
the best techniques for getting and formatting the data. A final step was to
add some diagrams.

The Requirements section was a little more complex in that the ontology
would mostly be unknown. It also used data relationships which required some
additional research to find the best way to access the data.

The Data Dictionary section built further on creating an ontology dependent
document, and added cross references in the form of hyperlinks to the PDF.

Finally the Architecture section could build on all these techniques to
create an initial architecture document. For this cut I restricted it to just
the conceptual view and the logical view of components. It became evident
that creating nice diagrams was still going to be complex, so this will need
to be one focus for the next increment.

Conclusion

It became clear during the architecture development that building the
document was too dependent on the content of the ontology. For the simpler
documents this would be OK since we could control what relationships would
be used. However, for the a more general ontology this starts to become
problematic. Also it bacame evident that some way to generate new views of
the data would be necessary. A little research found SPARQL-DL which should
allow us to build a system where new views can be added through the
configuration for SASSY.

The next increment will tidy up some of the rough edges, such as diagram
scaling and orientation, and re-factor the code so that it is a bit more
maintainable.

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

SASSY - Proof of Concept

The first development cycle for the project is designed to determine if the
concept is even possible. To demonstrate this we will build a small application
that takes an ontology prepared by Protege and attempt to generate LaTeX and
then PDF.

For my test data I built an ontology of quality attributes. Every term like
maintainability or performance that was mentioned in the literature was dumped
into this ontology, along with a short description of what it means. This will
later be enhanced to incorporate the various quality frameworks that
researchers have developed to try and bring some structure to this collection.

I then started by using GCJ to compile the Java OWLAPI library so that it could
be linked to my C++ code. After a bit of hacking the Ant build script a
successful build was created. I was able to call this from C++ code and
generate some fragments of LaTeX. Adding in some calls to the dvips and ps2pdf
programs completed the process.

After a bit of work it became evident that the version of OWLAPI that I was
using had a problem with one of the functions that I wanted to use. The release
notes for the subsequent version indicated that this had been resolved, so I
downloaded the latest version and recompiled it using GCJ.


At this point things started to go wrong. The program would build OK, but when
run it would disappear into a loop that steadily used up all available memory.
I tried to run it under Valgrind to determine where the memory leak was, but it
promptly reported that I was attempting to execute an illegal instruction.
Trying it under GDB was no better; it reported a segment violation and showed
a stack trace that made no sense whatsoever. As far as I can tell the code
generated by GCJ was not being loaded correctly by the linker. After a week or
so of trying to get to the root cause I decided that perhaps an alternative
approach was warranted.

The only other solution I can think of for combining Java and C++ is to use CORBA.
The OWLAPI library would be made into a server process and the application would
be a client. This would give the application some additional freedom since we
could now distribute it across multiple processes or machines if necessary.
However, I wanted to use open source and it became apparent that there was no
viable open source CORBA product that had bindings for both C++ and Java. There
were plenty that supported Java and a few for C++, but nothing workable for both.
I was starting to look into passing data between CORBA implementations, which seemed
to be a possibility thanks to standards employed by these products. The idea
of having to support two CORBA implementations, though, was a bit of an issue.


During my CORBA research I came across the ICE product by ZeroC. This product is
open source, has bindings for a wide range of languages and platforms and seems
to be actively supported. It works much like CORBA but without a lot of the
complexity, which I think is nearly always a good thing. After a few experiments
to become familiar with building ICE applications I redesigned the interface to
use ICE generated code and successfully completed the proof of concept.

My work with Protege to develop the quality attribute ontology highlighted a
problem with the visualisation of the ontology. I decided that it would be good
practice to develop an application that would enable its user to graphically
navigate the ontology and to display all the relationships between the entities
of the ontology. I used the GraphViz dot program to generate a diagram based on
the data extracted from the OWLAPI using the ICE generated interface. The
output of dot was set to SVG and I used Qt's SVG and SceneGraph components to
create the visual representation. The result was a program that can quickly
navigate an ontology.

The first increment of the project was thus completed successfully, albeit with
a radically different architecture that was first envisaged. We now have a basis
for designing and developing the software.


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

SASSY - Project Establishment

The preliminary analysis did not turn up any insurmountable issues, so the
next step is to establish a project for the development. While I do intend for this
project to eventually be a collaborative development, I wanted to get the core
of the project written in a more private setting. Once I have something usable I
will transfer it to a public development area, such as Source Forge.

Fedora Linux

Since I am most comfortable in a Linux environment, and it has all the development
tools I could possibly want readily available, the project will be established
on my personal computer which runs Fedora Linux. I chose Fedora as it is based
on Red Hat which I often use for work, but tracks the latest developments. I
avoid the worst of the "bleeding edge" by remaining one release behind. This
means that all the issues will have been worked through when I upgrade.

Project Structure

The first step is to create the directory structure for the project. I created
a typical Subversion structure containing a trunk, tags and branches directories.
I will be using Subversion as my version control system. Once it goes public I
may consider using Git, but that is a decision I can make later. Within the trunk
I then created a bin, lib and include directories to install into, plus a docs
directory for documentation, an ontologies directory for data and a workspace (ws)
directory for the source code. The use of ws rather than src comes about since I
will be using Eclipse for the project's IDE, and it creates workspaces into which
the source projects are placed.

Documentation

I find it useful to document stuff (my memory isn't what it used to be), and for
this project there will be several documents, so the next step was to create a
document template for the project. The vision statement and the preliminary analysis
were then brought into the project. I will initially use Open Office, but expect to
move to Libre Office in line with Fedora.

There will be various diagrams for class diagrams and such. I use Dia as my diagramming
tool since it does a reasonable job of UML, and includes a variety of other symbol sets.
The aim of SASSY is to automate the creation of the diagrams, but until its up and
running I will need to do them by hand.

Tool Set

I like to document the various products that I use on a project. It makes it much
easier on the next project to be able to refer back to how it was done last time.
For each product I record how it was installed, any configuration that was done,
and any tips for using it.

As mentioned I will be using Eclipse for the IDE. Normally I would just run up a
few terminal sessions and use vi to do the editing. However, when working with
large, complex libraries things like auto-completion are very handy. I expect to
be doing C++ development as well as Java, so I included the CDT package from the
Eclipse repository. The CDT package also supports autotools which can simplify
development if we ever need to support a range of platforms.

For designing the user interface the Qt Designer is a suitable product, especially
since I will be using Qt for the user interface programs.

For defect tracking I am a fan of Mantis. I wanted to use PostgreSQL for the
underlying database, and after a bit of hacking I have this working satisfactorily.
For the very large projects that are the very reason for SASSY we will eventually
need to store the data in a database, as opposed to a simple XML file, so getting
PostgreSQL into the mix early on has some plusses.

Component Products

For the user interface programs I have chosen the Qt libraries. This package has
a complete user interface library in C++, is available for a variety of platforms,
and is open source. It also has an abstraction layer for the operating system which
may eventually be useful if we support multiple platforms. The only down-side I
see is that it has its own implementation of templates for containers etc rather
than use the STL. This can result in a lot of code moving data between containers.

The Protege product provides a complete front end for entering and editing an
ontology. It is under active development but is satisfactory for the initial
development. There are currently some issues with large databases and multiple
users for the OWL version 2 environment, but I am hopeful that these will be
resolved by the time we need them.

Program access to the ontology database is via a Java library called OWLAPI,
available from Source Forge. I am also looking at the owldb library which
aims to provide the database storage for large projects.

The mixture of C++ and Java presents a small problem since you cannot easily
call the Java libraries from a C++ program. My approach, initially, was to use
GCJ and compile the OWLAPI library into a form that can be linked into a C++
program. This eventually came unstuck, but that is a story for another time.

The documents will have diagrams so the GraphViz package gets a run for this
project. It allows you to input a graph in a simple format and does all the
layout for you, producing an output in a variety of formats.

The document formatting will be done with the LaTeX package. The output can
be converted to PDF using various command line tools.


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

SASSY- Analysis, Part 9

Interfaces

In this last blog on the preliminary analysis for the SASSY project we look at the interfaces between our software architecture system and the surrounding environment.

Input Interfaces

The inputs to the software architecture process are the vision statement, the preliminary analysis document, the data dictionary and the functional and quality requirements documents.

The software architecture process also contains a body of its own knowledge. Currently this is mostly held in the expertise of our software architects, but for this project we aim to capture as much as we can into a core software architecture ontology.

For a general project there may not be much control over the format of the inputs since they may come from a client who will simply provide the requirements etc. as a set of word processing documents. We can either accept these documents as the input, or transcribe them into the ontologies described in the previous blog. It may be that the act of transcribing them will uncover gaps which the preliminary analysis can attempt to resolve.

Output Interfaces

The outputs from the software architecture are a set of documents and diagrams that describe the system from a range of viewpoints.

Glossary

From our vision statement we intend to use knowledge engineering, specifically ontologies, to store the software architecture, and we also understand that we intend for this to be used when creating very large systems. One of the tasks in building a system, and an output of the preliminary analysis, is the glossary or data dictionary for the project's terminology. For a very large system it would seem logical to use an ontology to store this data dictionary.

Given that the aim of this project is to produce documentation from the contents of an ontology, it would seem reasonable to extend the project to the generation of the glossary ontology.

Requirements

It is often useful to know how all the parts of a software system are related. In particular it is often useful to know what functional or quality requirements drove various aspects of the design, code, testing, documentation, etc. If we were to relate all the components of a system together into an ontology then it might be possible to readily deduce such information and thus be in a better position to maintain the system.

Hence the requirements for the system should be drawn into the software architecture ontology, or perhaps exist as an ontology of their own which can then be referenced from the SASSY ontology.

Quality Attributes

Also from the vision statement we can expect our system to have a core Software Architecture ontology, and part of this will be a collection of quality attributes. These would be of interest when creating the Quality Requirements document, so it would appear to be a useful extension to the system to be able to print out such a list from the Software Architecture ontology.

Document Format

There are a variety of possible formats for the documents, ranging from plain text, to HTML, Word Processing and to PDF.

While plain text might be the easiest to generate, and it has advantages if you want to do further processing with it, it does not present very well to those that expect to see a high quality product.

HTML is fine for on-line viewing, but generally does not print well. If XHTML is used it can still be further processed if necessary.

The internal format of most word processing documents is quite complex, and sometimes not well documented. This makes generating the documents quite difficult. The other problem with word process documents is that they can be subsequently edited. There is, therefore, a danger that the output documents will be maintained, rather than the underlying ontology. This could lead to confusion as documents get out of step.

One option that produces high quality output, in PDF, is to generate LaTex. This is a well documented format that is easy enough to generate.

Diagram Format

The natural choice for diagrams is SVG. This is easy to generate, both manually and with various tools.

It is also easy enough to further process if necessary, since it is just XML.

While simple diagrams can be, and probably should be, embedded into the documents to which they refer, larger, more complex diagrams might be better left as separate documents.

If we allow separate documents for the diagrams it opens up some additional possibilities. We might introduce a third dimension and create a 3D model that can show more complex relationships than would be practical for a 2D diagram. Alternatively we might use animation to show how things change over time.


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

SASSY – Analysis, Part 8

Ontologies

In their papers [BER06] and [HAP06] four different purposes are proposed for using ontologies:

• Ontology–driven development (ODD): ontologies are used at development time to describe the domain.
• Ontology–enabled development (OED): ontologies are used at development time to support developers with their activities.
• Ontology–based architectures (OBA): ontologies are used at run time as part of the system architecture.
• Ontology–enabled architectures (OEA): ontologies are used at run time to provide support to the users.

The SASSY project aims to demonstrate how ODD and OED can be used during the architecture phase of development. Of course this means that the SASSY project itself will also use OBA and OEA.

Data Dictionary

An ontology (ODD) can be used to describe the problem domain. [HAP06] For projects beyond a certain size a simple glossary of terms ceases to be of much value. Once the project has got to the size where it becomes difficult to remember all the names of things you need something more than the ability to look up by name. An ontology with its more structured and linked view can make finding things easier.

The ontology also allows you to capture the relationships between objects, and, using data properties, it allows you to begin the object modelling.

Requirements

The requirements for a very large system can become a huge document in its own right. It is also common for there to be relationships between the requirements. Thus the requirements are another candidate for an ontology (ODD). [HAP06]

The ability of the Web Ontology Language (OWL) to import one ontology into another means that a requirements ontology can be imported into other ontologies, such as the software architecture ontology and the traceability ontology.

There are quite a large number of possible Quality Requirements that might be considered when creating the requirements document for a system. An ontology (OED) of documented candidates can be referenced during the development of the system requirements.

Software Architecture

The Software Architecture discipline has a large body of knowledge that might be more useful as an ontology (OED). The SASSY project aims to demonstrate the utility of such a collection.

There should be a static ontology that encapsulates the discipline, and a second that captures the specifics of the project.

Since OWL allows ontologies to be imported into other ontologies it might be sensible to partition the SA discipline into several smaller ones.

Traceability

For many systems it is important to know how each component depends on the system requirements. There is rarely a one-to-one mapping from requirements to components, or lines of code, so some way of capturing these relationships seems to be called for. An ontology (OED) seems like a candidate, and the SASSY project should support tracing requirements through the architectural design phase.

Configuration Management

When a large system is being developed by multiple teams, working at differing rates, perhaps even on completely different increment cycles it can become “interesting” trying to keep track of which combinations of components are known to work together (or not).

An ontology, with its ability to handle a large variety of relationships, seems like a good fit to the configuration management problem.



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

References

BER06: Julita Bermejo Alonso, Ontology-based Software Enginnering, 2006
HAP06: Hans-Jörg Happel, Stefan Seedorf, Applications of Ontologies in Software Engineering, 2006

SASSY – Analysis, Part 7

Architecture Analysis

Once a design has emerged it needs to be analysed to determine how well it will meet the requirements. The analysis is usually a risk based approach since a complete formal analysis would be too time consuming.

The usual approach is as follows:

• Each quality scenario is examined in turn. For each one a rating of its importance is given – low, medium or high. The stakeholders will need to discuss and agree on these ratings.
• Then each scenario is examined to see how it will perform under the proposed design. A risk level (low, medium or high) is assigned indicating how easy it is likely to be that the requirement can be met.
• The important and high risk scenarios become candidates for alternative tactics or designs.

However, once we have the architecture in a machine usable form we have some additional possibilities. We can perform various measurements on the interconnections between the components to get metrics for the dependency relationships.



In his thesis on a Software Architecture Analysis Tool Johan Muskens suggested the following measurements:

• Components that call a service or from which a service is called in context of a scenario that is part of a specific use-case. The main thought behind this metric is that related functionality spread over the design is bad for maintainability and reusability.
• The number of use-cases that contain a scenario in which a service of a specific component is called or in which that component calls a service. The main thought behind this metric is that cohesion within a component should be high.
• Tasks should be distributed over the design as equally as possible. When the number of called services of a component is high this can give an indication that the component is a possible bottleneck when considering scalability. It also indicates that dependency of other components on the specific component is high.
• the number of service calls of a specific component for all scenarios. Main thought behind this metric is that dependencies are bad for reusability and maintainability.
• the number of different services called by a specific component for all scenarios. Main thought behind this metric is that dependencies are bad for reusability and maintainability.
• the number of provided services of a specific component. The main thought behind this metric is that a well balanced distribution of functionality over the design is good for extendibility and maintainability.
• the number of components of which a service is called. The main thought behind this metric is that dependence on many different components is bad for reusability, extendibility and maintainability.
• the number of components that call any service of a specific component. The main thought behind this metric is that a large number of components depending on a specific component is bad for extendibility and maintainability.
• the average number of state transitions per service for a component. Main thought behind this metric is that complexity of components / services is bad for maintainability and extendibility.
• the maximum number of subsets of services of a component such that the sets of use-cases using services of the subsets are disjoint. It gives an indication of the cohesion between the services provided by a component.
• The last metric gives an indication of the complexity of a scenario. It measures how deep the service calls are nested for a scenario. If the depth of a scenario is to high this is bad for the understandability and therefore also bad for maintainability and adaptability.

The absolute values for these measurements is not the important criteria. However, values that are abnormal may indicate some problem with the design.

If we add attributes to the components then we can also measure things like performance and portability for the overall design. For example components could have an attribute that indicated what platforms it was suitable for. This would then feed into the execution architecture to control how the components would be assigned to platforms. A performance attribute for each component could be used to assign components to CPU cores to get the best cost vs performance balance.

It might be possible, eventually, to automate the analysis phase sufficiently to enable it to be used to automatically refine the architecture. Techniques such as genetic algorithms might be able to generate and test various alternative designs and perhaps come up with some new design patterns. For the really large systems that we are contemplating this might be the only way to do it.

This is the completion of the description of what a software architecture is. Next we will look at ontologies as these will form the basis for SASSY.


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

SASSY – Analysis, Part 6

Views and Viewpoints

The proposed design is documented in a series of Views, each from the viewpoint of one or more stakeholders.

It is important to keep the number of viewpoints in each diagram or document to a minimum, otherwise there will be confusion over what the document is trying to express. This means that for a large system there can be a multitude of documents, which can become a hindrance to the understanding of the system in its own right.

In the paper [M&B05] describe six types of architectural views – behavioural and a structural views for each of the conceptual, logical, and execution architecture. They go on to suggest the following should form the minimum set:

• Reference Specification. The full set of architecture drivers, views, and supplements such as the architecture decision matrix and issues list, provides your reference specification.
• Management Overview. For management, you would want to create a high-level overview, including vision, business drivers, Architecture Diagram (Conceptual) and rationale linking business strategy to technical strategy.
• Component Documents. For each component owner, you would ideally want to provide a system-level view (Logical Architecture Diagram), the Component Specification for the component and Interface Specifications for all of its provided interfaces, as well as the Collaboration Diagrams that feature the component in question.

For SASSY the knowledge base forms the reference specification. The management overview seems to be a collection containing the original project vision statement, the preliminary analysis, in addition to a view showing the conceptual architecture. The component documents outlined above would be a good start, but you will also want other views, such as a network view and a database view, that have a system wide perspective.

There are a lot of different views that can be created for a complex system. Various researchers have attempted to classify these views into view models, such as the 4+1 Architectural View. Despite these models the views for any particular system should be carefully selected according the specific requirements of the project.

The core ontology for SASSY will need to have a collection of views defined along with a relationship that allows the components of the design to be associated with one or more views. We might also include view models so that the user can quickly select a collection of views that will have good coverage of the design.



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

References

M&B05: Ruth Malan and Dana Bredemeyer, Software Architecture: Central Concerns, Key Decisions, 2005

SASSY – Analysis, Part 5

Design Patterns

Once the tactics for achieving the desired quality and functionality have been selected the next step is to choose the design patterns that can best implement those tactics. Note that we are not interested in design patterns that deal with algorithms and data structures (such as the observer pattern) but rather we are looking for structural design patterns such as a client-server design.

The SASSY Ontology will need to include a catalogue of architectural design patterns and provide a means to include them into the design for a specific system. High level patterns such as ETL, SOA, Publish/Subscribe, Client/Server, Message Exchange, Peer-to-Pear and Data Warehouse will need to be included. More structural patterns such as Layered Architecture, Pipe and Filter and Event Driven Architecture will also need to be included.

A quick review of the literature has not turned up a very large number of architectural patterns, so this ontology is likely to be easy to implement and manage.

Products

We will also be looking at various existing products that can be used to implement the selected design. For example a message based design might select IBM's Websphere-MQ message queuing product.

Selecting a COTS product may have some side effects. In their book [WAL02] repeatedly stress that the examination of a COTS product may influence the requirements for the project. When users see what a product is capable of, they may want their system to also have that capability. This is to be expected. They also describe cases where the software exhibited behaviour that was not desired because the functionality was not correctly disabled, for example.

The options available will present different flexibility choices. A commercial product will constrain the remainder of the system to its interfaces. An open source product, if used unchanged would be the same, but there is the possibility of making modifications to it. The most flexible alternative is to build your own, but that flexibility comes at the cost of doing the development, and the corresponding time delay. A possible option is to start with COTS, then migrate to OSS or in-house developed at a later release of the system, once the initial time-to-market pressure has eased.

The number of products available is extremely large. While building an ontology of available products would be extremely valuable it will have to be placed beyond the scope of this project for now.


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

SASSY – Analysis, Part 4

Decomposition

One tactic that is common to any large project is to divide it into more manageable pieces. Malan and Bredemeyer describe how the complexity of a large project can be addressed by the architecture:

Intellectual Intractability

The complexity is inherent in the system being built, and may arise from broad scope or sheer size, novelty, dependencies, technologies employed, etc.

Software architecture should make the system more understandable and intellectually manageable—by providing abstractions that hide unnecessary detail, providing unifying and simplifying concepts, decomposing the system, etc.

Management Intractability

The complexity lies in the organization and processes employed in building the system, and may arise from the size of the project (number of people involved in all aspects of building the system), dependencies in the project, use of outsourcing, geographically distributed teams, etc.

Software architecture should make the development of the system easier to manage—by enhancing communication, providing better work partitioning with decreased and/or more manageable dependencies, etc.

My experience with very large projects leads me to the conclusion that the first partitions should be on political lines. This has the advantage that it also divides the stakeholders which can be a significant step towards getting a solution. All that has to happen is for the interfaces to be defined and each subproject can be worked upon independently.

This should be repeated recursively until tractable projects emerge.

A variation on the political division idea is to also include a “technical” partition in addition to the functional partitions. This is made responsible for the common aspects of the system. It can be an easy sell to the stakeholders as it reduces their individual costs, being a shared component. You can then move functions in or out of the technical sub-project as best suits the design. The stakeholders will then also gain an appreciation of the cost of having a special component, and may decide that the cheaper alternative is to modify the business process instead.

In their Attribute Driven Design technique Bass, Clements and Kazman describe the following steps for designing the architecture:

1. Choose the module to decompose. The module to start with is usually the whole system. All required inputs for this module should be available (constraints, functional requirements, quality requirements).
2. Refine the module according to these steps:
   
   1. Choose the architectural drivers from the set of concrete quality scenarios and functional requirements. This step determines what is important for this decomposition.
   2. Choose an architectural pattern that satisfies the architectural drivers. Create (or select) the patterns based on the tactics that can be used to achieve the drivers. Identify child modules required to implement the tactics.
   3. Instantiate modules and allocate functionality from the use cases and represent using multiple views.
   4. Define interfaces to the child modules. The decomposition provides modules and constraints on the types of module interactions. Document this information in the interface document for each module.
   5. Verify and refine use cases and quality scenarios and make them constraints for the child modules. This step verifies that nothing important was forgotten and prepares the child modules for further decomposition or implementation.
3. Repeat the steps above for every module that needs further decomposition.
   

An ontology with its subclassing capability seems like a good fit for decomposing a system into its component modules. If SASSY fulfils its requirements the step 2c above will be significantly automated since the point of the project is to generate the various views of the system.


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

SASSY – Analysis, Part 3

Requirements

The requirements for a system come in three categories: Functional, Environmental, and Quality.

The functional requirements describe what the system is required to do.

The environmental requirements are usually restrictions that the system must conform to, such as the operating system that must be used, or that the software will be for medical use.

The quality requirements describe those other aspects of the system, such as performance, safety, usability and maintainability.

Tactics

The components of a system have a set of responsibilities. Each component has assigned to it a set of things that it is responsible for.

For the functional requirements these normally map directly to a component’s responsibilities. That is, a particular component will be responsible for a particular system function.

For the quality requirements however there is no single component that is directly responsible. No component could be responsible entirely for the performance of the system. A tactic is what maps these requirements to a set of responsibilities which can then be assigned to components. For example a scalability requirement might be met by using a client-server design – the tactic. We can then map the consequential responsibilities to components; in this case by putting a service in one component and a client in another, and perhaps a name lookup service in a third.

Thus the design process is one of selecting a set of tactics that give the best response to each of the quality requirements. Of course there will be competition since using one tactic might compromise the use of another – it is hard to have a system that has both good security and good usability, for example.

In their introduction to tactics Bass, Clements and Kazman define a tactic as a design decision that influences the control of a quality attribute response. They also define an architectural strategy as the collection of tactics, and an architectural pattern as something which packages one or more tactics.

The software architecture ontology that will form the foundations for SASSY should include a collection of well known tactics and their relationships to the quality attributes.

Alternative Requirements

While considering some potentially very large systems it became apparent that sometimes the requirements were not always single valued. For example, building a system to support an entire organisation might have an environmental requirement that the solution must use Microsoft products where possible. However we can easily imagine a similar project that had a requirement for open source software where possible. The conceptual architecture for these two alternatives is likely to by almost identical, with the differences appearing in the logical and execution architectures.

Similarly the same project – a system to support an entire organisation – might be required to support a small office, a one-man company, or a large government department. When you look at the functionality, a lot of the requirements are identical but the quality requirement of scale has various alternatives. Again the conceptual design is likely to be quite consistent across all scales, but the logical and execution architectures will diverge.

It would seem then that the design of SASSY should include the capability of creating a suite of alternative designs based on these varying requirements.

It is somewhat amazing that we have gone from systems that are gigantic in scope to suites of such systems !


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

SASSY – Analysis Part 2

Quality Attributes

A fundamental driver to modern software architecture development are the quality attributes that the system is required to have. Factors such as performance, security, safety, usability and maintainability are often much more important in the design process than the functional requirements.

It is so important to have these quality requirements that we should provide some support in SASSY for their acquisition.

The core ontology for SASSY will be the software architecture knowledge base. An important part of that ontology will be a collection of quality attributes. The system should allow its user to assign an importance to each attribute for the specific project and thus include the quality requirements in the project's ontology.

Quality Frameworks

Several researchers in this field have developed classifications of the quality attributes according to how they see the relationships between them. One such classification has been promoted to being an ISO standard.

FURPS

A model developed by Hewlett-Packard that partitions the quality attributes into Functionality, Usability, Reliability, Performance, and Supportability.

Boehm

A model that partitions the quality attributes into Utility, Portability, and Maintainability. Utility is further divided into Reliability, Usability, and Efficiency.

McCall

Another model that partitions the quality attributes in a manner similar to the Boehm model, dividing them into operations, transitions, and revisions.

Dromey

This model partitions the quality attributes into Correctness (Functionality and Reliability), Internal (Maintainability and Performance), Context (Portability and Reusability) and Descriptive.

ISO-9126

This model partitions the quality attributes into Functionality, Reliability, Maintainability, Usability, Portability and Efficiency.

We should allow the user to select whichever classification they need, or use what might be called the Ontological classification of all known terms.

Quality Attribute Scenarios

It is all very well to specify that the system must achieve some quality requirement, but it is of no real use if there is no way to determine if the requirement is being met. In their book, Software Architecture in Practice, Bass, Clements and Kazman describe a set of Quality Attribute Scenarios that can be used to test the quality of a system.

Each scenario consists of six parts:

• The source of a stimulus which is some entity that generates a stimulating event.
• The stimulus which is some event that must be considered when it arrives at the system.
• The environment in which the stimulus is processed, such as a running instance of the system, or a system under some stress.
• The artefact that is stimulated, which may be the entire system or some part of it.
• The response that the system makes after the arrival of the stimulus; and
• Some measurement that can determine how the system responded.

While some these are quite obvious, such as how long the system takes to respond to an incoming event, others are a bit more problematic. For example it is quite reasonable to have a quality requirement that states that the system must be easy to maintain. However, the system itself is unlikely to include facilities for self modification. This sort of requirement forces us to expand the scope of what we mean by “the system” to include not only a set of running executables, but also the infrastructure required to maintain it – the maintenance team becomes part of the system.

SASSY will need to include the ability to set up these scenarios for all the important quality requirements.


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

SASSY – Analysis, Part 1

If we are going to build a system for doing software architecture we had better get a very good grip on what a software architecture actually is.

Scope

Garlan and Shaw describe software architecture as the design problems that go beyond the selection of algorithms and data structures:

“Structural issues include gross organization and global control
structure; protocols for communication, synchronization, and data
access; assignment of functionality to design elements; physical
distribution; composition of design elements; scaling and
performance; and selection among design alternatives.”

A common theme in the discussion of the nature of software architecture is that it covers those design issues that encompass more than one component module of the system.

Malan and Bredemeyer describe the central concerns of a software architect as being the setting of system wide priorities; system decomposition and composition; system wide properties, especially those that cut across multiple components; how well the system fits its context; and the overall integrity of the system.

Structure

Malan and Bredemeyer describe an architectural framework as having three main layers:

• A meta-architecture with a focus on the high level decisions that will strongly influence the structure of the system, rule certain structural choices out, and guide selection decisions and tradeoffs among others.
• An architecture with a focus on decomposition and allocation of responsibilities, interface design and assignment to processes and threads; and
• A set of guidelines and policies which guide the engineers creating designs that maintain the integrity of the system.

The architecture layer is further divided into three sub-layers:

• A conceptual architecture with a focus on identification of components and allocation of responsibilities to components;
• A logical architecture with a focus on design of component interactions, connection mechanisms and protocols, interface design and specification, and providing contextual information for component users; and
• An execution architecture with a focus on the assignment of the runtime component instances to processes, threads and address spaces; how they communicate and coordinate and how physical resources are allocated to them.

Process

At its core the software architecture process entails taking the requirements and preliminary analysis and developing a set of documents and diagrams describing the system to be constructed.

The functional requirements, and perhaps more importantly the quality requirements are first examined in order to develop a set of tactics that will best satisfy those requirements. The software architecture discipline has a large body of well known tactics that can be combined to produce the approach for the specific problem.

The tactics are then used select appropriate COTS products and to develop a set of design patterns.

The project is divided into sub-projects which can each be separately developed. This is important for large projects, since very few large projects ever complete successfully it is necessary to subdivide them into manageable chunks to a size where the success rate is more satisfactory.

The overall design is then subjected to an analysis to determine if it is a viable solution.

The interfaces between these components is then fully documented so that each sub-project can get under-way as soon as possible.

A set of scenarios are developed that will form the basis of the test cases for the system. These tests are designed to ensure that not only are the functional requirements met, but also the quality requirements.


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

The SASSY Project - Introduction

The Super Sized Software page introduced the idea of the very large project. At
the end I lamented the lack of any decent support for building really large
systems. The Software Architecture Support System (or SASSY) is a project I have
undertaken to try and address this problem.

The basic idea is to build a knowledge database containing all the information
concerned with the architecture of the system. By having a single repository
we avoid the issues of having things get out of synch. We can then generate
all the architectural documentation from that repository.

My plan is to do the initial development as a personal project, and if it starts
to look promising, migrate it to Source Forge and open it up for others to assist.
Such projects will only take off if there is something solid to start
with - hence the initial private project.

While SASSY is not likely to become a hugely complex project, I though that it
might be interesting to use itself as its first project. This way I only have
to design the architecture for one system, not two.

The Vision Statement

The goal is to produce a software system that assists with the task of creating
an architecture for a software system.

The current process involves writing text documents, typically using a word
processor, and trying to embed into them a set of diagrams that describe the
proposed design at a high level. The results are generally not very satisfactory
for a variety of reasons.

Creating diagrams for inclusion into word processing documents is not easy.
Some word processors are quite poor at handling diagrams. There are serious
limits to the complexity that can be described in such a diagram. For a complex
system the diagram will either be too cluttered to be readable or such a high
level view that it is essentially meaningless.

Creating diagrams is often manually intensive. Even with diagramming editors
that have the appropriate symbols and an understanding of what the symbols
represent it is still necessary to place the symbols and label them. This
takes a considerable amount of tedious effort. The result is that diagrams can
quickly become out of date as the design evolves but there is not time to
revisit the diagrams. There is also a tendency to combine several aspects of
the design into the one diagram. This can make the diagrams confusing and
ambiguous.

The use of word processing documents to describe the system also has its
problems. When writing a document it is usual to target a specific audience
- perhaps the developers, perhaps the stakeholders, for example. It is very
difficult to write a single document for the use of a variety of audiences.
It will have too much detail that is not relevant for most of its readers,
and conversely each reader will have difficulty finding the information that
they need.

The rather obvious answer is to create numerous documents and diagrams each
tailored to a specific aspect of the design. However this brings with it
another problem, namely, how to keep a large collection of objects consistent
while the design goes through its inevitable evolution?

The current process for developing a software architecture does not scale very
well. For very large projects it becomes necessary to use a significant number
of 3rd party products (unless you have an extraordinarily large budget). This
range of products can easily exceed the knowledge of any single architect.
Moving to a team of architects presents its own problems since the
project will no longer have a single visionary to guide it.

The objective of this project is solve these problems. The approach is to
capture the design, the software architecture, in an ontology or knowledge
database. Being in a single repository it can be kept consistent, and in fact
the tools available for checking ontologies can be used to identify any
inconsistencies. We will then develop a set of tools that can generate the
documentation and diagrams for each aspect or view that is required. A single
repository, with multi-user access, can allow multiple architects to
collaborate on the design process by enabling each one to easily see the
information that is relevant to the part of the project that they are working on.

Software will then extract the data from the knowledge base and feed them
into programs that will generate the text and diagrams. A user interface
component will coordinate the process. The output format should be PDF so
that there is less temptation to edit the output documents rather than the
source knowledge base.

Next time we will look at the preliminary analysis for the SASSY project.


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