Essential Software Architecture - Chapter 2 Introducing the Case Study - Summary

1. Essential Software Architecture
Chapter 2: Introducing the Case Study
Summary
2.1 Overview
● In this chapter will be introduced a case study that will be used in subsequent chapters
to illustrate some of the benefit of the design principles.
● The applications is a multiuser software system with a database that is used to share
information between users and intelligent tools.
● Fig. 2.1 depicts an informal context diagram:
2.2 The ICDE System

2. ● ICDE: Information Capture and Dissemination Environment
● ICDE provides intelligent assistance to professionals such as financial analysts,
scientific researchers and intelligence analysts.
● ICDE automatically captures and stores data that records a range of actions performed
by a user when operating a workstation.
○ i.e.: When a user performs a Google search, the ICDE system will transparently
store in a database:
■ The search query string
■ Copies of the web pages returned by Google that displays in their
browser.
● The data stored in the database can be recovered by third-party software tools that
attempt to offer intelligent help to the user.
● These tools might interpret a sequence of user inputs, and try to find additional
information to help the user with their current task.
● The unvisited links will be analyzed to extract relevant information that user overlooks.
● Fig. 2.2 depicts a use case diagram for ICDE:
2.3 Project Contect
● The first version of ICDE (v1.0) was developed by small development team.
○ They implemented the Capture User Actions use case.
● The first tangible component was the client that runs on each user workstation, and
drove the design and implementation of the data store.

3. ● The database is an integral part of the rest of system’s functionality.
○ Its design must be suitable to support high transaction rate that a large
number of users could potentially generate.
● The first test was made with few users, and it demonstrated the concepts of data capture
and storage.
● The design of v1.0 was based upon a simple two-tier architecture, with all
components executing on the user’s workstation.
● Fig. 2.3 depicts the design of the first version of ICDE:
● The collection and analysis client components were written in Java and access the data
store (server) directly using the JDBC API.
● The role of each component is as follows:
○ Data Collection:
■ Integrates with loosely coupled components1 running on a client
workstation.
■ Transparently tracks the user’s relevant activities and store them in the
Data Store.
■ Captured events:
● Internet accesses,
● Opened documents,
● Browsed documents,
● Changes made to documents,
1 http://en.wikipedia.org/wiki/Coupling_(computer_programming)

4. ● and some basic windowing information about when the user
opens and closes applications on the desktop.
■ Each event has associated a number of attributes:
● x, y coordinates,
● window activation,
● double clicked elements, and so on.
○ Data Store:
■ Compromises a COTS relational database.
■ The DB stores event information in various table to capture user activities,
with timestamps.
■ Binary files (i.e.: images, documents, etc.) are stored in Binary Large
Object Fields using the native database facilities.
○ Data Analysis:
■ A GUI tool lets to make queries on the data store.
● This was useful for testing purposes.
● Give a general look of the captured data.
● Provides a useful way to analyze data.
2.4 Business Goals
● ICDE v2.0 had much more ambitious aims.
● The previous trial deployments that systems is working, now the sponsors had two
major business objective for the next release. These were
○ Allows a third party developer build a, e.g., “stock advisor” that watches the
stocks that an analyst is looking at in their browser and informs them of any
events in the news that might affect the stock value.
○ Promote the ICDE concepto and tools to potentials customers, in order to
enhance their analytical working environment.
● The above objectives are focused on create an environment around the ICDE
technology, through:
○ Advisory environment for users in a range of applications domains.
○ a market for third party tools.
● Table 2.1 describes the major objectives identified:

5. ● In order to attract a third party tool developers, it is essential that the environment has
a powerful and easy-to-use application programming interface (API) that could be
accessed from any operating system platforms that a developer chooses to use.
● One survey raised that powerful analytical tools might require high-end cluster machines
to run.
○ Hence, developers would need the capability to communicate with ICDE
deployment over local and wide area networks.
● ICDE must provides the mechanism to accommodate new users: scalability.
● Avoid expensive COTS technologies.
○ This in turn will make the product more attractive in terms of price for clients.
2.5 Constraints
● Technical objectives are so ambitious, hence it would require a different architecture
to support distributed data access and communications.
○ Client components like GUI and data capture tools must be stable.
● Changes would only be made to the client to enable it to communicate with the new data
management and notification architecture that this project would design.
● A time horizon of 12 months was set for ICDE v2.0.
○ An interim release after 6 months was planned to expose tool developers to the
API, and allow them to develop their tools at the same time that ICDE v2.0 was
being productized and enhanced.
● Have a fixed schedule.
● Development budget was also fixed.
○ This meant the development resources available would constrain the features
that could be included in the v2.0 release.