• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (11)

1 localhost commented Permalink

In partial defense of Microsoft, I think the work that they are doing with visual architecture tools, such as the "Whitehorse" technology in the Visual Studio 2005 code is very forward looking. Software systems design and methodologies are inherently addressing economic value derived from information systems. What Microsoft is doing with Domain Specific Languages serves two purposes: First, it addresses a broader spectrum of need than current generation UML tools, by starting a a conceptual architecture level, then moving down through a logical and physical deployment, based on reference architectures. It's the reference architectures which today have higher economic value to an enterprise. Second, DSL's create economic opportunities for ISV's to add value by providing standardized visual components which cannot be seperated from implementation details. This ecosystem drives has the potential to drive more choice and fit for purpose when integrating commercial of the shelf software with customized integration, which is exactly the way most enterprises operate today.Finally, Microsoft is not alone in realizing that development of software related systems is inherently an economic value judgement for most enterprises. Sun Microsystems certainly promotes a competitive view - see the recent book "Software by Numbers", which expresses this using incremental development using agile techniques.What the UML tools lack today are the abstraction capabilities. I've heard this described as "the police skecth artist" view of a system architecture. Ideally the tool would allow visual representation of a system to be described in abstractions, while at the same time driving the abstraction down through the logical and physical reference architecture layers, which themselves incorporate standard reference patterns.

2 localhost commented Permalink

As a user of UML, I feel that, just as with any other language or tool, UML has its range of applicability. UML is well suited for identifying and visualizing the structure and the collaborations of the components in a system. It is also an invaluable aid in the iterative process of discovering and refining requirements. On the other hand, a UML tool may not be the best suited for modeling UI components, or for creating business rules or even writing math formulae. I don't feel the need to defend the fact that UML does not do all these things well. It is always conceivable that, given enough specialization, a particular tool or mechanism will perform better than others in a given context.

Software is about patterns, and if something doesn't look like a pattern to you, just broaden the context. UML captures patterns. A good software development tool or language (let's not exclude DSLs), like UML, should aid in the discovery, refinement and validation of requirements ('cause if requirements were always complete, accurate, unambiguous and the same for everyone, then maybe we could use software factories). In addition, it should also capture patterns and, in my opinion, those patterns should be expressed as semantically validated models. It would then be possible to automatically transform those models into a particular target technology in a coherent way within the context of our architecture or platform of choice. Only at this point in the software development process can we talk about factory-like productivity gains. It would help of course if all your favorite development tools were to share a common meta-model, even more if they were to share the same technology. The Eclipse Modeling Framework (EMF) is coming very close to making this vision a reality, a reality where there is no exclusion of UML, or anything that may help you develop your application, even DSLs.

3 localhost commented Permalink

"XML is not really for human consumption, and ultimately, MDD is all about raising the level of abstraction for the developer"Looking at the above quote by Grady and points made by Bob Wilmes, the difference in opinion appears to boil down to "economic relativity".What I mean is that if you know UML and you are a developer, then using UML represents an economy of effort for the developer.If you are a Vertical Industry "Subject Matter Expert", or just an "average Joe" who has spent 10-20 years in a business, then UML is a foreign and confusing language. In this case, having a DSL is key to providing "economy of effort". If proven, patterned, well-architected code can be generated from the DSL -what practical value does UML then provide?

4 localhost commented Permalink

From my experience, using uml to document high level software architecture may not be always optimal. The business users who look at the component diagrams/package diagrams find it difficult to identify the logical flows. Using basic block diagrams with arrows for flows seems to be a better way to provide high level architecture to non technical business users. UML Profiles will further bloat UML. For instance, there are many profiles for modelling web applications. which profile to use is confusing.

5 localhost commented Permalink

Dear Blogger,I totally agree with Grady, but only if he talks about UML 2 (the new flavor of UML). UML version 2 is offering great more than before and especially a modular and semantically well defined core.I do not see any inconvenient of using UML 2.0 as a strong basis for building DSL. In my opinion, the main problem is that people continue to think that UML is just a digramming language (I call it the "Visio" view).You can design a UML profile to describe enterprise architecture with UML 2.0 and it is very easy and staighforward (if you have a clear idea of what you want!). You can also use pattern and transformation at the model and metamodel level. So you have all the feature needed for customizing UML in the way you want.Tools are now ready to support UML 2.0, so please before making yourself an idea, try UML 2.0, build your profile, create some patterns and see the result.So why so much noise around DSL? For building DSL, you will have to design your model and then use it (run time phase). Microsoft will offer a complete suite for building DSL (you can try the beta now!), and will also offer some pre-defined dialects for usage in its tools. I see Microsoft DSL vision more as a "configuration language" building set (see the Microsoft Dynamic System Intitative at http://www.microsoft.com/windowsserversystem/dsi/default.mspx).Finally, as you see, both camps propose the model driven based approach, but with a clear difference on the process and tools/language to use. You can adopt it using a strategic unified approach (UML language and may be MDA) or a tactical approach (proprietary DSL, proprietary DSL with UML documentation, DSL generated from UML).

6 localhost commented Permalink

Mr. Booch, one of your points is: 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.... 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). This argument contends that all apects of building systems is creative to the point that software factories cannot accomodate the level of variance between systems. This argument is fundamentally flawed, as evidenced by the prevalence of established design patterns. I would argue that companies building good software actually want to take creativity out of the development process when it comes to components for which mature design patterns exist. In other words, the building blocks should come from software factories and be assembled in a creative way to solve the problem at hand. Only the truly unique components should be hand-crafted.At MAKE Technologies we currently implement this methodology -- we call it Standards Based Automation (SBA) -- presenting DSL models graphically in UML where appropriate or using other visual representations. From the models we can then generate code that conforms to industry-standard design patterns.The key success behind DSLs is the ease with which people can create them evolve them and implement solutions based on DSL modeling. To my knowledge, successful heavyweight MDA extensions through MOF are non-existant. I can think of dozens of examples of successful DSL implementations. The problem here is that MOF is too complicated.

7 localhost commented Permalink

dgreen: “the key success behind DSLs is the ease with which people can create them evolve them and implement solutions based on DSL modeling. To my knowledge, successful heavyweight MDA extensions through MOF are non-existant. I can think of dozens of examples of successful DSL implementations. The problem here is that MOF is too complicated.”I share this opinion. Based on my experience MOF is inadequate for defining modeling languages. There are several reasons, explained in more detail at http://www.metacase.com/blogs/jpt/blogView?showComments=true&entry=3288440249, but briefly: MOF covers the aspects of language specification only partially; it lacks some elementary expressiveness and is definitely too complex. MOF is also a standard which implementations seems to end up with something else than the standard MOF (calling it then XMOF, EMOF, MOF-like etc). If MOF is sufficient as a metametamodel, why that happens? Any suggestion?

8 localhost commented Permalink

I think every yahoo in the world who likes to re-invent the wheel will be putting out their own designers.This now pisses me off as much as the MSF did when it claimed to be a process framework when it first came out.The only thing that has accomplished is making a huge mess, and then coming back full circle when they decided to give it some instances of structure, and they implement XP, UP, and RUP.The same crap that was around when they started their mess.I think it is their way of being able to pull UML into their owned domain, with out saying they are using it.The only part of it I like is the template engine, but this isn going to be worth the mess this makes.The only hope we have is if the experts in the field like Mr. Booch, Mr. Gamma, Mr. Martin, Mr. Ambler, Mr. Jacobson, Mr. Gomaa, Mr. Clements, Mrs. Northrop, Mr. Fowler, Mr. Evansetc. (You know who you are) step in and take the lead on this, to get this under control as quickly as possible, and guide us in the right direction on how to use this correctly.

9 localhost commented Permalink

Grady, I've admired your work since 1989, when I installed your early version of Rose and ran it on Windows 2. My version of OOAD with Apps is the original one with the brown cover. The pages are dog-eared from years of use and reference. I consider "Object Solutions: Managing the OOP Project" the only worthwhile book on software PM. Obviously you made a fortune selling to IBM. Congratulations, I envy you. Obviously your contributions to the software engineering process will probably never be surpassed. We all know that most of what you say here has to be said because it would just look ridiculous for you to sell your company for a gazillion one day, then the next day say "hey boys, looks like we're a step behind the times". So why people argue with your points knowing that they're probably not what you're thinking is beyond me. It's kind of like arguing with Hejlsberg's official position on VB. "It's syntactically equal to C#", he says. Of course he does. What he's actually thinking is "It's the ugliest language I've ever seen and every day I thank God there are minions to manage it at Microsoft so that I never have to write a Dim statement otherwise I'd throw up!"So rather than take you up on your points, which I'm betting are not really what you're thinking, I'll just lay down some "obvious" realities: 1. UML is great2. UML doesn't do everything3. UML is complicated and takes years to get acquainted with4. Domain experts and laymen are more comfortable with terms, diagrams and icons that map more directly to what they know that with terms, diagrams and icons that confuse them. 5. The ability of the architect to communicate directly and rapidly to the business person is critical to the success of the project6. It's rare that this communication can occur with the UML7. Currently at the outset of almost every major project a buy/vs. build-from-scratch decision is made. Obviously there's a big domain of "something-between-buy-and-build" that's going to evolve no matter how hard anyone rants and rails against it. 8. Just because it's not "build-from-scratch" doesn't mean it's not R&D. How people are making the leap from "Software Factories" to "the end of R&D" to "everyone knows software is R&D therefore software factories make no sense" is just plan weird. 9. Ten years from now, a good web site won't cost a hundred K, half a million, or a million, which is what it costs now, because there will be a lot less R&D involved that there is today. Something... nobody quite knows what yet... will create the efficiencies that drive this difference. Software Factories will no doubt play some significant part in it.10. Factories *is* an emotionally-laden, very familiar and highly connotative term. That's why Microsoft chose it.

10 localhost commented Permalink

Correction: Semantically, not syntactically

11 localhost commented Permalink

Although many business oriented software can be made or will be using a production metaphor in software factories. The tools and operating systems being on the market today make impossible to solve all the problems with tools.One little example: In Windows It's imposible to build all kind of UIs without doing some tricks in win32, and concepts from win32 are not enough to build UIs. It will be good in the future if UIs has some mix of freedom between macromedia flash and new UI concepts.

Add a Comment Add a Comment