GHR's online KCard repository
KCard : Projection
|
Divide
Software architecture can be defined following two
'major' points of view. The two points of view are technical and functional.
The idea developed here is to design the system independently following these
two axes and to merge them (projection operation) later in the process. This offers many advantages:
Generally, technical architecture is less well
understood that functional, so below more details will be given for the
former. Technical architecture
The technical architecture of the system must be
designed to support the technical requirements. The concept of technical
requirements is often misunderstood and limited to technical constraints. It is important to understand that the technical
architecture must reply not only to the technical constraints but also to the
technical functions/services the user will expect from the system Equally important is not to confuse technical
functions/services with functional functions(?)/services
(discussed later). A helpful rule of thumb is that functional requirements
have business value and technical requirement don't. Examples of classical technical constraints are
performance, stability, geographic distribution, ... Classic examples of technical services are
authorisation, persistence, object CRUD management, user interfacing, ... However, the two aspects of technical requirements
(constraints and services) will be handled similarly by the technical
architecture. It is just important not to limit the technical analysis to the
technical constraints therefore forgetting the services (and integrating them
into the functional architecture which is a mistake). Technical use cases (in contrast to standard use
cases which are functional) are used as the primary means to describe
technical requirements. This allows using standard use case methods to design
the technical architecture. The main outputs of this analysis are technical
kernels, which provide packages of technical functions replying to the
requirements across the system and in particular they 'model' the layers. Functional architecture
The functional architecture is designed to respond
to the functional requirements. As mentioned previously, functional requirements
have business value. These are things which must be done for the business to
run (in opposition to the technical authentification
service for example). Use cases are the preferred medium for defining the
functional requirements (with business modelling as input). Many methods
exist to develop architecture based on use cases and these can be used here. Mainly, this analysis results in a number of
functional packages which put together support the business processes the
system is required to. Projection operation
The projection phase is admittedly one of the most
complex operations in architecture design. The goal is to project the functional
architecture onto the technical architecture. This generally results in an
architectural matrix because the functional architecture is a row
(horizontal) and the technical architecture is a column (vertical). Another way of seeing this is by considering how
each functional component blends with the technical kernels. The result of the projection is the software
architecture. |
Ideas to develop
|
