`a2) Patent Application Publication co) Pub. No.: US 2004/0006765 Al
`(43) Pub. Date: Jan. 8, 2004
`
`Goldman
`
`US 20040006765A1
`
`(54)
`
`(76)
`
`LIVE SOFTWARE CONSTRUCTION WITH
`DYNAMIC CLASSES
`
`Inventor: Kenneth J. Goldman, Clayton, MO
`(US)
`
`Correspondence Address:
`WOODCOCK WASHBURN LLP
`ONE LIBERTY PLACE, 46TH FLOOR
`1650 MARKET STREET
`PHILADELPHIA,PA 19103 (US)
`
`Appl. No.:
`
`10/414,670
`
`Filed:
`
`Apr. 16, 2003
`
`Related U.S. Application Data
`
`Provisional application No. 60/373,855,filed on Apr.
`16, 2002.
`
`Publication Classification
`
`(51)
`
`TInt, C17 eee cceeeeccesseeneeececneneeseecennnseenes GO6F 9/44
`
`(52) US. Ch.
`
`caesscstssssesestsssnecseeasesse 717/116; 717/109
`
`ABSTRACT
`(57)
`Asystem for software development provides an underlying
`object-oricnted 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 programmingenvi-
`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
`
`the
`In one embodiment,
`existing prior to the changes.
`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 mayselectively override methodsof the parent
`class.
`
`‘ESE TelaUe) cn ENECRSTL: JPanel
`
`
`Data View Events Constructors Methods 8
`
`i Methods:
`* pS
`~getshapeset
`-
`6 STN
`~ setShapeSet
`
`{|
`
`oe
` &) ¥
`
`=
`Yar.
`J] sshapeset SP
`A Jeorrom_avicnment #8)
`A
`)
`===
`—
`
`J CENTER_ALIGNPIENT 9)
`en
`}LEFT_ALIGNMENT *)
`
`/ ae= <
`paint
`
`(RIGHTALIGNMENT @:Pp
`[|
`[Overrides JPanel's paint method to draw all the shapes: Ina calle ction. os es |
`i (overseer oe
`
`|
`2,TOOL_TIP_TEXT_KEY ey
`)
`sesenemcenmenn ene
`eAAIRQUAN A memento
`oT Sg
`“TOP_ALIGNMENT &
` sere recma area
`|:
`#9
`TUNUEFINEU_CoMDITioN
`IWHEN_ANCESTOR_OFFOCUL
`“wren_Focusen 7)
`WHEN_IH_FOCUSED_WIND!
`
`
`
` Behaviors
`
`
`
`
`
`
`
`pmethads-
`
`Ae ™ getShapaSet
`1
`'~ setShapeSetee
`
`: }
`
`5
`
`a
`
`
`
`~ g2D
`
`.
`
`
`
`a draw
`{ _JiawaevaShape a
`
`
`|| Dawe Oh)
`
`a)
`
`java.util,Get}
`|
`|
`
`|
`;
`
`pDirect access Is permitted by
`fall classes.
`
`
`i
`
`iS static
`I finat
`[Fi synchronized
`
`|, Instances I
`
`Page 1 of 24
`
`GOOGLEEXHIBIT 1024
`
`Page 1 of 24
`
`GOOGLE EXHIBIT 1024
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 1 of 7
`
`US 2004/0006765 Al
`
`i.
`
`PRBS TTTet Perens swing JPanel
`
`| Fite Edit Dat
`View Evonts Constructors Methods Behaviore
`Instances Help
`Methods
`Fa eG gy
`_wetShapeSet af
`x
`selShapeSet
`
`~chapese! %)
`own
`JBOTTOM_ALIGNMENT a)“Se
`CENTERJALIGNMENT
`xy
`SS
`LEFT.ALIGNMENT
`)
`Richt aLiGuemnt &)
`),TOOL_TIP_TEXT_KEY ey
`TOP_ALIGHMENT )
`“UNDEFINEDCONDITION By
`“\IWMEN_ANCESTOR_OF_FOCU:
`
`paint
`
`i edescriptian-= =
`jOvarrides JPanel:‘Ss$ paint methodto raw all iheshapes Ina collection.
`‘throws~ —
`
`
`
`treatasfsiowa.owtGraphics20=!
`
`
`
`
`
`
`
`
`4
`
`
`
`
`
`I
`
`
`ethod access se") p modifierssrs
`
`' protected
`package
`private
`;Divact access le permitted by
`allclasses:
`
`
`{C] static
`(Fi anar
`{21 synchronized
`
`
`
`=frameninygremnemnore
`
`Foe
`Jove:LawiEvent 9.pee
`_pewesangsJODject =
`oes
`add
`_}ave.setComponent a
`add
`Javea:Popupheni a)
`
`We
`
`Ij
`
`FIGURE 1
`
`Page 2 of 24
`
`Page 2 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 2 of 7
`
`US 2004/0006765 Al
`
`!
`
`
`
`3 Packages and Clasees|Jer]
`2 Matha.
`s— -
`ere
`= > —
`“
`as
`sy
`Edit Debug
`
`
`
`
`™ setBackground
`fe ESpunt
`F
`
`
`
`
`
`piaramet ee|
`
`
`
`iks
`
`
` Shree
`
` JApplet$AccessibleJAppl
`BE apution
`—
`setFereground
`% JBurton$AccessibleJButto|
`
`
`
`
`
`awietar
`& JCheckBox
`
`| Rava.
`
`
`
`[.
`
`
`
`cle4 VW) peepackgrouna
`}
`
`
`
`
`aE]
`Jacaawecotar
`
`
`aiettedgeeeet "
`
`
`
`
`
`
`: ” detauktGapabte 9
`i
`Al aetauntcon ©
`
`
`
`
`
`yl
`HS
`1
`i
`arathod
`'
`2.
`i
`Hf detauntargin %}
`(rruttic
`E
`i
`i
`A aisamerecan &)
`|
`a
`
`
`i
`;
`iy is
`E | protectat
`eae
`hs
`
`[ ! jffpackiewe“inabledSeluctedicen 9%) i
`
`
`
`
`|
`ub
`on
`ql
`|
`private
`|
`iignateher &)
`maori
`4
`:
`é
`_
`
`-
`N
`:
`
` es—,
`ertacbegcated
`a
`r
`paCohay &
`
`
`
`scthackgrountoe,
`
`
`5 PrvaCass Q
`
`
`_Jivaxawing.bord os Border
`5
`=
`settturcetPaintad
`&
`
`
`J
`aL LZ
`
`
`reed
`8|
`
`Cb)
`
`4
`
`
`
`
`
`
`
`
`i
`5
`
`t
`
`L
`
`1
`
`Bahaviars [Instanc
`
`
`
`|.
`
`i
`
`
`
`
`
`
`
`r
`
`i
`
`FIGURE 2
`
`Page 3 of 24
`
`Page 3 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 3 of 7
`
`US 2004/0006765 Al
`
`__SAEN
`
`AY CLA OBE.
`
`
`(Packages and Classes _
`
`Fila Edit Model View Controflers Constructors Methods
`Behaviors
`Instances Help
`Debug
`[fie] cae
`
`
`CHE
`
`Open clase.
`
`
`
`_Newclass.,
`
`
`
`LASS.
`SEE
`nate
`
`
`2H UTETECR
`
`
`bane:
`NY
`p
`
`
`
`“variablel—#y
`:
`: a
`‘Save all
`Char
`org
`
`sun
`
`
`sunw
`~ variable1
`nrathods:
`es
`© myciass
`
`b|rar at
`
`[HOSCETCO
`
`
`
`
`(a) i getvariablet=#
`
`
`
`:
`p default wale ccc
`:
` setvariable1
`@
`Ho Actes
`a>
`To
`
`
`:
`(| See ete) nae
`ito]
`
`Madel View
`Contraters Constructors Methods Behaviors
`instances Help
` jave.lenginteger
`| file Edit
`
`
` ae
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`pshortculs
`
`
`pone
`:
`[collections
`
`A. Character
`
`id Double
`
`Float
`
`3 Integer
`
`
`‘
`# Lona
`description
`
`
`®% SViawatangante
`
`default value
`
`
`
`
` were
`
`
`message
`ridescriptioy
`the textto appear onthe buttan
`
`
` _
`“default value
`-
`ae
`
`|femS
`| gelMessage
` setMes:
`sage
`
`os)
`
`(«c)
`
`FIGURE3
`
`Page 4 of 24
`
`Page 4 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 4 of 7
`
`US 2004/0006765 Al
`
`
`
`
`
`
`
`
`
`
`
`
` n
`
`
`
`
`
`
`
`
`(det|wonfconsota|consuuceTammuct
`
`(a)
`
`
`-aetion 8) Vv
`
`*actionCommand489 Vv
`
`
`>*actionMap a;pV
`i
`
`
`S~atignmnenty fy
`
`
`
`
`FIGURE 4
`
`Page 5 of 24
`
`Page 5 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 5 of 7
`
`US 2004/0006765 Al
`
`
`
`
`
`
`
`
`4eo
`
`
`
`
`[parent
`
`
`
`inethod a
`
`a ingButton
`
`
`Behaviars
`
`|iq
`
`
`
`F
`
`| sdeacriptiine==
`
`
`
`|Swaps the background and foreground.
`
`
`
`poarameters-———
`soon cinewants
`
`i! —e
`cecseettmeneel|
`|
`reveat fa James per second x|
`
`
`
`|
`
`until
`ffatse
`
`gnethod body
`
`
`
`settlackarounct
`
`
`
`
`
`
`
`
`
`
`
`
`
`Fuuttic
`protected
`package
`
`
`private
`
`
`
`
`Olract accessIs permitted by
`
`all classes.
`
`
`
`
`
`
`FIGURE 5
`
`Page 6 of 24
`
`Page 6 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 6 of 7
`
`US 2004/0006765 Al
`
` ELUTEggcea cageshy
`paces
` | aed ( collections[°F Boolean
`
`£ paoscrintion:
`
`
`companents|A, Character :
`i= ue on 44.4 Double__primitives | Float
`
` Ve [ navaineters———
`ii
`it integer
`3 Long
`i@ System
`void
`
`
`
`
`
`
`
`
`
`}
`
`ane
`
`:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`alee
`OE Sw Ea
`
`preturn
`
`
`i
`prin eenapnanc
`
`i
`:
`1
`i epeesnes
`
`eeoe
`recur ®
`
`
`|
`
`
`protected
`round
`3
`i
`cell
`floor
`
`package
`om
`[wt|
`
`private
`
`Direct access ts permitted by
`
`~
`all classes,
`
`feb
`i
`
`FIGURE6
`
`Page 7 of 24
`
`Page 7 of 24
`
`
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 7 of 7
`
`US 2004/0006765 Al
`
`REComputeGCD
`Behaviors Instances |
`
`
`
`{File Edit Model View Controllers Constructors Methodsawe
`
`
`Valais
` . pconmmarters:
`
`
`
`
`“mm &
`
`“nh #
`
`
`
`
`
`
`
`||
`
`
`
`einethad body es
`
`
`
` | untitled
`
`eose
`
`
`
` cthonPerformadijavaaat.evantActionEvant),
`
`
`‘ocusGalned(jiava.awtevent.FocusEvent)
`DCUSLOSI(java.aWh.event.FocusEvant)
`
`(a)
`|
`(= EST='
`
`
` ~ actionP arformed
`i
`) gdgseription
`
`
`
`
`
`
`
`
`
`
`FIGURE 7
`
`Page 8 of 24
`
`Page 8 of 24
`
`
`
`US 2004/0006765 Al
`
`Jan. 8, 2004
`
`LIVE SOFTWARE CONSTRUCTION WITH
`DYNAMIC CLASSES
`
`RELATED APPLICATIONS
`
`[0001] This application claims bencfit of U.S. Provisional
`Application Serial No. 60/373,855,
`filed Apr. 16, 2002,
`entitled, “TTVE 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 cfficicnt 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 developmenttools, formal training of competent
`programmers remainsa labor-intensive and time-consuming
`task. Introductory programming courses continue to be ‘rites
`of passage’ in which only those whoare willing to contend
`with a steep learning curve in an artificial syntax survive.
`The endresult 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 powerof general-purpose programminginto 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 concernstools for the simplification
`of object-oriented software construction. An object-oriented
`programming language is one in which each componentof
`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 instanceofthe classis 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 maybe defined to accept
`parameter values, which provide additional information to
`the method whenit executes. Each method mayoptionally
`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 extended 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 languagesare traditionally textual languages.
`
`A text editor is used to write the source program whichis
`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
`applicationsare 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
`‘Ioday’s
`[0009]
`(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 Inprise (Borland)
`JBuilder, Sun’s Forte for Java, NetBeans, IBM VisualAge
`for Java, Webgain (Symantec) Visual Café, 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
`changesin relationships between the GUI and the underly-
`ing data modelare 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
`whois familiar with the syntax of the language andis 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 crrors 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 Al
`
`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
`languagesprovidea 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 paradigmsis dataflow, in which data flows across
`“arrows” to trigger actions performed in “boxes.” Some
`examples of dataflow 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 within 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 languagesare 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 languagesthat 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 profcssional 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 advancementin both programmerproduc-
`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
`budding 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
`programs will continue to apply when they begin scaling up
`o 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
`have the incentive to invest the time in the first place. As a
`result, we need to provide an environmentthat 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 environmentisa 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 overthe 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
`programming process more natural and that can be mapped,
`by 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
`people to think about computations at a higher level. Each
`high-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
`humansand 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 cxposcs a novice uscr to a text editor and
`compiler is likely to meet only limited success. The goal is
`how 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 observationis 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
`power within the relative comfort of a graphical user inter-
`ace that supports working directly with the abstractions
`provided bythat 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 Al
`
`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.
`
`SUMMARYOF 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-
`mentenablesfirst-time programmers to achieve early suc-
`cess, without the steep learning curvethat typically precedes
`developmentin a traditional textual language. At the same
`time, the environmenttransparently 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 programminglan-
`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:
`
`1. 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-Oricnted Textual Language. The underlying
`language mustbe 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 powerof the underlying language,
`including access to compiled classes andlibraries.
`
`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
`classcs, but also cxisting instances.
`
`Interoperabilily with Compiled Code.
`5.
`[0024]
`Instances of dynamically modifiable classes must
`interact seamlessly with instancesoftraditional 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
`nameconflicts, 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, mustbe readily
`visible to the user. This design goal, together with the
`previous onc, saves uscrs 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. or example,
`instance variables are
`declared in one place, a method’s parameters in
`another. We expect this to increase cade organiza-
`tion,
`improve user familiarity, and speed up the
`learning curve.
`
`9. Syntactic Consistency. The language [ront-
`[0028]
`end must make it impossible for the user to express
`anything that is syntactically incorrect. In addition,
`type mismatch errors must be obviously and imme-
`diatcly flagged so uscrs 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 strcamlincd support
`for programming
`tasks that are common to many applications, such as
`automatic creation of accessor methods, handling
`commonuser events, creating periodic threads, and
`layout of typical graphical user interfaces. At the
`
`Page 11 of 24
`
`Page 11 of 24
`
`
`
`US 2004/0006765 Al
`
`Jan. 8, 2004
`
`same time, the environment 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 goalis to accom-
`plish this without confusing the novice orirritating
`the professional.
`
`betweenan architect creating a blueprintin 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, windowsand doors. Table 1 compares text-based
`and abstraction-based programming in terms of human-
`computer interface design principles.
`
`11. ‘Lransitional 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 programsdirectly in the
`underlying language. Therefore,
`it
`is incumbent
`upon us to design the tool in such a wayas 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 programmingprocess, by raising
`a level of abstraction by treating the programming process as
`an application domain. This accordinglyresults 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 awarcness of program structure ercatcs
`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.
`While 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 programmingpractices. 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 accomplishesat least two main goals. First,
`the programmeris 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-bascd 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. Byanalogy,it is the difference
`
`Page 12 of 24
`
`TABLE1
`
`A comparison of text-based and abstraction-hased programming.
`Text-based
`programming
`
`Abstraction-based programming
`
`Principle
`
`Domain-
`specific
`objects
`
`Natural
`operations
`Immediate
`feedback
`
`Constrained
`editing and
`consistency
`checking
`
`Gradual
`learning curve
`(prerequisiles
`to starting)
`
`Source code files Variables, parameters, methods,
`method calls, statements and
`expressions, exception handlers,
`
`Cut/copy/paste
`text strings
`Limited (Syntax
`colorizing,...)
`
`Essentially any
`text can be
`typed (compiler
`checkslater)
`
`Significant
`syntax and some
`semantic
`knowledge
`is required.
`
`Declare variable, override method,
`tee
`Type checking, flagging
`incomplete expressions, live
`execution
`Prevention of syntax errors by
`default, consistent variable
`renaming, enforced matching of
`formal and actual parameterlists,
`enforced access protection, .
`.
`.
`No knowledge of syntax is
`requiredto start.
`Semantics is buill up
`incrementally.
`
`[0035] Table 2 provides a sampling of domain-specific
`entities and associated natural operations that could be
`provided by a tool supporting a typical object-oriented
`programming model. Elevating the unit of discourse is not
`necessarily directed to inventing new abstractions, but to
`allowing programmers to work more directly with them. The
`abstractionsare nottied to a parti