Nicolai N asks: How likely do you think it is that these ideas are actually applied in the field? I agree that CAR Hoare’s CSP concepts are awesome, but they are poorly applied in commercial settings. The current approach to Agile development effectively works against proper conceptual design/architecture…
I’m more optimistic than that. You have a good point that people don’t readily adopt an idea even if would make their work easier. But we have seen many examples of ideas that were at one time considered quite radical becoming mainstream: network and hierarchical databases being replaced by relational databases, OOP replacing imperative programming, the adoption of data abstraction, strong typing (due to the success of Java) and more recently functional programming and even ownership types (in the context of languages like Rust). I also think that agile dev is actually very consistent with concept design. First, microservices are becoming near universal, even in agile circles. And second, agile development relies very heavily on being able to incrementalism your development, and concepts should help with that.
Steven F asks: Really enjoyed the talk and Q&A discussion (great work DJ & GF)! A question for later … do you have thoughts on resolving questions of completeness, ambiguity, and consistency of interactions (an extension of my colleague Dennis M’s question on conflict of purpose.
Thank you!
Concepts are, as I explain in the book, deterministic by design, and due to that and the fact that they have their own data models without any shared state, inconsistency and incompleteness should be less of a problem than in a traditional design. That said, these are big issues and concept design cannot be a panacea, so it remains to be seen how they will play out in the context of concepts.
Jeff A asks: Is there a “GOF” concept book in the works?
I’m trying to get a nascent catalog going in the concept design forum (https://forum.softwareconcepts.io), It would be great to have a book one day. Or maybe different books for different domains.
James P asks: You’ve discussed concepts to provide clarity for the user. But I often find designers have not designed an operation to minimize the workload for a user (e.g., visual to look for something on screen or moving the curser may times-- for example using Spell Check). How can you expand concept design to consider the task to be done and not just the UI.
Are you suggesting a kind of GOMS model (GOMS - Wikipedia) for concepts? That’s a really interesting idea! I wonder if concepts would give you a smaller and more tractable context within which to explore questions of this sort for a system…
Daniel, your talk was very interesting. It and the question about “fatal interactions” between concepts made me wonder about the relationship of concepts to features. Do concepts provide a way of getting a handle on problematic, even if not fatal, interactions between features, such as those that arose long ago in telephone networks? I seem to remember that John Guttag and I once upon a time talked to NTT about using Larch to specify and reason about features and interactions among them. Steve
I have always been disturbed that software patterns are a reduction far away from what it seems to me that Alexander and A Pattern Language was struggling to capture. I see essences in that, and ways artifacts are evocative for us. Some treatment of concepts there might be valuable in having pattern languages reflect and affirm some of this.
I also wonder about aspect-oriented approaches here, although I have never gotten my brain around that and it may be at the wrong level, if taken as a disciplined way to leak implementations.
Thank you Daniel for a Herculean effort to answer all the questions.
I think you missed mine (Peter L) .
Basically, is concept modeling equivalent to domain modeling ? In my industry (medical/clinical informatics), we often incorporate “Subject Matter Experts” to help us model the intricacies of a complex domain like clinical medicine and the different specialties within it. They would tease apart actions/processes from states/entities and map these things using data modeling (for states/entities) and process modeling (for actions/processes).
Is concept modeling another way to combine these into a more unified framework ? How would that be distinguishable from “Object Oriented” approaches (properties and methods with inheritance) ?
Hi Steve – Welcome to the forum, and so nice to hear from you!
I’ve thought a bit about concepts and their relationship to traditional feature interaction and discuss in the end notes of EOS (pp. 294-295) how concepts apply in this context. Also, in the purpose chapter, I discuss two different (conflicting) call forwarding features (p. 62), and use this example to show how concept purposes can resolve design problems, and how in this case, differing purposes suggest you should choose different concepts (and not both at once).
In general, concept composition prevents concepts from conflicting the way telephony features can, because I want to ensure that the behavior a user observes is always consistent with the system’s concepts (whereas, in feature interaction, the overall behavior can violate a feature’s spec). From a concept design point of view, then, a traditional telephone feature-based design would be seen as flawed. Perhaps one solution (which I’m exploring) would be to weaken the definition of each feature (with some non-determinism) so that it could be treated as a concept and composed using concept composition rather than the more ad hoc mechanisms features require.
I need to look at DFC, an architecture that addresses the feature interaction problem, which I should have cited in the book, and which may offer a solution that fits within concept design.
Hi orcmid – Welcome to the forum! I discuss the relationship of concepts to Alexander’s patterns in another response here, and connections to AOP here.
Hi Peter – Welcome to the forum! I think I skipped your question because it was similar to another one that I answered about domain driven design here. The key distinctions between domain modeling and concepts are:
Concepts give you modularity to break the data model into smaller, reusable pieces.
Concepts include not just data but also behavior.
Concepts often embody design features that don’t correspond to anything in the problem domain. Contrast, for example, the Reservation concept which, for a restaurant system, involves domain elements like guests and tables, and the Style concept in word processors, which involves elements like paragraphs and styles which were only brought into existence by the design of the software, and are entirely internal to it.
.