CS680 Midterm Reading Guide, updated for final exam

Main text: Object Oriented Software Engineering Using UML, Patterns, and Java, Second Edition, by Bernd Bruegge and Allen Dutoit
Chap 1: Intro
Chap 2: Read  pp 29-60 except as follows:
Skip Sec. 2.2.4-2.2.5 and their Fig. 2-4, 2-5 (statechart and activity diagrams)
Midterm:Skip Fig. 2-25, 2-26 (association classes)
Final: We have now covered association classes. However, these figures need fixing. In Figure 2-25, change the 1 on Incident to *, so that this is N-N from FieldOfficer to Incident (the normal case for assoc. classes).  In Figure 2-26, each Allocation represents a particular combination of one FieldOfficer and one Incident.The FieldOfficer should have 1, its side of Allocation should have * (from the * we put on Incident in 2-25), the Incident should have 1 and its side of Allocation should have 1..*. Since the Allocation sees a single associated FieldOfficer, the name should be "resource", not "resources". I'm planning to report this as errata, along with the similar problem in Fig. 10-13.
pg. 54: Aggregation has been dropped from UML, but composition lives on in UML. See notes of 9/11
and more discussion in book on pg. 192, where composition is defined.
Skip Fig. 2-31 (qualification)
Final: add Fig 2-35. We could use this *op3() notation in our Pong7b sequence diagram.

Chap 3: Skip

Chap. 4:
Read pg. 125: intro SatWatch example
Read pp 130-146: identifying actors, scenarios, use cases
Read pp 153-166: Arena ex.

Chap 5
Read pp. 177-197: entity objects (model objects), boundary objects (view objects), and
control objects. Note no mention of MVC here, so sneaky intro to it.
Final: Note that entity objects are candidates for persistent objects, if they represent long-term data for the app. We didn't get to see this in our Pong project, because we only played one game.
p. 189: "entity objects (i.e. model objects) never access boundary or control objects" There's
the basic layering, in one line.
Skip CRC cards (5.4.5)
Note pg 192: aggregation vs. composition, where aggregation is now deprecated
Read pp 206-217, Arena ex
Final:  Table 5-6 Note that all entity objects except Game have listed attributes and would be persistent objects. Game is special because it has rapidly changing state of no long-term interest.

Chap. 6
Read pp 228-243:
Note pg 230 discussion of dependencies (should be more highlighted)
pg. 233: "high coupling only an issue if change is likely". Note also that high coupling impacts testability.
Skip Fig 6-6, 6-7 (confusing example)
Pg. 234: note layers def.
Pg. 238: note repository def.
Pg. 239: finally MVC by name, but diagram (Fig. 6-14) is defective. Use F&F, pg. 530 diagram.
Skip Peer-to-peer, stop after Three-tier.  Note Pizza is "three tier".
Final: Fig. 6-20 caption: "The database server can both process requests from and send notifications to applications." Note that a database used via JDBC cannot send notifications directly to an app. We had to poll the database to find a new move.
Final: Add Sec. 6.4.3, pp 252-254. I would use directional dependencies whereever possible in the related diagrams to find layers if they exist. Note the idea of using the Facade pattern to provide a unified API to a subsystem, like the example in class of PizzaService being a combination of StudentService and AdminService for the Pizza system.

Chap 7.
Final: Read Sec. 7.4.4 Designing the Global Control Flow
Note Procedure-driven vs. event-driven. Threads here are only discussed for procedure-driven code, but we used them for event-driven code, spinning off work that would slow down the event loop.
Final: Read Sec. 7.6, pp 288-293. Arena case study. Note that here in Fig. 7-18 and 7-19 dependencies have direction, revealing layers. Games are specially treated (bottom of pg. 292) because of their memory-only state.

Chap 8 Object Design
Final: Read Sec. 8.3, pp 309-315. Note that Fig 8-3 (right-hand side) also gives us an example of the Adapter Pattern. Note ideas of specification inheritance, implementation inheritance, delegation, Liskov Substitution Principle, and of course design patterns. In both Fig. 8-5 and 8-6 (and also Fig 8-8), "adaptee" should be at the end for the LegacyClass, since it gives a name for this as seen through the association. Also put an arrowhead on the association, since the LegacyClass is clueless about this arrangement.
Final: Read Sec. 8.4, pp 316-328. We have studied all these patterns except Composite, which you can skip if you want. We haven't labelled a pattern "Bridge", but have studied its workings, so just add that name to your vocabulary.
Pg. 325 (also pg. 339): Command pattern for Matches/Moves. Here the Invoker is Match and the command is Move, with execute() to make a move. Making a Move changes the state of a GameBoard (our PongGame), so we would expect a ref from Move to the GameBoard it could change. But if the many Moves attached to a Match are a record of the moves of a game, they can't all ref the same GameBoard meaningfully (pg. 339 shows one GameBoard/Match). Maybe the set of Moves is just the set of possible moves (like the 9 possible moves in tic-tac-toe), in which case they can all ref the current GameBoard. But then we don't have a history for "replay()".  Because of this confusion, and the fact we don't have time to sort it out in class, you can just ignore this example. We have plenty of examples in F&F.
Final: Read Sec 8.6: Arena case study, through pg 328.

Chap 10
Read pp 394-408 plus pg. 414
Final: We have now covered association classes such as shown in Fig. 10-13. However this has the same kind of errors as Fig 2-26: The * symbols need to be on the sides of Statistics, and the 1's on the Tournament and Player classes.
Final: Read pp 414-420. Note that we are showing the id attribute in the class diagram if we show attributes at all, so add "id" to Fig. 10-18 and also in 10-21 and 10-22 (in User only)
Final: Read pp 422-429 Arena ex. Note that Figure 10-24 has multiplicity problems like the other association class figures: The 0..1's are OK, but each of these (Game, League, Tournament) sees many links to Player, so there should be *s all around the diamond. But even this is not really right to carry an association class, because for overall statistics on Game for example, there is no association on which to attach the association class. As we discussed in class on 11/4, you can have Statistics in the middle instead of the diamond and get something working.

Head First Design Patterns, by Eric Freeman and Elizabeth Freeman

Chap 1: not covered, but good to read. At least read pg. 23: Prefer HAS-A over IS-A
Final: Chap 1: Now covered: read all
Chap 2 Observer Pattern: read all.
Chap 4. Factory Pattern: read all
Final:Chap. 5  Singleton Pattern: read to pg. 180, but also understand how to do this with a static initializer, which I think is easier and has no "synchonized" overhead, yet works in multithreaded programs fine.
Final: Chap 6 Command Pattern: read all. In class 12/9 we discussed how there are really two clients in the Command Pattern, the operational client and the pattern client. The operational client is the caller of the Invoker API, while the pattern client is the app that sets everything up for later use by the operational client. The GoF named the pattern client the "client", but gave no name for the operational client, leaving a vacuum for confusion. Fix your book as follows:
pg. 198: The customer here is the operational client and does not "create an order", only simply request what he wants. The pattern client is the diner owner who hired the waitress and the cook and told them what to do.
pg. 201: at start: the pattern client is responsible for creating the command object.
pg. 207: Add a class OpClient to the left of Invoker and put an association from OpClient to Invoker. Add "pattern" to Client name.
pg. 212-213: take the last 8 lines out of RemoteLoader and put them in RemoteClient, the operational client code. Add a getter for remoteControl to RemoteLoader and call it in RemoteClient.
pg. 215: Add a class RemoteClient to the left of RemoteControl (the Invoker) and put an association from RemoteClient to RemoteControl. Also I suggest putting A on RemoteClient and B on Light, to show the communications going from A to B at runtime.
pg 232: Customer is the op client, not the GoF client. Maybe add the diner owner, the real GoF client.

Final: Chap 7 Adapter and Facade: read all except pp 244-247 and 252-253.

Chap 12. MVC pp 526-544 plus pp. 549-557 except skip code in this part.
Note pg. 549 Web MVC, which we called "pull MVC" in hw3 is also called "Model 2".

Swing coverage: know all the Swing used in the Pong project, plus JSlider from trainset.