Showing posts with label UML tool. Show all posts
Showing posts with label UML tool. Show all posts

Thursday, 29 May 2008

Snapshots


Last week I was doing UML diagrams for a colleague to use in building his part of a large application. It occurred to me that the information he actually needed was quite a lot less than what was on the diagram, but as we were doing some test led development, and the model was continuously evolving to reflect the results of our tests, it was too annoying (and unreliable) to have two separate versions of the model to update.

I think the answer to this problem would be for each Identity Project to be able to have multiple 'Snapshots' - as roughly visualised in the pic above. In different Snapshots the state (CRC / Full class element / Collapsed class element) of each element could be different, but making a change to the model would update it overall, and the changes would be reflected in each snapshot. 

I've also been thinking about 'visibility filters' for the snapshots. Being able to toggle on and off all public / private / protected / package attributes and operations in the whole diagram would be useful too - I often find myself running 2 copies of a model, one with the entire structure and one to give to a collaborator which only includes the public stuff.

Apologies if this stuff is already present in existing UML tools - at the moment I've decided to not do any research into what's already out there until the first draft of the Identity spec is written up. At that point I think it'd be useful to compare what we've come up with to what's already available, but I'm trying to keep my thinking coming from 'what do we want this to do?' at the moment rather than 'what do other tools do?', knowing that we can pick the status quo up later.

Tuesday, 20 May 2008

Identity modeller roadmap

If you build it, they will come ... 

That's my mantra at the moment anyway. At times I wonder whether I'll get enough active contribution to this project to make it worth doing open source ... and then I tell myself to shut up, because open source is something I believe in.  Wikinomics, etc.

I have a genuine passion about this project. I guess it's my old production engineer background coming out - I want to fix the process, regardless of the product. In the last year or so I've begun to feel incredibly frustrated by a lot of the work I do, by the sheer pointlessness of it to be honest.  But I still have friends who do OO coding who don't feel able to use UML, or CRC, and I still find I'm having to talk myself into doing it sometimes, and I know that if I had the tool that Identity aims to become I would be a much better coder and technical manager. I know that sharing good code would be easier for starters.

I'm fortunate to be involved in a couple of really, genuinely worthwhile projects - the biggest of which is a training application that runs in AIR. Apart from a really good usable GUI, the AIR-ness means that this app can manage its own updates in a wonderfully smooth way, something which has allowed us to get it out to users much earlier in the process than with a conventional app, where releasing updates might be problematic.  We can get a bug report from the client, engineer a fix and release the new update to all users within hours.

Based on that experience, the Identity modeller roadmap aims to release as early as possible. I'm also a fan of getting the risky bits out of the way as early as you can, so we start up with the data side, and work towards graphics at the end. To begin with it won't be pretty, but it will be working.


I've no idea what the timeframe is, which will depend partly on how many people get involved and how their schedules are playing out. If you want to have input into the big picture, in particular the scope of the model and the way data is saved, speak up now.  Thanks to all those already chipping in on email and chat!

If you're not able to contribute in terms of coding or design but would like to do unit testing or alpha / beta testing I'm already taking names for those ... don't be shy.

Wednesday, 7 May 2008

Interested in testing or influencing development?

There are a few different ways in which you could get involved in this project if you're interested.

The easiest is just by reading this blog and chipping in with a few comments here and there.

I'm also going to build some mailing lists, so please drop me an email if you'd like to get involved in any of the following ways:

  • Top level design team - reading through the specification for the app, contributing brain power to solving the big problems and specifying unit tests.
  • Coding team - writing classes to unit test for the main app.
  • Plug-in team - creating swfs to add functionality using the plug-in APIs.
  • Graphic design team - determining how this thing should look.
  • Language team - drawing up xml files for AS3 / AS2 etc.
  • Unit-testing team - testing parts of the app (obviously we'll do as much as possible with automated unit tests, but sometimes you really do need a human to bash things!)
  • Alpha-testing team - testing the first usable release of the app.
  • Beta-testing team - does what it says on the tin.

I know this kind of project is potentially a bit daunting, but if you feel like there is a particular task that you'd be interested in, let me know.  Maybe you've already got some experience that might be useful - perhaps you're a regex junkie who'd relish the prospect of churning through AS3 files to strip out the data required for reverse generation of models?  Or perhaps you're just really good at breaking stuff, and would be an ideal candidate for the unit-testing team :)

Maybe you're up to your neck in actual work but would like to read through the proposals to make sure we're building something that meets your needs as well as our own?

Don't be shy ...


[edit : It's been suggested that we put the project up on osflash.org - a really good idea, but when I tried to do it I found that the sign up page has the following message : 

New project signups are currently on hold as we transition to an automatic system. The old manual system just isn’t working out as neither John nor I (Aral) have time to go through the submissions and that’s not fair for you guys. 

If anyone has another suggestion please let me know, otherwise I'll stick to the blog for now and set up a svn repository as soon as it's going to be useful. ]

Monday, 5 May 2008

Introducing identity modeller

Dauntless pointed out on email that I can't keep calling it "Air UML tool thing" ... and I thought coming up with a half-decent name would take ages, but here I am already, introducing Identity modeller.  Whadya think?

I wanted it to convey the fact that the code and the model are intended to stay in step with each other ... and 'congruent' isn't exactly catchy.

Plus, like all good math-geeks, I'm a long term fan of Euler. Couldn't resist ... sorry!


Sunday, 4 May 2008

Air UML Tool : File formats and more on typing

I've been trying to wrap my head around the xmi specification for describing UML models using xml.  The purpose of the spec is obviously to allow models to be imported / exported and switched between different UML tools.

It has given me a focus for the core functionality of the application - to be able to read and write both xmi models and language specific class files.  The application would then also have the ability to write extended xmi files, containing the compliant xmi model stuff but also the project data relating to everything else - non uml stuff to do with getter/setters, positioning, etc etc. 

The language specific element will be provided by external xml configs - one to describe how a class file is structured, and one to map generic types to language specific types.

I've been having a bit of useful exchange with Dauntless on the types issue.  The thinking I have at the moment is that some classes are clearly language specific - anything using or extending MovieClip for example is only useful in Actionscript - whilst other classes might be much more generic, in which case it would be nice to be able to move them across different language projects.  I have a few utility type classes which I use in both AS3 and php5.  

The most basic type set is that provided by UML itself: boolean, integer, float and string.

Then there is the set provided by ECMAScript 4 - discussed in the previous post.

As Dauntless pointed out, Java has useful stuff like Enum. 

I think I've almost reached a clear enough understanding of the multiple-languages issues to be able to post more detail of that tomorrow.

As always - the more the merrier - please chip in if you're interested in contributing.

Meantime - if anyone can think of a good name for this baby ... Dauntless has rightly pointed out that AIR UML Tool is getting a bit dull ...!

Friday, 2 May 2008

AIR UML tool : Working with types across different languages

One of the most obvious changes when switching between AS2 and AS3 is the difference in built-in types.

I'm talking Number vs int / uint. Void vs void.

From time to time I plan something that I want to execute in more than one language - in php5 or Actionscript 3 ... I've been fortunate to be able to leave AS2 behind but I know a lot of people are working on legacy projects.

With Colin Moock already talking about Actionscript 4, the focus for future-proofing seems to be on ECMAScript 4.

The release data for the new spec isn't til December 2008, but I'm guessing the end of the year will be upon us in no time.

Reading through the ECMAScript 4 Overview, it's struck me that building with this spec in mind will force us to include the kind of flexibility that will make it easier to extend this app to other languages.

For example - some of the Number types proposed - byte, int, uint, double and decimal - may not make it into the final spec, and we may continue to have the current AS3 set: int, uint and Number.

If each language contains a type mapping spec for the core types then AS3 can map byte, double and decimal to Number, and if AS4 supports them then they can be supported.

eg:

translations/as2/typeMapping.xml :


<typeMapping>
<type_byte>Number</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>



translations/as3/typeMapping.xml :


<typeMapping>
<type_byte>uint</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>Number</type_double>
<type_decimal>Number</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>



translations/as4/typeMapping.xml :


<typeMapping>
<type_byte>byte</type_byte>
<type_int>int</type_int>
<type_uint>uint</type_uint>
<type_double>double</type_double>
<type_decimal>decimal</type_decimal>
<type_Number>Number</type_Number>
</typeMapping>


So far, the types I can identify in the ECMAScript 4 list are:
null, undefined, void

Object

Number, byte, int, uint, double, decimal

Boolean, boolean

String, string

Array

Vector (a strictly typed array?)

Function

Map (binary relations)

Date

RegExp

Name, Namespace, NamespaceSet, NamespaceSetList

Error, EncodingError, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, UndefinedError, URIError

AnyString = (string,String)
AnyBoolean = (boolean,Boolean)
AnyNumber = (byte,int,uint,double,decimal,Number)
FloatNumber = (double,decimal)

XML, XMLList, AttributeName, AnyName

IterableType, IteratorType


I've also spotted a few more in the documentation - FieldIterator and ControlInspector perhaps?

Either way - this strategy allows us to be highly specific in our documentation, and then water that precision down for each language. Of course, coming back the other way it's trickier. Do we want reverse engineering to simply pick the most generic type, or do we need a special comment that can specify how types are backward translated? Something like ... (for AS3)

// *strictType:decimal //
public var salary:Number;

Obviously the app also needs to support types from your own library.

Something else I've noticed is the support for ! ? notation to specify that an object can / can't be null. Eg

// "!" indicates that v can't be assigned null
var v : MyType!

// "?" indicates that v can be assigned null
var v : MyType?

// "!" indicates that this whole class is non-nullable
class MyClass! { ...


The idea is that this will allow earlier detection of null-pointer errors - ideally at compile-time rather than run-time. That would make me very very happy!

----

It's a pain that ECMAScript 4 is still six and a bit months from completion, but I think the rigour that having to build for an almost-complete standard gives us is probably a good thing.

Thursday, 1 May 2008

AIR UML tool : A clearer concept


To save any confusion - this is just a graphic, a jpg exported from a flash file which has absolutely no functionality and is purely intended to help rough out an interface concept.

I started thinking in more depth about what I personally needed this tool to be able to do, given that I'm pretty happy with my current working strategy but it just feels like there's a fair bit of friction in the system in terms of duplicating work.

So, I went right back to basics - my current process, which I'm sure is not unique, is to use index file cards for a fair bit of my modeling.  On one side I scribble the CRC stuff (Class Responsibilities and Collaborations).  On the other I outline the most important public properties and functions.


At a later stage I do a more formal UML diagram in Omnigraffle, using the UML-General template.  Then, once I'm satisfied that it's close enough to what I'll finally need, I create skeleton AS3 classes in Flash or Flex, and then write in skeleton asDoc comments ... both of which are rather tedious.

Inevitably the coding process throws up unforeseen stuff and functions, structure or even the whole model can be subject to changes.  Unless I am feeling particularly disciplined, many of these changes go mostly undocumented, usually only being written up if the code is then applied to a new project or handed over to a new developer.

I no longer work as part of a large team of developers, so I've only my own experience to call upon, but if there's one thing I've learned in my time as an engineer (in both the physical and the software world) it is to begin by making a product that a single concrete person needs, and not a product that doesn't actually satisfactorily meet the needs of any of a whole bunch of abstract people :)

Where I've landed is that this tool should be like a digital version of my index file card box, which integrates my workflow all the way through from creating CRCs to assembling them into a project, to defining public interfaces on the flip side, to drawing that up in a UML sketching tool, to defining private functionality, to adding comments to explain usage, to generating AS3 skeleton functions with asDoc compatible comments and getter / setter functions where desired ... it has to take care of that whole shebang.

That process has to be 2 way, preferably with 'intelligent' (the magic word for 'haven't defined the rules for this yet') syncing.

Returning to my dodgy graphic at the top - I'm no designer, so will be looking to get some major input on that side - the concept is that you have a bunch of index cards on screen, you click the little arrow in the top right corner to flip 'em round.  They expand and contract to give enough space for the properties / functions.  All the standard spec of UML 2 is available to you and they also have a neat interface (represented by the G S on the right of the properties) for requesting that Getter / Setter functions be created for those properties. 

I'm sure there will be other, sexier, less geeky skins that people want to add later but this one seems like a great one to kick off with because it focusses the mind on what we're trying to do - take the friction out of a tried-and-tested way of working, not revolutionise the whole process!