Page 122 -

AGENT-ORIENTED INFORMATION SYSTEMS ANALYSIS AND DESIGN 107
analysis into particular business processes for processing bills and orders. Likewise, a security
softgoal might be operationalized by defining interfaces that minimize input/output between the
system and its environment, or by limiting access to sensitive information. Alternatively, the
security requirement may be metricized into something such as “No more than X unauthorized
operations in the system-to-be per year.”
Leaving goal dependencies with system actors as dependees makes sense whenever there is a
foreseeable need for flexibility in the performance of a task on the part of the system. For example,
consider a communication goal “communicate X to Y.” According to conventional development
techniques, such a goal needs to be operationalized before the end of late requirements analysis,
perhaps into some sort of a user interface through which user Y will receive message X from the
system. The problem with this approach is that the steps through which this goal is to be fulfilled
(along with a host of background assumptions) are frozen into the requirements of the system-to-
be. This early translation of goals into concrete plans for their fulfillment makes systems fragile
and less reusable.
In our example, we have left three (soft)goals (Availability, Security, Adaptability) in the late
requirements model. The first goal is Availability because we propose to allow system agents to
automatically decide at run-time which catalogue browser, shopping cart, and order processor
architecture best fit customer needs or navigator/platform specifications. Moreover, we would
like to include different search engines, reflecting different search techniques, and let the sys-
tem dynamically choose the most appropriate. The second key softgoal in the late requirements
specification is Security. To fulfill this, we propose to support a number of security strategies in
the system’s architecture and let the system decide at run-time which one is the most appropri-
ate, taking into account environment configurations, Web browser specifications, and network
protocols used. The third goal is Adaptability, meaning that catalogue content, database schema,
and architectural model can be dynamically extended or modified to integrate new and future
Web-related technologies.

ARCHITECTURAL DESIGN

Figure 7.6 suggests a possible assignment of system responsibilities for Medi@ following the
structure-in-5 style (Do, Faulkner, and Kolp, 2003). It is decomposed into five principal actors:
Store Front, Coordinator, Billing Processor, Back Store, and Decision Maker. Store Front serves
as the Operational Core. It interacts primarily with Customer and provides him/her with a us-
able front-end Web application for consulting and shopping media items. Back Store constitutes
the Support component. It manages the product database and communicates to the Store Front
information on products selected by the user. It stores and backs up all Web information from the
Store Front about customers, products, sales, orders, and bills to produce statistical information
to the Coordinator. It provides the Decision Maker with strategic information (analyses, historical
charts, and sales reports).
The Billing Processor is in charge of handling orders and bills for the Coordinator and imple-
menting the corresponding procedures for the Store Front. It also ensures the secure management
of financial transactions for the Decision Maker. As the Middle Line, the Coordinator assumes the
central position of the architecture. It ensures the coordination of e-shopping services provided
by the Operational Core, including the management of conflicts between itself, the Billing Pro-
cessor, the Back Store, and the Store Front. To this end, it also handles and implements strategies
to manage and prevent security gaps and adaptability issues. The Decision Maker assumes the
Strategic Apex role. To this end, it defines the Strategic Behavior of the architecture ensuring that