Dear Vojtech,

I think your paper is quite relevant to an every growing awareness about software complexity, and the desire to try and understand what drives software complexity and how to make software easier to design especially in large organization. We still have plenty of examples of individual developers creating great pieces of software, but unfortunately it is not obvious how to take the process than an individual might follow in development (in the individuals mind) and scale it up to large teams. From my own perspective, I’m looking for ways to define the software development process in such a way that it can be better integrated into an overall systems engineering plan for relatively large military systems.

I do disagree with your assessment that UML was designed by engineers. Computer science and software engineering despite the respective labels have traditionally not been part of any school of engineering (this however changing). CS, for example, is apparently joined at the hip to mathematics departments. I think the issue has more do to with standards “design by committee”. I have just started to read the paper, but I can see it is quite relevant to trying to understand why software design is so complex. As you point out, a big part of the reason is that it is made more complex than necessary. As you have identified the UML has duplication in the various diagrams, and is a “weakly ordered”. I think this is part of the problem, but the solution is quite simple and it doesn’t require a change to the UML. Nobody has a gun to the head of the lead designer saying they have to use everything In UML anymore than you have to use everything in the latest bleeding edge release of C++.

We see a consistent pattern in designed by committee software standards; the two most obvious are C++ and UML. Both suffer from a bloated set of terms and features that extend far beyond what a typical applications might require. Compare this to the usability of Linux or Python which were largely designed by a single individual with a certain specialization in mind. The popularity of these derivative works far exceed the tools that generated them. The point is that UML and C++ are the basic tool that should be used to generate more domain-specific design meta patterns. There is no reason to throw the baby out with the bath water because these standards are too general for our specific application.

I realize that patterns do already exist, and those same patterns are part of the same problem. The classic Gamma, Helm, Johnson, Vlissides represent the standard set of patterns that all software engineers worth their salt need to know, but these patterns are taken as fundamental building blocks of a system instead of meta-patterns . I see repeated software architectural definitions where the abstract design patterns are the architecture and instead of the architectures centered around application specific ontologies. In my own work, I have concluded that at an enterprise level, reusable product domain specific frameworks (PDSF) are the optimal and objective structures that an organization should seek to create, refine for the common utilization of same. It is best to have and use reusable patterns in a PDSF rather than the more general class GHJV patterns. This helps to focus the meta-models on the specific program domain and allows a domain specific ontology to be used instead of product specific architectures being defined in terms of open standards ontologies.

The PDSF is also layered, using OO type inheritance do it is inherently reusable and extensible. I find the abstract factory pattern one of the most fundamental patterns in this layered approach, but I would not use that terminology in an architectural diagram. It is equivalent to saying my architecture is based on inputs-processing-outputs; whose is not? So there is no information conveyed. The architecture should define hat interfaces are being abstracted.

The PDSF will have to be constructed resolving multiple inheritance of more open standards. For example an enterprise, might have a common set of tools and languages specific to its enterprise that in reuses on related program

(e.g. UML and C++ for specific embedded environments). If we represent this as a UML diagram were have a situation of multiple inheritance that must be reconciled if reusable patterns are to instantiated.

In summary, the basic notion of a Domain Specific Framework (DSF) or for an enterprise a Product Domain Specific Framework(PDSF) are ways of blocking the full complement of an open standards from bleeding into your enterprise design patterns. Restricting the program specific design to reusable patterns in a PDSF are the best ways of fighting the more general problem of too much generalizations and bloated standards. If as you say there is strong opposition to UML in the Agile communities, then I would claim that there is not enough adherence to the fundamental agile credo to focus on reuse. It would appear that the interpretations of the agile manifesto is “to just write the code”, and there is a tacit assumption that architecture and standards of reuse are to be given short shrift. This practice is clearly not part of the agile manifesto.

Regards

Jim

Hi,

just a quick feedback from my side: Quick-reading the PDF, I don't yet understand your statements about asymmetry and redundancy of UML concepts completely, but there are interesting thoughts. We should keep in mind that UML wasn't designed to guarantee consistency and redundancy-free artifacts. I agree with Jim that a customization is necessary to make UML a project-specific language. I have done this via profiles and OCL constraints so that the model "behave" as desired. It would be interesting to get some more information about your ideas.

Best reagrds

Roland