Ted Patrick - Demos & MAX @ Adobe Systems

Note: This is the personal blog of Ted Patrick. The opinions and statements voiced here are my own.

Usage Modeling

DIGG IT!     9 Comments Published Sunday, August 23, 2009 at 8:17 AM .

Whenever I write a class, I typically write a usage example prior to writing the class itself. I want to understand what the class will be like to work with, its behavior/interface in development. With OOP it is so easy to hop right into building class after class but actually seeing usage really helps me get the interface right and makes development much easier. On Thursday, before writing the class version of f.net.Load, I showed Doug Winnie how this might work as an example. He notices I hadn't written the classes yet and that it would be a great feature to actually generate classes from usage. hmmmm...

So this idea of "Usage Modelling" has been stuck in my head for a few days. How could I write usage examples with modelling classes and generate classes the support this behavior? Instead of UML or modelling could one use usage examples to generate classes? It wouldn't generate the logic within methods but would generate a very solid start to a set of classes. Basically writing code to generate better code.

This is possible with flash.utils.Proxy where you can catch all interface interaction on a class and simply send class text to the output panel. Based on the type passed in methods or get/set behavior you can type the class properties dynamically, setting a string would type a property as a string. Here is some some "Usage Modelling" usage:

import f.model.UsageModel;

UsageModel.start();

//model the events Class
LoadEvent:* = UsageModel.create( 'f.event.LoadEvent' , flash.event.Event );

//consts in caps
LoadEvent.OPEN = 'f.events.LoadEvent.OPEN';
LoadEvent.CLOSE = 'f.events.LoadEvent.CLOSE';
LoadEvent.PROGRESS = 'f.events.LoadEvent.PROGRESS';
LoadEvent.SUCCESS = 'f.events.LoadEvent.SUCCESS';
LoadEvent.FAIL = 'f.events.LoadEvent.FAIL';
LoadEvent.INIT = 'f.events.LoadEvent.INIT';

//instance use
var loadevent:* = new LoadEvent( LoadEvent.FAIL );
loadevent.data = {};
loadevent.loader = {};
loadevent.percent = 0.75;
loadevent.bytesLoaded = 34;
loadevent.bytesTotal = 56;
loadevent.bytesAvailable = 56;
loadevent.error = 'woops';
loadevent.status = 'status 23';

//denote start of Class
Load:* = UsageModel.create( 'f.net.Load' , flash.events.EventDispatcher );

//define class data
Load._Public = true;

//static use
Load.AMF = "f.net.Load.AMF";
Load.amf( LoadModel.AMF , "http://onflex.org/f/Load/test.amf" , function(){} );

//instance use
var load:* = new Load();
load.url = "http://onflex.org/f/Load/test.amf";
load.parameters = { method:'post', data:{ a:12345 }};
load.resultFormat = Load.AMF;
load.addEventListener( LoadEvent.SUCCESS , loadSuccess );
load.addEventListener( LoadEvent.PROGRESS , loadProgress );
load.addEventListener( LoadEvent.FAIL , loadFail );
load.addEventListener( LoadEvent.OPEN , loadFail );
load.addEventListener( LoadEvent.CLOSE , loadFail );
load.load();

UsageModel.print();

And no I haven't written any classes yet, the irony.

Cheers,

Ted :)

9 Responses to “Usage Modeling”

  1. # Anonymous Anonymous August 23, 2009 11:36 AM

    TDD  

  2. # Blogger Abdul August 23, 2009 11:42 AM

    I guess, with experience we tend to think the use-cases and usage (as you say) before we write even a single line of code.

    It's really important to have developer usability (i.e. having right API).

    Good to see you would be release UsageModel soon, I am sure it would be pretty handy.  

  3. # Blogger Ted Patrick August 23, 2009 11:51 AM

    Anonymous,

    True, but TDD doesn't generate classes or tests.

    Ted :)  

  4. # Blogger Ted Patrick August 23, 2009 11:54 AM

    Abdul,

    Not sure about the timeliness on UsageModel. This would take a while to develop fully. Still at the pencil and paper stages.

    Ted :)  

  5. # Blogger marvotron August 24, 2009 2:15 AM

    interesting idea. one way to achieve this idea would be through improvements in Flash Builder to match some JDT features so you can do better TDD.

    First generate the test case, start writing the test, e.g.

    var f:Foo = new Foo();

    the lightbulb marker appears, CTRL+1 -> Create new class Foo.

    f.doSomething()

    CTRL+1 -> create method doSomething

    etc..

    That way you get true incremental TDD. The tests are your usage examples and Flash Builder generates the stub code as you need it.  

  6. # Blogger Robert Penner August 24, 2009 10:50 AM

    @marvotron
    I would love that. FlashDevelop is close; you can Ctrl-Shift-1 to generate a property or method in the class you're working on. But if it were smart enough to add the code to the class under test... [drools]  

  7. # Anonymous Anonymous August 25, 2009 11:56 AM

    Never thought about that! Very cool idea. And nice implementation as well.

    Greetz Erik  

  8. # Blogger MossyBlog August 27, 2009 1:03 PM

    Good read Ted,

    I do something similiar where i use XML to describe the entire workflow etc. It helps me think in terms of verbs more clearly and essentially makes sure i'm thinking about the high level code-value-chain.

    Then i break it down into what you do now, API implementation first, class composition second.

    Nice to know i'm not entirely my own in this similiar thinking :)

    -
    Scott Barnes.
    MossyBlog.  

  9. # Anonymous Jeremy Holland September 1, 2009 5:48 PM

    Absolutely agree - one way I've heard this concept put that strikes me as very poignant is "Write the code you wish you had". When I heard that, it was like an epiphany - here, here.  

Post a Comment

Where to find me:

Ted on Twitter - @AdobeTed
Ted on Adobe Groups
Ted on LinkedIn
Ted on Facebook
Ted at Adobe


Latest

Lists

Links

Jobs

Flex Jobs
city, state, zip

Archives