Architecture: Prototyping
Prototyping consists of several activities to produce architectural documents and artifacts. One of the first steps is creating an architectural "sketch" - an initial image of a system's look (external structure). The external structure will then accommodate system components. Typically all the components are interconnected in the system. Thus one must define relationships and dependencies between system components and elements. After elements are defined, a maquette is
created depicting the system's external structure.
Physical design consists of the maquette embodied into a structure simulating real-life system. This is a system prototype.
System Subject
Implementation of system’s Conceptual Integrity is achieved when all elements of the system become of the same type.
It allows them to acquire the same characteristics and facilitates easy recognition and communication between them, even if they have their own subtypes.
OpenFrame Framework, for instance, is based on the BizCase Concept. BizCase is a subject of the OpenFrame system and purpose of OpenFrame processes.
The OpenFrame system processes operate on BizCase that is transmitted from one component to another.
Each component and object responsible for BizCase processing in the OpenFrame system must be able to recognize a BizCase instance and operate on it.
However, we cannot make BizCase the root type because BizCase is the system subject. Making it the root type would force any object in the OpenFrame system to implement it while not each object may be a BizCase.
(Considering System Metaphor of Postal Letter, we cannot make a Postman acquire a Letter type since the Letter is the system subject and Postman is not Letter).
We need to define a system-wide type (such as Post Service). In this case, we would be able to say that any object in the Postal business is of Post Service type, including Postman, Letter, and other subtypes.
We can call the OpenFrame system-wide type as IOpenFrame. Then any object in the OpenFrame system would be of IOpenFrame Type.
We cannot declare BizCase type before we define and declare all system-wide types and subtypes that form a system structure.
In order for all components in the system to share common types (and subtypes), such types should be placed into a repository of common types – a metadata component. The metadata contains only system-wide types and common objects. If a common type or object is not referenced (used) by all the components in the system, it should not be declared in the system metadata but rather in a separate repository or component.
Prototype Design Process
Prototype design goes along with generating a set of design documentation. It is back-and-forth process: a prototype gives hints what should be formally defined, and formal specifications describe how concepts are implemented in the prototype the way they should be implemented in the real system.
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.
Each design falls within one of specific architectural areas. The system/foundation/metadata area 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 area defines the components which are recognized in and are unique to a particular domain. Components in the domain area represent either
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 area 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 system area and domain components from the domain area 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 area contains the user interface components that interact with the user and the application area 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; 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 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.
»
Back To Steps to Create True Software Architecure