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

 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.

The database is an integral part of the rest of systems 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 users 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 users 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)

 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:

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.