Our software systems are like our cities. We have a few design masterpieces surrounded by suburbia and slum. As a software architect, your responsibility is to remove the suburbia and slum and create new masterpieces.

Be original. Be creative. Be demanding. We are not an eternity of echoes, patiently awaiting the dawn of indifference. We want to create excellence, and we must both demand and earn[1] the freedom to be able to do so.

Freedom in this case is not about personal liberty, but about freedom from assumed directions and structures. As Brooks[2] states, when discussing the role of the organisation chart in software projects:

This [the organisation chart] becomes intertwined with the interface specification. As Conway’s law predicts: ‘Organisations which design systems are constrained to produce systems which are copies of the communication structure of these organisations.’ Conway goes on to point out that the organisation chart will initially reflect the first system design, which is almost surely not the right one. If system design is to be free to change, the organisation must be prepared to change.

If a business leader defines your software, he or she is in all likelihood defining the wrong software. You must work your way into their trust, then use that trust to communicate a better software and business vision.

To clarify the design process, we shall look at three separate projects and select moments of interest in each.

All of these are fairly large projects. Some believe the role of software architect exists only on such large projects as there is little architectural work to do on smaller projects. This belief means software architecture exists within a larger idea of software creation. An alternative view is that software architecture is the creational model, and everything exists within it. Therefore, a software architect defines the architecture of both large and small projects. It is only the level of abstraction, or detail, which changes.

The project approach proposed in chapter 6, of framework and toolset, will only ever exist in architecturally led development. In business led development, it becomes ever more difficult to achieve. There is little visible output when developing these items, and business focused project managers have nothing visible to sell as progress. If you are working in this environment, the toolset and framework are best developed as part of each subproject. Do so while selling the benefits of architecturally led development to the business.

Steve McConnel[3], states the aims of design:

• Minimal defects
• High correctedness
• Maximum user satisfaction
• Minimal response time
• Good maintainability
• Good extensibility
• High robustness

Upon these, he builds project objectives:

• Short schedule
• Predictable delivery date
• Low cost
• Small team size
• Flexibility to make mid-project feature-set changes

Upon these, I would add, once more:

• Clarity – the message is obvious: biggest = most important, no clutter
• Harmony – No sudden changes
• Balance – A careful weighing of issues
• Simplicity – Easy on the eye
• Refinement - Unambiguous
• Restraint – No announcement trumpets, no painful colour clashes
• Unity – Each part is clearly related, each action produces an expected outcome
• Modularity – Each decision, each information point is separate
• Sophistication – You understand and are helping
• Elegance – Simple flow
• Economy – Least is most
• Beauty - Always forgotten, but never unnoticed

A stationer has agreed to investigations into replacing their aging and difficult to maintain system. The job is out to tender, and three software suppliers have been invited in to estimate the complexity and cost of replacement.

For those unfamiliar with a Stationer’s business, here is a quick overview.

Our Stationer is a business supplying other businesses with everything from paper clips to photocopiers. It also has a high street shop. Sales terminals in the shop are referred to as Point of Sale (PoS) terminals. The shop and the business customers are supplied from the stationer's own warehouse. Selling stationery is also known as office supplies.

The warehouse is managed by keeping stocked items at a stock location, and recorded against each item is a stock level (count of the number of items), a reorder level and a reorder quantity. When the stock level gets down to the reorder level, an order is made to replenish that item. The amount of items ordered is the reorder quantity. The word reorder is used as if someone has ordered it, and in turn, it is being reordered from the supplier.

The stationer orders its stocked items from wholesalers or manufacturers, and stocks a few thousand items. Stocked items are also referred to as stock lines. Their full catalogue of supplies contains twenty thousand items, and those not held in stock are called non-stocked items.

A discussion about the business reveals the following information:

Figure 7.1 Stationer’s system use cases

The use case diagram shows sales and purchase order processing, account management, stock control, accounting, reporting and sales analysis. Purchase order processing is always done as part of the stock control activity. Reporting is either a separate use case for management, or an extension of the other use cases. A system administrator has a system administration and upgrade management use case. Customers and suppliers have accounts with the stationer.

This represents the core of the business. The stationer also has its own printing facilities where they produce letter-headed paper, compliments slips, printed envelopes and business cards. The print business is managed on a separate system designed specifically for the effective management of printing. Running the presses efficiently (or constantly) is core to profitability for the print business. The print system provides daily updates into the core system for accounting purposes.

The stationer uses a number of different pricing techniques depending on the size and complexity of each customer, and on the generosity the customer extracted from the salesperson when agreeing fixed prices. Fixed prices are reviewed every six months, and allow the customer to predict how much will be spent on stationery with a usage model and non-varying prices.

At this point in the design you may have begun to see the enormity of the task ahead, and use the information gained so far to identify a set of likely subprojects. Pricing is obviously a keen issue, where business rules must be applied differently for each customer. There are core system actions such as recalling, editing, saving and analysing data. There are links to external systems. Add to that all of the normal sales order processing and accounting functions, and it is quite clear this is a large project.

The design must also allow for nationwide deployment as the stationer is intending to expand by opening shops in all major cities. They may also be buying up smaller companies and expediently merging their customers and management information so they become one seamless entity. They would also like the system to allow for  expansion internationally as they have been in talks with similar companies in other nations with a view to consolidating. Providing software with these capabilities will be a big win.

A straw man is a loosely stated first stab at creating a solution. It is used as an opening bid, which can be refined, redefined or shot down in flames of withering despair. It is also a psychological tool, for he who states his straw man first and loudest most often gets to lay the foundations of the design. Once the straw man is made, he is easier to drive home than burn. And if the flames do come, step back, and say: 'It was just a straw man.'

You gather straw: The system will be distributed. Order processing and stock control information will be stored in one or more locations with regular data consolidation to a single central point. A layered set of objects will be provided to extract, convert and deliver information. Browser access will be provided to all major parts of the system to allow expansion to take place without large installs on different platforms, but there will also be a set of fast, efficient, compiled applications so those who process information all day can do so most effectively. Analysis of the business data will be through reports viewed in a browser, and also in highly interactive compiled applications where required.

The throughput of the system is moderately high, without taxing the transaction throughput of any commercial database. A few thousand orders are placed each day from the business customers, and the shop handles around 500 callers. The shop’s customers are fairly evenly spread throughout the day, but the business customers place most of their orders between 10am and 11am, and again between 3pm and 4pm. These times of higher throughput are known as the morning and afternoon rushes.

The most obvious item in the business at this point is a sales order. It is composed of an order header, a body and a pricing summary.

The header contains the customer’s account code, their business name, the date the order was raised, the name of the person who placed the order, its intended recipient, and also the delivery and invoice addresses.

The body of the order is a collection of one or more order lines, where each order line contains a line number, a product code, the product’s description, the quantity ordered, the quantity available for delivery, the unit price for a single item, the discount they got, and the line value, or quantity multiplied by unit price.

The order summary contains the current state of the order. During its rather short lifetime, its state progresses through order being taken, order being picked, order being delivered, and order delivered. It also contains the number of the invoice which the order relates to. You ask for an example, and they manage to find an old one lying around containing no sensitive information.

Figure 7.3 Order classes

Certain nuggets of detail gained during discussion lead to the class model of figure 7.3. For example, reuse of product codes from one catalogue to the next was discovered, meaning product codes are not unique. Therefore the product description must also be stored, despite this apparent inefficiency. Other solutions, such as storing product codes against their descriptions with valid from and valid to dates may require less storage, but they are likely to add complexity.

The orders require storage in a database. One practice to be aware of is that object oriented software should be designed objects out. Many client server systems were designed data up. Data up may have produced decent results in a procedural language, but will not lead to an efficient set of objects. Procedural languages and their associated systems are on the wane. They are most likely to continue to be so.

If you disagree, I would like you to do something:

Imagine your favourite cup

Are you doing so? Can you see an object floating around in your mind’s eye? You have a vision of a cup. You can see it. You can imagine it has texture, the friction of its surface, how it burns your hand when the drink inside is too hot. How light reflects off it, how heavy it is, whether it sits on a saucer, the rings of stain it leaves behind on your desk...

First you saw the object, then you added data and interactions to it. You did not imagine height, width, depth and thickness. Think on that a while.

Divide the real-life object (in this case a sales order) into parts. Make each part a class, then add attributes and operations. Finally, add data types and persist it to a database. Don’t begin with data and try to create an object from it.

The layers a sales order might flow through in a layered system are displayed in figure 7.4. A salesperson requests an empty order from the user interface. This request reaches the business rules, which in turn requests this information from the database. Upon true returning from the data, the business rule says OK. The object is created, then adorned with the user’s preferences and sent to the UI.

Figure 7.4 A sales order through the layers

As a scenario, imagine a salesperson arriving at work. She logs on to her machine and fires up her business software. During startup, the salesperson is identified with a number of roles, and one or more of these roles is able to place an order. The order entry option is added to the list of actions she may perform, and she is presented with a menu of items in the software's default startup view.

She selects the order processing screen and it is presented with her preferences already set. The telephone rings. Client y wants to place an order. She selects the client, and down through the layers goes a request: can salesperson x create an order for client y? If she cannot, she will get a message back saying so, with an action provided by the business rules: please direct this call to Mary or Steve. If the customer has reached their credit limit she will get a message saying so. If all conditions are met to be able to place an order for them, she will get an order screen, set up and completed to her own preferences and overlaid with the customer’s preferences and details.

When writing design scenarios (or requirement scenarios) always use the present tense and avoid conditional words like could, should or might.

A framework and toolset were presented in chapter 6, and now layers have been introduced. Both concepts are shown together in Figure 7.5

Figure 7.5 Application using a framework and toolset

The framework (itself consisting of layers) and toolset, are used by all of the applications in the system. In some cases, the toolset converses directly with the operating system, and in others employs the functionality offered by the framework. As a reminder, the framework is deployed sparingly, often across many servers, whereas the toolset is deployed on every client and server.

In reality, another set of layers will reside between your framework/toolset and the operating system. This is the runtime library you have developed for, such as the .net framework, CICS, MFC or the J2EE runtime etc.

We shall begin our design with a typical layered business system. If our stationery software system requires more or less layers than considered for figure 7.4, we shall discover this during design. At this stage, the class diagram is a mere sketch, which cannot be properly detailed without a discussion of design patterns in chapter 15.

Figure 7.6 Layered design showing object relationships

In actuality, all of our objects are dependent upon the runtime library from our development environment. They may also communicate directly with the operating system, which is not shown both for clarity and in the hope that direct calls will not be required. Each layer of the framework also has access to, or can be accessed by, the toolset. The layered framework is composed of the four objects Business syntax & context to Data translation. Data access, in this case, is a predefined library such as JDBC, ODBC or OLEDB.

Direct communication with the operating system is being strongly discouraged as development tools become more effective in delivering our needs without such a measure. This leads to better encapsulation, higher robustness and easier debugging. It is with the Java runtime or the .Net framework layers we converse with.

The benefits of layered design are fourfold:

1. To be able to change an item in any layer, such as a business rule or data access technology with the least change to any other part of the system.
2. To simplify the code at each place of deployment
3. To support different deployment models and server configurations. If the business rules and business syntax & context functions sit on a server local to the users, and caches local customer data, it will deliver a better perceived performance to the users. Also if a server supporting the entire set of layers becomes overburdened, perhaps the business rules service can be deployed to its own server. 
4. To support multiple objects performing the same task in any layer. This may mean supporting two user interfaces, browser and compiled application or to switch in replacement or alternative components while the previous one continues to serve.

Business objects such as an order are created and completed in different layers. When traversing across layers, particularly if those layers reside on different physical servers, the objects are decomposed, or serialised into streams of data, and rebuilt in the receiving layer. This kind of design is growing due to higher available bandwidth and technologies providing serialization and transportation. In many cases, the layers become generic data extractors, gatherers, and filters for presentation and manipulation of these objects.

A service oriented architecture is a loosely coupled collection of functions providing vital operations and knowledge to applications or their users.

Benefits

• Single point of deployment and reference

• Simplified mechanism (e.g. web services) for calling across non-heterogeneous systems (e.g. Windows to CICS).

• A method for switching in and out services as required, possibly providing some fault tolerance, load balancing and higher upgradeability

• A method for separating or consolidating services across servers without discomfort

Drawbacks

• More work required in design to define message structure and technologies

• Management of message routing error handling is required

• Possible slower function calls

• Careful management of asynchronous calls required

The majority of service oriented architectures use web technologies because of the pervasiveness of the internet. The opportunities afforded by web based services allow information to be delivered globally from a single point of reference. Thus, information need not be replicated, nor out of date. Http provides the transport over TCP/IP. SOAP, XML and DTDs provide the messaging formats, controls and data, and web servers provide the interfaces between servers and operating systems.

The language of user interfaces has gone through a few iterations. When we moved away from text based interfaces we were left staring at WIMPs. Wimps became clients, which in turn became thick clients when browsers, namely thin clients, came along. With the advent of thin client, thick client was perceived as no longer suitable, but thick clients are making a comeback, renamed as smart clients.

To add to the confusion, the browser manufacturers have long been trying to deliver thick client functionality in their thin clients, and development tool (thick client) suppliers have equally been at pains to remove the deployment burden of thick clients. In the intervening space it has been equally difficult to deliver browser upgrades as thick client installs.

The solution to both problems comes from neither, but from faster and easier internet access.

To compare client server, SOA, desktop and thin client business applications is a simple task, but creates many difficult ramifications for the architect to resolve when designing a new system.

Thin clients can have a huge benefit when absorbing other companies. Getting them on your business software is as easy as installing a VPN (Virtual Private Network) and pointing them at an http address. So goes the theory. The actuality is that all businesses are different. They have different leaders, who have different ideas, and they operate quite differently. All are sold on their existing business model and will argue quite convincingly that they cannot stop operating the way they do without losing business.

All of their ways of doing business must be added to your software. Business leaders have no dilemma at all when answering the question: ‘Do we upset all of the people in the company we’ve just bought, or do we upset our IT department?’ Then they start using slogans from the great wars, words like together and team, and start dribbling Churchill quotes.

The depth of client offers no real solution to functionality nor deployment, but in certain circumstances, one or the other may provide a better option.

The use case model defined a rather coarse grained system. Each of the use cases identified can be further analysed and detailed as use case pathways in activity diagrams.

Figure 7.7 shows order processing broken down into high level tasks. Common functions of product and account lookup have been separated into a separate swim lane, indicating functionality which will be contained within a framework or toolset rather than in each individual application requiring them. This will ease the complexity of the sales ordering application and also provide a method for sharing and changing product and customer lookup without redeployment to the clients.

 

Figure 7.7 Sales order high level activities

In addition to the account and product lookups, it is highly likely that all lookup, selection and deletion of the major business objects (customer, employee, product, order etc) are candidates for the shared client or server based functions. Mathematical functions like calculateCustomerDiscount(Customer), getProductPrice(Product, Customer) and drawing functions, stylesheets and javascript libraries are equally likely bound for the framework or toolset.

Without trying too hard, we have the structure of a layered framework on which our individual applications sit, a set of subprojects we will be able to divide among our development teams (one project team per use case). We have the beginnings of a framework including product and account lookups. It is starting to take shape.

Suppose we get to this point after a few weeks of analysis. We have the major use cases, a layered definition of our intentions of how the system will hang together, and we also have a list of applications which will sit on these layers. The sponsor then comes with a request:

We have had some rather severe fluctuations in the price of paperclips this year. The paperclips are made of a type of plastic refined from oil, and as you know, oil prices are up and down. We have been keeping our customers free of fluctuating prices, but the situation is such that paperclips are now ridiculously overpriced as the price of oil has fallen so far. We want to be able to manage our systems based on the true cost, but we want our salespeople to see a distorted cost based on the sales price we have set. We expect oil and paperclip prices will soon increase quite significantly, so passing on the cheap prices now would mean making huge increases later. Such huge increases in the past have led to bad feelings between our customers and salespeople and we have lost accounts. So can you ensure the software will allow us to do this.

In our design so far, it is not likely to make much difference. Had we completed building the application as a typical bunch of applications, then each place where each application read and displayed the cost price would require reworking. We merely note it for later when we are building the component which handles pricing.

This also indicates that our application, initially intended to be client-server, should additionally make use of a number of services. So our architecture is mostly client-server with a bit of SOA mixed in.

To provide a useful environment for the subprojects to be developed and added to easily, as much of their work as possible should be built into the framework. To decide what goes in the framework, and what stays out, each item in the framework should provide services to more than one subproject. If only one subproject is served and it is unlikely that the service will be required for expansion, then it belongs in the subproject.

Tools such as math libraries and common lookups belong in the toolset, whereas business decision and operation belongs in the framework.

Let’s take a look at worldwide set of servers.

Figure 7.8 Worldwide deployment

A system designed this way will scale geographically and in number of users far easier than a non-layered approach. Perhaps we will one day expand to two US business servers for every data server. As you can see, the layered approach is highly configurable.

We decide that all applications will be available from a browser to facilitate rapid deployment. We also need to provide a shell for compiled applications. The shell will provide each component with a basic set of functionality and cached data, such as who the operator is, where components can be found, and where data is stored. Those functions requiring complex compiled user interfaces will then have a set of shared methods.

To begin, we shall take a high level view of the collaborations of the main objects in the stationer’s business.

 

Figure 7.8 High level collaborations between principal players

Roles, Goals and Business Objects

The principal roles of the stationer are SalesPerson, Buyer, Supplier, Customer, Picker, Carrier, PaymentsReceived and PaymentsMade. Three of these roles, Carrier, Supplier and Customer are external to the stationer. The PaymentsReceived and PaymentsMade roles are both accounting roles, and the other roles of SalesPerson and Buyer, sell and buy stock. We will define each of these roles as a business object, and give each role a collection of one or more goals.

For more on accounting terms, see[4]

Some time must be spent early in design defining all business roles and the business objects they interact with. Following that, create the use case pathways, and identify which roles drive each activity.

As an example, consider the create new sales order use case.

Figure 7.9 Create new Sales order

Each use case is detailed as a set of activity diagrams. Each business component is defined using CRC cards, XML schemas etc, including key and base data and optional sets of collections. For example, in the customer object, you may have a container to collect all of their orders. For a salesperson you may have a (usually empty) collection for their customers.

XML and collections save a lot of headaches when building hierarchies of objects. Consider, for example, a SalesPerson object containing her customers, each having a number of orders.

<SalesPerson name="A Aspinall">
    <Customers>
        <Customer ID="000014" Name="Goodies Repeats Inc">
            <Orders>
                <Order ID="0216450">
                    <Customer ID="000014>
                    <SalesPerson Name=...

In a pure business object world, the Order would contain either a data item for SalesPerson, or the business object of SalesPerson. In this case, containing the business object would create a never ending hierarchy as the SalesPerson within the order would contain Customers, and customers would have orders, over and over again. XML makes this problem much easier to avoid, but consider the following two situations:

Situation 1: Business object Order contains business object SalesPerson
Situation 2: Business object SalesPerson contains business object Order

To avoid having a great number of SalesPerson objects, such as SalesPersonFull, SalesPersonNameAndAddressOnly, SalesPersonSummary, choose instead to populate one single business object of SalesPerson with a number of different sets of data. Consider each one a view. When populating SalesPerson within an Order, do not fill the Orders collection or container.

The framework manages the translation between the database and user, and back again to the database, controlling lookups, creations, deletions and changes. Any access to the operating or file system is also handled by classes within the framework or toolset.

An example in chapter 1 builds on the activity diagram to show the state changes of a sales order. By defining the state changes, they can be coded in a controller class. The activities themselves can also be written (as code) in sequence, reflecting the activity diagram.

To continue this design activity would further detail activities and states for all of the applications and business objects, and clarify the layers in terms of how they operate on a business object. Finally in the design, we need to create and test the various layers so that the objects and management of those objects can be fitted together on predefined layers in their most efficient configuration.

When writing code, the activity diagrams are translated into controller classes and object classes. The user interfaces are designed to lead people through the activities just as they detailed them when describing their business function.

To get a better idea of how to get from idea to design to code, try Visual Basic and UML [5] or UML Components [6]

To keep all of the data definitions tidy, and free from attachment to any object or document, it is good practice is to create a data dictionary.

Data dictionary and terms for stationer

Once again, the key to large project success is division into small labours, and the extraction from the main functions (use cases) of a framework and a toolset. The framework will contain the major functionality of the system and abstracts away data, operating system and storage. If the framework is defined as a set of layered components which can be developed as part of the subprojects rather than as a separate project, some resource allocation problems may be avoided, but careful inter-team communication is required to ensure interfaces suitable for all. Also, the tools used in the project such as common lookup and selection dialogs, common methods and common script and style components, should also be wrapped up as part of the subprojects where possible. Doing so will modularise your development effort into a set of discrete projects.

We will leave the stationer’s system at this point, as to discuss it further would not benefit our architectural journey. There are plenty of books on object oriented design, and vast areas of publication dedicated to layers, components and business systems in general.

We can compare large software projects to many other large projects such as buildings, vehicles, infrastructures for transport or delivery of utilities such as water or gas. They can also be compared to almost any consumer product such as cameras, computers, music centres and televisions. All of these are based on components. They have principles of science, engineering and aesthetics which must be understood and addressed to make the product successful. We shall briefly compare software systems to cars.

Cars are built of large (chassis, body, engine) and increasingly small, collaborating components. They are designed by dividing up the car into smaller systems and allowing specialist teams to work on their own subsystems. The leaders of the smaller teams will work together, and with senior people who are responsible for the whole vehicle, to ensure the parts work together and fit together.

All of the bits of a car are held together by the chassis. The body sits on it, the engine is contained within it and the wheels hold it up off the road. The design of the engine requires all of its sub components to fit within its space, and that they act as a crumple zone, slowing the car during a crash and absorbing as much of the impact as possible to protect the passengers.

Car designers approach a new design in the following ways:

• Sketches are made to get an idea of the shape of the car
• A full size or scaled clay model is built to show exactly what the car will look like
• Computer aided design (CAD) is used to specify the dimensions and location of component parts
• CAD is also used for strength, noise and vibration analysis
• More computer and physical models are used for airflow around the body and also for the airflow within the engine
• Prototypes are built, often using computer aided manufacturing for 3D parts such as deposition 3D modellers or CNC machinery.
• Wind tunnels allow the designers to observe the airflow around, under and through their vehicle, and allow them to tweak the design to make the body shape more aerodynamic.

The car is ultimately a collection of smaller components. They either pre-exist, are bought in, or are built in house.

Software is ultimately a collection of smaller components. They either pre-exist (databases, user interface controls, components built for other systems), are bought in (user interface controls, widgets) or are built in house (everything else).

 

Figure 7.10 A car made up of components

This brief list of components grows as more knowledge is gained of the car. Every time the diagram is revisited, more information and more detail is added, possibly continuing right through the design process, and possible into production. This should not be seen as a problem. Design is an iterative process, i.e. it is revisited repeatedly as more is discovered.

It is likely that each component will need to be further detailed in a separate diagram:

Figure 7.11 A carburettor with interfaces and subcomponents

At class level, the carburettor might look like this:

Figure 7.12 Carburettor classes

A car is an excellent example of an object based system. It's chassis is a kind of framework. On the chassis sits an engine, which has interfaces with other parts of the car, like the accelerator and gearbox. Each of these objects is a whole system in itself, joined using components such as wires, connecting rods, a clutch, an axle etc.

Each component is itself composed of ever decreasing components. For example, a car has an engine, an engine has a carburettor, a carburettor has a float, the float has a hinge. Some of these items are externally supplied and others are created internally for one or more different components or cars. Careful trade-off between buying and creating, and even the method of creating can create a more economical product.

Many attempts have been made in software development to allow us to buy in components, but it has stalled at the carburettor level. If we could get down to the washer level, creating software might become a less time consuming and less problematic affair.

The code equivalent of a washer is:

Open database
Open recordset
Locate first record
Read record
Is this the last one?
No - move to next record
Yes - jump to Close records
Loop back to Read Record
Close records
Close database

A washer:

Material: steel manganese (10%) alloy, hardened martinite
Thickness: 0.5mm
Outer diameter: 12mm
Inner diameter: 5mm
Metric size: 5M
Shape: flat

Rarely do we pick up and place the equivalent of a washer. We get the metal, cut it, drill it and harden it. Only a fool would do that for a car. Perhaps one day we will be able to click on an activity in an activity diagram, and select the equivalent of a washer to provide a partially finished code template.

Let’s compare a car and its environment to a software system. The match is not perfect, yet there are many parallels.

At the design level, they are not too different. They look equally complicated, and after release they both have their problems. Cars are recalled for faulty tires, fuel injectors etc, and software soon has its service packs and quick fixes. Cars can crash, come off the road, be driven by fools. Cars can kill people, as can software.

If you are designing software to monitor hospital patients, or for air traffic control, your design must have safety redundancy built in. You will also be involved in the design of the hardware so that when failure occurs, emergency routines can kick in or raise an emergency warning effectively.

Design requires different disciplines for different arenas. You must become familiar with your arena. How would you feel if your heart monitor stopped working because the software developer couldn’t be bothered or some fool project manager said I need it by Friday without considering the consequence to you, dead because no software architect had the strength to raise his voice, nor the skill to persuade others away from their course of action?

We can learn a lot about design by looking at everyday products. We can learn by studying them, by dismantling them and seeing how the pieces fit and work together. The Design of Everyday Things[7] is a good place to start.

Let's take a look at designing a software system for a human-like robot, named Robbie.

Robbie has senses, but not feelings. It is a genderless robot, but male in appearance. He has a means of motivation, called muscles, and a way to know what load is on those muscles, using nerves. Unlike us, his day is filled with clear, unchanging objectives. He cannot manage complex commands, and instead manages by breaking down each command into a series of tasks, then working with the person commanding to agree the individual tasks which might collectively meet the command.

Figure 7.13 Robbie the robot’s high level classes

Robbie is not perfect. He’s a little like you and I. He has his flaws, but he is doing his best to overcome them. Unlike He who made us, Robbie has been designed by a less than perfect creator, and so he has that floating dictionary class shared between hearing and sight. If there is a fault there, he will be immediately unable to speak, to understand speech, and to read.

That movement controller looks a little overloaded also. It has too many links into some packages. For example, there are three separate links with the nervous system. That’s not too good. I’m sure you would make a better job of it, yet this is my best solution acting as software architect. I know another software architect who put in a superior design, but I was the best salesman. He was a bit tongue tied and shy. Served him right. What’s the point of being an excellent technician if you aren’t prepared to work on your presentation? Harsh, I know, and as true as the fact that there is water at the bottom of the Atlantic.

At this point we should define the underlying structure upon which our robot software will be built, and define the interactions between the packages. If we succeed at this, then the individual packages may be worked on as separate projects. Smaller pieces of work mean a project is more likely to succeed.

Robbie would benefit from a few things. First, we want him to be excruciatingly polite. Should we find ourselves in an awkward position involving him, he should melt into the background. The root of all of his decisions will therefore be based on ethics. He will have a timer for scheduling tasks and generally keeping him going. In biological or neurological terms, this will be his endogenous circadian pacemaker. I may use that as a class name. Somehow he must be able to prioritise over conflicting schedules, should his pacemaker demand two things at once.

To solve his daily dilemmas, he shall have a project management module. This will manage initiating, planning, executing, controlling and closing of his daily tasks. Each decision will be based on scope management, time management, cost management, quality management, communications management, risk management and procurement management

It will also manage action decisions based on all of the above. Robbie is a whole project manager in himself, excluding human resource and integration management. There is none of the latter to do, and we wouldn’t want him bossing us around. We already have enough people doing that.

Figure 7.14 Robbie's internal use case diagram

 

Figure 7.15 Robbie’s external use case diagram

Of course, Robbie will also have his real user type use cases, depending on the levels of excitement he has been programmed to perform. He may wash up, tidy up, pick up the kids from school, or hurl himself in front of an oncoming vehicle to save a small dog. He’s quite complicated enough for us to abstract away these real use cases in the sure knowledge that if we build him right, then he will be able to perform many tasks. If we don’t, there is little point expecting him to perform anything. Instead, he will sit in the corner of a room twitching uncontrollably. This is a big success or big failure project. It is extremely high risk as everything we are trying to do has not yet been done, despite our clever toys and Honda’s success in teaching their robot to dance.

Software architecture is all about maximising the amount of work not done. The point of a common toolset is to avoid writing everything twice. The point of a framework is to provide applications with most of their functionality. Additional applications are created more easily, and require less work. It is also about reworking or pushing back costly requirements, so developers do not spend half of their time on a project meeting an asinine requirement added without the appreciation of its cost or complexity.

Design is creativity. We have certain tools at our disposal, such as patterns and a software process slowly leading in to design to help us, but it is the creative aspects that will most affect the result. Good creativity can maximise the amount of work not done. It can make coding easier. It can make code small, tight, integrated and reusable. Bad design can contribute to never ending projects and poor quality code from apathetic, confused developers.

Hopefully, Robbie will be neither confused nor apathetic, as we have built our design based (rather sketchily) on ourselves.

Robbie will have an operating system, a framework for coordinating and controlling his movement, and a number of applications for which he can be used (vacuuming, washing…) He will also be layered in that his action decision will sit atop self preservation, which in turn sits above ethics, his action controller and his operating system.

 

Figure 7.16 Robbie’s layers

We shall also include a short cut, but this will be used only for the blinking of an eye or dodging of a head when projectiles are incoming.

We might manage a little better if we have a link between memory and avoidance - that fine line in our hippocampus where we make a sudden movement and then recoil. Something like here’s an incoming object, I’d better blink, or last time I was whooshing out of the way of this car, I went down an enormous ditch. Robbie will blink, but is likely to go down the ditch twice. That is good enough; Robbie is a robot. Although he is rather expensive, he is also non-unique, and therefore replaceable.

In the layer diagram, it is difficult to link memory to avoidance while it is also linked to ethics and self preservation. Instead, despite the increased area, a package diagram will aid accuracy.

 

Figure 7.17 Robbie’s layers as packages

Showing the layers as packages makes it a little clearer as I can show all relationships. It also gets away from having to draw small things in crannies on the layers. Anyone looking at a layer diagram sees that things have relative sizes. Smaller means less code, less important. Drawing all of the layers and objects the same size implies little.

Before we develop our software vision any further, we shall take a look at the pieces of carbon fibre, steel, slips of oil and kevlar which together will fashion Robbie’s skeleton.

Figure 7.18 Robbie’s arm showing it’s degrees of freedom and his hand’s pressure sensors

Altogether there are six degrees of freedom in our current understanding of spacetime. I do not consider time a degree of freedom, as we are trapped forever in the now. Therefore, we have translation (movement) in the x, y and z planes (directions), and rotation around the x, y and z axes. Thus, the complete degrees of freedom of a joint can be written in terms of x y z θx θy θz. 100100, for example, allows movement in the x direction and around the x axis. Its a bit like a ring on a finger. You can rotate it around your finger, and move it along your finger to take it off or put it on, but it won't shift any other way. The limit of movement can also be listed this way: 70 0 0 360 0 0 allows 70mm of movement along your finger, and 360 degrees of freedom around your finger.

Robbie’s main purpose in his unwaking dream of electric sheep, is to keep the place clean and tidy. He will be programmed with chore motivation and little else. We must take care programming his visual imaging system as he may start seeing things when the light levels are low.

If you are driven, at this point, to begin questioning whether my design is right or not, you may as well ask if the design of a particular tree is correct. All trees work as trees. Some can survive in particular places, some have a more satisfying shape. They are all correct. Similarly my design is correct. I could argue with you over its perfection, but it will still work. Making it happen will only prove my correctness. If I can finish version one, then I can improve version two. Imagine a Robbie Mark III, a Matilda Mark IV. My goal in design is to reach the nth degree of perfection in the first iteration, and then ensure its delivery. Many good designs never get finished, or are hacked away at by others until the designer gives up and moves on to another project.

Furthermore, no piece of software, however brilliant the design, has yet stood the test of time. We live in a changing world, and software is a pale reflection of it. Most software available today has been through many iterations. We are beginning to see signs of maturity in some simpler software tools such as business applications, or methods such as sorting algorithms. By maturity, I mean that people are not as anxious for the next upgrade to give them functionality X. In a newer wave, the world of 3D modelling has had more products than we ever had word processors. On a yet-to-be wave, we don’t have a common operating system upon which I can build Robbie. I have had to invent one, ROX (Robot operating xystem – please try) for Robbie. Buy ROX, it rocks. I can see the colourful billboards now.

We have had so many office tools that we exhausted version numbers long ago, and switched to calling them by year. Years are passé too, and we are in the chirpy names arena: Omega Office PowerQuest. Buy it now. This year’s model has more superlatives than ever.

Business software abhors variety. Why is that? How can that thought help you make your next million?

Maybe one day our software will be as numerous as the trees, and in as many varieties. Perhaps even your plum tree will be different to mine.

Architecture and music have had their movements. We live in cities of many architectural styles, and musical styles go on changing. Software is still in its early stages. We had our character screen and glorified oscilloscopes. We are now into window and mouse, and fledgeling electronic representations of reality. Maybe our software movements are defined by their technologies. Maybe they will be its gothic or medieval. I think it unlikely though. Perhaps the next generation will provide the dissatisfied youngsters of change, our pre-Raphaelites. And will we be remembered as the Raphaels, the traditionalists, the unblinking robots of the megacorps?

We have a rough idea. Quite obviously, Robbie is state of the art, so we shall need some significant effort up front in research, iterative improvement and proof of concept. To begin, we need an idea of where we are going, and the various models presented here will be a coarse foundation which will need to be improved. We should move next into mock-up and prototype.

Mock up

A design technique which creates an artificial, visually complete but technologically challenged model.

Prototype

A full working, complete in itself, but partial representation, of the final system.

Mock ups are used for showing to people so they will understand and be able to contribute without having to read boring documents. A prototype is used to prove that something will work, and to be able to measure its response.

If Robbie is ever to be complete, he will need a programme plan. This will identify the problems to be overcome, the methods we shall use to measure feasibility and risk. It will contain the definition of the interfaces between the communicating parts of the system, and the deliverables which together will make Robbie work. Each piece of work will have its own project plan, and be developed by different teams. The programme manager will look after the interfaces between projects, and the project managers will meet the targets set in the programme. Either that, or a lone scientist can tinker on in his garage until his work is complete.

I would be extremely interested in the outcome of these competing methods. I have the feeling that the loner would create a far better Robbie, but is unlikely ever to deliver him.

The programme plan needs something else. We have a central processor which we shall refer to as Robbie’s driver. It is the driver which ensures tasks happen on time, marshals communication, and divides out time slices of the thought process. We shall drive the thought process at 100%, allocating a slice of this to each project team. We will not rely on an event driven model. Event driven wastes quite a chunk of processor time, and we will need to squeeze out every cycle we can. During the design, the programme manager will reallocate time slices and manage the requests of the individual projects for a larger slice of the time. I have no doubt that all projects will absolutely need an ever increasing slice of the thought and decision process.

We shall leave Robbie at this point. I have used him to demonstrate how huge projects are approached and argue a few points on the design activity. The design of huge projects is a significant task, and is best approached iteratively. The chief architect will spend quite a bit of time getting to know what the system must be capable of, and where the many cruxes of the problems are. He will then begin with a rough, partial design, and with the help of specialists and other architects, begin to flesh out the solution.

Many huge projects fail, embarrassing governments and suppliers alike. Newspapers leap on the bandwagon of failed IT projects and are filled with glee at another superlative flop and the many millions, if not billions it has cost. Failure can be attributed to many things, but the real failure can usually be traced to poor communication compounded on a lack of real process.

There are many arguments I could have made about The internal design of Robbie and his real time systems, but they have been done before and better in Doing Hard Time[8] 

The SuperSport X9i is a software model of a car, designed specifically for the annual virtual race from Paris to Dhaka, on the ground breaking True2Life world. True2Life is a complete model of the world. It supports every country, road and tree which exists in reality, and uses reality physics to measure the effect of wind resistance, fuel consumption and wear on a vehicle during the race.

The Paris to Dakar race was abandoned early in the True2Life world as there were too many cheats building land bridges across the Straits of Gibraltar. As soon as cost was not an issue it became easy.

It is the consideration of cost which has stifled everything since the Moon race. Cost was hardly an issue then, it was the pride of two great powers in competition. Competition brings out the best in us. Considering monetary cost can destroy anything.

Perhaps the open source movement has heralded a new age of cooperation and collaboration. Maybe we can do away with the competition and cost arguments and raise ourselves as a society beyond the murk of commerce. Or maybe we need the commercial straitjacket around us to make us achieve at all. 

Anyone can enter the Paris to Dhaka race, just as anyone with an internet connection can enter the True2Life world. Huge companies use it for predictive modelling and searching for good locations as offices for their next big push. Small companies use it for research for their aircraft and vehicle designs. Innovators use it to test their products. It contains the physical world, the geographic, demographic, populated world. All you need to do to get an opinion is to send your completed 3d model to it, anywhere you like.

All you need to do to race is to put your 3D car model on the starting grid (now an area of three square miles) and start when the green light comes. Winners from previous years get to start at the front, but you are likely to end up with the pack, stuck with a stopped engine until those in front of you get out of the way. If you’re lucky, you may get going around an hour after the green light.

The race is now so popular, it has become a parody of Wacky Races. Contestants hire others to destroy their competitors with rocket launchers, booby traps, and holes drilled in virtual petrol tanks, leaving drivers stranded in vast deserts.

The poor True2Life world got in a bit of a state in the last war. There was a sudden uprising between the game players and the multinationals. It was a True2Life third world war, played out in streams of light and electrons. Of course, it was nuclear. Getting access to such weapons was too easy, as those killed trying simply logged on again and tried once more. By then the True2Life world was self-sufficient. The whole thing was open source and maintained by armies of theodolite waving fanatics, virtual inventors and opinion givers.

It was shut down and rebuilt. Weapons of mass destruction were banned as they were obviously bad for all. These days the True2Life is rather better than the real world, and is known throughout its user community simply as Eden.

The design of our virtual car will take in the rigour of race. It will be lean, mean and low, and look like nothing on our roads at present.

Figure 7.19 Supersport X9i

When stationary or moving slowly, our X9i lowers its two stabilizer wheels. When on the move, it can sneak through traffic, and overtake on the narrow mountain roads, slipping past where no other car can fit. It is built on motorcycle technology, and uses lightweight materials for its body shell and inner structure. It has a large fuel tank, which is a failing of many motorcycles, and can go for a thousand miles without refueling. The engine is straight from a race motorbike, and with the highly efficient streamlined shape, the X9i can manage 0-100 in 1.6 seconds, and a 400km/h top speed.

As the engine is a production model, developed and tested in Eden, I don’t have to do any work on its design. Some of the racers have designed their own engines, but after three years’ work, they are still not as good as the virtual production models.

Bodies are all different, as they are far more malleable with 3D programs, and far more open to style than mechanical bits. The vehicles are created using components from their real counterparts. Every shop in Eden sells real and virtual objects. It does make things easier, especially when you want to bring your vehicle back to Earth and have it made. Unfortunately manufacture is still not quite up with Eden. Even the best 100 element deposition modellers still can’t quite match the quality of virtual or real manufactured parts.

We have a car to design. Design is creativity. Good design creates a product which works better, is easier to use, and performs well in the non-functional requirement arena of updateability, understandability, etc.

Good design in this case will result in a vehicle which is fast, efficient, easy to control, and of course, cool. Everyone else can see your car. They’re all in the race too.

I have my body shape. I tested it in a wind tunnel in Eden created by NASA. No-one was using it so I put in my body shell, wound up the flow to 200kph and tweaked away at the shape until I had all of the microflows between the body and the wheels as linear and thin as possible. I even played about with different materials and polishes on the surface to get the wind resistance down to a minimum. The drag coefficient is 0.23. Most vehicles in the race are higher, but they have bigger engines. Some people enter with novelty cars where drag isn’t important, but I’m out to win. I’ve even been dieting, as you can only enter Eden as yourself now, and the lighter I am, the faster and further my car will go.

I tested the rubber on my wheels, and have built a cunning interface with Eden, where I project my car into the virtual future on a predictive path always half a kilometre ahead, and measure how the tires perform on that particular bit of road. It’s cheating, but cheating’s OK. I’ve even built in a heatball to counter targeting rocket launchers. I only managed to avoid one last year through shear luck.

Paris to Dhaka is over eight thousand kilometres. If you die en route, then you can only begin again from the start, so once you’re dead, you’re out. That’s one of Eden’s rules.

When Eden was first designed, it was a simple layered model. All objects in Eden could persist themselves, and interacted within an interactional layer. This was built on the existential layer, which was built on the object-coordinate layer, which was built on the world layer, the physical layer and the operating system.

Figure 7.20 The layers of Eden

Eden has evolved. It now contains alternatives to the original core layers, which provide enhancements. The first enhancement was to record history. Then those dissatisfied with reality created their own object-coordinate layer which supported morphing and wormhole jumps. And those unhappy with the world simply created a better one. Once the international space consortium had modelled the stars, the great cloud nebulas and the dark matter, daily trips into space began.

To hold together these diverse ideas, Eden evolved into a 2D layer design, and uses superstrings to hold together the layer alternatives. Superstrings are set up when an object enters Eden. The object’s path through the layers is set up in the master superstring, which maps the object’s path to its chosen layers. Superstrings are also useful as they get around the inefficiencies of layers and classes by creating a direct memory addressed path through the layers to pass messages faster.

Layer security is taken care of at object creation time. When an object is added to Eden, each of the class properties and relationships is replaced by a live pointer model, providing instant direct access to any property or function in any layer. Each object on entering Eden, must state its aims, e.g. the superstring ‘In, Ex, OCm, AR, Phy, Op’ is shown on the right. The object would then use the object coordinate (magic) and alternative reality (AR) layers to give some magical properties, but would otherwise exist in the normal world. Perhaps a game character with a little out of the ordinary powers, but no magic from the magic layer.

Figure 7.21 Eden 2D layers and superstring notation

All Eden objects are held in a data dump in the operating system. They are only instantiated if an object in the object/coordinate layer gets close to them. Objects in the data dump are known as ghosts, and are stored in holographic memory on a 10mm³ piece of quartz. Live memory is currently running at one trilobyte. This is not much to be playing with and Eden is a little overloaded. Some are claiming the memory system is a fossil and needs renewing.

The car needs software to work. In Eden, software can run on virtual microprocessors. Occasionally, manufacturers release new chips in Eden for testing before they go out into the real world. There is no shortage of power for this, as Eden shares out its huge calculation burden between all participants in a grid, and of course the original Eden lab built from the discarded microprocessors of twenty years. Between its ever growing distributed lab model, contributed to around the world by armies of techies wiring up and sharing their old machines, and the shared participation of its high bandwidth connected users, Eden outperforms the latest greatest processors and supercomputers by quite a margin.

You have an idea of the car and its host. We shall concentrate on the software. First, a mind map of what is required.

 

Figure 7.22 Car mind map

I have named the central controller the car brain. It responds to the driver’s commands, controls the car’s suspension and lowers the stabilizers when the speed has dropped to less than 8 km/h. It monitors everything, including the alpha and theta waves from the driver’s brain. When they get too high, the car pulls over and lets him sleep. When he wakes, the engine purrs into life, and they are off again on the race.

All of the information under monitor and display will be shown on a small flat screen in the driver’s dashboard. It can also be used as a heads up display, reflecting off the inner windscreen. This will not be used much, as it obscures the driver’s vision of the road, but may come in handy during the race.

As this is my car, the dashboard does not have to be designed to help others instantly recognize its functions. It will not require usability testing as I am the only user. I can make it bare, functional and able to give me an instant overview of the condition of my car at a glance.

Figure 7.23 Dashboard

A quick glance will show my speed, engine revs, gear, fuel remaining and how far it is likely to carry me. I am conditioned to look top left for the beginning, or most important things, so that is where I have placed these things. The vehicle is reading speed signs, so if I exceed the stated speed, I get a bright hand symbol flashing me. I can see the fuel efficiency I’m getting out of my current speed right next to the fuel level. I’m currently in 5^th gear at 6000rpm, slightly down on my engine’s most efficient, which is marked on the rev counter with a dot. The current efficiency and the amount of fuel left in my tank will get me another 620 kilometres. Also important in these races is being able to keep a clear vision. Therefore, the volume of water left in my window washers is shown almost as importantly as the volume of fuel I have.

I can see the state of the battery, whether my tires are under or over pressure. I can see whether the volume, pressure and temperature of the oil (and therefore the engine) are off normal. The temperature’s a little high at the moment.

The trip computer shows some stats about my current journey; there is a picture of the car bottom left to pinpoint problems, and on the right is a map. The black dot in the map is me, and I’m coming up to a roundabout. The various buttons around the map can be used to expand it to full screen, to show contours, scale, zoom in and out. It can also superimpose a grid on the  map, align the map to the magnetic grid or my direction, or show the distance between the car and other objects of interest within range. 

If the road noise is high or the music is high and the noise cancellation system can’t handle it too well so I am not being understood, I can type in commands on my non-conventional keyboard.  I can also use it to program the car while I am in Eden. If things aren’t working too well, I would have to come out, reprogram and re-enter, so I would be back at the starting grid.

A conventional keyboard would take up too much room, and I wouldn’t be able to type while driving. It is mounted on the rear of the steering wheel and uses a set of three strips of pressure sensitive rubber. It is operated by pressing down on the strip to generate a sound. Behind the scenes, the keyboard input uses an allophone based dictionary to decipher the sounds. Each separate sound is represented by a single 8 bit integer for each allophone, and drawn shorthand on the international allophone exchange as a rendering of its 8 bit number by a square within a square.

Figure 7.24 Pressure sensitive keyboard strip

Allophones are pieces of speech. The letter I in English contains two allophones, an A sound and a EE sound. The word tin has three allophones, T then I then N. Related allophones can be grouped into phonemes for a more logical presentation. A (sounded as in at) E (flat E as in bet) E (short e as in beat) EE (long E as in eel) could be considered a partial set of allophones, or a phoneme. All languages are made up of phoneme sets which are slightly different.

Here are most of our sounds classified by the shape and part of the mouth, nose and throat which are creating the sound. I have taken the liberty of a few foreign sounds to make it a little more complete. I have used the Arabic غ (ghain) which sounds a little like it is pronounced and rolled from the throat. I have also used the nasal baNGla where the NG is pushed out through the nose. I have also use the German ich in both its pronunciations, iCH from the roof of the mouth and iCH from the throat. Finally, I have used the Viking derived Geordie nA (no), with its snatched A, and Gannin (going) with its glottal G. The rest you will have to guess at.

 

These sounds are mapped to a 16x16 matrix of sounds, and represented in an 8 bit format.

Figure 7.25 Eden’s 8 bit allophone format

Here is hello in Eden allophone language. The 8 bit mechanism is easily printed, transported, read from paper and converted into any script. Eden came before Babel

Figure 7.26 'Hello' (or helow) in Eden's allophone exchange format

Each strip of the keyboard represents multiple sets of phonemes, in the most logical order I could think of.

Figure 7.27 Complete keyboard

Some sounds simply cannot be made or cannot be made with enough distinction to be needed. The last 5 columns (not shown in the table above) are for programming sound effects, word or phrase shortcuts, or the arrival of interstellars.

The display is provided by the car’s brain. It also monitors things without any display, such as the active suspension, and controls yet others.

It’s time for the post-it notes. I shall go back to my mind map and write down all of the objects in the car that are of interest to the car’s brain, then divide them up with a logic which will help me create a set of classes for them.

We obviously have many monitor and controller functions. It makes sense to model those to get warmed up.

Figure 7.28 Monitor and control classes

The monitor objects will use a bitmap, and a screen location and size to allow them to display their parts of the dashboard. The control objects will additionally use their i/o functions to exercise control.

Conceptually, the code layer for providing all monitoring and warning is quite simple. When the car starts, it provides a wake-up call to the car’s brain. In turn, the brain runs through its initialization process, recalling data that was saved on shutdown, and starting the threads for each separate monitoring and control system.

The operating system provides and supports the threads, and each thread has its own memory space. The brain and operating system exist in a microcontroller. The input and output for measurement and control are a set of 8 bit channels, each with an 8 bit analogue-to-digital converter. Each channel is connected to an 8 way multiplexer, so 8 analogue lines can be measured using a single port. As an example, let’s look at how a single 8 bit input port will work.

Figure 7.29 Multiplexed input to microcontroller

Multiplexers can work in a number of different ways. The method we use is the simplest, called time division multiplexing, in that the lowest three bits of each port are used to drive the multiplexer. Together the three lines provide 3 bits of information to the address port of the multiplexer. The three lines count from 0 to 7, and the multiplexer output is connected from the 0^th to the 7^th analogue input line in sequence. The cycle repeats continuously. The speed of the count is eight times the maximum frequency. That means, to sample each of those lines at 50Hz, we must drive the multiplexer at 8 x 50 = 400Hz.

Each of the voltages V_in0 to V_in7 are in the range 0 to 5 volts, and are converted to digital numbers 0 to 255. Each digital increment is 5/256 or approximately 0.02 volts.

The circuit in figure 7.29 provides monitoring, but we must also control. To do so, we use a similar circuit comprising the same microcontroller, a digital to analogue (D/A) converter, and a multiplexer. This time we write to the port rather than reading from it. The D/A converts the digital number to a voltage between 0 and 5 volts, which is divided out by a multiplexer, this time to eight output channels. Those channels are used to control the car.

Any book on digital electronics will explain multiplexers in more detail.

We shall use four 8 bit input ports for monitoring, and another three 8 bit output ports for controlling. We shall also use 3 bits of our 8 bit output port for controlling the selection of channels from both multiplexers. We shall need a microcontroller with eight i/o ports.

The software to manage this will be based on an operating system which abstracts away I/O ports, memory management for loading bitmaps, timers and counters and other electronic devices.

When creating such systems, there is no fine line between hardware and software. Both drive each other. For example, I could maintain the clock with a software counting device, or a hardware device. Whichever I choose to do affects the other, in that it would be foolish to do neither, and wasteful to do both. Designing hardware is part of the act of the software architect. Similarly, I have to design the operating system. Admittedly it will not be overly complex as the microcontroller itself does a lot of the work. My operating system will be just another layer in my design.

Let's take a look at the software for monitoring and display. I have two separate threads, one for monitoring and display, and one for monitoring and control. By doing so, I can alter the speed at which each thread will run. It may be that the monitoring and control where no display is required, only needs to run at 10Hz, whereas the monitoring and display is best run at 25Hz to avoid screen flicker or values appearing to jump rather than change smoothly.

Figure 7.30 The monitoring and display thread

The class structure for this application will have a base class for monitoring, display and control. All other classes will inherit from the base class as shown in figure 7.28.

The control object will manage engine tuning, tyre pressure, suspension displacement and hardness, and I shall have three threads. Thread 1 will manage measurement and display. Thread 2 will manage measurement and control. Thread 3 will manage diagnostics. They will be driven in the order 121312131213… That will make my task of thread management easier in the operating system.

If I run the sampling clock at 400Hz, then the circuit will be sampling, displaying and controlling at one eighth of that due to the multiplexer. Internally, my processor must manage to run the complete loop of each thread in 5 milliseconds to keep up with the sampling frequency of 50Hz.

 

Figure 7.31 Monitor, control and display classes

The operating system is now little more than a thread provider, object manager and i/o controller. I shall store the operating system, program and bitmaps in an EPROM (erasable, programmable, read only memory). I shall use a limited amount of memory, probably a single 1Mbit chip will be enough, and have no disks. The program will be written in C using a compiler created for the microcontroller, and written to the EPROM. Should I wish to revise my program, I can remove the EPROM from its plug in base, stick it in the EPROM programmer, and rewrite it.

All of the design work will happen in Eden. A full set of electronic components, circuit constructors and programmers is available, as is a fully operational physical environment.

Our car will exist, fashioned only of light and electrons and delivered to us down a cable of barely a hair’s breadth. Yet we can drive it across the face of Eden, and experience the race as well as if it was a dream.

Design is part invention, part imagination, and part engineering. It begins in the head, and migrates to paper, being improved by an iterative think, draw, think, re-draw, build, tweak, think kind of a process.

 

Figure 7.31 Car software structure

From here to code is one long, arduous step. Each item above must be built, tested, measured and improved. During coding some weakness in the design will be found, and the design will be revisited. Therefore it will improve. This revisit to design should be continuous within the coding process, by constant review and communication. People writing code will have ideas about the design. They may be better ideas than those they were presented with. If so, thank them profusely. Show what a difference their contribution has made and let everyone else know it too. They would be nowhere without your architectural statement in the beginning. You would be nowhere without them questioning your design and writing the code. You are locked in an interdependent game, but interdependence is greater than dependence.

Invention is the pinnacle of achievement of the mind. We create what we believe we can create, however many years it might take, however much must be endured before we can spin our dreams into reality.

Such is the way of the inventor.

As software architect, you are inventor, chief designer and chief engineer. Or, you can claim:

I sculpt patterns of electromagnetic waves in concert
with larger light sources to produce realities [9]

1. Influence Secrets of Successful Architects. Richard J Black. Fawcette.
2. The Mythical Man Month. Fred Brooks. Addison Wesley.
3. After the Goldrush. Steve McConnell. Microsoft Press.
4. Accounting for Non-Accounting Students. John Dyson.
5. Visual Basic and UML. Paul R Reed. Addison Wesley.
6. UML Components.
7. The Design of Everyday Things. Norman
8. Doing Hard Time. Bruce Powel Douglass. Addison Wesley
9. Posted on a WWISA discussion board by Shawn Bellina

1. How would you design Eden?
2. What design would you replace figure 7.13 with?
3. Design your own visual display for the virtual car.
4. Why is your design in question 3 better for you than mine is?
5. How much memory would you allocate for Eden's topological model?
6. Which processor would you select for Robbie's Controller?
7. Would you use an event driven or round-robin controller for Robbie, and why?
8. How would you program Robbie's tactile system, and how would you use that information to control his movements?
9. How would you let Robbie balance on his own two feet?
10. What would you do as programme manager if a team came to you demanding half of Robbie's processor time for their own activity. Would you (a) communicate your needs to the processor producer, even though you are using their most powerful processor already? (b) reduce the other teams' allocations? (c) other? - if you answer other, please specify your solution.
11. If you created a being in Eden, and gave him responsibilities, drive, learning, ageing and self-awareness, how could you prove that he is a simulation and you are not?