Teamwork ---------------------------------------- Benefits : - Two heads are better than one, but watch out for "death by committe" - There is no single solution to a problem, and more collaborators increases the liklihood that a good one will be chosen. - A team has the potential to accomplish more than an individual. - A team can fill in for each other, provides flexibility, allows various points of expertise - The real world works this way. Problems : - But why should I depend on someone else for my grade? - It is hard to reconcile coding styles - Bob ain't doing his part - I'm a frickin genius, why don't these people see it? Cautions : - You can't do it yourself; you will fail. Let other people help - If you know more than the other people, share it. - Don't commit to more than you can actually do. - Be on time, every time, or notify your team. - If things are taking longer than expected, COMMUNICATE THIS - If you are having problems, ASK Problem Analysis ------------------------------------------ - What are you trying to do (Analysis) - What does the system need to do to accomplish that (Design) - How do you build a system that does what you need (Implementation) Analysis Phase You have to clearly define the problem. This is usually a negotiation between the customer and the developers. They tell you what they want, you get clarification, and see if what they want is really what they say they want. Design Phase - Identify the classes - Identify the responsibilities of the classes - Identify the relationships between the classes This is an iterative process. You won't get it right the first time, and thinking that you did will only cause you problems later on. Implementation phase Build it. This usually leads to changes in phase 1 and 2. Misleading to think of these as discreet and sequential phases. Each phase will lead to a return to the other parts, as problems require re-negotiation, clarification, restructuring, etc. Analysis Phase Detail ------------------------------------------------------ Use cases This is part of analysis. It describes a sequence of events that yields a result. "back button" Design Phase Detail ------------------------------------------------------ Discovering Classes, Responsabilities, Relationships classes - nouns responsabilities - verbs This is a balancing act. If you make things too specific, then you will be mislead. Example of selling stuff - no need for classes for products, one product class suffices. Too general is also bad; if you just have a browser class, and it does everything, then it isn't really object oriented; it is a functional program jammed into one big object. Some things useful to help discover classes : -Tangible things - these are the nouns. First step. -Agents - This is turning a method into a class that specializes in this. For example, renderers, tokenizers,processors, translators, etc. -Events and transactions - very important in data oriented applications; adds, updates, deletes, or at low level mouse moved, keyboard input, exception -Users and roles - any app with users (and this is most) needs to identify user info, such as permissions, or address info, or security data, or preferences. -Systems - this is the overall controller, or controllers, of the project. Server, client, interface. -System interface - File io, database, mail, messaging, sockets, etc. -Foundational classes - assume that these exist. String, Date, Rectangle, Shape. Some things useful to help discover responsabilities : Responsabilities should belong to one class, and only one class. They can be augmented (decorator, facade, etc), but the core responsability should belong to one place, and not half in one, half in another. This does not mean that subclasses can't handle components of the responsability, but there shouldn't be two top level classes. You wouldn't make a roundshapes renderer, and a squareshapes renderer, and make the client call both. Pay attention to "layering of abstraction levels". A class should probably not be handling high and low level responsabilities. For example, a PhotoAlbum class that organizes pictures should not be reading them from disk. CRC Cards ----------------------------------------------- Design technique. Card, with responsabilities on the left, associated classes on right. Move, split, erase, very flexible. Try to keep the things high level - when it looks like multiple actions might be related, roll them up. Design tips : ----------------------------------------------- - Avoid "mission creep". If a class does too much, split it. - Avoid having unrelated things in a class. This also goes back to the levels of abstraction. - DONT DO THINGS JUST BECAUSE YOU CAN! Sorting if not necessary, translation to french, etc. - Avoid a bunch of small, unused classes too. Balancing act. - If you have a bunch of attributes, consider rolling them up into classes as well. UML diagrams. ----------------------------------------------- Standardized way to diagram classes, states. Tools are listed in the book Do this as much is as useful. Boxes with connectors -------------------- | Class Name | -------------------- | Attributes | -------------------- | Methods | -------------------- The connectors can be Dependency - - - - - - - > (dashed, open head) Aggregation <>------------- (open diamond, solid) Inheritance ---------------|> (solid, closed head) Composition <>------------- (filled diamond, solid) Association --------------- (plain, use description) Directed Assoc -------------> (solid, arrow, use desc) Interface - - - - - - - -|> (dashed, closed head) For the has (aggregation, composition) you can use numbers for relationship *, 1..*, 1..3, 1 Use aggregation only if it manages the objects. <> These should not be comprehensive, they are only to help explain parts of the system. Leave out the details if not important to what you are trying to describe. Sequence Diagrams. Flow of control, don't do for everything. State Diagrams Like old DFDs in a way. Development Tools ----------------------------------------------------- Version control - very important IDEs Logging Unit Testing