asy United States
`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
`
`
`
`
`
`
`~ g2D
`
`.
`
`pmethads-
`
`Ae ™ getShapaSet
`1
`'~ setShapeSetee
`
`: }
`
`5
`
`a
`
`
`
`a draw
`{ _JiawaevaShape a
`
`
`| Xsnape S| |
`
`
`
`a)
`
`java.util,Get}
`|
`|
`
`|
`;
`
`pDirect access Is permitted by
`fall classes.
`
`
`i
`
`iS static
`I finat
`[Fi synchronized
`
`|, Instances I
`
`Booking, Exh. 1050, Page 1
`
`Booking, Exh. 1050, Page 1
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet 1 of 7
`
`US 2004/0006765 Al
`
`ff ShapePane!l extends javax.swing JPanel
`| File Edit Dala View Events Constructors Methods Behaviors
`‘variables
`
`Instances Help
`
`i
`
`page _
`getShapeSet
`@)
`x
`selShapeSet
`
`.
`paint
`.
`eecenneeristamagenere
`oes
`i) pdescription----
`|
`[Overrides JPanel's paint methodto drawall the
`,
`-
`.
`4
`parametors =
`
`h i
`i
`‘java.util,Sot}
`
`:
`
`Constructors|.Methods
`
`
`
`
`
`
`
`
`
`
`|
`3) method bocky—
`
`:
`4
`oft
`tf
`
`treatasE/jave.awt.Grapbics20
`
`Peal _
`
`.
`
`:
`
`_t
`
`
`i protected
`package
`
`at
`if
`al
`|
`!
`private
`|
`| [Dlact access le pamitted by
`4 allclasses
`
`|
`
`
`
`{C] static
`[i anat
`ee
`i
`sync
`
`h
`
`ronized
`
`FIGURE 1
`
`Booking, Exh. 1050, Page 2
`
`:
`TRIGHI_ALIGNAS
`NT ar
`“
`AL
`z
`RIGHTALiGuMaENT2)
`il, roo_np_rext_KeY ey Ee
`OD Atte
`_ a
`i
`| ETOPALIGNMENT ® )
`UNDEFINEDCONDITION #)
`“\IWMEN_ANCESTOR_OF_FOCU:
`~
`_,
`hy
`_WHEN_FOCUSED i]
`oS
`WHEN_IK.FOCUSEDWIND
`
`methods
`~ getsnapeset
`'~ satShapesot
`fg
`2”
`
`:
`: ey
`oO
`
`?
`
`F
`
`:
`
`ii
`
`! |m
`
`Foe
`Foe,
`Jove:LawiEvent 9.
`
`imo_AevasangeODject
`“add
`Alp
`i
`f _Jewe.awtComponent ay
`x
`4, Lonmin mnt mined
`aad
`Javea:PopupMonu a)
`
`nel
`
`Booking, Exh. 1050, Page 2
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet 2 of 7
`
`US 2004/0006765 Al
`
`
`3 Packages and Clasees|Jer]
`2 Matha.
`s— -
`ere
`- — > — — me -
`oe
`Edit Debug
`
`
`
`
`~ setBackground
`fe ESpunt
`i
`
`
`
`
`
`piaramet ee|
`
`
`
`iks
`
`
` Shree
`
` JApplet$AccessibleJAppl
`BE apution
`—
`setFereground
`% JBurton$AccessibleJButto|
`
`
`
`awietar
`
`& JCheckBox
`
`| Rava.
`
`[.
`
`
`
`cle4 VW) peepackgrouna
`}
`
`
`
`
`aE]
`Jacaawecotar
`
`
`
`aiettedgeeeet "
`
`
`
`
`
`
`: ” detauktGapabte 9
`Pe etauntcon &
`
`
`
`
`
`'
`arathod
`2.
`
`dos
`_
`8
`aft
`:
`:
`Hf
`sete
`detauntargin %}
`[P “aisamermean &)
`| protected
`t
`
`
`L |
`acta
`ys
`)-
`! ;
`package
`[
`“inabledSeluctedicen 9%)
`
`
`ub
`on
`ql
`|
`iignateher &)
`|
`private
`a
`<—-————~
`;
`
`-
`N
`:
`
` es—,
`ertacbegcated
`a
`r
`paCohay &
`
`
`
`scthackgrount
`oe,
`
`i PrvaCass RR
`
`
`
`_Jivaxawing.bord os Border
`5
`=
`settturcetPaintad
`&
`
`
`.!
`aL LZ
`
`
`reed
`8|
`
`Cb)
`
`|.
`
`i
`i
`4
`i
`i
`E
`;
`i
`|
`fi
`
`i
`
`
`
`
`
`
`i
`
`r
`
`
`
`4
`
`
`
`
`
`
`,
`
`i
`5
`
`t
`
`E
`E
`:
`
`L
`
`|
`
`Bahaviars [Instanc
`
`
`
`FIGURE 2
`
`Booking, Exh. 1050, Page 3
`
`Booking, Exh. 1050, Page 3
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet 3 of 7
`
`US 2004/0006765 Al
`
`
`
`
`
`~ variable1
`
`
`ALCL
`BL
`oS
`
`
`(Packages and Classes _
`Lal
`Fila Edit Model View Controflers Constructors Methods
`Behaviors
`Instances Help
`[File] Edit Debug
`
` CHE
`
`
`Open clase.
`
`
`
`_Newclass.,
`CuRN
`
`
`
`rei class...
`NEE
`
`
`2H UTETECRbane:
`
`NY
`p
`
`
`“yariablel=##Y
`Save all
`Cots
`Chr
`org
`
`sun
`ar
`
`
`© (2) sunw
`nrathods:
`& myciasses
`
`:ee'
`Iie og,
`
`
`
`
`
`
`i getvariablet=#(a) Bl
`
`
`(aa?
`p default wale ccc
`:
`:
` setvariable1
`@
`Ho Actes
`a>
`TL
`
`
`
`
`:
`(| See ete) ae
`iio]
`
`
` jave.lenginteger
`Contraters Constructors Methods Behaviors
`instances Help
`| File Edit Model View
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` pshortculs
`pone
`[collections
`:
`
`A. Character
`
`id Double
`Float
`
`
`3 Integer
`‘
`# Lona
`description
`
`
`
`®% SViawatangante
`
`
`default value
`
`
`
`ridescriptioy
`~ message
` the textto appear onthe buttan
`“default value
`-
`
`
`
`|iFi
`| gelMessage—fc)
`(«c)
`selMessage
`®
`
`es) v
`
`FIGURE3
`
`Booking, Exh. 1050, Page 4
`
`Booking, Exh. 1050, Page 4
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet 4 of 7
`
`US 2004/0006765 Al
`
`
`
`
`
`
`
`
`
`~text<5 ey“ectioneg
`
`yl
`os
`:
`"
`;_eetinattap ayVv
`
`
`
` =
`
`
`
`
`
`
`
`
`
`
`
`
`
`A av
`~ message a) ¥ -
`
`
`
`
`
`a t
`
`porns
`ext er)
`-aetion 8) Vv
`
`
`“message$5)‘je
`*actionCommand489 Vv
`
`>*actionMap a;pV
`
`S~atignmnenty fy
`
`
` “oy
`
`FIGURE 4
`
`Booking, Exh. 1050, Page 5
`
`Booking, Exh. 1050, Page 5
`
`

`

`
`
`
`
`
`
`F
`| sdeacriptiine==
`
` |Swaps the background and foreground.
`
`Patent Application Publication
`
`Jan. 8, 2004 Sheet 5 of 7
`
`US 2004/0006765 Al
`
`
`
`
`4eo
`
`
`
`
`
`
`
`
`
`
`[parent
`
`inethod a a ingButton
`
`
`
`
`
`Behaviars
`
`
`|iq
`
`
`
`
`rineal wari
`7
`
`pparameters——— a
`
`j bm
`eeinegmenneel
`| repeat].|dines pet)second x|
`
` until
`
`
`|
`
`ffatse
`gnethod body
`
`
`
`
`
`
`
`
`settlackarounct
`
`Fuuttic
`
`
`protected
`package
`
`
`private
`
`
`
`
`Olract accessIs permitted by
`
`all classes.
`
`
`
`FIGURE 5
`
`Booking, Exh. 1050, Page 6
`
`Booking, Exh. 1050, Page 6
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet
`
`6 of 7
`
`US 2004/0006765 Al
`
`aed
`£ pdescriplion=
`
`eh Peiggssnvemcuapataipan wacocereSaceaenatat i
`f collections[24 Boolean ~
`
`ancesAY, Character
`i
`+44 Double
`bens
`me
`-
`|
`_Brimives | Float
`2 Pmarametars
`
`it integer
`3 Long
`
`i® System
`
`void
`:& Object
`
`
`
`
`
`
`
`
`
`
`
`
`
`preturn peut
`
`
`
`2)oe
`
`
`
`
`
`
`ih
`
`protected
`
`package
`
`private
`
`Direct access ts permitted by
`
`~
`all classes,
`
`
`|
`
`|
`
`FIGURE6
`
`Booking, Exh. 1050, Page 7
`
`Booking, Exh. 1050, Page 7
`
`

`

`Patent Application Publication
`
`Jan. 8, 2004 Sheet 7 of 7
`
`US 2004/0006765 Al
`
`REComputeGCD
` aes
`Ry
`Instances |
`{File Edit Model View Controllers Constructors Methods BSchaviors
`rcony ORETS:
`
`(a)
`(= EST=
`
`
`Methods Behav
`
`ar
`| Fle Edn Model
`View
`Controllers Constructo
`
`
`
`4
`
`
`)
`
`|Cuntroliars-
`
`
`
`
`
`
`
`
`pinethon body
`
` _ ee
`
`|
`5%
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`‘massage
`
`
`
`
`PEEEOTSIEDETarabhehAAATTT tinhnsassbamomenwnmenane 1
`
` untitied
`e—————oe
`
`
`
`cthonPerformadijavaaat.evantActionEvant),
`
` |
`‘ocusGalned(jiava.awtevent.FocusEvent)
`
`
`DCUSLOSI(java.aWh.event.FocusEvant)
`of
`View
`Controllers
`
`
`ctors [Methods [Behaviors[instances
`
`
`useExi ed(java.awt_event.Mousaevant)
`
`
`ouseMaveddava.awt.event.Mouservent)
`
`
`
`
`
`
`i
`
`FIGURE 7
`
`Booking, Exh. 1050, Page 8
`
`Booking, Exh. 1050, Page 8
`
`

`

`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.
`
`Booking, Exh. 1050, Page 9
`
`Booking, Exh. 1050, Page 9
`
`

`

`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-
`
`
`
`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-
`
`
`
`Booking, Exh. 1050, Page 10
`
`Booking, Exh. 1050, Page 10
`
`

`

`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
`
`Booking, Exh. 1050, Page 11
`
`Booking, Exh. 1050, Page 11
`
`

`

`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
`
`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,
`te