Broadcom CA SDM overview - Introduction to BOP

Chapter 1
Introduction to BOP
Table of Contents
PURPOSE OF THIS DOCUMENT 3
WHAT IS BOP? 4
High level Architecture ...................................................................................................................................5
How to learn all of this stuff...........................................................................................................................9
HIGH LEVEL DOMSRVR DESIGN DISCUSSION 10
Business Objects.............................................................................................................................................10
Factories and Lists.........................................................................................................................................12
The TOP object...............................................................................................................................................13
Modifying Dobs...............................................................................................................................................13
Domsrvr Summary.........................................................................................................................................14
A HIGH LEVEL VIEW OF THE GUI APPLICATION LAYER. 15
Wand files........................................................................................................................................................15
The DISPOB....................................................................................................................................................15
.VR files............................................................................................................................................................16
Summary..........................................................................................................................................................16
COMMAND LINE INTERFACES 17
bop_cmd.................................................................................................................................................17
bop_msg..................................................................................................................................................17
THE WEB INTERFACE 18
GLOSSARY 19
Business Objects Paradigm gi–1
overview.doc, printed on 7/23/2009, at 7/23/2009

Purpose of this document
gi–2 Introduction to BOP

This document is intended to serve as a starting point / frame of reference for the Bop
developers course. It is intended to be read by engineers and field support who need to
support and customize existing applications, and to build new applications. It provides
an external or user view of the Bop Application Environment where a user is defined as
one who is developing or modifying applications which use this technology.
This material assumes you understand the basics of object oriented programming and
have at least an acquaintance with the C language. If you are going to do the exercises
you need a UNIX Workstation or NT Workstation upon which you can play that has the
latest release of Paradigm installed
Structure of BOP Documents
This material is structured into a Programmer's Guide and a Programmer's Reference.
The Programmer's Reference consists of an introductory chapter. The remaining
chapters should be read and the associated exercises performed on Paradigm
environment. Each subsequent chapters is designed to ‘peel the onion of functionality’ in
the Bop environment. The intent is to expose the pieces in a step by step fashion. The
initial workshops will be based on a employee tracking system. Later workshops will
use the objects already created in the Call manager system. The items covered are:
When provided as part of a BOP class, please read the inial chapter before first class.
• BOP Overview
• Your First Bop Application
• Adding simple behavior to the Domsrvr
• More complex Domsrvr behavior
• Working with Spel and the command line interface
• Basics of the GUI layer
• Linking the GUI and the Domsrvr together
• Using LRELs
• Events
• Modifying Call Manager

What is BOP?
Traditional development environments have done a good job of defining a way to store
information (Such as SQL databases) and have good tools for defining GUI forms to
allow the user to poke at that data. What is typically missing is the middle layer that
glue’s the database to the GUI and defines the application behavior. The application
developer is called on to write code to provide this behavior, typically in some compiled
language. This model begins to break down in Business Process applications
(Applications which mimic an existing business process) such as Problem Management.
In these applications the customer wants the application to match their way of doing
business. There is no ‘right’ way to design the application. To meet these customer
needs, we have designed an application framework which can be extensively modified to
meet our customers needs.
Bop (Business Objects on Paradigm) is an object oriented application environment using
distributed objects technology, optimized for fast development of many kinds of
business process applications. It contains facilities to define Business Objects and to
bind the attributes of a business object to various underlying data repositories such as an
SQL data base. The behaviors and attributes of these objects are completely late bound
and can be customized and extended by the user, integrator, or developer. The Bop suite
of tools includes a GUI tool / viewer which makes building GUI applications quick and
relatively painless. Like object definition, the viewer is completely defined in late-
bound configuration and procedure files. A web interface to BOP is also provided which
again provides for easy web application development.
What all of that means to you as a developer is that writing code is no longer a major
part of developing an application.
Let’s define some of the terms we just introduced.
Application Environment:
Bop is a collection of pieces which fit together to create the business application. These
tools are optimized for development of multi-user, client server, form based business
applications. The bop environment makes the developers job easier and quicker, and
provides for great flexibility in the customer product.
Distributed Object Technology.
We make development easier by utilizing distributed objects. The objects used in our
applications are distributed among various processes and computers around the network
with location transparency. We call methods in these objects by sending messages to
them. In our model processes are peer to peer. In other words any process can provide
objects (be a server) and any process can ask for an object( be a client). The bop
distributed object is similar in concept to a COM object.
Business Process Application:
We are not optimized for building a spreadsheet, for word processing, or for building a
medical imaging system. We do handle business forms and data quite well. The original
target application was problem and call management.

Business Object.
We introduce a different paradigm for software development. A business object is an
object which encapsulates business knowledge and rules. A collection of business
objects can be assembled into applications by some program. A well designed business
object will live in many applications at any time. They lend themselves to re-use. It
makes you ask ‘where does the logic belong’ If it is a business rule, chances are it
belongs in the business objet. If it is application behavior, it belongs in the application
logic. Deciding where behavior belongs, is one of the first intriguing questions you will
need to answer in any development.
Late Bound Definition,
The class definitions of our business objects, GUI application, command line tools, and
Web Applications can be defined at run time with no lengthy compile-link cycle. This
includes the attributes of our business objects, methods on our business objects and other
objects, and behavior. This late bound definition is what makes it possible for the end
user to extensively customize the product for his needs.
GUI Viewer
What most end users first think of as the application. It presents the business objects to
the user on a screen, and adds GUI behavior to complete the application.
High level Architecture
tech_ovr.ppt 1
Domserver
Win
Viewer
Unix
Viewer
Web
App
Server
Web
Client
Netscape
Data
Store
Internet
Web
Client
Netscape
Domserver
C API
User
App
The architecture consists of three layers:
• The Data Repository Layer
• The Object Repository Layer
• The Application Layer

The Data Repository is where the data portion of objects are backstored. The system
currently supports the major Relational Databases as well as a proprietary relational
database. A schema file (*.sch) is part of the Data Repository. This file provides
information to the remainder of the system as to what tables are available, what the
columns in the tables are, etc.

The domsrvr (Domain Object Server) is where the Business objects live. It is the
Business Object Repository. The objects in the domsrvr are defined and implemented in
two types of files. The majic files (*.maj and *.mod) define the schema of the objects, in
other words the class definitions. The Spel files (*.spl) define the procedural behavior
via interpreted C code.
Type Product Files
bopcfg/majic
Customer Files
site/mods/majic
Majic
*.maj
Initial OBJECT
specification of product
Initial Customer
specifications of local
tables
Majic modification
*.mod
product temporary fixes to
delivered *.maj files in
bopcfg/majic
Customer modifications
to either product OBJECT
or Customer OBJECT
specifications
Spel *.spl Either
1) compiled product spel
libraries or
2) ptf0xxx.spl replacements
for one or more spell
methods in product spel
libraries.
Either
1) customer ascii Spel
methods
2) optional customer
replacements for one
or more spell methods
in product Spel
libraries.

The application layer currently consists of three application types. Additional types will
probably be defined in the future. The three types are a command line interface (CLI), a
GUI for ‘standard’ application access, and a Web Interface. Each of the application
layer types utilize the same idea of a late bound definition.
• The GUI forms are defined in wand files( *.wnd) which define the display objects
that make up the application, and by vr files (*.vr) which define the look and layout
of the window.
Type Product Files
bopcfg/gvr
Customer Files
site/mods/wnd
Wand
*.wnd
Either
1) inital product wand or
2) ptf0xxx.wnd that replace
one or more wand
methods in product wnd
libraries.
Initial Customer
specifications
Visual Resource
*.vr
product temporary fixes to
delivered *.vr files in
bopcfg/gvr
Customer modifications
to either product or
Customer specifications
• The CLI interface uses Fragment files (*.frg) which are identical in format to the
Spel files. The Fragment file (IE code fragments) are read by a command line
tool and executed.
• The Web Interface is currently driven by freeaccess.cspl, a Fragment file which
defines behavior, and by HTML Template files (*.htmpl) which define the look of
the HTML forms.
tech_ovr.ppt 1
Domserver
Viewer
Data
Store
bop/cfg/majic/*.maj
bop/cfg/majic/*.spl
bop/cfg/wand/*.wnd
site/mods/majic/*.maj
site/mods/majic/*.spl
site/mods/wand/*.wnd
site/mods/gvr/*.vr
bop/cfg/gvr/*.vr
s
h
i
p
p
e
d
m
o
d
s

How to learn all of this stuff
The best way to learn a new environment is to work in it. There are no Wizards or IDE
for Bop as yet. So you will be doing a bit of work in a text editor in order to see results.
We will assume that you are working from an existing Paradigm application. This
makes setting up the environment much easier. In order to reduce the variables in our
document we will further assume that you are running the Paradigm Proprietary
database.
Once you learn how it all fits together, you will be able to make good use of the
reference documentation that we supply.
The beginning of design for any application is defining what additional objects you need
in the domsrvr to support the application. We can’t begin to talk about this however
until we have a better understanding of what a business object is, and how it can be used.

High level domsrvr design discussion
The purpose of the domsrvr is to create and provide useful objects to the application
layer in a consistent extensible manner. In the past, we have had SQL which defines a
standard way to store and retrieve data in relational tables on a disk. Whenever you
wrote an application , however, you had to write a fair amount of code to handle the data
not stored on the disk, to add behavior to the application, to define ways of retrieving
and manipulating lists of data in the application. The domsrvr provides a standard way
of handling this functionality for you so you don’t have to spend time designing and
writing that code. It does this by defining standard Business objects, List objects, as well
as Access and Update methods.
Business Objects
Let’s start in the middle and talk about what is a business object without any regard to
how you create one or what you can do with it.
The internal name for a Business object is a Domain Object (dob) that shouldn’t be
confused with the viewer’s Display Object (DOB). Dobs are what you will be dealing
with most often in your applications. It is the programming object you define which
contains the business rules of the organization and which you combine with other dobs
to make an application. A business object has attributes (Sometimes called properties)
and methods. The methods are only accessed by sending a message to the business
object asking it to execute the method. The business object, can be defined to reply by
sending a message back to its callers.
Each attribute in the dob has a name. You typically access the attribute by it’s name.
One attribute is always present, the ‘persistent_id’. This read only string attribute
contains an id which will is unique to a single instance of a business object (For example
John Smith) and also contains the class name of the object. For example the object
representing John Smith (A member of the class ct) might have a persistent id of
ct:1234.
We have several types of attributes in the system. Creating new attribute types is not
supported outside of the domsrvr developers. The attribute types we support are:

Type Description
Value A simple concrete value. Current types are String, Integer, Duration, and
Date/Time. An example in our Contact object might be ‘ last_name
string’
SREL A single relation. A reference to another business object. An example
might by ‘my_group SREL org’ where org is another business object
which is the department our contact belongs to. Think of SRELS as the
unique foreign key of another table.
BREL A back relation. The ‘other side’ of an SREL. For example, our
organization object could have a ‘my_contacts BREL contact my_group’
where my_contacts is a list of all contacts which have this organization as
their ‘my_group’ attribute.
Think of BREL as the (non_unique) foreign key of another table.
QREL A Query relation. A relation which contains a list of objects defined by an
SQL type WHERE clause.
LREL A List relation. A many to many mapping between two dob’s
SREL, BREL, and LREL example
The data for the attributes are stored in an SQL database. At this time there is a one to
one correspondence to an object class and a database table (This may change in the
future . Part of defining your Business Objects is deciding what columns in the database
table you want to bind your attributes to. We should note however that not all attribute
types need to be backstored (BREL and QREL) and that some have a ‘special’ storage
not in the ‘main’ database table (LREL). Additionally you may define Value attributes
which are not backstored in the database. This feature is particularly useful if you need
to keep additional scratch state variables or want to define a combo_name(last_name,
first_name middle_name) field for Contacts.
...
LRel
desc (String)
sym (String)
TYPE
cr_members
type (SREL)
open_call_req(BREL)
call_req (BREL)
last_name (String)
first_name (String)
id (Int)
CONTACT
notify_list (LREL)
active_flag (Int)
Assignee (SREL)
open_date(DateTime)
Desc (String)
CALL REQUEST

Dob’s and their attributes will both respond to messages being sent to them (i.e. they
have methods). There are a rich set of methods for access , modification, being notified
of changes to the object, etc. You can define additional methods on the dob if needed.
For example in Call Manager we defined a method of the Call_Request object (cr) to
create an activity record which would be properly initialized and which would point to
the cr. This is one major way you have of customizing and enhancing the business
object. You can define a method, and provide the procedure to be done when the
method is called in interpreted Spel code.
The other primary form of modification is in triggers on the attributes and on the
Business objects.
• Built in trigger points are available to allow you to define default rules for attribute
values.
• You can use both pre-validate and post-validate triggers on an attribute changing
that can test for valid input, or have other side effects. For example, I could
define a pre_validate trigger on the last_name attribute in the contact object to
make sure the first letter is Capitalized (or I could coerce it to be Capitalized)
and when it is changed, I could re-build the combo_name attribute.
• On the Business Object you define triggers to be called when the object is created,
instanced from the backstore, validate prior to being saved, post_validate prior to
being saved, and after being saved. These triggers can further be filtered to only fire
based on specific values of specific attributes in the business object. For example I
could set up a trigger to fire whenever the status of a Call Request is being changed
to Closed when the object is being saved.
Remember that when you get a reference for a dob (say a contact for Sam Smith), that
all you have is a reference. The actual object for Sam Smith is ‘really’ in the Domsrvr.
You present requests to manipulate that object, and the domsrvr will honor those
requests as best it can. Also remember that what you really have is a public interface to
the Sam Smith object. Multiple users may be requesting the Sam Smith object. and
could be making changes to it. You are protected from those other accesses until they
save their work however.
The most interesting question now is how to get a dob from the domsrvr.
Factories and Lists
How do you get the business objects to display and manipulate. The answer is from a
Factory object or a Domset object ( The Domset is the List object)
A Factory is the object that will provide you with a dob if you give it the persistent_id.
It will make a new dob for you if you ask it to. You can define methods on the factory
as you can in the Business Object. For example, for the knowledge manager we defined
a method in the Solution factory to take a Description field and return the keywords that
are contained in the description field.
A Factory will also create for you the List object (Called a Domset ). A Domset is
designed to hold a set of business objects that match selection criteria. A Domset can be
defined to sort the dob’s based on the attribute values. In this way you can set up a Call

Request list to sort by Assignee, or Status, etc. Domsets have some unique features that
should be mentioned.
• Domsets can be static or dynamic. A dynamic Domset will be notified whenever a
dob is changed and it matches the selection criteria. For example, if you have a
dynamic list to show all call requests assigned to you, and you re-assign one of
your call requests to someone else and save the change, the dynamic list would
remove the call request that you changed.
• For efficiency, lists can be shared by users. You can define global lists to (for
example) keep track of the number of priority-1 Call Requests.
A factory has a set of standard lists. These are lists that you know will always be there.
You can define many options about the standard lists. We will discuss these later.
Factories (like dobs) have attributes. In this case the attribute is a Producer. We will not
talk about producers too much. For the most part they are an implementation detail in
the Domsrvr itself.
We get Domsets from Factories by sending a message to the factory requesting a
Domset. Where do we get Factories from.?
The TOP object
Factories are attributes of the TOP object. The TOP object is the well known interface
into the Domsrvr. It is where you always start. It is always possible to send a message
to TOP because you know it’s name. You can always get a Factory object by asking
TOP.
For example, if you want to get the first call request that matches some selection criteria,
you could send a message to the TOP object to be dispatched to the cr factory to get a
Domset object. Send a fetch command to the Domset, wait for the Domset to get in
some items. Get the first one.
The top object also provides the user with instances of the Group Leader object. This
object is used in concurrency control. The TOP object is also where additional security
will be implemented.
Modifying Dobs
Instead of a more common read/write lock approach, the BOP environment utilizes a
check-in / check-out metaphor with notification of changes as it’s way of handling
revisions and update conflict. The user requests a special object from the TOP object
named the Group Leader. When the user wants to modify the attributes of a dob, he
sends a ‘checkout’ message to the group leader. If the group leader can check out the
object he does so and tells the user that the checkout succeeded. If some other group
leader has the object checked out the checkout fails and the user is notified of this. Once
the object is checked out, the user can make changes. The user can checkout additional
objects on the group leader. When the user has completed his changes, he checks in the
group leader which commits all of the changes. Any other consumers of the Bop(s)

which are changed can register for changes in the attributes of the Bop. They would be
notified of the change in attribute value after the chicken is complete.
Domsrvr Summary
• Distributed Business Object Server
• Single derivation available in all objects
• Consistent Interface to all objects
• Relations between objects are attributes
• Late Bound
• Behavior via added methods and triggers on object or attribute
• Access via Messaging
• Interpretive language to define procedural behavior

A high level view of the GUI application layer.
The best way to think of this layer is as an application that reads .wnd (Wand) files,
and .vr (Visual Resource or Form) files and creates the application the end user
manipulates. The two keys to understanding the vbop layer are the Wand files, and the
VR files.
Wand files.
Consider designing a new GUI application. You have split the application into major
subsections, and have divided the subsections into individual forms. You want to be
able to invoke the various subsections and forms you have defined from various
locations from within the application. For example if your application is trouble
ticketing, the trouble ticket detail form should be able to display and manage failed
resources, action lists, and details of actions. You might wish to invoke the trouble
ticket detail form from a list of open tickets, or from a list of work assigned to ‘Fred
Smith’. This is the part of the application process that WAND is designed to address.
In WAND you define sections of the application which may consist of multiple forms,
and the relationship between those forms. WAND also allows you to define the context
information required to invoke a form or subsection. This allows you to hook up the
form in any part of the application that has the needed context.
For example, a ticket detail form which has sub displays, (Actions, failed resources, etc.)
associated with it could be defined to need as it’s only context the persistent id of the
trouble ticket to display. You could then ‘hook up’ the ticket detail anywhere the id is
available. From a list query screen, from a list of tickets assigned to Fred, or from a Call
Manager screen that has an associated ticket.
Unlike pure visual programming environments, where behavior is tightly bound to a
particular form screen, the wand approach allows you to define behavior and
relationships in one location, and associate one or more forms with them. This means
that in our Ticket Detail example above, I could have a different form which is targeted
towards different users, or which varies based on the place I invoked the Trouble Ticket
detail. I don’t have to re-create the application functionality with each form the user
sees.
The DISPOB
The major unit of WAND configuration is the Display Object (DISPOB). The DISPOB
encapsulates a related group of information which can be displayed on some form. In
early learning states, it is useful to think of a DISPOB as the ‘code’ that drives a ‘form’
although later you will see that this is not strictly true. A DISPOB can also be a row in a
grid, or a special section of a form.
As you will see in our early tutorials, the vbop application queries the domsrvr for object
schema information and creates a DISPOB with default attributes for the objects in the

domsrvr. This makes writing code easier (less to do) but makes understanding it a bit
harder (it’s hidden from you). It is therefore useful to briefly define the major parts of a
DISPOB.
The easiest way to think of the default DISPOB’s that are automatically created for you
are is as one of two types. A detail DISPOB whose function in life is to display a single
dob from the domsrvr. A list DISPOB whose job is to display some Domset from the
domsrvr. A detail DISPOB can of course display lists associated with the object (such as
a list of call activities associated with a call, or a list of call requests associated with a
customer).
Additionally we have two flavors of each kind of DISPOB - managed and not managed.
A managed DISPOB means that the viewer will only have one instance of the DISPOB
at any time. For example, if I decide that my application will have a single list
maintenance for Location, and when the user selects Location from the menu while the
Location is already up, we will raise the Location form to the top instead of creating
another form.
With our default DISPOB’s we have a rich set of built in behavior. From our list we can
create new objects, search for specific objects, save changes, etc. We even create default
selector helpers for our objects. What the form looks like is under the control of the .vr
file associated with the screen we are putting up.
.VR files
.vr files are created by a GUI form editor. This editor allows you to lay out your
dialogs , to give the dialog a name, and to associate tags with the objects you put on the
form. When the DISPOB is created, it looks for the named form and puts it on the
screen. It then gets the tag names from the form for each widget that is in the form, and
puts the data from the domsrvr (via the DISPOB) onto the screen. For example, if your
DISPOB was a loc_detail (Location Detail) and you wanted to display the location’s
description attribute on the form, you would put a text edit widget on the form and set
the tag to ‘loc.description’.
BOP also support the idea of form groups (same functionality but with a different
implementation from Problem Management). A user can have a different form from
other users either based on who the user is or what group they belong to. This gives
flexibility in controlling access and layout to different users. Like the WAND language,
the forms are completely late bound. No re-compilation is required to display a new
form. The form group feature allows you to easily set up different looking and
functioning screens. For example, you could use the standard call manager screens for
you help desk analysts, but set up a simpler screen for a dispatcher who gets calls when
the help desk is swamped..
Summary
• DISPOB as Logical form. Defines behavior
• DISPOB defined in Wand files
• .vr file to define look of form
• Tags in .vr files to tie form to DISPOB

Command line Interfaces
The behavior of BOP is defined in large part via interpretive code. BOP has two types
of command line interfaces.
bop_cmd
BOP has a command line utility which can be invoked with a file name (containing code
to be interpreted) and a function within that code to execute. If you are defining a
command line interface, you will be sending messages to the domsrvr, executing code
you write etc. This Spel code runs within bop_cmd???
bop_msg
BOP has a command line utility which can be invoked with a function within the
domsrvr to execute. This code runs within the domsrvr. If the function were to run for a
long period of time ( example crarcpurge ) and the bop_msg were killed, the function
would continue to run.

The Web interface
The web interface is managed via a separate web server daemon. It communicates to the
domsrvr using the standard BOP messaging. The current webengine was not
documented for customer modification. (product packaging, not a technical decision).
What you can customize is the template files which define the forms. This is similar to
defining vr files in the GUI application.

Glossary
.maj files:
.sch files
.spl files
.vr files
.wnd files
Environment variables
NX_BPTIMEOUT
NX_DSSORT BINARY EN INTL INTL_NOCASE NOCASE EN_NOCASE
NX_DSCONFIG
NX_MODS
Application:
An executable which provides useful work for the user.
Attribute:
Part of domsrvr object. Sometimes called Propertys. Attributes have names by
which they can be accessed. They represent other objects, concrete data types,
Single relations to another object, Query or Back relations to another object class, or
List relations.
BOP:
Business Object Paradigm. An application development and runtime environment
which is used to define applications.
bop_logging:
An executable which will print messages to a file. A very useful debugging routine.
bop_sinfo
An executable which will print various details about the domsrvr schema
bop_tps
A ‘thread ps’ utility. This tells you where any active threads in your interprative
code may be.
Brel Attribute
An attribute on a dob. This is the ‘Back’ relation. It can best be thought of as a list
of objects where the definition of what is in the list is based primarily on some other
Srel attribute
Business Object
An object which encapsulates a business funciton. We build applications from
business objects. In the domsrvr the business object is called a domain object or
more commonly a Dob.
Business Process Application
An user application of the type that lends itself to a Busines Object approach.
Business Process Applications are designed to track events, replace paperwork,
automate workflow, etc.

Business Rules
The rules of a Business Object.
Call Manager
An application in the Paradigm suite of products. Call Manager is based on the BOP
technology.
catcher method
Some calls you make to the domsrvr will cause multiple messages to be sent to you
at later time. You need to provide a catcher object and a catcher method to ‘catch’
these later asynchronous objects.
catcher object
Some calls you make to the domsrvr will cause multiple messages to be sent to you
at later time. You need to provide a catcher object and a catcher method to ‘catch’
these later asynchronous objects.
Checkout/Checkin
The metaphor for revision control in the BOP world. You get an object and, if you
want to make a change, you attempt to checkout the object. Later you check it back
in when your changes are complete.
combo_name field
A field in the call manager contact object which combines the first, last, and middle
names.
cursed row
In the GUI application. When you are viewing a grid on the screen and your cursor
is located on some row, that is the cursed row.
dbspy
An executable which examines the low level slump calls to the database daemons
dialog
A screen construct you can define for the user. Sometimes called a window.
DISPOB
A Display object in the Bop Viewer. A Dispob encapsulates application behavior
separate from the dialog which is used to present it to the end user.
distributed objects
A style of object oriented programming where the objects you are manipulating may
be in any process space.
Dob (Domsrvr)
A Business Object.
DOB (vbop)
The object which wraps a Dob (Domsrvr) for you and manages the display.
Domain Object
Another word for Business Object.
Domset
The list construct in BOP. A domset is a list of dobs that match some selection
criteria. They are typically sorted by multiple keys.
domsrvr
The executable which serves domain objects (dobs or business objects). This is the
primary server in the Bop world.

editwin
The executable which provides a drag and drop GUI to create and modify the
Dialogs that are part of the GUI application.
Ensemble
A collection of objects in the domsrvr that co-ordinate to handle some class of
business object. Typically is is the Factory, Producer, and Dob itself.
Event Trigger
A way to have an object be activated at some time in the future to do some work.
With no human intervention.
factory
The object which provides Dobs and Domsets to the user
Fast Channel
A way that two processes can set up a ‘faster’ communication channel under Slump.
The two processes in fact set up a provate semaphore to communicate over.
Form Groups
A way to provide different looks and functionality to different users. A form group
can be defined for some functional group or hardware configuration (like VGA).
The user will use the forms in the form group instead of the default forms.
Group Leader
Used in revision control. The group leader is a construct that actually manages
doing the triggers and checkin logic.
GUI Viewer
The application that manages the GUI for the end_user applciation (vbop)
Late Bound Definition
A feature of bop. The atrtributes and behavior of the objects and the application can
be defined and re-defined at the customer.
LIST
A vbop construct which is a list of dobs.
Lrel Attribute
The list relation attribute. An Lrel attribute maintains a many to many mapping
between objects.
Majic files
The files that define the object schema. The file extensions are .maj or .mod.
Managed Dispob
A dispob that is managed.
Managed
A vbop concept, If there is a managed display object, there will be only one instance
of it allowed at any time. For example, if Contact detail were managed, and the user
attempts to bring one up while there is another active, the existing instance will be
raised to the top, and the data in it will be set to the new context.
Message
The way we communicate between bop applications. The messages we use are
asyncronous and provide for reply mechanisms.

Method
A receptacle for a particular message. Similar in concept to a function on the
distributed object.
METHOD
In vbop - some wand code which can be associated with a button.
NX_ROOT
The root to the Paradigm applications. An environment variable you need to set
before developeing applicaitons
pdm_editwin
The script to start up the editwin application.
pdm_init
The script that starts the Paradigm daemons
persistent_id
Each dob has a persistant id. The persistent id is a string which combines class
information with instance information.
Problem Manager
One component of the Paradigm system. Problem manager is based on older less
flexible technology.
Producer
The object which instances dobs from the backstore.
Public/Private metaphor
The idea of a ‘private’ object that actually contains the data and methods, and an
access object which we make for each user which gives seamless access to the
private object.
Qrel Attribute
An attribute of a Dob which is a list of other objects. The list is defined by some
where clause (hence the Query)
Reference Count
Distributed objects have a built in reference count so the application will know when
the object may be deleted.
reply method
When you send a message to some object, you usually want the object to reply. To
do this you define in the message that is sent to the object a catcher object, and a
catcher method.
reply object
When you send a message to some object, you usually want the object to reply. To
do this you define in the message that is sent to the object a catcher object, and a
catcher method.
Schema files
The files that define the database schema for the environment.
slspy
A utility that looks at the raw low_level messages in the BOP environment.
slstat
An executable which provides slump status information.

Slump
The core messaging facility used in BOP.
Spel files
The files that contain the Interpreted C behavior need by the domsrvr. They have an
extension of .spl
Srel Attribute
An attribute which represents a single relation. Such as employee type, or assignee
of a Trouble Ticket.
Standard Lists
Each factory defines some standard domsets it supports. We refer to these as the
Standard Lists.
TOP
The object at the ‘top’ of the object instnace hierarchy in the domsrvr. This object
always has the same name so you can always send messages to it. This is the entry
point into the domsrvr.
Trigger
A function that has been defined to be called at some point in the business
processing . Triggers may be conditional of various attribute values. They may be
applied to Attributes, or Dob.
Value Attribute
An attribute which is a simple concrete type such as string or integer
vbop
The executable which controls the GUI applicaiton.
Vre files
The Visual Resource files that define the dialogs for the application. These are
created and edited by the editwin application.
Wand files
The files that define GUI applicaiton behavior.
Widget tag
The string that the vbop application uses to decide where to hook up the widget to
the data structures in the Dispob.
Widget
Some item you place on the Dialog to place a label, add a text field, line, button,
grid, etc
Window
Another name for a Dialog

Broadcom CA SDM overview - Introduction to BOP

More Related Content

Similar to Broadcom CA SDM overview - Introduction to BOP (20)

More from Tiago Macul (20)

Recently uploaded (20)

Broadcom CA SDM overview - Introduction to BOP