MDA vs. Software Factories


August 2006

Click ARCast: MDA vs. Software Factories to listen to this ARCast.

In this final episode of the modeling series, Jack Greenfield and Martin Danner go head to head, mano a mano, to eliminate any confusion and misunderstanding generated by the last ARCast, "Reality Check." These guys are great, tune in.

Ron Jacobs:   Welcome, friends, welcome to ARCast. I am your host, Ron Jacobs, where our theme is tune in, turn on, and keep up. That's right, keep up with all these changes in architecture and all the latest quiz, many new things that people are talking about, like software factories versus model-driven architecture. I have to tell you, I have been sitting on the sidelines on this debate, you know, because I think there is probably something useful in there somewhere.

But there have been a group of guys who have been kind of passing this stuff, debating, back and forth on the previous, on the very earliest ARCast episodes before I took over as the host, and so my intender, who is just a regular guy like you, wanted to get on up on and... get on the line, rather, with Jack Greenfield, so I said, Hey, let's do it. So, here we go. Martin, Jack, take it away.

Hi, this is Ron Jacobs, and welcome to ARCast .I am joined today on the line by Martin Danner and Jack Greenfield, who have been kind of talking back and forth on some of the previous ARCast in... in this sort of confessional style, you know, where one speaks for a while, then the other one gets on and speaks, but, you know, we are being more real-time today, so we have everybody on the line, so we can kind of respond and interact a little more. We are going to begin with Martin, who has some thoughts, once you get on with the questions. So, Martin, go ahead.

Martin Danner:   Thanks, Ron. Yeah, I would like to respond to some of the comments in the previous ARCast. I must tell you, I know Jack took exception to some of my comments and I can certainly appreciate his point of view, and I just want to say, I think that both Jack and I are actually on same side of this issue.

First of all, I would like to preface my comments by saying that Jack is the expert here in this situation; I mean, modeling and the tools that go with it are his life's work, and I am… I am not a computer scientist, I am not an expert on model-driven development; in fact, I am just that person in the trenches who has to take this technology and make use for things out of it—hopefully faster, better, and cheaper.

But I do have an engineering background, with 20 years of experience in the software-development field. Also, I have done quite a bit of research on this particular subject, lately: model-driven design, software factories, and what-have-you. I have read the software-factories book.

I have gone to the OMG Web site and looked there for model-driven architecture (MDA). I have watched and listened to new recent views, looked for blogs on the subject out there. Also, I have experimented with the… as many other tools I can get my hands on. So, I think I am in fairly good position to act as a reality checker in this situation.

Based on what I have seen so far, I think that… Oh, it's my opinion, my humble opinion, that software factories are for more complete solution to the deals of model and software development than MDA. Now, the reason I come to that conclusion is that software factories are for practical accommodation of automation through model-driven development, but they also utilize guidance to those aspects in software-development process where manual approach is more feasible. MDA, on the other hand, is strictly about model-driven development only.

It's a specific technique that focuses on all model transformations and it does not address any of the other aspects of software development, where model-driven development is not practical. So, here's the thing that confuses me about the debate between the software factories and MDA. In my mind, it's not an either-or situation. Software factories and MDA are, as far as I can tell, are not mutually exclusive; for instance, they both have the same goals: to increase productivity and quality by producing software that consists of location centre.

So, here's the way I see it, Jack, I want you to calibrate me here, you know, even if I have got it wrong, do put me in the right direction. I see that you could consider software factories as including model-driven development, and that model-driven development is a… Model-driven architecture (MDA) is one approach to model-driven development. So, my question actually is, Is it not possible to create a software factory that utilizes MDA as its modeling component?

Jack Greenfield:   Oh, Martin, you are asking me some really great questions, and there is a lot to say about this. I guess I would have to say that I do disagree. I think they are mutually exclusive and, therefore, the answer is, "No." It's, well… I would say it's not possible to create a factory that uses MDA as its model-driven development component, but what I would say is it's not desirable, and there's really two aspects to this.

The first is that a lot of the power of factory comes from being able to create a set of viewpoints that is tailor-made for the problem domain in question, whereas with MDA, we have exactly two viewpoints: PIM and PSM (or, if you include the computational… computational-independent model, we have three, but people are not really doing much with the SIM, at this point). So, you know, you can immediately, if you want to sort of conform to MDA, throw away a lot of power of the factory, down to one big platform-independent model and, ostensibly, a platform-specific model for every target; then, I have to say it, you know, from my experience, that just sort of stretches the ground rules of disbelief. I still have, you know, very vivid memories of case in which we worked with these very abstract models that we just totally removed from the reality of what you wanted to accomplish and, you know, to meet us what the PIM really represents so general.

You know, we are dealing with a general-purpose modeling language, to begin with, designed by a committee that can't possibly know the specific problem… problem domain I am working with. It came up with a set of very general notations which are quite useful, but frankly they could be describing anything and nothing at the same time. To really describe a specific problem domain in detail, I really need to be able to look at it in more than one perspective… from more than one perspective and more than a PIM, and I need number of different models, and I need for each of the models to be expressed in a language that's more appropriate to the specific aspect of the problem domain that I am focusing on in a particular instance.

Ron Jacobs:   So, I am trying to parse what you are saying, and it seems to me that a good example of this is like in VS 2005, where I can have the data-center diagram, which is sort of like a viewpoint form IT architect's point of view, and then I have an application diagram, which is sort of from the solution architect's point of view, and that you have to be reconciled. Is that the kind of viewpoint thing you are talking about?

Jack Greenfield:   Yes, that's exactly it, Ron, and in the real world that I am trying to tackle any, a… you know, any real-world piece of enterprise software, there's going to be tens—potentially hundreds—of viewpoints that really matter, depending upon the size of the project, but it is hard to imagine anything of significance that does not include at least tens of viewpoints. For example, if we start with the logical data-center diagram and application diagram as a starting points, which will witness change as a lot of other places to start (for example, business process)… But let's just take those two, for starters. Well, what does a given application consist of, right? The AD does not say anything about that. I wanted to sort of one of those application and look inside, but what I see… what I am seeing is something has UI and business logic, and that accesses the database. I have got at least three viewpoints there, and each of those viewpoints are probably going to decompose in a smaller parts; for example, in working with the UI, I probably want to think about UI look and feel independently from the way I think UI process, in other words, interaction between the user and the system, which is really look-and-feel-independent. And if I am thinking about business logic, you know, there are workflow aspects to it, there are business-logic components. There will probably be used by the workflow, there are business rules that probably want to be called out to.

You know, this sort of three viewpoints within just the business-logic layer viewpoint, if you like, right there, so I guess we are up to—what?—AD, LDD, UI, business logic, data access… decompose UI into two and more, decompose business logic into three or more… up to ten, and I have not even started taking apart the data-access layer.

That's for a very simplistic three-tier component. Now, if we want to start getting into more detail about how the service-oriented components are actually laid out, we are going to see more viewpoints pop up still, and at this point we are just dealing with the implementation, we have not even started talking about the business requirements and the viewpoints that I might see when I start thinking about the business events, business roles, business information, and the business process that ties all these pieces together.

So, I mean, I just rattled off a few, but in the real world, dealing with something like e-commerce app, for example, I am going to have a lot of viewpoints specific to that domain. Viewpoint dealing with the various aspects of the requirements such as customer management, order management, catalog management, sales and marketing campaigns, administration… There is just a lot more complexity in real world than PIM and PSM.

Ron Jacobs:   OK, Martin, what [do] you think, does that make sense?

Martin Danner:   Sure, I can fully understand what you are saying, and I agree [with] what you are saying. I do need some clarification, though, I should point out that I am not an MDA practitioner, but I know what MDA is on an OMG Web site, and in fact I was hoping one of our other analysts can hop in and elaborate on this technology, but most of my comments would be based on what I found directly OMG Web site called "MDA Guide Version 1.0.1."

It was the closest thing I could find to a specification on MDA, but it really is actually more of a guideline in itself, in the sense that it did not appear to actually prescribe. It was more of descriptive sort of thing. It's interesting to note that within that document, they do have viewpoints that utilizes many of the same terminology that Jack uses in the software factories things, like abstraction concepts, that sort of thing.

Jack Greenfield:   Let me just say, you are absolutely right. We didn't invent the notion of the viewpoints, it's being parking around the modeling communities for quite sometime. It shows up in RMODP, for example, it shows up in IEEE 1471, perhaps most significantly because software-factories schema is really an architectural-description standard that has been extended to cover the entire life cycle. IEEE 1471 uses graphs of viewpoints to describe the way in which an architecture should be laid out, and that's why it's called the architecture-description standard, so we didn't invent that, and the OMG's definition of the viewpoint is very similar to one… to one in IEEE 1471.

And I should add, however, that unlike the viewpoints in 1471 and in MDA and RMODP, for that matter, the viewpoints that we use in a factory are richer; specifically, they don't have to be model-based, you may be aware… earlier, which I wholeheartedly agree with, which is that factories are about more than just models, because we just don't believe to solve real-life problem using nothing but that particular kind of technology, it's really a combination of technologies that have to be brought to there, so our viewpoints don't actually have to be model-based. And, in addition to describing the artifacts that you are developing, our viewpoints also capture something of the development process… describe the assets that are used to help someone enact that process. So, at the end of the day, it is a combination of three things: It is the activities, workflow that I want to perform; the artifacts or the product I am gonna build; and the asset or tools and templates, class libraries, and so on, that I am going to use to do that. And I think that takes the definition of viewpoints just that a little further than you will find in RMODP, MDA, or IEEE 1471.

Martin Danner:   Oh, I totally agree, and that's why I say that the software factories are a more complete solution for the software-development process. But perhaps you can help clarify the MDA, and for instance you mentioned higher-level abstractions like business-process modeling, that sort of things, and I wonder if that might be contain within the notion of the competition-independent model for the SIM. Also, the… Another question is the idea is a PIM one viewpoint or we may have different PIMs with different viewpoints. I understand you can have viewpoints that don't fit into a raw, but is it not possible that you have more than one type of PIM?

Jack Greenfield:   Well, the MDA doesn't allow that. The MDA insists there are three viewpoints—SIM, PIM, and PSM—so I take them at their word, so they would like to describe more than three aspects of things, perhaps, but they don't say so, and I think it is very important that if you are going to have more than one viewpoint, you will think a little bit through what that means. What does it mean to have multiple viewpoints, the viewpoints nest, how do viewpoints relate to one another, what kind of operations can be performed across the relationship between viewpoints…?

Ron Jacobs:   You know, Jack, I think your dog agrees with you. (Dog barking in the background)

Jack Greenfield:   No, no, that is not my dog.

Ron Jacobs:   That is, a... Martin's dog. No problem, go ahead. So, we are not at the office, it's an evening podcast, yes. Hence, the relaxed real feel of this recording, with the barking dog.

Jack Greenfield:   Well, just to sort of stitch this together, and I guess, you know, to answer Martin's question: I don't believe that MDA does describe a methodology for partitioning a problem in terms of more than those three viewpoints, which they called out. In fact, I would go even further, I think I might [have] said this in my previous podcast, but while they do use the term "viewpoints" to define SIM, PIM, and PSM, they don't do much with the notion of the viewpoint. From there, it sort of degenerates to talking about the models, and the rest of the discussion is about the models and model transformation, you know… I think they thrown away the notion of the viewpoints and the relationship between the viewpoints, because of the tremendous amount, such as the ability to support other kinds of operation across the relationship between the viewpoints besides the transformation, like validation, analysis, retracer navigation, refactoring, optimization, to name a few.

Ron Jacobs:   So, you know, Jack, I think one thing that kind of strikes me, anyways, is that a lot of people throw around the term like "model-driven architecture" in sort of a generic sense. I wonder, Do something with model turns into architecture code or something like that, or maybe they do the same thing with the term "software factories" in a generic sense that, you know... be nice to build factories to generate software. But when they talk to guys like you, those terms have very, very specific meanings, almost like, you know, they have little trademark symbol after them.

Jack Greenfield:   In fact, Ron, they do, and that is the crux of the issue for me, I guess for us in Microsoft. MDA is a brand, it's not a standard. It's the brand that advocates the use of certain standards, and the brand itself belongs to the organization called Object Management Group and is leveraged by some of its members, like IBM. So, you know, to use the term "MDA" generic way they talked about the model-driven development is essentially using that brand, and that is the significant thing, it is basically a way directing people to look the OMG's way of thinking about the model-driven development and, frankly, I guess we have some issues with that.

Ron Jacobs:   I see. Well, of course, that makes sense when, you know... understanding from that point of view. I remember, you know, just throwing out the term once and people kind of reacting, "No, no, you can't say that," but I guess I was thinking of it more in the generic sense. But you have educated me on their viewpoint, and I think, you know, my experiences with whole UML thing, to be honest with you, was very constricting and found that, over time, I just felt that it did not adapt well the way that absolute changing over time.

Jack Greenfield:   Well, you know, that's true. UML was an excellent effort, and it holds together the best and brightest to come up with set of abstractions, really, and notations for sort of rendering those abstractions and manipulating them in a tool. And, you know, frankly, we like that work. We leverage the DSL template distributed with the DSL tools and make heavy use of the UML notation styles, or at least the subset of the UML notation style that are widely recognized and widely used, such as class diagram, activity graphs, use case… We would like to get sequence charts out the doors yet, but we find it very useful, and this really brings me to the second part of the instructor to Martin's original question.

Why could not you just use MDA as model-driven development portion of the factory. Specifically, there are two parts. The first, we talked already. The second part is that MDA requires the use of UML, and when you start talking about the standards, there is this nasty notion of compliance, and it's fine to say, Hey, I got something that's useful, why not you use too sure if it is makes sense than use it, otherwise not. When you start dealing with standards and start rolling out the "C" word for compliance, things get ugly. And that's where the gloves come off and you start saying, Look this tool is not compliant, we are going to deny you with a logo or whatever, it might be right. And you get people saying, If you want to submit something to our RFP, it has to be UML-compliant.

So, what does compliance really mean? Well, when you look at the spec, the UML spec, it defines compliances, and those definitions are enough to make a tool vendor a… pretty uncomfortable, because at the end of the day tool vendors need to be able to build tools that the user needs, and satisfy the demands of the marketplace that has to be no.1 authority to which the tool vendor answers. And when a standard requires a tool vendor to do something that is at odds with that, you know that tool vendors are going to get caught between the rock and hard place where they are either going to satisfy the customer or be compliant with the standard. And if the standards were something that was distilled from what customers want and demonstrate they want by voting with their dollars, then it won't be such a difficult proposition. But the fact of the matter, it is not how UML was developed, and the OMG used to have the policy which they adhered to before the days. Then, anything that was going to be standardized had to be in actual product, and that kind of got loosened, and that requirement got relaxed a little bit; then, over the time, it melted away altogether. I think that still on paper, but there is no requirement now that has any teeth to it. That the standards sort of embody what actual products do, and so what that means is if you have a committee for a guys who are in the abstract coming up with the solutions to problems that haven't really been written down anywhere, and there is nothing to validate those solutions nor even the problem statements that they are designed to address in theory. Now, working it fine to set of requirements UML addresses. And how can you prove UML satisfies those requirements? You can't. And there was lots of detail behind this we cover on some of the papers, some other conference work, and I won't sort of drag everybody in the gory details, but suffice it to say, try to build the tool according to the UML spec, you will find awful lot of issues with UML spec, and I am talking major issue, severe issues.

When I was at Rational as chief architect, I kind of encountered these in person, it kind of leaves you with a choice, and it may be the case that some people prefer the compliance mark on their tool, something they are going to use in the marketplace trying to get some leverage; but, in our case, we didn't find to be as powerful as satisfying the needs of the customers.

Ron Jacobs:   So, Martin, I am curious; you know, being the guy out there in the trenches. What's the feeling from the customers you have about the UML, are they using it, or are they liking it?

Martin Danner:   Well, I guess I have to refer back to some other comments that add value in UML and, you know, there is three ways you can use it: You can use it as way of specifying the application, as that's not to the practical for the reason Jack has stated, just does not have the fidelity to fully describe the applications; you can use it as a blueprint and transform to MDA style, but clearly that has its issues, as well; and by far the most people using UML as a sketch tool, as for documentation too, to capture ideas and concepts and then manually transform those to implementation of one sort or another.

Ron Jacobs:   Yeah, I have to say that being the way I primarily used it, like when I was on the Indigo team at Microsoft. I wrote a lot of specifications that, we used UML elements often, like especially sequence diagram, I used those all quite often and specifications, because they were a very convenient graphical way that everybody understood to describe the flow of a process, so to speak, and the... Beyond that, my UML always ended up in Word document; only, that was as far as it went.

Martin Danner:   Right, once the application is built, who bothers to keep it up to date, right?

Ron Jacobs:   Yeah, well, in fact, it probably did not take even very long for the UML diagram... The UML diagram and my Word document don't reflect reality, so, yaw, that's true.

Jack Greenfield:   I think you guys are really hitting the nail on the head, and at the end of the day the reason we… we would prefer to use DSL is because, unlike the model that's designed for the documentation, a model built with the DSL, if it's DSL that's being fit to purpose is really a source artifact like a piece of code. And so, instead of being sort of something else outside the development cycle, it's within the development cycle… must be maintained, because you are using it to generate something or to validate something or to, you know, to fit in the process of something, so that… so that perhaps to me single and most significant reason to use the DSL, as opposed to a language that was, in fact, designed for documentation.

Martin Danner:   You know, I would like to elaborate on some comments you made regarding UML in a previous podcast. I referred to UML as a domain-specific language for object-oriented programming, and Jack carried with the idea that the UML is a general-purpose modeling language, and I would like to say that we both are right. And the reason I say that is because, you know, when we are talking about the model-driven development, we are talking about the abstraction and the idea that the… we can describe the systems at various levels of abstraction, and if you are taking a very high level of abstraction—say, a business-process model down to UML—in that instance, I believe that we are talking about a domain-specific model, because there we are using UML as a solution to describe a computerized system. You can take a business process and render as a manual process, for instance, that involves different procedures, OK, but if you take it from a lower level of abstraction—say, from the code—and then look up to UML modeling from, say, a code perspective, there you are going to from specific to more general and, so, in that situation, Jack's comments must be true. Jack, any comments on that now?

Jack Greenfield:   Yeah, that's well said, Martin, so I could see how one can make the assertion that UML is a DSL for OO, object-oriented programming, which is slightly different beast than OMD, but I guess I have a few issues with that, because, I tried to… using that for that purpose and when you tried to map UML onto an actual object-oriented programming language, what you find… It does a fairly poor job. In particular, the UML was originally designed to reflect a number of the features of the C++ and, over the years, it's undergone some adaptation, but just for the instances, up to UML 14, the notion of the interface in UML didn't allow any notion of the state like a property or a field, right, and that's the problem if you trying to describe, say, Java or C++—excuse me, C#—where you can have in the interface to a class some public fields.

And so, you know, while in theory it's nice to say, I use UML to describe the interfaces that I want to expose and generate the Java or C# interfaces, in practice, that was very hard to do until an update was made. I half-suspect it was in response to some .criticism, to add that, but at the end of the day what you really end up with is the… two different languages: the object-oriented programming language that you are working with and UML, which is an approximation of it. The UML cannot possibly describe all object-oriented programming languages with high fidelity. It's just not capable of doing that, no, no languages… If there is important features in the language like, say, properties in C# which are very important, you either have to add that to UML and then say, Well, sorry, it doesn't describe Java or we don't add it to the UML, and we say, Sorry, you can't use that feature of C#. And I ran into issues with this firsthand when I was the spec lead for UML profile for EJB. The first thing we had do, before start modeling enterprise Java, was the model of Java languages. When I was… discovered that what I was really doing was rewriting the Java-language spec in UML and trying to come up with the mapping between UML constructs defined by the UML spec and Java-languages construct defined by the Java-language spec. And it was not an easy task, because the fit was actually quite poor. Go beyond the Java right up to C#. Sorry, go ahead.

Martin Danner:   It might do well to define what UML profile is.

Jack Greenfield:   Yeah, it might. I don't know whether they really help with this issue, but go ahead.

Martin Danner:   Oh, I was gonna point out that the UML profiles are a way of extending UML to try and address some of the shortcomings, and tailored to more specialized domains.

Jack Greenfield:   So, we tried at Rational, we tried building a profile of UML 14 for C#, and you ran into a lot of issues. I guess I have to admit one of my issues with UML profile is purely aesthetic. Profiles are really konky, so I look at to manipulate, and at the end of the day they don't provide a good user experience. And while that might seem like a, you know, a problem that doesn't deserve to be listed among the technical issues, it's actually a very significant problem, because you are trying to get 7 million VB developers who don't know anything about modeling, don't care about modeling, to use modeling tools; and you put something like stereotypes and tags in front of them, you will get tissue rejection, and that's been our experience. But there is also some technical issues, as well, which is to say that a profile uses stereotypes and tags to approximate what you would do. If you could extend the UML metamodel modified… In other words, if I have to have a new kind of class, I can make a stereotype maybe I called that… something like… I don't know… maybe I called that "entity," and I put this entity stereotype on the UML class box. Now, the problem with doing that is what I already done is label in a diagram. The tool itself doesn't have the notion of the entity built into it. There is no behavior for entity; there is no custom code generation for entity. Entity is merely a label that sits on a class.

The tool itself is dumb about it. It says, Look at the class with a label on it; and I don't have the idea, you know, what to do with. It merely carries the label along and, at the end of the day, the user is experiencing and trying to connect things to the entity and manipulating entity is really experience of classes that have labels on it.

Martin Danner:   That's right, and what's more, you can't describe the relationship between entity and other type of stereotypes which control those relationships.

Jack Greenfield:   Exactly, because they are not first-class metaclasses, and this is why within the OMG itself there is a whole a sort of category folks who would rather not use your profiles; rather, they go directly to MOF and build domain-specific languages that do have the kind of fidelity that you need to model abstraction you pointed out very succinctly a little while back. And those folks are, sort of, internally in the OMG at odds with the UML folks who want to do everything by extending UML. And, frankly, I think the OMG has a sort of a, you know, a problem

Ron Jacobs:   Well, you know what, guys, this has been really fascinating, the kind of get-behind-the-scenes of what this all has evolved from. And, you know, we are out of time. So, I want to thank you guys for joining me tonight and the, giving me some insight on the background of all this.

Martin Danner:   Yeah, thanks, Ron.

Jack Greenfield:   Yeah, thanks, Ron.

Ron Jacobs:   Jack Greenfield and Martin Danner, ladies and gentlemen. Modeling, tools, software factories; love it, love it, great stuff. You know what, we have more great stuff coming up on ARCast, as we are going to now shift our focus a little bit this week, as we are recording with some folks. We are thinking about the management at Microsoft. No, no, not executives, not budgets. IT management and how you manage systems and this thing we have called the "dynamic systems initiative," so you can look forward to some podcast about that in a week or two when I get them all edited and posted up. But some great, great stuff coming, and keep sending those mails, because I love to hear from my listeners to Tell me what you think, because it is really pumping me up, because it is working on ARCast.