Compare this:
Scot A. Becker's Perspective and Abstraction (JCM Dec. 2000):
There are two orthogonal classifications of models:
_____________ | language | problem (domain) prototyping | development |--------------+.......> teaching | processes | | language research |_____________| | intermediate representation | solution | computer communication | (domain) | ... | ____V________ __V__ | implement. | / \ prog. lang. | activities | | implem.| application | during | problem (domain) | prog. |------------->|(different |----------------. | langs. | (domain) | sorts of) | | \______/ | program | | : : | development | | : : :| processes | | : : : |_____________| | : : : | solution | : : : | (domain) | : : : | | : V : ___V____ program ____V_______ : CASE : / \ application | | : developers | | (domain) |(different | : | programs |------------>#| sorts of) | : | | \ / / | activities | V \________/ | | |____________| compiler/ | | interpreter ..................\ program application developers / processing interface
Many requirements will depend on specific characteristics of the targeted program development process. Some requirements are always of concern (but with different relative importance and with different importance relative to additional requirements).
Compare that to programs:
A general purpose program
supports several different sorts of activities,
i.e. can be applied in different (program) application domains.
E.g. an operating system package with utility programs (Windows),
a general purpose macro scripting tool,
shells/environments
(Netscape Communicator, Emacs, Oberon, Norton Commander) ...
[you know other, better examples?].
The opposite is an application that supports just
one sort of activity (application domain).
The program application domain can also influence the software process which in turn might influence what the most suitable language is. «Control systems indicate an area of significant use [of formal methods] ... Some applications [of formal methods] are traditional computer science areas such as databases, language processors, and arithmetic units. Timing specification and analysis remains an outstanding problem ...» [FormalInInd]
Program development processes can differ in the following ascpects that might or might not be supported by a programming language.
«The Programming Process: It is advantagerous
to consider the programming process as a kind of modelling.
Seen form a certain viewpoint a computer program is
a concrete model of some system of phenomena.
It is concrete because it can be manipulated directly
(using a computer to execute it);
it is a model because it has been created in order to give
some answers to some problem that exists outside the computer
(or at least outside the program itself).
...
From a slightly different viewpoint, a computer program
is a form of communication. One way to consider this
is that a program is a way to communicate the needs of the programmer
and his or her client to a computer.» [DAOOC++, 21]
[C Liu, S Goetze, B Glynn: What Contributes to Successful Object-Oriented Learning? OOPSLA'92] analyzed the learning success of 495 students after 4 1/2 day introductory courses on object-oriented programming and design with Smalltalk as vehicle in an uncontrolled experiment (observation). The subjective score given by the instructors to the subjects was correlated to several criteria (Attention: Without statistical evaluation, you cannot tell how significant the differences between different criteria's coefficient is):
| Experience indicator | coefficient (simple linear regression) | significance p (likelyhood of random correlation) |
| lifetime lines of code (<100 ... >100k) | .1873 | < .00005 |
| largest program (? ... ?) | .1739 | < .00005 |
| months since last programming (<1 ... >120) | -.1654 | < .00005 |
| most weeks spent writing a program (<1 ... >104) | .1381 | .0003 |
| number of PL families (pradigms) programmed in (0 ... 6) | .1284 | .0002 |
| number of PLs known (0 ... 14) | .0857 | < .00005 |
| Language L | mean score of subjects most familiar w. L (and their number) | mean score of others | difference | significance p (likelyhood of difference by chance) |
| PL/I-dialects (used for systems programming) | 3.44 (28) | 3.00 | -.44 | .0031 |
| C | 3.28 (160) | 2.91 | -.37 | < .00005 |
| PL/I | 2.86 (73) | 3.06 | +.20 | .0422 |
| assembly lang. | 2.79 (42) | 3.05 | +.26 | .0368 |
| Cobol | 2.64 (26) | 3.05 | +.41 | .0095 |
| Basic | 2.57 (12) | 3.04 | +.47 | .0384 |
| Language L | mean score of subjects w. largest program in L (and their number) | mean score of others | difference | significance p (likelyhood of difference by chance) |
| C++ | 4.25 (2) | 3.02 | -1.32 | .0246 |
| C | 3.29 (121) | 2.94 | -.37 | < .00005 |
| assembly lang. | 2.79 (52) | 3.05 | +.26 | .0175 |
| Cobol | 2.75 (33) | 3.05 | +.30 | .0334 |
| Language L | mean score of subjects knowing L (and their number) | mean score of others | difference | significance p (likelyhood of difference by chance) |
| C++ | 3.54 (42) | 2.98 | -.56 | < .00005 |
| Smalltalk | 3.52 (33) | 2.99 | -.53 | .0001 |
| Pascal | 3.22 (254) | 2.82 | -.40 | < .00005 |
| C | 3.15 (342) | 2.76 | -.39 | < .00005 |
| Fortran | 3.13 (187) | 2.96 | -.17 | .0175 |
| Cobol | 3.05 (168) | 3.01 | -.04 | .6398 |
| assembly lang. | 3.03 (237) | 3.02 | -.01 | .8768 |
| Paradigm P | mean score of subjects knowing L in paradigm P | mean score of others | difference | significance p (likelyhood of difference by chance) |
| Procedural | 3.04 (484) | 2.42 (only 11!) | -.62 | .0085 |
| OO | 3.39 (103) | 2.93 | -.46 | < .00005 |
| Functional | 3.24 (119) | 2.96 | -.28 | .0004 |
| Application generators | 2.86 (81) | 3.06 | +.20 | .0345 |
a. Architectural Style
b. Architectural Perspectives used in the SW development for thinking about the system structure: [quotes from SAIA]
| library name | language | classes | depth | max parents | avg. parents |
| Visualworks2 | Smalltalk-80 | 1956 | 15 | 1 | 1 |
| digitalk3 | Smalltalk-80 | 1357 | 14 | 1 | 1 |
| NeXTStep | Objective-C | 311 | 8 | 1 | 1 |
| ET++ | C++ | 371 | 9 | 1 | 1 |
| Unidraw | C++ | 614 | 10 | 2 | 1.01 |
| Self | Self | 1802 | 18 | 0 | 1.05 |
| Geode | LOV | 1319 | 14 | 16 | 1.89 |
| Ed | LOV | 434 | 11 | 7 | 1.66 |
| LOV | LOV | 436 | 10 | 10 | 1.71 |
| Laure | Laure | 295 | 12 | 3 | 1.07 |
| Java | Java | 225 | 7 | 3 | 1.04 |
A "general use" programming language
[Do you know a better word for that?]
supports several different sorts of programming processes,
i.e. can be applied in different (PL) application domains.
One recognized factor of that are the supported paradigms
(see Paradigms):
Multiparadigm PLs support several different paradigms.
A brief reminder of the distinction Analysis/Design/Implementation:
[ProcBack]
Tetsuo Tamai, Akito Itou: Requirements and design change in
large-scale software development:
Analysis from the viewpoint of process backtracking; ICSE'93.
studied two development projects for a mainframe with RDBMS, 4GL and Cobol
w.r.t. the backtracking to earlier software development stages.
Case A was a 550kloc project following the water-fall process model Aug'85-Sep'88.
Case B was a 2000kloc project with prototyping Apr'85-Dec'90.
(1) 40-50% of the backtracking might affect the program:
«Total of 111 backtracking cases were identified for the Case A
and 196 for Case B. They distribute as Table 2 and 3.
Table 3: Process backtracking statistics of Case B
(No data of operation phase are collected yet.)
The row-total which is added here shows that 40% or >50% of the backtracking
happened after starting to write the program.
(2) The program might need to be adapted w.r.t. the following aspects:
«One classification is by function areas
each change to the specification belongs to. The function areas are:
(3) Program adaption might be of the following kind:
«Another classification is by the type of changes:
addition, alteration, and deletion. For Case A, they distribute as follows.
The impact of the implementation language on reusability
will be discussed in PL requirements.
«A software developer's design language is the set
of abstractions over structures in a program.
Software development with classes and objects is now so
well-understood that software developers are extending
their design languages.
The concepts finding their way to the software developers'
design languages express archetypical patterns
of class and object relations and collaborations.
One kind of archetypical patterns are termed design patterns. ...
Frameworks [DesPat, AAF] and design patterns [DesPat]
are software structures on the design level.
If design patterns (DP)
are implemented without support, the following problems occur:
Frameworks and design patterns on the design level
could also be addressed by constructs of a programming language:
How would a general support for frameworks look like?
«A programming language is essentially a toolbox of abstraction
mechanisms. Nonetheless, the abstraction mechanisms of current
object-oriented programming languages are still too low-level.
here design patterns come to the rescue. ...
Gul and Lorenz present a taxonomy of patterns based on how far they are
from becoming actual language features.
Besides Gamma etal's famous 20-some original design patterns...
[Douglas C Schmidt Using Design Patterns to Develop High-Performance Object-Oriented Communication Software Frameworks; Software Technology Conference; 1996]
Table 2: Process backtracking statistics of Case A
(Number shows % of backtracking from column process to row process.)
»
Prelimary Design Detailed Design Programming/Testing
Operation Total
Req.Analysis 14 19 3 4 40
Pre.Design . 27 11 5 43
Det.Design . . 15 2 17
[Total 14 46
29
11 100]
Prototyping Prelimary Design Detailed Design
Programming/Testing Total
Req.Analysis 38 2 1 1 42
Pre.Design . . 8 20 28
Det.Design . . . 30 30
[Total 38 2 9
51 100]
The backtracking instances of Case A distribute over these function areas
as follows. [No such statistics is given for Case B.]
»
input output data model functions
16% 39% 11% 34% ''
We can clearly see the tendency of user's preference that welcomes functional extension
but is reluctant the reduce them. ...
addition alteration deletion
51% 35% 12%
It may be interpreted that the prototyping helps the user
list up key functional requirements in the early stage
and thus reduces the later functional addition.
»
addition alteration deletion
29% 71% 0%
The Program Design/Implementation Boundary
[LSDF97] Workshop on Language Support for Design Patterns and Frameworks;
In: ECOOP'97 Workshop Reader; LNCS 1357; 1997.
[AAF] Palle Nowack: Architectural Abstractions for Frameworks; in [LSDF97]
Class Proliferation. DP implementations need new class definitions
that often specify only trivial behavior such as message forwarding. ...
Difficult Reusablity. ... Although DPs are reused at design level,
their implementation is not reused.» [MPA]
«The software architecture level of system design suggests
the use of components and connectors as basic units.
Components and connectors are used to describe the high-level compositions
of systems independent of the individual components' and connectors'
representations. ...
while(*s++ = *t++) ;
See also some design patterns for Petri Nets.
Relators are cadets relating two objects (pseudo-inheritance).
Architects are cadets describing the structure
of a large number of entities (pseudo-composition).
«For example, data flow languages can be thought
as a more mature form of the pipeline concept.»
Some Design Patterns
Ulf Schünemann 071297, 140801
Analysis
Requirements & Principles
Paradigms
Abstractions
Domains
Features
foundational
safety
flexible typing
Syntactics
Defining PLs
Language List