2 Requirements Phase Requirements -- should be an unambiguous description of the external behavior of the system to be builtTypical problems :Contains embedded design decisions (How vs. What).Vague (must be measurable / testable)Computer industry language (instead of user's language)Requirements are not traceable to the system developed
3 Analysis Phase Discover and understand the problem domain Object-oriented Analysisdecompose a problem by selecting relevant concepts from the vocabulary of the domain.Develop a Conceptual Modelinclude class and interaction diagrams.
4 Conceptual Modelcontains important real-world concepts and associations in the vocabulary of the problem domain: includes objects, roles, events, interactionsbecomes the foundation for the class model
5 Use Cases A purposeful user interaction with a system A narrative description of a sequence of actions required to produce something of value to an actor or organization
6 Use Cases describe functional requirements of the system give a clear description of needed system behaviorhelp customer and developer agree on what the system should doprovide a basis for performing verification tests.trace requirements to actual classes and operations in the system.set bounds on the problem space
7 High-level use cases (collected to determine the complete scope of the system) Use Case – the name is usually a business or domain process (Order a product, register for courses)Actors -- external agent (person playing a role, computer system, input/output device)Type -- primary, secondary or optionalDescription -- a short narrative description (2 - 3 sentences)
8 Setting Priorities (rank order use cases) Ranking may involve a combined score including multiple factors:Impact on the architectural designRisky, time-critical, or complex functionsNew or risky technologyRepresent line-of- business processesDirectly support increased revenue or decreased costs.Or ranking may simply classify use cases as high, medium, or lowThe most important use case is then expanded
9 Expanded Use Case (minimal technology references) Buy Items (essential description)Typical Course of Events:Actor Actions:System Response:1) This use case begins when a Customer arrives at a cashier's location with items to purchase2) The Cashier records the identifier from each item, its description and price from the sales tag. If there is more than one of the same item, the Cashier can enter the quantity3) Multiply the price by the quantity and add this to the ongoing sales transaction4) When the item entry is complete,5) Calculate the sales total6) Cashier tells the Customer the total7) Customer gives cash payment.8) Cashier records the cash received amount9) Calculate balance due the customer
10 Object Oriented Design (OOD) Phase Developer decides how the system will be implementedMany of the concepts become classesThe design phase elaborates (adds attributes and methods) to the class modelTry this techniqueModify the use case to include new system features
11 Put new system features into the use case Buy Items (system solution)Requirements:R1, R2, R3, R4, R5, R6Actor Actions:System Response:1) This Use case starts when a Customer arrives at POST with items to purchase.2) The Cashier enters UPC of each item.3) Use UPC to determine item name, price and description. The item price is added to the sales total.If there is more than one of an item, the Cashier can enter the quantity as well or re-enter the UPCShow description and price of the current item4) On completion of item entry, the Cashier indicates to the POST that item entry is complete.5) Calculate and present the sales total.6) The Cashier tells the customer the total7) The Customer chooses payment type:8) Log the completed salea. If cash, see Pay by Cash9) Update inventory levelsb. If credit, see Pay by Credit10) Generate a receiptc. If check, see Pay by Check11) The Cashier gives the receipt to the Customer12) The Customer leaves with the items purchased.
14 Plan the first Iteration Determine how much can be delivered within the first development cycleIf necessary, create a simplified use case to fit the first time-box
15 Special Considerations for the first Development Cycle Try to handle the most difficult parts of the system first.If the architecture is untested, exercise the functionality of the architecture.If there is technological risk, exercise all the significant interfaces and interactions among subsystems to assure they are compatible.
16 Architecture – describes the structure of software systems Architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces.Describe major subsystemsExternal software interfacesUser interfaceDatabase organizationData storageKey algorithmsConcurrencySecurityNetworkingPortabilityProgramming languageError handling
17 Plan Future Cycles In subsequent development cycles, add functionality to the previously delivered use case or do another use caseupdate task assignments and milestones for each cycle:RequirementsDesignUser documentationTest casesTechnical reviewsetc
18 First Cycle: Simplified Use Case Buy Items with cash (First Iteration)Actor Actions:System Response:1) This Use case starts when a Customer arrives at POST with items to purchase.2) The Cashier enters the UPC and quantity of each item.3) The item name and description is displayed. The price is added to the sales total.4) On completion of item entry, the Cashier indicates to the POST that item entry is complete.5) Presents the sales total.6) The Cashier tells the customer the sales total7) The Customer gives a cash amount equal to or greater than the sales total8) The Cashier enters the cash amount9) Calculate and display change due the customer10) Generate a receipt11) The Cashier gives the receipt and change due to the Customer12) The Customer leaves with the items purchased.
19 Make a minimum conceptual model concepts relevant to the use case being developed.A complete conceptual model would be all significant real-world concepts in the problem domain.
20 Find domain concepts in the use case Who are the actors and what are they trying to do?What “real world” objects are needed for each use case?How do the objects work together to complete each use case goal?Consult with domain expertsParse for noun and verb phrasesNouns become objects or attributesVerbs become operations or associations.Use a Concept Check List
21 Concept Check List (Craig Larman) Physical objectsSpecifications, designs or descriptions of thingsPlacesTransactionsTransaction line itemsRolesThings in a containerContainers of other thingsCatalogsEventsOrganizationsProcessesRules and policiesRecords of finance, work, contracts, legal mattersFinancial instruments and servicesManuals, booksExternal Computer Systems or devicesAbstract noun concepts
23 Decide which domain concepts become objects that implement a solution Try CRC cards to Bridge from Concepts to Classes CRC cards (Class, Responsibility, Collaboration)Original paper by Beck and Cunninghamat
24 CRC Cards Class Name -- Domain concept or programmer created class Class Name = SaleResponsibilities:Collaborators: store Item specs and quantity SalesLineItemcalculate a sales total store payment amount and typeClass Name -- Domain concept or programmer created classResponsibilities -- Tasks an object can do alone because of its local knowledgeCollaborators -- Tasks done by other objects because of their knowledge
25 Responsibility Responsibilities become class methods The method accomplishes a task by the object acting alone or with the help of others.Two Basic Responsibilities for objectsKnowingobject’s awareness of its own data, its links to other objects and knowledge it can derive or calculateDoingobjects ability to modify itself, create and link to other objects, or delete other objects and links, command other objects to take action or control or coordinate activity in other objects
26 CRC Card ProcedureCreate cards for each relevant object in the use case-- actors initiating a message to the system-- the first object that receives the message-- every object from the domain used in the solutionWalk through the handling of a system eventAllocate responsibilities by deciding which class handles an event or delegates it to another object-- Put the main responsibilities of each class on the card.-- Put the collaborators of each class on the card
27 Role Play the ClassA designer or member of a group can act the part of a "Class" when it is given control in a scenarioWhen role playing a class, determinewhat can you do,how are you dependent on others
28 ScenariosEach use case has a successful outcome and usually one or more failure outcomes.Failures usually are:Looking for an object which does not exist (identifier not found)Creating a new object but the identifier already exists.Violation of business rules (i.e. Customer withdraws an amount that makes the balance lower than the minimum required by the bank)Use scenarios to validate the responsibilities of each object.Events leading to failure and to success
29 Use truth tables to check for completeness Use Case ScenariosBuy Items123Pre-ConditionsUPC ExistsFTCustomer has sufficient fundsPost-Condition ActionsReject sale and provide a messageXAccept transaction