|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 18
Messages: 18
Messages: 18
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Grady Booch Fires Back at Software Factories
In a recent article on IBM's developerWorks, Grady Booch responds to many of the claims put forth in a brewing blog war over Microsoft's software factories advantages compared to MDA using UML. Citing factual innacuracies and a confusion of the use of tools versus language definition, he points out several statements that he considers false.
I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies of the same thing, although perhaps with slight variants therein. There's no doubt that reuse at the level of design patterns or, even better, vertically-oriented architectural patterns is a Good Thing, but what Microsoft is proposing to do is not exactly like the manufacturing metaphor, and so their use of the term is a bit misleading (although Steve has curiously used the image of a conveyor belt when describing the Microsoft factory process). Tom Demarco in his book Why Does Software Cost So Much? sets aside a chapter on software factories in which he notes - and I agree with him - that "I think factory methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production activity. Organizations that try to make it into a production activity produce bad software (though potentially lots of it)."
In his article, Booch singled out blog postings by Alan Will as factually incorrect.
Will's blog had a number of errors of fact, which Bran Selic has pointed out to me and so which I'll paraphrase here. Alan wrote "So here's why we don't want to limit ourselves to the UML as a basis for our users' domain-specific language" and then went on to say:
"A careful look at the specialization mechanisms for UML reveals their limitations. Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn't within range. You can't change the semantic constraints, or invent new sorts of diagram or new categories of element." This is incorrect: a stereotype allows you to define a set of associated constraints (in OCL, for example) that can capture the characteristics of your domain-specific context. While it is true that you cannot violate the semantics of the metaclass that you have stereotyped, this is actually an advantage of the stereotypeing mechanism. A stereotype is a type-compatible specialization of an existing UML concept. Consequently, you can reuse standard UML tools and expertise even though you are using a domain-specific language. Of course, if you want a language that is incompatible with UML, that is OK as well (specifically, you can define it using MOF), but you will be losing some of those benefits.
Read the entire article here.
|
|
|
Message #149271
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Context Dependent...
This is totally depenedent on the type of company developing the software. Some companies (such as the one I work for) benefit greatly from the "software factory" approach. We have one or two advanced senior developers perform all of the R&D and component development with the junior developers responsible for plugging everything into the standardized framework and making minor changes. It's very cost effective, as guru C# developers don't come cheap. Two or three novice developers are more than capable of piecing together a fully functional application out of pre-built components and cost about as much as a single top tier developer. When little or no actual coding is involved you can greatly reduce the window for potential errors.
This works great for consulting companies, and the end result is much prettier (and costs a whole lot less) than developing each and every solution from scratch. Why recreate the wheel if you don't have to?
|
|
|
Message #149277
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Grady Booch Fires Back at Software Factories
This is from my serverside.com post,
--<start>--
Software factories, name sounds little right. Its beyond patterns and UML. MDA is just in air, sounds like named by one person -- not team, its sounds like i have Nut and Bolt, what do you want to make. Companies like Ford, or BMW will laugh at it.
Ok What is software factories? -- It brings XML into picture to define Data and (domain) process. That is to say Data and Context.
Go Deep, bring on Patterns. Now we have -- Data, Context, Patterns, ie. to say i have cement, bricks, and i have blue print (ie i want kitchen, i want 3 bath, i want a big back yard) --- an idea to live better, so that i can grow somethings in my back yard without worrying about space, and Context is how much money i have.
This sounds realistic then --- most of companies flatly rejecting to build any UML diagram of their system, which earns revenue for them.
Cann't reject, need more time to see how it comes up.
--<end>--
Interestingly Booch points to Alan Will's blog....And more interestingly Alan uses Nuts and Bolts term...The one that i used, before reading Alan's blog, that indicates that i am with software factories, intellectually rather than emotionally.
Booch arguments are totally opposite - he says Software factories is emotionally driven.
|
|
|
Message #149280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Grady Booch Fires Back at Software Factories
Editor's Note: I am republishing Steve Cook's blog post with his permission
UML Semantics
Grady has blogged about Microsoft’s position on UML. His article is a masterpiece of technopolitical spin. He says Microsoft “rejects UML”, and of course we don’t; as my colleague Alan Cameron Wills says, “we don’t want to limit ourselves to UML as a basis for our users’ domain specific languages”. We support UML in our Visio product, and we use it extensively for documentation.
Grady also attributes several mistakes to Alan, who actually got his facts right. But getting facts right is never the important issue in technopolitics; and UML is primarily a political artifact, not a technical one. In this vein, I’m going to write about UML semantics.
What is “semantics”? Grady talks about it a lot. For example: “In many cases, the semantics of the UML are pretty close to what you need, although they are deeper than necessary; in such cases, a suitable UML profile is sufficient to focus the language, which allows you to leverage standard UML tools and training and yet eliminate the bloat.” There are some interesting words in there: “close”, “deep”, “focus”.
George Lakoff’s interesting book “Woman, Fire and Dangerous Things” distinguishes between “objectivist” semantics and “cognitive” semantics. Objectivist semantics involves defining precise mappings from symbols to abstract entities and sets, and thus giving meanings to symbols by virtue of the logical properties of the corresponding abstract entities and sets. Lakoff goes to some lengths to dismiss objectivist semantics as an appropriate theory about the mind and language. To give semantics to real experiences in real languages, he says, requires a different kind of cognitive semantics based ultimately in categories of bodily experience.
Providing semantics for computer programming languages has historically been a completely objectivist matter. Programming languages can be given semantics in various ways, operational, axiomatic and denotational methods being customary. What these methods have in common is that they ascribe exactly the same meaning to a particular set of symbols under all possible circumstances; where exactly the same can be objectively assessed according to basic laws of equality in set theory. Users of such languages really do expect different implementations of them to behave the same.
Now UML is different. Its semantics is given by prose headed Semantics, containing sentences such as “The representing collaboration may be used to provide a description of the behavior of the classifier at a different level of abstraction than is offered by the internal structure of the classifier.” It’s immediately obvious that an objectivist method is not being applied here, and that we have to appeal to a more cognitive understanding of the language used. The problem, of course, is that we can no longer make any objective assessment of what symbols mean. Users may not expect different implementations to behave the same; it simply is not set up like that. The best we can expect is for implementations to be similar.
The bottom line is that discussions of UML semantics become political, rather than objective. In consequence, discussions of UML compliance become political, rather than objective. Tool interoperability becomes a political, rather than an objective matter: two UML tools will interoperate if their vendors decide to make this work, rather than by virtue of any objective tests.
None of this would be a problem if UML were widely recognized for what it really is: an informally defined, popular set of conventions, which can be put to use in whatever ways are appropriate. The problem is that many of its proponents insist on pretending that it is in some way objectively defined; for example the OMG describes it as normative. Now interestingly, Grady does not seem to go this way – for example he says: “... there really is no "illegal" UML graphical syntax.” I was surprised to read that – but it’s good. I hope it stays that way.
|
|
|
Message #149293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
UML/Software Factories
I'll say it again, for me, the data is the application. Processes, classes, and code exist in the end only to manipulate the data. Far too often folks get caught up in abstract domain models and diagrams and end up creating nightmares for their fellow developers.
|
|
|
Message #149299
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Data is the application??
I couldn't disagree more... Well, maybe but not much more. Using the modern SOA paradigm, reuse is aimed not at data but at business logic. The underlying data, in whatever form it may take, is irrelevant. When you build an application that accesses an external web service, it's to add that service's functionality to your application. It's the Borg Manifesto, the service's uniqueness will be made part of a collective (application). Resistance is futile. :-)
Too many developers concentrate on using services as a means to access data and are missing the bigger picture. What good would it do to access Google's data without running their search algorithm on it? The data you receive as results in no way represents the data their algorithm uses.
Data only exists to store the state of some business process. For example, the concept of a customer address only has relevance when applied to some interaction with that customer via that address. If nothing your business ever does involves their physical address, would you still store it? No. You only store the data that your processes need, therefore the data is dependent on the process, not the other way around.
Modeling those processes, no matter which method you choose, SHOULD give us the data that we need to store. But as is often the case, developers start with the database and build from there (see my comments about The Code Room). But when you model the database first, you are designing the data to match a process model that exists only in your head, and I think that can be a mistake.
|
|
|
Message #149321
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Data is the application??
I knew I catch some for that, but let me explain. However, first, isn't your phrase => "Data only exists to store the state of some business process" the same as mine in that "processes only exist to manipulate data"? It's not the process we're after it's the data, the process is the means the data is the goal.
WebServices and SOA offer nothing new here, they're still just data - they just might not be lying around in some DBMS (or at least served up that way).
To me, the GEFN (Good Enough For Now) approach is far better, cheaper, and more realistic in that 5 years from now the applications we're creating will be on the trash heap of history or completely rewritten. I submit to you that the data will live on not the business objects, not the processes, not the UML diagrams, or even WebServices, they'll all come to pass. But the data, that will live on.
I know you'll probably disagree with me and that's okay. Show me a data model and I can tell you what edit screens (web pages) and listing screens you'll need and what the overall application looks like, then I can simply generate the business objects from that meta data (using our product MyGeneration). Think about it, this is exactly what we do with Visual Studio, we point to a WSDL file and generate business objects that talk to that webservice, we do the same with database meta data.
Programming languages will change, we just moved from ASP to ASPX, but many of us are using the same exact database tables and stored procedures that outlived the other technologies, and if I can point and generate both business objects and even UI code why bother planning on making my business objects live for 10 years? The simple truth is they won't, to much will change in the future to make it worth my effort.
While most are hashing out diagrams and abstract domain models that often aren't really that useful my approach will be have me nearing completion, and with a better code base I think. OF course, these are just my experiences, I have no concrete study to provide you.
|
|
|
Message #149322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Can Java take the next few years as well?
I'm just an architect/developer that wants to pick a language to my team that will be supported by any OO developer that is hired. So, with that I was very excited about how Microsoft has finally caught up with the rest of enterprise object oriented development with patterns and pratices for software development. I understood this as the first steps to bring Senior OO developers from other languages and to give .Net a try and see how it can support enterprise solutions, heck it got me doing C# daily.
Now that tools are finally ready to give MDA its day in the sun, Microsoft goes off and forces the architects to draw a line in the sand again. Either stick with UML and use tools that will fully support it, and believe in it. And probly develop Struct Frameworks utilizing BEPL and other OMG meta-models or go the way of Microsoft and the MSF "Software Factory" meta-model solution in 2005.
Last time microsoft did this (Visual Basic 1.0-6.0), they won the quick built, easy developed applications and let Java and Oracle take the major enterprise solutions piece of the pie. So for a guy just trying to pick the right tools and languages for the next wave of developers my gut tells me that nothing is new and enterprise solutions need to be done by UML and Java. That is unless the colleges are teaching their CS student MSF and not UML and IEEE starts to use it as well.
Darn it!!! I thought things were getting easier. Guess if I learn MSF, my bill rate would probly be pretty good :)
|
|
|
Message #149323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
UML/Software Factories
<<Providing semantics for computer programming languages has historically been a completely objectivist matter. Programming languages can be given semantics in various ways, operational, axiomatic and denotational methods being customary. What these methods have in common is that they ascribe exactly the same meaning to a particular set of symbols under all possible circumstances; where exactly the same can be objectively assessed according to basic laws of equality in set theory. Users of such languages really do expect different implementations of them to behave the same>>>
Paul to the laymen - and by laymen I mean the developer or end user - you could just as easily be speaking Swahili. There is a fundamental disconnect between what the theorists propose/devise and what works in practice. Perhaps the disconnect comes from the lexicon these types of languages try to impose on the development community. For example, I have a purchase order I want to print. The purchase order contains product details. To visually present this in terms that both the end user and developer understand could we not depict the following?
An image of purchase order is connected to image of printer with annotation indicating print. The purchase invoice is connected to an image of catalogue indicating the purchase order contains items from our company’s product catalogue. This sounds over simplistic and certainly doesn’t represent a more complex scenario but I believe it drives home my point. Verbs such as print indicate the action and nouns such as purchase order or catalogue represent the real world things. Is it absolutely necessary to cloud the issues with complex dialects?
In closing I will dangle the following question. Why hasn’t there been more uptake with model driven development.
Regards
Kevin Weir
|
|
|
Message #149326
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Further Comments in Response to Grady
The very author of UML Distilled, Martin Fowler, has doubts about UML as well (http://www.martinfowler.com/ieeeSoftware/mda-thomas.pdf). I guess Grady will have to attack him as well now.
Did you really read the article? It was not written by Martin Fowler but by Dave Thomas. He doesn't mention "doubts" about UML, but problems with tooling, read carefully section "UML: The good, the bad, and the ugly"
UML 2.0 lacks both a reference implementation and a human-readable semantic account to provide an operational semantics, so it’s difficult to interpret and correctly implement UML model transformation tools.
His conclusion:
Used in moderation and where appropriate, UML and MDA code generators are useful tools, although not the panaceas that some would have us believe.
And perhaps I misread Grady Booch entry, but I couldn't find any "attack". Las time I checked, to clarify things is not the same as attacking them.
Cheers
|
|
|
Message #149349
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A very practical answer to the debate
In the end, for every day life, I think that the tool used to design has very few importance. A good tool will not turn a not so rigorous developer into a rigorous one, and vice versa. You are able to design complex architectures and processes or you're not. The tool is here to help you being understood by others, so, in my opinion, the most important feature of the tool is to be standard and widely used, so that everybody understands what you have in mind. I definitely agree with the post by Ron Rodenberg, we're using the same approach (some core competent developers for the architecture and core components, and junior developers for the glue). If that's software factory, so be it, but it won't prevent me from using UML to show junior developers what the architecture is like. You see what I mean?
My 2 cents :)
|
|
|
Message #149381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Data is the application??
As predicted, I disagree. :-)"Data only exists to store the state of some business process" the same as mine in that "processes only exist to manipulate data"? It's not the process we're after it's the data, the process is the means the data is the goal. In a word, "no" this is not the same. Process is the goal, not for the developer perhaps but for the business. The company wants to notify customers of a new product, that is the process. The customer's address is the data that is used during that process. If we didn't want the process, we wouldn't need the data.
Your statement that web services and SOA are nothing new, is a sign of how many developers don't understand the purpose of SOA. If all we wanted was universal access to data, we have that. Put it in Oracle, put it in SQL Server, heck even Sybase. There are very few technologies that can't access data in any reasonable commercial database. What SOA is trying to leverage is how I as an enterprise use that data, the process. So for example, if my company specializes in healthcare and we offer web services that allow you to track drug usage throughout a chain of hospitals, what would a pharmaceutical company want to leverage to track their product, our data or our process? The data they already have, just by looking at receipts. What they want to use is our business process of aggregating the data from the hospital chains. It's a fine distinction, but an important one.
The data will live beyond the processes only because processes need to change more frequently than the data. How a company sends it's mail may change ten, even hundreds of times before ZIP codes become 10 digits instead of 5. But what is more likely is that the company will switch to sending correspondence via email, in which case the address data while still accurate is now irrelevant. Build to change, not to last. But with each new process inevitably comes new data. Most new systems built on old data structures perform miserably and don't take advantage of new technology.
The ability to generate an object model or some amount of code is strictly a developer productivity tool. Too many times those productivity tools cause us to misuse a technology, i.e. Datasets in web services. We shouldn't let the tools dictate how we build systems.
|
|
|
Message #149385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
UML/Software Factories
I'm answering this post mostly because you mentioned my name. I don't think my comments were geared towards MDA or Software Factories so much as against the data centric approach to SOA.
However, I would answer this by saying that the situation you describe is exactly what DSLs and the tools that Microsoft is building have in mind. Rather than represent a purchase order with an abstract class image, use an image that actually represents what a purchase order means to you with all of the functionality (aka verbs) that you determine a purchase order should have.
|
|
|
Message #149392
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Data is the application??
Hahahahhhhhh
Data and Process. Leg and Head. Paul took so much trouble to explain, i dont get it. Let me try Data is Leg, and Process is head, cut the leg, process still works, cut the head -- Guess what happens !!.
Tell microsoft or a bartender, he will tell you what's important.
|
|
|
Message #149395
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Incorrect Reference
You are correct, I incorrectly referenced that article... I reached it via Martin Fowler's site and didn't look carefully enough at the author.
However I do believe that the article does attack the ability of UML 2.0 to adequately deliver on the MDA objectives. And I have read on Martin Fowler's blog that he sees a lot of positives in the approach that Microsoft is taking with the DSL path.
The biggest problem I have with the MDA world is the breakdown between the model and the code. An example with Rational XDE is that you have to go through a "sync" process to keep your code and your model as accurate representations of the current system. What always happens is that the model and the code diverge and you end up with models that no longer adequately document the actual system. With a DSL approach you gain the "syncless" world where the code and model are only different representations of the same data. I think Microsoft is showing quite clearly that UML 2.0 may promise a wonderful world of MDA but the clear fact is that IBM and Grady Booch have not been able to deliver with UML as it currently stands.
Instead of one uber UML attempt to qualify the entire landscape DSL promises to deliver real value on a smaller scale so that we can actually get some benefit in the near future.
|
|
|
Message #149946
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GEFN
To me, the GEFN (Good Enough For Now) approach is far better, cheaper, and more realistic in that 5 years from now the applications we're creating will be on the trash heap of history or completely rewritten.
Maybe if we created more robust, extensible, maintainable applications such that they can readily accommodate changing business requirements, we wouldn't have to throw them away and start over all the time. When I read the above, it sounds as if these throwaways are an inevitability. I'm not convinced that it has to be that way.
|
|
|
Message #150266
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Software Factories vs. MDA
The debate about UML vs. DSLs is a red herring. Instead of asking whether or not we should use our existing hammer to hit every object in sight, whether or not it looks like a nail, we should be asking what it is that we want to accomplish. Only after that question has been answered is it appropriate to ask what languages, techniques, tools or other resources we should use. Why? Because we cannot evaluate any resource apart from understanding what we hope to gain by using it and how we will use it to realize that benefit.
To make this point more bluntly, technology decisions should be driven by requirements. While this should be patently obvious, the cart is frequently put in front of the horse in the debate about UML vs. DSLs. That debate should therefore be replaced by a debate about Software Factories vs. Model Driven Architecture, since they are the methodologies that define the contexts in which UML or DSLs will ultimately be used for model driven development.
One volley in that debate was fired by Grady, with his comments about Software Factories, which I will answer in a future blog posting. Another has been fired by Wim Bast in a Server Side news posting, which I will answer on that thread.
|
|
|
Message #154056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Data is the app (mv Data v. Process all over again)
This feels like a ride on the technology mobius strip.
Wasn't the object revolution an exploration of the distinction between behavior (process) and data? And how the two are both necessary? And how sometimes it's good to create tight linkages between them? But sometimes its not?
Values and algorithms, state and behavior, applications and data, (yin and yang?), the beat goes on... each necessary, each has its own set of issues.
I suspect that this disagreement is really about (or should be about) how tightly coupled the code/data should be, and what criteria to use to decide which.
I do fear that in practice the web services rhetoric is recreating the deathgrip that objects (tight couplings) had on software in the 90's, just as XML (looser couplings) created some breathing room.
[disclaimer: I like objects for some things]
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
