軟件需求分析課件：Chap 4-Iteration1-OOA

1、Elaboration Iteration 1-OOACh8. Iteration 1BasicsCh9. Domain ModelsCh10.System Sequence DiagramsCh11. Operation Contracts1Chapter 8. Iteration 1BasicsObjectivesDefine the first iteration in the elaboration phase.Motivate the following chapters in this section.Describe key inception and elaboration p

2、hase concepts.2Iteration 1 Requirements and EmphasisCore OOA/D SkillsNextGen POSImplement a basic, key scenario of the Process Sale use case: entering items and receiving a cash paymentImplement a Start Up use case as necessary to support the initialization needs of the iterationNothing fancy or com

3、plex is handled, just a simple happy path scenario, and the design and implementation to support itThere is no collaboration with external services, such as a tax calculator or product databaseNo complex pricing rules are applied3In Iterative Development We Dont Implement All the Requirements at Onc

4、eSubsets of the complete requirements or use casesa simplified version of the complete Process Sale use case- one simple cash-only scenariokey understanding in iterative lifecycle methodsstart production-quality programming and testing for a subset of the requirementsstart that development before al

5、l the requirements analysis is complete4Incremental Development for the Same Use Case Across Iterations5Process: Inception and ElaborationWhat Happened in Inception?Inception is a short step to elaboration It determined basic feasibility, risk, and scope, to decide if the project is worth more serio

6、us investigation On to ElaborationElaboration is the initial series of iterationsthe core, risky software architecture is programmed and testedthe majority of requirements are discovered and stabilizedthe major risks are mitigated or retired6Rank requirements as:High (score high on all rankings; har

7、d to add late)Medium (affects security domain)Lowby: Risk (includes both technical complexity and other factors, such as uncertainty of effort and usability)Coverage (all major parts of the system are tackled in early iterations)Criticality (refers to functions the client considers of high business

8、value)Ranking is done before each iterationProcess: Planning the Next Iteration7Chapter 9. Domain ModelsObjectivesIdentify conceptual classes related to the current iterationCreate an initial domain modelModel appropriate attributes and associations81. What is a Domain Model?OO software system consi

9、sts of a group of software objects Where to find these objects for a specific software system? Domain model illustrates meaningful conceptual classes in the problem domain is a source of inspiration for design software objects gives a conceptual visualisation of the problem, it shows:domain objects

10、or conceptual classesassociations between conceptual classesattributes of conceptual classesIdentifying a rich set of conceptual classes is at the heart of OO analysis9A Domain Model Example10Sample UP artifact influence11A domain model does not represent software classesSoftware artifacts, such as

11、a window or a databaseResponsibilities or methodsDomain Models Are Not Models of Software Components 12Domain models are a stepping step to designFrom Analysis to Design13Given the current requirements under consideration:Find the conceptual classes.Draw them as classes in a UML class diagram.Add as

12、sociations and attributes.2. How to create a Domain Model?14Three main strategiesReuse or modify existing models! (do this as much as possible! Analysis Pattern)Think hard and use a category listIdentify noun phrases in requirementsAll 3 strategies should be used initially even if that leads to much

13、 overlappingit should not take too long anywaybest way to arrive at a rich set of conceptual classesHow to Find Conceptual Classes?15 Using a Category ListConceptual Class CategoryExamplesbusiness transactionsGuideline: These are critical (they involve money), so start with transactions.Sale, Paymen

14、tReservationtransaction line itemsGuideline: Transactions often come with related line items, so consider these next.SalesLineItemproduct or service related to a transaction or transaction line itemGuideline: Transactions are for something (a product or service).ItemFlight, Seat, Mealwhere is the tr

15、ansaction recorded?Guideline: Important.Register, Ledgerroles of people or organizations related to the transaction; actors in the use caseGuideline: We usually need to know about the parties involved in a transaction.Cashier, Customer, Store MonopolyPlayer Passenger, Airline16Conceptual Class Categ

16、oryExamplesplace of transaction; place of serviceStoreAirport, Plane, Seatnoteworthy events, often with a time or place we need to rememberSale, Payment MonopolyGame Flightphysical objectsGuideline: This is especially relevant when creating device-control software, or simulations.Item, Register Boar

17、d, Piece, Die Airplanedescriptions of thingsProductDescriptionFlightDescriptioncatalogsGuideline: Descriptions are often in a catalog.ProductCatalogFlightCatalogcontainers of things (physical or information)Store, Bin Board Airplanethings in a containerItem Square (in a Board) Passengerother collabo

18、rating systemsCreditAuthorizationSystemAirTrafficControlContinued 17Conceptual Class CategoryExamplesrecords of finance, work, contracts, legal mattersReceipt, LedgerMaintenanceLogfinancial instrumentsCash, Check, LineOfCreditTicketCreditschedules, manuals, documents that are regularly referred to i

19、n order to perform workDailyPriceChangeListRepairScheduleContinued 18Linguistic analysis Requirements must be read very closely (especially fully-dressed use cases) and nouns or sequences of nouns identified:This yields candidate conceptual classes.Natural language is imprecise and ambiguous, so you

20、 need to use judgmentExample from the Process Sale fully dressed use case (see previous separate document): note that we restrict ourselves to current requirements (e.g. cash payment only)Using a Noun Phrases Identification19Main Success Scenario (or Basic Flow):1.Customer arrives at POS checkout wi

21、th goods and/or services to purchase.2.Cashier starts a new sale.3.Cashier enters item identifier.4.System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules.Cashier repeats steps 3-4 until indicates done.5.System presents total

22、 with taxes calculated.6.Cashier tells Customer the total, and asks for payment.7.Customer pays and System handles payment.8.System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory)

23、.9.System presents receipt10.Customer leaves with receipt and goods (if any).20Extensions (or Alternative Flows): 7a. Paying by cash:Cashier enters the cash amount tendered.System presents the balance due, and releases the cash drawer.Cashier deposits cash tendered and returns balance in cash to Cus

24、tomer.System records the cash payment Using these approaches we end up with candidate conceptual classes:Some will be outside the current requirements (e.g. price rules);Some will be redundant (e.g. goods is better described by item);Some will be attributes of concepts rather than concepts themselve

25、s (e.g. price);21There is no correct list of conceptual classes! Initial POS Domain ModelPOS Conceptual Classes22 1） should Receipt be a conceptual class?A receipt is certainly noteworthy (allows refunds）：FORAll the information (? Sure ? E.g. receipt number; or should that be Sale number?) on the re

26、ceipt is however derived from other conceptual classes (from Sale) : AGAINST;Returns are not being considering in this iteration : AGAINST;So we wont include it now: it may be needed when considering the Handle Returns use case (Make a note to that effect)23Representing something as an attribute whe

27、n it should be a conceptGuideline: if something is not a number or a string then it is probably a conceptual class, not an attribute.StorephoneNumberSaleSalestoreOr 2) A Common mistake in a domain modelAirportnameFlightFlightdestinationOr 24Think about description classes when creating an initial li

28、st of conceptual classes (or during refactoring):A description class contains information that describes something else 3) When to Model with Description Classes 25Add a description class (for example, ProductDescription) when:There needs to be a description about an item or service, independent of

29、the current existence of any examples of those items or services.Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.It reduces redundant or duplicated information.26Another

30、 example:Descriptions in the Airline Domain27Some conceptual classes will be missed at this stage : aim at a good initial domain, not perfection.Use terminology (e.g. names of concepts, descriptions of use cases) that make sense in the application context.We can also model un-real world problems: E.

31、g. in a telecommunication domain: Message, Connection, Port, Dialog, Route, Protocol would be candidate conceptual classes.Discussion283. AssociationsAn association is a relationship between classes that indicate some meaningful and interesting relationshipCriteria for Useful Associations Associatio

32、ns for which knowledge of the relationship needs to be preserved for some duration (“need-to-know” association) SalesLineItem instances are associated with a Sale ?a Cashier has looked-up a particular ProductDescription ?Associations derived from the Common Association List29The UML Association Nota

33、tion30Based on a ClassName-VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful.Naming Associations31Each end of an association is called a role. Roles may optionally have:multiplicity expressionname (to clarify meaning)navigability (not relevant durin

34、g OOA)The multiplicity defines how many instances of a class A can be associated with one instance of a class B3233The multiplicity value communicates how many instances can be validly associated with another, at a particular moment, rather than over a span of timeA Car Stocked-by one DealerAdding m

35、ultiplicity values to the roles of an association helps exploring the problem domain.Two classes may have multiple associations between them in a UML class diagram; this is not uncommon:34Two main ways:what need to know associations are necessary given our current list of candidate concepts?Using a

36、list of association categories.Association CategoryExamplesA is a transaction related to another transaction BCashPayment-SaleCancellation-ReservationA is a line item of a transaction BSalesLineItem-SaleA is a product or service for a transaction (or line item) BItem-SalesLineItemFlight-ReservationA

37、 is a role related to a transaction BCustomer-PaymentPassenger-TicketA is a physical or logical part of BDrawer-RegisterSquare-BoardSeat-Airplane35How to Find Associations?Continued Association CategoryExamplesA is physically or logically contained in/on BRegister-StoreItem-ShelfSquare-BoardPassenge

38、r-AirplaneA is a description for BProductDescription-ItemFlightDescription-FlightA is known/logged/recorded/reported/captured in BSale-RegisterPiece-SquareA is a member of BCashier-StorePlayer-MonopolyGamePilot-AirlineA is an organizational subunit of BDepartmentStoreMaintenanceAirline36Continued As

39、sociation CategoryExamplesA uses or manages or owns BCashier-RegisterPlayer-PiecePilot-AirplaneA is next to BSalesLineItem-SalesLineItemSquare-SquareCity-City37Partial POS Domain Model384. AttributesAn attribute is a logical data values of an objectInclude attributes that the requirements (for examp

40、le, use cases) suggest or imply a need to remember information For example, a receipt (which reports the information of a salenormally includes a date and time, the store name and address, and the cashier ID, among many other things. Therefore,Sale needs a dateTime attribute.Store needs a name and a

41、ddress.Cashier needs an ID.39The full syntax :visibility name : type multiplicity = default property-stringreadOnly is probably the most common property string for attributes. Private visibility (-) is usually implicit.Attribute multiplicity can be used to indicate the optional presence of a value,

42、or the number of objects that can fill a (collection) attribute.40UML Attribute Notation Derived Attributes An attribute that can be derived by other information.41What are Suitable Attribute in the Domain ModelFocus on Data Type Attribute in the Domain Model The attributes should be “primitive” dat

43、a types Ex. Numbers, Booleans, Date, String, Time, Character, The attributes, normally, should not be a complex domain concept Ex. Sale, Airport A common mistake is modeling a complex domain concept as an attribute 4243When to Define New Data Type ClassesRepresent what may initially be considered a

44、number or string as a new data type class in the domain model if:It is composed of separate sections.phone number, name of personThere are operations associated with it, such as parsing or validation.social security numberIt has other motional price could have a start (effective) date

45、and end dateIt is a quantity with a unit.payment amount has a unit of currencyIt is an abstraction of one or more types with some of these qualities.item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) and European Article Number (EAN)44Where to Illus

46、trate These Data Type Classes?Since ItemID is a data type, it can be shown in the attribute compartment of the class box If ItemID is a new type with its own attributes and associations, it can be shown as a conceptual class in its own box It depends what you want to emphasize in the diagram 45No At

47、tributes Representing Foreign KeysAttributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute46Modeling Attribute Quantities and Units 47Attributes in the Domain Models48NextGen POS Domain Model

48、 (with attributes) 49In iterative development, we incrementally evolve a domain model over several iterations.In each, the domain model is limited to the prior and current scenarios under consideration, rather than expanding to a big bang waterfall-style model that early on attempts to capture all p

49、ossible conceptual classes and relationships. For example, this POS iteration is limited to a simplified cash-only Process Sale scenario; therefore, a partial domain model will be created to reflect just that not more. 5. Process: Iterative and Evolutionary Domain Modelling50Domain modeling is a ver

50、y important activity in OOA. We must ensure that the model built will be able to withstand the information requirements of the current iteration.In addition, the model will grow in subsequent iterations are more requirements are examined.Identifying a rich set of conceptual classes is at the heart o

51、f OO analysisDomain Modeling is often called Business Modeling; and is both started and completed in the elaboration phase.Conclusions51Chapter 10. System Sequence DiagramsObjectivesIdentify system eventsCreate system sequence diagrams for use case scenarios5253System Sequence Diagram (SSD)The OOAD

52、challengeUCs are functional but System is OOThis is a modeling paradigm mismatchHow to make the functional-OO transitionWithout losing any reqsBeing able to demonstrate no reqs are lostEnd up with a correct, robust & flexible OO systemUltimately, every req must be an assigned responsibility for some

53、 object!5455SSDsSSDs are one of the books best ideasSSD is the key model thatLinks UCs with OO models (e.g., class & sequence)Supported by operation contracts (next chp)Establishes traceability of reqs into OO models5656SSDsA UC specifies function-alityA UC scenario is a time-ordered series of funct

54、ion calls that Actor invokes on SystemLarman calls them system operations or system eventsKey tasks areIdentify the functions in a UC scenarioTranslate them into UML function syntaxDraw a sequence diagram (easy part)Easier if you have simple, complete UCsSystem Sequence Diagram (SSD) Illustrate inpu

55、t and output events related to the system under discussion The use case text and its implied system events are input to SSD creation SSD is used to describe a particular scenario of a use case main success scenario frequent or complex alternative scenario For each system events, there is a system op

56、eration (1 to 1) The SSD operations can be analyzed in the operation contracts Detailed in the Glossary Serve as the starting point for designing collaboration objects 57SSD for a Process Sale Scenario58SSDs are derived from use cases; they show one scenario5960Process Sale UCUC: Process Sale makeNe

57、wSale()User selects new sale option (Request-invocation)System requests item identifier(Response-return) enterItem(itemID, quantity)User enters item identifier & quantitySystem records sale of item, and System displays item description, price, current totalSteps 2-5 repeated until user finished endS

58、ale()6.User selects sale finished optionSystem displays total and taxes due makePayment(amount)User enters payment informationSystem handles payment recordSale()System logs completed sale and sends sale information to Accounting System and Inventory SystemSystem generates receiptChoose event and ope

59、ration names at an abstract level61Process: Iterative and Evolutionary SSDsDont create SSDs for all scenarios, draw them only for the scenarios chosen for the next iterationSSDs are part of the Use-Case, not explicitly mentioned in the original UP Most SSDs are created during elaboration, when it is

60、 useful to identify the details of the system events to clarify what major operations the system must be designed to handle, write system operation contracts, and possibly to support estimation62Chapter 11. Operation ContractsObjectivesDefine system operations.Create contracts for system operations6