`(12) Patent Application Publication (10) Pub. No.: US 2004/0006765 A1
`
`Goldman
`(43) Pub. Date:
`Jan. 8, 2004
`
`US 20040006765A1
`
`(54) LIVE SOFTWARE CONSTRUCTION WITH
`DYNAMIC CLASSES
`
`(52) U.S. Cl.
`
`............................................ 717/116; 717/109
`
`(76)
`
`Inventor: Kenneth J' Goldman, Clayton, MO
`(US)
`
`Correspondence Address:
`WOODCOCK WASHBURN LLP
`ONE LIBERTY PLACE, 46TH FLOOR
`1650 MARKET STREET
`PHILADELPHIA, PA 19103 (US)
`
`(21) Appl, NO”
`(22)
`Filed:
`
`10/414’670
`Apr. 16 2003
`’
`Related US. Application Data
`
`(60) Provisional application No. 60/373,855, filed on Apr.
`16, 2002.
`
`Publication Classification
`
`(51)
`
`Int. Cl.7 ....................................................... G06F 9/44
`
`‘-
`
`71: ShapePanel extends ‘a-vnx.swin JPanal
`gala 303w gvarna
`
`I
`
`V
`
`ABSTRACT
`(57)
`A system for software development provides an underlying
`object-oriented programming language and a language
`front-end supporting software development in a program-
`ming methodology of the object-oriented programming lan-
`guage, the system providing a graphical programming envi-
`ronment permitting access to classes of the object-oriented
`programming language and permitting subclasses to be
`defined and modified dynamically (“dynamic classes”)
`while the software under development is executing. Modi-
`fications to the dynamic classes can be reflected in future
`instances of the classes and in instances of the classes
`existing prior to the changes.
`In one embodiment,
`the
`object-oriented programming language is Java. The dynamic
`classes coexist with compiled classes of the object-oriented
`programming language, the dynamic and compiled classes
`each being capable of calling methods on instances of any
`class. The dynamic classes may be created as subclasses of
`other dynamic classes or of compiled classes (“parent
`classes") and may selectively override methods of the parent
`class,
`
`
`
`[Manual];
`/
`,
`
`juetshapeset
`_.________.
`V
`
`4
`9.
`pJ
`
`-I
`
`,
`
`,
`
`7
`
`s“
`
`
`
`
`
`
`
`
`
`
`
`
`,
`
`.,
`
`v
`,, ,
`
`,
`
`‘! pvsnidesJPanel'g palnl melhod to draw all the shapes In a tulle tlion
`:3 [description 7 77
`7‘7‘
`
`5
`
`a,
`.;
`g‘
`f,
`i)
`
`”
`
`" 2‘,
`‘ ;‘ “ ’
`)i
`.awl.6ranhlcsm i.
`
`r
`
`,
`
`.
`1,,
`f
`
`‘
`
`_.
`
`,
`
`'
`
`_
`5
`«A _..........._N
`5 aia.uzil,r'30
`I
`a TI
`
`'
`
`-
`
`'
`
`E J
`
`I; smile
`m
`u final
`[fl synchrunlzau
`
`Banana"
`
`\ Innmcea I
`
`jurolacled
`nckn B
`"
`a
`Prime
`L Dlracl access ls permitted by
`h,
`alt classes.
`
`\
`
`,
`v
`
`“
`
`'
`
`,r
`
`‘
`‘
`
`I"
`i
`V
`‘R i
`i
`__
`__
`Shapes“ a ..
`I
`“7‘
`‘
`= {-5
`'
`V
`)VBOYIOM.RLIGNMENT ‘1
`‘
`.
`..
`y
`)
`_.
`,
`, ,
`.
`
`)CEMIEFLALIGNMEMT ‘3 l
`tLEerIrmMnn ‘3‘
`l(‘vmom mailman" aIf)"
`i‘ :
`—
`"
`' ‘
`‘
`s
`"
`'7 7'
`'
`;
`;uuumuzu_couumon
`Twasuvmczsronvorvrocu '
`T‘wusujocuszn it)
`WHEN_|lI_FOCUSED_WllID
`
`‘ methods
`‘ .
`7,
`‘
`‘ unghaoaSet
`N
`'l.x
`1’_,selShapeSet
`
`a
`l
`--,r
`,
`
`'
`
`L,
`
`,.
`g:
`
`‘ .13k__.;-—.
`‘7 I; )luuuwlgu-em a)
`I
`‘4 )uuummonjea ‘57-
`'
`"
`" '
`
`Page 1 of 24
`
`GOOGLE EXHIBIT 1024
`
`Page 1 of 24
`
`GOOGLE EXHIBIT 1024
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 1 0f 7
`
`US 2004/0006765 A1
`
`ShapePanel extends 'avax swingJPanel
`,
`
`View Elan“: Cunmruclms Mathilda Bemwlms Instances Help
`EFila Ed" Dal
`variables
`- Methods
`' WW,
`r
`‘*
`:DETShapeSet
`.J K7
`V‘
`,,
`7
`salinapesat
`
`',
`
`f
`
`'
`
`‘
`
`‘
`
`,
`
`,
`
`..
`shapaSet QI
`)aorrouALIGNMENT .3)
`WW
`_\\
`CEHTHl_ALIGNMENT
`:j
`\
`LEFTJlLIGNMEIIT
`E
`~
`-3
`nulsm ALI NMIINI fl.)
`-
`”'
`G
`j,TooL_nP_IExt_KEV gt)
`.
`-
`é“ '
`V
`'
`'
`‘TOP_ALIGIIME|II W )
`UNDEFIHEUCONDITION #3
`,1WIIEH_ANCESY0R_OF_FOCLI
`
`,
`
`
`-
`,
`[ «descllpdlan , 7,
`~
`,
`~
`.
`/
`A
`w
`,
`, OvamdesdPanel's palm method in draw all the shapes \n a collection
`J
`'
`'
`‘
`" '7
`_'1hrows-
`--~
`
`[ram as I)inun.am.Graphicslfl {3E
`
`
`
`«
`
`
`
`
`
`
`
`
`)IVMM.PonupMenu IN
`
`/, DIShJDOSOt
`"V”..M‘fl"
`.t
`26439
`.
`'9
`
`W a .kw» 34H»? f
`jurapmcs
`._
`Idlnn
`
`Ejun..nmEuam _
`E2:—jun-nu..oujnn 3"
`,— .
`dd
`
`,,
`
`E )avuwlpumpnnnnl 0?-
`(add
`
`=
`
`I
`
`
`
`'
`
`‘
`
`'
`
`‘
`
`jproiacied
`ackn a
`n
`"
`Firms
`I‘E
`'Dlvact access Is nevmmed by
`'
`all cla5ses
`
`‘
`,
`
`m
`[LJ stalls
`mflnal
`Ii] synchronllad
`
`
`
`FIGURE 1
`
`Page 2 of 24
`
`Page 2 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 2 0f 7
`
`US 2004/0006765 A1
`
` Ipackagas and Classes .51.. i..
`
`gun Dahuu
`31.1mm: s" V
`<
`,
`U
`I»
`.
`- ,,
`A
`
`
`
`
`
`”-‘HW ,
`
`,
`”ajnjldflmo
`
`
`isetBacKuround
`5
`.
`:‘Hesmmnn - Arrirw
`A
`i
`
`4
`a
`I
`if
`F
`E
`i
`f
`5 nnai’amm W Almrnhmriahlu.
`
`
`‘
`,
`_
`:f
`
`
`1
`I}
`:1
`j
`i
`“vimmnur'
`
`
`
`i
`Q; JApplgtSAccassihleJAppl
`
`
`.‘
`,I'
`8 WV ,_
`-
`,
`l-Ifllmfln'
`
`
`
`
`
`
`‘:
`i
`kaii‘nnmiomnl
`Q; JaunonMccaxsmIsJBunu
`
`
`
`a?“ JCW’CBB‘FE ‘ Jauaflwlfimm' 2 i
`
`
`‘ ‘
`V
`.
`,; .
`
`
`,m Sackga‘oum‘ {:3
`
`
`
`
`
`
`
`y'de
`tmxm
`,,
`, w
`-7
`,
`,
`,
`_
`i
`
`
`
`M
`W
`.
`Q
`-' AJButtu Ihalfl hearts:
`1
`§
`,ezeflhckglnumi
`
`
`
`.
`‘
`javekwucmar
`,Mvmuusw—«zwm-mW i
`7
`
`
`
`amdmd ‘
`
`
`Q tuhlic
`.
`E
`,
`lurnmmmi
`g
`,
`‘
`‘
`;
`package
`‘
`'
`
`
`
`
`
`»
`
`i 9
`
`urn/Mu
`Direct access l5 permuted by
`‘all classos.
`
`ii3
`
`i!
`.
`g
`‘
`
`[
`I
`
`f
`A
`,
`’
`
`
`
`i
`§
`
`i
`
`E
`r
`
`
`
`
`
`
`'
`
`
`w
`‘ fidurauncwwm H)
`dulaumcun Q )
`.\
`flnlmanuIn “Q:
`I y
`'
`.
`,_uism1\mlh:un 9.-
`_
`J ,
`v
`a
`‘“ '
`,}fi$ahkfii§fih¥w§(.‘d‘dzfin “a;
`‘
`fiiumumn 35,
`
`s
`.
`,
`;
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`«auxmmg. W nd
`..
`r“
`M.Culm 5’)
`
`_.__
`__._
`
`.J.‘
`I
`
`'3
`
`
`a 1mm)
`
`i'
`
`,
`
`l
`)dux\.ilfl”.ll00lcAll 3%_
`
`*—~ ,
`,.._.__.___._
`scmnckijimmu
`-'
` \
`ijvemVef‘iOiM f?
`Em [50mm
`
`: I
`
`E
`
`)nulsufiwmntbord M .Botdur
`
`
`
`
`lgiaw» ‘ca
`0))
`
`FIGURE 2
`
`Page 3 of 24
`
`Page 3 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 3 0f 7
`
`US 2004/0006765 A1
`
`
`.0!“ *2
`
`
`ila Edit Model
`\_fiew Qaniwllers Cngstructurs Methods gahaviurs
`[nstances Help
`
`
`
`
`real ”use...
`
`at mamas,“
`immune
`.\
`
`‘vanamm
`#"
`game all
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` 0:,
`
`9' m sunw
`0' myclasses
`
`(a)
`
`
`
`
`
`mmhmls
`
`
`: ‘
`
`
`
`l—destrimin:r~—v—-—>—-w—~—~-~~——v————v~—‘
`
`,M
`,,
`,
`EL..,,,,,
`gewariablm
`f!)
`_
`‘
`
`
`
`\ saNariahlm
`, m
`«
`,
`,
`[delaullvnlue
`(33‘
`\.... _
`!
`
`
`
`W» Hz.
`
`
`
`mmangilntcger
`
`
`
`\variablet
`
`xllmtculs
`
`
`
`,
`1..
`,.
`
`.
`COIIBCHDIIS
`I4 Boolean
`
`
`
`A Charactel
`.J______'cun_|ptinems 91:1 Double
`
`. final
`
`3,2 Integer
`
`
`,# Luna
`7
`7 7
`(109B! “mull
`
`
`‘Q; final ngnh
`dflrflllll value
`
`
`
`
`
`
`_ messag 9
`
`mean ipliun
`the lento appear on [he hufiun
`'ucrault value
`
`
`IV gelMessage
`
`E's)
`
`
`
`
`
`
`(C)
`
`FIGURE 3
`
`Page 4 of 24
`
`Page 4 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 4 0f 7
`
`US 2004/0006765 A1
`
`YEW-time}
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘message
`
`‘gqu
`
`
`
` 1w!CoMrollms kanslmot
`(a)
`
`Y when I) V
`H
`actimltnmmamj “.C ‘/
`
`i
`, umunMup Q' V
`I\
`.i
`illlfllllnl:nix .) V
`
`
`\alignmcm‘v’. »V
`
`
`
`(b5
`
`FIGURE 4
`
`Page 5 of 24
`
`Page 5 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 5 0f 7
`
`US 2004/0006765 A1
`
`
`
`
`(a)
`New constructor cum!
`
`
`
`
`‘ [descrmnmr—«<»—»*«A—-.->
`
`
`
`
`
`
`, EammedeGfl
`
`
`
`
`{{Inflihud ' Flee ngBunon
`
`
`
`
`
`
`Instances
`:
`
`
`fflflgrnnflfinvr‘frz
`2. Conflayteccfi
`
`
`
`ESwaps the background and foreground.
`
`
`Fnarammemw
`«
`1
`Iucmwnz
`7 w‘W
`
`ii
`A
`
`
`1 mueaihu imnuspeliseconu VJ
`\
` until
`
`[9151:
`; method DDWW4
`
`
`a
`l'lnmkgrnund
`
`
` struciors Methods
`
`
`
`Vlew [‘Comrollars J59”
`
`
`
`
`
`
`
`
`
`
`D ilmlic
`
`
`
`protected
`package
`
`
`private
`
`
`
`
`mum access Is permitted by
`all classes,
`
`
`
`
`
`FIGURE 5
`
`Page 6 of 24
`
`Page 6 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 6 0f 7
`
`US 2004/0006765 A1
`
`jam
`:7“descrimiun
`
`
`“If“; [wig—.Z;m:_wum.u__ .....I=.'.._.\;2.Z;.AI .........L.
`
`
`J. Chatamer
`l)colimhfis }: Boolean
`
`.cwnnonams 2.}; Double
`4
`P'WWL, Float
`:43? Menu:
`f _.
`
`’uammetum * *I 1
`
`‘3: Long
`(1 MRI"
`Q) vum
`
`"“M’R‘T!EW"’“W"~T‘W”‘
`
`21. Object
`‘ memml MW
`
`
`
`
`
`
`
`
`\
`
`
` nrmszmen
`
`
`
`
`
`
`
`
`E
`}
`
`f iI 2
`
`
`
`it)
`
`I result
`i1
`1,
`I
`
`
`
`
`
`
`
`
`package
`
`mmm
`
`Direct access Is aarrnmad by
` -
`aH classes,
`
`.IL
`M
`L
`,
`
`
`
`
`
`FIGURE 6
`
`Page 7 of 24
`
`Page 7 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 7 0f 7
`
`US 2004/0006765 A1
`
`1—i
`
`ilfile Edit Mudel View Cummllem Constructing Methods Qchavlurs [Hana-Ices
`
`
`
`E'VFLHMHC‘S
`-
`r‘iillnllfllimil
`
` ‘mt'z
`i
`
`In
`If
`
`
`.,
`,
`_ We",
`
`
`
`
`
`1A7.
`1Elle Ed" Model View Controllers Constructnrs Methods Enhau
`7 acliunP afiormad
`
`
`5
`’ {11081}! imanW’WW.
`
`
`
`
`
`
`
`
`
`
`
`-\
`'
`0-5! #3
`
`3
`“message
`5'},
`
`
`
`unflned
`
`“’4 ,‘__.._M__.w,,fi,,, 777.: fifiea
`
`[tirwcriunmrnu.....i._'.__..._mm.m m .
`i
`r,
`
`
`
`
`
`mmnpwnrmauummimnmwmmm)
`
`
`
`
`
`g ntusGaInsuummMMJocusEvem)
`
`
`
`ncusLnnumammmmcusmm)
`Mndal’
`"L:
`View
`
`
`ouseClIckedumawl.Mm.MouseEvem)
`
`
`Carmina; {finals Estimate z‘mmamas
`ouseEmatedUava.uwl.wunl.MnusnEvent)
`
`
`ussExll ndtjmvuwlmnmimnusafvam)
`
`
`ousaMmdflm.aM.MlflMwseEvamJ
`
`
`V
`
`
`
`
`
`
`
`
`FIGURE 7
`
`Page 8 of 24
`
`Page 8 of 24
`
`
`
`US 2004/0006765 A1
`
`Jan. 8, 2004
`
`LIVE SOFTWARE CONSTRUCTION WITH
`DYNAMIC CLASSES
`
`RELATED APPLICATIONS
`
`[0001] This application claims benefit of US. Provisional
`Application Serial No. 60/373,855,
`filed Apr. 16, 2002,
`entitled, “LIVE SOFTWARE CONSTRUCTION WITH
`DYNAMIC CLASSES.”
`
`FIELD OF THE INVENTION
`
`[0002] The present invention relates generally to software
`development, and more particularly to a method and system
`for creating software using a visual rather than textual
`representation, further providing that program modifications
`be made while the program is running.
`
`BACKGROUND OF THE INVENTION
`
`[0003] Creating tools for efficient software development
`has been a longstanding goal of computer science, starting
`from the first compilers and continuing to today’s visual
`languages
`and
`integrated
`development
`environments
`(IDEs). Significant progress has been made, but the fact
`remains that custom software construction, even for rela-
`tively small applications, is a slow and difficult process,
`successfully accomplished only by people with substantial
`training and experience. Moreover, in spite of advances in
`software development tools, formal training of competent
`programmers remains a labor-intensive and time-consuming
`task. Introductory programming courses continue to be ‘rites
`of passage” in which only those who are willing to contend
`with a steep learning curve in an artificial syntax survive.
`The end result is that few people have ever been exposed to
`the idea of software construction, and fewer still have
`actually built an application. If we are serious about putting
`the power of general-purpose programming into the hands of
`more people,
`then we need to be serious about creating
`software tools that enable people to create software in ways
`that are attractive, comfortable, efficient, and reliable.
`
`[0004] Background Definitions
`
`[0005] This invention concerns tools for the simplification
`of object-oriented software construction. An obj ect-oriented
`programming language is one in which each component of
`a software system is an object, which is an instance of a
`class. A class may be thought of as a definition of a type of
`object, and each instance of the class is said to belong to that
`type. Each class provides one or more constructors for
`creating instances of that class. Each object, in accordance
`with its class definition, contains instance variables for
`storing information and methods for accessing and operating
`on that information. Each method may be defined to accept
`parameter values, which provide additional information to
`the method when it executes. Each method may optionally
`contain local variables that are used to store the results of
`intermediate computations, a method body that contains a
`sequence of steps (or statements) to be carried out by the
`method, and a return statement that determines the value to
`be returned as the result of when the method completes.
`Classes may be extendcd to create subclasses that inherit
`methods of the class. A subclass definition may include
`additional methods and/or override inherited methods in
`order to achieve more specialized behavior. Object-oriented
`programming languages are traditionally textual languages.
`
`A text editor is used to write the source program which is
`subsequently compiled or interpreted for execution. When
`one or more classes need to be modified, the source code
`typically must be changed, and the execution must be
`restarted from the beginning, possibly using any information
`that the previous execution might have saved in one or more
`files.
`
`[0006] Further Background and Motivation for the Inven—
`tion
`
`[0007] Successful tools scale. They allow novice users to
`get started quickly, and they support experienced users in
`more sophisticated tasks. However, tools for software devel-
`opment generally do not scale well from novice to expert.
`Instead, software tools appear to be targeted to one of two
`groups. Either they are written “by programmers for pro-
`grammers,” in which case the user is assumed to have a
`significant amount of experience, or they are written “by
`programmers for non-programmers," in which case the
`expectation is that the user is not (and never will be) a
`programmer, and therefore does not need a “real” program-
`ming language, but instead a “toy” programming language
`suitable for building only simple applications. Non-pro-
`grammers who attempt to build an application using a tool
`designed for programmers must be relatively determined
`and have the patience for a great deal of self-teaching. On
`the other hand, individuals who gain some experience in a
`tool for non-programmers and later wish to develop serious
`applications are likely to discover that their “toy” language
`doesn’t adequately support the task. In that case, they will
`need to abandon their first tool for a “professional” one,
`giving up the familiarity of the tool and, more importantly,
`the software development methodology they have learned
`within it.
`
`[0008]
`
`Integrated Development Environments (IDES)
`
`integrated development environments
`[0009] Today’s
`(IDES) generally fall into the “by programmers for program—
`mers” category. Such systems are umbrella applications,
`combining an editor, compiler, run-time system, and debug-
`ger all under one roof. For example, IDEs supporting
`software development
`in Java include lnprise (Borland)
`JBuilder, Sun’s Forte for Java, NetBeans, IBM VisualAge
`for Java, Webgain (Symantec) Visual Cafe, and Metrowerks
`Code Warrior, among others. Many of these environments
`provide programmer support, including a GUI builder that
`permits rapid specification of the layout of the graphical user
`interface. Construction of the GUI is usually “live” so
`changes in relationships between the GUI and the underly-
`ing data model are reflected instantly. However, all of these
`systems are built on the assumption that,
`in the end, the
`underlying functionality of a truly custom application is
`written in a textual language by an experienced programmer
`who is familiar with the syntax of the language and is adept
`at understanding compilation errors and tracking down
`program errors. To support writing code in the textual
`language, these environments provide source code editors
`with helpful features like text colorizing and method name
`completion. When compile time or run-time errors occur,
`these environments provide help in navigating the code to
`quickly locate the offending line of text. But these features,
`although handy for programmers, are of little help to the
`individual without programming experience.
`
`Page 9 of 24
`
`Page 9 of 24
`
`
`
`US 2004/0006765 A1
`
`Jan. 8, 2004
`
`[0010] Visual Languages
`
`[0011] Visual languages are designed for programming
`environments in which software is constructed by direct
`manipulation of graphical language primitives and opera-
`tors. They are typically new languages (as opposed to
`graphical front-ends for existing languages), and they are
`generally based on execution models that are deemed to be
`particularly well suited for visual expression. Usually, these
`languages provide a tight integration of editing and program
`execution, and in some cases the program can be edited
`“live,” while it is running.
`
`[0012] Most visual languages are at the other end of the
`spectrum,
`in the category of “by programmers for non-
`programmers.” Many visual
`languages have been con-
`structed using a variety of paradigms. One of the most
`common paradigms is dataflow, in which data flows across
`“arrows” to trigger actions performed in “boxes.” Some
`examples of datallow visual languages are Show and Tell,
`one of the first dataflow visual languages, designed to be
`accessible to children; Prograph, which has been developed
`commercially; Khoros, which has been targeted for image
`and signal processing; and our own distributed application
`configuration language. However, visual
`languages use
`other paradigms as well. Forms/3 introduces procedural
`abstraction withm a declarative programming spreadsheet
`paradigm. ThingLab uses a constraint—oriented paradigm to
`support the construction of geometric models. Statecharts
`supports software development with a nested state-machine
`paradigm, VIPR uses arrows and nested rings to declare
`program behavior with elements of object-oriented pro-
`gramming. AgentSheets provides a rule—based paradigm for
`specifying how interacting agents gather and process infor-
`mation. Stagecast (a commercial realization of KidSim and
`Cocoa uses a combination of rule-based programming and
`programming-by-example to support children in developing
`video games and simulations.
`
`[0013] Sometimes, visual languages are described as “cute
`toys,” but many visual languages have been successful, both
`academically and commercially, particularly when the lan—
`guage supports application development in a specialized
`domain. However, for general-purpose programming, pro-
`fessional software developers have preferred textual
`lan-
`guages over visual languages because the expressive power
`and scalability of textual languages provides more flexibil—
`ity. For this reason, colleges and universities generally have
`not adopted visual
`languages as a means to introduce
`students to programming and computer science. This could
`be partly because the faculty do not consider them “real”
`programming languages, but more likely it is because the
`thought process involved in constructing programs within
`visual languages is so strikingly different from that of the
`more widely-used textual languages th at it would be difficult
`to justify asking students to devote significant time and
`effort to learn these visual paradigms only to abandon them
`later.
`
`[0014] Neither IDEs nor visual languages are very suc-
`cessful at serving the novice user who wants a smooth
`upgrade path into the world of professional programmers. A
`fresh approach to programming environments is needed.
`Rather than targeting an environment to either “program-
`mers” or “non-programmers,” we maintain that thinking of
`a programming environment as being written “by program—
`
`Page 10 of 24
`
`
`
`mers for new programmers” has the best chance of giving
`ise to significant advancement in both programmer produc-
`ivity and computer science education and outreach. If we
`design environments not only to enable novice programmers
`o achieve early success, but also that grow with these
`Judding programmers as they gradually become more
`sophisticated, then two important gains are achieved. First,
`we will have created a situation in which the concepts and
`ools individuals learn while creating their first simple
`arograms will continue to apply when they begin scaling up
`0 practical applications. Second, potential users of the
`environment will be able to expect
`that
`their effort
`in
`earning these concepts is likely to pay off in their profes-
`sional productivity over the long term. Therefore, they will
`lave the incentive to invest the time in the first place. As a
`result, we need to provide an environment that supports not
`only the creation of simple applications, but also the con-
`struction of practical software that fulfills real information
`processing needs. Furthermore, we want the development
`process to be consistent with professional practice. We
`believe that having such an environment is a critical ingre-
`dient in any outreach effort that seeks to bring the power of
`general-purpose computing to a larger population.
`[0015] The present invention incorporates not a new lan-
`guage (visual or otherwise), but something that we call a
`anguage front-end. This idea is based upon the following
`observations. First, we recognize that modem textual pro—
`gramming languages have evolved over the entire history of
`computing. The success of high-level languages like For-
`ran, C, Pascal, Smalltalk, Lisp, C++, and Java is primarily
`attributable to their support of abstractions that make the
`arogramming process more natural and that can be mapped,
`3y a compiler or interpreter, to efficient execution. Proce-
`dural abstraction, parameters and return values, abstract data
`ypes, encapsulation, iterators, objects, methods, class hier-
`archies,
`inheritance, and polymorphism are examples of
`abstractions that have driven the evolution of high—level
`anguages. These abstractions transcend programming lan-
`guages. They support programming models that allow
`aeople to think about computations at a higher level. Each
`ugh-level language provides constructs for expressing the
`abstractions in its programming model. Constructs are
`designed to provide compact and unambiguous expression
`of these abstractions in a way that
`is both readable by
`lumans and efficiently processed by a compiler. At the same
`ime, we recognize that textual languages are too open-
`ended and error—prone for the inexperienced user, so an
`environment that exposes a novice user to a text editor and
`compiler is likely to meet only limited success. The goal is
`10w to get the best of both worlds: the accumulated expe-
`rience embodied in modern textual languages and the user-
`‘riendliness of non-textual programming. In achieving this
`goal, a key observation is that the set of abstractions, not the
`articular linguistic mechanisms, that account for the suc-
`cess of high-level
`languages. Our approach develops a
`anguage front-end that gives its users the powerful seman-
`ics of an underlying textual language, yet delivers that
`aower within the relative comfort of a graphical user inter-
`ace that supports working directly with the abstractions
`arovided by that language. In other words, we advocate not
`designing a new language, but instead putting a sensible face
`on an existing general-purpose language.
`[0016] However, a “pretty new face” is not enough by
`itself. Users are accustomed to interactive software appli—
`
`
`
`Page 10 of 24
`
`
`
`US 2004/0006765 A1
`
`Jan. 8, 2004
`
`in immediate and
`cations in which user actions result
`appropriate feedback. For example,
`the days of running
`word processing commands through a text formatter are
`over for most users; they expect an interactive WYSIWYG
`experience with relevant and timely feedback. Conse—
`quently,
`the write-compile-execute separation, with its
`delayed and seemingly-obscure error messages, can be a
`surprising and unwelcome paradigm for novice program-
`mers, and it wastes precious time for even the most expe-
`rienced. Novice programmers expect
`the programming
`experience to be live, so they can modify the program
`dynamically during its execution. Therefore, there is a need
`in the art to develop a language front-end for a powerful
`underlying textual language, and couple it with a run-time
`system that supports live software construction. The present
`invention satisfies this need.
`
`SUMMARY OF THE INVENTION
`
`invention discloses a novel visual
`[0017] The present
`programming environment
`that
`lets people build entire
`applications interactively while harnessing the power of a
`modern object-oriented programming language. The present
`invention supports live software development in which all
`aspects of a program’s behavior can be modified while the
`program runs, without the write-compile-execute cycle that
`routinely bogs down software development. The environ-
`ment enables first-time programmers to achieve early suc-
`cess, without the steep learning curve that typically precedes
`development in a traditional textual language. At the same
`time, the environment transparently exposes the capabilities
`of the underlying programming language so that more
`experienced developers can leverage object-oriented soft-
`ware development techniques.
`
`[0018] The present invention intersects programming lan-
`guages, user interfaces, visual
`languages, programming
`environments, and run-time systems, and is directed toward
`the development of language front-ends that provide their
`users with the powerful semantics of a proven underlying
`textual language, yet delivers that power within the relative
`comfort of a graphical user interface. Language front-ends
`promise to transform the way people think about general-
`purpose programming and to make the power of software
`creation accessible to a much wider and more diverse
`population, The present
`invention has the potential for
`significant and immediate impact in both programmer pro-
`ductivity and education.
`
`invention develops a
`the present
`[0019] As discussed,
`better union between programming languages, run-time
`systems, and human-computer interfaces to construct a new
`kind of programming environment having the following
`aspects and features:
`
`l. Scalability. The environment must support
`[0020]
`the construction of simple applications by novice
`programmers, as well the construction of sophisti—
`cated software systems. The tool must support, not
`limit, growth and creativity.
`
`a Modern
`2. A Language Front—End For
`[0021]
`Object-Oriented Textual Language. The underlying
`language must be sufficiently well-developed to sup-
`port the development of a wide range of sophisti-
`cated applications using modern object-oriented
`design techniques.
`
`3. Semantic Transparency. The language
`[0022]
`front-end must support the same programming meth-
`odology as the underlying language so that users
`may leverage the power of the underlying language,
`including access to compiled classes and libraries.
`
`4. Live Software Construction. The environ-
`[0023]
`ment must support
`the dynamic modification of
`classes during program execution, and those modi-
`fications must affect not only new instances of the
`classes, but also existing instances.
`
`Interoperability with Compiled Code.
`5.
`[0024]
`Instances of dynamically modifiable classes must
`interact seamlessly with instances of traditional com-
`piled classes. Instances of dynamically modifiable
`classes must be able to create instances of compiled
`classes, and access their fields and methods. More-
`over, when dynamically modifiable classes extend
`compiled classes and override their methods, com-
`piled classes must be able to call the dynamically
`modifiable methods polymorphically.
`
`6. Enactive Declaration and Use. In keeping
`[0025]
`with accepted user-interface design philosophy,
`direct manipulation should be used wherever pos-
`sible,
`in place of indirect commands and textual
`identifiers. Directly grabbing or selecting types,
`methods, and variables prevents ambiguity, avoids
`name conflicts, and eliminates masking Ideally, tex-
`tual names should be used solely for documentation
`purposes.
`
`7. Semantic Visibility. Properties of expres-
`[0026]
`sions, such as the scope and type of variables and
`expected parameters of method calls, must be readily
`visible to the user. This design goal, together with the
`previous one, saves users from the need to retain a
`mental map from identifiers to information about
`their targets.
`
`8. Spatial Consistency. Each kind of program-
`[0027]
`ming activity must occur in a consistent position in
`the interface. For example,
`instance variables are
`declared in one place, a method’s parameters in
`another. We expect this to increase code organiza-
`tion,
`improve user familiarity, and speed up the
`learning curve.
`
`9. Syntactic Consistency. The language front-
`[0028]
`end must make it impossible for the riser to express
`anything that is syntactically incorrect. In addition,
`type mismatch errors must be obviously and imme—
`diately flagged so users can correct them while still
`focused on the offending expression.
`
`10. Learning Curve Management. The tool
`[0029]
`must be designed with the user’s learning curve in
`mind. This has obvious implications for system
`usability and documentation, and deeper implica-
`tions for the way the environment is structured to
`support developers with a wide range of experience.
`The environment must simplify the common case,
`providing streamlined support
`for programming
`tasks that are common to many applications, such as
`automatic creation of accessor methods, handling
`common user events, creating periodic threads, and
`layout of typical graphical user interfaces. At the
`
`Page 11 of 24
`
`Page 11 of 24
`
`
`
`US 2004/0006765 A1
`
`Jan. 8, 2004
`
`same time, the enviromnent must support the con-
`struction and deployment of sophisticated custom-
`ized applications using arbitrary designs, such as
`those involving specialized threads, custom event
`handlers, and custom graphics. The goal is to accom—
`plish this without confusing the novice or irritating
`the professional.
`
`between an architect creating a blueprint in a paint program,
`where the units of discourse are lines and pixels, versus
`creating the same blueprint in a computer-aided design tool,
`in which the units of discourse are domain-specific entities
`like walls, windows and doors. Table 1 compares text—based
`and abstraction-based programming in terms of human-
`computer interface design principles.
`
`11. Transitional Support. Scalability dictates
`[0030]
`that users must be able to grow up within the tool,
`rather than outgrow the tool. However, we must
`recognize that any tool, however supportive, has its
`limitations. Furthermore, there is clear educational
`value in being able to write programs directly in the
`underlying language. Therefore,
`it
`is incumbent
`upon us to design the tool in such a way as to provide
`a migration path so that programmers can make a
`smooth transition into the underlying language. This
`begins with semantic consistency, but does not end
`there.
`
`fresh
`invention is directed to a
`[0031] The present
`approach to supporting the programming process, by raising
`a level of abstraction by treating the programming process as
`an application domain. This accordingly results in elevating
`the unit of discourse for software construction by providing
`direct manipulation of semantic elements, so that program-
`ming abstractions become the primitives of expression. In
`turn, this enables a transition from loosely-coupled umbrella
`IDEs
`to tightly integrated development environments
`(TIDEs), in which awareness of program structure creates
`tremendous opportunities for ensuring program consistency
`and supporting truly live software development.
`
`[0032] Treating programming as an application domain
`leads to direct manipulation of domain-specific entities.
`W'hile visual languages have produced systems supporting
`direct manipulation of program entities, visual languages are
`focused on new ways to think about computation that is
`particularly well-suited for visual expression. The present
`invention provides application—level support for already
`widely accepted programming practices. Rather than create
`new languages, the present invention applies human-com-
`puter interface design principles to the problem of providing
`domain-specific support for programming in existing high-
`level languages.
`
`[0033] Elevating the domain of discourse in program
`construction includes having abstractions used in object-
`oriented program design become the manipulated units,
`rather than the characters that describe them. Elevating the
`unit of discourse accomplishes at least two main goals. First,
`the programmer is able to think and work directly in terms
`of abstractions, and is freed from the process of translating
`those abstractions into a code that describes them. Second,
`and equally important,
`the programming environment
`becomes fully aware of the fine-grain structure of the
`program. This creates tremendous opportunities for provid-
`ing timely feedback and enforcing program consistency.
`Further,
`it enables dynamic modification of running pro-
`grams.
`
`In text-based programming, programmers work
`[0034]
`with files of characters. In contrast, abstraction-based pro-
`gramming provides a full complement of domain-specific
`entities that programmers can manipulate to construct func-
`tionality of the application. By analogy, it is the difference
`
`Page 12 of 24
`
`TABLE 1
`
`A comparison of text-based and abstraction-based programming.
`Text-based
`programming
`
`Abstractionebased programming
`
`Principle
`
`Domain-
`specific
`objects
`
`Natural
`operations
`Immediate
`feedback
`
`Constrained
`editing and
`consistency
`checking
`
`Gradual
`learning curve
`(prerequisites
`to starting)
`
`Source code files Variables