I Unit

OOAD
Introduction to OOAD What is OOAD? What is UML? What are the United process(UP) phases - Case study the NextGen POS system, Inception -Use case Modeling - Relating Use cases include, extend and generalization.

Introduction to OOAD: What to do you mean by analysis and design? - Process of determining what needs to be done before - how it should be done? - developer refers the existing system and documents

Design: Process of adapting the one among the many,--> best accomblishes the user needs What are all the steps involved in designing? - Before getting the design the designer should go through the SRS prepared by the system analyst - main task of designs are 1. architectural 2. detailed Object Oriented System: - composed of objects - behaviour of the system results from collaboration of those objects - sending message to each other

What is OOAD? - empasize the considering a problem domain and provide logical solution from the perspective of objects(things,concepts or entities) Object oriented analysis - empasize on finding & describing the objects or concepts in the problem domain( use set of use cases, class diagram & number of interaction diagram) - OOA is requirement analysis activity Ex: LIS: some of the concepts include Book,Library and rack - purpose of develop a model satisfy set of customer defined statements

Object oriented Design: - empasize on defining logical software objects(class) that will ultimately be implemented in an Object Oriented Programming language Ex: in the library system, a book s/w object may have title attributes & a print method Book S/W object name book_no issue() locate()

Analysis Vs Design Analysis: * arrive the description of the problem * arrive at the requirements * what the problem is about and what a system must do Design: * arrive at detailed description of the logical solution * how the logical solution filfills requirements and constraints * design can be implemented in s/w & h/w

Summary: - The essence of OOAD is to empasize considering a problem domain and provide logical solution from the perspective of objects( things,concepts or entities)
Analysis

Design

Construction

Investigation of the problem

Logical Solution

Code

WHAT IS OOAD? - is a software engineering approach that models a system as a group of interacting objects. - Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. - Various models can be created to show the static structure, dynamic behavior, and runtime deployment of these collaborating objects constraints - There are a number of different notations for representing these models, such as the Unified Modeling Language (UML).

WHAT IS OOAD? - OOA: applies object-modeling techniques to analyze the functional requirements for a system - OOD : elaborates the analysis models to produce implementation specifications - OOA : focuses on what the system does - OOD: how the system does it

WHAT IS UML? - The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems 3 ways to apply UML 1. UML as Sketch : informal and incomplete diagram (WB) 2. UML as blueprint : detailed design diagram used 1. existing code in UML diagram 2. code generation 3. UML as programming language : Executable code will be automatically generated, but is not normally seen or modified by developers

Three Perspective to apply UML - Conceptual Perspective: diagrams are interpreted describing things - Specification Perspective: diagram descriptive s/w abstraction - Implementation Perspective: diagram descriptive s/w implements in a particular technology

What is Unified Process S/w Development process: describe an approach to building,deploying,maintanace- iteration process UP: building object oriented System 1. Inception 2. Elaboration 3. Construction 4. Transition Inception: bussiness case for project * establish project scope & boundary condition * Out line the use case & key requirement * Outline one or more candidate architecture

* Identify risks * prepare & priliminary project schedule and cost estimate 2. Elaboration phase: * project team expected to capture a healthy majority of the system requirements * create use case, conceptual diagram( class with only basic notation) & package diagram (architectural design) * final estimation phase to deliver is a plan(including last and schedule estimates) 3. Construction: * iteration results in the executable release to a s/w * Activity, Sequence, Colaboration , state and interaction

NextGen point-of-sale (POS) system.

The Case study allows us to concentrate on learning fundamental OOA/D, requirements analysis, UML and patterns 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 - they must still be capable of capturing sales and handling at least cash payments. A POS system increasingly must support multiple and varied client-side terminals and interfaces

Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical nonfunctional requirement, creation of a business case, and preparation of the development environment. Inception in one sentence: Envision the product scope, vision, and business case How long is inception? The intent of inception is to establish some initial common vision for the objective of the project It may include the first requirement workshop, Planning for the first iteration and then quickly moving forward to elaboration. What Artifacts may start in Inception? 1. Vision and Business Case : Describes the high-level goals and constraints, the business case

2.Use-Case Model : Describes the functional requirements most use cases will be identified, and perhaps 10% of the use cases will be analyzed in detail 3.Supplementary Specification: Describes other requirements, mostly nonfunctional 4.Glossary : Key domain terminology, and data dictionary 5.Risk List & Risk Management Plan: business, technical,ressource, and schedule and ideas for their response. 6.Prototypes and proof-of-concepts: validate technical ideas 7.Iteration Plan: Describes what to do in the first elaboration iteration. 8.Phase Plan & Software Development Plan:Low-precision guess for elaboration phase duration and effort 9.Development Case:Description of the customized UP steps

The purpose of inception is to collect just enough information to establish a common vision, decide if moving forward is feasible, and if the project is worth serious investigation in the elaboration phase. USE CASE MODELINGS Discrete unit of interaction between a user and the system. Example: such as Create Account or View Account Details Use cases are requirements primarily functional or behavioral requirements that indicate what the system will do. Use case defines a contract of how a system will behave Why use cases? requirement to themselves write use cases It emphasize the user goals and perspective Strength of use case is functionality to be built in the proposed system

A Use Case description will generally includes: Requirements:Use case perform some actions Constraints: limitations a Use Case operates under, defining what can and cannot be done These include 1.Pre-conditions: in place before the use case is run for example, <create order> must precede <modify order> 2.Post-conditions that must be true once the Use Case is complete For ex, <order is modified and consistent> 3. Invariants that must always be true throughout the time the Use Case operates For ex, an order must always have a customer number 4. Scenorios: Textual representation of the Sequence Diagram 5. Scenario diagrams - Sequence diagrams to depict the workflow 6. Additional attributes, such as implementation phase, version number etc..

Use Case's functionality or extend another Use Case with its own behavior.

Actors human or machine entities that use or interact with the system to perform a piece of meaningful work

three kinds of external actors * Primary actor has user goals. Example: the cashier. * Supporting actor provides a service (for example, information). * Offstage actor has an interest in the behavior of the use case Example: a government tax agency. Use cases can be written in different formats and levels of formality: 1.Brief:one-paragraph summary 2.casual:Multiple paragraphs that cover various scenarios 3.fully dressed: All steps and variations are written in detail

Fully dressed Use case: Example Process Sale use cases show more detail and are structured Use Case Section 1.Use Case Name 2.Scope 3.Level 4.Primary Actor 5.Stakeholders and Interests 6.Preconditions 7.Success Guarantee 8.Main Success Scenario 9.Extensions Comment Start with a verb. The system under design "user-goal" or "subfunction Calls on the system to deliver its services. what do they want? What must be true on start What must be true on successful completion unconditional path scenario of success scenarios of success or failure

Use Case Section 10.Special Requirements 11.Technology and Data Variations List 12.Frequency of Occurrence 13.Miscellaneous What does the Section mean?

Comment Related non-functional requirements. Varying I/O methods and data formats investigation, testing, and timing of Implementation. Such as open issues

Scope: The scope bounds the system under design Level: use cases are classified as at the user-goal level or the sub function level EX - Level: user goal Primary Actor: The principal actor that calls upon system services to fulfill a goal EX - Primary Actor: Cashier

Stakeholders and Interests List Important: It suggests and bounds what the system must do. EX - Stakeholders and Interests: Cashier: Wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from his/her salary Salesperson: Wants sales commissions updated. Preconditions: state what must always be true before a scenario is begun in the use case EX - Preconditions: Cashier is identified and authenticated. Main Success Scenario and Steps: Basic Flow" or "Typical Flow." that satisfies the interests of the stakeholders. EX - Main Success Scenario:

1. Customer arrives at a POS checkout with items to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. Cashier repeats steps 3-4 until indicates done. 5. Extensions: indicate all the other scenarios or branches, both success and failure 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 1. Cashier can enter item category identifier and the quantity. Special Requirements: non-functional requirement -Touch screen UI on a large flat panel monitor -Credit authorization response within 30 seconds -Language internationalization on the text displayed.

Technology and Data Variations List: how something must be done - record this in the use case example is a technical constraint imposed by a stakeholder regarding input or output Technologies The POS system must support credit account input using a card reader and the keyboard EX - Technology and Data Variations List: 3a. Item identifier entered by laser scanner or keyboard. 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. 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.

Relating Use cases include, extend and generalization Include Relationship:It is common to have some partial behavior(use case) This is simply refactoring and linking text to avoid duplication Example: UC1 Process Sale Main Success Scenario: 1.Customer arrives at a POS checkout with goods and/or services to purchase. 7.Customer pays and System handles payment. Extensions: 7b. Paying by credit: Include Handle Credit Payment. 7c. Paying by check: Include Handle Check Payment.

Using include with Asynchronous Event Handling: when a user is able to, at any time, select or branch to a particular function The basic notation is to use the a*, b*, ... Example - UC1: Process FooBars Main Success Scenario: 1. Extensions: a*. At any time, Customer selects to edit personal information: Edit Personal Information b*. At any time, Customer selects printing help: Present Printing Help Terminology: Concrete use case: entire behavior desired by the actor Example -Process Sale is a concrete use case. Abstract use case:it is a subfunction use case that is part of another use case(never instantiated) Ex: Handle Credit payment

Base use case: A use case that includes another use case, or that is extended or specialized by another use case is called a base use case Example : Process Sale Addition use case: The use case that is an inclusion, extension, or specialization is called an addition use case. Example - Handle Credit Payment Addition use cases are usually abstract. Base use cases are usually concrete. Extend Relationship: Suppose a use case's text should not be modified Example Handle Gift Certificate Payment Trigger: Customer wants to pay with gift certificate. Extension Points: Payment in Process Sale. Level: Sub-function Main Success Scenario: 1. Customer gives gift certificate to Cashier. 2. Cashier enters gift certificate ID.

Generalization Relationship: superclass Payment represents a more general concept, and the subclasses more specialized Ones.

End