Agile Architecture
The software architecture defines how its various components are connected and how they communicate. An agile architecture defines its connectors so that it can adapt easily and rapidly to new or different components. This goal requires segregation built into the component design. Segregated components can communicate through an event-driven mechanism that isolates them even further. Coupling segregated components with event-driven communications help simplify two additional agile abilities: (1) to extend an application’s capabilities after delivery and (2) to develop detachable user interfaces.
Segregated Components
Software components normally rely on other software components in order to complete a requested task. Each client component connects and communicates with its support, or service, components through their interface, or list of methods they provide. This tight coupling between components usually means service components exist first so the client components are aware of their interface.
An agile architecture needs components with loose coupling where they are not dependent on others. These segregated components must be able to exist with or without the presence of other components. This concept is very crucial and has become a cornerstone in all our designs.
Event-driven Communications
An event-driven architecture allows its components to remain idle until they receive a call (an event) from another component. Components can publish as many events as deemed possible, or necessary. They will then fire them off, as they occur, to any component that subscribes to the event. If no component subscribes to an event, it should simply do nothing. Published components fully function without any knowledge of what components will subscribe. This concept is the enabler that provides segregated components a path to succeed. It is also important for maximizing idle time with the CPU by ensuring the only components active are those servicing any current user requests.
Extendibility
An agile architecture must be able to adapt to new components in the future. This requires a method to link new libraries with the application and for the library to register its components. Making an extendable architecture allows application developers as well as third-party developers to add new features to an existing application. This should help the validation process as developers add new features because the existing software remains unmodified. The risk of breaking the existing application when adding new features is practically non-existent. (There is always the possibility, however, that outputs from new components can cause unacceptable behaviors with existing components.)
Detachable GUI
Segregating components allows the developer to create an application with a graphical user interface without the problems inherent of the GUI. This is especially important with a machine control application.
One of the biggest problems with a GUI is it must remain responsive to the user. That means that functions called in response to a user action must complete as quickly as possible (ideally less than half a second). Machines do not always respond this quickly. In fact, they often take many seconds to respond. The GUI executes within its own thread, so the application must spin more threads where the actual work will occur. This keeps the GUI thread idle, which makes it more responsive to the user.
Spinning worker threads to perform these functions creates a couple more issues with the GUI, however. First, the user requires feedback that the function is still working and knowing when they are complete. Usually the GUI controls are disabled or the GUI enters a busy state until the function is complete. A second issue occurs if the function needs to provide intermediate data to the user while it is working.
Both issues require the worker thread to communicate and synchronize with the GUI thread. This can cause the worker thread to hang and lose valuable time as it waits for the GUI thread to respond, especially when the function is performing lengthy calculations and/or synchronizing with critical hardware devices.
An agile architecture should define a relationship between the GUI and the application that keeps the GUI responsive without starving the application for any necessary bandwidth. Defining GUI components with segregation that are event-driven makes this goal easier to achieve. The application can actually execute without the GUI present. This will make it easier to tailor multiple GUIs for the same application for specific purposes. It also makes it easier to create remote GUIs that will control the application from remote computer systems, including over the Internet. Finally, this allows applications to execute as a service without a GUI that is controlled by other applications.