ENGINEERING BUSINESS SYSTEMS IN EIFFEL
Thomas Beale Deep Thought Informatics Pty Ltd Mooloolah, Qld, Australia phone: + 61 (0)7 5439 9405 email:
[email protected] © Thomas Beale, 1999 1 EE-TOOLS May 00
Engineering Business Systems in Eiffel
RESUME Supervisory Control (SCADA) systems R&D Software Engineer - Leeds & Northrup (Foxboro), Brisbane, Australia
Electronic Document Management System (EDSMS) Software Architect - British Telecom, Martlesham, UK
Configuration Management Centre SCM Manager - British Telecom, Martlesham, UK
Good European Health Record (GEHR; AIM Project 2014) Technical Architect - London, UK
Investment Management System Consulting software engineer - Deep Thought Informatics, Sydney, Australia
Ocean GEHR kernel development Ocean Informatics/Deep Thought Informatics - Australia
2 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Introduction
3 EE-TOOLS May 00
Engineering Business Systems in Eiffel
TUTORIAL FORMAT
30 min break
90 mins 30
15
30
15
90 mins 30
30
= presentation
15
= discussion
15
30
15
4 EE-TOOLS May 00
Engineering Business Systems in Eiffel
OUTLINE •
Introduction
3
•
Management
17
Discussion •
Software Engineering Process
22
•
Tools
31
Discussion Break •
Technical Architecture
42
Discussion •
The Big Lessons
70
Discussion 5 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ENGINEERING BUSINESS SYSTEMS IN EIFFEL Many organisations have made a foray into object technology, with projects in which requirements, some design, and some implementations are engineered using OO tools and methods. While the supposed cost savings of OO have sometimes been experienced, more often than not, they have been masked by increased costs of training and cultural change - the cost of organisational learning, which is part of the establishment of a new paradigm. The more complex functions of business systems such as RDBMS integration, rule processing and meta-data have frequently been avoided as either “too hard”, or seen as adequately served by older technology.
6 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Consequently, a surprising number of organisations have shied away from: • Adopting a fully OO mindset in development: seamlessness, reusability, software contracting • Engineering fully OO systems, in particular, using object databases (ODBs) and object distribution (CORBA, COM) • Being lucid about the cost of change, particularly in education and project management However, the real cost savings are only to be found by “going the whole way”. Why? Because systems engineered with mixed technologies cannot escape the significant costs of both semantic gaps as well as cultural gaps.
7 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ABSTRACT This tutorial will look at the holistic application of object technology, and the particular challenges of business systems, using a concrete example. In a recent project at a leading Australian investment house, a client/server database project was chosen as a trial for a number of technologies which appeared to be well-matched to the complexity of investment concepts, while delivering costeffective maintainability and enhancement. The technologies chosen were Eiffel, BON, and the Matisse object database. The development team consisted of relatively inexperienced client personnel and a consulting software engineer. 8 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Over nearly two years, the project has delivered: • A complete replacement for time-consuming, error-prone human compliance checking, allowing personnel to use the system to define more sophisticated checks, for a greater number of investments • Over 10 production system releases, satisfying an evergrowing requirements definition • “Living” online documentation • A new, formal understanding of investment mandate compliance (i.e. problem domain understanding) • The basis for 3 new similar systems, at minimal cost • The beginnings of a new development culture in which the benefits of long-term, holistic application of object technology are being realised • What the users wanted...!
9 EE-TOOLS May 00
Engineering Business Systems in Eiffel
AIMS OF THIS TUTORIAL This tutorial will attempt to answer typical questions about engineering business systems using an object-oriented approach, including: • Can (should) a business system be developed in 100% OO technology? • How to integrate an object-oriented system with a legacy relational database (properly...)? • Are object databases viable technology? • Does Eiffel live up to its claims for higher quality software? • How to represent and process business rules in an OO system? • Design by contract: is it really useful? • Why not use Java? 10 EE-TOOLS May 00
Engineering Business Systems in Eiffel
MCS SYSTEM OVERVIEW We will commence with an overview of the example system, in order to provide a context for the tutorial. compliance team
cust svc mgrs cust svc mgrs
GUI
security defs invest pos’ns TSF
security defs invest pos’ns rules
RDBMS
reports WEB
ODB GUI
cust svc mgrs
admin
11 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Salient features of Mandate Compliance System (MCS) • Receives a daily cross-load of tab-separated text files (TSF) from a relational database. This contains current investment position and security definitions • Maintains its own database of rules, authored by compliance managers, which must be applied to the investment data. Doing this is "compliance checking". • Executes the rules with respect to the investment data each day, to determine "compliance breaches". Generates daily HTML reports.
12 EE-TOOLS May 00
Engineering Business Systems in Eiffel
MCS PROJECT GOALS The project had challenging goals: • Process: trial object-oriented software method(s) • Tools: trial object-oriented development tools and databases • Deliver: a working, non-trivial system We will explore how these were approached under the headings: • Management • Software engineering process • Tools • Technical architecture First, however, it is useful to consider the cultural context of development of business systems. 13 EE-TOOLS May 00
Engineering Business Systems in Eiffel
CULTURAL CONTEXT Culture defines the development context, type of people, and most of all, expectations. Compare software development culture in business and technical environments: Business Technical RDBMS, else small large Systems programme but not project programme & project Management once only (!) continual (e.g. bimonthly) Estimation constantly changing controlled change Requirements minimal constant Review often first-time only constantly updated Documentation ad hoc, debug-oriented structured, planning-oriented Design/implem ad hoc strict, e.g. IEEE or DoD Testing fast staged Delivery minimal methodology, often sophisticated: change Infrastructure Personnel Quality Cost
management tools mgt, metholodogy, CM few experienced in full-cycle experienced software engineers ?? +++++ $$ $$$$$ 14
EE-TOOLS May 00
Engineering Business Systems in Eiffel
In a business environment, there may be an expectation that any software project (no matter how complex) can be delivered in a few months, at a cost based on a first, very rough estimate. Sometimes, developers have to tailor the first estimate to be acceptable to management in order for the project to proceed at all. The question is: how to proceed in building a quality software system in such a culture? The keys: 1. Find acceptable compromise in each area & be comfortable with it (and stay calm...) 2. Maximise reuse, enabling quality systems to be produced at incremental cost 3. Maximise tool support: •
It won’t get done if it’s not automated
•
To make up for missing procedure and experience 15
EE-TOOLS May 00
Engineering Business Systems in Eiffel
Notice: 2 & 3 above point toward: • Using an object-oriented development method • Investing in tools which inherently support quality In general, the culture points towards the use of tools supporting: • High-level of abstraction • Quick incremental delivery These are all indicators to using a high-level, quality-oriented development solution such as Eiffel.
16 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Management
17 EE-TOOLS May 00
Engineering Business Systems in Eiffel
SOFTWARE ESTIMATION Software estimation is carried out initially to determine the economic feasibility of the project, and thereafter to update the remaining cost of the project. Basic rules (common sense): • Granularity: break down work into items no larger than a small unit, e.g. 40 hours -> error is reduced • Scope: ensure every possible item is covered • Dimensions: deliverables x process (tabulate) • Re-estimate often (every 2 weeks) It is essential to use a project management tool which supports: • New estimate figures - the target • New actual figures - the progress • Critical paths - order and parallelism 18 EE-TOOLS May 00
Engineering Business Systems in Eiffel
The importance of re-estimating continually cannot be overstated. As time goes on the error in the estimate reduces. Not re-estimating makes it impossible to do project management, since the “current position” will never be known. % Error
(see Barry Boehm - Software Engineering Economics)
100 early estimate - very rough
later estimate - better 0
T 19
EE-TOOLS May 00
Engineering Business Systems in Eiffel
SOFTWARE ESTIMATION - OO TECHNIQUES Use preliminary requirements to count number of: • Roles (become role classes) • Business entities (become core classes) • Graphical screens (become form classes) • Reports (become form or report definition classes) • Use cases (become form elements & commands) • High-level functions (become process or policy classes) • Rule types • etc These categories correspond to the divisions in design - class architecture. Develop a weighting for each category. 20 EE-TOOLS May 00
Engineering Business Systems in Eiffel
MANAGEMENT - HUMAN RESOURCES Ideal team configuration: Project Manager Business Analyst Consulting S/W Eng Developer
Roles
Nr
Proj. Mgt., review, some dev’t Req’ts, test cases, review Tech. mentor, req’ts, design, impl Req’ts, design, impl, test
1 1 1 3
As an example, let us profile developers on the MCS project: Typical Actual + +++ Knowledge of bus. dom. ++ ++++ Knowledge of enterprise +++++ ++ Med/large S/W dev’t exp. +++ + OO experience Eiffel allowed the gap in technical development experience to be bridged. No other language or environment makes this possible (successful compromise #1...) 21 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Software Engineering Process
22 EE-TOOLS May 00
Engineering Business Systems in Eiffel
PROCESS - OVERVIEW Important general observation: object-orientation does not replace the need for software engineering process. Elements of process remain the same as ever: • Requirements capture • Analysis and design • Implementation • Testing - unit and system • Review • Quality assurance • Change control • Deployment • Standards • Project management
typical extent of most “methodologies”
23 EE-TOOLS May 00
Engineering Business Systems in Eiffel
PROCESS - METHODOLOGY I The choice of development methodology is: • Often the object of endless (soul-) searching! • A source of unending religious debate on the internet • Often erroneously made based on tool availability, not requirements, and then set in place forever. Typical approach: • Implementation language already in place • Choose A&D methodology (agony of bubbles and arrows) • Sometimes ... choose requirements methodology (e.g. Jacobsen)
24 EE-TOOLS May 00
Engineering Business Systems in Eiffel
PROCESS - METHODOLOGY II Better approach: what are the requirements? • Seamlessness (and reversibility) • Micro-reuse - influences choice of implem. formalism • Macro-reuse - requires componentisation capability Only strictly enforce those methodological elements for which there is tool support. These considerations lead to a choice of formalism which exists at A, D, I levels, and a requirements methodology whose deliverables have traceability to the formal description of the system.
25 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Seamlessness
Requirements + formalness
+ descriptiveness
tool-supported traceability
Analysis Model abstraction level
+ classes + features
+ documentation + graphic layout
formal transformation
Design Model + classes + features
+ documentation + graphic layout
formal transformation
Implem. Model 26 EE-TOOLS May 00
Engineering Business Systems in Eiffel
METHODOLOGY - SEAMLESSNESS The idea of seamlessness is revolutionary for some developers, but in fact the challenge may be psychological as much as technical. The underlying philosophy is that the deliverables should remain at all times comprehensible and up to date. If the idea that each expression of the model (= the software) is a transform of other expressions, sophisticated models can be developed once, and leveraged many times (illustration). One consequence of seamlessness is that the “programmer” disappears! All developers will end up doing: • Some analysis • Some design • Some implementation 27 EE-TOOLS May 00
Engineering Business Systems in Eiffel
METHODOLOGY - REQUIREMENTS CAPTURE Requirements capture is absolutely essential to engineering a good system. The keys for process: • Thorough investigation • Constant user representative/developer interaction & review • Public dissemination (e.g. intranet web)! • Review • Constant update (“living document”) We will consider the structure for requirements in the technical architecture section, which concentrates on deliverables.
28 EE-TOOLS May 00
Engineering Business Systems in Eiffel
METHODOLOGY - RECOMMENDATIONS Possibilities: • Requirements + Business Object Notation (BON) + Eiffel • Requirements + UML + C++ or Java (but seamlessness difficult) • etc Recommendations: • Do not slavishly follow published methodology • Just use elements which support seamlessness and quality • Find/develop tools which support the choices • Be prepared to adapt the methodology over time
29 EE-TOOLS May 00
Engineering Business Systems in Eiffel
METHODOLOGY - EXPERIENCE Experience on MCS: • Requirements: used consultant’s proforma (requirements): •
Developed over 10 years - experience-based
•
Inspired by IEEE SRS std
•
Includes OO elements from e.g. Wirfs/Brock, Jacobsen
• A&D: adopted BON style approach •
Seamless with Eiffel implementation
•
But no tool support for object interactions - not used
• Implementation: adopted Eiffel
30 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Tools
31 EE-TOOLS May 00
Engineering Business Systems in Eiffel
IMPLEMENTATION LANGUAGE Early on in the MCS project, it was assumed that Java would be used as the main development language, based on the following assumptions: • C++ was clearly out of the question since experienced C++ developers were not available • Smalltalk was seen as unattractive due to lack of static typing, and "heavyweight" development and runtime environment • Delphi was not seriously considered because of the lack of an object database and weak general purpose libraries. Java appeared to be the ideal language, since it was claimed to be clean, and it was an emerging, “bandwagon” technology (i.e. get on or miss out....)
32 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Eiffel was added to the list of candidate development approaches based on it being: • Simple and clean enough to be understood by inexperienced developers, as well as non-developers (e.g. business analysts • Very effective at directly modelling complex domain concepts • Statically typed • ODB bindings were available • Direct support for design by contract • Large, well-tested general-purpose and specialist libraries • Supported seamlessness and reuse An investigation was undertaken into Java and Eiffel which decided in favour of Eiffel. (Report published on web/news in 1997). 33 EE-TOOLS May 00
Engineering Business Systems in Eiffel
IMPLEM. LANGUAGE - EIFFEL Summary of winning features of Eiffel: • Superior modelling capabilities - genericity, MI, DbC • Comprehensive general-purpose libraries • Suitable for inexperienced developers, and particularly for cross-disciplinary personnel • Stability - has been available since 1988
34 EE-TOOLS May 00
Engineering Business Systems in Eiffel
SOFTWARE CONFIGURATION MANAGEMENT (SCM) SCM is a critical technique in the management of any medium- to large software project. CM tool is essential in the infrastructure. What is configuration management? • Version control • Configuration control • Change control • Release control • Build support • Multiple parallel developer support The SCM tool supports changes to a software repository over time, made simultaneously by multiple developers. The following diagram illustrates the paradigm. 35 EE-TOOLS May 00
Engineering Business Systems in Eiffel
CHANGE PARADIGM
OPERATIONAL PROCESS
v 1.1
CR
Controlled Repository
File System
/ent/base
/ent/rel
automatic refresh
v 1.2
release area (RO)
all VC files CR
includes
check-in check-out
workspace overlaying
v 1.3 CR CR
!! $HOME/work $HOME/work
CR
Time 36 EE-TOOLS May 00
Engineering Business Systems in Eiffel
The golden rules: • Only logical changes (CRs) can be applied to repository • Run quality checks as part of check-in process • Development mode: baseline every time milestone • Test, Production modes: baseline after every CR MCS Experience: • Commercial tool (TrueChange) chosen & purchased, 1 licence/person • Consultant configured tool and performed minimal training General observations: • Probably the single most important tool in the project • Most CM functions supported • All changes reversible 37 EE-TOOLS May 00
Engineering Business Systems in Eiffel
• Project-wide versioning (baselining) used as a basis of release strategy (diagram below) Object-oriented observations: • Far less “central file” contention (e.g., .h files in C, C++) • Eiffel cluster = application or library or test data • Class is lowest level Configuration Item (good - maintains encapsulation) • Invaluable as means of managing change in seamless environment: don’t allow checkins until all levels have been updated (could automate this on unix) • Supports “living documentation” concept
38 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Release Strategy for 1 x Prod, 1 x Test, n x Dev Envs Release 1.1 d1.1.1
Release 2.1
d1.1.2
d2.1.1
d1.1.3
Release 1.2
d1.1.4
d1.2.1
t1.1.1
d1.2.2
t1.1.2
d1.2.3
d2.1.3
test m/c: t1.1.2 dev m/c: d1.2.3 dev m/c: d2.1.2
d2.1.4
t1.1.3
Time
d2.1.2
p1.1.1
t1.2.1
p1.1.2
t1.2.2
d2.1.5
p1.2.1
t2.1.1
p1.2.2
t2.1.2
p1.2.3
t2.1.3
prod m/c: p1.2.1 test m/c: t2.1.1
p2.1.1 p2.1.2 39
EE-TOOLS May 00
Engineering Business Systems in Eiffel
DOCUMENTATION Primary goals: • Provide a content repository which integrates information from all levels of development, supporting seamlessness • Support process: provide wide accessibility, reviewing • Encourage currency: automated tool integration Tool requirements: • Quality WP: styles, TOC, sidebars, multi-level auto paras etc • Inline diagramming, graphic import (diags must be easy!) • Dissemination mechanism, e.g. web or notes • Integrated/integratable with CASE, other tools; e.g. reverse engineered case diagrams, class interfaces • Markup or versioning for review • Can be command-line driven -> can use make to rebuild doc 40 EE-TOOLS May 00
Engineering Business Systems in Eiffel
• Directly supports process workflow MCS experience: • Authoring was painful: Aolpress, MS Word, ABC Flowcharter, Powerpoint + graphic format converter • Review: ??? (could have used HTML editor...) • Dissemination: intranet web • Integration at HTML level of Eiffel and Case output • Quality was acceptable Conclusion was that a better authoring alternative must be found next time around. Tool possibilities (non-exhaustive): • FrameMaker, disseminate in HTML, review by marking up HTML • FrameMaker, disseminate in HTML/PDF, review with PDF • LaTex solutions exist on unix • Other DTP products, e.g. Interleaf, PageMaker etc 41 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Technical Architecture
42 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ARCHITECTURE - GOALS A reminder of what we are trying to achieve in the “big picture”: • Economically viable • Quality How: • Seamless architecture • Internal (micro) reuse • Enterprise (macro) reuse • Economically extensible
43 EE-TOOLS May 00
Engineering Business Systems in Eiffel
REQUIREMENTS Keys for structure: • Comprehensive structure right from start (example) • Use traceability markers in the text • Keep in CM system, and keep updating Continual update and review is essential, because errors at the requirements level cost orders of magnitude more to rectify than errors at the design or implementation levels.
44 EE-TOOLS May 00
Engineering Business Systems in Eiffel
REQUIREMENTS - MYTH AND EXPERIENCE Some opinions (mine!): • Myth: requirements = use cases & user interface descriptions • Fact: in business systems, requirements for usage patterns and GUI change far more often than for business objects • Conclusion: the business object model (BOM) is the core
• Myth: functional (cf object) descriptions are bad • Fact: users understand functional descriptions. (So do developers, but worry that it is not OO) • Conclusion: write functional requirements as a 2nd tier of descriptive requirements, referencing 1st tier items such as BOM entities, UIDs, use cases, critical attributes etc
45 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ANALYSIS AND DESIGN Analysis and Design is about turning the requirements into a solution. Differentiating between the two is yet another area of religious argument! For people who want to differentiate: • Analysis (n.): formal expression of entities in requirements (and nothing else); formal expression of agreed requirements • Design (n.): formal expression of solution, starting from analysis model (much extra) Possible motivation for separation: since Analysis model is effectively a formalisation of agreed requirements, its change status is different - same level as requirements; it may be able to be controlled in the CM system.
46 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ANALYSIS Process for producing analysis model: • Convert requirements BOM descriptions into concrete classes • Express constraints from BOM as class invariants • Define configuration data for system, based on requirements • Find/develop beginnings of grammar for expressing business rules; define business rules The last step above is often ignored, but is the basis for producing the meta-model.
47 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN Deliverables: • System architecture (OS processes, machines etc) • Concrete class model (i.e. hard-coded) • Meta-model • Business rule language and processor The last two are optional, although not many non-trivial business systems would be without either. Traditional OO design focusses on the concrete class model, and fails to address the other two. We will explore them below.
48 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Process of design: • Introduces inheritance • Converts configuration data to meta-model • Introduces (new) design classes • Introduces genericity Process considerations: • Separation of meta-model and concrete model • Separation of framework classes and business classes • Design for use of database • Operate simultaneously in diagram and textual domains • Compile often (even totally abstract model) • Build and test representative applications early • Bottom-up for core classes (don’t care about applications) • Top-down for applications 49 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - CLASS ARCHITECTURE The class architecture in thematic terms. Application GUI Forms GUI Commands GUI Controllers
Rule scanner parser processor
xx
novice developers
xx
experienced developers
Core Business Classes Archetype DB interface Database
Application Framework
Operating System 50 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - THE CONCRETE MODEL The concrete model is the directly programmed logic and structure of the system. It relates to the meta-model and business rules as follows: • Some behaviours may be driven by the meta-model • Business rule processor attaches rules to objects at runtime, using a method-dispatcher or similar mechanism Note: the meta-model and rule processing are implemented using normal classes as well - they just model “meta-concepts”. Guidelines: • Build core classes bottom-up, ~independently of apps • Build applications top-down Example of CASE design. Example of core class (very short!). 51 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - THE META-MODEL The meta-model, or “archetype” encapsulates constraints and parameters of the system which must be dynamically determined at runtime. Such parameters are typically fairly simple, and do not change often; nevertheless, a change must not require recompilation of the system. The meta-model is easily implemented: • Implemented as group of classes whose job it is to represent configuration parameters. • In the runtime system, objects of concrete classes must have a way of referencing the archetype objects. Good reference: Fowler, Martin - Analysis Patterns.
52 EE-TOOLS May 00
Engineering Business Systems in Eiffel
META-MODEL - EXAMPLE MCS Example: investment structures. Cl
Cl = client
F
F
F
= fund
pf = portfolio pf sh sh sh sh sh
pf sh
pf sh
sh
pf
pf
pf
sh
sh
= security holding
sh
Desired runtime (instance) structure The problem to be solved: • Model desired runtime structure • Hierarchies with different orders and types must be possible 53 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Naive class model:
All relationships are modelled concretely. Problem: • What if we want to remove the FUND level? • What if we want to add a new level? 54 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Adopt meta-model approach. Firstly introduce some flexibility into the class model:
• All asset types inherit from ASSET • Generic relation holdings:LINKED_LIST[ASSET] allows any asset to have holdings of any other asset type (bad....?) To solve this, we add classes to the archetype, modelling the legal holdings hierarchy. 55 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Now add investment archetype.
56 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Investment archetype - runtime effect Archetype
Cl
Cl sub sup
F
F sub
xx = config items (can be populated from config file or db)
sup
pf
is_sup(ai:ARCH_ITEM):BOOLEAN is do Result := not is_bottom or sub = ai end
pf sub
sh
sup sh
is_sup(ah:ASSET_HOLDER):BOOLEAN is do Result := arch_item(generator).is_sup(ah.arch_item) end 57 EE-TOOLS May 00
Engineering Business Systems in Eiffel
General pattern for archetype use:
58 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - BUSINESS RULES What is a business rule? • An informal or semi-formal (e.g. legal) statement about business entities, and... • A formal statement about business objects (examples) • Modifiable online • May change frequently • May be quite complex Rule creation, modification and processing is often the focus of business systems. One area of confusion is whether business rules can be represented as assertions (pre-cond, post-cond, invariant). In fact they are generally more complex and mutable, and cannot usually afford to be hard-coded. 59 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Architecture: • Define rule grammar (example); contains syntax for referring to business objects • Express as lex/yacc spec, using e.g. GOBO gelex, geyacc (Example Lex file (for GOBO gelex), Example Yacc file (for GOBO geyacc)) • GUI rule-builder application (example screen) creates rule text strings to be stored in database • Rule evaluator application: •
Reads rules from database as STRINGs
•
Creates parse tree (form for evaluation)
•
Links each object reference to a target object
•
Calls an evaluate method in the rule tree
•
Writes the result to a report (example)
60 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ODB/RDBMS interface architecture
lex rule grammar EBNF
gelex
scanner.e
xxx.e zzz.e yyy.e
yacc
geyacc
builder.e www.e
es4
abc.exe
61 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - RDBMS INTERFACE Interfacing Eiffel system with an RDBMS may not be difficult, depending on what is needed. Make sure the requirements:
requirement
is
understood!
Possible
Requirement
Difficulty
Approach
A
RDBMS information must be migrated to new system (once)
+
write a one-time converter (may be hard-coded)
B
RDBMS is data source; OO system must be able to import from RDBMS (periodically)
++
write a periodic converter (schema driven)
C
OO system must be able to read and update the RDBMS
+++
periodic converter + SQL update
D
OO system must use the RDBMS as its primary persistence mechanism (e.g. due to enterprise database “standard”)
++++++++
live schema object/relational schema mapping & software layer 62
EE-TOOLS May 00
Engineering Business Systems in Eiffel
Most of the talk about the object/relational problem relates to D above. But many systems only need to do B or C. The architecture for B and C is: SQL
OO app w. SQL OO app OO app OO app converter
Tab-separated text files
RDBMS Relational/object schema
ODB
63 EE-TOOLS May 00
Engineering Business Systems in Eiffel
This architecture: • Allows a pure OO system • Is cheap to build, using a simple equivalence schema (Example .map file) rather than a live object/relational software layer; • Is easy to maintain (just add new .map files) • Can be built in Eiffel using CECIL to create new objects
64 EE-TOOLS May 00
Engineering Business Systems in Eiffel
DESIGN - ODB CONSIDERATIONS Two areas of design concern: • Database schema - quite simple (Example .odl schema) • Class design Using an object database impacts on the design of classes, and requires a certain amount of intelligence. This is because ODBs operate on the priniciple of reference-following to store and retrieve objects. The problem is to correctly limit the following of references during storage, so as to store the appropriate closure. In particular, care must be taken with: • Business objects are composed of prog. lang. instances • Shared objects • Aggregration and association relationships (= cascade and break-link in relational systems) 65 EE-TOOLS May 00
Engineering Business Systems in Eiffel
• Extent of deletions • How to retrieve sub-aggregations • How to implement version control • Locking sub-aggregations Example below. The correct place to implement these complex behaviours is in the database interface. They are not generally supported in basic versions of commercial products, and usually require some implementation. Develop a generic solution, and use it once (see design - class architecture). On MCS: Eiffel/Matisse binding from ISE, re-engineered by Deep Thought Informatics
66 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Aggregation and Composition in complex objects CLIENT holdings
CS_MGR
name STRING
LL first L item
name
PERSON_NAME
right SPECIAL
first_name
L
STRING STRING
item
FUND holdings
LL first L item
SPECIAL SPECIAL
name STRING right SPECIAL
L item
PORTFOLIO holdings
LL first L item
last_name
PORTFOLIO
name STRING
holdings
LL right SPECIAL
SEC_HOLDING
L item
first L item
name STRING right SPECIAL
SEC_HOLDING
LL L
aggregation association LINKED_LIST LINKABLE 67
EE-TOOLS May 00
Engineering Business Systems in Eiffel
IMPLEMENTATION AND TEST Observations: • Eiffel does own dependency checking (no make files) • No out of sync header files (cf C, C++) • Views, navigation far superior to other tools • Assertions support aids debugging. Rules of the game for assertions: • “I satisfy the pre-condition, you guarantee the postcondition” • Pre-condition violation -> my bug • Post-condition violation -> your implementation bug Result: there is no mystery of responsibility. For example, if a post-condition violation occurs in 3rd party code (ISE’s BASE perhaps) - I waste no time on determining this - I simply report the problem to the supplier. 68 EE-TOOLS May 00
Engineering Business Systems in Eiffel
With assertions, bug diagnosis is fast (maybe 10x as fast as without). How much time is spent on your project finding bugs? Categories of error caught by assertions: • Pre-conditions •
Basic parameter checks, e.g. x /= Void, not x.empty
•
Semantic checks, e.g. not holdings.has(x)
• Post-conditions •
Set routines, e.g. name = a_name, name.is_equal(a_name)
•
Semantic checks, e.g. holdings.has(new_item), implies not error_msg.empty
last_op_fail
• Invariants •
Attributes (data items) becoming Void or empty unintentionally
•
Make (creation routine) not performing correctly
The automated mechanism for catching such errors means that significant time is saved in the development process. 69 EE-TOOLS May 00
Engineering Business Systems in Eiffel
The Big Lessons
70 EE-TOOLS May 00
Engineering Business Systems in Eiffel
ENTERPRISE REUSABILITY IS POSSIBLE Enterprise reusability: the reuse of entire subsystems and systems, creating large cost savings. The keys: • Meta-data modelling: have to predict the future somewhat; the meta-model is where you avoid concrete modelling. • Clearly delineate systems and subsystems in the CM repository for easy reuse.
71 EE-TOOLS May 00
Engineering Business Systems in Eiffel
META-DATA IS ESSENTIAL FOR A BUSINESS SYSTEM Meta-data: • Models parameters of the system considered to be mutable during its operation • Contains what is normally thought of as “configuration” • Allows concrete modelling decisions to be put off until later • Is the “intelligence” repository of the system. Systems with meta-models are somewhat like the human brain: the concrete model (software) is the brain, and the meta-data corresponds to a particular set of ideas. Very powerful systems can be built whose meta-models can accept different configurations, allowing the concrete system to behave quite differently in each case. 72 EE-TOOLS May 00
Engineering Business Systems in Eiffel
CULTURAL CHANGE MUST BE MANAGED Where new ideas and methods are adopted, cultural change is inevitable. The keys to managing it include: • Identifying the costs and building them into the project plan. Types of cost: •
Training
•
Developing new procedures
•
Experimentation, prototyping
•
Making mistakes
• Not being over-ambitious for the first project • Be prepared to compromise on ideals initially
73 EE-TOOLS May 00
Engineering Business Systems in Eiffel
MIX DOMAIN AND SOFTWARE SPECIALISTS The classic problem of the wrong solution being developed by IT departments can be overcome by intimately involving domain specialists as developers, even if they are not as efficient as professional software engineers. Aim to put new developers on non-critical parts of the system. A good split is (see design - class architecture): • Experienced engineers on infrastructure (database binding, GUI framework, distribution libraries) • New developers on business class implementation, GUI forms and commands, reports Eiffel supports this by allowing interfaces to be much more precisely defined (and published) than any other formalism. Assertions also reduce the amount of time in finding bugs. 74 EE-TOOLS May 00
Engineering Business Systems in Eiffel
OBJECT DATABASES ARE VIABLE Object Databases provide seamlessness in the runtime domain, since they (nearly) eliminate the semantic gap between OOPL objects and stored objects. Cost-effective: • Schema does not have to be designed & maintained - it is a (nearly) 1:1 mapping from the programming language • Runtime licence of the Matisse database ~USD 540 • Matisse runs on a normal Pentium with SCSI discs and 96Mb RAM or more Other features: • Can be integrated with RDBMS • Support SQL or OQL natively 75 EE-TOOLS May 00
Engineering Business Systems in Eiffel
EIFFEL IS A COST-EFFECTIVE, QUALITY APPROACH Eiffel supports cost-effective software engineering in numerous ways, while maintaining a superior level of quality: Benefit Phase Semantic power Powerful formalism (genericity, MI, Simplicity Assertions Seamlessness Component support Comprehensive libraries
assertions) reduces cost of modelling - no semantic gap Learning curve is an order of magnitude less than C++ Bug diagnosis cost vastly reduced Catastrophe costs averted Avert costs of out of date Deliverables Precompiled libs, DLLs, COM wrapping, CORBA interface
Design
Deployment, Reuse
Existing libraries limit development costs to application
Design, Implem
Training Implem Maintenance Design, Maint
76 EE-TOOLS May 00
Engineering Business Systems in Eiffel
The numerous libraries include: • BASE - data structures, kernel etc • TIME - date/time • WEB - basic replacement for CGI interface • NET - object oriented RPC over sockets (simple CORBA) • LEX/PARSE - lexical analysis and parsing • MATH - calculus, matrices and vectors • STORE - ODBC, Sybase, Oracle, Matisse and other DB i/f • WEL - wrapper for Windows MFC • VISION - portable high-level GUI library
77 EE-TOOLS May 00
Engineering Business Systems in Eiffel
MAINTAIN “LIVING” DOCUMENTATION The old way: the waterfall model: • Semantic gap between formal/semi-formal deliverables (e.g. Rumbaugh mapped to C++) • The cost: high cost maintenance, low extensibility Living documentation: part of the seamless approach • Needs configuration management support • Needs tools supporting seamlessness between formal/semiformal deliverables, e.g. Eiffel & BON or Eiffel & UML • Create a bucket for each kind of information at the start
78 EE-TOOLS May 00
Engineering Business Systems in Eiffel
The Typical Approach
Req’ts
abstraction level
v1.0
ad hoc
Reqt’s
Req’ts
v1.1 ?
Design
Design
v1.0
v1.1
Design
too hard!! ?
the remaining legacy: source code
Implem
Implem
Implem
Implem
Implem
Implem
v1.0
v1.1
v1.2
v2.0
v2.1
v2.2
time
79 EE-TOOLS May 00
Engineering Business Systems in Eiffel
abstraction level
“Living Documentation” Approach
Req’ts
Req’ts
Req’ts
Req’ts
v1.0
v1.1
v1.2
v2.0
traceability Design
Design
Design
Design
Design
v1.0
v1.1
v1.2
v1.3
v1.1
the continuing legacy: all deliverables
seamlessness Implem
Implem
Implem
Implem
Implem
v1.0
v1.1
v1.2
v2.0
v2.1
time
80 EE-TOOLS May 00
Engineering Business Systems in Eiffel
REFERENCES 1. Fowler, Martin - Analysis Patterns Addison Wesley, 1997 2. Meyer, Bertrand - Eiffel The Language Prentice Hall 1992 3. Meyer, Bertrand - Object-oriented Software Construction, 2nd Ed. Prentice Hall 1997 4. Walden, Kim and Nerson, Jean-Marc - Seamless Object-oriented Software Architecture. Prentice Hall 1994
81 EE-TOOLS May 00
Engineering Business Systems in Eiffel
Example .map file ;cur_simple_assets relational to OO Map ; ;----------------- schema map example file format --------------------; ; CLASS class_name ; ICR_NAME icr_file_name ; ; SUBTYPED ; ; ATTR targ_attr set_methodtarget_class ; REL_FWD_1:1 targ_attr set_methodsucc_class ; REL_REV pred_attr pred_class ; ; REL_FWD_1:N targ_attr add_methoddel_method succ_class ; ;---------------------------------------------------------------------; CLASS SIMPLE_ASSET ; ATTR external_key set_external_key REL_REV holdings PORTFOLIO ATTR security_ref set_security_ref ATTR name set_name ATTR quantity set_quantity ATTR total_quantity_data set_total_quantity REL_FWD_1:1 market_sector set_market_sector MARKET_SECTOR REL_FWD_1:1 stored_position set_stored_position SIMPLE_POSITION
Page 1
Example .odl schema /***********************************************/ /* */ /* MANDATE Schema */ /* */ /***********************************************/
/********** Default Eiffel Schema for matisse **********/ /* ---------- */ /* Attributes */ /* ---------- */ mt_attribute mt_attribute mt_attribute mt_attribute mt_attribute mt_attribute mt_attribute
MtS32 object_comparison=0; MtS32 upper=0; MtS32 lower=0; MtS32 eif_count=0; MtS32 eif_size=0; Array
flags; Array oids;
/* -------------- */ /* Relationships */ /* -------------- */ mt_relationship List area[0,-1] inverse area_of; mt_relationship {SPECIAL,ARRAY} area_of inverse area; /* -------- */ /* Classes */ /* -------- */ interface ANY ():persistent { }; interface ARRAY:ANY ():persistent { mt_attribute object_comparison; mt_attribute upper; mt_attribute lower; mt_relationship area; }; interface SPECIAL:ANY ():persistent { mt_attribute eif_size; mt_attribute eif_count; mt_relationship area; }; interface IDF_TABLE:ANY ():persistent { mt_attribute flags; mt_attribute oids; };
Page 2
mt_attribute Long stored_table_id; interface EXT_STORABLE:ANY ():persistent { mt_attribute stored_table_id; };
/* ------- COMPOSED_OBJECT ------------*/ mt_relationship COMPOSED_OBJECT agg_parent inverse agg_parent_of; mt_relationship List agg_parent_of[0,-1] inverse agg_parent; interface COMPOSED_OBJECT:EXT_STORABLE ():persistent { mt_relationship agg_parent; }; /* ------- LINKABLE ------------*/ mt_relationship ANY item inverse item_of; mt_relationship List item_of inverse item; mt_relationship List right[0,-1] inverse right_of; mt_relationship LINKABLE right_of inverse right; interface LINKABLE:ANY ():persistent { mt_relationship item; mt_relationship right; };
/* ------- LINKED_LIST ------------*/ mt_relationship List active[0,-1] inverse active_of; mt_relationship ANY active_of inverse active; mt_relationship List first_element[0,-1] inverse first_element_of; mt_relationship ANY first_element_of inverse first_element; mt_attribute MtS32 after=0; mt_attribute MtS32 before=0; mt_attribute MtS32 count=0; interface LINKED_LIST:ANY ():persistent { mt_relationship active; mt_attribute after; mt_attribute before; mt_attribute count; mt_relationship first_element; mt_attribute object_comparison; };
Page 3
/* ------- LINKED_SET ------------*/ interface LINKED_SET:LINKED_LIST ():persistent { };
/* ------- ARRAYED_LIST ------------*/ mt_attribute MtS32 index=0; interface ARRAYED_LIST:ARRAY ():persistent { mt_attribute count; mt_attribute index; }; /* ------- MT_HASH_TABLE ------------*/ mt_attribute MtS32 capacity=0; mt_attribute MtS32 control=0; mt_attribute MtS32 has_default=0; mt_attribute Array<String> hash_keys; //mt_attribute Array deleted_marks; //mt_attribute Array deleted_marks; mt_attribute Array deleted_marks; mt_relationship ARRAY content inverse content_of; mt_relationship ANY content_of inverse content; interface MT_HASH_TABLE:ANY ():persistent { mt_attribute capacity; mt_attribute control; mt_attribute count; mt_attribute object_comparison; mt_attribute has_default; mt_relationship content; mt_attribute hash_keys; mt_attribute deleted_marks; }; /* ------- TIME, DATE --------*/ mt_attribute String timezone; interface SYSTEM_TIME:ANY ():persistent { mt_attribute timezone; }; interface SIMPLE_TIMESTAMP:ANY ():persistent { }; mt_attribute MtS32 milliseconds; interface TIME:SIMPLE_TIMESTAMP ():persistent {
Page 4
mt_attribute milliseconds; }; mt_attribute MtS32 absolute_days; interface DATE:SIMPLE_TIMESTAMP ():persistent { mt_attribute absolute_days; }; interface TIMESTAMP:DATE, TIME ():persistent { }; /**************************************/ /**************************************/ /** **/ /** MANDATE SCHEMA **/ /** **/ /**************************************/ /**************************************/
/**************************************************/ /* */ /* BASIC */ /* */ /**************************************************/ /* -------------- MONEY ---------------- */ mt_attribute String currency; mt_attribute MtFloat value; interface MONEY:ANY ():persistent { mt_attribute currency; mt_attribute value; }; /* -------------- FINANCIAL_VALUE ---------------- */ mt_relationship MONEY confirmed_only inverse confirmed_only_of; mt_relationship ANY confirmed_only_of inverse confirmed_only; mt_relationship MONEY unconfirmed_only inverse unconfirmed_only_of; mt_relationship ANY unconfirmed_only_of inverse unconfirmed_only; mt_relationship MONEY settled_only inverse settled_only_of; mt_relationship ANY settled_only_of inverse settled_only; interface FINANCIAL_VALUE:ANY ():persistent { mt_relationship confirmed_only; mt_relationship unconfirmed_only; mt_relationship settled_only; }; /**************************************************/ /* */
Page 5
/* REP_ITEMS */ /* */ /**************************************************/ /* -------------- REP_ITEM ---------------- */ mt_attribute MtS32 dt_code; mt_attribute String<32> stored_key; interface REP_ITEM:COMPOSED_OBJECT ():persistent { mt_attribute dt_code; mt_attribute String external_key; mt_attribute stored_key; mt_attribute String stored_to_string; mt_attribute String uname; mt_attribute String name; mt_index stored_key criteria {stored_key 32 MTASCEND}; }; mt_attribute String rep_clnt_name; interface REP_ITEM_REF:ANY ():persistent { mt_attribute stored_key; mt_attribute rep_clnt_name; };
/* -------------- INVESTMENT_SECTOR ---------------- */ mt_attribute MtS32 is_marketed=0; interface INVESTMENT_SECTOR:REP_ITEM ():persistent { mt_attribute is_marketed; }; /* -------------- BASE_SECTOR ---------------- */ interface BASE_SECTOR:INVESTMENT_SECTOR ():persistent { }; /* -------------- COMPOSITE_SECTOR ---------------- */ mt_relationship ARRAYED_LIST composition inverse composition_of; mt_relationship COMPOSITE_SECTOR composition_of inverse composition; interface COMPOSITE_SECTOR:INVESTMENT_SECTOR ():persistent { mt_relationship composition; };
/* -------------- INVESTMENT_VEHICLE ---------------- */ interface INVESTMENT_VEHICLE:REP_ITEM ():persistent { };
Page 6
/* -------------- MARKET_SECTOR ---------------- */ interface MARKET_SECTOR:REP_ITEM ():persistent { }; /* -------------- ASSET_ATTR ---------------- */ interface ASSET_ATTR:REP_ITEM ():persistent { }; /* -------------- CASH_VALUE ---------------- */ mt_relationship FINANCIAL_VALUE exposure inverse exposure_of; mt_relationship CASH_VALUE exposure_of inverse exposure; mt_relationship FINANCIAL_VALUE market_value inverse market_value_of; mt_relationship CASH_VALUE market_value_of inverse market_value; interface CASH_VALUE:ANY ():persistent { mt_relationship exposure; mt_relationship market_value; }; /* -------------- CASH_POOL ---------------- */ mt_relationship FINANCIAL_VALUE dom_exposure inverse dom_exposure_of; mt_relationship CASH_POOL dom_exposure_of inverse dom_exposure; mt_relationship FINANCIAL_VALUE int_exposure inverse int_exposure_of; mt_relationship CASH_POOL int_exposure_of inverse int_exposure; mt_relationship FINANCIAL_VALUE dom_market_value inverse dom_market_value_of; mt_relationship CASH_POOL dom_market_value_of inverse dom_market_value; mt_relationship FINANCIAL_VALUE int_market_value inverse int_market_value_of; mt_relationship CASH_POOL int_market_value_of inverse int_market_value; /* List<> and [0,1] is used since not all CASH_POOL objects have an ISSUER */ mt_relationship List issuer_ref[0,1] inverse issuer_ref_of; mt_relationship List issuer_ref_of[0,-1] inverse issuer_ref; interface CASH_POOL:REP_ITEM ():persistent { mt_relationship dom_exposure; mt_relationship int_exposure; mt_relationship dom_market_value; mt_relationship int_market_value; mt_relationship issuer_ref; }; /* -------------- CASH ---------------- */ mt_relationship LINKED_LIST cash_pool inverse cash_pool_of; mt_relationship CASH cash_pool_of inverse cash_pool; mt_relationship CASH_VALUE dom_income_due inverse dom_income_due_of; mt_relationship CASH dom_income_due_of inverse dom_income_due;
Page 7
mt_relationship CASH_VALUE int_income_due inverse int_income_due_of; mt_relationship CASH int_income_due_of inverse int_income_due; mt_relationship CASH_VALUE dom_outstand_stlmnts inverse dom_outstand_stlmnts_of; mt_relationship CASH dom_outstand_stlmnts_of inverse dom_outstand_stlmnts; mt_relationship CASH_VALUE int_outstand_stlmnts inverse int_outstand_stlmnts_of; mt_relationship CASH int_outstand_stlmnts_of inverse int_outstand_stlmnts; interface CASH:REP_ITEM ():persistent { mt_relationship cash_pool; mt_relationship dom_income_due; mt_relationship int_income_due; mt_relationship dom_outstand_stlmnts; mt_relationship int_outstand_stlmnts; }; /* -------------- SIMPLE_LIQUIDITY ---------------- */ mt_relationship FINANCIAL_VALUE domestic_short_dated inverse domestic_short_dated_of; mt_relationship SIMPLE_LIQUIDITY domestic_short_dated_of inverse domestic_short_dated; mt_relationship FINANCIAL_VALUE fi_6_to_12_mth_to_maturity inverse fi_6_to_12_mth_to_maturity_of; mt_relationship SIMPLE_LIQUIDITY fi_6_to_12_mth_to_maturity_of inverse fi_6_to_12_mth_to_maturity; mt_relationship FINANCIAL_VALUE fi_lt_6m_maturity inverse fi_lt_6m_maturity_of; mt_relationship SIMPLE_LIQUIDITY fi_lt_6m_maturity_of inverse fi_lt_6m_maturity; mt_relationship FINANCIAL_VALUE domestic_drv_margins inverse domestic_drv_margins_of; mt_relationship SIMPLE_LIQUIDITY domestic_drv_margins_of inverse domestic_drv_margins; mt_relationship FINANCIAL_VALUE int_short_dated inverse int_short_dated_of; mt_relationship SIMPLE_LIQUIDITY int_short_dated_of inverse int_short_dated; mt_relationship FINANCIAL_VALUE int_drv_margins inverse int_drv_margins_of; mt_relationship SIMPLE_LIQUIDITY int_drv_margins_of inverse int_drv_margins; mt_relationship FINANCIAL_VALUE domestic_value inverse domestic_value_of; mt_relationship SIMPLE_LIQUIDITY domestic_value_of inverse domestic_value; mt_relationship FINANCIAL_VALUE international_value inverse international_value_of; mt_relationship SIMPLE_LIQUIDITY international_value_of inverse international_value; mt_relationship FINANCIAL_VALUE total inverse total_of; mt_relationship SIMPLE_LIQUIDITY total_of inverse total;
Page 8
mt_relationship FINANCIAL_VALUE futures_exposure inverse futures_exposure_of; mt_relationship SIMPLE_LIQUIDITY futures_exposure_of inverse futures_exposure; mt_relationship FINANCIAL_VALUE options_exposure inverse options_exposure_of; mt_relationship SIMPLE_LIQUIDITY options_exposure_of inverse options_exposure; mt_relationship FINANCIAL_VALUE adjusted inverse adjusted_of; mt_relationship SIMPLE_LIQUIDITY adjusted_of inverse adjusted;
interface SIMPLE_LIQUIDITY:REP_ITEM ():persistent { mt_relationship domestic_short_dated; mt_relationship fi_6_to_12_mth_to_maturity; mt_relationship fi_lt_6m_maturity; mt_relationship domestic_drv_margins; mt_relationship int_short_dated; mt_relationship int_drv_margins; mt_relationship domestic_value; mt_relationship international_value; mt_relationship total; mt_relationship futures_exposure; mt_relationship options_exposure; mt_relationship adjusted; }; /* -------------- SIMPLE_FUNDS_UNDER_MGT ---------------- */ mt_relationship FINANCIAL_VALUE funds_under_mgmt inverse funds_under_mgmt_of; mt_relationship SIMPLE_FUNDS_UNDER_MGT funds_under_mgmt_of inverse funds_under_mgmt; interface SIMPLE_FUNDS_UNDER_MGT:REP_ITEM ():persistent { mt_relationship funds_under_mgmt; };
/**************************************************/ /* */ /* INFO_ITEMs */ /* */ /**************************************************/ /* -------------- INFO_ITEM ---------------- */ mt_relationship TIMESTAMP last_changed inverse last_changed_of; mt_relationship ANY last_changed_of inverse last_changed; interface INFO_ITEM:REP_ITEM ():persistent { mt_attribute Long status;
Page 9
mt_relationship last_changed; };
/* -------------- CLIENT_SVC_MGR_GRP ---------------- */ mt_relationship LINKED_SET svc_mgrs inverse svc_mgrs_of; mt_relationship ANY svc_mgrs_of inverse svc_mgrs; interface CLIENT_SVC_MGR_GRP:INFO_ITEM ():persistent { mt_relationship svc_mgrs; }; /* -------------- CLIENT_SVC_MGR ---------------- */ mt_relationship LINKED_SET mandate_refs inverse mandate_refs_of; mt_relationship CLIENT_SVC_MGR mandate_refs_of inverse mandate_refs; mt_relationship CLIENT_SVC_MGR_GRP svc_grp inverse svc_grp_of; mt_relationship List svc_grp_of[0,-1] inverse svc_grp; interface CLIENT_SVC_MGR:INFO_ITEM ():persistent { mt_relationship mandate_refs; mt_relationship svc_grp; }; /* -------------- PORTFOLIO_MGR ---------------- */ mt_relationship LINKED_SET portfolio_refs inverse portfolio_refs_of; mt_relationship PORTFOLIO_MGR portfolio_refs_of inverse portfolio_refs; interface PORTFOLIO_MGR:INFO_ITEM ():persistent { mt_relationship portfolio_refs; };
/* -------------- SIMPLE_POSITION ---------------- */ mt_relationship FINANCIAL_VALUE book_value_data inverse book_value_data_of; mt_relationship SIMPLE_POSITION book_value_data_of inverse book_value_data; mt_relationship FINANCIAL_VALUE exposure_data inverse exposure_data_of; mt_relationship SIMPLE_POSITION exposure_data_of inverse exposure_data; mt_relationship FINANCIAL_VALUE market_value_data inverse market_value_data_of; mt_relationship SIMPLE_POSITION market_value_data_of inverse market_value_data; mt_relationship List target [0,1] inverse target_of; mt_relationship SIMPLE_POSITION target_of inverse target; interface SIMPLE_POSITION:INFO_ITEM ():persistent { mt_relationship book_value_data; mt_relationship exposure_data; mt_relationship market_value_data; mt_relationship target; };
Page 10
/* -------------- COMPLIANCE_RULE ---------------- */ interface COMPLIANCE_RULE:INFO_ITEM ():persistent { };
/**************************************************/ /* */ /* ASSETs */ /* */ /**************************************************/ /* -------------- ASSET ---------------- */ mt_relationship REP_ITEM_REF holder_ref inverse holder_ref_of; mt_relationship ASSET holder_ref_of inverse holder_ref; interface ASSET:INFO_ITEM ():persistent { mt_relationship holder_ref; };
/* -------------- ASSET_HOLDER ---------------- */ mt_relationship LINKED_LIST allocations inverse allocations_of; mt_relationship ASSET_HOLDER allocations_of inverse allocations; mt_relationship LINKED_LIST holdings inverse holdings_of; mt_relationship ASSET_HOLDER holdings_of inverse holdings; mt_relationship LINKED_LIST cash_holdings inverse cash_holdings_of; mt_relationship ASSET_HOLDER cash_holdings_of inverse cash_holdings; interface ASSET_HOLDER:ASSET ():persistent { mt_relationship allocations; mt_relationship cash_holdings; mt_relationship holdings; };
/* -------------- CLIENT ---------------- */ interface CLIENT:ASSET_HOLDER ():persistent { };
/* -------------- MANDATE ---------------- */ mt_relationship CLIENT_SVC_MGR svc_mgr inverse svc_mgr_of; mt_relationship List<MANDATE> svc_mgr_of[0,-1] inverse svc_mgr; interface MANDATE:ASSET_HOLDER ():persistent { // mt_relationship details; mt_relationship svc_mgr; };
Page 11
/* -------------- INVESTMENT ---------------- */ mt_relationship INVESTMENT_SECTOR sector inverse sector_of; mt_relationship List sector_of[0,-1] inverse sector; mt_relationship INVESTMENT_VEHICLE vehicle inverse vehicle_of; mt_relationship List vehicle_of[0,-1] inverse vehicle; interface INVESTMENT:ASSET_HOLDER ():persistent { mt_relationship sector; mt_relationship vehicle; };
/* -------------- NON_UNITISED_INVESTMENT ---------------- */ interface NON_UNITISED_INVESTMENT:INVESTMENT ():persistent { };
/* -------------- UNITISED_INVESTMENT ---------------- */ interface UNITISED_INVESTMENT:INVESTMENT ():persistent { }; /* -------------- BASE_SECTOR_ASSETS ---------------- */ interface BASE_SECTOR_ASSETS:ASSET_HOLDER ():persistent { mt_relationship sector; };
/* -------------- PORTFOLIO ---------------- */ mt_relationship BASE_SECTOR asset_class inverse asset_class_of; mt_relationship List asset_class_of[0,-1] inverse asset_class; mt_relationship PORTFOLIO_MGR manager inverse manager_of; mt_relationship List manager_of[0,-1] inverse manager; mt_relationship SIMPLE_FUNDS_UNDER_MGT stored_fum inverse stored_fum_of; mt_relationship PORTFOLIO stored_fum_of inverse stored_fum; mt_relationship SIMPLE_LIQUIDITY stored_liquidity inverse stored_liquidity_of; mt_relationship PORTFOLIO stored_liquidity_of inverse stored_liquidity; interface PORTFOLIO:ASSET_HOLDER ():persistent { mt_relationship asset_class; mt_relationship manager; mt_relationship stored_fum; mt_relationship stored_liquidity; };
/* -------------- SIMPLE_ASSET ---------------- */
Page 12
mt_attribute MtS32 confirmed_quantity_data=0; mt_attribute MtS32 total_quantity_data=0; mt_relationship MARKET_SECTOR market_sector inverse market_sector_of; mt_relationship List<SIMPLE_ASSET> market_sector_of[0,-1] inverse market_sector; mt_relationship REP_ITEM_REF security_ref inverse security_ref_of; mt_relationship List<SIMPLE_ASSET> security_ref_of[0,-1] inverse security_ref; mt_relationship SIMPLE_POSITION stored_position inverse stored_position_of; mt_relationship List<SIMPLE_ASSET> stored_position_of[0,-1] inverse stored_position; interface SIMPLE_ASSET:ASSET ():persistent { mt_attribute confirmed_quantity_data; mt_attribute total_quantity_data; mt_relationship market_sector; mt_relationship security_ref; mt_relationship stored_position; };
Page 13
Example Lex file (for GOBO gelex) %{ indexing description: "Rule Scanner" author: "Andrew Perry, THomas Beale" keywords: "mandate, rule" revision: "" requirements: "Section 7 Mandate Rule" class RULE_SCANNER inherit YY_COMPRESSED_SCANNER_SKELETON rename make as make_compressed_scanner_skeleton, reset as reset_compressed_scanner_skeleton end RULE_TOKENS export {NONE} all end ARGUMENTS export {NONE} all end UT_CHARACTER_CODES export {NONE} all end KL_SHARED_INTEGER_ROUTINES KL_SHARED_INPUT_STREAM_ROUTINES KL_SHARED_STRING_ROUTINES KL_SHARED_PLATFORM KL_SHARED_EXCEPTIONS creation make %} %option nodefault outfile="rule_scanner.e" %% --/* Separators */ \n+ [ \t\r]+
eif_lineno := eif_lineno + text_count ;
--/* Eiffel-style comments */
Page 14
"--".*\n[ \t\r]* eif_lineno := eif_lineno + 1 "--".* ;
--/*
Eiffel symbols */
"+" "-" "*" "/" "^"
{ last_token := Plus_code; last_value := text } { last_token := Minus_code; last_value := text } { last_token := Star_code; last_value := text } { last_token := Slash_code; last_value := text } { last_token := Caret_code; last_value := text }
"=" "/=" ">" ">=" "<" "<="
{ last_token := Equal_code; last_value := text } { last_token := E_NE; last_value := text } { last_token := Greater_than_code; last_value := text } { last_token := E_GE; last_value := text } { last_token := Less_than_code; last_value := text } { last_token := E_LE; last_value := text }
"." ";" "," "(" ")" "[" "]" "{" "}" "$" "%"
last_token := Dot_code last_token := Semicolon_code last_token := Comma_code last_token := Left_parenthesis_code last_token := Right_parenthesis_code last_token := Left_bracket_code last_token := Right_bracket_code last_token := Left_brace_code last_token := Right_brace_code last_token := Dollar_code last_token := Percent_code
--/* Reserved words */ [aA][nN][dD] { last_token := E_AND; last_value := text } [fF][aA][lL][sS][eE] { last_token := E_FALSE; last_value := text } [gG][rR][oO][uU][pP][bB][yY] last_token := E_GROUPBY [iI][nN][cC][lL][uU][dD][eE]last_token := E_INCLUDE [eE][xX][cC][lL][uU][dD][eE]last_token := E_EXCLUDE [fF][iI][_][iI][nN][dD][eE][xX] last_token := E_FI_INDEX [eE][qQ][_][iI][nN][dD][eE][xX] last_token := E_EQ_INDEX [lL][iI][qQ][uU][iI][dD][iI][tT][yY]last_token := E_LIQUIDITY [nN][oO][tT] { last_token := E_NOT; last_value := text } [oO][rR] { last_token := E_OR; last_value := text } [tT][rR][uU][eE] { last_token := E_TRUE; last_value := text }
--/* identifiers */ [a-zA-Z][a-zA-Z0-9_-]*{ last_token := E_IDENTIFIER last_value := text }
\"[^\n"]*\"
--/* Eiffel strings */ { last_token := E_STRING last_value := text_substring (2, text_count - 1) }
Page 15
--/* Eiffel integers */ [0-9]+
{ last_token := E_INTEGER last_value := text }
[0-9]{1,3}(,[0-9]{3})+
{ last_token := E_INTEGER str_ := text nb_ := text_count from i_ := 1 until i_ > nb_ loop char_ := str_.item (i_) -- if char_ /= ’,’ then eif_buffer.append_character (char_) -- end i_ := i_ + 1 end last_value := clone(eif_buffer) eif_buffer.wipe_out } last_token := E_INTERR-- Catch-all rule (no backing up)
[0-9]+
--/* Eiffel reals */ --/* non-separated */ [0-9]+\./[^.0-9] | [0-9]+\.[0-9]*[eE][+-]?[0-9]+| [0-9]*\.[0-9]+([eE][+-]?[0-9]+)?{ last_token := E_REAL last_value := text } --/* comma-separated 000,000,000 style with optional E-format */ [0-9]{1,3}(,[0-9]{3})+\.[0-9]+ | [0-9]{1,3}(,[0-9]{3})*\.([0-9]{1,3}(,[0-9]{3})*)?[eE][+-]?[0-9]{1,3}(,[0-9]{3})*| ([0-9]{1,3}(,[0-9]{3})*)?\.[0-9]{1,3}(,[0-9]{3})*([eE][+-]?[0-9]{1,3}(,[0-9]{3})*)?{ last_token := E_REAL str_ := text nb_ := text_count from i_ := 1 until i_ > nb_ loop char_ := str_.item (i_) -- if char_ /= ’,’ then eif_buffer.append_character (char_) -- end i_ := i_ + 1 end last_value := clone(eif_buffer) eif_buffer.wipe_out } [0-9,]+/\. | [0-9,]+\.[0-9]*[eE][+-]?[0-9]*| [0-9]*\.[0-9]+([eE][+-]?[0-9]*)?{-- Catch-all rules (no backing up) last_token := E_REALERR }
<<EOF>>
terminate
Page 16
.
last_token := E_UNKNOWN
%% feature {NONE} -- Local variables i_, nb_: INTEGER char_: CHARACTER str_: STRING code_: INTEGER feature {NONE} -- Initialization make is -- Create a new scanner. do make_compressed_scanner_skeleton eif_buffer := string_.make (Init_buffer_size) eif_lineno := 1 end feature -- Initialization reset is -- Reset scanner before scanning next input. do reset_compressed_scanner_skeleton eif_lineno := 1 eif_buffer.wipe_out end feature -- Access last_value: STRING -- Semantic value to be passed to the parser eif_buffer: STRING -- Buffer for lexial tokens eif_lineno: INTEGER -- Current line number is_operator: BOOLEAN -- Parsing an operator declaration? feature {NONE} -- Processing process_operator (op: INTEGER): INTEGER is -- Process current token as operator ‘op’ or as -- an Eiffel string depending on the context require text_count_large_enough: text_count > 2 do if is_operator then Result := op else Result := E_STRING last_value := text_substring (2, text_count - 1) end end feature {NONE} -- Constants
Page 17
Init_buffer_size: INTEGER is 256 -- Initial size for ‘eif_buffer’ invariant eif_buffer_not_void: eif_buffer /= Void end
Page 18
Example Yacc file (for GOBO geyacc) %{ indexing description: "Compliance rule parser - builds COMPLIANCE_RULE structure of rule parsed" author: "Thomas Beale" revision: "%%A%%" source: "%%P%%" class RULE_BUILDER inherit YY_PARSER_SKELETON [ANY] rename make as make_parser_skeleton redefine report_error end RULE_SCANNER rename make as make_eiffel_scanner end NUMERIC_CODES export {NONE} all end OPERATORS export {NONE} all end BUSINESS_INFO_TYPES export {NONE} all end creation make %} %token E_CHARACTER E_INTEGER E_REAL E_IDENTIFIER E_STRING %token E_CHARERR E_INTERR E_REALERR E_STRERR E_UNKNOWN E_NOMEMORY %token E_FI_INDEX E_EQ_INDEX E_LIQUIDITY E_GROUPBY %token E_TRUE E_FALSE %token E_EXCLUDE E_INCLUDE %token ’$’ %token ’%’ %left E_OR %left E_AND %right E_NOT %left ’=’ E_NE ’<’ ’>’ E_LE E_GE %left ’+’ ’-’ %left ’*’ ’/’ %right ’^’
Page 19
%% input: -- /* empty */ | input rule ; rule:
’;’ | logical_term ’;’ | error ’;’ ;
{ output := "Empty rule" } { output := "Valid rule" } { output := "Error"; recover }
logical_term: E_NOT logical_term{ -- not yet implemented } | logical_term log_op relational_term { -- validity: anything is ok, since it will be turned into a scalar reduce_vector_result(False) lt1 ?= $1 str ?= $2 !!bool_term.make(lt1, rel_term, operator_from_string(str)) cr.set_rule_tree_root(bool_term) $$ := bool_term } | relational_term { cr.set_rule_tree_root(rel_term); $$ := rel_term } | ’(’ logical_term ’)’ { -- not yet implemented } ; relational_term: quantity_item rel_op quantity_item{ -- validity: anything but V * V is ok if not lhs_is_vector and rhs_is_vector then report_error("illegal construct: scalar rel_op vector") raise_error else -- set result type to be vector or scalar if lhs_is_vector or rhs_is_vector then reduce_vector_result(True) else reduce_vector_result(False) end qi1 ?= $1 qi2 ?= $3 str ?= $2 !!rel_term.make(qi1, qi2, operator_from_string(str)) $$ := rel_term end } ; quantity_item: quantity { $$ := $1 } | quantity_item ’*’ quantity_item{ -- validity: anything but V * V is ok if lhs_is_vector and rhs_is_vector then report_error("illegal construct: cannot multiply two vectors") raise_error else -- set result type to be vector or scalar if lhs_is_vector or rhs_is_vector then
Page 20
reduce_vector_result(True) else reduce_vector_result(False) end qi1 ?= $1 qi2 ?= $3 str ?= $2 !!qty_term.make(qi1, qi2, operator_from_string(str)); $$ := qty_term; end } | quantity_item ’/’ quantity_item{ -- validity: RHS must be scalar if rhs_is_vector then report_error("illegal construct: cannot divide-by vector") raise_error else -- set result type to be vector or scalar if lhs_is_vector then reduce_vector_result(True) else reduce_vector_result(False) end qi1 ?= $1 qi2 ?= $3 str ?= $2 !!qty_term.make(qi1, qi2, operator_from_string(str)); $$ := qty_term; end } | quantity_item ’+’ quantity_item{ -- validity: RHS cannot be vector if rhs_is_vector then report_error("illegal construct: right-hand side cannot be vector") raise_error else -- set result type to be vector or scalar if lhs_is_vector or rhs_is_vector then reduce_vector_result(True) else reduce_vector_result(False) end
qi1 ?= $1 qi2 ?= $3 str ?= $2 !!qty_term.make(qi1, qi2, operator_from_string(str)); $$ := qty_term; end } | quantity_item ’-’ quantity_item{ -- validity: RHS cannot be vector if rhs_is_vector then report_error("illegal construct: right-hand side cannot be vector") raise_error else -- set result type to be vector or scalar
Page 21
if lhs_is_vector or rhs_is_vector then reduce_vector_result(True) else reduce_vector_result(False) end qi1 ?= $1 qi2 ?= $3 str ?= $2 !!qty_term.make(qi1, qi2, operator_from_string(str)); $$ := qty_term; end } | ’(’ quantity_item ’)’ ;
{ $$ := $2 }
quantity: identifier filter group_by{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_status(feat_sts) f ?= $2; bi.set_filter(f); bi.set_feature_type(Group_by_feature_type) str ?= $3; bi.set_group_by(str) bi.set_group_by_feature(group_by_feat) if group_by_feat.is_equal("for_each") then vector_result.extend(True) else vector_result.extend(False) end $$ := bi; } | identifier filter
{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_status(feat_sts) bi.set_feature_type(Position_feature_type) f ?= $2; bi.set_filter(f); $$ := bi; vector_result.extend(False) }
| identifier group_by
{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_status(feat_sts) bi.set_feature_type(Group_by_feature_type) str ?= $2; bi.set_group_by(str) bi.set_group_by_feature(group_by_feat) if group_by_feat.is_equal("for_each") then vector_result.extend(True) else vector_result.extend(False) end $$ := bi; }
| identifier
{ !!bi.make; str ?= $1; bi.set_feature_name(str)
Page 22
bi.set_feature_status(feat_sts) bi.set_feature_type(Position_feature_type) $$ := bi; vector_result.extend(False) } | fi_index
{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_type(FI_index_feature_type) $$ := bi; vector_result.extend(False) }
| eq_index
{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_type(EQ_index_feature_type) $$ := bi; vector_result.extend(True) }
| eq_index group_by
{ !!bi.make; str ?= $1; bi.set_feature_name(str) bi.set_feature_type(EQ_index_feature_type) $$ := bi;
if not is_aggregate then str ?= $2; bi.set_group_by(str) else report_error("eq_index cannot have aggregate operator") raise_error end vector_result.extend(True) } | numeric_constant
{ !!rc.make; str ?= $1; str.prune_all(’,’); rc.set_value_code(numeric_code); rc.set_value(str.to_double); $$ := rc vector_result.extend(False) }
; fi_index: E_FI_INDEX ’(’ manifest_string ’)’ { $$ := $3 } eq_index: E_EQ_INDEX ’(’ manifest_string ’)’ { $$ := $3 } group_by: E_GROUPBY E_IDENTIFIER ’.’ E_IDENTIFIER{ is_aggregate := True; group_by_feat := $4.out; $$ := $2; } | E_GROUPBY E_IDENTIFIER
{ is_aggregate := False; $$ := $2; }
;
Page 23
identifier: E_LIQUIDITY ’.’ E_IDENTIFIER ’.’ E_IDENTIFIER { $$ := string_.concatenate(<<"liquidity.", $3.out>>); feat_sts := $5.out; } | E_IDENTIFIER ’.’ E_IDENTIFIER { $$ := $1; feat_sts := $3.out; } ;
filter: ’[’ sub_filters ’]’
{ !!f.make; from sfs.start until sfs.off loop f.extend(sfs.item) sfs.forth end $$ := f; !!sfs.make(0) }
; sub_filters: sub_filter { sf ?= $1; sfs.extend(sf); $$ := sfs; } | sub_filters ’,’ sub_filter{ sf ?= $3; sfs.extend(sf); $$ := sfs; } ; sub_filter: ’(’ sub_filter_items ’)’{ !!sf.make; from sfis.start until sfis.off loop sf.extend(sfis.item) sfis.forth end $$ := sf !!sfis.make(0) } ; sub_filter_items: sub_filter_item{ sfi ?= $1; sfis.extend(sfi); $$ := sfis; } | sub_filter_items ’,’ sub_filter_item { sfi ?= $3; sfis.extend(sfi); $$ := sfis; } ; sub_filter_item: E_INCLUDE E_IDENTIFIER rel_op datum{ !!sfi.make; str ?= $2; sfi.set_attr_name(str); str ?= $3; sfi.set_operator(str); str ?= $4; sfi.set_attr_value(str); sfi.set_action("include"); $$ := sfi; } | E_EXCLUDE E_IDENTIFIER rel_op datum { !!sfi.make; str ?= $2; sfi.set_attr_name(str); str ?= $3; sfi.set_operator(str); str ?= $4; sfi.set_attr_value(str); sfi.set_action("exclude"); $$ := sfi; } ; datum:
boolean_constant | numeric_constant
Page 24
| manifest_string ;
rel_op:’=’ | E_NE | ’<’ | ’>’ | E_LE | E_GE ; log_op: E_OR | E_AND ; boolean_constant: E_TRUE | E_FALSE ; manifest_string: E_STRING | E_STRERR ; integer_constant: E_INTEGER { $$ := $1; numeric_code := ET_Number } | ’-’ E_INTEGER { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Number } | ’+’ E_INTEGER { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Number } | ’$’ E_INTEGER { $$ := $2; numeric_code := ET_Dollar } | ’-’ ’$’ E_INTEGER { $$ := STRING_.concatenate(<<$1.out, $3.out>>); numeric_code := ET_Dollar } | ’+’ ’$’ E_INTEGER { $$ := STRING_.concatenate(<<$1.out, $3.out>>); numeric_code := ET_Dollar } | E_INTEGER’%’ { $$ := $2; numeric_code := ET_Percent } | ’-’ E_INTEGER’%’ { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Percent } | ’+’ E_INTEGER’%’ { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Percent } | E_INTERR ; real_constant: E_REAL { $$ := $1; numeric_code := ET_Number } | ’-’ E_REAL { $$ := string_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Number } | ’+’ E_REAL { $$ := string_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Number } | ’$’ E_REAL { $$ := $2; numeric_code := ET_Dollar } | ’-’ ’$’ E_REAL { $$ := STRING_.concatenate(<<$1.out, $3.out>>); numeric_code := ET_Dollar } | ’+’ ’$’ E_REAL { $$ := STRING_.concatenate(<<$1.out, $3.out>>); numeric_code := ET_Dollar } | E_REAL ’%’ { $$ := $1; numeric_code := ET_Percent } | ’-’ E_REAL ’%’ { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Percent } | ’+’ E_REAL ’%’ { $$ := STRING_.concatenate(<<$1.out, $2.out>>); numeric_code := ET_Percent } | E_REALERR ; numeric_constant: integer_constant | real_constant ; %% feature -- Initialization make is
Page 25
-- Create a new Eiffel parser. do make_eiffel_scanner make_parser_skeleton end execute(rule_text:STRING; a_cr:COMPLIANCE_RULE) is require Input_exists: rule_text /= Void and then not rule_text.empty Rule_exists: a_cr /= Void do reset set_input_buffer (new_string_buffer (rule_text)) !!sfs.make(0) !!sfis.make(0) !!output.make(0) !!error_message.make(0) !!vector_result.make cr := a_cr parse end feature {YY_PARSER_ACTION} -- Basic Operations report_error (a_message: STRING) is do error_message.append(a_message) error_message.append("; ") end feature {COMPLIANCE_RULE} -- Access output:STRING error_message:STRING cr:COMPLIANCE_RULE -- already created feature {NONE} -- Building f:FILTER_STR sf:SUB_FILTER_STR sfi:SUB_FILTER_STR_ITEM sfs:ARRAYED_LIST[SUB_FILTER_STR] sfis:ARRAYED_LIST[SUB_FILTER_STR_ITEM] bi:BUSINESS_INFO feat_sts:STRING group_by_feat:STRING is_aggregate:BOOLEAN rc:RULE_CONSTANT bool_term:BOOLEAN_TERM rel_term:RELATIONAL_TERM qty_term:QUANTITY_TERM str:STRING qi1, qi2:QUANTITY_ITEM ei:EVALUATION_ITEM lt1:LOGICAL_TERM numeric_code: INTEGER feature -- Implementation vector_result:LINKED_LIST[BOOLEAN] -- stack to remember lhs and rhs vector/scalar statuses
Page 26
-- True = is_vector, False = is_scalar pop_vector_result is do vector_result.finish vector_result.remove end lhs_is_vector:BOOLEAN is do vector_result.finish vector_result.back Result := vector_result.item end rhs_is_vector:BOOLEAN is do vector_result.finish Result := vector_result.item end reduce_vector_result(is_vector:BOOLEAN) is do pop_vector_result pop_vector_result vector_result.extend(is_vector) end end
Page 27
