Lecture notes on Object oriented analysis and design

what is object oriented analysis and design and why do we need it and object oriented systems analysis and design using uml lecture notes, pdf free download
Dr.MasonHanks Profile Pic
Published Date:23-07-2017
Your Website URL(Optional)
Chapter 1 Introduction to Object Oriented Analysis and Design 1. Analysis and Design Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new online trading system is desired, how will it be used? What are its functions? "Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the requirements) or object-oriented analysis (an investigation of the domain objects). Design emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Design ideas often exclude low-level or "obvious" details obvious to the intended consumers. Ultimately, designs can be implemented, and the implementation (such as code) expresses the true and complete realized design. As with analysis, the term is best qualified, as in object-oriented design or database design. Useful analysis and design have been summarized in the phrase do the right thing (analysis), and do the thing right (design). 2. Object-Oriented Analysis and Design In dealing with object-oriented technology, Object-Oriented Analysis and Design is the method of choice for the software development life-cycle. It can be applied in the analysis and design phase and provides general instructions as for what has to be accomplished. In discussing Object-Oriented Analysis and Design the distinction between these two phases has to be clarified first. In the phase of OOA the typical question starts with What...? like “What will my program need to do?”, “What will the classes in my program be?” and “What will each class be responsible for?” . Hence, OOA cares about the real world and how to model this real world without getting into much detail. Larman describes in Lar02 the OOA phase as an investigation of the problem and requirements, rather than finding a solution to the problem. In contrast, in the OOD phase, the question typically starts with How...? like “How will this class handle it’s responsibilities?”, “How to ensure that this class knows all the information it needs?” and “How will classes in the design communicate?” . The OOD phase deals with finding a conceptual solution to the problem – it is about fulfilling the requirements, but not about implementing the solution During object-oriented analysis(OOA) there is an emphasis on finding and describing the objects or concepts in the problem domain. For example, in the case of the flight information system, some of the concepts include Book, Library, and Patron 1 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l During software requirement phase, requirement analysis and object analysis, it is a method of analysis that examines requirements from the perspective of classes and objects as related to problem domain. Object oriented analysis emphasizes the building of real-world model using the object oriented view of the world. During object-oriented design (OOD) (or simply, object design) there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. During user requirement phase, OOD involves understanding of the application domain and build an object model. Identify objects; it is methods of design showing process of object oriented decomposition. Object oriented design is a method of design encompassing the process of objects oriented decomposition and a notation for depicting logical and physical as well as static and dynamic models of the system under design. For example, in the library system, a Book software object may have a title attribute and a getChapter method. Fig: Object-orientation emphasizes representation of objects. Finally, during implementation or object-oriented programming, design objects are implemented, such as a Book class in Java. 3. OOP (Object oriented programming) During system implementation phase, t is a method of implementation in which programs are organized as cooperative collection of objects, each of which represents an instance of some class and whose classes are all members of a hierarchy of classes united in inheritance relationships. Object oriented programming satisfies the following requirements:  It supports objects that are data abstractions with an interface of named operations and a hidden local state.  Objects have associated type (class).  Classes may inherit attributes from supertype to subtype. 4. Analysis Vs Design 2 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l Analysis Vs Design Object Oriented Analysis Object Oriented Design Identify Decide how to implement Classes • Classes • Who am I? • State • What is the same/different? • Behavior • What do I contain? • Collaborations • Who am I associated with? Add Implementation-Specific Components Attributes • Human interaction • What do I need to know? • Data management Behaviors • Other implementation areas • What can I do? Collaborations • What help do I need? • Who needs my help? How are OOA,OOD and OOP related? The product of OOA serves as the models from which we may start an OOD , the product of OOD can then be used as blueprint for completely implementing a system using OOP methods. Object-oriented analysis, design and programming are related but distinct OOA is concerned with developing an object model of the application domain OOD is concerned with developing an object-oriented system model to implement requirements OOP is concerned with realising an OOD using an OO programming language such as Java or C++ 5. Steps/Activities for Object oriented Analysis A. Analyze the domain problem B. Describe the process of systems C. Identify the objects D. Specify attributes E. Defining operations F. Define and establish Inter-object Communication mechanism Generic Steps 1. Elicit customer requirements for the system. 2. Identify scenarios for use-cases. 3. Select classes and objects using basic requirements as a guide. 4. Identify attributes and operations for each system object. 5. Define structures and hierarchies that organize classes. 6. Build an object-behavior model. 7. Review the OO analysis model against usec ases or scenarios. A. Domain Analysis (Domain Class Diagram) –will study later B. Describe the Process of System C. Identifying objects 3 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l What are physical objects in system ? • Individuals, organizations, machines, units of information, pictures, whatever makes up application/ make sense in context of real world • Objects can be: o External Entity (e.g., other systems, devices, people) that produce or consume information to be used by system o Things (e.g., reports, displays, letters, signals) that are part of information domain for the problem o Places (e.g., book’s room) that establish the context of the problem and the overall function of the system. o Organizational units (e.g., division, group, team, department) that are relevant to an application, o Transaction (e.g., loan, take course, buy, order). Objects help establish workable system so work iteratively between use-case & object models Example of candidate objects Just a Line management wishes to increase security, both in their building and on site, without antagonizing their employees. They would also like to prevent people who are not part of the company from using the Just a Line car park. It has been decide to issue identity cards to all employees, which they are expected to wear while on the Just a Line site. The cards records the name, department and number of the member of staff, and permit access to the Just a Line car park. A barrier and a card reader are placed at the entrance to the car park. The driver of an approaching car insert his or her numbered card in the card reader, which then checks that the card number is known to the Just a Line system. If the card is recognized, the reader sends a signal to raise the barrier and the car is able to enter the car park. At the exit, there is also a barrier, which is raised when a car wishes to leave the car park. When there are no spaces in the car park a sign at the entrance display “Full” and is only switched off when a car leaves. Special visitor’s cards, which record a number and the current date, also permit access to the car park. Visitor’s cards may be sent out in advance, or collected from reception. All visitor’s cards must be returned to reception when the visitor leaves Just a Line. Candidate objects in given case are: 4 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l Candidate objects’ rejection rule • Duplicates: if two or more objects are simply different names for the same thing. • Irrelevant: objects which exists in the problem domain, but which are not intended. • Vague: when considering words carefully it sometimes becomes clear that they do not have a price meaning and cannot be the basis of a useful in the system. • General: the meaning is too broad. • Attributes: as the attribute of objects.p • Associations: actually represents the relationships between objects. • Roles: sometimes objects referred to by the role they play in a particular part of the system. Rejected Candidate objects Final Objects D. Define class Attributes and Operations 5 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l E. Define Objects Relationship F. Object behaviour modelling(defining inter object communication) • A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case • Sequence diagrams (or collaboration diagrams) in the UML are used to model interaction between objects 6 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l 6. Object Oriented Analysis Approaches (Complementary Analysis Approaches) A number of additional activities can be used which are complimentary to object-oriented analysis and design methodologies. A. Domain Analysis. • Identify classes which are common to all applications in this domain. • Domain analysis seeks to identify the classes and objects that are common to all applications of a given domain. o For example: all accounting systems have certain classes in common. • Domain analysis works well, because there are very few truly unique kinds of software systems. • Try to compare the system you are developing to a generalized class of systems. When starting to design a system. • Survey the architecture of existing systems in that domain. • Define key abstractions and mechanisms. • Evaluate which can be used in the new system. • A domain expert may be required to assist in this effort. B. Scenario Planning or Use-Case Analysis. • Identify operations patterns by users initiating some sequence of interrelated events. • A use case is a scenario that begins with some user of the system initiating some transaction or sequence of interrelated events. • Scenario planning of this type is employed by many other OO methodologies, including Coad/Yourdon, Jacobson, and Wirfs-Brock. • A basic scenario planning approach is introduced under human interaction in the section on design. • Basic goal is to group the primary function points of the system by related behavior or hierarchy • This technique is similar to storyboarding. Use-Case Analysis Activities 7 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l For each interesting set of function points, storyboard a scenario to identify the following. • Actors that participate. • Actors are classes or categories of users, with a specific role. • Their responsibilities. • How they collaborate with each other. Modify the scenarios as necessary. • Expand the initial scenarios to identify secondary scenarios. • Create a generalized scenario from several related scenarios. Update the list of classes, responsibilities, and behaviors that result for this effort. C. CRC Cards. • Class-Responsibility-Collaboration cards. • CRC stands for Class - Responsibility - Collaboration. • They are simple 3x5 index cards with the class name along the top and two columns below for responsibilities and collaborations. • They provide a simple tool for team development tasks, such as storyboarding. • They can be used during storyboarding sessions to keep track of the classes for each scenario. • They can be easily grouped and organized. D. Informal English. • Identify key concepts from textual description of the problem. • An alternative is to write an English language description of the problem, or part of the problem. • Take the natural language description and underline the nouns and verbs to identify candidate classes and operations, respectively. • This is by no means a rigorous approach. • Natural language is to imprecise and ambiguous. • Any noun can be verbed, and any verb can be nouned. However, since natural language is often used for system descriptions and requirements documents, it may provide some useful insight. E. Structured Analysis F. classical categorization G. Behavior Analysis 7. Object-oriented Design  OOD transforms the analysis model created using OOA into a design model that serves as a blueprint for software construction.  OOD results in a design that achieves a number of different levels of modularity.  Subsystems: Major system components.  Objects: Data and the operations.  Four important software design concepts: o Abstraction o Information Hiding o Functional Independence o Modularity  As stated earlier, analysis is the practice of studying a problem domain, leading to a specification of externally observable behavior. 8 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l  Building on this, design is the practice of taking a specification of externally observable behavior and adding details needed for actual computer system implementation.  Analysis is what or the problem phase. Design is the how or the solution phase.  OOD consists mainly of expanding the requirements model to account for the complexities introduced in selecting a particular implementation. o Human interaction. o Data management. o Other implementation areas. OOD Goal :  To design classes identified during analysis phase & user interface  Identify additional objects & classes that support implementation of requirements o E.g. add objects for user interface to system (data entry windows, browse windows)  Can be intertwined(entangled) with analysis phase o Highly incremental, e.g. can start with object-oriented analysis, model it, create object-oriented design, then do some more of each again & again, gradually refining & completing models of system  Activities & focus of OO analysis & OO design are intertwined OOD Steps:  First, build object model based on objects & relationship  Then iterate & refine model o Design & refine classes o Design & refine attributes o Design & refine methods o Design & refine structures o Design & refine associations Guidelines in OOD  Reuse rather than build new classes : Know existing classes  Design large number of simple classes rather than small number of complex classes  Design methods  Critique what has been proposed : Go back & refine classes OOD Design Strategy 1. Problem Domain Component. • The OOA results are placed here directly. Certain modifications are made base on implementation-specific criteria. 2. Human Interaction Component. • The actual displays and inputs needed for human interaction. The classes will vary somewhat depending upon the type of user interface. Example classes would include specializations of Menu, Screen, and Display. 3. Data Management Component. • Deals with the access and management of persistent data, using a flat file, relational, or object-oriented database. Generic Components for OOD 9 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l • Problem domain component—the subsystems that are responsible for implementing customer requirements directly; • Human interaction component —the subsystems that implement the user interface (this included reusable GUI subsystems); • Task Management Component—the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems; • Data management component—the subsystem that is responsible for the storage and retrieval of objects. OOA to OOD Attributes, operations, responsibilities collaborators Object- design CRC relationship model Index Cards message Use cases design Class and object design Object-Behavior Model subsystem design THE ANALYSIS MODEL THE DESIGN MODEL 10 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l 8. 0 The models of Object Oriented Development The models of object oriented analysis and design reflect the importance of explicitly capturing both the class and object hierarchies of the system under design. These models also over the spectrum of the important design decisions that we must consider in developing a complex system and so encourage us to craft implementations that embody the five attributes of well formed complex systems. Booch presents a model of object- oriented development that identifies several relevant perspectives Fig: Different types of model of OO Development The classes and objects that form the system are identified in a logical model. For this logical model, again two different perspectives have to be considered  A static perspective identifies the structure of classes and objects, their properties and the relationships classes and objects participate in.  A dynamic model identifies the dynamic behavior of classes and objects, the different valid states they can be in and the transitions between these states. Besides the logical model, also a physical model needs to be identified. This is usually done later in the system's lifecycle. The module architecture identifies how classes are kept in separately compliable modules and the process architecture identifies how objects are distributed at run-time over different operating system processes and identifies the relationships between those. Again for this physical model a static perspective is defined that considers the structure of module and process architecture and a dynamic perspective identifies process and object activation strategies and inter-process communication. Object-orientation has not, however, emerged fully formed. In fact it has developed over a long period, and continues to change.  Descriptive models written in English are often ambiguous  Mathematical models often frightens developers though it is good for safety critical system.  Graphical models can be seen by the user and other developers, e.g. UML The Importance of Model Building  The buildings of models have a broad acceptance among all engineering disciplines largely because model building appeals to the principles of decomposition, abstraction and hierarchy.  Each model within a design describes a specific aspect/ perspective of the system under consideration, when put together will provide an overall view of the system.  Models give us the opportunity to fail under controlled conditions. 11 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l  We evaluate each model under both expected and unusual situations and then after them when they fail to behave as we expect or desire. More than one kind of model is used on order to express all the subtleties of a complex system.  Creating a model for a given level of abstraction decides which elements are to be included and which are to be excluded.  The notation often takes the form of graphical symbols and connections.  Models in software help us to visualize, specify, construct and document the artifacts of a software intensive system. Business Modeling  UML is used for modeling business process.  Business models provide ways of expressing the business processes in terms of business activities and collaborative behavior.  Business modeling is a technique which will help in finding out whether we have identified all the system use cases as well as determining the business value of the system Why Business Modeling  The system can provide value only if we know how it will be used, who will use it and in what circumstances it will be used.  To ensure that customer-oriented solutions are built, we must not overlook o the environment in which these systems will work o the roles and responsibilities of the employees using the system o the "things" that are handled by the business, as a basis for building the system  great benefits of business modeling o elicit better system requirements, o requirements that will drive the creation of information systems that actually fit in the organization and that will indeed be used by end-users Key Steps of OOAD Define Use Cases Requirements analysis may include a description of related domain processes; these can be written as use cases. Use cases are not an object-oriented artifact—they are simply written stories. However, they are a popular tool in requirements analysis and are an important part of the Unified Process. For example, here is a brief version of the Play a Dice Game use case: • Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose. Define a Domain Model Object-oriented analysis is concerned with creating a description of the domain from the perspective of objects. There is an identification of the concepts, attributes, and associations that 12 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l are considered noteworthy. The result can be expressed in a domain model that shows the noteworthy domain concepts or objects. Note that a domain model is not a description of software objects; it is a visualization of the concepts or mental models of a real-world domain. Thus, it has also been called a conceptual object model. For example, a partial domain model is shown in This model illustrates the noteworthy concepts Player, Die, and DiceGame, with their associations and attributes. Fig: Partial domain model of the dice game Define Interaction Diagrams Object-oriented design is concerned with defining software objects their responsibilities and collaborations. A common notation to illustrate these collaborations is the sequence diagram (a kind of UML interaction diagram). It shows the flow of messages between software objects, and thus the invocation of methods. For example, the sequence diagram in Figure illustrates an OO software design, by sending messages to instances of the DiceGame and Die classes. Note this illustrates a common real- world way the UML is applied: by sketching on a whiteboard. Notice that although in the real world a player rolls the dice, in the software design the DiceGame object "rolls" the dice (that is, sends messages to Die objects). Software object designs and programs do take some inspiration from real- world domains, but they are not direct models or simulations Fig: Interaction diagram illustrating messages between software objects. of the real world. Define Design Class Diagrams 13 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l In addition to a dynamic view of collaborating objects shown in interaction diagrams, a static view of the class definitions is usefully shown with a design class diagram. This illustrates the attributes and methods of the classes. For example, in the dice game, an inspection of the sequence diagram leads to the partial design class diagram shown in fig below. Since a play message is sent to a DiceGame object, the DiceGame class requires a play method, while class Die requires a roll and getFaceValue method. In contrast to the domain model showing real-world classes, this diagram shows software classes. Notice that although this design class diagram is not the same as the domain model, some class names and content are similar. Fig: design class diagram. In this way, OO designs and languages can support a lower representational gap between the software components and our mental models of a domain. That improves comprehension. 9. Case Studies: In this section we will present two different types of case study, one is business transaction type problem and other is computer simulation game. A. Case One: The NextGen POS System A POS system is a computerized application used (in part) to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. It interfaces to various service applications, such as a third- party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments (so that the business is not crippled). A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and so forth. Furthermore, we are creating a commercial POS system that we will sell to different clients with disparate needs in terms of business rule processing. Each client will desire a unique set of logic to execute at certain predictable points in scenarios of using the system, such as when a new sale is initiated or when a new line item is added. Therefore, we will need a mechanism to provide this flexibility and customization. Using an iterative development strategy, we are going to proceed through requirements, object-oriented 14 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l analysis, design, and implementation. B. Case Two: The Monopoly Game System To show that the same practices of OOA/D can apply to very different problems, I've chosen a software version of the game of Monopoly® as another case study. Although the domain and requirements are not at all like a business system such as the NextGen POS, we will see that domain modeling, object design with patterns, and applying the UML are still relevant and useful. As with a POS, software versions of Monopoly are truly developed and sold, with both rich client and Web UIs. The software version of the game will run as a simulation. One person will start the game and indicate the number of simulated players, and then watch while the game runs to completion, presenting a trace of the activity during the simulated player turns. Read Rule of monopoly game from different websites 10. Use Cases OOD (and all software design) is strongly related to the prerequisite activity of requirements analysis, which often includes writing use cases. Use Case, is a name for a scenario to describe the user–computer system interaction. Use Cases are used to determine system requirements; identify classes & their relationship to other classes in domain. Use cases are text stories, widely used to discover and record requirements. They influence many aspects of a project including OOA/D and will be input to many subsequent artifacts in the case studies. Requirements analysis may include stories or scenarios of how people use the application; these can be written as use cases. Use cases are not an object-oriented artifact they are simply written stories. However, they are a popular tool in requirements analysis. For example, here is a brief version of the Play a Dice Game use case: Play a Dice Game: Player requests to roll the dice. System presents results: If the dice face value totals seven, player wins; otherwise, player loses. To understand system requirements: • Need to identify the users or actors o Who are the actors? o How do they use system? Use case is typical interaction between user & system that captures users’ goal & needs. In simple, usage, capture use case by talking to typical users, discussing various things they might want to do with system. Use cases can be used to examine who does what in interactions among objects, what role they play, intersection among objects’ role to achieve given goal is called 15 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l collaboration. Several scenarios (usual & unusual behavior, exceptions) needed to understand all aspects of collaboration & all potential actions. Use case modeling: expressing high level processes & interactions with customers in a scenario & analyzing it .It gives system uses, system responsibilities Developing use case is iterative process, when use case model better understood & developed, start identifying classes & create their relationship Use case modeling:  Helps in capturing requirements  Helps in planning iterations of development  Helps in validating systems  expressing high level processes & interactions with customers in a scenario & analyzing it  It gives system uses, system responsibilities Scenarios vs Usecase: • Great way to establish communication with client • Different types of scenarios: As-Is, visionary, evaluation and training Use cases • Abstractions of scenarios • Use cases bridge the transition between functional requirements and objects. How to write a use case • Name of Use Case • Actors • Description of Actors involved in use case • Entry condition • “This use case starts when…” • Flow of Events • Free form, informal natural language • Exit condition • “This use cases terminates when…” • Exceptions • Describe what happens if things go wrong • Special Requirements • Nonfunctional Requirements, Constraints Format of Use case Black-box versus white-box visibility type, use cases are written in varying degrees of formality: • Brief—terse one-paragraph summary, usually of the main success scenario. The prior Process Sale example was brief. 16 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l • Casual—informal paragraph format. Multiple paragraphs that cover various scenarios. The prior Handle Returns example was casual. • Fully dressed—the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. Fully Dressed use case format Various format templates re available for fully dressed use cases. However, perhaps the most widely used and shared format is the template available at www.usecases.org. The following example illustrates this style. Use Case ID: Use Case Name: Primary Actor: Stakeholders and Interests:: Preconditions: Success Guarantee(Postconditions): Main Success Scenario (or Basic Flow):: Extensions (or Alternative Flows):: Special Requirements: Technology and Data Variations List:: Frequency of Occurrence:: Open Issues Based on a real POS system’s requirements (example of use case text story) Use case ID UC1 Use case Name Process Sale Primary Actor Cashier Stakeholders and - Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short ages are deducted Interests from his/her salary. - Salesperson: Wants sales commissions updated. - Customer: Wants purchase and fast service with minimal effort. Wants proof of purchase to support returns. - Company: Wants to accurately record transactions and satisfy customer interests. Wants to ensure that Payment Authorization Service payment receivables are recorded. Wants some fault tolerance to allow sales capture even if server components (e.g., remote credit validation) are unavailable. Wants automatic and fast update of accounting and inventory. - Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies, such as national, state, and county. - Payment Authorization Service: Wants to receive digital authorization requests in the correct format and protocol. Wants to accurately account for their payables to the store. Preconditions Cashier is identified and authenticated Success Sale is saved. Tax is correctly calculated. Guarantee Accounting and Inventory are updated. Commissions recorded. Receipt is generated. (Postconditions) Payment authorization approvals are recorded. Main Success 1. Customer arrives at POS checkout with goods and/or services to purchase. Scenario (or 2. Cashier starts a new sale. Basic Flow) 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 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 17 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l Accounting system (for accounting and commissions) and Inventory system (to update inventory). 9. System presents receipt. 10. Customer leaves with receipt and goods (if any). Extensions (or a. At any time, System fails: Alternative To support recovery and correct accounting, ensure all transaction sensitive state Flows): and events can be recovered from any step of the scenario. 1. Cashier restarts System, logs in, and requests recovery of prior state. 2. System reconstructs prior state. 2a. System detects anomalies preventing recovery: 1. System signals error to the Cashier, records the error, and enters a clean state. 2. Cashier starts a new sale. 3a. Invalid identifier: 1. System signals error and rejects entry. 3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers): 1. Cashier can enter item category identifier and the quantity. 3-6a: Customer asks Cashier to remove an item from the purchase: 1. Cashier enters item identifier for removal from sale. 2. System displays updated running total. 3-6b. Customer tells Cashier to cancel sale: 1. Cashier cancels sale on System. 3-6c. Cashier suspends the sale: 1. System records sale so that it is available for retrieval on any POS terminal. 4a. The system generated item price is not wanted (e.g., Customer complained about something and is offered a lower price): 1. Cashier enters override price. 2. System presents new price. 5a. System detects failure to communicate with external tax calculation system service: 1. System restarts the service on the POS node, and continues. 1a. System detects that the service does not restart. 1. System signals error. 2. Cashier may manually calculate and enter the tax, or cancel the sale. 5b. Customer says they are eligible for a discount (e.g., employee, preferred customer): 1. Cashier signals discount request. 2. Cashier enters Customer identification. 3. System presents discount total, based on discount rules. 5c. Customer says they have credit in their account, to apply to the sale: 1. Cashier signals credit request. 2. Cashier enters Customer identification. 3. Systems applies credit up to price=0, and reduces remaining credit. 6a. Customer says they intended to pay by cash but don’t have enough cash: 1a. Customer uses an alternate payment method. 1b. Customer tells Cashier to cancel sale. Cashier cancels sale on System. 7a. Paying by cash: 1. Cashier enters the cash amount tendered. 2. System presents the balance due, and releases the cash drawer. 3. Cashier deposits cash tendered and returns balance in cash to Customer. 4. System records the cash payment. 7b. Paying by credit: 1. Customer enters their credit account information. 2. System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval. 2a. System detects failure to collaborate with external system: 1. System signals error to Cashier. 2. Cashier asks Customer for alternate payment. 3. System receives payment approval and signals approval to Cashier. 3a. System receives payment denial: 1. System signals denial to Cashier. 2. Cashier asks Customer for alternate payment. 4. System records the credit payment, which includes the payment approval. 5. System presents credit payment signature input mechanism. 6. Cashier asks Customer for a credit payment signature. Customer enters signature. 7c. Paying by check... 18 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l 7d. Paying by debit... 7e. Customer presents coupons: 1. Before handling payment, Cashier records each coupon and System reduces price as appropriate. System records the used coupons for accounting reasons. 1a. Coupon entered is not for any purchased item: 1. System signals error to Cashier. 9a. There are product rebates: 1. System presents the rebate forms and rebate receipts for each item with a rebate. 9b. Customer requests gift receipt (no prices visible): 1. Cashier requests gift receipt and System presents it. Special - Touch screen Ul on a large flat panel monitor. Text must be visible from 1 meter. Requirements: - Credit authorization response within 30 seconds 90% of the time. - Somehow, we want robust recovery when access to remote services such the inventory system is failing. - Language internationalization on the text displayed. - Pluggable business rules to be insertable at steps 3 and 7. Technology and 3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard. Data Variations 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. List: 7a. Credit account information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture. Frequency of Could be nearly continuous Occurrence: Open Issues - What are the tax law variations? - Explore the remote service recovery issue. - What customization is needed for different businesses? - Must a cashier take their cash drawer when they log out? - Can the customer directly use the card reader, or does the cashier have to do it? Example 2 19 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l A use case describes three things: • An actor (user) that initiates an event • An event that triggers a use case • The use case that performs the actions triggered by the event There are two kinds of use cases: • Primary, the standard flow of events within a system that describe a standard system behavior • Use case scenarios that describe variations of the primary use case Steps for Creating a Use Case Model The steps required to create a use case model are • Review the business specifications and identify the actors within the problem domain 20 P a g e O b j e c t O r i e n t e d A n a l y s i s a n d D e s i g n - - H a r i P r a s a d P o k h r e l

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.