"Increment" is what I would locally call a "phase", so that increment 1 could result in release 1.2.1 or IOC. "Iteration" is a phase (finest-level) "repeat" (6-10 weeks). PROJECT PHASES (chapt 1) Inception + Elaboration + Construction + Transition Iteration are loops within a phase LENGTH of an iteration according to ArgoUML User Manual, 6 to 10 weeks. NUMBER of iterations according to app, of course, but ratio per phases of 1:2:3:3 typical (With result that a typical project will last (1+2+3+3) * 2 mon. = 18 months = 1.5 yr.) BUT ITERATIONS AND PHASES MAY OVERLAP! Increments are divisions of work with their own full 4-phase lifecycles. (i.e., their own phase schedules and iterations) Use-cases will be assigned to Increments, the more risky the Use-case, the earlier the increment it must be assigned to. Project Phases and their milestones (milestones are just wishy-washy synonyms for the conclusion of the phase) And the real phase output. Inception -> Lifecycle Objective = requirements model = diagrams + project vision [PROJECT PLANNING (not a phase-- see separate section below)] Elaboration -> (1st iteration) Lifecycle Architecture = Architectural Prototype Construction -> Initial Operational Capability Transition -> Product Release Inception: discovery, solidify project vision, feature understanding, generate Use-cases and identify architecturally significant ones. Detail the Primary Paths of Use-cases (defined below). This phase is based on the PROBLEM DOMAIN (customer's perspective), not the solution domain. Steps { Feature list Event table (funcl), Business rule list (funcl), Non-functional Reqs (latter includes Database Design requirements) Use-cases, assigning Event lists to paths and Business rules to business rule sections. Assign name to each Use-case path Non-functional Reqs -> skeleton SS? and/or Use-case templ/specs Detail primary Use-case paths Reed suggests "fleshing out" SAD List hardware pieces, supporting software (OSes, client, middleware, DB), protocols Make a component/deployment hybrid diagram out of it Assign Use-cases to increments* (riskier -> earlier) Package diagram to show Use-cases per increment } * = 1st increment Elaboration: solidify requirements, 1st it. targets architecture-impacting requirements, SAD (for Unified Process) Construction. Alpha releases, packaging, rollout, support, training Transition: betas, parallel operations with legacy, production support issues PROJECT PLANNING This isn't a phase. It comes after the Inception phase. { Make High level phase plan Make Detailed plan for current-incr 1st-iteration of Elaboration phase } UML doesn't address: Gui; Process distribution; Data distribution Unified Process (of Rational Software) [ Note that ArgoUML uses SRS for: Supplementary Requirements Specificat. ] Has 9 "Workflows" that run throughtout the project, such as "Business Modeling" and "Test". Each Workflow has an "Activity Set". SRS, Software Requirements Specification Use-case detail -> SRS Nonfunctional elements -> Supplementary Specification (or in Section 4 of Reed's Use-Case template for Use-Case-specific NFEs) (See argouml.notes file) Supplementary Specification includes Database spec, I think. SAD, Software Architecture Document. Primary documentation for Architecture p. 23 Minimal Diagrams Class/collaboration Sequence Use-case p. 47 talk about apparently optional walk throughs for sequence diagrams. p. 56 "Event Lists" and event tables aren't in the Unified Process, "but I find it invaluable to the process". p. 56 "The event list can be created separately from the event table". AND p. 58 "The goal is to get the events into the event table quickly because it is one of the first artifacts...". So, why the hell make the event list at all? EVENT TABLE Basic event: Actor + Verb + Object { Particular business goal. Self contained unit with no intervening time delays before reaches end. Actor has a specific "goal" which the actor can see through to its end. Concerned with "what", not "how" Technology-neutral } I think that each "implemented" event corresponds to a Use-case "pathway". Sample table headers: Actor Verb Object Frequency Arrival Pattern Response ----- ---- ------ --------- --------------- -------- (also need date added and ref. to use-case). Do not include "business rules" (covered elsewhere) Based on feature list. Be liberal in list. It doesn't hurt to have records with no corresponding Use-case (i.e., event doesn't get implemented). Since Use-cases built from feature list, features added "late" must go through change control. XP is a goofy development-with-a-partner strategy. POSTNOTE: WRONG. That is one rather minor facet of XP. Inception (chapt. 3) Vision { (A "few pages long" according to UML, but contains use-case specifications that are 10-15 pages each?!!!!) Business purpose Business objectives Desired features Critical success factors (scheduling, budget, hires, resources) Constraints (time, cost, functional (and nonfunct accord to Argo)) Risks (anticipated problems) Roles and responsibilities Locations of interest (staff) Stakeholders/actors Event list / event table (eventually -> SRS) Use-cases (eventually -> SRS) (I think just a summary or list of 'em) Preliminary execution architecture Project infrastructure (change control, risk assessment of changes) Project release strategy } Actors people or "other systems, timers and clocks, or hardware devices." Actors should identify the role, not a person. Events. "system-generated" triggered by criteria are handled by business rules instead of Use-cases. (unclear. p. 56) Business Rules (Functional, I think) These go "into" Use-cases, but do not define Use-cases, nor Pathways Types { Structural fact. assertions Action restricting. prohibits actions based on criteria Action triggering. does something if criteria true Inference. Knowledge inferred from other knowledge. Derivation. Similarly, like updating a running total. } Use-Cases (chapt. 4) These contain the "functional requirements" (p. 66) Just group together Events according to similar objects and/or responses. Each Use-case should definitely contain multiple paths. Functional entitlement: Use-cases are an expression of a key goal of app "in the eyes of the user". E.g. "Validate customer number" is NOT. I think that each event corresponds to a Use-case "pathway/flow". <= about 30 use cases for a single project (according to ArgoUML Manual) "Primary Path" is the most common path, and is always "successful". (Reed calls it "Happy Path". Too subjective for my tastes.) "Alternate Pathways" are alternate positive pathways "Exception Pathways". Self-descriptive. (Argo includes these w/ Alts) Standard "Actor" icon is stick figure. Can use alternate icons for Actors (especially if non-human) Arrow with triangle-head = is-a = generalization relationship dashed regular arrow = FOR ACTORS depends on = dependency association (needs an implementor of X). dashed regular arrow with <> label = includes (for UC's anyways) (Reed says <> with an S?? Prosaic meaning of "includes"). Features added later must go through change control before adding to Use-case. No standardization about what info goes into a Use-case, so need to agree on a "Template". See Reed's template on pp. 72 to 76. (ArgoUML cals it "Use case specification") (Note that his section 4 contains technology-specific data!) One field contains business rules Argo says to avoid using pre and post conditions Full template/spec should be about 10 to 15 pages. Seems to me that there should also be a reference to customer's raw requirements (Argo says that this is sometimes required by custs) Path/Flow Details (Reed calls them "paths", ArgoUML calls them "flows") Step 3 of Reed's template. At relatively high level, no specific references to technology. From a "what" perspective, not how. During Inception phase, we detail only the Primary Paths. (May be done with "outlines" or with with Activity Diagram) All paths in a Use-case are linear. Primary path just makes assertions. Alt's make contrary assertions referring to the line in the primary path. Good example at http://argouml.tigris.org/documentation/defaulthtml/manual/ch03s03.html#s3.tut.alternate_flows Each "step" interacts with or makes a change observable to Actor. Alternative paths are labelled like A1, A2 with steps A1.1, etc. steps that are "include" references are underscored (accord. Reed) Shadow Use-Cases. Reed says that these should always be "first class" Use-cases) so that they will get the attention that they need. Actor usually "IT department" { Security Audit Parameter Maintenance Archiving Architecture Infrastructure (components for communication to/from business rules). E.g., RMI, JDBC. This DOES NOT GO IN BUSINESS RULE VIEW OF USE-CASE, but is its own Use-case. } CLASS DIAGRAMS================================ 3 Class Stereotypes: Boundary (Actor interface) (like *Panel, *Interface) [V of MVC] Controller (neither Boundary nor Entity) (persistent only for conn or sess) [C and M of MVC] Entity (persistent data and associated methods) [M of MVC] However, Argo says Stereotypes are for "extending the basic UML notation", AND their selection box for Association type is labelled "Stereotype". Order Associations read top-to-bottom, left-to-right, but can use solid arrow near association to specify. Association Represents an operation/interaction, not a relationship. (for Java classes operations will be methods; for DB tables, interactions will be referential constraints/relationships). By default two-way (no arrows) If not obvious, label the assocation (like "places", "is paid by") Role is an (optional) association-specific name for each class which appears as a label on diagram near assoc-class intersections. (generated code uses these names (+ a prefix) as the ref var names) Assign correct multiplicities to entity associations so they map to correct database referential constraints ADVANCED ASSOCIATION TYPES Aggregation Components may belong to multiple owners. Composition Components belong only to the owner. Standard "part of the whole". Link. Represented by a CLASS! on the diagram. AKA Assoc. Class. Specifies run-time purpose for specific objects of class. Reflexive Qualification Dependency I think requirement on a Java Interface object (normally passed in as an instantiation parameter). STEPS Gather nouns from UC pathways (I guess "pathways". He doesn't say) Filter out. Each class should "do ONE thing WELL". + interface objects needed by actors => more Boundary classes + each UC => 1 controller class Add attributes to classes. Many atts come from nouns from UC pathways (that we filtered out above). Format: +varName:Type=`initval' (visibility is +/-/# pub/priv/protected) Add operations to classes for everything the class must do. Format: +methName(arg1nam:arg1Type,arg2nam:arg2Type):Type For each path in UC, + a corresponding method in the corresponding Controller class (I don't believe this) Make a Sequence Diagram for each Use Case path (other than Exception paths?) Needed operations will have to be added to classes (tool should auto-add) Additional classes will be needed. Operations must be numbered in a collaboration diagram. Many tools can make a collaboration diagram from a Sequence diagram. DDL Generation 1-to-1 class associations. 1 table per class. Each table has a FK to the other table. 1-to-many associations have a FK in both tables. The MANY side has PK to the other table. May-to-many. Additional lookup table. Generalization handled most gracefully with view joins. Composition associations are generally merged into one table for the main class. Aggregation associations have separate tables for the two classes. Reflexive association. Additional lookup table. Surrogate or Programming keys are best as PKs due to size and performance considerations. Shouldn't use an incrementing counter for keys. I don't understand why. Instead, use some randomness. See Reed's shitty example on p. 299. VALUE CLASSES consist of just atts and the getters and setters. These are passed to/from DAOs. Open Source TOOLS. Main contendors are MagicDraw and Poseidon. "Community Editions" are for non-commercial use. The Gentleware site (Poseidon) web site is usually down. $250 for Standard Edition. Need Professional Edition $875 for Eclipse integration. MagicDraw. $150 for Personal Edition. Community only writes Class diags. Need Standard Edition $500 for Eclipse integration. SDE (http://www.visual-paradigm.com/product/sde) Community/Personal/Modeler/Standard $0/$59/$99/$299. Eclipse plugins. UML Tool for Eclipse (SDE for Eclipse) Omondo's EclipseUML Free Edition UMLet