What are some useful ways to visualize concepts? What about visualizing how they compose?
1 Like
Welcome to the forum, Josh! There are three kinds of diagrams I draw for concepts. First, for an individual concept, I draw the localized data model of that concept. For example, for the Upvote concept, I may draw a data model like this showing that the concept stores relations between users and the items they’ve upvoted or downvoted:
Second, I draw synchronization diagrams to show how when concepts are composed, their actions can be linked together. For example, here’s a sync diagram that shows that when I composed Upvote with Karma, I linked the downvote action of Upvote with the auth action of Karma, to implement the restriction (which is present in HackerNews, eg) that a user can only downvote an item if their karma level is enough for them to be authorized to perform that action.
Third, I draw dependence diagrams to show how in the design of an app as a whole, the inclusion of one concept depends on another – not in the programming sense (since concepts are not coupled the way traditional functions and modules are) but in the sense that one concept is only there because another one is. For example, for an app in which comments are upvoted but not posts, I might draw:
to show that the Upvote concept depends on the Comment concept (because if you removed, there would be no need for Upvote), and Comment depends on Post:
My book has a chapter about sync and another chapter on dependences. Both have lots of examples. I find the sync diagrams most useful when you’re trying to figure out subtle details of how concepts fit together; the dependence diagrams give you the big picture. I don’t use data model diagrams in the book because they’re well known, and I wanted to minimize the amount of stuff readers have to know (so I just describe data models with simple textual declarations instead).
Have you considered the visualization associated with (Novak’s) concept mapping? https://cmap.ihmc.us/docs/theory-of-concept-maps
Interesting enough, a number of practitioners from the business analysis and business rules communities have been converging on this as a way of creating user-accessible models of a business domain and the software system to support it. Not sure if this is closely enough aligned with this notion of software concepts to be directly applicable or if there will have to be work done first to align the “concepts”.
In my understanding, a concept map is a kind of knowledge graph that was developed for use in education (as Novak explains in the article you cite). A knowledge graph is a collection of facts—what are called triples in RDF—each comprising a predicate and two arguments. As a visual representation, it’s an appealing way to present a theory (and the attraction in the educational context is presumably that it encourages the learner or teacher to piece facts together). In data modeling terms, a concept map or knowledge graph is thus an instance, and unlike a data model in which each node represents a set and each edge represents a relation, represents single objects and tuples belonging to the relations. What’s interesting is that these graphs are related: every tuple in the instance must correspond to a relation in the data model.
Whether this kind of thinking could help software concepts is an interesting question. My gut sense is that knowledge graphs and concept maps are too generic to shed much light on design: there just doesn’t seem to be any way to distinguish one possible concept map from another.
I do wonder, however, if such diagrams might be used to describe and relate the structures and behaviors of different concepts, for example showing how a RestaurantReservation concept might be a specialization of a more general ResourceReservation concept. I have a feeling that category theory could help here, but haven’t yet figured out how. Maybe someone else has some ideas?
Could you say more about software concepts vs concept mapping concepts? I get the sense that concept maps could be useful as a tool for figuring out the right concepts to apply, especially to an existing system, for communicating and documenting the resulting software, and for discovering new software concepts, whereas software concepts for are useful primarily designing and architecting systems out of well-understood components.
there just doesn’t seem to be any way to distinguish one possible concept map from another.
There is some literature around this:
- Table 2 of From representing to modelling knowledge: Proposing a two-step training for excellence in concept mapping presents some criteria.
- There is some earlier work, How good is my concept map? Am I a good Cmapper? and Is My Concept Map Large Enough? that engages with the topic but gives less actionable suggestions.
I wonder if it would be fair to say that CMaps are primarily useful for modeling the problem domain while software concepts are for modeling the solution domain 
.
I have a feeling that category theory could help here
There’s some programmer humor about regular expressions and problems that comes to my mind whenever someone tries a foray into category theory (not that this has stopped me). Maybe Ologs?