richr@ai.etl.army.mil (Richard Rosenthal) (05/30/90)
I am comtemplating the purchase of a CASE tool for use on
a PC platform. Excelerator seems to lead the list of choices.
I would like to hear your comments about Excelerator.
Thanks.
/s/ Richard Rosenthal
richr@ai.etl.army.mil
--
Richard Rosenthal, Engineer Topographic Labs, Alexandria, VA 22060-5546
richr@ai.etl.army.mil +1 202 355 3653wdh1@ra.MsState.Edu (William D. Henry) (05/31/90)
In article <10@ai.etl.army.mil> richr@ai.etl.army.mil. (Richard Rosenthal) writes: >I am comtemplating the purchase of a CASE tool for use on >a PC platform. Excelerator seems to lead the list of choices. >I would like to hear your comments about Excelerator. I used Excelerator for software development in a Software Engineering class a few semesters ago. I was not at all impressed. It was not a simple program to use or learn to use in the first place. The graphics were not very well done, both on screen and printed. The single complaint that stands out in my mind was that it was too complex. As a Pascal, Ada, C, and (ugh) FORTRAN programmer, I found my experiences with numerous software packages like WordPerfect, Lotus 1-2-3, Windows, FAX software, and other PD communications programs literally useless. Excelerator is so unlike any other software, that I wonder how it was developed. Online help is pretty much non-existent, so the manual had to be referred to, but it also left much to be desired (as many manuals do in all fairness). Let me know if I can answer any specific questions. -Bill ____ | \ | | Bill Henry - wdh1@ra.msstate.edu | / . | | Mississippi State University |----\ | | University Honors Program | ) | | | |____/ | | | Live long and prosper.
tucker@pixel.HAC.COM (George Tucker) (05/31/90)
> Let me know if I can answer any specific questions. > -Bill Can you compare Excelerator with any other CASE tools for the same job? geo tucker@tcville.hac.com !<confiscatory taxes> => (<capital gains tax> || <inflation deduction>)
rlb@cs.odu.edu (Robert L. Bailey) (05/31/90)
In article <10@ai.etl.army.mil> richr@ai.etl.army.mil. (Richard Rosenthal) writes: >I am comtemplating the purchase of a CASE tool for use on >a PC platform. Excelerator seems to lead the list of choices. > >I would like to hear your comments about Excelerator. > The "best" CASE tool is the one that suits your needs and development environment. There are a lot of choices on the market. Before you can make an intelligent decision about which CASE tool is "best" for you, you need to ask yourself several questions: 1. Is this going to be used for new development? life cycle support/re-engineering an existing system? both? 2. What formal development method do you use? Is this the best for your development environment? Which CASE tools support that method/environment? If the tool you think is best doesn't support that method, are you willing to change it? 3. Do you have TOTAL commitment to the underlying philosophy of CASE technology? Less than TOTAL commitment is doomed to failure. 80% of all CASE software ends up being shelved due to lack of TOTAL commitment. 4. Are you and your colleagues/employees willing to TRAIN, TRAIN, TRAIN? CASE tools require a lot of training up front. 5. Do you know what features you want in a CASE tool? Some provide only partial development support. Some provide a fully integrated environment from design through code generation. Do you want a front-end CASE tool? A back-end CASE tool? Middle CASE? ALL? If you don't know the answer to these questions, (or if you aren't sure of the implications of these questions) you are not ready to choose a CASE tool. 6. Are you willing to READ, READ, READ? Choosing a CASE tool requires a thorough understanding of what you want from a CASE tool and what features each tool provides. If you want a good article to read, try the April 1989 BYTE. It has a thorough discussion of CASE in several articles of that issue. A very useful checklist is provided for the evaluation of CASE tools. Excelerator is a very good front-end CASE tool. It also interfaces with the largest number of other CASE tools. (very important) I used it several years ago to do an analysis of a couple of systems. I found it easy to use, although I would have liked it better if it had an integrated code generator. I think that the newer versions provides more features than the one I used, but, I haven't seen it lately to make an evaluation of its current capabilities. Asking about a particular CASE tool is somewhat like the old adage: "If you have to ask how much it is, you can't afford it." With CASE, "If you have to ask 'is this a good tool', you aren't ready to decide." A given CASE tool may be absolutely perfect for one application/method/ company/person, while it might me absolutely lousy for another! Know what you are looking for, and evaluate MANY CASE tools based upon that criteria. THEN you will know which one is best for you. In some instances, it may be NONE! In others, you may be able to choose from several. Bob Bailey (rlb@cs.odu.edu)
cberg@leadsv.UUCP (Charles R Berg) (06/01/90)
In some article, somebody wrote:
>Can you compare Excelerator with any other CASE tools for the same job?
I used Excelerator for about 18 months (over 3 years ago), and am now using StP
for about 2 years. While I haven't done the SAME job with both tools, I can
compare how the two tools would work on the two jobs I did.
First, some philosophy. Index Technology (authors of Excelerator) frequently
claims "We don't preach religion, we build churches." What they mean is, they
don't rigidly enforce any given methodology with their tool, they provide the
framework in which to 'massage' standard methodologies into your company
preferences. They offer a companion product, Customizer, that allows you to
define new diagram types, new entities, new symbols, and new relationships
between objects. With this complete set of tools, it is relatively easy to
make the rules you want, and capture the information you want. One other
important philosophy is that there are virtually no methodology rules
enforced when drawing a diagram. Rules are applied upon analysis of an
existing diagram.
IDE, (authors of StP), on the other hand, advertises "Visible Connections" and
"Open Architecture". What this means is that many of the parameters that
define the tools behavior are configurable in ASCII files. So, it is actually
trivial to change the information captured about any given object in the
database. However, it is a major effort, but do-able (I know, I'm doing it),
to add new diagrams, entities, and relationships. In addition, there are a
number of methodology rules that are enforced before a drawing is allowed into
the database. Other rules are further applied upon analysis.
So, some comparisons.
Dataflow Diagrams. Excelerator allows the user to build a directed graph of
diagrams. If you want to define 3 identical processes that share the load in
a multi-processor architecture, you can draw 3 process bubbles, label them as
you wish, and decompose all 3 to the same lower-level diagram. StP would
require that two of the process bubbles be annotated as being identical to the
3rd, which would be actually decomposed. I AGREE, its not Yourdan methodology,
but if its important to you to want to do it anyway, then Excelerator makes
it easier. Excelerator also allows you to decompose process bubbles
recursively, and will allow you to decompose a process bubble to a structure
chart if you want. In addition, Excelerator process ID's are free-form text,
while StP enforces numerical hierarchy. So in summary, both tools provide
an environment in which you can do standard Yourdan dataflow diagramming. If
your company has other needs, Excelerator allows you greater methods
flexibility.
Other Diagrams. If you will allow some generalization in the interest of
brevity, I would say that the previous summary is generally true. Both tools
provide an environment for standard methodology, but Excelerator allows
greater flexibility in tailoring those methods to your company needs.
Document Production. Both tools provide a mechanism for extracting information
from the database and exporting into 'desktop publishing' systems. Both
allow you to customize the attributes that are defined for each object type.
StP provides this by editting ASCII configuration files, Excelerator provides
a screen editor tool. The real differences appear when you want to use that
information. StP has a very powerful, 4th generation language that allows you
to make database queries based on these attributes. You can select, sort, and
manipulate the information quite extensively. It also provides a relatively
complete and powerful set of document formatting commands. Excelerator's
document production, on the other hand, is more limited to extracting
diagrams and objects, and the block of information stored in the database
about each. However, Excelerator does have a report writer, separate from its
document production tool, that allows you to make ad-hoc queries very quickly
and easily. "Give me the names of all dataflow diagrams containing process
bubbles that do not decompose to other dataflow diagrams" is a very easy
query to create, and can be saved for later use. These queries can also be
included in documents. StP would require that a separate document script be
written in their DPS language. Also relatively easy, but a bit more time-
consuming, and not something you would likely want all of your users to be
doing.
So, (this is getting kinda long, isn't it) as far as the two projects I worked
on using these tools.
The first was for a start-up company, and we needed a tool to capture object-
oriented design information (back before either tool provided such a thing).
We also wanted to capture a multiple-window, pop-up menu user interface, in
addition to normal data structures and structure charts. High quality,
polished documents were not a requirement. I was quite pleased with our choice
of Excelerator, and if I had it to do over again, I would choose it again.
The second project was for my current employer, a government contractor. Here,
high-quality document production was paramount. We are using StP (obviously),
and are succesfully pushing its document production capability beyond what
IDE ever expected it to do. Of course, the underlying database necessary to
produce our complex documents is also supported by the tool. Once again, I
still believe we have the right tool for the job.
I guess another generalization I can offer is this. Excelerator is easier and
more flexible at getting information into the database. StP is more powerful
at being able to manipulate and document the information captured. Now, if I
could have the methods flexibility of Excelerator with the powerful database
and document production of StP....
Now, in case I haven't made myself clear, both of these tools are good tools.
They each have their strengths and weaknesses. I have successfully used both,
on two very different programs. In no way are my comments intended to
recommend one over the other.
In conclusion, you have now heard from several people who have said (in effect)
"The best tool is a matter of your requirements and your preferences." You
have to do your homework. Get evaluation copies of every tool you're thinking
about buying and use them. Try to do meaningful little projects with each. No
tool is perfect - you have to find the one with strengths that complement your
needs, and weaknesses that don't get in your way.
One other good piece of advice you received bears repeating. The amount of
work you put into selecting the right tool is SMALL compared to the amount of
work necessary to learn how to use it, support it, maintain it, extend it, and
do everything else your going to want/need to do. The cost of purchasing the
tool is SMALL compared to the cost of the effort of using it. If you aren't
ommitted to that effort and expense, don't bother.
I hope this helps.
Chuck Berg
PS: I am an independent consultant. I have no ties what-so-ever with either
Index Technology or IDE. I also do not speak for my current employer. I am
offering personal opinions based on personal experience. If I have inaccurately
stated features or limitations of either of these tools, I apologize, and
encourage the vendors to post corrections. I personally think it would be
great if some CASE vendors would get involoved in discussions in this group.cberg@leadsv.UUCP (Charles R Berg) (06/01/90)
In article <11394@leadsv.UUCP> cberg@leadsv.LEADS.LMSC.COM.UUCP (I) wrote: >In some article, somebody wrote: >>Can you compare Excelerator with any other CASE tools for the same job? > >I used Excelerator for about 18 months (3 years ago), and am now using StP >for about 2 years. > >First, some philosophy. (philosophy deleted) One other significant 'philosophy' difference. Excelerator interacts with the database on-line during the diagram editting process. With StP, you edit the diagrams 'off-line' and in a separate step, 'compile' them into the database. This results in some interesting trade-offs. With Excelerator, if you can't remember the name of the module you want to reference? A few keystrokes and mouse-clicks and you have a list on the screen from which to select. It automatically restricts the list to only those objects (by type) that are valid for the current field, and names can be qualified by wild-card. With StP, the nearest equivalent is the Database Browser. This provides a scrollable list of all objects in the database. If there are any mechanisms to qualify this list by object type or wild-card name selection, I'm not aware of any. Another trade-off. With StP, when you create a diagram, you frequently reference existing objects in the database. Data structure diagrams reference existing data structures, structure charts reference existing modules, etc. These references can be annotated with all kinds of free form and strucured information, but only the annotation on the 'defining' object goes into the database. Virtually the reverse is true with module parameters on a structure chart. If the module is defined on a separate diagram, with the parameters entering from 'off-page', these parameters are NOT entered into the database. But on other diagrams, where references to this module are made, the parameters ARE entered into the database. And, there are no checks to ensure that all references to a given module use the same parameters. (But you could easily write your own DPS script to verify this.) With Excelerator, during the editting process, any reference to a defined object will automatically provide the existing database entries for that object. If you change the (Excelerator equivalent of) annotation, you are changing the one and only one copy of that information that exists. These examples imply (to me anyway) that the Excelerator approach is better. However, there is a big price you pay for it. Excelerator requires that each user 'check-out' that portion of the database that they want to work with. Then they can do their job, and check it back in. This is more than just checking out one diagram at a time. It means checking out all the diagrams and objects for a major portion of the system, since thats the only way that all the objects you might want to reference will be in the local database. And there is still the opportunity for conflict when two or more people copy out information for reference purpose, and then want to check it all back in. There are procedures for taking care of all this, but it really requires some effort on the part of a database administrator person. With StP, there is a single database, (usually on a network), that is dynamically locked and unlocked as each user interacts with it. In addition, individual diagrams are dynamically locked and unlocked as they are 'checked- out' for editing. So, once again, which is better depends on individual requirements. My first project only involved three users of the Excelerator database. We didn't bother checking out individual copies of the database for private use. We just hollered around the room as we worked. With StP, we have 12 or so users, so the informal approach would have been very difficult to rely on. Once again, I hope this information helps. Chuck Berg PS: Same caveats and disclaimers as before.