Held: ,

Back to Outline 18 - Codes of Ethics, Revisited. On to Outline 20 - Design Patterns for SaaS.

Summary

We consider the UML (Unified Modeling Language), a visual notation for describing the design of object-oriented programs.

Related Pages

Overview

• Basics of the UML.
• UML: Class notation.
• UML: Other issues.

Administrivia

• Friday PSA!
• Warning: ALthough I teach the UML, I don't use it all that much. (I also don't work in medium or large software teams.)
• Note: When Dr. Davis designed this class, she did not include a significant component on the UML. However, one of the class mentors noted that he had found serious value in using the UML, and advicated for its inclusion. I look forward to hearing what you think about this unit.

Upcoming Work

• Reading for Monday: SaaS 11
• Reading Journal for Monday (due Sunday at 11pm) (as always, inspired by JLND)
  • Subject: Reading Journal for Class 20 (Your Name)
  • In your own words, what is a design pattern? What is an antipattern?
  • What new design principle or pattern did you find most useful?
  • Which design principle or pattern did you find the most relevant to your CSC 322 project or other prior experience with object-oriented programming? Explain the pattern and why you chose it.
  • Which design principle or pattern did you find the most confusing? Explain it as best you can and say where you got confused.

Good Things to Do

• Fall Fest.
• Book sale!

The UML

• The UML == The Unified Modeling Language
• A visual notation for representing key issues in the design of an object-oriented program.
• Observation: We like to communicate things visually. But for a visual notation to work well, we have to agree upon what the symbols mean.
• Can be used prospectively or retrospectively
• Three traditional ways to think about the UML
  • We use the UML to sketch out classes and their relationships while thinking about design.
  • We use the UML to blueprint most of the details of a system.
  • We use the UML as a programming language to implement a system.
• Developed collaboratively by many of the big names in OOP in the early ages of the adoption of OOA&D by industry.
• We'll focus mostly on it as a tool for sketching.
• That is, we'll use the UML to communicate important things about our systems to each other, but we won't try to dot every t and cross every i.

UML: Class Notation

What do we care about for classes? Here are some possibilities * The basic components of the class: + The fields + The methods * The role of the class in the inheritance hierarchy * The other classes that the class uses (implicitly)

We will need notations for each of these things.

We may find that we need other notations, too.