Object-Oriented Functional Analysis and Design for POS Example

Size: px

Start display at page:

Download "Object-Oriented Functional Analysis and Design for POS Example"

Lynne Andrews
5 years ago
Views:

1 Object-Oriented Functional Analysis and Design for POS Example

2 Focus in Analysis, Design, Implementation Analysis Investigation to the problem in problem domain Design Logical solution(model) for implementation in computer domain Analysis Design Construction Investigation of the problem Logical solution Code

3 Functional AD Process & Artifacts 1) Function Requirement Capture 2) Analysis Define use cases Define conceptual model 2) Behavior Design 4) Static Design Define collaboration diagrams Define design class diagrams Analysis Artifact Use cases Conceptual Model System sequence diagrams Contracts Questions Answered What are the domain processes? What are the concepts, terms? What are the system events and operations? What do the system operations do?

4 POS Example

5 Function Requirements Capture

6 Use Case Diagram (Functional Req.)

7 Process Steps for the Point-of-Sale System Expanded Use Cases: Buy Items with Cash Use Case: Buy Items Section: Main Use case : Actors : Purpose : Overview : Type : Cross References : Buy Items Customer(initiator), Cashier Capture a sale its payment. A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a payment, which may be authorized. On completion, the Customer leaves with the items. Primary and essential Functions: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1, R2.2, R2.3, R2.4 Use Cases : Cashier must have completed the Log In use case.

8 Expanded Use Cases: Buy Items with Cash Typical Course of Events Actor Action 1. This use case begins when a Customer arrives at the POST check-out with items to purchase 2. The Cashier records each item. 4. On completion of item entry, the Cashier indicates to the POST that item entry is complete. 6. The Cashier tells the Customer the total System Response 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are presented. 5. Calculates and presents the sale total.

9 Identifying Use Cases One method used to identify use cases is actor-based. 1. Identify the actors related to a system or organization 2. For each actor, identify the processes they initiate or participate in. A second method to identify use cases is event-based. 1. Identify the external events that a system must respond to. 2. Relate the events to actors and use cases.

10 Functional Requirements Sale Functions Ref# Function Category R1.1 Record the underway(current)sale the evident items purchased R1.2 Calculate current sale total, including tax evident and coupon calculations. R1.3 Capture purchase item information from evident a bar code using a bar code scanner, or manual entry of a porduct code, such as a universal product code(upc) R1.4 Reduce inventory quantities when a sale hidden is comitted R1.5 Log completed sales hidden R1.6 Cashing must log in with an ID and Evident password in order to use the system R1.7 Provide a persistent storage mechanism. Hidden R1.8 Provide inter-process and inter-system Hidden communication mechanisms. R1.9 Display description and price of item recorded. evident

11 Function Model Analysis

12 Conceptual Model A conceptual model is a representation of concepts in a problem domain. It may show : - concepts - associations between concepts - attributes of concepts

13 Strategies to Identify Concepts Finding Concepts with Noun Phrase identification - A useful technique is to identify the noun and noun phrases in textual descriptions of a problem domain, and consider them as candidate concepts or attributes - Care must be applied with this method; a mechanical noun-to-concept mapping isn t possible, and words in natural languages are ambiguous(especially English)

14 Strategies to Identify Concepts Finding Concepts with the Concept Category List Concept Category Physical or tangible objects Specifications, designs, or descriptions of things places transaction Transaction line items Role of peopel Containers of other things Things in a container Other computer or electromechanical systems external to our system POST, Airplane Examples ProductSpecification FlightDescription Stores, Airport Sale, Payment, Reservation SaleLineItem Cashier, Pilot Store, Bin, Airplane Item, Passenger CreditCardAuthorizationSystem AirTrafficControl

15 Strategies to Identify Concepts Concept Category Abstract noun concepts Organizations Events Process(often not represented as a concept, but may be) Rules and policies Catalogs Records of finance, work, contracts, legal maters Financial instruments and services Manuals, books Examples Hunger, Acrophobia SalesDepartment, ObjectAirline Sale, Robbery, Meeting, Flight, Crash, Landing SellingAProduct, BookingASeat RefundPolicy, CancellationPolicy ProductCatalog, PartsCatalog Receipt, Ledger, EmploymentContract, MaintenanceLog LineOfCredit, Stock EmployeeManual, RepairManual

16 Strategies to Identify Concepts Example - the Buy Items Actor Action 1. This use case begins when a Customer arrives at the POST check-out with items to purchase 2. The Cashier records the universal product code(upc) from each item If there is more than one of the same item, the Cashier can enter the quantity as well System Response 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are displayed

17 Conceptual Modeling Guidelines How to Make a Conceptual Model : apply the following steps to create a conceptual model. 1. List the candidate concepts using the Concept Category List and noun phrase identification related to the current requirements under cosideration 2. Draw them in a conceptual model. 3. Add the associations necessary to record relationships for which there is a need to preserve some memory ( discussed in a subsequent chapter) 4. Add the attributes necessary to fulfill the information requirements ( discussed in a subsequent chapter)

18 Conceptual Modeling Guidelines On Naming and Modeling Things : The Mapmaker - the mapmaker strategy applies to the spirit of how a cartographer or mapmaker works: Exclude irrelevant features Use the existing names in the territory Do not add things that are not there - A conceptual model is a kind of map of concepts or things in a domain. This spirit emphasizes the analytical role of a conceptual model, and suggests the following Mapmakers uses the names of the territory - they do not change the names of cities on a map. For conceptual model, this means to use the vocabulary of the domain when naming concepts and attributes.

19 Concepts with Attributes

20 Finding Associations Common Associations List Category A is a physical part of B A is a logical part of B A is physically contained in/on B A is logically contained in B A is a description for B A is a line item of a transaction or report B A is known/logged/recorded/reported/ captured in B Examples Drawer-POST, Wing-Airplane SalesLineItem - Sale FlightLeg FlightRoute POST Store, Item Shelf Passenger Airplane ItemDescription Catalog Flight FlightSchedule ItemDescription Item FlighDescription Flight SalesLineItem Sale MaintenanceJob MaintenanceLog Sale POST Reservation FlightManifest

21 Finding Associations Common Associations List Category Examples A is a member of B Cashier Store Pilot Airline A is an organizational subunit of B Department Store Maintenance Airline A uses or manages B Cashier POST Pilot Airplane A communicates with B Customer Cashier ReservationAgent Passenger A is related to a transcation B Customer Payment Passenger Ticket

22 Finding Associations Common Associations List Category A is a transaction related to another transaction B A is next to B A is owned by B Examples Payment Sale Reservation Cancellation POST POST City City POST Store Plane Airline

23 Association Guidelines Association Guidelines: Focus on those associations for which knowledge of the relationship needs to be preserved for some duration( need-to-know associations) It is more important to identify concepts than to identify associations. Too many associations tend to confuse a conceptual model rather than illuminate it. Their discovery can be time-consuming, with marginal benefit. Avoid showing redundant or derivable associations.

24 POS Conceptual Model

25 Function Model Design

26 System Behavior: System Interaction Diagrams A system sequence diagram illustrates events from actors to systems. System Behavior : System behavior is a description of what a system does, without explaining how it does it. System Interaction Diagrams : A system interaction diagram is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events. A system interaction diagram should be done for the typical course of events of the use case, and possibly others, fot the most interesting alternative courses

27 How to Make a System Interaction Diagram To make system interaction diagrams for the typical course of events for a use case: Draw a line representing the system as a black box. Identify each actor that directly operates on the system. Draw a line for each such actor. From the use case typical course of events text, identify the system (external)events that each actor generates. Illustrate them on the diagram. Optionally, include the use case text to the left of the diagram.

28 Identifying the system (external) events

29 System Behavior: Contracts Contracts a contract is a document that describes what an operation commits to archive. It is usually declarative in style, emphasizing what will happen, rather than how it will be achieved A system operation contracts describes changes in the state of the overall system when a system operation is invoked.

30 Example contract - enteritem Name: Responsibilit ies: Type: Cross References: Notes: Exceptions: Output: Preconditions: Postconditions: Contract EnterItem(upc: number, quantity: intege) Enter (record) sale of an item and add it to the sale. Display the item description and price. System System Functions: R1.1, R1.3, R1.9 Use Cases: Buy Items Use superfast database access. If the UPC is not valid, indicate that it was an error. UPC is known to the system 다음

31 Postconditions: If a new sale, a Sale was created(instance creation) If a new sale, the new Sale was associated with the POST (association formed) A SalesLineItem was created(instance creation) The SalesLineItem was associated with the Sale(association formed) SalesLineItem.quantity was set to quantity(attribute modification) The SalesLineItem was associated with a ProductSpecfication, based on UPC match(association formed)

32 Name: Responsibilities: Type: Cross References: Notes: Exceptions: Output: Pre-conditions: Post-conditions: Contract Name of operation, and parameters An informal description of the responsibilities this operation must fulfill. Name of type(concept, software class, interface) System function reference numbers, use cases, etc. Design notes, algorithms, and so on. Exceptional cases. Non-UI outputs, such as messages or records that are sent outside of the system. Assumptions about the state of the system before execution of the operation. The state of the system after completion of the operation. Discussed in detail in a following section.

33 How to Make A Contract To make contracts for each use case: 1. Identify the system operations from the system sequence diagrams. 2. For each system operation, construct an contract. 3. Start by wirting the Responsibilities section, informally describing the purpose of the operation. 4. Then complete the Post-conditions section, declaratively describing the state changes that occur to objects in the conceptual model. 5. To describe the post-conditions, use the following categories: Instance creation and deletion. Attribute modification Associations formed and broken

34 Contracts and other Artifacts the use cases suggests the system sequencs diagrams. The system operations can then be identified. The effect of the system operations is described in contracts.

35 Interaction Diagrams The contracts do not show a solution of how software objects are going to fulfill the post-conditions. The UML includes interaction diagrams to illustrate how objects interact via message to fullfill tasks. Interaction Diagrams illustrates the message interactions between instances ( and classes ) in the class model. Collaboration diagrams Object interactions in a graph or network format

36 How to Make Collaboration Diagrams 1. Create a seprate diagram for each system operation under development in the current development in the current development cycle. -For each system operation message,make a diagram with it as the starting message. 2. If the diagram gets complex(for example, does not easily fit on an 8.5 x 11 sheet of paper), spilt it into smaller diagrams. 3. Using the operation contract responsibilities and post-conditions, and use case description as a starting point, design a system of interacting objects to fullfill the tasks. Apply the GRASP and other patterns to develop a good design

37 Collaboration Diagrams and other Artifacts

38 Conceptual Diagram Payment SaleLineItems Sale Casher Post Casher Items Store Product Spec. Product Catalog /Inventory

39 Collaboration Diagram: enteritem :POST SALE :Product Catalog SalelineItem :Product Specs SalelineItem

40 Collaboration Diagram: enteritem Pattern Pattern Pattern

41 SW Development Process Define use cases Define conceptual model Define collaboration diagrams Define design class diagrams Analysis Artifact Use cases Conceptual Model System sequence diagrams Contracts Questions Answered What are the domain processes? What are the concepts, terms? What are the system events and operations? What do the system operations do?

42 Class Diagram

SW Modeling Requirement Capture A System ( 문제 ) The overall thing that is being developed 모델링 ( 분석 / 설계 ) A Model An abstraction of a system from a particular perspective 구현 개발 A Software (

43 SW Modeling Requirement Capture A System ( 문제 ) The overall thing that is being developed 모델링 ( 분석 / 설계 ) A Model An abstraction of a system from a particular perspective 구현 개발 A Software ( 솔루션 ) An implementation of a model Use Cases Problem Analysis Conceptual Model Solution Design Collaboration Diagram Class Diagram Implementation Design Component Diagram Deployment Diagram 43

44 SW Modeling in UML Requirements UML Diagram 관련산출물또는자원 Use Case Description User Interface Object Diagram Concept Class Diagram Interaction Diagram Class Diagram (Object Diagram) Relational Data Model Physical Data Models Implementation Code Relational Database Object Database Business Use Cases Use Cases Diagram Sequence Diagram Collaboration Diagram Implementation Diagram Component Diagram Activity Diagram CRC Cards State Diagram Deployment Diagram

45 Thank You!

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D Today s Objectives To explain the basic concepts of OO(A)D To describe some best practices regarding to OO(A)D What is NOT UML? The UML