<p>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.</p>
<p>I will share good resources too:</p>
<p>Online Visual Paradigm - have free academic partnership that your course/school can utilize</p>
<p>Head First: Design Patterns</p>
<p>Awesome design pattern resource:
<a href="https://refactoring.guru/design-patterns/catalog" rel="nofollow noreferrer">https://refactoring.guru/design-patterns/catalog</a></p>
<p>I also create a simple code base on my repository
<a href="https://github.com/clarkngo/design-patterns" rel="nofollow noreferrer">https://github.com/clarkngo/design-patterns</a></p>

CC BY-SA 4.0
2021-04-07T21:04:32.990Z
Thanks for those resources!
Ben I.
CC BY-SA 4.0
2021-04-07T16:43:20.340Z
2021-04-07T16:43:20.340Z
Clark Ngo
<p>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.</p>
<p>Then I came across these 2 interesting articles I would like to share,</p>
<ol>
<li><a href="https://buttondown.email/hillelwayne/archive/why-uml-really-died/" rel="nofollow noreferrer">Why UML &quot;Really&quot; Died</a> I agree most parts of this article, expect for this point &quot;textual formats are terrible at representing visual layout.&quot;, then why complained &quot;No Text Format&quot;. As a matter of fact, I like to use <a href="https://mermaid-js.github.io/mermaid/#/" rel="nofollow noreferrer">Mermaid</a></li>
<li><a href="https://garba.org/posts/2021/uml/" rel="nofollow noreferrer">Has UML died without anyone noticing?</a></li>
</ol>

CC BY-SA 4.0
2021-05-10T10:16:19.643Z
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?"
Ben I.
CC BY-SA 4.0
2022-04-02T02:24:05.780Z
@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.
Qiulang 邱朗
CC BY-SA 4.0
2022-04-02T02:28:33.863Z
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.
Qiulang 邱朗
CC BY-SA 4.0
2021-05-10T06:17:57.360Z
2021-05-10T06:31:23.100Z
2021-05-10T06:31:23.100Z
Qiulang 邱朗
<p>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.</p>
<p>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!</p>
<p>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, &quot;wait... if I use the Decorator pattern here, I can make this diagram look better.&quot;  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!</p>
<p>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 <a href="https://en.wikipedia.org/wiki/Mediator_pattern" rel="noreferrer">Mediator</a>, 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.</p>
<p>If any of your students go on to become systems engineers, they will have to learn UML the &quot;right&quot; 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.</p>
<p>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.</p>

CC BY-SA 4.0
2021-03-21T01:05:24.013Z
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.
Cort Ammon
CC BY-SA 4.0
2021-03-21T01:02:09.917Z
2021-03-21T01:02:09.917Z
Cort Ammon
<p>You are teaching a course on design patterns,  not on UML. You just happen to be using UML for the graphical notations.</p>
<p>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.</p>
<p>That way, it doesn't take over the subject of the class, but students interested in learning more can do so by themselves.</p>

CC BY-SA 4.0
2021-03-21T08:13:00.690Z
2021-03-21T08:13:00.690Z
Bart van Ingen Schenau
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>But, if your philosophy of OO is that a class is &quot;a bundle of behavior&quot;, rather than &quot;bundle of data&quot;, then you can use UML to show the public interface of a class (public methods) along with relationships, avoiding the &quot;field&quot; entries in the diagrams.</p>
<p>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).</p>
<p>I'll especially note that for Strategy and Decorator patterns, which I find very useful to produce clean code with low <a href="https://en.wikipedia.org/wiki/Cyclomatic_complexity" rel="noreferrer">cyclomatic complexity</a>, 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.</p>
<p>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.</p>
<p>But the same is true of <a href="https://en.wikipedia.org/wiki/Class-responsibility-collaboration_card" rel="noreferrer">CRC cards</a>, which are nothing more than index cards used in a certain way. They are easy to use, share, annotate, and discard as needed.</p>
<p>For advanced students, however, it might be necessary to go into the detail of UML to prepare them for the workforce.</p>
<hr />
<p>Programming by composition means that for most classes, the inner workings are dependent on having &quot;parts&quot; 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.</p>

CC BY-SA 4.0
2021-03-20T16:11:17.617Z
2021-03-20T16:20:38.117Z
2021-03-20T16:20:38.117Z
Buffy
<p>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 <em>not</em> have a lot of background in this topic yet.  I am currently learning the material as I develop the course for next September.</p>
<p>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.</p>
<p>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?</p>

CC BY-SA 4.0
2021-03-20T16:40:21.537Z
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.
Michel Billaud
CC BY-SA 4.0
2021-03-21T04:35:50.730Z
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.
Owen Reynolds
CC BY-SA 4.0
2021-03-21T15:27:44.633Z
Related reading: https://ronnieschaniel.medium.com/object-oriented-design-patterns-explained-using-practical-examples-84807445b092
ThisClark
CC BY-SA 4.0
2021-03-26T07:08:33.843Z
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.
Qiulang 邱朗
CC BY-SA 4.0
2021-03-29T05:25:54.887Z
Mostly in response to your last sentence (question) https://news.ycombinator.com/item?id=24056901 Only makes sense if "patterns" can be significantly widened beyond "OO patterns"
Rushi
CC BY-SA 4.0
2021-03-31T06:42:19.413Z
I can't find the quote I guess it was too long ago. But this article was written probably in 2010, which shown clearcase was still terrible https://daedtech.com/how-rational-clear-case-stole-my-innocence-and-nearly-ruined-my-life/, to quote "So don’t let Clear Case or anything else steal your innocence or ruin your life; don’t tolerate a tool that constantly forces you to think about it as you battle it."
Qiulang 邱朗
CC BY-SA 4.0
2021-03-31T16:45:18.807Z
@Qiulang What does Clear Case have to do wit UML?  UML isn't version control.
Ben I.
CC BY-SA 4.0
2021-03-31T17:59:28.600Z
I know clear case has nothing to do with UML. It is Rational Rose. I remembered it was terrible too. The fact that Rational hired grady booch and some other OO experts to as their team leads while their softwares were so terrible was my point. It was 20 years ago and your question just brought back that memory.
Qiulang 邱朗
CC BY-SA 4.0
2021-03-31T18:29:09.657Z
@Qiulang Sorry to bring back your pain!
Ben I.
CC BY-SA 4.0
2021-04-01T05:14:58.173Z
@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](https://www.amazon.com/Applying-UML-Patterns-Craig-Larman/dp/0137488807) ??
Rushi
CC BY-SA 4.0
2021-04-01T07:52:26.903Z
@BenI. from then now I was NOT a strong advocate of object-oriented programming any more :D
Qiulang 邱朗
<object-oriented-paradigm>
How necessary is UML for a course in object programming patterns?
# How necessary is UML for a course in object programming patterns?

(Asked by: username_0 on 2021-03-20)

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?

**Tags:** object-oriented-paradigm

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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.  
> **username_3**: Related reading: https://ronnieschaniel.medium.com/object-oriented-design-patterns-explained-using-practical-examples-84807445b092  
> **username_4**: 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.  
> **username_5**: Mostly in response to your last sentence (question) https://news.ycombinator.com/item?id=24056901 Only makes sense if "patterns" can be significantly widened beyond "OO patterns"  
> **username_4**: I can't find the quote I guess it was too long ago. But this article was written probably in 2010, which shown clearcase was still terrible https://daedtech.com/how-rational-clear-case-stole-my-innocence-and-nearly-ruined-my-life/, to quote "So don’t let Clear Case or anything else steal your innocence or ruin your life; don’t tolerate a tool that constantly forces you to think about it as you battle it."  
> **username_0**: @Qiulang What does Clear Case have to do wit UML?  UML isn't version control.  
> **username_4**: I know clear case has nothing to do with UML. It is Rational Rose. I remembered it was terrible too. The fact that Rational hired grady booch and some other OO experts to as their team leads while their softwares were so terrible was my point. It was 20 years ago and your question just brought back that memory.  
> **username_0**: @Qiulang Sorry to bring back your pain!  
> **username_5**: @Quilang : Thanks for the clear-case blog-link. It helps me in something I'm just writing on the edu-costs of bad tooling.  username_0 : You have seen [Larman : Applying uml and patterns](https://www.amazon.com/Applying-UML-Patterns-Craig-Larman/dp/0137488807) ??  
> **username_4**: @BenI. from then now I was NOT a strong advocate of object-oriented programming any more :D  

---

## 5 answers

### Answer by username_7 on 2021-03-21. Score: 10

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](https://en.wikipedia.org/wiki/Mediator_pattern), 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.

> **Comments:**
> **username_7**: 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.  

---

### Answer by username_8 on 2021-03-21. Score: 10

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.


---

### Answer by username_9 on 2021-03-20. Score: 5

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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Class-responsibility-collaboration_card), 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.


---

### Answer by username_6 on 2021-04-07. Score: 2

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>

> **Comments:**
> **username_0**: Thanks for those resources!  

---

### Answer by username_4 on 2021-05-10. Score: 2

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](https://buttondown.email/hillelwayne/archive/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](https://mermaid-js.github.io/mermaid/#/)
2. [Has UML died without anyone noticing?](https://garba.org/posts/2021/uml/)

> **Comments:**
> **username_0**: 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?"  
> **username_4**: @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.  
> **username_4**: 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.  

---

