Newsgroups: comp.ai,comp.lang.misc,comp.programming,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!Germany.EU.net!EU.net!sun4nl!phcoms4.seri.philips.nl!newssvr!pvloon
From: pvloon@prl.philips.nl (Paul van Loon)
Subject: Re: A new approach to software engineering!
Message-ID: <D1u7GH.7B9@prl.philips.nl>
Originator: pvloon@prl.philips.nl
Sender: news@prl.philips.nl (USENET News System)
Organization: Philips Research Laboratories, Eindhoven, The Netherlands
Date: Tue, 3 Jan 1995 16:07:29 GMT
Lines: 221
Xref: glinda.oz.cs.cmu.edu comp.ai:26194 comp.lang.misc:19813 comp.programming:13746 comp.software-eng:29121

The week before Christmas we wrote a newsnet note on Domain Specific
Formalisms (DSF) and we gave it the title: A New Approach to Software
Engineering. Since then many valuable comments and remarks have been
made, either on the net but also directly. This has made us feel
grateful. Some of the respondices will get a personal answer, but in
this note I will try to respond on the more general remarks made.

For convenience I first include the original note:
>
>Within Philips Research in Eindhoven we form a group of people that
>highly believe that for a lot of application domains it is time for 
>a new approach to software development. We want domain experts
>to generate software themselves without the need of programming
>experience. To that end we have developed, and to some extent 
>have experience with, an approach that is characterised by the
>following aspects:
>-- We don't let domain experts use a general purpose language like C, 
>   Pascal or whatsoever. Per application domain we actually develop a 
>   tailor made programming language (DSF) -and corresponding (graphical) 
>   tool- that enables people from the domain to describe their world in 
>   a form that can be used automatically for further execution without 
>   the daily involvement of a software expert.
>-- The domain experts concentrate on the declarative description of their 
>   domain knowledge and they don't have to bother on all kinds of
>   implementation hassle.
>-- We make a clear distinction between the static representation part of 
>   a domain, describing the abstractions with their interrelations, and
>   a dynamic exploitation part, describing specific actions or tasks
>   upon the representation part.
>-- Reusability of domain knowledge has become possible, by connecting more 
>   than one task-specific software system to this declarative description.
>-- We use compiler technology to implement all of these (one front-end and 
>   one or more back-ends).
>-- We will use all good aspects of modern software programming techniques, 
>   like object orientation, functional programming, etcetera.
>
>Note that we don't think task-specific, but domain-specific. We believe
>that in many applications large parts of the specific tasks can be
>automated. Therefore a domain expert is not asked to describe a solution, 
>but rather the data that is needed to generate a solution!
>
>We would like to get feedback on this DSF approach. Therefore we are
>interested in answering questions like:
>Who has experience with such an approach? What was that experience? Do
>you know any prototypes, or even better operational systems, build with
>such an approach? What are (possible) bottlenecks in this approach?
>What are relevant names and publications?
>
>Please inform us of everything that might be of value for us. Thank you!
>


-- NEW
Dagmar Anne Bogan wrote in <3dnops$n85@news2.delphi.com>:
>Is this truly a "new approach"?  I seem to vaguely remember the same 
>ideas of the end-user creating their own software tools back in the early 
>80s with the advent of Lotus and dBase, and later in the 90s with 
>rule-based expert systems.
and Ralph Johnson in <johnson.788537339@hal.cs.uiuc.edu>:
>This is a great idea.  However, it is not new.  It is sometimes called
>"end user programming" or "domain specific languages".  It is closely
>related to "domain specific software architectures" and "object-oriented
>frameworks".  
and they are right. Of course our approach is not brand new. On the 
contrary, we use as much as possible the good things of proven technology. 
But I do think we further extrapolate in a direction of software development 
that is seen for quite a long time now. For instance, we think our approach
distinguishes itself in the separation between declarative knowledge
representation (in compiler technology: the front-end) and exploitation
(the back-end). In contrast to Expert System shells we don't use
something like a generic inference engine. For neither parts of the system 
we have general tools available on the shelf.
The domain specific knowledge model, which is the framework for the
knowledge representation, and a clearly specified task-specific exploitation
scheme are to be developed simultaneously. We compare our approach more with
the database approach than with rule-based systems. 

-- PROCEDURAL KNOWLEDGE
Chuck Matthews wrote in <1994Dec23.115040.4648@driftwood.cray.com>:
>Problem solutions are a combination of data description and some
>procedural mechanism for processing the data. The developers of your
>application must be able to specify both data and the computational
>procedures.

Indeed, for making an application (which we consider as a task on a
certain domain) also procedural knowledge is needed. However, we don't
want the domain expert to implement the procedures he uses to come to 
solutions. Procedures can be well specified and implemented
by a software engineer (as part of the back-end). In general these
procedures are more fixed than the domain specific data/knowledge. So,
we want to develop languages and tools by which the domain expert can
describe the declarative data/knowledge of his domain, i.e., can fill a
declarative data- or knowledgebase, but not the way he comes to conclusions.
Even a stronger statement can be made: depending on the application we
decide whether to follow the procedures of the expert or to use
techniques that better fit the possibilities and opportunities of the
computer (like, for instance, heuristic techniques for optimisation).

-- COOPERATION
I fully agree with Thad Smiths who wrote in <c76_9412260001@hms.com> 
(comp.programming):
>Most successful applications, I think, involve a range of talents, from
>computer types that write software for user interfaces and language
>parsing, to in-between types that have a fair understanding of the
>application domain and how to apply software, and the domain experts
>that think mostly in the domain area and don't usually need to bother
>with computers. 
That is why (at least initially) we work in teams, at least consisting
of a domain expert, a software architect/engineer and a so-called
knowledge author. This last person requires special skills, in
particular great expertise in the application area and the ability to
make formal abstractions, but does not require background in computer
science. Because of this different profile we certainly will not call
him a 'knowledge engineer'.
The software architect/engineer is partly responsible for the
definition and fully responsible for the implementation of the tools,
i.e., both front-end and back-end(s). A crucial role is played by the 
domain specific knowledge model (for short: domain model or domain ontology),
which is a shared responsibility. Actually the creation of this model can be 
seen as 'understanding the problem', which by Scott Whitmire in
<netnewsD18uuF.Ju1@netcom.com> is called the hardest activity.

-- PROGRAMMING
In <netnewsD18uuF.Ju1@netcom.com> Scott Whitmire writes:
>In every application I've built over the last 15 years, the programming has
>been the easiest, if not the most tedious part, of development. 

And in <1994Dec23.115040.4648@driftwood.cray.com> Chuck Matthews replied:
>I have to agree with Scott. I have some strong reservations on the 
>feasibility of this approach. From a general consideration the goal 
>of allowing non-programmers to write computer programs has been attempted 
>by many different companies with little success. While I still believe that
>this is a worthwhile goal, I don't think that this particular approach will 
>achieve it. 

That is just what we wanted to say! We will not let the domain expert
do his own programming. No, the actual programming (the back-end) is
automated! We have an example in which the domain expert describes in
his terminology a production process (front-end) and both a simulator 
(back-end 1) and a diagnostic tool (back-end 2) of the production process
are automatically generated. The domain expert can fully concentrate on
describing the relevant production parameters and their interrelations
and doesn't have to bother on Fortran or C bottlenecks and neither on
numerical algorithms to solve differential equations. Other experts
have already brought in these expertises! Note that in this approach
we also have re-use of domain knowledge.

In that respect we agree with John Stauffer who wrote in
<D1H1pF.CCn@tyrell.net>:
>The language paradigm only applies to the input of data and places no
>constraints on how that data is used or stored after it has been entered.
>The information could be processed and then placed in some centralized RDBMS
>if application integration is important; or write another problem oriented
>language transforms the data from the disparate applications into some
>common data format.

We will certainly not go as far as Eric Marshall who wrote in
<3derbt$cqm@portal.gmu.edu>:
>We don't *want* programmers writing applications, we want
>domain-experts (or even not so expert) doing this. We don't even want
>programmers writing our domain-specific tool environments, because we
>want domain-experts to do that too!

-- MAINTENANCE
We believe in our approach especially because of its maintenance opportunities. 
New problem descriptions can be added by the knowledge author without
any modifications. If minor changes are needed, for instance in the
user interface (for the knowledge author or for the end-user), then
often a local software engineer can do the job. Only in case of major
changes (think of extensions of the domain model or adding a new task, which
does in general not influence the front-end in use by the knowledge author)
then a software architect has to be recruited. Our statement is that this 
will happen not that often. In the day-to-day business the software engineer
(or the domain expert behaving as a software engineer) is out of the
critical path.
We are aware of the fact that not every application is satisfying the
conditions to make this all possible. However, we have seen in our
environment sufficiently many applications that do, which makes us
optimistic about the generality of the DSF-approach (not yet of the 
constructed tools!).


-- GENERALITY VS. SPECIFICITY
Ralph Johnson warned us in <johnson.788537339@hal.cs.uiuc.edu> by
writing:
>The problem is that it is hard to invent a language that is powerful
>enough to get work done, but simple enough for nonprogrammers to
>learn.  You don't want to fall into the "Turing tarpit" and just end up
>inventing another general purpose language. You want your language to
>*less* than Turing complete so that people who use it really *aren't*
>programming.
An even more pessimistic statement came from Duncan Campbell in
<3eb0je$dje@jhereg.mdd.comm.mot.com>:
>In  my experience with systems implementation and testing, the most
>common problem groups are those associated with the use of non-turing
>languages.  They are always problematic in that user expectations often
>exceed the system's capabilities. 

This is a difficult point, but one thing we are certain of: in our case
Turing completeness is a non-issue. We don't make application
languages, but domain languages. The knowledge author only has to
describe declaratively the domain data and knowledge, not the
exploitation routines! But on the other hand as soon as the domain concepts 
are better understood there is always the tendency to further
abstract from the details and to end up with a very generic knowledge
model with corresponding domain language. This is a point were every
software architect and knowledge author have to been alert on; keep it
simple! The abstraction level must well fit to the general abstraction
level of the experts of that particular domain.


We have really appreciated all the valuable comments that are made so
far and will appreciate further reactions on this more detailed
description of the DSF-approach. As promised before, all the
interesting pointers to persons and other types of information will
certainly be followed.


Sincerely yours
Paul van Loon

