Amarco case study:
a banking authorization system
Services and structure
This is a "classic" study of a banking
authorization system. The basic services of this system are:
- Process and deliver authorization to its own cardholders
- Request external authorization for alien cardholders
- Fulfill billing and administration services
The system's objects were first defined in Amarco Repository tool.
They were drawn afterwards by the Amarco Cartography tool. This page
presents the services and the structure of the authorization system.
Another page presents the
behavior aspects.
|
external architecture
internal architecture
internal object
notes about reuse
|
Authorization system - External Architecture
The External architecture of the system shows the users of the system and
the service points:
|
|
ATM access system - presents the user requests for
authorization |
|
|
Billing system - used to store billing information for
fulfilled requests |
|
|
Administrator - controls the system |
|
|
External authorization system - processes the requests
from non-local cardholders |
The picture shows also the service points (red for "server" Service
Point, white for "client" Service Point):
A better view -
the same image - JPEG (70 K)
For example, the Authorization service point could support the following
services:
|
Requested services |
Rendered services |
|
Request authorization |
|
|
|
Authorization granted |
|
|
Authorization denied, card preserved |
|
|
Authorization denied, system unavailable |
|
|
Authorization denied, card rendered |
|
Request account information |
|
|
|
Information present |
|
|
System unavailable |
The external architecture shows the purpose
of the system. This global view tells what is the environment of the system
and how the system is connected to this environment. With the service
definitions you may ask prospective sellers about available products.
Authorization system - Internal Architecture
The internal architecture shows the component objects. The service points
that were visible in the external architecture view are now mapped on the
component objects. We can see now also other objects and service points that
were not visible before.
A better view -
the same image - JPEG (111 K).
This picture is easy to understand, even by non-technical oriented
managers! The information is organized in objects. It is possible to assign
the objects to various people or organizations, to be taken in charge. It is
clear which services concern each object, how the objects connect and
communicate. The picture tells the whole story. At the same time there is
rigor in this organization representation. All communications between
the components take place only through service points, and we know which
services belong to which service points.
NOTE: The relationship that is depicted is not confined
to technical domain. An enterprise is organized like
that!
Internal object - authorization network
The internal objects that make the structure of the authorization system
are seen as external architectures. Each one can be divided in the component
parts. For example, the authorization network object may contain a
conversational network.
A better view -
the same image - JPEG (100 K)
The conversational network may be divided at its turn in component parts
etc.
Notes
about reuse
It is interesting to note that the conversational network object is not
dependent on the authorization network. If there is another project, like a
messaging system, the conversational network object can be
reused.
I think it is clear that the reuse concerns the specifications, the
service definition and the paperwork that was needed to specify what a
conversational network is like. It may lead to the reuse of the
implementation of the conversational system, but this is not compulsory.
What is reused is the know-how about the object, and this know-how can be
applied to any technology!
This page presents the services and the structure of the
authorization system. Another page presents the
behavior aspects. |