Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
Notice: In order to edit this ticket you need to be either: a Product Owner, The owner or the reporter of the ticket, or, in case of a Task not yet assigned, a team_member"

User Story #96 (closed)

Opened 18 years ago

Closed 17 years ago

Grand Unified Modelling

Reported by: sfrank Owned by: sfrank
Priority: minor Milestone: 3.0-M3
Component: DSL Keywords: Modelling, Documentation, EMF,
Cc: jamoore Story Points: n.a.
Sprint: n.a. Importance: n.a.
Total Remaining Time: n.a. Estimated Remaining Time: n.a.

Description (last modified by jmoore)

Goal of this story is to increase the quality of the documentation of the system and to unify the sources, from which artefacts are generated. For a full discussion&Motivation of this story see GrandUnifiedModelling.

The goals in detail are:

  • Use UML as the single source for code-generation in the system
  • Use this UML as the basis for an elaborate and complete documentation
  • Use off-the-shelf-tools for UML-Visualization, Template-Production and Code-Generation whereever possible

Getting from a specification of users objects to a running version of code usually works like this:

  • requirements for new business-objects are gathered and layed down into UML
  • this UML is then manually translated into DomainSpecificLanguage?
  • the build then generates from this dsl all required artefacts (*.java, *.hbm.xml, ddl, etc.)

Although this approach is now tried and tested, it has some drawbacks:

  • manual step to get from UML to DSL: There is no automatism to translate the UML we use to specify the object-model into the DSL from which the actual code is generated. There are also no tools available to visualise the DSL. If the goal to enable end-users to make up their own types can actually be achieved with the current state of the dsl is not clear. Writing correct XML for the DSL's is not trivial and would need a significant investment into supporting infrastructure (an editor that supports code-completion and validation, visualization-tools etc., tools for documentation)
  • documentation and model can get out of sync: As the dsl is the actual basis for the code, deltas between this dsl and the underlying can occur.
  • UML is not required to be valid and complete: As no actual code is generated out of it, there is no single source for documentation. Therefore, the UML is not yet used as the single source for complete documentation of the business-objects in the system. (There have been some efforts to document the ER-Model, as it gives a complete picture of whats in the database. Although this gives you a good overview of the system, this documentation is not stable. The DDL gets regenerated whenever changes in the DSL occur, therefore it becomes hard to maintain this documentation.)

This a huge task, it is therefore split into several sub-stories:

  • Migration to ejb3/annotations:
    • #93: Migrating from *.hbm.xml
    • #94: Annotations for Search
    • #95: Ensure Testablility

  • Model-Cleaning
    • getting the UML-model right to the point where we can generate the whole domain-model from it
    • documentation of the model (ongoing task...)

Change History (4)

comment:1 Changed 18 years ago by jmoore

  • Description modified (diff)

comment:2 Changed 18 years ago by jmoore

  • Cc jmoore added
  • Milestone set to 3.0-M3
  • Version changed from 3.0-M2 to 3.0-M3

On completion review #87 and #174.

comment:3 Changed 18 years ago by jmoore

  • Owner changed from jmoore, sfrank to sfrank

comment:4 Changed 17 years ago by sfrank

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets. You may also have a look at Agilo extensions to the ticket.

1.3.13-PRO © 2008-2011 Agilo Software all rights reserved (this page was served in: 0.64647 sec.)

We're Hiring!