An Object-Oriented Frameworks-based Architecture for Decision Support Systems

Reusability is considered to be the key for achieving productivity and quality in software, and much has been claimed about the particular contributions of the object-oriented paradigm towards the achievement of these goals. Object-oriented frameworks are coarse-grained reuse units, composed of a set of classes speci cally designed to be re ned and used as a group. In this paper, we discuss the nature of frameworks necessary to build a particular type of systems, namely Decision Support Systems (DSS), and their organization in a generic OO DSS multilayer architecture. DSS are systems intended to improve the e ectiveness of decision making, but information technologies can only have a major impact on decision making if techniques allowing the easy and rapid development of DSS are available. Much bene t is expected in terms of easiness and rapidity of development by constructing DSS from domain-oriented reusable components, as well as in terms of quality of DSS in this way developed.


Introduction
One of the persistent c hallenges faced by managers is to comprehend and respond in a timely manner to the opportunities and threats of the market place with decisions that will make the best use of corporate resources.Decision Support Systems (DSS) are computer-based systems intended to improve the e ectiveness of decision making, by helping decision-makers use models and data to solve semi-structured to unstructured decision problems 46,47].Major problems identi ed in early DSS designs were: 1) the systems were so time consuming and costly to develop and maintain that they were di cult to adapt to rapid changes in organisation's decision support requirements, and 2) they were too user and problem speci c.From these realizations, and aided by rapid advances in information technology, m uch of DSS research has been oriented towards the investigation of more exible approaches for the easy and rapid development o f D S S .
Despite their di erences, most propositions found in the literature aim at the discover of some degree of genericity and reuse as the foundations for the exible and rapid development o f D S S .T w o major trends can then be identi ed since late 1970's: DSS generators and Generalized Model Management Systems (MMS).DSS generators 47], such as spreadsheets, nancial modeling languages, MS/OR packages, etc., are implementation tools targeted at reducing the time, cost and e ort involved in implementing and maintaining a DSS.The focus on Generalized MMS 10,17,33,38] is rather to extend the scope of DSS, so as to allow the support of multiple problems using a variety of models and data sources, as well as the centralized management of models as an organizational resource.In both approaches, the underlying genericity for DSS development is function-oriented.DSS generators enable the reuse of high-level implementation functions targeted at the requirements for DSS development.The reuse promoted by Generalized MMS is at the level of generic facilities for development, storage, manipulation, control and e ective utilization of models as a corporate resource of an organization, in an attempt of evening it up with Database Management Systems (DBMS), which o er the same facilities for data.
The easy and rapid development of computer-based systems is a concern shared by the Software Engineering community with regard to the development of applications in general.Reuse is regarded as the key for improving quality and productivity o f s o f t ware development 8], with a primary focus on the potential contributions of the object-oriented (OO) paradigm and derived methods and technologies 37,40,30,31].Frameworks are an object-oriented reuse technique.A framework 16,52,28,31,40,22] can be regarded as a high-level application or subsystem architecture, consisting of a set of classes that are speci cally designed to be re ned and used as a group.A framework represents a generic solution for the development of applications in a speci c domain (e.g.graphical editors 29], operational systems 13], graphical user interfaces 34]), which can be customized to meet the particularities of the problem at hand.Being more coarse-grained reuse units than individual classes, frameworks are expected to promote application component-oriented r euse, b y addressing the development of applications as the activity o f re ning and binding pre-de ned, plug-compatible components that are truly application oriented 40].The development of speci c applications based on the reuse of frameworks induces a new application development life-cycle, in which two distinct activities can bedistinguished 23]: 1) Application Engineering, related to the development of frameworks, and 2) Application Development, where frameworks are customized to develop speci c applications.
The OO paradigm has lately attracted the attention of the DSS research c o m m unity, but more emphasis has been given to the bene ts of the unifying characteristics of this paradigm in the design of DSS 19,36,38,39].We h a ve b e e n i n vestigating the potential contributions to the DSS eld of the domain-oriented genericity underlying OO.The issue of decision problem formulation and modeling based on domain-oriented components has been addressed in 4,5], where frameworks were used to represent classes of decision problems (e.g.industrial activity planning, capital budgeting), expressed in terms of the prototypical decision elements.This approach is intended to decision-makers as a modeling tool, since a framework, regarded as a generic decision model for problems of a certain class, can becustomized through an instantiation process to represent the particular decision problem at hand.Speci c models can be constructed by selecting, adapting and combining problem-domain concepts.The methodological role played by a framework based modeling environment is discussed in 6].
In this paper, we go one step further, considering the development of DSS that provide such modeling capabilities, through the reuse of OO frameworks.Frameworks for DSS development in the domain of nancial instruments analysis are reported in 20, 9, 1].Their experiences con rm that application engineering is a hard task for which presently no consistent formal support exists, and therefore subject to much empiricism and creativity, and doomed to a trialand-error process.As an attempt to manage the complexity of framework development and reuse in large scale industrial banking projects, 2] proposed the Gebos System, an architecture in which distinct types of frameworks are organized in 5 distinct layers: business domain, business section, application, technical kernel and desktop.The Gebos System makes it possible to con gure and adapt new application systems in a comparatively short time 2], since it identi es and organizes frameworks with loose coupling and fewer dependencies.
In restricting our concerns to the DSS context, we have also identi ed a number of common criteria for DSS development based on frameworks reuse.The contribution of this paper is the analysis and description of the di erent natures of frameworks that can be combined for developing DSS, and their organization as a generic OO DSS multi-layer architecture, aiming at a less hazardous approach for performing the application engineering and application development activities in the DSS domain.
The rest of this paper is organized as follows.Frameworks are discussed in Section 2. The striking characteristics of target DSS, i.e. the type of DSS that can adequately be developed through the reuse of the suggested reusable components, are presented in Section 3. The distinct types of reusable components for target DSS are then detailed in Section 4. In Section 5, the application development of DSS is brie y discussed, and Section 6 draws conclusions.

Frameworks
Object-oriented application frameworks are a promising reuse technology for reifying proven software designs and implementations 22,31].A framework provides a generic solution for a given class of problems, which c a n be customized to meet the particularities of the problem at hand.A framework can be regarded as a high-level application or subsystem architecture, consisting of a set of classes that are speci cally designed to be re ned and used as a group.A framework concentrates on describing the kind of objects that make up the ensemble and their protocol of interaction, i.e. how they cooperate with each other to accomplish the overall objective of the application.Most classes composing a framework are abstract 41], i.e. they serve as template for other classes (concrete classes), and not for objects.The functional interface of abstract classes is essentially de ned by abstract operations, for which code is actually provided in concrete classes.Though code can equally be provided in the classes constituting a framework, the essential role of a framework is to describe the way a system is partitioned into components and their interfaces.In this way, the users of frameworks, i.e. application developers, can concentrate on re ning and combining components.This is the key insight behind frameworks 31,40,16].
The rst and most successful frameworks were in the general domain of graphical user interfaces (GUI).Well-known frameworks in this domain are MVC 34] De nitions for frameworks vary, as researchers and practionners have di culty on recognizing the similarities and di erences with regard to other reuse techniques in general, and OO reuse techniques in particular 48,32,22,31].For the purposes of this paper, it is interesting to adopt the proposition of 22], which classi es frameworks according their purpose as system infrastructure frameworks (e.g.operating systems, communications, GUI), middleware integration frameworks (e.g.implementations of OMG standards, message-oriented middleware) and enterprise application frameworks, targeted at speci c application domains (e.g.telecommunications, manufacturing, nancial engineering).The rst two focus largely on internal software development concerns and are basically application domain-independent, whereas the latter is targeted directly to support the development of end-users applications and products in speci c domains.
Relative to system infrastructure and middleware integration frameworks, enterprise frameworks are the most di cult and expensive to develop and commercialize 22,31].Indeed, designing a framework is like d e v eloping a theory about application development, that can be tested only by trying to reuse the framework.While developing software is di cult enough, developing high quality, extensible and reusable frameworks for complex applications domains is even harder 24,52], in particular when no standards or normative w ays of developing applications exist for such domains.
OO and framework design principles 28,42,44,15,32] and design patterns 24, 31, 41, 14, 50] are important trends towards reducing the complexity of frameworks development and (re)use.It has been recognized that black-box frameworks are easier to reuse than whitebox frameworks 28,22].Whereas white-box frameworks rely heavily on OO programming language features like inheritance and dynamic binding, black-box frameworks support extensibility b y de ning interfaces for components that can be plugged into the framework via object composition and delegation.Back-box frameworks are easier to reuse because they do not require from application developers an extensive k n o wledge about how the framework was developed in order to be reused, but they are much harder to design since interfaces for a wide range of use cases must be anticipated.Patterns have become a popular way to reuse design experience that cannot be expressed in terms of components, and have been extensively used as a guide for the development of more reusable frameworks.As for frameworks, de nitions for patterns vary, in uenced by issues such a s granularity, domain (in)dependency and notations for patterns description.Other research issues on frameworks are documentation, learning curve, development and maintenance processes, framework economics, framework standards, interoperability, etc 22, 31].

Striking Features of Target DSS
No generic solution can be constructed without a clear understanding of the nature and characteristics of the speci c solutions that one wishes to be derived from it.DSS are di cult to de ne, and many are the sources of disagreements for their de nition 46].A generally agreed upon functional architecture for DSS is the frame of reference proposed by 47], which i d e n ties 3 main functional components, namely the model component (MMS), the data component (DBMS) and the dialogue component.DSS following this functional architecture are referred to as model-oriented DSS.
Acceptance of (model-oriented) DSS by managers as a decision-making supporting tool is still limited.Model formulation is typically performed by experts, and managers often feel reluctance on using models they do not fully understand, and in which d e v elopment they had little participation 18].One of the major goals in the DSS research is the provision of modeling environments for users who are not modeling specialists 21,46].The reusable components discussed in this paper are targeted at the development o f DSS supporting modeling capabilities for non-experts.The basic idea is that, by using application component-oriented components to construct the modeling capabilities of DSS, the domain concepts represented by those components become also apparent t o DSS users (i.e.decision-makers), such that model formulation, from their point of view, becomes the simple process of choosing and applying a set of specialpurpose, domain-oriented concepts for describing the decision situation at hand, in a process fully compatible with their pro les, as described in 4,5,6].This and other features of target DSS are further considered below.For illustration purposes, a very simple example of speci c DSS that could beconstructed according to the proposed approach is considered.Figure 1 presents some elements of the modeling facilities of a simpli ed DSS for capital budgeting decision problems.modeling paradigm: decision-makers should be able to express their speci c problems in a conceptual level, directly in terms of decision elements of the problem and independently of resolution and implementation concerns.This is possible if domain-oriented building blocks used to construct the DSS are o ered to decision-makers as modeling concepts.Model modeling becomes then the activity of customizing a generic decision model for classes of decision problems, by the instantiation of concepts and binding of those instances 5].For example, the Capital Budgeting class of problems 11] involves decisions about investments whose returns are expected to extend beyond a year.The lifetime of a project can thus span over several years, and it implies forecasting all incomes and expenditures incurred in this period.The pro tability o f a n i n vestment can beevaluated by a numberof criteria, such as the Net Present Value (NPV), Internal Rate of Return, Payback Period, etc. Models for this class of decision problems can bestructured and formulated in terms of concepts such as lifetime of the investment project, time-schedules of incomes and expenses, cash ow, pro tability criteria, cost of capital, etc. Figures 1.(a,c) show some of those concepts, and Figure 1.(b) depicts the instantiation of an object time by a user.visual representation: domain concepts are given a graphical representation, using familiar presentation structures, such as table, graph, report, chart, etc.It is through this visual representation that users can create and manipulate instances of model concepts.For example, a tabular form is the most frequent graphical representation for representing Capital Budgeting problems, with columns representing the concept of time, whereas the rows would represent v arious concepts such a s c a s h o w, pro tability criteria, etc (Figure 1.(a)).Instances of those concepts would be created as a result of the creation of columns and rows (Figure 1.(f)).The inherent hierarchical structure among budgetary items, used to describe the incomes and expenditures of an investment project, can berepresented using a tree structure.The generic item tree presented in Figure 1.(c) shows to the user the nature of the items that can bespeci ed, and the valid relationships between them.A customized item tree is shown in Figure 1.(d).For instance, the \working cash ow" is the balance between the \results" of the project, and the \taxes" that must be paid.In Figure 1.(e), in an attempt to create a row representing the NPV criterion, the user is warned that the parameter cost of capital must be de ned rst to keep the consistency of the model.

OO Architecture for DSS
Considering the target DSS discussed in the previous section, we propose an OO DSS architecture divided into 3 parts, namely semantics, presentation and guidelines (Figure 2).This architecture corresponds to the one nowadays adopted for interactive applications, which promotes independence between application semantics and interface 26].Each part is represented by a set of interacting classes with speci c responsibilities, as follows:  Presentation Part: its classes are used to describe how general-purpose representation structures, such as table, graph, etc., can be adapted to become the visual presentation for the concepts captured in the semantics part.Methods are o ered to deal with the conceptual meaning of the presentation structure, and with its graphical behavior.
Guidelines Part: its classes capture all conversational aspects of the interface, de ning the interaction scenarios for modeling and execution activities.This multi-layer architecture is not only a means to manage the complexity of DSS OO development.More important, as in 2], it helps identifying the distinct natures of frameworks potentially reusable in the development of DSS, with the characterization of their speci c role, and the way classes of di erent layers cooperate with each other, so as to produce frameworks with loose coupling and that are more easily interchangeable.This architecture could be thought a s a higher-level framework for target DSS development, composed of lowerlevel framework types and guidelines to combine them.A framework acts as a \specialized methodology", streamlining the application development activity by xing in advance as many choices as possible 40], and this is done with regard to DSS by detailing the nature and characteristics of the di erent building blocks that can beusedin its construction, and their relationship for systematic combination.The identi ed framework types are depicted in Figure 2, and are further discussed in the remaining of this section.The assemblage of these frameworks to develop speci c DSS according to this multi-layer architecture is the object of Section 5.

Decision Models and Model Modeling
Decision model is a semantically overloaded term, where the di erent i n terpretations re ects views at di erent levels ranging from user-oriented to execution-oriented 38].For our purposes, a decision model is the representation, according to some notation, of the elements characterizing a decision problem, in order to seek, analyze and evaluate possible solutions.As any model, a decision model is always an incomplete and approximate representation of the reality, and as such, it constitutes a particular approach for addressing the original decision problem, and can be expressed according to successive levels of abstraction.By analogy with the Software Engineering eld, we regard the expression of a decision model according to three main abstraction levels, namely speci cation, design, and implementation, as depicted in Figure 3.The former is concerned with the problem space, whereas the latter two deal with the solution space.The solution space in the DSS eld concerns the choice of a method or technique for solving the problem.Among the dominant resolution methods and technologies, we can mention mathematical programming, spreadsheet capabilities, simulation, etc.Each resolution technique presupposes a particular modeling paradigm, consisting of a set of speci c concepts and relationships according to which a decision problem has to bestructured.For instance, if a decision model is formulated as a linear program, then model modeling consists in identifying the decision variables and coe cients, and structuring them as a linear objective function and a set of linear constraints.At design level, one can abstract from a numberofdetails, such as the choice of algorithms, and the idiosyncrasies of particular languages available in tools that can beused for implementation.Instead, one focuses on the structuring of a decision problem according to the modeling paradigm underlying the resolution method chosen.
The problem space in DSS consists in characterizing the decision situation, independently of the technique to solve it.One of the many ways to approach a decision problem at speci cation level, is to make use of an existing theory addressing that class of decision problems, such as those theories derived from Economics or Financial Management elds, or set of common practices, in this paper referred to as domain theory.If a domain theory is used, its underlying concepts and relationships can guide the identi cation of the elements in the decision problem that can be used to analyze and evaluate it, and the structuring of these elements in a decision model.For instance, the application of the capital budgeting domain theory to specify an investment problem involves the characterization of an investment project by its lifetime and cash ow, the selection of relevant pro tability criteria, etc.
Two di erent natures of frameworks for developing the semantics part of a DSS were identi ed, namely the decision situation framework and resolution model framework, depicted in Figure 2, and further described below.

Decision Situation Framework
A decision situation framework provides a generic model formulation paradigm targeted at a particular class of decision problems, according to which speci c problems of that class can bespeci ed, independently of how they can besolved.A decision situation framework is thus a set of interacting classes that represent domain-oriented, speci c-purpose modeling concepts derived from a domain theory.Speci c decision problems can be speci ed by creating instances of those concepts.
This type of framework can be classi ed as an enterprise application framework 22], and it is certainly the most complex type of framework to design.Indeed, to act as a model formulation paradigm, a decision situation framework has to capture not only the concepts and relationships underlying a domain theory, but more importantly, t h e generic aspects of its application to represent a particular problem.However, the application of a domain theory to specify a decision model is by no means a deterministic process.It may be a ected in various degrees by ill-structure of decision problems in general, the particular characteristics of the decision problem at hand, as well as by the particular view a decision-maker might have of the problem.Being the numberof possible transpositions of a domain theory for modeling a particular problem very large, possibly and most probably even in nite, it is virtually impossible to capture them all.Therefore, the genericity of a decision situation framework with regard to a class of decision problems relies on the invariants that can be identi ed in modeling decision problems of that class with the concepts and relationships underlying a domain theory.
In representing these modeling invariants, the classes composing a decision situation framework are abstractions that either: -capture concepts and relationships as they appear in the domain theory -factor out common characteristics of a set of concepts for representing higher-level abstractions -are speci cally added for structuring purposes, or to allow more exibility in the model modeling process.
The accompanying methods enable to create, update and destroy instances, as well as to retrieve information associated to them.Methods also exist to de ne typical questions one would like to pose for problems of that class.Typical questions for the capital budgeting class of problems would be, for instance, \calculate NP", \maximize NPV", etc.Most methods de ned for questions will be abstract, since decision situation frameworks are independent o f resolution model frameworks.Indeed, di erent resolution techniques can beapplied to the same problem speci cation, and decision situation and resolution model frameworks are only assembled in the development of speci c DSS, as discussed in Section 5.
For illustration purposes, a very limited aspect of the capital budgeting problem is considered: the pro tability e v aluation of a single investment project by the criterion Net Present Value (NPV).The following elements characterizing an investment project serve as parameters for this evaluation: -the lifetime of the project: N -the time-schedule of incomes: I = ( I 0 I 1 ::: I N ) -the time-schedule of expenses: E = ( E 0 E 1 ::: E N ) -the time-schedule of investments: V = ( V 0 V 1 ::: V N ) -the net cash ow time-schedule: CF = ( I 0 ; E 0 ; V 0 I 1 ; E 1 ; V 1 ::: I N ; E N ; V N ) -the cost of capital: c The pro tability criterion NPV is de ned by Formula 1.The investment is considered pro table if NPV > 0.
An investment project is not necessarily formulated as concisely as suggested above.The main issue is to characterize the cash ow of the investment project, i.e. the in-out ow of money.This implies identifying all sources of expenditures for implementing the project, as well as the source of all incomes and expenses implied by the project over its lifetime, and distributing them over the entire lifetime of the project.The cash ow o f a n i n vestment project is actually described by a number of time-schedules representing the elementary incomes, expenses and investments.Additionally, for problem structuring purposes, one can specify as well a numberof intermediate time-schedules, representing either intermediate balances between incomes and expenses, or aggregated forms (i.e.totals) of incomes, investments and expenses.In other words, the cash ow o f a n i n vestment project can be characterized by t h e successive aggregation of time-schedules.This is just one among the many invariants that can be identi ed in the speci cation of investment decision problems.
Figure 4 presents a simpli ed decision situation framework addressing the capital budgeting class of problems.Due to space limitations, the picture depicts only a few structural relationships between the main classes of the framework.The reader can refer to 5] for the complete OO design of this and all other frameworks presented in this paper.
Item is a class factoring out the commonalties between the concepts of income, expense, investment and balance, which are regarded as the attribute nature of Item.Items are arranged in a multilevel Item Hierarchy, i.e. an item can be an aggregation of items, themselves aggregated or not.The root of the hierarchy is the item representing the net cash ow o f t h e project (Figure 1.(d).A numberof constraints are speci ed for this hierarchical structure (Figure 1

.(c)).
A Time-Schedule relates an item with the concept of Time.It is characterized by an expression de ning the forecasting of values for the lifetime of the project.If the related item is an aggregation of other items, it is possible to deduce that the time-schedule is characterized by an algebraic expression based on sum/subtraction of other time-schedules, i.e. those related to the items aggregated.For example, for t = 0::N P roductionC osts t = F ixedC osts t + V ariableC osts t .
NPV is one among many pro tability criteria 11], and it is related to its arguments, from which an algebraic expression can also be automatically deduced, according to Formula 1.

Resolution Model Framework
A resolution model framework captures on the one hand the generic modeling paradigm underlying a particular resolution technique, and on the other, the algorithmic details of that technique.In capturing the modeling paradigm, the set of classes composing a resolution model framework captures the essential concepts, relationships and assumptions necessary to the formulation of a decision model in the solution space.Besides the modeling paradigm, it also contain methods that either implement the algorithms for execution, sensitivity analysis and optimization of models 10], or interface with implementation functions of DSS generators/tools.The second alternative is based on the pragmatic observation that target implementation tools for widely used resolution techniques are already available in the market (spreadsheet, MS/OR and statistical packages, etc).According to the solution adopted, the framework may contain additional classes for representing data structures necessary to apply the resolution algorithms, as well as transformation procedures 17].For example, to solve a linear program, it must be transformed from a set of algebraic expressions (model formulation paradigm) to a matrix that contains only the coe cients of the decision variables.
Resolution model frameworks, with regard to the general domain of DSS, can be classi ed as infrastructure frameworks 22].It should benoticed that they are much easier to design than decision situation frameworks, in the sense that resolution techniques rely on a sound formal theory from which knowledge can beextracted almost straightforward.In case the behavior necessary for execution is implemented by interfacing this type of framework with existing DSS tools, middleware integration frameworks may be additionally used.
A simpli ed example of a resolution model framework is depicted in Figure 5.The resolution model framework is called DAM (Descriptive Algebraic Model),and it is essentially based on the speci cation of directed causal relationships among variables.It assumes a resolution technique where the values assigned to variables are either explicitly given, or deduced by the application of the relationships, thus similar to the resolution technique underlying spreadsheets.Again, Figure 5 shows only main structural relationships between these classes.The accompanying methods enable to create, update, retrieve and destroy instances, as well as solve methods for executing the model.
As a rst approximation, a DAM can be thought of as a set of variables, where each variable is characterized by an evaluation expression (algebraic expression or input expression), de ning how values are assigned to the variable.Two other main concepts complete the framework, namely variable type and dimension.Every variable is derived from a variable type, and it is further classi ed as simple variable or dimensioned variable, according to whether it is associated to dimension(s).Whereas a simple variable is an abstraction for a single value, a dimensioned variable is an abstraction for a set or sequence of values.For example, given variable type \sales", and dimension \product", it is possible to de ne the dimensioned variable \sales product " (the sales perproduct) and the simple variable \sales" (the total sales of products).

Reusable Components for the Presentation Part
The main goal of the presentation part is to extract from the semantics part those concepts that are relevant for the speci cation and execution of decision problems of a given class, providing DSS users with a coherent and homogeneous view of models, compatible with their cognitive w orld.This work is based on the premise that there is a number of known generalpurpose presentation structures with which decision-makers feel familiar, and that can be conveniently be adapted and used as the visual presentation of a variety of decision problems.A table, for instance, could conveniently represent a budgetary problem, a capital budgeting problem, a forecasting problem, etc.Among the presentation structures familiar to decisionmakers, we can mention tables, forms, hierarchical structures, graphs, (textual) algebraic formulae, etc. Frameworks describing general-purpose representation structures are referred to as presentation structure frameworks.This type of framework can also be classi ed as infrastructure frameworks 22].General-purpose presentation structures can becharacterized by a numberof concepts, relationships, and behavior, independently of the particular use that can bemade of them.These determine, on the one hand, the underlying basic visual properties of the structure and, on the other hand, how it can be manipulated.For example, a table is composed of a set of interacting rows and columns, and it is manipulated by the insertion/removal/update of rows and columns.The static and dynamic properties de ned for the classes of presentation structure frameworks manipulate either the semantics of the presentation (i.e. its underlying concepts), or its visual properties (e.g.size, display).Figure 6 depicts the structural relationships between the classes of the Table framework.Methods include, besides the creation, update and deletion, graphical behavior, such a s m o ve (row, column), display, erase, etc.

Reusable Components for the Guidelines Part
The guidelines part captures all conversational aspects of the interface, de ning the interaction scenarios for model formulation and execution.The domain of human-machine interface is one of the most fruitful ones in terms of generic reusable components available for its development.This genericity ranges from ne-grained (or low-level) reusable units, such as the ones o ered by toolkits and user-interface classes (e.g.windows, dialogue boxes, buttons) available in the class library of OOPLs to more coarse-grained GUI infrastructure frameworks (e.g.34,45,51,35]).Any of them is suitable for guidelines part development, given that it requires reusable components for dialogue development.

Assemblage of Frameworks for DSS Development
So far, we h a ve discussed a decomposition process as a means to perform the application engineering activity, b y isolating frameworks at di erent l e v els of abstraction, and with di erent roles, given a clear de nition of target DSS.Application development is the complementary composition process, where those reusable components will be re ned and put together to develop speci c DSS, according the multi-level architecture presented in Section 4.1.Typically, application development i n volves 52]: 1) de ning any new classes that are needed, most often by the specialization of the classes of the framework, and 2) con guring applications by creating objects of those classes and connecting them together, so as to de ne the global behavior of the application.We use the term assemblage just to highlight the fact that in the DSS context, those classes come from distinct framework types.
In the semantics part, the assemblage can comprise three aspects: assemblage of distinct decision situation frameworks, assemblage of distinct resolution frameworks, and assemblage of decision situation framework(s) with resolution model framework(s).The goal of the rst kind of assemblage is to enlarge the boundaries of the selected domain, by integrating related sub-problems.For instance, a capital budgeting DSS could address the following set of interrelated problems: analysis of individual investment projects, selection of alternative investment projects under capital constraints, cost of capital estimation, and selection of sources of nancing, each of them represented as a framework, and potentially reusable.The purpose of the assemblage of resolution model frameworks is the same: to integrate more resolution paradigms to cope with the needs of decision situation frameworks in terms of questions resolution.The third kind of assemblage is due to the fact that a decision situation framework must bealways assembled with at least a resolution model framework, so as to guarantee that formulated models can be analyzed (i.e.executed).The objective i s t o c a p t u r e the correspondence between decision concepts and their \equivalent" representation in terms of resolution concepts, as well as to automate the transition from one to another.Figure 7 illustrates some correspondences between the Investment Project Analysis framework (Figure 4) and the DAM framework (Figure 5).The basic idea is that when an instance of a decision concept is created, it triggers the creation of the corresponding instance at the resolution level, thus establishing a chain of related behavior in each level of the architecture.Similarly, other operations characterizing the modeling behavior of decision objects will trigger the corresponding modeling behavior at resolution objects.This triggering relationship is represented by the black triangles depicted in Figure 2. Likewise, the questions formulated at the highest level need to be related to the methods that actually trigger execution procedures at resolution model level (solve methods).For example, \calculate NPV" can besolved by triggering the method \calculate" de ned for Variable class in the DAM framework.As already mentioned, decision models are given a visual presentation, and it is through this visual representation that users can manipulate (formulate and execute) models.According to the characteristics of the class of problems addressed and cognitive studies, one or more presentation structures are selected to constitute its visual presentation.The presentation structure framework(s) will be assembled with the frameworks composing the semantics part of the DSS to associate a meaning to the components of a general-purpose presentation structure.For example, in a table there are rows and columns.In a Capital Budgeting Table there are cash ow r o ws, criterion rows, time columns, etc. Users thus create and manipulate instances of modeling concepts through the visual, concrete presentation given to them.For instance, the creation of a Time-Column instance triggers the creation of an instance of the Time class.In this way, every operation applied to presentation objects are forwarded to the decision objects they represent, which in turn, forward it to the corresponding resolution objects.
Finally, the dialogue for the formulation and execution scenarios are developed, using the user-interface reusable components.It should be clear that any new classes that are needed to implement additional features (to the DSS semantics or interface) not foreseen by the frameworks can be added at will.

Conclusions
In this paper, we discussed an OO approach for the easy and rapid development of DSS, based on the reuse of frameworks of distinct types organized in a multi-layer OO DSS architecture.This architecture re ects the needs of target DSS in terms of support to model formulation performed by non-experts, which is a crucial problem that must be overcome if model-oriented DSS are to be more widely accepted.The modeling facilities o ered by target DSS are intended to allow users to formulate decision models by the customization of generic solutions, in terms of prototypical decision elements of a given class of problems 5].
The de nition of striking characteristics for target DSS, the clear interpretation given for the semantically overloaded term decision model, and the de nition of an OO multi-layer architecture, enabled the discovery of distinct natures of reusable components for target DSS development: decision situation frameworks, resolution model frameworks, presentation structure frameworks and user interface frameworks.Each type of framework was characterized and exempli ed, and their assemblage to develop speci c DSS following the proposed architecture was discussed.It was also shown how our classi cation of framework types, speci c to the DSS domain, compares to the ones of 22].It should be stressed that, as more functionality is added to target DSS (e.g.integration with database or data warehouse, visualization facilities, etc), new types of frameworks will have to beconsidered for the architecture, in particular middleware integration frameworks.
The suggested approach is limited to the development of DSS for classes of decision problems for which there exists at least one well-accepted and well-formed domain theory to formulate decision models.The discovery of modeling invariants is the main creative task in the development of decision situation frameworks, and certainly the most di cult one.Due to the ill-de ned structure of decision problems, the generic solutions should cope with a variety of contexts and di erent points of view.The generality of the invariants captured are the determinant factor for the success of a decision situation framework.We believe that the approach is more suitable for the formulation of analysis models, used to asses and re ne problems already identi ed in early stages of the decision-making process.It should be noticed that the other framework types (e.g.resolution model, presentation structure) should not present this kind of di culty for their engineering, given that they are based on stable and widely accepted knowledge.
Frameworks are result of much design and redesign, as each application development experience reveals new di culties for adapting frameworks for new situations.A prototype DSS for a limited aspect of the Capital Budgeting problem was implemented for validation purposes, by the assemblage of various frameworks (e.g.Investment Project Analysis, DAM, Table , Tree).This experience revealed several limitations on the reusability p r o vided by t h e original design of these frameworks.Two major problems were identi ed in early designs: 1) they were too oriented towards the capturing of semantics of the Universe of Discourse, which not necessarily results in a exible OO design for reuse and 2) they were clearly white-box frameworks, relying heavily on inheritance and dynamic binding for con guration, and requiring a deep understanding of they were designed to be used.We are currently redesigning these frameworks using the catalogue of design patterns 24] to achieve more black-box designs, with very interesting results 25].
Future research topics include, among others, the evolution of the architecture for a pattern language for DSS development 14, 50], the investigation of techniques, models and tools to better support the generic model formulation activity (particularly techniques easing the extraction of knowledge from selected domains), the extension of the proposed approach as an aid in the formulation of non-quantitative models, and the investigation of additional DSS features that could be supported with the proposed approach.

Figure 1 :
Figure 1: Modeling Capabilities of a Capital Budgeting DSS

Figure 4 :
Figure 4: Simpli ed Investment Project Analysis Framework

Figure 5 :
Figure 5: DAM Resolution Model Framework Figure 6: Table Framework

Figure 7 :
Figure 7: Correspondence Between Decision and Resolution Concepts

of Capital An NPV row could not be created since the required parameter COST OF CAPITAL has not been defined yet OK HELP WARNING
(a)