UML gives you a standardized, flexible language to design and model your software. This chapter covered the following UML diagrams:
use case diagrams
component and deployment diagrams
You also learned some concepts about software architecture, such as domain modeling and gathering requirements.
Remember, using every diagram is not necessary. The use case and class diagrams are almost always useful, but the other diagrams are not worth drawing for every class or use case in your software. You need an activity diagram only if you want to get a better idea of the processes within a single use case. Use a state diagram if you have an object whose state changes in a complex way during one or more use cases and you need to make clear how it will work. A few sequence diagrams are usually necessary, but don't try to diagram every message passed between every instance in your application.
Chapter 4, "Design Patterns," discusses software design patterns, which are a way of describing reusable object relationships that you can use to solve various problems in software development. Because each design pattern is described with a UML class diagram, you're in good shape to learn about them when you get to that chapter.