0.0 Executive Summary
1.0 FIXED EVENTS - none
2.0 PRELIMINARY AND ADMINISTRATIVE MATTERS
2.1 Establish scribe - Jeff Sutherland
2.2 Attendance and introductions
Glenn Hollowell, Texas Instruments, Chair <glenn@ti.com>
Joaquin Miller, MCI SHL Systemhouse, Vice-Chair <miller@shl.com>
Jeff Sutherland, IDX Systems Corp., Secretary <jeff.sutherland@idx.com>
Tom Digre, Texas Instruments <digre@ti.com>
Hiam Kilov, IBM TJ Watson Research Center <kilov@watson.ibm.com>
Bryan Wood, Open IT Ltd. <bmw@mci.org.uk>
Bob Hodges, Texas Instruments <bhodges@ti.com>
Cory Casanave, Data Access Corp., Chair BODTF <cory_casanave@omg.org>
Mohammad Rashid, Quantitative Data Systems <mrashid@qds.com>
Frank Manola, Object Services and Consulting, Inc. <fmanola@objs.com>
Stuart McIntosh, MIT
Selden Stewart, NIST <selden@nist.gov>
Silas Larry Smith, IBM <slsmith@vnet.ibm.com>
Tom Rutt, Lucent Technologies <t.rutt@lucent.com>
Stig Berild, SISU <stig@sisu.se>
David Smith, Deere & Company <ds60162@deere.com>
Oliver Sims, SSA Object Technology <olivers@cix.compulink.co.ok>
Karsten Riemer, Sun Microsystems Computer Corp. <karsten.riemer@sun.com>
Woody Pidcock, The Boeing Company <woody@atc.boeing.com>
2.3 Review the proposed work items
2.4 Administrative
| Date | Meeting | Place |
| 6-7 Dec 96 | X3H7
|
Boston @IDX |
| 10-11 Mar 97 | X3H7 | Austin w/X3J21, OMG BODTF |
| 23-24 Jun 97 | X3H7 | Montreal w/X3J21, OMG BODTF |
| 17-18 Nov 97 | X3H7 | Princeton w/X3J21, OMG BODTF |
2.5 Special topics
2.6 X3H7 Final Report
2.7 Review/discuss submitted documents
2.8 Define and schedule work to be done in plenary and breakout groups
Motion: Persons not present at the end of the day will give their
votes on the ballot to the Chairman within the next day. Passed by unanimous
consent.
Motion: Approve minutes of X3H7 7 June 96 Meeting. Passed by
unanimous consent.
Motion: Change Ballot title to "RM-ODP Enterprise Language
and Relationships to other Viewpoints." Glenn Hollowell, second Frank
Manola. Passed 6 for, 0 against, 4 abstentions.
Motion: Change text in clause 2.1 as indicated. Joaquin Miller,
second Frank Manola.
Therefore, there exists a clear need to describe how
the viewpoint languages are used together for creating application
architectures. This description shall
be based on existing RM-ODP definitions in IS 10796-2 as refined by IS
10796-3 and the new concepts and constructs defined for the new enterprise
viewpoint.
After discussion, the change was amended by unanimous consent to:
Therefore, there exists a clear need to describe how
the viewpoint languages are used together for creating application
architectures. This description shall be based on existing RM-ODP definitions
in IS 10796-2 as refined by IS 10796-3 and the new concepts and constructs
defined for the new enterprise viewpoint..
Passed 7 for, 0 against, 1 abstention.
Motion: Change text in clause 2.2 as indicated. Brian Wood, second
Glenn Hollowell.
There are no provisions for interoperation with a model prepared for
some other enterprise, nor do such models link in a rigorous manner with
system specification languages.
Passed by unanimous consent.
Motion: Recommend to X3T3 that they should respond to the Ballot
item by voting yes with the editorial comments adopted by X3H7. Glenn Hollowell,
Frank Manola second. Passed 7 for, 0 against, 1 abstention.
RESPONSIBILITY PRIMARY BACKUP
Chair Glenn Hollowell
Vice-Chair Joaquin Miller
Project Editor (Object Models) Frank Manola
Project Editor (Enterprise Viewpoint) Joaquin Miller
Vocabulary Rep Joaquin Miller Haim Kilov
Secretary Jeff Sutherland
OMC/SC21 TAG Rep
Membership Status Joaquin Miller
Document Log/Librarian Jeff Sutherland
Document Distribution Jeff Sutherland
| X3H7-96-01 | Some materials on relationships for the enterprise viewpoint of RM-ODP | Haim Kilov | 5 Jan 96 |
| X3H7-96-02 | Proposed New Work Item: RM-ODP Enterprise Language and Application Architecture | ISO/IEC JTC1/SC21 N 10387 Rev 1 | 23 May 96 |
| X3H7-96-03 | Minutes of Meeting, Washington, D.C. | Joaquin Miller | 7 Jun 96 |
| X3H7-96-04 | RFP-1 "Business Objects" BOF Evaluation Scenario | Oliver Sims, Peter Eeles. OMG BODTF | 6 Sep 96 |
| X3H7-96-05 | Business Object Facility RFP Response Evaluation Guidelines | Tom Digre (Ed.) OMG BODTF | 7 Sep 96 |
| X3H7-96-06 | U.S. ballot comments on SC21 N10387 - New Work Item Proposal for Enterprise Language | Tom Rutt X3T3-96-096 | 16 Sep 96 |
| X3H7-96-07R1 | Business rules for the Enterprise Viewpoint of RM-ODP | Haim Kilov | 13 Oct 96 |
Joaquin Miller will provide Jeff Sutherland minutes of ad hoc meeting
1-5PM on 15 Sep.
Minutes of June 96 meeting by Joaquin Miller will be reviewed after lunch.
Need to meet in late November to finalize the U.S. position to ISO Australia
meeting. We will develop about a 10 page submission and take two days to
work on it on December 6-7 in Boston at IDX.
Next Meetings
6-7 Dec 96 Boston, IDX Systems
10-11 Mar 97 Austin, Joint with X3J21 and OMG BODTF
23-24 Jun 97 Montreal, Joint with X3J21 and OMG BODTF
17-18 Nov 97 Princeton, Joint with X3J21 and OMG BODTF
Reports on work completed - Haim Kilov contribution
Discussion of what is needed next
Gathering of work assignments
Making work assignments
Prepare ballot response for ISO new work item
Reconcile RFP Response Evaluation Guidelines with RM-ODP requirements - Tom Digre
There is a different in perspective. At yesterday's BODTF meeting, the
BOF was viewed as part of the engineering viewpoint. On Page 6 of the Business
Object Facility Response Evaluation Guidelines, the BOF is considered part
of the information and enterprise viewpoint.
It was my interpretation of the last ISO meeting that BOF was part of
the engineering viewpoint. This needs to be clarified at the next ISO meeting.
It depends on how your are looking at how you specify the BOF facility
(Bryan Wood).
There are different views on this. I originally viewed the BOF as a
mechanism like OLE/COM that allowed plug and play. Cory Casanave, Chair
BODTF, views BOF as an underlying application framework that is used to
build vertical application domain frameworks (Jeff Sutherland).
What Tom has written is good in that it dicusses it from all viewpoint
perspectives. I don't see a problem here. There will be a problem with
lack of clear specifications in the submissions (Haim Kilov).
Example: Rumbaugh has week specification of relationships, they are
just links in most cases. RM-ODP precisely specifies relationships. Some
statements in responses may be based on vague concepts like Rumbaugh's
and not precise specifications as in RM-ODP (Haim Kilov).
Since you are looking at the BOF facility, you may want to evaluate
it from all viewpoints. This is different that looking at the specific
use of the BOF which may be an engineering issue (Bryan Wood).
Here is an example of how viewpoints work. Depending on your needs,
you make focus on a different subset of viewpoints (Joaquin Miller).
Serveral people recommended deletion of last sentence in Engineering
viewpoint paragraph which states "This viewpoint does not need to
be addressed by BOF, it is implied by CORBA."
On Page 7, bullet stating "Additional enterprise viewpoint concepts
were suggested …" needs to be clarified and amplified. Only some of
these concepts are defined in RM-ODP Part 2 (Haim Kilov). There are some
relationship management specifications in the enterprise viewpoint but
they may appear elsewhere as well (Bryan Wood).
The object model for the order system in the addendum by Oliver Sims
needs improvement. Sale or agreement needs to at the center of the model.
Relationships needs to be better specified. Haim Kilov can provide some
enhancements.
There was a discussion of the limitations of graphical notations which
Haim prefers to avoid. Others thought they were useful. You need an object
modeling notation to provide a description of each viewpoint (Bryan Wood).
There are two RFP's out for OOAD and a meta-object specification. There
is a requirement that responses to these be mutually supportive (Bob Hodges).
At Tools, a document interviewing Rumbaugh, Booch, and Jacobson was presented. Jacobson stated that dynamic sematics are not yet in the Unified Model. They are working on it (Haim Kilov). There was an inadequate response two years ago on this issue of how to describe behavior (Joaquin Miller).
Assignments in minutes from last meeting were reviewed.
Haim walked the Committee through the document briefly. Glenn raised
the question of how to use the document in preparing the U.S. contribution
to ISO.
The Outline for Draft New Standard was reviewed (ISO/ISE JTC 1/SC 21
N 10387 Rev 1). Business rule specifications and patterns for reuse are
the essential concepts and Part 3.2 is an appropriate place for them (Hiam
Kilov).
Business specification says what the business does. This does not include
workflow detail.
Business design says how the business does it. This includes workflow
and specification of what part of the business will be automated.
System specification and system implementation follow from business
design.
It would be an important contribution to bring the General Relationship
Model into this work and it should be called to the attention of other
companies prior to the ISO meeting in Australia (Bryan Wood). There is
an explicit reference to the GRM (Haim Kilov).
If ISO standards are needed for standards work, they can be reprinted
for this purpose. Joaquin Miller will followup on this. Jean Paul Emard,
ANSI, Washington, D.C. is the individual to communicate with.
Action: Haim's instruction for the next meeting is to provide
a paragraph on Business Rules for Part 3.2 of the outline.
A draft was reviewed and minor changes made. Votes will be taken at
the end of the day on these comments.
Motion: Persons not present at the end of the day will give their votes on the ballot to the Chairman within the next day. Passed by unanimous consent.
Many of these concepts are used in RM-ODP Part II but need enhancement:
Contract
Community
Role
Process activity
Life Cycle
Time
Objective
Relationship
Rule
In RM-ODP a party (person, corporation) has a role when he becomes a
homeowner. He becomes part of the community of homeowners. This can be
viewed as a composite relationship between party and homeowner. Or homeowner
can be viewed as a subtype of party. Or homeowner can be a plug-in to the
party object (reuse by delegation).
Within the enterprise viewpoint there are two things that are important (Haim Kilov):
Desire (retire early and wealthy)
Goals (invest in stocks and bonds, etc.)
Composition of desire and goals is a concept.
Action - work for next meeting:
Process, activities and life cycles - Karsten Reimer
Contracts, uniform commercial code, integrating feedback - Haim Kilov
Coordinate Texas Instruments position paper on these concepts - Glenn
Hollowell
Motion: Approve minutes of X3H7 7 June 96 Meeting. Passed by
unanimous consent.
Motion: Change Ballot title to "RM-ODP Enterprise Language
and Relationships to other Viewpoints." Glenn Hollowell, second Frank
Manola. Passed 6 for, 0 against, 4 abstentions.
Motion: Change text in clause 2.1 as indicated. Joaquin Miller,
second Frank Manola.
Therefore, there exists a clear need to describe how
the viewpoint languages are used together for creating application
architectures. This description shall
be based on existing RM-ODP definitions in IS 10796-2 as refined by IS
10796-3 and the new concepts and constructs defined for the new enterprise
viewpoint.
After discussion, the change was amended by unanimous consent to:
Therefore, there exists a clear need to describe how
the viewpoint languages are used together for creating application
architectures. This description shall be based on existing RM-ODP definitions
in IS 10796-2 as refined by IS 10796-3 and the new concepts and constructs
defined for the new enterprise viewpoint..
Passed 7 for, 0 against, 1 abstention.
Motion: Change text in clause 2.2 as indicated. Brian Wood, second
Glenn Hollowell.
There are no provisions for interoperation with a model prepared for
some other enterprise, nor do such models link in a rigorous manner with
system specification languages.
Passed by unanimous consent.
Motion: Recommend to X3T3 that they should respond to the Ballot
item by voting yes with the editorial comments adopted by X3H7. Glenn Hollowell,
Frank Manola second. Passed 7 for, 0 against, 1 abstention.
What does metadata management mean in the context of OMG? What kind
of facility could be used in multiple domains. Work has narrowed focused
to OOAD models.
In June 1996, RFP5 was issued at Australia meeting. The Architecture
Board scoped down the two RFPs and partitioned them into separate areas
of concern.
A. MetaObject Facility: Set of IDL Interfaces that manipulate meta-meta-model.
B. Meta-meta-model: Defines how meta-models of OA&D CF will be specified.
C. O&AD CF: Set of IDL interfaces that support creation and manipulation
of A&D models.
D. OA&D Meta Model: Enables semantic interoperability and tool interoperability
across OA&D methods
| Abstraction | Examples | Typical Purview |
| Domain Objects | Telephone customer
Bank customer |
Application vendor |
| Common Business Objects | Customer Warehouse | Framework vendor |
| Business Object Facility | Plug and play components | Framework/Operating system vendor |
| Object Analysis & Design Models | Class diagram
State transition model Use case |
Tools vendor |
| Meta-Object Facility | Class Relationship Model | Repository/Framework vendor |
| OMA Object Model | Interface Operation | ORB vendor |
An abstraction level's model element becomes next higher abstraction
level's meta-model element. The Business Object Facility has been inserted
into this chart by Jeff Sutherland. It is related to the Meta-Object facility
and repository structure, however, and this may not be the optimal placement.
The original chart was provided by OA&D TF/Mary Loomis.
BOF, MOF, and OA&D RFPs are scoped down, partitioned, and will be
harmonized. Deadlines for all of these will be 15 April 1996, allowing
various groups to work together.
Handouts for this presentation are on the Web.
Minutes of this meeting will be submitted to Joaquin Miller in RTF format
for posting.
The Committee invites submissions related to the outline of the work
item for development of the standard and explanatory papers on the concepts.
Submissions for the next meeting are due on 25 November.
There will be three speakers this morning addressing how to develop
business specifications for object-oriented systems:
OMG Business Objects and Open Distributed Processing Enterprise Viewpoint
Standards
Conditions
ODP Viewpoints to OMG Business Object Correspondence
Engineering (BOF)
Technical Enterprise (BO) Information
Computational
ODP Enerprise Viewpoint Work Item
-BO overlaps Enterprise/Information
Timeline
Future ODP work Item
Contacts and Contributions
Tom Rutt X3T3 and head of WG7 delegation
Questions
What are the obligations of computer systems to humans and what access
should they have to other computers.
Randy is a logician, was in academia, last five years in formal specification
languages for NSA
Deontic Logic as a language for specifications
Contrast between simplicity and expressive power is central to logic.
Logical languages allow you to have it both ways - clean and simple as
well as highly expressive. The job of logicians is to define these is the
best possible way.
The first thing to talk about in the syntax. Next are the rules of reasoning.
Third is precise semantics. We will have time to talk about the first two.
Deontic logic is an extension of proposition logic:
p, q, r stand for propositions which are statements of fact. Randy has
a blue shirt on this morning.
Connectives
or
and
not
implies
equivalent
(A or B) is an expression that means not(not A and not B) which is the
disjunction
Personal aside: In Tibetan philosophy, the ultimate insight is accessible
only by negating the negatee. It is not true that there is no personal
identity. At the same time, one cannot say there is identity. There is
no "self" in the ultimate sense. Disjunction does not work in
this case. The computer analogy is that objects have unique identifiers
so it is not true that there is not identity. At the same time these identifiers
are normally not visible, so they do not exist in some sense. Even when
visible, there is an absolute minimal amount of uniqueness, only that they
are different, they are arbitrarily chosen, and one is the same as any
other except for the uniqueness feature. The partitioning of the underlying
reality is arbitrary, but by attaching different attributes and relationships
to the arbitrarily partitioned identity, the world of form appears.
A, A implies B modus pundis, most common rule of inference
B
Predicate logic adds to the power of atomic assertions:
For all x, p(x) means it is not the case that there is an x that doesn't have the property
There exists an x such that p(x) means it is not the case that for all
x it fails
Box A means that A is true and necessarily true. Diamond A means that A is true but not necessarily true. We are still in the general setting of modal logic. It happens to be true that Randy is wearing a blue shirt, but that is not necessarily the case. He could have worn the green shirt in his closet.
Box (A implies B) implies (Box A implies Box B)
A implies B
Box A implies Box B
A A
Box A A
It is very difficult to say some things in English that are crystal
clear when using symbols. Most logicians accept the proposition above but
not the propositions that A implies Box A.
Anything that is a correct rule of logic is necessarily true. This is
the fundamental assertion of logicians.
OA means A is obligatory
PA means A is permitted
FA means
OA is equivalent to not permitted not A
PA is equivalent to not obligatory not A
A implies A is OK
OA implies A means whatever ought to be true is true. Not always the case.
OA implies PA. If it is obligatory it must be permissible. You need this.
OA implies OPA. It is permitted implies it ought to be permitted.
In the world, there is often more than one obligation at the same time
(federal vs. State law, etc.). Logicians handle this with more than one
deontic operator and make one take precedence over the other. If you can't
assign precedence you are in trouble.
Standard deontic logic:
A implies O(A implies B) implies (OA implies OB)
OA
OA
PA
If something is provable as a logical statement, it should be true.
This is standard in that it is simple, widely known, and lots of philosophers
have argued against it.
FA implies F(A and B) follows from the standard deontic logic theorems
If I beat him up and rob him, this is forbidden. But then I make restitution.
This must be permitted and may be obligatory. So this theorem is problematic.
Deontic logic is useful in the real world where what ought to be true
is not necessarily true. In telecommunications and chip industries, temporal
logic is widely used and is the standard way to do things. There are computer
based theorem provers for temporal logic. Deontic logics are not that far
along. It is headed from the academic world into the real world. Check
the references to get started.
Tom Rutt - ODP says you must state obligations, permissions, and prohibitions.
Deontic logic may apply here.
Oliver Sims - Can we apply this to Business Rules?
I don't have enough experience to know, but I do know that it is easier
to express things clearly in symbols that cannot clearly be expressed in
English.
Take a notion of business obligations and write is down and make it
logical precise before trying to discuss it. This may be helpful. At a
minimum there could be a computer tool that goes through the logical statements
representating policies. For example, if a big bank swallows a little bank.
A computer could search through the logical statements of policies of both
organizations and find inconsistencies between the two organizations policies.
Check out "Deontic Logic in Computer Science, Wiley Professioal
Series
Godel's Theorem question:
Godel's Theorem says you cannot fully specify a logical system, i.e.
you cannot prove everything with the system that is true. One example,
is that you cannot prove a logical system is consistent. You must use arguments
external to the system to try to make the case.
Why business objects are not reused?
Grace Hopper understood in 1957 that while calculating the square root
was the same in each U.S. city, the calculation of gross pay was different
even within cities.
Banks, rules, documents, and contracts existed before computers.
Business logic is in the code! But the code is often ambiguous. Some
programs use age minus 44 to calculate insurance projections for a person
born in 1945. The cost of fixing this worldwide is estimated to be $300
to $600 billion.
Architect and builders do different things. Builders have subcontractors.
In software development, a programmer does all of the above.
"… a pattern defines an invariant field which captures all the
possible solutions to the problem given, in the stated range of contexts."
Christopher Alexander (an architect understands these things)
Specifications must be simple and understandable to users, developers,
and reusers. They must be specified at a higher level than the implementation.
Business specification - understand the business with no reference to
computers, software, screens, etc. Must define things, relationships, collections
of things.
Let's reuse what good programmers do and keep what good modelers have
invented.
"Think first, program later."
Simplicity is key. Abstract and concise. Complete and precise.
Business rules are about objects, operations, and invariants.
Operations involve several things (objects).
Invariants involve several things.
Object- orientation = abstraction plus precision
ODP provides common generic concepts throughout the lifecycle, is well-written
and short with emphasis on semantics, not syntax.
Someone (not the programmer) should provide the missing pieces of the
business rules in order to be precise so that rules can be effectively
implemeted.
Signature vs. Semantics:
contract ( house1, person1, person2, money)
A contract specifies what is true before and what is true after:
Pre-conditions:
Post-conditions
Relationships between objects are ambiguously specified in OOAD. For
example, I a composition-containment relationship a department may exist
without employees, employees must belong to exactly oe department, at least
one property of department is independent of an employee, etc.
A definition of a relationship must specify the invariants. Specify
once and reuse.
A warm and fuzzy feeling is not a definition.
Composition has mutually orthogonal subtypes
Elementary relationships are not isolated and can be combined into patterns.
A type is a predicate characterising a collection. Therefore a thing
may have several types. A thing is a subtype if and only if it satisfies
the predicate of the supertype.
An instance satisfies a type and belongs to a class - ODP.
A type is not attached to a thing forever. Relationships can have types.
Patterns for reuse. Understand -> Specify -> Reuse
Almost everything you need to know about business patterns can be found
in Lewis Carroll's "Alice in Wonderland."
Operations have a contract:
A business rule is one of the last four bullets above.
Biggest problem for reuse is defining things in one context and not
considering others.
A model is finished when you can ask all relevant questions in terms
of the model.
If pays to be elegant. With a small set of reusable constructs, you
have a common ground for modelers and developers, complete and precise
business rules, and savings in time, money, and effort.
Many business patterns have been defined and published by Hiam (see
slides).
Questions:
Is there any work going on in specifying contexts?
Haim - Yes and no. Some parts of contexts are invariants. Others must
be specified by some approach like deontic logic. We acknowledge that this
needs to be done and are looking for a customer that will work with us
on this.
How can we get a copy of the ISO General Relationship Model (GRM) document?
Haim - If you are a member of an ISO organization, I can mail you one.
I have a limited number of copies of my paper about the ISO document.
Many references were discussed (see slides). For ISO document sources, check out the following:
www.itut.ch
www.iso.ch
Oliver Sims - There seems to be a relationship between pre and postconditions and Phase I and Phase II of a two phase commit?
Haim - Yes. To do work on this I need a customer who will fund it.
Oliver Sims - In a cloud of business objects there are multiple resource manners and clean two phase commits are not possible. The best solution to this seems to be to build the business objects in a way that pre and postconditions are enforced.
Haim - Yes, and there is some work going on in this area.
Do you do anything with event typing?
Haim - not yet.
Does the Workflow Coalition know about the model of a business rule? Can they use it?
Haim - There will be a paper at OOPSLA'96 Workshop on Behavioral Specification
on this.