195
in different languages—the graphical user interface language for the top tier; C/C , for
the middle tier; and SQL for much of the database tier. Two widely recognized best prac-
tices for multitier implementations are that:● Tiers should be agnostic of consumers. That is, the data tier should not know about
or depend on the business logic tier that is using its services. Neither should the
business tier depend on the presentation layer.
● Tiers should be independently testable, maintainable, and versioned. Preferably,
each tier should be able to be tested independently, by simulating the behavior of
the other tiers.Finally, though the presentation layer may seem to be the least important layer
(at least to the performance of the trading/investment strategy), particular attention
should be paid to it. The product team ’ s perception of the quality and integrity of the
system as a whole will be greatly influenced by their perception of the user interface
design.21.2. Design Process
Software development is most naturally done through learning loops, identifying prob-
lems, and discovering best practice solutions through short iterations, including test
design, software design, coding, unit testing, refactoring, and then improving the design
as the system develops. This is the most effective way to rapidly acquire and apply new
knowledge.
Design starts with domain analysis. During domain analysis the development team
studies as completely as possible the features and users of the trading/investment system.
The team leader is responsible for defining the vocabulary of the system and ensuring that
programmers understand the application domain. Misunderstandings create problems.
Domain-level analysis models the interactions of a trader, real-time and historical data,
and the system software in use cases. (A use case is a scenario that illustrates how the
system should interact with the users and real-time markets.) This necessarily involves
communication between the development team and the product team, including iterative
reviews and evaluations.
The development team later will add lower-level designs, but all business-related fea-
tures will be validated against domain-level models. Modeling of both domain-level fea-
tures and lower-level constructs should ensure that a design will solve the right problem
and at the same time be effectively implementable in software.
Once the domain is understood, the iterative design process can be broken down into
parts:● Decomposition. Decompose problems into modules and relationships.
● Test design. Create test cases first, then design architecture.
● Conceptual design. Produce designs of modules. A team may create many alterna-
tive designs over several iterations.
● Evaluation/Benchmarking. Evaluate alternative architectures, called candidate
designs, to arrive at a benchmark design. (The next step, K | V 3.3, will transform the
design into software. The final software will implement the best practice design.)21.2. D ESIGN PROCESS