5
$\begingroup$

I'm gathering my wits to create a course that will focus a great deal on OO programming patterns (things like singleton, flyweight, command, etc, etc.) I do not have a lot of background in this topic yet. I am currently learning the material as I develop the course for next September.

It seems like having a way to graph out the patterns is necessary to such an endeavor, but UML also seems a bit nuts -- there are entire textbooks on the specifications. Now, I understand that most of the UML diagram types would not be useful for a course in OO design patterns, but a few of them would be quite helpful.

So my question, then, is how deeply into UML should I go? Should I cover class and object diagrams? Sequence diagrams? Should I cover them in depth, or only in a shallow way? Or is there a completely different method that I should be looking for in order to notate design patterns for my students?

Improve this question
$\endgroup$
11
  • 1
    $\begingroup$ I suppose you're trying to teach how to conceive programs by a object approach. It's handy to have some drawings to explain how things are made / connected / are talking to each other. UML helps for communication, as a standardized notation, but don't turn your course into Technical Drawing 101. $\endgroup$
    – Michel Billaud
    Commented Mar 20, 2021 at 16:40
  • $\begingroup$ The Design Patterns book uses what it calls OMT (Object Modelling Technique), which seems to be a precurser to UML. So at least Intro to UML seems required if you use that book. $\endgroup$
    – Owen Reynolds
    Commented Mar 21, 2021 at 4:35
  • $\begingroup$ Related reading: ronnieschaniel.medium.com/… $\endgroup$
    – ThisClark
    Commented Mar 21, 2021 at 15:27
  • 1
    $\begingroup$ This question and the answer below brings back some memory more than 20 years ago! When I first learned UML, OOA and read grady booch's books. I was amazed at first. My then employer also required us to use cleacase and other Rational tools. Then something just didn't add up. I remembered saw some quote said something along the line like, if UML, grady booch was supposed to teach us OO, why clearcase and all Rational tools were such terrible software! The memory and quote was so vivid that I still remember it now. $\endgroup$
    – Qiulang 邱朗
    Commented Mar 26, 2021 at 7:08
  • 1
    $\begingroup$ @Quilang : Thanks for the clear-case blog-link. It helps me in something I'm just writing on the edu-costs of bad tooling. Ben I. : You have seen Larman : Applying uml and patterns ?? $\endgroup$
    – Rushi
    Commented Apr 1, 2021 at 5:14

5 Answers 5

Reset to default
10
$\begingroup$

As a professional software developer, I would recommend minimizing the time spent teaching UML. Teach the patterns. If they learn some UML along the way, so much the better. But don't burden them.

In my experience, I've found value in using UML for somewhere around 3-5% of my work. It usually provides its value after the fact, once I've already identified the design patterns, and I need to describe them to others quickly. Often they don't actually need to understand, they just need enough of a warm-fuzzy to check off on my work. UML is great for this!

All too often I find that I need something that isn't handled in UML (like handling dependent types), or something that can easily be explained in one sentence rather than a dozen fancy boxes (like object lifespan management). I can't think of a time where I've ever looked at a UML diagram and thought, "wait... if I use the Decorator pattern here, I can make this diagram look better." It never helped me for actual understanding of the patterns. And I can't count the number of times where neither aggregation nor composition adequately described my relationships, leading me to fall back on just drawing a line between them and calling it a day!

That being said, use a tool for what it is good for. In the cases where UML does a good job of describing the pattern, use it! I love UML for drawing basic inheritance hierarchies. But I don't think it needs to be taught. It's simply the way you choose to draw the patterns so that you can point to boxes and talk to them. If a sequence diagram is the right way to describe Mediator, use it. Use it correctly, and don't spend too much time explaining what all of the symbols mean or why. Don't worry about explaining why the activation box on the Mediator in the Wikipeida page is broken into two part. Doing so will teach UML as one learns a natural language.

If any of your students go on to become systems engineers, they will have to learn UML the "right" way. And they will get to learn all of the kludges we use to make UML work in situations where it shouldn't. You wont want any of those in your course.

If you wish to support the students who will work under a systems person in the future, go with the natural learning approach -- show them the tools, and let them riff on them. Let them express themselves in almost-UML. Then construct the assignments in a way where requirements come down from a systems person in proper UML speak, and use that as your tool for teaching UML.

Improve this answer
$\endgroup$
1
  • 4
    $\begingroup$ I'm sure each software developer's career is different. But I not only found that I managed to get away with almost-UML for over a decade, learned intuitively by examples, but that once I learned the actual formal UML rules, I became less effective at communicating my ideas using the diagrams. $\endgroup$
    – Cort Ammon
    Commented Mar 21, 2021 at 1:05
10
$\begingroup$

You are teaching a course on design patterns, not on UML. You just happen to be using UML for the graphical notations.

As UML is not the subject, don't spend too much time on it. Spend just enough time so that your students understand what you mean with each symbol that gets used in class as if it were a notation you invented, but also tell them it is called UML.

That way, it doesn't take over the subject of the class, but students interested in learning more can do so by themselves.

Improve this answer
$\endgroup$
5
$\begingroup$

This depends on the level of the course you are teaching and what background the students have. But UML is a language unto itself and has sufficient expressiveness to use it as a way to generate program outlines. Personally, I find it a bit intrusive and, not unlike flow charts (flaw charts), can get in the way.

But a simplification of UML is probably very useful showing relationships between classes. Boxes with arrows is probably enough to get started. If people are learning OO along with some OO language, then focus on the language and its uses, with UML-lite diagrams as a supplement. Visual learners will appreciate it.

But, if you need to have a philosophy about programming in an OO language in order to avoid the traps. Just as in flow charts where it is entirely too easy to draw an arrow, leading to terrible code, the same can be true with UML.

But, if your philosophy of OO is that a class is "a bundle of behavior", rather than "bundle of data", then you can use UML to show the public interface of a class (public methods) along with relationships, avoiding the "field" entries in the diagrams.

Another issue, is that if you program using composition, rather than inheritance (as I recommend) then Inner Classes are important for hiding details of a composition. There was a time when UML supported this idea poorly. (Caveat: that may have changed).

I'll especially note that for Strategy and Decorator patterns, which I find very useful to produce clean code with low cyclomatic complexity, that inner classes (composition) are especially useful. They are simple enough, like your other suggested patterns, that the UML diagrams for them won't be overwhelming. But still, a simplified (behavior only) view is enough.

I think there is one use of UML that can be useful for novices if they work in teams and have actual team meetings. UML diagrams (simplified) can be used as a brainstorming tool permitting ideas to be quickly sketched, critiqued and, perhaps, abandoned.

But the same is true of CRC cards, which are nothing more than index cards used in a certain way. They are easy to use, share, annotate, and discard as needed.

For advanced students, however, it might be necessary to go into the detail of UML to prepare them for the workforce.

Programming by composition means that for most classes, the inner workings are dependent on having "parts" that are, themselves, objects, not primitive values. Only the innermost items of a composition (of compositions) are primitives. This gives the programmer a way to control the semantics of the parts and develop the parts with their own methods. You can't do that if everything is an int or a long.

Improve this answer
$\endgroup$
2
$\begingroup$

I recommend teaching UML only as deep as the required notation to understand the design patterns. Let them be exposed to analyzing UML diagrams and creating some. I believe this will be good foundation for them to google about specific concepts or notation in UML in the future if they need to.

I will share good resources too:

Online Visual Paradigm - have free academic partnership that your course/school can utilize

Head First: Design Patterns

Awesome design pattern resource: https://refactoring.guru/design-patterns/catalog

I also create a simple code base on my repository https://github.com/clarkngo/design-patterns

Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks for those resources! $\endgroup$
    – Ben I. ♦
    Commented Apr 7, 2021 at 21:04
2
$\begingroup$

As I commented to the question I absolutely hated all Rational tools and since Rational was the driving force behind UML, so I was never a fan of UML. But I want to emphasized that I had quite some hand-on experience to make this point.

Then I came across these 2 interesting articles I would like to share,

  1. Why UML "Really" Died I agree most parts of this article, expect for this point "textual formats are terrible at representing visual layout.", then why complained "No Text Format". As a matter of fact, I like to use Mermaid
  2. Has UML died without anyone noticing?
Improve this answer
$\endgroup$
3
  • $\begingroup$ Thanks! This pretty much cemented my decision to only teach a few diagrams, and to do it without a huge amount of detail. The author there talked about the "sketch" use... my two goals are to "describe" an OOP pattern, and to have students "sketch" some ideas out. So, no enterprise-level tooling, no Rational, nothing like that. Just, " what do we need to communicate this pattern well enough for you to internalize it?" $\endgroup$
    – Ben I. ♦
    Commented May 10, 2021 at 10:16
  • $\begingroup$ @BenI. I recently hit a similar problem and would like to hear your experience. When will you use flowchart or sequence diagram to describing a sequence of operations or activities? I am not referring to UML diagrams but flowchart and sequence diagram in general sense. $\endgroup$
    – Qiulang 邱朗
    Commented Apr 2, 2022 at 2:24
  • $\begingroup$ For example when describe an algorithm, which in the simplest sense is from an input get an output, both flowchart and sequence diagram can do the job. They may focus on difference aspects of operation, e.g. sequence diagram may focus on interaction and flowchart focus on control flow but they also have overlapping areas. So I would like to hear your opinion. $\endgroup$
    – Qiulang 邱朗
    Commented Apr 2, 2022 at 2:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.