[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(FC-Devel) Re: Argo & architecure

>> Some tools, like (older versions of?) Software Through Pictures and
>> Cyanne's ObjectTeam seem to have a shell application and separate
>> applications for diagram editing, code generation, reporting, and
>> (limited) model analysis.  However, I think all of these components
>> execute on the user's desktop.  Maybe someone in the project knows
>> more about these tools?
>That sounds close to the model I was thinking of. Of course despite the
>implementation the user would see the system as one integrated application
>(unless there was benefit in exposing it's modular nature in some cases).

They do expose it somewhat because their user interface has explicit
commands to invoke certain analyses.  In contrast Argo is constantly
running analyses in a background thread.

>Hmm, I am a bit confused, maybe we are having terminology problems (or maybe I
>need to ease up on the coffee). I think that what you are refering to as the
>model I am thinking of as the meta-model. Isn't the model the thing that is
>produced using a CASE tool (expressed as one or more views on the model, i.e.

Right, sorry to be so imprecise.

>Anyway, I agree that a tight coupling is unavoidable between the
>UML meta-model and the various components. I don't necessarily agree that IPC
>would be too slow for model analysis or code generation though. What sort of
>delay is introduced by a remote method invocation using CORBA compared to the
>same method being called in-process? In the case where the method is serviced
>by a different process on the same machine (the most likely scenario for us),
>or even a machine connected to the same LAN (also likely), I would have
>thought the delay would be totally insignificant.

If this is true then we can forget about all my objections to using
different processes.

>Don't the critics suggest changes,
>rather than implement them directly? And if they do implement them
>automatically wouldn't we need some sort of contention mechanism anyway
>between the editor and the critic?

Right now they only suggest, but I want them to offer to automatically
correct problems also.  Yes, the model (I really mean "model" here)
would have to be locked during each manipulation.

>Secondly the interface. Why can't the critics (etc.) communicate with the user
>interface process using IPC? If the response time is the only issue then I
>think that we should take a look at it a bit more closely before we assume it
>is unworkable. IPC may be slow compared to CPU speeds, but it can be
>blindingly fast to us poor limited humans :)


The two main requirements for intercomponent communication are (1)
support for fast and frequent "procedure calls", and (2) ability to
hold references to objects in another component.

>Hah! Excellent question! I am sure that SOME people can (isn't that kind of a
>definition of a methodology?) Luckily for all of us it should be possible for
>lesser mortals to translate their codifed ideas from their English and
>diagrammatic representations into whatever language we build critics

Right, critic authoring is a pretty nice feature that can help groups
of designers that work together over time codify their best practice.

>thinking about it we had better have a simple mechanism for disabling and
>prioritising critics, I have a very strong feeling that not everyone will be
>receptive to all suggestions, or even that all critics will necessarily agree!

Absolutly.  There are several criticism control mechanisms in Argo.  I
can talk about them at length.

Assuming that frequent IPC is really not a problem for an interactive
application, here is one other difference between the architecture
that Jeff proposed and the current architecture of Argo.  Jeff's
diagram shows basically a star-topology with the UML repositoy at the
center.  Argo's is more of a sandwhich with UML representation as the
bottom slice of bread and integrated user interface as the top slice
of bread, and the editors, code generators, cognitive features in the
in the middle.  Jeff also had two "secondary interface servers", but I
am not sure what those are.

[UI-1] [UI-2]  [code_gen/rev_eng] 
 |      |       |

  |        |        |
[diagrams] [cg/re] [critics] ...
  |        |        |