Here are some fun numbers, no idea what they mean. Since I imagine they
will be wildly realigned in the NG formatting, I have done it as Lisp so
the truly curious can explore at will:
(defparameter *stats* ;; CL+ MDL FM PS DB MG ARC TNV CS PV
(list (cons 'defstruct (list 0 13 1 2 0 6 0 0 0 0))
(cons 'defun (list 133 46 42 10 54 280 204 32 0 0))
(cons 'defmacro (list 57 54 25 9 18 127 82 6 0 0))
(cons 'lambda (list 34 69 14 14 30 28 89 50 22 8))
(cons 'defmethod (list 18 104 19 47 72 215 271 83 30 16))
(cons 'defclass (list 1 12 0 10 10 21 0 4 0 0))
(cons ':initform (list 14 21 6 6 37 150 162 22 0 0)) ;;
slot proxy
(cons 'make-inst (list 1 5 3 4 4 12 29 8 0 0))
;------------------------------------------------------------
(cons 'defmodel (list 0 0 3 3 16 84 99 46 0 0)) ;;
defclass for models
(cons ':semaphor (list 0 3 3 3 14 112 71 22 0 0)) ;;
slots declared semaphoric
;------------------------------------------------------------
(cons 'smv (list 0 5 4 1 5 28 20 22 0 0)) ;;
model inputs
(cons 'echo (list 0 0 1 0 7 42 8 2 0 0)) ;;
model outputs
;------------------------------------------------------------
(cons 'sm? (list 0 18 4 1 6 208 72 142 0 0)) ;;
rules
(cons '^slotValue(list 0 17 7 0 26 432 128 234 133 124)) ;;
dependencies in rules
(cons 'make-Part (list 0 0 0 0 0 37 11 74 31 26)) ;;
-> make-inst 'someModel
(cons 'ps? (list 0 0 0 2 0 0 3 0 44 19)) ;;
persistent rules
(cons 'def^methd (list 0 3 1 0 3 1 5 1 2 0))))
;; class rules, effectively
Columns are...
CL+ -- extensions to CL we like
MDL -- Semaphors/defmodel implementation
FM -- the crucial Family model used to manage a dynamic namespace whose
population is mediated semaphorically.
PS -- persistent DefModel metaclass
DB -- another RDB-like metasubclass of PS
MG -- ModelGraphics (a la garnet)
ARC -- Archos, a document generation, capture, networking, workflow
management system
TNV -- A Navigator-style interface to documents
CS -- Standard documents required in the application domain across all
projects
PV -- Custom documents for the test project being used for development
The numbers above describe an application which generates, captures,
validates, parses, stores and replicates across a loosely-connected
network predefined forms. A special challenge is that in each project
half the documents will be unique to that project. Another nasty
requirement is that any document can change during the project, and data
must always be viewed in the context of the version of the form in
effect at the time the data was collected. A key module is the
navigator-style module which allows tracking, review and editing of the
forms, as well as a set of front-end forms for the database of entities
documented by the forms. Note that the project is a also a workgroup
application, in that users will be collaborating on maintenance of data
collected from the forms.
Caveat: this was a casual exercise (there is the project to get done),
including no attempt to excise dead code, but the numbers look right:
250 model types, 520 rules, 1100 dependencies, 80 inputs, 60 outputs
(mostly attributes triggering screen refresh). I wager if we do a few
more applications this way, the number of dependencies will correlate
nicely (and linearly) with project cost.
So, taking a hundred dependencies as our unit, right now this project is
an "11".
kenny