Florian W asks: Really exciting topic! Thank you. I wonder what are the differences and similarities of the paradigm of “concepts” and “aspect-oriented programming”? (or are there none?)
Thank you for your kind comments.
This could make an interesting research project! Concepts usually embody what AOP calls “cross cutting” behavior, and you can think of the concept composition mechanism as similar to the mechanisms (such as join points) that AOP uses. Perhaps one key difference is that in AOP you typically have a base system and then a collection of aspects; in a concept-oriented system it’s all concepts. So the concept approach is akin to designing a system as a collection of free-standing aspects that then get joined together. Also not sure if AOP emphasizes the opportunity to reuse aspects across systems?
Orlando M asks: How to make the notion of purpose available not only to users and designers, but to all stakeholders involved in a piece of software?
Not sure exactly what the question is here. Concept purposes can be helpful in identifying the motivations and needs of different stakeholders; in some cases, a concept may serve one kind of stakeholder well and not another. So different stakeholders should be given the opportunity to identify their own purposes.
Stephen S asks: What do think of Michael Jackson Problem frame in dealing with software problems? [Similar question from Ignacio T]
Problem frames were a major source of inspiration for concepts. My operational principle was inspired in part by how the “frame concern” is expressed as a scenario that circles around all the domains. Like concepts, problem frames help you clarify the essential structure of the problem without getting involved in implementation issues. One key respect in which problem frames are important is recognizing the way in which a machine interacts with its environment (peripherals, other users and operators, the physical world) and how the essential requirements are fulfilled in combination with the environment. This is an aspect of concept design which has not yet been properly developed, because I have concentrated primarily on apps rather than cyber physical systems, and in which I expect problem frames to be very helpful.
Amruth K asks: Wouldn’t exposing the concept model underlying software expose the IP of the software? How do we protect IP while making concept model obvious to the user?
I think that’s inevitable. If the user is to understand how to use the software, they’re going to have to have a conceptual model of it. In some cases, the concept may be a weak one that hides aspects of behavior that the developer wants to keep secret. In Facebook, eg, the Upvote concept is more complicated than I implied, because the ranking of posts in your timeline is not simply determined by upvotes, but rather by many opaque factors. This weakens the value of the concept, because it means the user has very little control over it, and little understanding of what to expect.
Alfredo C asks: Aren’t the practical lessons meant for people in charge of making specifications (i.e specifiers or analysts rather than designers?
The people who make the specs (that is, decide what the system or app is going to do, and what its functions should be) are designers. My view (which is inspired by Mitchell Kapor’s Software Design Manifesto) is that we need a new role of a software designer who shapes the product, bridging between technical design and understanding the user. In other fields, such roles are well established: the architect in the design of buildings, for example. In software, we have fragmented the role to our detriment.
Steven F asks: What approaches do you suggest for “user education” - particularly when ambiguity in design/implementation impacts safety critical issues - such as behavior of the 737 Max.
You won’t be surprised to hear that I think that user training should be structured around concepts. As I explain in my book, the concept dependency graph can suggest good orders to explain concepts in, and the model I present for concepts (purpose/OP/state/actions) can be used to structure the explanation of a single concept. I believe that the purpose and operational principle (OP) are especially important in explaining concepts, and are often missing. I give an example of this in my book for the concept of Section in Google Docs.
Bran S asks: Shouldn’t concepts and synchronizations be associated with a context?
Great question. They are already context dependent in two ways: first in that the same concepts will have different syncs in different apps, and second in that syncs of actions can be dependent on concept state. But there may well be an additional notion of context that could be useful, perhaps something similar to the notion of mode. I’d be interested to hear more about what you have in mind here.
Rishiyur N asks: Challenge: identify the concepts in Git.
Funny you should mention that: not sure if you know what my student Santiago and I did a case study applying concept design to Git, and built a veneer called Gitless that fixes some of Git’s concept design problems.
Jeremy S asks: How many concepts would a reasonably complex application contain? If you’re designing an application and find you have 100s of concepts, would that be a red-flag that the concepts you’ve identified are too fine-grained?
Great question. I’d expect an app to have a large number of small and fairly routine concepts, and there are some concepts that almost every app needs (such as the concepts of User, Session, Notification). The key question is how many core concepts you have: namely the ones that really characterize the app. If you have too many of those, your app might be unfocused or not well scoped (or it might be the kind of app, such as Microsoft Word, that has evolved over a long period and accrued a lot of diverse functions). I think your question hints at another issue though, which is how you actually identify the concepts at an appropriate level of granularity. My book offers some heuristics to help with that. For example, if a concept has multiple purpose, it should probably be multiple concepts; if a concept has no OP, or if composing it with other concepts requires a lot of sync based on state, then your concept boundaries are probably too small.
Boumediene B asks: How can Formal Concept Analysis be used in this context?
Perhaps FCA could be used as another ordering, maybe as a lattice, on concepts. But as I explained in my talk, I don’t think FCA offers a productive notion of concept for software design — at least for the kinds of concerns I’ve been trying to address.
Richard M asks: I imagine one way to develop mutual understanding of concepts is by prototyping with a group of prospective users. Was this not done for the examples given? If it was, what do you think went wrong?
Richard M asks: I imagine one way to develop mutual understanding of concepts is by prototyping with a group of prospective users. Was this not done for the examples given? If it was, what do you think went wrong?
Nandakumar R asks: Do you have any practical suggestions to identify concepts?
One way to do it is to sketch out the functionality you want to support and then ask yourself, by comparison to existing apps, which familiar concepts already provide some of that functionality. Another strategy is to imagine the functionality you want with all its actions, and describe it as a single concept, and then start to break it into smaller concepts as you discover parts of the functionality that can be factored out. For example, you might define a concept for a Group in a forum that has moderation and notification functions in it, and then discover that those are concepts in their own right. One way to notice that you have more than one concept is to ask yourself which functions might be omitted; when you see that some whole collection of actions or functions can be either omitted or included in its entirety, you’ve discovered a concept.
Steven E asks: Where does a concept reside in code?
Concepts could be implemented using traditional architectures but with greater modularization, where you group together in a module the datatypes and actions associated with a concept. More ambitious structures are possible too. My former student Santiago Perez De Rosso built a platform called Deja Vu in which each concept was a vertical slice of the web stack, with its own front end components, back end and data store.
Omar B asks: Great Talk. Do you recommend to use the material you described prior to learn (Java) programming ?
Thank you!
I don’t think that people need to learn concept design before they learn how to program. Often, it’s easier to learn more concrete things first. In the same way, we don’t teach abstract data types before we teach students how to write simple functions on lists. But I do think concepts could inform early programming education, by having students build concepts as self-contained pieces of functionality, without even having to be aware that they’re building concepts. For example, a concept like Upvote presents a nice (and very tractable challenge) for a beginning web programmer.
Dina G asks: If a company is working on a new product, won’t they have concepts that are NEW? How does your research help them?
Yes, a new product will probably have at least one new concept. Concept design helps first by saving you from reinvent the wheel on all the concepts that are not new, second by helping you convey the real value that your product brings by identifying the key new concepts, and third gives you a framework for inventing the new concepts and structuring them. My book gives examples of the “killer” concepts that defined an app and were often responsible for its success. What I’ve found in my teaching and consulting is that development teams aren’t always fully aware of which concepts are in fact their key assets, and with concept design they could focus on them more effectively.
Malak B asks: Many thanks for the interesting talk. My question is how concept design is different to domain modeling?
Thank you!
The book has a discussion of exactly this question. Unlike domain modeling, concept design helps you invent structures that don’t exist in the domain. In the Upvote concept, for example, there is nothing “out there” in the world that already exists to be modeled, and this is true of many of the most impactful concepts. But concepts can embody domain models, often because the domain already includes a concept that is being executed by a social protocol prior to being automated: a system that provides online reservations for restaurant tables is like this. A key difference between concept design and traditional domain modeling is that concepts give you modularity which domain models typically lack.
Valentine E asks: Could you comment a bit on your expression of concern over Empiricism in the book or did i misunderstand ?
I believe that an over enthusiasm for empiricism has damaged the fields of software engineering and software design. The analogy with science is misleading in my view; design is not a primarily empirical activity, but a creative one. On the other hand, as I explain in the book, empirical methods are an important part of the designer’s toolbox.
Ishtiaque H asks: I’m teaching a Software Engineering class, any specific paper that I can ask students to read to learn about this, instead of the books you mentioned?
There’s no single paper that explains the idea of concept design in its current form. Perhaps the intro chapter to the book (which is available on Amazon with“look inside”) is a good start. One paper that represents an earlier version of the idea of concept design, and has more of a research flavor, is the paper my student Santiago and I wrote about the Git conceptual analysis and redesign (https://groups.csail.mit.edu/sdg/pubs/2016/gitless-oopsla16.pdf).
Robert B asks: Shouldn’t concepts be specified by liveness and safety properties?
The operational principle can be viewed as an essential safety property. Liveness properties are problematic because they can be undermined by composition (since one concept can block the actions of another). The end notes of my book discuss this in some detail, and show how to express an operational principle in temporal logic.
