OK, back to the Shlaer-Mellor and Executable UML grindstone. I've have a few weeks away from modelling and tooling to clear my head. My highest priority now is to create a stable build to release the many features I have added and changes I have made to OOA Tool. The outstanding issues holding up the release are:
- reworking OOA of OOA Metamodel 0.01 population logic since I have considerably expanded the Information Model and Data Type subsystems,
- finishing the outstanding chunks of operation logic including predefined operations on all data types,
- and reviewing and documenting OOA Interchange Format Version 0.05 since lots of changes have been made (but OOA Tool will still be backwards compatible with Version 0.04).
Over the last week, I had a good long look at the subject of object ordering within information models (another diversion!). Complete orderings across child-parent relationships are already handled using Arbitrary ID Attributes and Parent Allocated ID Types (important note to self: finish the technical note on Arbitrary and Ordinal IDs so that people know what I'm talking about!). Partial and complete orderings across objects within Action Language code is handled using an ordered by clause on select statements. However, such orderings are transitory in nature and prone to becoming out of date when an information model changes, e.g. what was once a complete ordering can become a partial ordering without anyone noticing. With regard to complete orderings, the logical place to look in an information model is an identifier since an identifier specifies the minimum information required to define a complete ordering. This lead me to subtype identifiers as either Unordered Identifiers or Ordered Identifiers (see Information Model). Now I'm not going to say too much here since I want to discuss the issues in full in a technical note on Identifiers which I hope to publish soon. However, objects can now define a preferred identifier and an ordered by identifier. If the latter is specified then the object in question is ordered and object instances can be compared using normal relational operators within Action Language code.
This work on ordered identifiers has also allowed me to think how limited but meaningful aggregation and composition relationships could be defined within Executable UML models. Composition relationships could result from child-parent relationships that result directly from Parent Allocated ID Types since those parents have specific duties to manage their children (even though those duties are automatically handled by a software architecture). While aggregation relationships could result from child-parent relationships that result from ordered identifiers. I'm going to add support for hollow and filled diamonds into OOA Tool and see how these ideas work within my example models.
Anyway, I hope to get back to weekly reporting now. If anyone wants to discuss any ideas then don't be shy.
7 comments:
Are you planning to be able to build a model of your tool with your initial hand-coded tool and thereby code generate successive iterations? This is the dog food test after all.
You'd have to change your focus from the horizontal breadth of modelling capabilities to the vertical depth required to support code generation.
However, on the subject of modelling features why not also add to xUML model redundancy that would allow a model verify to check (if not prove) a model's correctness?
If you did all of this then you'd have a formally proven modelling tool and code generator that can be used to model and code generate other systems. Now that has got to be a unique selling point!
OK, so its non-trivial. But I can see that you like challenges!
Have fun,
Dave B.
It would be nice to bootstrap OOA Tool using the OOA Tool Model and the initial OOA Tool implementation. However, (1) I need to provide Action Language implementations for all derived attributes which I haven't done yet (but I am planning to do this), (2) I need to model several service domains including a GUI domain, (3) I need to map the OOA of OOA to the GUI domain which is a non-trivial task (I know since I have already done the work using Java listeners in OOA Tool). That said, If I had the time once the OOA Tool Model and OOA Tool is complete, I could convert my Java listeners into Domain Observers etc. It is more likely that I will use the OOA of OOA to create my model classes in the future leaving the rest of my OOA Tool application in place. This will ensure OOA Tool faithfully implements the OOA of OOA as specified which is a concern I have at present.
I have quite a bit of outstanding work to do to finish the simulator I am working on. This includes turning the OOA of OOA into a usable virtual machine. The outstanding work with regards to the archetype translator and an initial Java software architecture is also considerable. However, getting code generation to work once the simulator is working will be fairly straightforward. Most of my recent delays have resulted from work and rework on my OOA of OOA. I have already implemented a BridgePoint compatible archetype translator but it is useless without a stable and complete OOA of OOA. Creating an optimizing software architecture will be fun though.
There is already a fair amount of redundancy within an information model, e.g. multiple identifiers can be specified and many referential attributes will participate in multiple participant mappings. The area lacking redundancy at present is the lack of constraints (e.g. pre and post conditions etc.) within operation bodies. UML allows OCL constraints to be specified everywhere. I have no plans at present to support OCL but I have considered allowing action language constraints to be specified. An issue for me is that users sometimes place checks that should appear in final code into verification constraints which should not appear in final code. However, I am interested in constraints that can be proved to be true since they have no bearing on the final code generated.
I'm not sure how many people want to pay for software development tools at all these days. Thankfully, selling OOA Tool as a product isn't a crucial part of my strategy. Finding clients who want to create Shlaer-Mellor or Executable UML models is though and I'm not having a lot of luck in those regards at present!
WRT to your last paragraph: As I see it the big problem is that SM OOA is still a semi-formal method, but on a sliding scale ranging from sloppy to executable by simulation (whilst still being of general use), it is clearly at the top end. But this means that it is seen as being hard work to learn and niche by the majority. And as the method doesn't help much with the safety/integrity case for high integrity systems, those that might have been interested aren't.
So you're stuck between those wanting a code sketching tool (a la most UML tools) and those that want rigour that has a ROI with safety and integrity arguments. This generally means that a model used to produce code has a sufficiently defensive V&V argument (static & dynamic test + requirements traceability) and that the tools used to produce the production code from it have a sufficiently rigorous V&V argument. Such tools are often referred to as being "qualified".
Hence my suggestion that if you can build a rigorous OO modelling tool that allows 100% verified models to be built and code generated from with a fully qualified tool suite then I'm sure you'd be able to make some money from it.
Have a look at http://www.eschertech.com/ and the PD tutorials. A great CbC OO language, but with no graphical front end modelling capabilities...
Finally, I must say that I take my hat off and salute your tenacity for taking on such a project single handedly. I wish you all the best with your endeavours.
Regards
Dave B.
I’ve been using OOATool to do some trial xUML modelling. I have found it very easy to use – I really like the clean simple usage. Although you warn in the “readme” that it is only a beta, I have found it to be robust and it has never crashed on me – Even when I have done a lot of reshuffling of classes and relationships due to poor earlier modelling. So whatever design decision you have made under the hood, they are proving to be quite resilient.
Shlaer-Mellor & xUML use particular terminology (and you have some of your own), so I think a quick reference guide would be a great help. Doesn’t need a lot of words, the text books you provide references to can fill that gap. I’d much rather jump in and model but when I get stuck, something brief that can help unlock a misunderstanding or lack of prior knowledge would be a great help.
I have been trying to convince colleagues of the benefits of xUML modelling. For those who are open-minded, once they have a go and see what can be achieved they are convinced. For the wider group, there is a reluctance that seems to stem from concern over giving up programming (which is an enjoyable part of the job); they don’t seem to want to grasp that programming will still be needed yet their productivity for the mundane could be greatly enhanced. This is a cultural barrier and it will take time to overcome.
It seems to me that you need to complete OOATool in the areas you have already noted – full functionality across class, state & action modelling; simulation; code generation; sequence charts. Then when you visit potential modelling clients you can say “let’s do some modelling of your domain” and do it for real right there with them in a real tool not just “PowerPoint engineering”. That simple act seems to be a revelation. The fact that the modelling involves a group of stakeholders rather than primarily software engineers seems to be a key benefit – But it is also a challenge in existing engineering organisations where people are much more comfortable in their own area of expertise where other groups can’t really get involved. So for companies that you market to this cultural challenge can be difficult. Those that recognise the potential for leaner meaner development can be won over – And a real practical demonstration is much more powerful.
I come from a functional / data-flow background as do many of my colleagues and making the transition to OO is itself a challenge. Although sequence charts aren’t a core part of xUML, I have found that when getting stuck breaking off and trying to sketch out a sequence chart (which is a more familiar technique) can help to unlock some poor modelling or help unlock that next step and so move the core modelling forward.
I’d certainly be interested in a complete tool for my own personal use if you do complete and market it. My personal projects are single-developer, so I’m looking for the leverage that xUML claims but it needs simulation & code generation to make it viable.
Replying to Dave's comments:
You say that it doesn't help with safety and integrity issues. However, that really depends on your software architecture. Unfortunately, most of the existing Shlaer-Mellor and Executable UML tool vendors have kept their model compilers very much under wraps. However, I believe that it is much easier to verify and test a software architecture and separately test the application and service domains than having to test the whole final system. There are numerous cross checks that can be verified in an OOA model. Of course, with arbitrary constraints as in UML there is room for more cross checking. However, there are drawbacks to allowing users to specify arbitrary constraints (which I discussed above).
The notion that a model (or any program) can be 100% verified and thus must be correct always makes me laugh. Verification is all about duplicating facts normally using different levels of abstraction or specification so that one set of facts can be checked against the other set of facts. Furthermore, traditional verification techniques such as pre and post conditions work best for sequential programs. In a normal OOA model every active object has its own state model and every competitive relationship has its own assigner model. Pre and post conditions can still be used within actions but their usefulness is marginal since the real complexity that needs to be verified is the interactions between state models. To guard against problems all we can do is to treat each active object (or object cluster) as an independent entity with a clean lifecycle, i.e. make sure there are no holes in state transition tables. DON'T rely on sequence diagrams to test multiple state models. Sequence diagrams are only useful for verifying that a particular sequence can occur. They don't help identify the many invalid interactions that may still be possible.
I still believe that the Shlaer-Mellor ideas originally promoted are an order of magnitude more useful than the current UML ideas in the long run. It is unfortunate that there are no big companies that have taken the same viewpoint.
Replying to B's (perhaps a name would be useful here!) comments:
It is always nice to hear from OOA Tool users. It has been downloaded lots of times but I don't hear from users much. I also apologise for not getting a new build out in ages!
I think you will find that most Java applications are pretty robust compared to C or C++ applications. I do program defensively and this does keep down the number of stack traces that should appear in any output log but such errors aren't normally fatal in Java. The main thing I need to guard against is infinite loops/recursion and failure to save a model due to some inconsistency. If anyone has a model which doesn't load because of some inconsistency then they should email it to me and I will try to patch the model up (assuming they can't do it themselves).
There is so much documentation that I still have to do, it makes me cry sometimes! If you have ANY questions then just email me at sean@ooatool.com.
I do indeed need to complete OOA Tool. I am currently working full-time on the project but it is not always easy when you are working alone.
The Shlaer-Mellor equivalent of the Sequence Chart is a Thread of Control Chart which is normally generated from a simulation. Unlike UML which was never designed to be executed, OOA models should be executable very early on and this should allow such diagrams to be generated automatically very early on. Of course, I'm still working on the OOA Tool simulator but once it is finished then Thread of Control Charts which will appear as Sequence Charts in xUML will be supported. Users will only need to create a simulation, populate it with some test data, then manually invoke a synchronous service or generate an external event to create a Sequence Chart automatically.
Sorry, I didn't mean to get you on the defensive; my words weren't that well chosen on reflection.
I completely agree with you, which is why the SM method appeals to me a lot. However, unlike poster B, I have never been able to persuade any of my colleagues that it was the right technology. And the fact remains that it is niche. I've spent a long time wrestling with the question of how can this be.
In recent years I have moved in to the high integrity world and found many successful niche market technologies and products. Hence my suggestion for SM to develop into this area.
And yes it is perfectly possible with CbC to have a 100% correct model for the wrong problem! Requirements errors typically account for more than 60% of defects in most systems. But the point of executable analysis models is to get closer to the requirements faster by being liberated from the details of the implementation. In this regard I see 100% statically verifiable models as furthering this capability.
May be it is simply the fact that SM is a "magnitude more useful than the current UML" means that it also simply ahead of its time for the majority.
Any way, I'm looking forward to getting some spare time and sitting down with your tool to have a real go myself.
Regards
Dave B.
I did mention that I'm a defensive programmer (my attempt at a feeble joke)!
I also agree that we should be developing software in a more formal way. However, over the last 10 years, as an industry, we seem to have taken a step backwards. Before UML came along we had a range of methodologies with different notations perhaps aimed at different segments of the industry but at least we also had some kind of processes that people were trying to develop and adopt at the same time. Without a formal process for developing software it is difficult to believe that we can apply more formal techniques at a lower level. We seem to be mostly at CMM level 1 again which means most projects should be focusing on requirements and project management if they want to deliver their projects successfully.
I agree that SM was ahead of its time. I also think it didn't have sufficient backing to develop adequate tools in the early days. Both Project Technology (BridgePoint) and Kennedy Carter (iUML) are both very small companies with tiny development teams. I've spent 2.5 years on this project so far by myself. My Java and Shlaer-Mellor skills were at the expert level to begin with but the project is really a 10 man year effort. What we need is a Bill Gates like figure to take an interest and the software industry could take a giant leap forward!
Anyway, I recommend that you try creating a few information models (or class diagrams). I need all the feedback on OOA Tool that I can get.
Post a Comment