List of Figures

Chapter 1: A Little Taste of C#

Figure 1-1: Anatomy of a simple C# program

Chapter 2: Abstraction and Modeling

Figure 2-1: A generic abstraction of a cell
Figure 2-2: A simple abstraction hierarchy of natural objects
Figure 2-3: Focusing on a small subset of the hierarchy is less overwhelming.
Figure 2-4: Deriving the correct classification rules can be difficult.
Figure 2-5: Proper classification rules have been established.
Figure 2-6: A rule set that is too relaxed is as much of a problem as an overly restrictive rule set.
Figure 2-7: The human brain is adept at learning by building upon already-established abstractions.
Figure 2-8: Describing a landscape in UML notation

Chapter 3: Objects and Classes

Figure 3-1: A class defines attribute names and types.
Figure 3-2: An object provides attribute values.
Figure 3-3: Using a reference variable to keep track of an object in memory
Figure 3-4: Maintaining multiple handles on the same object
Figure 3-5: A second object comes into existence.
Figure 3-6: Transferring object handles
Figure 3-7: The first object is now lost to our program.
Figure 3-8: Conceptual object "nesting"
Figure 3-9: Objects exist separately in memory and maintain handles on one another.

Chapter 4: Object Interactions

Figure 4-1: SRS objects must collaborate to accomplish the overall SRS mission.
Figure 4-2: Message passing between a Student and Course object
Figure 4-3: A requestor sees only the external details of a message exchange.
Figure 4-4: A more complex message passing example involving three objects
Figure 4-5: The external details of this more complex interaction appear identical from the requestor's standpoint.
Figure 4-6: Attributes and the internal details of how methods work are "walled off" from client code.
Figure 4-7: Sorting out terminology
Figure 4-8: A "set" method is used to pass data into an object
Figure 4-9: A "get" method is used to retrieve data out of an object.

Chapter 5: Relationships Between Objects

Figure 5-1: An association is a template for creating links.
Figure 5-2: A ternary association
Figure 5-3: An equivalent representation using three binary associations
Figure 5-4: A many-to-many assocation between classes; links are always pairwise between objects.
Figure 5-5: A one-to-one assocation between classes; links are always pairwise between objects.
Figure 5-6: A sample class hierarchy
Figure 5-7: Class hierarchies almost always expand over time.
Figure 5-8: A method may be overridden multiple times within a class hierarchy.
Figure 5-9: A sample single inheritance hierarchy
Figure 5-10: Multiple inheritance permits a derived class to have multiple immediate ancestors.

Chapter 6: Collections of Objects

Figure 6-1: A collection organizes object references.
Figure 6-2: A collection references objects, which live separately in memory.
Figure 6-3: Array x is designed to hold up to 20 Student references.
Figure 6-4: Handing new objects one by one into a collection
Figure 6-5: A jagged two-dimensional array as an array of one-dimensional arrays
Figure 6-6: Collections other than arrays grow gracefully as needed.
Figure 6-7: Collections other than arrays automatically shrink as items are removed.
Figure 6-8: A set is an unordered collection.
Figure 6-9: Collections other than sets accommodate mutiple references to the same object.
Figure 6-10: Dictionary collections accommodate direct access by key.
Figure 6-11: A given object may be referenced by multiple collections simultaneously.

Chapter 7: Some Final Object Concepts

Figure 7-1: The Print method of Person is selectively overridden.
Figure 7-2: Subsequent overriding of Print by newly derived classes
Figure 7-3: "Breaking the spell" of abstractness by overriding abstract methods
Figure 7-4: The Professor object has three different identities.
Figure 7-5: Objects "fill in" their individual attribute values.
Figure 7-6: The value of a static attribute conceptually belongs to the class as a whole.
Figure 7-7: A class serves as a template for creating objects.
Figure 7-8: Objects then fill in the values of their nonstatic attributes.
Figure 7-9: Nonstatic attribute values are undefined in the class context.

Chapter 8: The Object Modeling Process in a Nutshell

Figure 8-1: Of the three aspects of a methodology, a sound process is by far the most important.
Figure 8-2: A methodology encompasses process, notation, and tools.
Figure 8-3: Many different approaches can serve us well when building software.

Chapter 9: Formalizing Requirements Through Use Cases

Figure 9-1: A "proper" UML use case diagram
Figure 9-2: Our customized version of use case notation
Figure 9-3: A sample UML use case diagram

Chapter 10: Modeling the Static/Data Aspects of the System

Figure 10-1: Noun phrases found in the SRS specification
Figure 10-2: Removing duplicates streamlines the noun phrase list.
Figure 10-3: Further streamlining the SRS noun phrase list
Figure 10-4: Grouping synonyms
Figure 10-5: UML depiction of the Student class
Figure 10-6: UML depiction of an abstract class
Figure 10-7: Class rectangles are divided into three compartments.
Figure 10-8: Alternative UML class depiction as rendered by some CASE tools
Figure 10-9: Sometimes just attribute names are presented.
Figure 10-10: Sometimes both attribute names and types are shown.
Figure 10-11: Identifying static attributes by underlining
Figure 10-12: Sometimes just method names are presented.
Figure 10-13: Sometimes argument signatures and return types are also reflected.
Figure 10-14: Representing associations between classes
Figure 10-15: Equivalent depictions of the advises association between the Professor and Student classes
Figure 10-16: Using an arrowhead to indicate the direction of an association label
Figure 10-17: A reflexive association involving the Course class
Figure 10-18: Indicating aggregation with a diamond
Figure 10-19: Aggregations can be oriented in any direction.
Figure 10-20: A simple association as an alternative to an aggregation
Figure 10-21: Two aggregations, drawn using two diamonds
Figure 10-22: Two aggregations involving the same "whole" class, drawn using a single diamond
Figure 10-23: Inheritance is indicated with a triangle.
Figure 10-24: Depicting two derived classes with two different triangles
Figure 10-25: Depicting two derived classes with a single triangle
Figure 10-26: Indicating multiplicity between classes
Figure 10-27: An example of mandatory one-to-one multiplicity
Figure 10-28: An example of mandatory one-to-many multiplicity
Figure 10-29: An example of optional one-to-many multiplicity
Figure 10-30: An example of optional many-to-many multiplicity
Figure 10-31: An example of optional many-to-many multiplicity on a reflexive association
Figure 10-32: Reflecting multiplicity on an aggregation
Figure 10-33: Multiplicity adornments are inappropriate for inheritance relationships.
Figure 10-34: Indicating both inheritance and an association between the Person and Student classes
Figure 10-35: Representing an object
Figure 10-36: We omit the class name if it's otherwise obvious.
Figure 10-37: Representing an anonymous object
Figure 10-38: Dr. Brown advises three students.
Figure 10-39: An instance diagram involving numerous objects
Figure 10-40: A one-to-many association between the Course and Section classes
Figure 10-41: Redundantly reflecting references as attributes is incorrect; the presence of an association implies these.
Figure 10-42: The name and chairmanName attributes are redundant.
Figure 10-43: The redundancy of Figure 10-42 has been eliminated.
Figure 10-44: An association "pipeline" between the Course, Section, and Professor classes.
Figure 10-45: Association "pipelines" can be quite elaborate!
Figure 10-46: We add redundant associations when objects frequently need a more direct "pipeline" for communication.
Figure 10-47: A sample UML model
Figure 10-48: Various possible "mentorship" associations are implied.
Figure 10-49: Specific mentor associations are deliniated.
Figure 10-50: A many-to-many association between Student and Section
Figure 10-51: Placing an association class on a many-to-many association
Figure 10-52: An alternative representation for Figure 10-51
Figure 10-53: Placing an association class on a one-to-many association
Figure 10-54: An alternative representation for Figure 10-53
Figure 10-55: Association classes themselves can participate in associations with other classes.
Figure 10-56: Our "completed" SRS class diagram
Figure 10-57: A WaitList can be modeled as an aggregation of WaitListEntry objects.
Figure 10-58: A Transcript is an aggregation of TranscriptEntry objects.
Figure 10-59: Initial portrayal of the attends association
Figure 10-60: The attends association may be portrayed alternatively as issues and receives.
Figure 10-61: GradeReceived has access to all of the makings of a TranscriptEntry.
Figure 10-62: A sample transcript report

Chapter 11: Modeling the Dynamic/Behavioral Aspects of the System

Figure 11-1: The state of an object includes the links it maintains with other objects.
Figure 11-2: Objects' interactions can affect their state.
Figure 11-3: Some interacting objects experience a change of state, others don't.
Figure 11-4: Revisiting the UML diagram for the advises association.
Figure 11-5: Fred's view of things, part 1
Figure 11-6: Fred's view of things, part 2
Figure 11-7: Fine-tuning the UML diagram
Figure 11-8: Sequence diagram for Scenario #1
Figure 11-9: hen Fred logs on, a Student object is created.
Figure 11-10: As requested, a schedule of classes is displayed.
Figure 11-11: Availability of the requested section is confirmed.
Figure 11-12: Collaboration diagram for Scenario #1
Figure 11-13: Fred sees only a small subset of the SRS collaborations.
Figure 11-14: Revised SRS class diagram

Chapter 12: Wrapping Up Our Modeling Efforts

Figure 12-1: Modeling degree program requirements proves to be rather complicated
Figure 12-2: Making minor adjustments to the SRS class diagram
Figure 12-3: Reusing the SRS design pattern for WBY
Figure 12-4: A general-purpose class diagram for reservation systems

Chapter 13: A Deeper Look at C#

Figure 13-1: One "official" Main method will drive the SRS.
Figure 13-2: Source files can be compiled directly into an executable file …
Figure 13-3: … or can first be compiled into DLL form.
Figure 13-4: Conventional compilation yields platform-dependent executable code.
Figure 13-5: .NET compilation yields platform-independent MSIL code.
Figure 13-6: Different common language runtimes can understand the same MSIL file.
Figure 13-7: Course exists in two namespaces; Professor and Student do not.
Figure 13-8: Execution sequence for try-catch blocks
Figure 13-9: Execution sequence for try-catch-finally blocks
Figure 13-10: If no catch blocks match, the exception is "thrown" to the client code.
Figure 13-11: Object #2 has the same data values as Object #1 but is a separate, distinct object in memory.
Figure 13-12: An ArrayList can be initialized with the contents of another collection.
Figure 13-13: An enumerator can step through the elements of a collection.
Figure 13-14: A Professor object is simultaneously a Person object and an Object object, all rolled into one!
Figure 13-15: The compiler only knows about this Professor object's "Object-ness."
Figure 13-16: The compiler now recognizes this Professor object's "Object-ness" and "Person-ness."

Chapter 14: Transforming Our UML Model into C# Code

Figure 14-1: The resultant streamlined SRS class diagram
Figure 14-2: The Person class
Figure 14-3: The Student class
Figure 14-4: The "mechanics" of method chaining
Figure 14-5: The Professor class
Figure 14-6: The Course class
Figure 14-7: The prerequisite association isn't implemented bidirectionally.
Figure 14-8: The Section class
Figure 14-9: Adding the assigns grade association
Figure 14-10: Many objects collaborate to accomplish a single method.
Figure 14-11: The ScheduleOfClasses class
Figure 14-12: The TranscriptEntry class
Figure 14-13: The TranscriptEntry class has relationships with many other classes.
Figure 14-14: The Transcript class

Chapter 15: Rounding Out Our Application, Part 1—Adding File Persistence

Figure 15-1: Adding file persistence and a GUI front-end to the SRS
Figure 15-2: Reading from a file, C# style
Figure 15-3: Writing to a file, C# style
Figure 15-4: UML diagram for the SRS collections

Chapter 16: Rounding Out Our Application, Part 2— Adding a Graphical User Interface

Figure 16-1: Relationship of containers to components
Figure 16-2: Using a list to display Student information
Figure 16-3: Using photographs to display Student information
Figure 16-4: Using a diagram to display Student information
Figure 16-5: Viewing folder contents as icons …
Figure 16-6: … . or as a detailed list …
Figure 16-7: … . or as an HTML page …
Figure 16-8: … . or as a DOS directory listing.
Figure 16-9: The UML model underlying all of our various Windows views
Figure 16-10: The initial view of the SRS GUI
Figure 16-11: Joe types his password into the dialog box.
Figure 16-12: If the password is invalid, a warning dialog box appears.
Figure 16-13: Joe has successfully logged on to the SRS.
Figure 16-14: Joe's current registration data is displayed.
Figure 16-15: Joe tries to register for a course.
Figure 16-16: Joe has already enrolled in a different section of CMP101.
Figure 16-17: Joe attempts to register for CMP999.
Figure 16-18: Joe hasn't satisfied the prerequisites for CMP999.
Figure 16-19: Joe tries to register for ART101.
Figure 16-20: Success at last!
Figure 16-21: Joe is now registered for two courses.
Figure 16-22: Joe drops CMP101.
Figure 16-23: The drop request is successful.
Figure 16-24: Joe is only registered for ART101 now.
Figure 16-25: Joe's schedule is saved to a file.
Figure 16-26: Joe has logged off of the SRS system.
Figure 16-27: GUI components are placed on a container.
Figure 16-28: Some of the built-in features of a Form
Figure 16-29: A simple Form
Figure 16-30: By default, a Form will appear in the upper-left corner of the display.
Figure 16-31: A Form can be centered on the display using the StartPosition property.
Figure 16-32: The SRS GUI will showcase a variety of GUI objects.
Figure 16-33: If the SRS GUI is resized to be smaller, some of the components won't be visible.
Figure 16-34: We've added four Label objects to the Form.
Figure 16-35: Three TextBox objects are added to the SRS GUI.
Figure 16-36: Two ListBox objects are added to the SRS GUI.
Figure 16-37: The look of our SRS GUI is complete!
Figure 16-38: The SRS GUI as it would appear with the Button objects disabled
Figure 16-39: A sample MessageBox
Figure 16-40: Events are generated automatically in response to user interactions with GUI objects.
Figure 16-41: We can choose the types of types of events to which we'll respond.
Figure 16-42: Class X declares a requirement for a delegate "plug-in."
Figure 16-43: An appropriate method is associated with an instance of X at run time.
Figure 16-44: Different instances of X can be associated with different methods.
Figure 16-45: The same method can be associated with more than one object.
Figure 16-46: More than one method can be associated with a single instance of a multicast delegate.
Figure 16-47: A Form with a single Button

Appendix D: Downloading and Compiling the SRS Source Code

Figure D-1: The source code directory structure