Figures
In chapter 3 we describe Pete Coad's "Modeling in Color" technique, whereby archetypes are used to classify the domain classes into forms that they "more or less" follow. The four archetypes are:
The figures in the book do use these colors, but to keep production costs down and the book a reasonable price, the figures themselves are reproduced in gray-scale. So, we've uploaded some of the key figures in this book so you can see them in their original pan-technicolored glory.
If there's a figure that you want to see in color that hasn't been uploaded, drop us a line and we'll dig it out and upload it.
Chapter 1:
Figure 1-1: A class diagram drawn with, or generated by, Together
Chapter 3:
Figure 3-12: The domain model for CarServ after the initial modeling exercise
Chapter 4:
Figure 4-8: The Service class from our initial domain model
Figure 4-11: Updated Service class showing additional and modified operations
Chapter 6:
Figure 6-26: Pattern instances make it easier to understand a design
Figure 6-27: The PatternInstance module itself uses the visitor and template patterns
Chapter 7:
Figure 7-6: The Observer pattern is used throughout the CarServ user interface
Figure 7-7: Database schema for the Car Servicing case study
Figure 7-9: A single object diagram can show both the before and after state of an interaction
Figure 7-12: The Car is responsible for instantiating and holding Services
Figure 7-14: The System instantiates Services, and Service remembers the Car
Figure 7-20: Booking in a car, described at a specification level
Figure 7-23: Statement blocks can show alternate outcomes
Figure 7-24: There are various UML interaction types
Figure 7-26: Class diagrams can be used to filter out implementation classes
Figure 7-27: Relationship between packages and classes
Figure 7-29: Class diagrams can narrow in on a particular corner of the design
Figure 7-31: Drawing two links is one way of showing a bi-directional navigability...
Figure 7-32: … but a constraint is required to ensure that the semantics of bi-directional associations are preserved
Figure 7-34: Bi-directional associations made easy
Figure 7-35: Qualifiers are shown as adornments to the association
Chapter 8:
Figure 8-2: Deployment diagrams can capture numerous architectural constraints
Figure 8-3: Run-time component diagrams can be used to show communication
Figure 8-4: The CarServ application in client/server mode, as a run-time component diagram
Figure 8-5: Compile-time dependencies show more detail than run-time dependencies
Figure 8-7: Interfaces can be implemented by software in different process spaces
Figure 8-16: The Command object gets and sets information in the Arg object
Figure 8-21: The domain package depends upon the datamgmt package…
Figure 8-22 : … or is it the other way around?
Appendix B:
Figure B-2: The fundamental JUnit classes and interfaces
Appendix E:
Figure E-3: InspectorBuilder adapter / template class
Appendix F:
Figure F-1: The RwiSupport framework allows auditing of non-code based elements
Appendix G:
Figure G-1: Overview class diagram
Figure G-2: Overview class diagram, detail omitted
Figure G-3: Car and Service Implementation class diagram
Figure G-4: BookIn.doExecute() sequence diagram
Figure G-5: Implementation Packages (showing classes)
Figure G-6: Database schema
|
