|
|
 |
News forum
News forum
News forum |
Messages: 31Messages: 31Messages: 31
Bookmark thread
Bookmark thread
Bookmark thread
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML  |
|
What is the place for MDA and UML?
MDA seems to be a technology that is either loved or hated. There has been an interesting discourse between Eric Newcomer from Iona, and Stefan Tilkov. Common ground was found. As is often the way, there is a place for many technologies.
It all started with Eric Newcomer's statement: Many people look toward graphic arts, line drawings, boxes, circles and arrows to find the future of software.
But I can't really see it.
Software has been language based since the beginning. Proposing that in the future, software will be written using UML and MDA is, to me, like saying books will be written entirely with pictures.
Ok, so some books are entirely pictoral, and icons are important if not critical to human life as we know it. But I can't really see how it's possible to impart real knowledge without using language. Or create precise enough computer instructions.
I can't see that the drawing approach will really work. I don't know of any graphical software development tool that has yet to address the entire lifecycle; or that generates code of sufficient quality.
I think it's just a problem that isn't meant to be solved. Since then the common ground was formed:
- Models can have common ui notation and be graphically driven
- Models can drive metadata
- The graphical notation and the resulting metadata are two completely different concepts and should be managed that way
- XML is a great way to drive a metadata approach
Read:
Jeff Schneider's round-up
Eric Newcomers original post: Graphically Yours
Stefan Tilkov in More MDA Critique
Threaded replies
· What is the place for MDA and UML? by
Dion Almaer on 04/12, 11:03 AM
· What is the place for MDA and UML? by
ABC DEF on 04/12, 01:18 PM
· Beware by
Bill Burke on 04/12, 03:51 PM
· Beware by
vicky kak on 04/13, 12:38 AM
· Beware by
Hans Schw?bli on 04/14, 03:13 PM
· Beware by
vicky kak on 04/15, 01:34 AM
· MDA - Demystified by
Stan Sewall on 04/13, 02:51 PM
· MDA + AOP??? by
George Lawniczak on 04/13, 03:56 PM
· MDA + AOP??? by
Emmanuel Pirsch on 04/14, 09:26 AM
· MDA + AOP by
Stan Sewall on 04/14, 10:02 AM
· MDA + AOP??? by
Brian Miller on 04/14, 02:55 PM
· MDA - Demystified by
Noel Hebert on 04/14, 06:57 AM
· MDA - Demystified by
Parag Gandhe on 04/14, 09:44 AM
· MDA - Demystified by
Stan Sewall on 04/14, 09:52 AM
· MDA - Demystified by
Parag Gandhe on 04/14, 10:31 AM
· MDA - Is the wave of the future by
Felicity Fendi on 04/14, 12:39 PM
· MDA - Is the wave of the future by
Brian Miller on 04/14, 03:01 PM
· MDA - Is the wave of the Future by
Stan Sewall on 04/14, 05:40 PM
· MDA is not just for Visual Models by
Chris Young on 04/15, 12:22 AM
· MDA is not just for Visual Models by
Hans Schw?bli on 04/15, 04:49 AM
· MDA is not just for Visual Models by
Brian Miller on 04/15, 11:05 AM
· MDA is not just for Visual Models by
Chris Young on 04/19, 07:12 AM
· What is the place for MDA and UML? by
han theman on 04/15, 05:05 AM
· What is the place for MDA and UML? by
Brian Miller on 04/12, 06:19 PM
· Eric, you need to read Eric. by
siju odeyemi on 04/12, 06:59 PM
· What is the place for MDA and UML? by
Noel Hebert on 04/13, 08:41 AM
· What is the place for MDA and UML? by
Brian Miller on 04/13, 02:33 PM
· What is the place for MDA and UML? by
Hans Schw?bli on 04/14, 03:21 PM
· What is the place for MDA and UML? by
Hans Schw?bli on 04/14, 03:30 PM
· Response - too much UML by
Stan Sewall on 04/14, 05:32 PM
· Nothing like a drag-n-drop world... by
Steve Mahan on 04/13, 02:24 PM
|
|
|
Message #117668
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
There's always some degree of overzealousness when evangelizing new methodologies. Here's an interesting quote from a recent article about offshore outsourcing by Joe Celko (the SQL guru):For us, the particulars are new technologies and model-driven architecture. Any detail work can go to the developing nations. He claims that those involved in construction/implementation are code monkeys, and their jobs will soon -- or should -- be outsourced, and those involved in the design (exemplified by MDA) are the new jobs of the future.
Personally, I disagree. Coding AND design aren’t necessarily disjoint activities. You can sometimes design or improve a design while you’re coding (XP/Agile), and sometimes you can do some coding while you’re designing (RUP) to make sure your design is feasible and isn’t a castle in the air.
|
|
|
Message #117705
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
But I can't really see how it's possible to impart real knowledge without using language. XMI is a language. Eric is a fool.
|
|
|
Message #117708
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Eric, you need to read Eric.
Eric seems to lack the knowledge required to make any conclusions on the subject of software design (and whether or not we need graphical models for it).
His article "Graphically Yours", is just a tad bit naive (and vague - hence he isn't really saying anything new or relevant). Perhaps Eric needs to read books such as "Building J2EE Applications with RUP" (assuming he hasn't read it already) and he should also read Eric Evan's book on Model Driven Design.
|
|
|
Message #117739
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Beware
Beware of "architects" that are allergic to code. Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .
|
|
|
Message #117771
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
After reading his blog it seems to me that
Eric's frequent references to "...I can't really see it"
and "...I can't really see how..." that he is *not*
a visually oriented person. This in not a bad thing
just an observation.
For him, modelling or "...the drawing approach..." does not
work for him. He writes "Software has been language based
since the beginning". I could construe that "language based"
is more like "text"(?).
I am not saying his view of the UML/MDA landscape is
wrong, maybe different from mine.
For me, I think in pictures. So modelling (UML) is natural
It allows me to *communicate* what I see in my head.
MDA (for me) is a reasonable extention to transform those
pictures into working code.
I am not suggesting that MDA is some "silver bullet" to
some how graphically (magically) write 100% working code.
I will say that if MDA technologies can generate from
models 80% working code with some degree of efficency
than I am all for it! That leaves me and my team the
20% to focus on the business logic.
|
|
|
Message #117839
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Nothing like a drag-n-drop world...
I can't really see that there's no room for
an approach that saves me work and lets me focus on
keeping my customers happy (that's supposed to be
the end result isn't it?). Certainly no generator can
assume what doStuff() means to my application, I need
to code that. Why is it so wrong if plumbing and/or
persistance are handled for me provided I can control
and modify the output to my satisfaction?
Most people who are continually facing real development issues
don't want to keep rewriting the exact same code in a different situation.
Otherwise there'd be no Xdoclet or other tools of it's type.
If the tools actually let me draw 40-80% of the grunt work,
with a reasonable measure of control, what's the problem?
No one is suggesting a drag-n-drop world, but it seems
pretty feasable (even if the tools aren't mature enough
today) to model the obvious stuff with enough success
that I can save valueable time for me and my customers.
|
|
|
Message #117843
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
After reading his blog it seems to me that Eric's...*not*a visually oriented person. This in not a bad thing just an observation. Actually, it *is* a bad thing to be an engineer with trouble visualizing. 90% of the human sensorium is visual. An architect who can't sketch is handicapped.
Text procedures predominate since they're suited to very primitive editors (vi, emacs). That's an historical bias towards editing text. Don't assume that what's entrenched is inherently best.
|
|
|
Message #117849
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Demystified
The major problem most developers have is a religious one. We, being a former hand-down developer, have been culturalized that hand-cranking code is the best way to create...or this one I get a lot..."I have my own libaries I maintain. I don't need it." Needless to say, the person maintain everything by hand..and nothing is documented! As part of the past expereince of trying CASE tools from 80s, the tools alway bound you to the architecture dicated by the software vendor. The primary difference between CASE and MDA is MDA gives the ability to take the change the architectual deployment targets.
The mind shift of communication of pictures from the PIM instead of the "verbal documentation". The cranking out of code w/out proper documentation has been the mainstay for our industry for the past 40 years. Now that you can have good workable code from a model, then on top of that...if you don't like it, you can change it in the PSM level. I always get a good chuckle when I hear some called "experts" say that MDA won't work...its too hard. I had to hear from industry experts 8-9 years ago that the web was a joke. Even Billy Gates said the web was not going to be taken seriously. Enough of the soap box.....
MDA/UML is the future of development. When you can approach 90%+ source code generation from a UML/PIM/PSM Model, it makes BUSINESS SENSE TO USE OR TRY MDA IN A COMPANY. MDA should and will have off-shore development quaking in their boots. If you own an off-shore development house...enjoy the time..because its short-lived. Its going to be a combination of Agile/MDA process moving forward.
|
|
|
Message #117866
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA + AOP???
My thought is that Aspect-Oriented Programming makes MDA feasible. Domain classes that implement the domain model are cleanly generated, then the other system functionality can be woven in via the aspects. The domain model itself is but one dimension in a multi-dimensional system.
Essentially aspects take care of the bi-directionality issue that has plagued efforts to implement MDA.
|
|
|
Message #117942
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Demystified
Stan, your points are spot on!
What I often hear most is that MDA/Code Generation/etc
cuts out my creativity! Yeah right. How much "creativity"
is there in writing a DAO?
This sort of thing is monkey code and automatable.
This is a circumstance of our creation. It is called *PATTERNS*.
I have been in IT since the mid-1980s. I have written more
lines of code in various languages then I care to think
about. After a while the code patterns become pretty damn obvious.
MDD (Model Driven Development) properly utilised, allows
me and my team to generate the 80% of the grunt, repetitive
crap code and focus on the 20% that actually has some
meaning. *Thats* where we get creative!
|
|
|
Message #117962
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA + AOP???
My thought is that Aspect-Oriented Programming makes MDA feasible... Essentially aspects take care of the bi-directionality issue that has plagued efforts to implement MDA. My line of tought goes in the same direction as yours... AOP and MDA are very complementary. While it's possible to do the equivalent of AOP with code generation, it does not really solve the problem that AOP as been designed to solve. With MDA (without AOP), you still have to have to implements your cross-cutting concerns in your code generation templates. This complexify the templates for nothing and there will be duplicate code in different templates.
MDA alone is fine when you want to to transform a PIM into a PSM, like when you want to make some Entity class in the PIM an Entity Bean in the PSM. This kind of transformation is very difficult (probably impossible) with AOP. However cross cutting concerns like logging, fine-grained security, context management, transaction management are more easily (and cleanly) done using AOP.
BTW, we are in the infancy of MDA... Tools are just begining to appear on the market (and none of them are perfect). Architects, designer and (the most important) customers are just starting to get a grasp on how to implement the approach in real life projects. It will take some successes and a lot of faillures before the best practices are defined. I do beleive that the overall goals of MDA will be achieved and the software development industry will grow up as a result.
|
|
|
Message #117965
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Demystified
Can anyone give an example of non-trivial Enterprise System developed and maintained using MDA tool? What kind of software development methodology work well with MDA? Which MDA tools are available in market that go well with large applications?
- Parag
|
|
|
Message #117970
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA + AOP
Emmanuel....MDA product have been around for 8+ years. This is not a new technology. I have been working in this space for 6 years. The only instance that I have found where MDA does not make a very good play is with building portals. Portals require very little transaction management, generally just push content. When it comes to building a system, or having to integrate a group of systems across an enterprise..MDA scales and the technology delivers. The problems that I have seen, because companies usually get themselves into trouble...which they hire me to bail them out...is that they underestimate the impact of MDA within an organization...from Key Intiatives all the way down to operational maintenance. That is the falicy of package software..thinking that package software will get you there quicker...but it doesn't. Its usually about 4X more expensive to implement a package software than customize development. Now with MDA, pending the application, package software is about 8-9x more expensive than a MDA approach.
Remember all....You still have to design anyway...why not use a PIM/UML for the communication module with an org. It works great.
|
|
|
Message #117989
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Is the wave of the future
MDA has been around for quite a few years and has been proven in large enterprise-strength applications. Ofcourse, it is not a silver bullet; and, ofcourse it will continue to evolve and improve.
In our establishment, we have a long term vision of increasing average IT-employee productivity by 25% each year, with the help of MDA, AOP and UML. We realize this will be true only for new development, not for maintenance work.
Currently, we have about 120 analysts, architects, developers working on new development. Assuming we acheive our goal of 25% annual productivity improvement, in 4 years, we hope to get the same work done with just 60 people.
Does that mean 60 people will lose their jobs? No. They will join the 800 IT people who are assigned to xisting (a.k.a. legacy) systems.
|
|
|
Message #118016
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA + AOP???
With MDA (without AOP), you still have to have to implements your cross-cutting concerns in your code generation templates. This complexify the templates for nothing and there will be duplicate code in different templates. The claim above in bold is a myth. Templates can be normalized by refactoring out common code into template utility methods. Cross cutting concerns were addressed in model compilation decades ago. Eg, Shlaer/Mellor 'coloring'.
|
|
|
Message #118020
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Is the wave of the future
In our establishment, we have a long term vision of increasing average IT-employee productivity by 25% each year, with the help of MDA, AOP and UML. ... Does that mean 60 people will lose their jobs? No. They will join the 800 IT people who are assigned to xisting (a.k.a. legacy) systems. Legacy maintenance, the last refuge for hand coders.
|
|
|
Message #118024
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Beware
Beware of "architects" that are allergic to code. Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .
In our team we have designers who rarely have coded before. I don't mean analysts or architects, but designers who can't code really. Senior developers are good rooted in the hierarchy and they have more power, although their knowledge might be outdated in some important areas, like coding. Such a senior developer became project leader. He liked to work with a special junior coworker so much, so he let him rise up in the hierarchy nearly up to his level. This junior developer has nearly no experience in programming. But he designs the applications with the project leader, who also has nearly no experience in programming. As long as they can command the coders, they feel happy I think.
|
|
|
Message #118029
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
I will say that if MDA technologies can generate from models 80% working code with some degree of efficencythan I am all for it! That leaves me and my team the 20% to focus on the business logic. In my eyes, using UML starts to get cumbesome and unproductive after covering maybe 33% of your application's design/implementation with UML/MDA. Now imagine how cumbersome MDA would be if 80% could be covered by it. Executable UML? I don't believe in such a ultimate goal.
Do you know that gold can be created artificially? Don't ask me how, a teacher told it to us many years ago. But its many times more expensive than digging for the gold. Now apply this example to xx% MDA and you know what I mean.
|
|
|
Message #118035
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
I have another example against MDA and too much UML.
The Germans built the biggest railroad gun ever. It is called "Dora". They thought, guns are good, so lets make them bigger, then they must be even better. This sounds logical, but it wasn't. It didn't "scale". The sideeffects scaled much more than the effects.
In my eyes, executable UML and MDA is an attemt like "Dora". The sideeffects of it will scale much more than the effects.
By the way, the even invented a rifle which could shoot around the corner (really). That would be an analogy to Entity Beans ...
|
|
|
Message #118060
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Response - too much UML
Hans...the problem with your statement is the fundamental premise of UML. To say that UML would be too cumbersome once you reach a certain level...
Well my response is that you still have to design in UML/PIM. Almost all of the vendors only require you to use between 4 - 6 of the fundamental designs of the UML standard. Now you actually have a working bridge between the design and code. The problem with the industry is that developers don't like to document what they do....or, this is the biggy....there has never been a value placed on design, because it was seen as a seperate function. Now...the design=code bridge is mature enough to work mission-critical application in the org.
Yes you are right, the Germans developed on a gun to shoot around the corner. In 1944, because of constant village fighting with Allied forces against Germany, the US Army developed a device that fits on the end of the M-1 rifle to shoot bullets from around the corner as well.
The analogy is, "It doesn't hurt to copy a good idea."
|
|
|
Message #118062
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA - Is the wave of the Future
That's a cheeky response...but an accurate one.
Think about this....anything that does not have a model/PIM attached to it will be a legacy system. Including non-MDA J2EE systems built!!
|
|
|
Message #118107
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA is not just for Visual Models
I have been developing J2EE applications for about 2 years using MDA and I constantly read these discussions about how silly MDA is because you could never build a system using entirley visual models!
Well, if you read the MDA standard it actually does not specify that you must model your system using a visual model. It does say that your PIM and PSM should be expressed in a formal language (ie, one that a computer can parse and understand).
The thing that is starting to make MDA popular is the availability of languages that are both formal and visual (ie UML).
In the MDA projects I work on, the PIM and PSM models are about 50% visual (ie using UML. The other 50% of the model is made up of property extensions and formally expressed business rules (eg if, then, else etc)
The real importance of MDA is not the visual use of UML at all. It is about mapping the business requirements to appropriate levels of abstraction. In MDA this is done by having a Platform Independent Model, A Platform Specific Model, A Code Model, a method to transform between your models and a way to preserve detail changes to each model.
We laugh at the very idea of writing Assembler by hand these days, once upon a time Assembler writers laughed at the ridiculous notion of a compiler!
4GL's were one step up from 3gl code, however these have been too specific to certain kinds of applications, proprietary and sometimes inflexible.
MDA has a better hope at long term success at raising the level of abstraction and Software Development because it is efficient, flexible and based entirely on open standards.
|
|
|
Message #118111
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Beware
Beware of "architects" that are allergic to code. Architects are well versed with designing the Application and focus more on the issues which can be noticed upfront and taken care of , and I believe the Architect definetly must have passed throught the coding phase? Dont you have the opinions matchining with mine , so let them foucus on the issues for which they are hired , ya design related issues .
In our team we have designers who rarely have coded before. I don't mean analysts or architects, but designers who can't code really. Senior developers are good rooted in the hierarchy and they have more power, although their knowledge might be outdated in some important areas, like coding. Such a senior developer became project leader. He liked to work with a special junior coworker so much, so he let him rise up in the hierarchy nearly up to his level. This junior developer has nearly no experience in programming. But he designs the applications with the project leader, who also has nearly no experience in programming. As long as they can command the coders, they feel happy I think.
I think your designers play just the role of Domian specialist , probabily capturing the function requirements and then delegating the techical work to the Developers.But to be the genuine architect one must have passed throught the coding phase extensively , that is my opinion
|
|
|
Message #118138
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA is not just for Visual Models
Chris Young:
In our company we don't even get the time to make an analysis modell. Now you expect companies to abstract even further, to create a platform independent model and then a platform specific model.
I don't know if the company I work for is thinking in short terms and neglecting the long terms and the big picture. But I could imagine, that there are some more companies, who just use one model, the design model (because of time to market and intitial production costs).
Someone talked that MDA contains a platform independent language. We already have that: Java. So what do you suggest? Leaving Java and learning that MDA programming language? Of course there are differences, but basically I think that trading Java for MDA language is just the same thing in pink color.
|
|
|
Message #118141
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is the place for MDA and UML?
Software has been language based since the beginning That statement was enough for me to decide not to read the article. UML is a language. Java is a language. Assembler is a language. Object code is a language. Just different levels of abstraction.
For specific domain, applications can already be built visually.
One quite nice example is Lego robots. You can write advanced programs and even use subroutines (abstracted as blocks). My 9 year old son does it all the time. It's REAL programming, just visual.
|
|
|
Message #118201
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA is not just for Visual Models
Now you expect companies to abstract even further, to create a platform independent model and then a platform specific model. Ideally the PSM would be automaticly generated, so the human is responsible for only one model. This is akin to writing Java once and having it automaticly translated to machine language by a variety of platform-specific JVMs at no additional cost.
|
|
|
Message #118572
Mark as noisy
Mark as noisy
Mark as noisy
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MDA is not just for Visual Models
Chris Young:In our company we don't even get the time to make an analysis modell....Someone talked that MDA contains a platform independent language. We already have that: Java. So what do you suggest? Leaving Java and learning that MDA programming language? Of course there are differences, but basically I think that trading Java for MDA language is just the same thing in pink color. Perhaps if you did spend more time on the analysis and you used MDA principals, then you would spend less time hand coding, then have more time for analysis on the next project :-)
Actually, you make a good point about Java being platform independent already. Sure it is, if you already have written a java application you expect it will run independent of the hardware you choose (as long as there is a JVM or Application Server for that platform). But will it automatically be Independant of the Architecture?, ie, will it run 2-tier or 3-tier? Will it be a web application or a SWING application, or SWT? Most Java is written to a "Platform Specific Architecture", which means you have to re-write a 2-tier application if you want it to use EJB's properly within an application server.
In MDA terms a true "Platform Independent Model" is what which expresses the pure business rules, and is completely, as far as possible, removed from the contraints of a particular hardware/implementation architecture.
If you are clever about it, nothing stops you expressing your PIM using the formal syntax of the Java language to define loops, conditionals, business object references, business attributes etc. This PIM can then be transformed automatically to multiple platform specific models (eg Web Model, EJB model, DBMS model, Web Services model, CORBA model, .Net model, Cobol Model etc).
There is some up front work to write your PSM transformations, but this is akin to spending time building an assembly line for a Car factory. Your factory will take longer to build than a factory without an assemly line. But who will put who out of business in the end?
For a long time developers have been looking for the holy grail of re-use in the Components themselves, many now realise that the re-use is in building the correct assembly lines. These days we call them "transformation patterns".
Eventually, traditional "code cutters" will decline, and new 21st century jobs will be created: "Pattern Developer", "Transformation Engineer", "Platform Independent Modeler", "Platform specific modeler" ... Don't scoff - these jobs are already here!
|
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Chris Webster and Srividhya Narayanan, both Sun engineers working on the Java Studio Enterprise Tools Organization, had a tech talk on things like asynchronous web services, security, orchestration, tools, and binding to services.
(Sep 1, Tech Talk)
The excerpt from Manning's "Ajax in Action" applies refactoring and patterns to the client-side codebase, showing how normal Javascript code can be refactored into a robust view component.
(Aug 26, Article)
J2EE and XML Development teaches how, where, and why to use XML in each layer of a J2EE application. The book categorizes and explains many recent Java and XML technologies and the ways in which a J2EE application can best use them.
(Book PDF Download)
In this article, Phil Zoio puts these frameworks head-to-head, comparing each on its merits. He rates the two on critical aspects of their design, development and runtime environments.
(Aug 24, Article)
In this article on building custom JSF UI components, Chris Schalk walks readers through creating a new JSF component - a "Hello, World" component at first, becoming a stock price component in the end.
(Aug 16, Article)
In this article, Wang Yu will take you on a tour of the technology inside J2EE clustering and let you know the features and limitations of some popular J2EE clustering products.
(Aug 12, Article)
TestNG is a promising new testing framework that addresses many of the shortfalls of JUnit. Hani Suleiman shows readers how they can migrate from JUnit to TestNG in this article.
(Aug 10, Article)
In the talk, Rod takes a first-principles approach to explaining persistence, discusses 8 lessons learned dealing with persistence, and discusses Spring JDBC.
(Aug 2, Tech Talk)
In this article, David Whitehurst explains how SAML, the Security Assertion Markup Language, might be used in a single-sign on product, and issues a call for arms for a SAML server solution.
(Jul 29, Article)
Bill Burke walks the audience through real world examples of applying AOP to everyday software development.
(Jul 21, TSS Symposium 2005 Presentation)
TSS and the Belgium Java Users Group have partnered to bring you an online presentation from one of their recent JUG meetings, hosted exclusively on TheServerSide.com.
(Jul 18, Tech Talk)
Justin Lee has written up a comparison between JUnit, JTiger, and TestNG, focusing on the differences between them to illustrate how each might be used.
(Jul 15, Article)
Dave Thomas, one of the Pragmatic Programmers, talks about ways to improve programming proficiency by diversifying the "knowledge portfolio," and discusses the place of Ruby, Python, and Groovy in the developer's tool belt.
(Jul 13, Tech Talk)
Cameron Purdy and Patrick Linskey focus on the primary source of performance and scalability woes in the J2EE environment: the database.
(Jul 7, TSS Symposium 2005 Presentation)
This article explains the concepts behind Dependency Injection using real word examples and demonstrates with code how DI is done in the top 4 DI frameworks.
(Jul 5, Article)
TheServerSide.com was at JavaOne and here is coverage of the four day event.
Day 1 | Day 2 | Day 3 | Day 4
(Jul 4, Coverage Articles)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
