Strategy from here for RM

Reference Implementation: Java (archive)
1

Rong and others,

my feeling for the way we should be going here is as follows. In the medium term (say by mid-year), we should aim to have:

  • RM & AM upgraded to Release 1.0
  • all test cases up to date and working
  • contracts in all the code. (See below)
  • potentially some changes to the general design of the core classes

In the short term, what we need is to have the classes upgraded in the current programming style to Release 1.0, with the test cases upgraded as well. We can do this at UCL in a few weeks if the rest of he team agrees to the idea. To actually do it, it means doing the following in Subversion:

  • declare a tag called “Release-0.95” of the current TRUNK(you can choose other names if you want - even funny ones, this is just my default suggestion - to follow the release numbering of the specification project for now).

  • declare a branch of the same name. This is where work can be done for bug-fixes and so on of this release into the future. All users of the current system take their builds from this branch. Minor releases are declared with tags as necessary.

  • the TRUNK then becomes the current line of work.

  • when the TRUNK is more or less at a stage of being Release-1.0 compliant, a Release 1.0 branch is declared, and it is tested and declared with a tag. The it can be maintained on its branch, just as the 0.95 version is on the first branch.

There are other strategies, but I think this is the best one for the team at the moment - it allows multiple simultaneous releases to co-exist.

Now in the medium term, a change in coding style that I want to convince the team to use is “Design by Contract”. This radically improves the quality and readability of the code and documentation, reduces bug-diagnosis time to almost nothing, and makes the delivered system safer. However, it will be a cultural shock to those who have never heard of it, so I don’t expect to convince you of it in 5 minutes. The theory of Design by Contract (DbC) is simple, and is based on thinking as far back as the sixties by Djikstra and others (back in the dark ages;-). In the last 15 years it has been used in various forms in VDM, Z, B and Eiffel. I have used it in Eiffel since 1989, and you will notice that we have it all throughout he openEHR specifications. The OMG has now finally gotten on the bandwagon, and OCL is the language it has created for this same purpose.

To learn about it, there is no better source that Bertrand Meyer’s Object-Oriented Software Construction 2nd Ed. This is the bible of object-oriented programming. If you don’t have a copy, you need to get one! Design by contract is described in about 70 pages, chapter 11. After that do some google serarches and you will see how much activity there is about it. C# will have it completely in the next or following version; there is already a spec# project based entirely on the idea.

The leading candidate for doing it in Java seems to be JML - Java Modelling Language. See http://www.cs.iastate.edu/~leavens/JML/. Have a look - there are many poeple and universities behind this, and the approach seems very solid. One of the designers is an Eiffel expert, so the approach looks quite like Eiffel (all languages will become Eiffel eventually;-). But syntactically it is all comments, processed by a pre-processor that generates an extra .jar.

Now…in practical terms, putting this into the existing code base would take time and involve some redesign (it will actually reduce the number of lines of code), so I am not suggesting doing this right now. Also, JML is not quite up to date with Java 1.5. So - some food for thought here. What I would hope to see is that the team gets acquainted with DbC, and decides to use it - I don’t want to force it!

There are other design issues, that Yin Su will talk about.

But the short term decision to be taken is: will we create the branches as above, and start work on the Release 1.0 upgrade?

  • thomas
2

Thomas Beale wrote:

Rong and others,

my feeling for the way we should be going here is as follows. In the
medium term (say by mid-year), we should aim to have:

    * RM & AM upgraded to Release 1.0
    * all test cases up to date and working
    * contracts in all the code. (See below)
    * potentially some changes to the general design of the core classes

In the short term, what we need is to have the classes upgraded in the
current programming style to Release 1.0, with the test cases upgraded
as well. We can do this at UCL in a few weeks if the rest of he team
agrees to the idea. To actually do it, it means doing the following in
Subversion:

    * declare a tag called "Release-0.95" of the current TRUNK(you can
      choose other names if you want - even funny ones, this is just
      my default suggestion - to follow the release numbering of the
      specification project for now).
    * declare a branch of the same name. This is where work can be
      done for bug-fixes and so on of this release into the future.
      All users of the current system take their builds from this
      branch. Minor releases are declared with tags as necessary.
    * the TRUNK then becomes the current line of work.
    * when the TRUNK is more or less at a stage of being Release-1.0
      compliant, a Release 1.0 branch is declared, and it is tested
      and declared with a tag. The it can be maintained on its branch,
      just as the 0.95 version is on the first branch.

There are other strategies, but I think this is the best one for the
team at the moment - it allows multiple simultaneous releases to co-exist.

Thomas,

I just committed my local copy into the subversion repository. Actually
I had to leave out my updates on the ArchetypeDescription class and
related changes in the parser since there was some annoying bug I
couldn't fix at the moment and I didn't want to delay the commit. So
this revision isn't much different from the previous except that bug fix
in the ArchetypeOntology.

Your branch/tag strategy looks good, let's just do it. After that I can
continue with the AOM and parser update on the trunk by myself.

Now in the medium term, a change in coding style that I want to
convince the team to use is "Design by Contract". This radically
improves the quality and readability of the code and documentation,
reduces bug-diagnosis time to almost nothing, and makes the delivered
system safer. However, it will be a cultural shock to those who have
never heard of it, so I don't expect to convince you of it in 5
minutes. The theory of Design by Contract (DbC) is simple, and is
based on thinking as far back as the sixties by Djikstra and others
(back in the dark ages;-). In the last 15 years it has been used in
various forms in VDM, Z, B and Eiffel. I have used it in Eiffel since
1989, and you will notice that we have it all throughout he openEHR
specifications. The OMG has now finally gotten on the bandwagon, and
OCL is the language it has created for this same purpose.

To learn about it, there is no better source that Bertrand Meyer's
Object-Oriented Software Construction 2nd Ed. This is the bible of
object-oriented programming. If you don't have a copy, you need to get
one! Design by contract is described in about 70 pages, chapter 11.
After that do some google serarches and you will see how much activity
there is about it. C# will have it completely in the next or following
version; there is already a spec# project based entirely on the idea.
The leading candidate for doing it in Java seems to be JML - Java
Modelling Language. See http://www.cs.iastate.edu/~leavens/JML/. Have
a look - there are many poeple and universities behind this, and the
approach seems very solid. One of the designers is an Eiffel expert,
so the approach looks quite like Eiffel (all languages will become
Eiffel eventually;-). But syntactically it is all comments, processed
by a pre-processor that generates an extra .jar.

Now...in practical terms, putting this into the existing code base
would take time and involve some redesign (it will actually reduce the
number of lines of code), so I am not suggesting doing this right now.
Also, JML is not quite up to date with Java 1.5. So - some food for
thought here. What I would hope to see is that the team gets
acquainted with DbC, and decides to use it - I don't want to force it!

There are other design issues, that Yin Su will talk about.

But the short term decision to be taken is: will we create the
branches as above, and start work on the Release 1.0 upgrade?

Yes, I think so! Who should do it and when?

Rong

3

Rong Chen wrote:

Thomas Beale wrote:
  

Rong and others,

There are other strategies, but I think this is the best one for the
team at the moment - it allows multiple simultaneous releases to co-exist.
    

Thomas,

I just committed my local copy into the subversion repository. Actually
I had to leave out my updates on the ArchetypeDescription class and
related changes in the parser since there was some annoying bug I
couldn't fix at the moment and I didn't want to delay the commit. So
this revision isn't much different from the previous except that bug fix
in the ArchetypeOntology.

Your branch/tag strategy looks good, let's just do it. After that I can
continue with the AOM and parser update on the trunk by myself.
  

But the short term decision to be taken is: will we create the
branches as above, and start work on the Release 1.0 upgrade?
    

Yes, I think so! Who should do it and when?
  

Well how I about you create the Release-0.95 branch (I am assuming that
the current code is 0.95). You just need to follow the instructions at
http://www.openehr.org/developer/t_svn_um_project_admin.htm - I am just
suggesting this so you get the experience of doing it; I am happy to do
it as well, no problem.
- t

4

Thomas Beale wrote:

Rong Chen wrote:
  

Thomas Beale wrote:
  

Rong and others,

There are other strategies, but I think this is the best one for the
team at the moment - it allows multiple simultaneous releases to co-exist.
    

Thomas,

I just committed my local copy into the subversion repository. Actually
I had to leave out my updates on the ArchetypeDescription class and
related changes in the parser since there was some annoying bug I
couldn't fix at the moment and I didn't want to delay the commit. So
this revision isn't much different from the previous except that bug fix
in the ArchetypeOntology.

Your branch/tag strategy looks good, let's just do it. After that I can
continue with the AOM and parser update on the trunk by myself.
  

But the short term decision to be taken is: will we create the
branches as above, and start work on the Release 1.0 upgrade?
    

Yes, I think so! Who should do it and when?
  

Well how I about you create the Release-0.95 branch (I am assuming that
the current code is 0.95). You just need to follow the instructions at
http://www.openehr.org/developer/t_svn_um_project_admin.htm - I am just
suggesting this so you get the experience of doing it; I am happy to do
it as well, no problem.
  

It's done!
R

5

Rong Chen wrote:

Well how I about you create the Release-0.95 branch (I am assuming that
the current code is 0.95). You just need to follow the instructions at
[http://www.openehr.org/developer/t_svn_um_project_admin.htm](http://www.openehr.org/developer/t_svn_um_project_admin.htm) - I am just
suggesting this so you get the experience of doing it; I am happy to do
it as well, no problem.



It's done!
R

looks good to me…so this branch is yours to maintain for he purpose of supporting the Karolinska system. And also for short-term support of the existing ADL parser (just to make the part work, so Rahil and Erik’s group are ok in the short term).

The mainline I think we start working on to upgrade to 1.0. Are you happy that Yin Su starts on that? She can do it in small bits if you want to monitor her changes (I know everyone gets nervous when someone plays with their code!). Alternatively, we can create another branch called Release-1.0 right away, and she can work on there, with you reviewing when/if you want. Personally I think it is just as simple to work on the mainline of development if we agree that this is going to be an openEHR Release-1.0 flavoured development line. You can also merge your ADL changes (and any other bug fixes) from the 0.95 line to the TRUNK as well - merging is quite good with TortoiseSVN - not sure about the Linux client tool (but you can always just do it from a Windows machine).

So my advice is:

  • anyone working on the Release 1.0 flavour of the codebase work on the mainline. Rong will still have to coordinate who is touching what.
  • Rong does the immediate fixes needed for the existing ADL parser on the 0.95 release branch, and others build from that
    Rong - you should use the project page as a means of communicating who is doing what and what the todo list is etc etc.

Seem reasonable? Let me know if I can be of further help, otherwise it is over to you. I will support Yin Su on any design questions to do with openEHR and Nathan to help with the testing at UCL.

  • thomas
6

Thomas Beale wrote:

Rong Chen wrote:

Well how I about you create the Release-0.95 branch (I am assuming that
the current code is 0.95). You just need to follow the instructions at
http://www.openehr.org/developer/t_svn_um_project_admin.htm - I am just
suggesting this so you get the experience of doing it; I am happy to do
it as well, no problem.
  

It's done!
R
  

looks good to me...so this branch is yours to maintain for he purpose
of supporting the Karolinska system. And also for short-term support
of the existing ADL parser (just to make the [] part work, so Rahil
and Erik's group are ok in the short term).

The mainline I think we start working on to upgrade to 1.0. Are you
happy that Yin Su starts on that? She can do it in small bits if you
want to monitor her changes (I know everyone gets nervous when someone
plays with their code!). Alternatively, we can create another branch
called Release-1.0 right away, and she can work on there, with you
reviewing when/if you want. Personally I think it is just as simple to
work on the mainline of development if

It depends what is going to be done on the code. If DbC is going to be
implemented with JML in the code, I would like it to be done in a
sandbox like branch.

we agree that this is going to be an openEHR Release-1.0 flavoured
development line. You can also merge your ADL changes (and any other
bug fixes) from the 0.95 line to the TRUNK as well - merging is quite
good with TortoiseSVN - not sure about the Linux client tool (but you
can always just do it from a Windows machine).

So my advice is:

    * anyone working on the Release 1.0 flavour of the codebase work
      on the mainline. Rong will still have to coordinate who is
      touching what.

OK. I will do some comparison between the code and 1.0 specs to estimate
the work, then do little survey to see who is willing to help and with
what. After that I will put down these information on the project page.

    * Rong does the immediate fixes needed for the existing ADL parser
      on the 0.95 release branch, and others build from that

I think they are just the [] and assumed value. Others would require
RM/AOM changes, which should be done on the mainline probably. Please
let me know if there are other urgent fixes.

Rong - you should use the project page as a means of communicating who
is doing what and what the todo list is etc etc.

Sure, I can do that.

Seem reasonable? Let me know if I can be of further help, otherwise it
is over to you. I will support Yin Su on any design questions to do
with openEHR and Nathan to help with the testing at UCL.

Nathan, what kind of testing are you working on? Just curious :slight_smile:

Rong

7

Rong Chen wrote:

Thomas Beale wrote:
  

It depends what is going to be done on the code. If DbC is going to be
implemented with JML in the code, I would like it to be done in a
sandbox like branch.
  

I agree - the current proposal is not to do that at all; it is to do a
fast upgrade to the code, following exactly your current style, and just
making all the classes, attributes and test cases Release 1.0 compliant
- nothing more. The JML stuff will happen later, and definitely in a
snadbox.

Nathan, what kind of testing are you working on? Just curious :slight_smile:
  

he will just do some testing at the moment of the Release 1.0 changes
that Yin Su does - mainly in the interests of getting a bit of
parallelism and reducing the delivery time...Nathan is pretty ties up
with thesis and other things, so it may not be much anyway.

- thomas