196 CHAPTER ◆ 2 1 Design System Architecture
As part of design processes, all engineering disciplines apply abstraction to reduce
complexity. Within each level of abstraction, the team can perceive two views—dynamic
and static. A dynamic view shows the interactions between modules or objects, and a
static view shows the structure. Apart from structuring design, abstraction can also form
the backbone of documentation of the system. User documentation can address domain-
level requirements, whereas the software architecture document addresses conceptual
designs.21.2.1. Decomposition
In decomposition, the team reduces complexity by constructing a set of independent
abstractions to describe the system, separating functionalities into components that have
defined interfaces. This way the development team first views the system as a single
component within some physical environment and then works from the top down into
the individual tiers. Modules form the highest-level decomposition view of a tier ’ s static
structure. The high-level architecture can be shown as a set of interconnected modules or
components. At this phase, the internal mechanisms and objects that comprise modules
and components are irrelevant.
During decomposition, the dynamic views depict the behavior of the system; for
example, how the historical and real-time data feeds in, how the system processes the
data, and how the data flows out of the system. Whereas domain analysis modeled the
real-world abstractions, this phase models the abstractions as they are to be represented
inside the system.
With respect to performance, as a development team decomposes a design, the team
often gives each component a budget for execution time and memory space. Changes that
improve performance may make the program harder to work with and can slow develop-
ment. We recommend the team write tunable software first, then tune it for speed. That is,
we recommend the team ignore performance until a later optimization loop. Nevertheless,
well-factored code will give a development team more time to spend on performance
tuning.21.2.2. Test Design
Test-driven development requires that the team design unit tests prior to coding.
Fortunately, the product team has already created test cases for the trading/investment
strategy, execution, and data cleaning algorithms over the course of Stages 1 and 2, so
the development team should not need to design new tests before coding. For user inter-
faces and data integration modules, the development should design unit test cases prior to
coding.
We believe in test-driven development and tests require plans. While quality assur-
ance testing will occur in Step 4 of this stage, we assume in this step that programmers
are employing code reviews and test-driven development, where:● Unit tests verify the correctness of every single method of every single object and
module.
● Integration tests verify unit tested software modules as a group.
● System tests verify that the complete system complies with the specified requirements.