Hi Jeroen, My experience is similar. I was always suspicious of the "code generation " approach, inevitably gives 2 "sources" that get out of step.
The only good exception I saw was TogetherJ where "the code is the model" Best Regards Mike Burton (Sent from my iPhone) > On 15 Nov 2015, at 23:44, Jeroen van der Wal <[email protected]> wrote: > > All very interesting! > > Over the years I tried numerous modelling tools and only the low-tech ones > stayed: drawing on a whiteboard, using coloured index cards [1] (learned > from Dan) or using a simple online tool like yUML [2]. And I only use them > to communicate the broad picture or for explorative purposes. > > I gave up on code generators: I always ended up fighting the generated > code. And the impression that they support rapid application development > proved wrong: at the point where you had to work on more advanced stuff > velocity came to a halt. If an application is built on lots of repeating > code snippets then my conclusion is that the underlying framework is not > good enough. > > I love source code that tells the story of the application. Where > everything that could be left out of the code is eliminated. Very DRY, > convention over code. This has drawn me to Naked Objects and made me decide > to spend my time on Apache Isis. > > As you imagine by now I would not take the route from diagram to code. For > me the code editor is the sole canvas to express your ideas. And I think > that if we keep improving Apache Isis on a few points there will never be a > need for an additional tool: > > 1) Reduce boilerplate and make writing an application skeleton as easy as > the easiest modelling tool. This has the advantage that a software > architect can sketch the application and leave it to his developers to fill > in details. But everyone is working on the same code base using the same > tools. In this area we started using Lombok. Also Dan had an idea to make > it possible to create your own custom annotations which can combine > multiple annotations. > > 2) Visualise the meta model. With contributions and mixins the application > logic can come from anywhere. This is architecturally sane but makes an > application hard to grasp. It would love to see a maven plugin that > generates appealing documentation from the meta model of an Isis > application. > > 3) When taking the visualisation concept a bit further it would be very > powerful to explore and navigate the meta model within the IDE. Any plugin > developers here? > > That's just my two cents. > > Cheers, > > Jeroen > > >> On 15 November 2015 at 21:01, David Tildesley <[email protected]> wrote: >> >> >> >> >> >> >> On Sunday, 15 November 2015 5:37 AM, Dan Haywood < >> [email protected]> wrote: >>> Thanks for this James. >> >>> My observation re: using the (relational) data model as the initial input >>> though is that this is likely to lead to rather coupled code, ultimately >>> not maintainable. >> >> Couldn't agree more. >> >> >>> So, while going from the database up to the domain is fine for a single >>> module of 10 or so entities, any app that is bigger than this really >> should >>> be modelled from the domain down to the database. >> >> Quite right. Any business app that is non trivial should be domain >> modelled. >> >> David. >> >>> Dan >> >> >> >> >> >>> On 14 November 2015 at 15:00, James Agada <[email protected]> wrote: >>> >>> I actually tested out using Telosys to generate an isis app from database >>> definition. It did work but of course it meant i did the ER first. I used >>> MySQL, did the ER modelling on the workbench, forward engineered into the >>> database and then used telosys scripts to generate a functional Isis >>> application. Did it as a PoC but we will come back to it later. >>> James Agada >>> Chief Technology Officer >>> >>> >>> On 14 Nov 2015, at 3:49 PM, Óscar Bou - GOVERTIS <[email protected]> >>> wrote: >>> >>> Many thanks, Stephen for this detailed explanation. >>> >>> The problem I’m facing is that I intent to communicate the developers >>> what’s the model to implement. >>> >>> And I usually don’t find big mistakes in action code, but what mostly >>> forces us to refactor is miscommunication regarding the Domain Entities, >>> attributes and actions names, including typos (think my team speak >> Spanish >>> but they’re modeling in English) or wrong or missing relationships >> between >>> those entities. >>> >>> All that could be avoided by firstly agree in a common UML Class Diagram. >>> >>> If it can potentially generate automatically the Java skeleton with >> Apache >>> Isis annotations is a big plus, as it will avoid mistakes when moving >> from >>> design to implementation. >>> >>> And if it could potentially reverse engineer Java (incl. Apache Isis >>> idioms) a really good feature. >>> >>> Any ideas about what tools could best adapt to the workflow (that could >> be >>> potentially customized to cover the last 2 whishes) ? >>> >>> >>> Thanks, >>> >>> Oscar >>> >>> >>> >>> >>> El 14 nov 2015, a las 2:03, Stephen Cameron <[email protected]> >>> escribió: >>> >>> Hi Oscar, >>> >>> In a qualified way I think your idea has merit. I have never used UML for >>> design, but a few years ago I decided to take a good look at it and see >> it >>> if was useful. The idea of being able to draw a diagram and generate code >>> from it seemed sensible, after all that is what is done by most other >>> 'design' professions, such as building architects and engineers. >>> >>> To cut a long story short I realised after some reading that it was not >>> that simple, and that OO languages themselves are really all that are >>> needed for the process of designing a system. This is "the code is the >>> design" school of thought, mainly attributed to Jack Reeves [1]. >>> >>> I found that keeping code and UML diagrams in sync in a top-down 'UML to >>> code' design process will always be problematic (maybe why there are >>> apparently no open-source tools that claim to do this). Then I read about >>> Domain Driven Design which seemed to agree with this premise, and from >>> there found Apache Isis via Dan's book. >>> >>> So now for me UML class diagrams do have an after the fact use for >>> documentation purposes and if a solution implement was capable of that >>> reverse generation of diagrams from code it would be a good thing to >> have. >>> Entity Framework can do this, its their "code first" approach. >>> >>> Given that the-code-is-the-design is true, I think that UML class >> diagrams >>> real main value is as a data model, the question then is why not use a >>> purely data-modeling tool and generate Java classes off it. Then the >>> diagrams 'designed' could have a usefulness to programmers and to system >>> users, something like those created SchemaSpy [2] for example. >>> >>> There are already useful and free Java class generation (binding) tools >>> from off data-models, of one sort or another, such as JAXB, DataNucleus' >>> schemaGen[3], even CAM [4]. >>> >>> Here is my vision of what I think would be really useful: to have a >> design >>> tool that can be used by non-programmers to create a simple data-model, >> and >>> then to have that create a working Apache Isis based CRUD system. This >>> could serve your purpose (I guess) and also find a wider use. >>> >>> The means of achieving this would I think, require something like the >>> "dynamic classes" in available in the Moxy framework [5], that is, map >>> based so that no Java class compilation is needed. Instead, a data-model >>> configuration file (a schema) is read-in to configure the system. This is >>> not a strange idea, in fact its the data-driven programming paradigm that >>> is the basis of the original browser concept (before it was turned into >> OO >>> application framework via addition of Javascript). In the browser the >> data >>> is HTML that is turned into an in-memory Document Object Model (DOM) for >>> rendering. >>> >>> As a blended solution between Apache Isis as it is currently (heavily >>> influence by naked objects, an OO modelling based approach for creating >>> custom *behavioural* applications) and this additional mainly data >> focused >>> approach, I think a programmer developing a business application would >>> start off with these dymanic classes and then in time 'harden' the design >>> by generating and compiling real Java classes from off the model. [A >>> non-programmer wouldn't get past the first design 'phase' usually, but >>> still end up with a useable UI.] >>> >>> In addition, by having separate abstract model-generated classes, that >> can >>> be overwritten if the data-model changes, and concrete implementation >>> classes, where you put all your behavioural code and that are never >>> overwritten, you get close to the 'round-tripping' that would seem to me >> to >>> be the only valid way to use UML *for design*. I think this is how the >>> Eclipse Ecore models work, that there are model classes and >> implementation >>> classes that extend the model classes. The IDE will often warn you when >>> these two sub-models have inconsistencies. This duality also offers an >>> alternative means to achieving the goals of Lombok it would seem. >>> >>> Of course, sitting in the middle of all this is a meta-model, that >> creates >>> the dynamic classes, generates and compiles the 'hardened' model classes >>> (when used) and maps either of these means to a UI 'viewer'. >>> >>> For such data-management frameworks, the complicated aspect isn't so much >>> going from the designed data-model to Java, there are lots of examples of >>> that, instead its being able to have also, a dynamic query capability. So >>> that a person unfamiliar with the dataset, can, via its data-model, start >>> querying it (and also maybe integrating it in real-time with other online >>> resources, the idea of a data-browser appeals!). >>> >>> In the science domain, where I worked for a few years building >>> data-management infrastructure, there are highly advanced systems for >>> online data access and querying e.g. [6], but at the same time a common >>> tool used for small databases is still Microsoft Access. Access has many >>> strengths as a desktop database, including form generation and also >> dynamic >>> query-by-form, but the problems arise when you want to make such data >>> publicly available, in the sense of being findable and searchable in real >>> time. You might as well have used a web-based system from the start and >>> then been able to easily open it to the world at the appropriate time. >>> >>> Having though about this problem for a number of years and spent alot of >>> time working on a XForms based solution as well. I'd be very interested >> to >>> see Apache Isis broaden its scope to offer what I have described, in fact >>> its doesn't seem to need very much more than what is already present in >> the >>> Isis meta-model and Wicket viewer. The Restful objects support already >>> provides a generic 'generated' web programming interface. >>> >>> In summary I know that there are some Java projects that make very >>> effective use of a Model Driven Architecture approach (e.g [7]), but I am >>> now not sure that UML is the 'be-all-and-end-all' basis of that. >> Actually I >>> think that data-models are the basis of most of MDAs efficiency dividends >>> and that there are other approaches, specifically that conceptual models >>> offer more versatility in terms of who and how you can make use of them. >>> This thinking goes way back, such as Sowa's Conceptual Graphs [8] and >> even >>> to Codd [9]. A modern expression of Sowa's thoughts (I gather) is the W3C >>> semantic web, but he was thinking of database design and query way back. >>> >>> Apart from some additions to Isis, another interesting aspect is looking >> at >>> the mapping to data-stores, using a graph database of one sort or another >>> to avoid the complexity of ORM is a simple answer to that I feel. Again, >>> the hardening of a design might mean manually adding a few overrides of >>> default ORM mapping rules into some behavioural-model classes, that >> extend >>> generated data-model classes (getters and setters only). >>> >>> >>> [1]http://www.developerdotstar.com/mag/articles/reeves_design_main.html >>> [2]http://schemaspy.sourceforge.net/sample/relationships.html >>> [3] >> http://www.datanucleus.org/products/accessplatform_2_1/rdbms/schematool.html >>> [4]http://camprocessor.sourceforge.net/wiki/index.php/Main_Page >>> [5]https://wiki.eclipse.org/EclipseLink/Examples/MOXy/Dynamic >>> [6]http://www.opendap.org/ >>> [7]http://www.opencrx.org/ >>> [8]https://en.wikipedia.org/wiki/Conceptual_graph >>> [9]https://en.wikipedia.org/wiki/Relational_Model/Tasmania >>> >>> >>> >>> On Fri, Nov 13, 2015 at 8:45 PM, Óscar Bou - GOVERTIS < >> [email protected]> >>> wrote: >>> >>> >>> Hi all. >>> >>> I’m considering re-introducing UML Class diagrams in our workflow mainly >>> for: >>> - graphically design the domain entities. >>> - modeling relationships. >>> - agree with names of properties, collections and actions needed. >>> >>> It would be wonderful if the UML solution could also be “integrated” with >>> Apache Isis or Java, automating at least the entities Java skeleton >>> generation. >>> >>> I’ve worked extensively with Rational Rose and Sparx EnterpriseArchitect, >>> but was thinking about an Eclipse-based solution that could “potentially” >>> be adapted to generate the Java entities with Isis annotations. >>> >>> Before joining the Apache Isis community I developed [1] for Enterprise >>> Architect for automatically generating Spring Roo-based classes, but Isis >>> was better suited for our project and I abandoned it. >>> >>> >>> Any ideas? >>> >>> Thanks, >>> >>> Oscar >>> >>> >>> [1] http://roomodeler.com >>> >>> >>> >>> >>> >>> >>> This email and any attachment thereto are confidential and priviledged. >> if >>> you have received it in error, please delete immediately and notify the >>> sender. Do not disclose, copy, circulate or in any way use it. The >>> information contained therein is for the address only, if you reply on >> it, >>> its at your own risk. Emails are not guaranteed to be secure or error >> free, >>> the message and any attachment could be intercepted, corrupted, lost, >>> delayed, incomplete or ammended. Computer warehouse group and its >> divisions >>> do not accept liability for damage caused by this email or any >> attachment. >>> The message you tried to print is protected with Information Rights >>> Management. You don't have the necessary user rights to print the >> message. >>> >>> >>> This email and any attachment thereto are confidential and priviledged. >> if >>> you have received it in error, please delete immediately and notify the >>> sender. Do not disclose, copy, circulate or in any way use it. The >>> information contained therein is for the address only, if you reply on >> it, >>> its at your own risk. Emails are not guaranteed to be secure or error >> free, >>> the message and any attachment could be intercepted, corrupted, lost, >>> delayed, incomplete or ammended. Computer warehouse group and its >> divisions >>> do not accept liability for damage caused by this email or any >> attachment. >>> The message you tried to print is protected with Information Rights >>> Management. You don't have the necessary user rights to print the >> message. >>
