Process Prerequisites

The process prescription described in this section is designed to meet the needs of the middle 80% of software organizations. There are more sophisticated guidelines for more mature organizations, for example, the Capability Maturity Model (CMM) approach defined by the Software Engineering Institute (SEI). An extremely dysfunctional organization—for example, one in which people are afraid to tell the truth—is unlikely to benefit from this approach or any other.

There is an important prerequisite to the insertion of software process which is a key challenge for many organizations. In order to effectively utilize a software process, the organizational skill base must be sufficiently high in the areas covered by the process to make it effective. It is much easier to adopt software processes from a book, consultant, or product (e.g., The Unified Software Development Process [Jacobson 99]) than to train the skill base to perform that process. Many organizations make this mistake and struggle mightily to overcome their capabilities shortcomings.

For example, when adopting object-oriented technologies, the development team needs to have some knowledge and experience of the technology before progress is feasible. First, people need to be trained to think in terms of objects. This is a simple thing technically, but a very difficult transition for some people. Many will never succeed in adopting the paradigm shift. Second, people need to be trained to develop with an object-oriented programming language. Competence in using the programming syntax is not the key training objective. What's more important is that people use the object-oriented language properly as an object-oriented language, and not as if they were using a language designed for some other paradigm. It's a very common problem that causes serious problems in object-oriented projects.

Finally, the people need experience with the new paradigm so that they apply common sense and mature engineering judgment. The fact that you have transitioned to objects does not mean that you can ignore common sense and machine limitations. We have seen many designs from otherwise competent engineers that have unwarranted levels of resources and complexity for otherwise simple tasks. This maturity of judgment often goes beyond what you will find documented in textbooks and courses. Instilling this practicality in the development environment is one of the important contributions that architects can contribute to a project. We are amazed that, a decade after the initial popularity of object orientation, many organizations are still in the early phases of transition and experiencing the age-old problems mentioned here.

Every military campaign is executed according to a thoughtfully crafted set of plans. Similarly, in software architecture, a detailed plan is needed to effectively capture requirements, produce designs which satisfy the requirements, manage the configuration of software, and test software artifacts to ensure their quality and consistency with the requirements and designs. Admittedly, it is frequently easier to discuss the need for improved software processes than to establish a plan for creating organizational processes and effectively implementing them for a particular team or organization. However, a well-kept secret among veteran software architects is how to create effective software processes. Before detailing the steps in process creation, there are a few golden rules which every software architect must know.

First, a software process which is not defined cannot be repeatable. If a process is not written down, then there is no basis to claim whether the same steps were truly executed according to a preconceived plan. When a team member has a skill at executing a particular process, there is frequently a resistance to documenting and detailing the steps executed to achieve the goal. Regardless of where the resistance comes from, be it a fear of being replaced or a desire to maintain control over future executions of the process, it must be overcome in order to mature the organization to the point where benefits from an architecture-driven approach can be realized.

Next, a software process needs to be tracked. Specifically, every software process must have concrete, definable deliverables. For example, a quality initiative which involves only a series of lectures cannot be considered a process. This is not to say that lectures and seminars are bad, but rather that without mechanisms to capture feedback and to measure how presented information is actually applied, it will be difficult to determine the impact of such activities. Generally, it is best to break deliverables down so that some portion can be completed every two or three days. A longer period between deliverables does not provide the feedback necessary to ensure that the deliverable is satisfying expectations. Project management that waits weeks or months for a tangible demonstration of progress is guaranteed to receive excuses and radical misinterpretations of the original goals. Just as military leaders rely upon continuous battlefield assessments to measure the progress of a campaign, a software architect needs a steady stream of concrete measures of development progress to assist project management in their frequent replanning efforts and to quickly identify problem areas on a project.

Also, all processes must have a clear progression. Even ongoing processes should define the progression through each cycle. For example, a defect tracking process is typically an ongoing process in an organization supporting multiple products with varying release dates. However, how an individual defect is identified, documented, and resolved must be clearly specified in the process. The consequence of failure to do so is that often a process is defined but its execution falters or occurs sporadically, frequently resulting in a state where outcomes are unreliable—which defeats the point of having a process at all.

A Basic Component Framework Software Design Process

This section begins our definition of a lightweight process for component software architecture and development. Compared to heavyweight approaches to architecture-centered development (e.g., ODP+4), this process is much more compatible with object-oriented approaches that your developers may already be familiar with. If you are working with a small team of developers, and you don't have complex distributed-systems issues to contend with, this process may be right for your project. Architects should carry a big bag of tricks with flexible notations and processes to meet the demands of the terrain.

Given the increasing popularity of component software, it may be beneficial to present a single design process which is effective in coping with the unique issues related to this emerging development approach. The assumption is that the system being built is of reasonable complexity and spans across several distributed heterogeneous systems.

A component-oriented design process is used to define how to implement the requirements for a project so that reuse is maximized from existing framework components and services, and to provide a distributed, scalable enterprise platform for the domain model and future system extensions. The basic approach used is a top-down design methodology which clearly defines the software boundaries, component responsibilities, and system collaborations. In addition, the external interfaces to COTS packages and the existing component base are specified in the design documents.

The design process presented has three distinct stages:

• Conceptual design phase: Specifies at a high level the goals and specific responsibilities of a component

• High-level design phase: Documents the classes, methods, and attributes for the subsystem

• Detailed design phase: Defines the precise semantics for the attributes and methods and the IDL, which provides a well-specified transition into implementation

Most component architectures define four architectural layers (Figure 6.1):

• Foundation layer

• Domain layer

• Application layer

• User interface layer

Each design falls within one of these architectural layers. The foundation layer defines the infrastructure components used throughout the system. It contains classes to manage database access, object-oriented querying, collections, basic object services, and object primitives used to compose more complex objects.

The domain layer defines the components which are recognized in and are unique to a particular domain. Components in the domain layer represent either specific business entities or specific business processes. Typically, domain components provide minimal, coarse-grained methods to access their underlying data representation. This is necessary because domain components are used throughout a particular enterprise and are typically distributed, requiring remote access. By defining a coarse-grained interface, network latency is reduced, with the application layer caching the information to provide a finer-grained method of accessing information to service view components.

The application layer provides the application logic for a set of views. It contains specializations of domain components which are tailored to perform a precise set of tasks. The coordination of object services in the foundation layer and domain components from the domain layer typically occurs in the application layer. Additionally, optimizations such as caching and conversions from domain types to user interface types occur in this architectural layer.

Finally, the user interface layer contains the user interface components that interact with the user and the application layer to provide a complete application from the user's standpoint.

The conceptual design focuses on high-level design issues. It defines the overall scope of the design subsystem and the limits of the responsibilities of the subsystem. Part of the process is to examine the requirements being addressed from different angles to ensure that the design resolves the design issues in such a manner as to let it be reused in other similar situations in other subsystems. Also, the design must handle the use case scenarios naturally and smoothly without unnecessary complexity. The deliverables for the conceptual design stage are:

• A one-sentence goal of what the design does

• A list of the responsibilities of the subsystems

• A clear statement of the architectural level the component is developed for

The document also gives the classes and objects initially identified for the subsystem and a description of what the class semantics and relationships are. This enables an early discussion on how the design satisfies a specific set of project requirements. Specifically, the conceptual design document can be used to discuss how the use cases in the requirements document are satisfied by the conceptual design.

The high-level design provides the details on precisely how the classes which make up the conceptual design are specified. The standard modeling notation in the industry is the Unified Modeling Language (UML), and the high-level design uses the static class diagrams to describe the static model of the classes in the subsystem. The dynamic model is provided in UML sequence diagrams in the detailed design stage. In the high-level design there are three key deliverables:

• Screen mockups of the component being designed

• The static class diagrams

• A document which provides information on the expected dependencies of the subsystem

Specifically, the document describes how the subsystem collaborates with other parts of the framework, what third-party tools and other components will be used in implementing the subsystem, and also the representative use cases which will be used in detailed design for providing detailed sequence diagrams of the selected scenarios. The static class model provides the classes, attributes, and methods for subsystem objects and explicitly identifies the relationships between them. The high-level design is the absolute minimum which must be completed before any amount of implementation can begin.

The detailed design provides the component specification for distributed components in the system (typically in OMG IDL); sequence diagrams for one or more use cases which are satisfied by the subsystem, either entirely or collaboratively with other subsystems; and detailed prose descriptions of the precise semantics of all attributes, methods, and data structures for the subsystem classes. The interface specification also includes the possible exceptions for a component, and the prose details when they occur and how they will be handled.

The sequence diagrams illustrate a use case scenario by tracing through the object model and showing by what method signatures are invoked and on what classes in order to satisfy the use case. An explanation of how system data is produced and what transformations are performed by libraries and nonobject portions of the system is also provided.

The combination of the conceptual, high-level, and detailed designs forms the design document deliverable for a subsystem. Together, the document contains the conceptual overview for the subsystem, detailed UML diagrams of the classes, screen mockups, sequence diagrams showing system dynamics, and a detailed prose description of the semantics of each of the subsystem components.

The component development methodology incorporates a concurrent design process where each of the subsystems is designed and managed by its own design process. The subsystems with the fewest dependencies are designed and implemented first, with subsystems with a higher number of dependencies being designed later. This provides the ability to stage the design process (Figure 6.2) so that concrete incremental progress can be validated with both design and software deliverables. In addition, the components which support the greatest amount of dependencies benefit from more iteration, creating a more robust, reliable platform for application components.

In Appendix B, a set of design templates defining the deliverables for this process and a sample set of designs documented according to the templates are provided.

Finally, process deliverables must be defined well enough to establish clear expectations as to what the document will contain and how it will be presented. Specifying how a process deliverable is to be presented is a recurring weak point for many processes, the predictable result being that the process deliverables vary significantly depending on the people executing the process or on other inconsistent factors.