The Rationale for the BDA Architecture explained using a Language Analogy

This page describes the Business Object Model using a language analogy, explaining why have it, and how do you use it. For an explanation of the business view point see Business Rationale page.

Why do we need a Business Object Model?

This is best described by using an analogy of language. Imagine there are many people wanting to discuss something using a conference call. If the participants all speak in a different native language it is impossible for everyone to understand what each other are saying.

A conference with all using native language

If everyone agrees to talk in a common language (e.g. English) and each person translates from their native language to English when they speak, and then translates from English back to their native language when listening then everyone will understand.

A conference with all using same language

Using this analogy, the Business Object Model is equivalent to English, i.e. it is the common language for communication. The use of web-services is equivalent to using the telephone (i.e. it is a transient communication, but may have log files to record what was said), and the BDA platforms are equivalent to the people talking, and the conference call is equivalent to the “team of trust” that has been set up to collaborate. So each BDA Platform, when it wants to send some information (talk) it first converts its own internal data model (native language) into the Business Object Model (common language), then sends it via a web service (telephone) to the server side(person listening). The server side responds to the web-service (listens) and converts to its own internal data model (native language) to act on it.

Language, Communication mechanism and Who is talking.

As there are many different ways to communicate in English (e.g. telephone, speaking, email, letter) there are also different ways to communicate using the Business Object Model.

One way is file transfer with a third party translator which converts the file into and out of the common format. This is analogous to someone writing an email in their native language, then a third party (e.g. translate.google) converts it to the common language. The same, or another third party then translates from the common to the other native language and sends the email to the other person.

The advantage of this is that a specialist can do the translating. The disadvantage is that the specialist needs to understand not only the common language but also the language of the participant. Also if the native language changes then the specialist has to be informed and update their routines, where it would be more efficient of the owner of the native language updated the translator at the same time as they made change.

Examples of Communication mechanism

Another way to communicate is to use web-services sent directly from one participant to another in the agreed format. The advantage is that each participant is in control of their own translation so can make sure that any changes to their native language are reflected in the translation. The disadvantage is that each participant must understand the common language in order to make sure they are translating correctly. But this is less risky than relying on a third party.

Use in Crescendo Thermal Test Case

Continuing the language analogy:

• All languages have an underlying standard, i.e. they are built up using words and sentences

• The Business Object Model is built on the standard ISO 10303-239 Product LifeCycle Support [PLCS] this is used by many different businesses to communicate in their own manner, and each can convert back to the standard.

  • Languages are built up of words

    • ISO 10303-239 is built up of classes

  • Languages have types of words, e.g. Nown, Verb, Adjective, and each language has their own versions of the types

    • e.g. English nowns = “House” “Car”, English verbs = “Read”, “Write”, English adjectives = “Black”, “White”.
    • PLCS has classes such as “Product” and “Justification”. the Business Object Model then has classifications of these so Product = “ModelType”, “QualityReportType” etc. Justification = “Decision”, “Argument” etc.

  • Languages have sentence rules e.g. a sentence must have one or more verbs. English has it own extensions to these rules such as the adjective comes before the nown e.g. “That is a white house” not “That is a house white”.

    • Similarly PLCS has rules about the allowed relationships between classes e.g. Products can have properties. The Business Object Model then extends that e.g. ModelInstance has a relationship called “status” to a property with a format of <string>.

  • When a language is used, it has semantics or meaning. This is not part of the rules of the language

    • Similarly the business rules such as what are the allowed values for the ModelInstance status string do not form part of the Business Object Model.

  • Experts in different fields use the common language of English, but have their own specialist jargon to communicate the details of their domain.

Experts language and common language

• Similarly the specialist domains all use Business Object Model as the common language, but each has their own Specialist Standard for communication of the technical details.

Technical standard and common language

“Why?” Conclusions

• It is the Vocabulary, Grammar and Syntax of the BDA Collaboration Standard

  • Using ISO 10303-239 (PLCS) as the underlying standard provides:

    • Communication with other systems based on PLCS
    • Ease of extension to complete lifecycle e.g.
    • Manufacturing and Maintenance
    • Publication mechanism, the mapping to PLCS will be published as a Data EXchange specification [DEX]
    • An Archive format
    • Facilitates the use of Specialist technical standards, e.g. AP203, AP209 etc

See also Business Object Model Introduction.

How do you use the Business Object Model?

The role of the Industrial Partners

Using the language analogy, they have defined the Vocabulary for the common language, i.e. classes of definitions of:

• Person, Organisation, Skills
• Contracts, Rights
• Methods, Templates, Type Definitions
• Models, Key-Values, Studies
• Interfaces and Components, Connections and Ports
• Requirements and Verification (VV&A)
• Architectures and System Views
• Quality Gates, Reports and Meetings
• Uncertainty, Justifications, Assumptions
• Optimisation: Variables, Objectives, etc
• etc

They have defined the Grammar and Syntax for the common language, i.e. the relationships between the classes, or how to:

• Record the “problem definition”
• Study Management and Control processes
• Allocate and trace requirement satisfaction
• Trace who did what, when and how
• Trace model dependency and usage
• Declare applicability and usage of methods
• Record key decisions with rationale
• Declare which Rights are governed by which Contract
• etc

They have verified the resultant Business Object Model by testing the implementations provided by the software providers.

The role of the software providers

The software providers have:

• Determined the collaborative aspects of their solutions, i.e.read, write, answer

  • AirCADia Example

• Understood the Business Object Model in these areas, and how that maps to their own internal data model/representation

  • AirCADia Example

• Developed the appropriate Web-Services Client (and Server)

  • AirCADia Example

• Test the Web Services

See also Business Object Model Introduction.