Re: Scaling up the Express Development Environment

Question

Paul,
We have two BM's and two AM's.
We had two full-time developers and 2 part-time.
BM1: 25 classes
BM2: 8 classes
AM1: 65 windows
AM2: 22 windows
2-3 classes in each BM had to be duplicated becauses of the problem that
you mentioned.
What we did to make the AM's and BM's more accessible was to create a
workspace in which the changes to the models would be made and the
classes re-generated and integrated but no other development was done. This way, a user
that needs to create a new class or window can be in and out of the workspace
in a relatively short period of time. The user then updates his own workspace
to get the changes created by the changes/additions to the models. Otherwise,
if a user checks out an AM and BM in their own workspace, makes the changes
and then continues to customize the windows, it may take a while before they
integrate and allow others to check the models out. In your case, you may want
to create a workspace for each AM/BM pair. You may also want to create a script
to update the workspaces of each of your users and force a compile on each workspace
on a nightly basis to reduce the amount of time wasted during the day updating and compiling. Another
thing we did to decrease wasted time waiting for updates, integrates and compiles was
to have each user create multiple workspaces(2-3) dedicated to different areas of
development so that while one workspace was busy updating, compiling etc..., they
could continue developing in another. This will increase the size of your repository
but disk space is cheap! Also, make sure everyone creates a shadow repository on their
machine to reduce hitting the main repository.
Hope this helps.
Peter Kelly
[email protected] wrote:
>
I'd like to get some opinions on the best way to handle medium to large scale
Express development. By this I mean more than 2 teams working concurrently on
applications that have dependencies.
The scenario:
BM - business model
AM1 - application model that uses subset of BM1
AM2 - application model that uses subset of BM1 and windows from AM1
Team1 - will enhance AM1 during month 1-6
Team2 - will enhance AM2 during month 1-12, incorporating the work from Team1
Both teams wish to change the business model. Does it make sense to split the
model up? Express doesn't provide a mechanism for linking business models. If
you define a class in BM1, you can't draw an association to it from BM2.
Therefore the generated windows will not be able to reference the object as the
association is not defined. You could duplicate the classes that are common to
both (Forte Technical Support recommends this) but redundancy is never a good
thing. Something would probably have to be done to get the services coordinated
for load balancing, transaction mgmt of aggregate updates, etc.
It is possible to link application models together (window in AM2 linked to
window in AM1) but the link invokes only the defined start window of AM. You
can get around this for lookup links and command links by defining a proxy
window and overriding the link code to instantiate a window of the correct
type. Alternatively you can change the super class of the window to point to
the correct class. Any additional customizations (additional links, folders,
etc.) that were defined in the original base window will be lost. What appears
to be much more difficult is adding an additional folder to a window that is
defined in another application model. Ideally in AM2 you would define a link to
a window in AM1 that inherited all the folders etc defined in AM1 plus any
additionally defined in AM2 (sounds like something an OO tool should do).
Of course, there is nothing in Forte that would prevent you from doing this
yourself. However Express relies a lot on code generation rather than reusable
classes so you would have to duplicate a lot of code and window widgets to
achieve this. I would like to see Express evolve away from code generation. To
do that Forte would probably need to become more dynamic. Then Express could
have create an ExpressWindow class that could dynamically register as a folder
window in any parent without the need for a static declaration in the
application model.
Even if all the technical issues are solved you still have to deal with all the
configuration mgmt issues involved in doing concurrent development. With
everyone wanting to change the models you need some form of version control. A
simple mechanism is to have multiple repositories and do a periodic manual
merge of the models.
I'd be interested in hearing how other groups are handling this. Any comments
or suggestions are welcome. Thanks.
Paul Krinsky
Price Waterhouse--
____ \ / ____ CrossKeys Systems Corporation
___ \ X / ___
\ X X / Crosskeys Centre Peter Kelly
X X X 350 Terry Fox Drive Software Designer
___/ X X \___ Kanata, Ontario
____/ X \____ Canada K2K 2W5 [email protected]
_____/ \_____ [phone] Ext. 8247

Answer 1

Split the business model, and duplicate the classes.
If you think of a business class the same way you think of and deal with
views, it will make accepting the redundancy more palatable. A view is a
virtual table created to support an application's "view" of a table or set
of tables. The BM business class is a similar conceptual object. Actually,
it is often useful to map a BM class to a declared view (if your update
requirements and your DBMSs view update capabilities permit). Using views
also allows you to map several business classes to the same table, which
Express normally would not allow you to do.
The issue of which tables should be in which business model is a schema
partitioning issue. For a small database (say five tables), even if you
have a hundred apps, the problem won't arise. You simply have one BM for
all the apps. For a very large database (say 300 tables), but very simple
apps (one or two tables) the problem still won't arise. You simply have one
BM for each app with the one or two tables the app needs. For large
applications on large databases the problem does arise. If you have a 300
table database with a 1000 screen system (40-50 app models), the problem
would arise, and would need a systematic clean solution. In such a system,
you can follow a data-centered design, where you partition based on the
data shared, which will lead you to a set of BMs that don't have duplicate
tables. Or you would partition based on functionality (more likely to
please the user community), in which case you would find that you would
have to duplicate tables across BMs.
Hope that helps.
-Nabil
At 04:49 PM 2/5/97 PST, [email protected] wrote:
I'd like to get some opinions on the best way to handle medium to largescale
Express development. By this I mean more than 2 teams working concurrentlyon
applications that have dependencies.
The scenario:
BM - business model
AM1 - application model that uses subset of BM1
AM2 - application model that uses subset of BM1 and windows from AM1
Team1 - will enhance AM1 during month 1-6
Team2 - will enhance AM2 during month 1-12, incorporating the work from Team1
Both teams wish to change the business model. Does it make sense to splitthe
model up? Express doesn't provide a mechanism for linking business models.If
you define a class in BM1, you can't draw an association to it from BM2.
Therefore the generated windows will not be able to reference the objectas the
association is not defined. You could duplicate the classes that arecommon to
both (Forte Technical Support recommends this) but redundancy is never agood
thing. Something would probably have to be done to get the servicescoordinated
for load balancing, transaction mgmt of aggregate updates, etc.
It is possible to link application models together (window in AM2 linked to
window in AM1) but the link invokes only the defined start window of AM. You
can get around this for lookup links and command links by defining a proxy
window and overriding the link code to instantiate a window of the correct
type. Alternatively you can change the super class of the window to point to
the correct class. Any additional customizations (additional links, folders,
etc.) that were defined in the original base window will be lost. Whatappears
to be much more difficult is adding an additional folder to a window that is
defined in another application model. Ideally in AM2 you would define alink to
a window in AM1 that inherited all the folders etc defined in AM1 plus any
additionally defined in AM2 (sounds like something an OO tool should do).
Of course, there is nothing in Forte that would prevent you from doing this
yourself. However Express relies a lot on code generation rather thanreusable
classes so you would have to duplicate a lot of code and window widgets to
achieve this. I would like to see Express evolve away from codegeneration. To
do that Forte would probably need to become more dynamic. Then Express could
have create an ExpressWindow class that could dynamically register as afolder
window in any parent without the need for a static declaration in the
application model.
Even if all the technical issues are solved you still have to deal withall the
configuration mgmt issues involved in doing concurrent development. With
everyone wanting to change the models you need some form of versioncontrol. A
simple mechanism is to have multiple repositories and do a periodic manual
merge of the models.
I'd be interested in hearing how other groups are handling this. Anycomments
or suggestions are welcome. Thanks.
Paul Krinsky
Price Waterhouse
==================================================
Nabil Hijazi Optimum Solutions, Inc.
[email protected] 11654 Plaza America Drive
Phone: [phone] #501
Fax: [phone] Reston, Va 20190
--------------------------------------------------