Professional Documents
Culture Documents
A Three-Model Architecture For The Analysis of Information Systems PDF
A Three-Model Architecture For The Analysis of Information Systems PDF
The presentation discusses the merging of object oriented technology with the well-established data base
technology in a third generation client-server architecture. The architecture is based on three kinds of
models. The first is an information model describing the information used in the organization. It will
usually describe a relational database, but object-oriented databases can be effective under certain
circumstances. The second is an organization model describing the users and their work processes. This
object-oriented model acts as a formal requirements specification; the required information can be
deduced from the description of the users and their work processes. The third is a tool model describing
the computer-based tools applied by the users to perform the tasks described in the second model. The
tools will typically access the databases; the tool model is thus a specification of the operations that must
be supported by the information model.
The architecture is based on the OOram method that is described in a new book: Reenskaug, Wold,
Lehne: Working with objects. Manning/Prentice Hall 1995.
1 Introduction
Modern database technology has all the hallmarks of the successful technology. The relational model has
sufficient flexibility for the expression of a large variety of interesting business phenomena; yet it has
sufficient rigidity to offer great leverage. The result is that we can describe our business information in a
very high level language such as the graphical NIAM schema language; and leave the programming of
the application details to automatic code generators. [Elmasri]
If the relational model gets its strength from its sharp focus on information structures, it also gets its main
weakness from the same source. Focusing on information structures leaves functional aspects out of
focus. The automatic code generators assume a certain functionality, e.g., get, put, select, and join. If
more sophisticated functionality is needed, the functionality has to be defined in a separate application
program that is outside the scope of the information model.
Another limitation of the relational model is that it assumes the existence of a global schema. Different
clients may see different external schemas, but these schemas are created from the one and only global
schema by filtering operations. The same limitation applies to traditional, procedure oriented application
programs. There is a main program that controls all functionality and also defines the global variables
that are available everywhere. The idea is illustrated in figure 1.
The SYSTEM
required
tasks
information
operations
Tool Models Information Models
The people described in the System User Models need some kind of user interfaces to operate on the
information. The Tool Models describe these interfaces. We use the term tool to denote the artifacts
employed by the users to perform their tasks. The tasks are described in the System User Models, the tool
specifications can be derived from these models.
The Tool Models describe how the users operate on the information. The operations that need to be
supported by the Information Models are therefore specified by the Tool Models.
We will illustrate the three model system architecture by a simple example. We will first consider a
system user model for the management of business travel. The focus will be on organization, division of
authority and responsibility, and the dynamic work procedure. We clearly need an object oriented model
to describe it all, and use the example as a vehicle for introducing the concepts and notation of OOram
role modeling. We then quickly create an additional model for purchasing airline tickets. In section 6, we
describe the idea of role model synthesis enabling us to derive composite models from any number of
simpler base models.
We then move on to an information model covering our example requirements. We see that this model is
basically a data model with almost no functionality. The information model can therefore be
implemented by a relational database service. We finally consider the users' tasks, and give an example
of a tool for the person who authorizes business travels. We see that a suitable tool needs access to a
number of information services in addition to the obvious travel management service. A client-server
implementation of the tools and information services is therefore appropriate even for this very simple
example.
Stimulus
message
IN OUT
Rules Files
IN OUT
Rules Files
IN OUT
Rules Files
Environment System
Ruth
(President)
Ruth
(President)
Bill Peter
(Bookkeeper) (Technical author)
Ann
(Customer consultant)
John Joyce
(Cashier) (Methodologist)
Ruth
(President)
Bill Peter
Bookkeeper
(Bookkeeper) Traveler
(Technical author)
Ann
(Customer consultant)
John Joyce
(Cashier) (Methodologist)
We select a notation and redraw as the role model collaboration view of figure 8. It shows the
collaborating roles and their message communication structure.
Traveler au tr Authorizer
bo
Book
pm Paymaster
keeper
Book
Traveler Authorizer Paymaster
keeper
travelPermissionRequest:
travelPermission:
expenseReport:
authorizedExpenseReport:
paymentRequest:
Real
World Objects Roles Code
IN OUT
Rules Files
IN OUT
IN OUT
Observed from
inter-object space Rules Files
Observed from
inside an object
Figure 12: System User Model collaboration view as seen from the environment
Authorizer Traveler
travelPermissionRequest: (aTravelRecord)
Check purpose
Traveler Authorizer
travelPermission: (aTravelRecord)
<Traveler travels>
sec
orderTicket:
orderTicket:
tr
ticket:
Booking Book
bk
Clerk Keeper invoice
ticketWithCost:
ta pm
authorizedInvoice:
paymentRequest:
cust
payment:
Travel
ven Paymaster
Agent
Book
Traveler au tr Authorizer bo pm Paymaster
keeper
Derived model
DTE
Authorizer
tr
au bo
DTE
Traveler
sec
tr
DTE DTE
DTE
Booking bk Book pm
Paymaster
Clerk Keeper
ven
ta
cust
DTE
Travel
Agent
Booking Book
Traveler sec tr bk
Clerk Keeper
ta pm
cust
Travel
ven Paymaster
Agent
TravelExpense activity
travelPermissionRequest:
travelPermission:
Ticketing activity
orderTicket:
orderTicket:
ticket:
invoice:
ticketWithCost:
authorizedInvoice:
paymentRequest:
payment:
expenseReport:
authorizedExpenseReport:
paymentRequest:
DTE
DTE
Booking
Traveler
Clerk
travelPermission: (aTravelRecord)
ticketWithCost: ()
<Traveler travels>
Figure 17: Derived model method sends base model stimulus message
Notice the fundamental difference between the creation of an external database schema and the synthesis
of a composite model. The external database schema is created by filtering from a single, global schema.
The creation of a derived model is the very opposite: the derived model is composed from a number of
initially independent base models:
1. The specifications from the base models are initially orthogonal.
2. Attributes and Methods (actions) integrate behavior:
- Traveler sends orderTicket as part of travelPermission method
- Traveler learns airfare from AirlineBooking model
- Traveler uses airfare when preparing expense report
The synthesis operation is used to support three popular abstraction mechanisms as illustrated in figure
18:
1. Peer model composition. An example could be that we have a base model for our budgeting
operation, and another for expense control. A cost management model could be derived from these
two models.
2. Hierarchical decomposition and aggregation. An example could be a materials management model
that has a PurchaseOrder-role. Opening this role, we could see that it enclosed a role model with
roles such as PurchaseOrderItem.
1.
Separation of concern
and composition on
same level of abstraction
2.
Separation of concern
and composition between
different levels of abstraction
3.
Specialization
-- generalization
Purpose
Attend OOPSLA'95 conference
Week 35 36 37 38 39 40 41
Authorize Reject
pla
Authorizer Account
Authorizer tool auth acc
Tool Service
bud
Budget
Service
We will here only give a first sketch of a possible model. Figure 21 shows a semantic view of the most
important parts, more work will be needed to specify the complete database.
Part of Travel
Permission
Consists of
Consists of
Pay
Authorization
Pay
Request
Part of
8 Conclusion
In this paper, we have shown how the proper application of object-oriented concepts and the OOram
technology can help us open the boundaries of databases and application programs. By moving from
closed to open systems, we can create multiple, interdependent models focusing on different aspects of
the enterprise. We can model the user organization and its procedures separate from the information
model, and the users' information tools independently of their information needs. Finally, we can study
the interdependencies between these models, creating an overall understanding of the enterprise
information handling needs and capabilities.
9 References