197
Tests should be designed and written first, and this forces a new perspective. The program-
mer develops each object from the perspective of a consumer of that object ’ s services,
making the object ’ s interface as important as its function. By writing test cases first, the
team forces the software to be testable. Writing test cases depends on a good design docu-
ment, a good requirements document, and a good development team leader, who budgets
sufficient time (likely 30–40% of coding time) for proper testing.
Testing should consist of a cohesive collection that attempts to cause failure under
controlled conditions. Ideally, testing will commence with the same toolsets that will be
used live and for this reason many exchanges and third-party vendors offer a simulated
trading environment. However, the order matching (i.e., fill characteristics) will likely be
significantly different from those experienced during live trading.
Writing tests is a form of documentation. Test cases used to test prototypes in K | V 1.4
should be used to test corresponding implementations in this step. Regression tests against
the results of tests in K | V 1.4 will verify correctness of the coded implementations.21.2.3. Conceptual Design
During conceptual design, the development team analyzes decomposed problems, experi-
ments with possible solutions, and creates a set of candidate architectures, which they
can further analyze and evaluate. The design step focuses on refining the description and
selecting from among alternative designs, potentially using a UML package and class dia-
grams with dependency associations. An architectural design becomes a blueprint, that is,
a technical description of a system that can be looked at and criticized. The development
team categorizes these perspectives on designs into views:● Logical view. Defines the software tiers and major abstractions that perform the
system functionalities.
● Object view. A view of the classes and their composition into components and
modules.
● Data view. Defines the design structure of the persistent data.
● Data flow view. A way of looking at the relationships between components.
● Concurrency view. A view of processes and threads and how they communicate
with each other and interact on shared resources.
● Physical, or deployment, view. A description of the system ’ s hardware resources
and network topology.During conceptual design, some coding of prototypes or stubs may take place. Often, a
team will build a skeleton of the system as a proof of concept. This skeleton may serve as
the basis for further development during the following step.21.2.4. Evaluation
The goal of Stage 3, Step 2 is to arrive at best-of-breed technologies, the hardware and
software that best satisfy the prioritized quality attribute requirements. Design evalu-
ation is where the development team analyzes candidate technologies and designs as
soon as they are stable, but before the team makes any real commitment to development.21.2. D ESIGN PROCESS