ooad i unit

7/29/2019 ooad i unit

1/33

I Unit

OOADIntroduction to OOAD What is OOAD? What isUML? What are the United process(UP) phases - Casestudy the NextGen POS system, Inception -Use case

Modeling - Relating Use cases include, extend andgeneralization.


2/33

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


3/33

Design:Process of adapting the one among the many,--> bestaccomblishes the user needs

What are all the steps involved in designing?

- Before getting the design the designer should go throughthe 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


4/33

What is OOAD?

- empasize the considering a problem domain and providelogical solution from the perspective ofobjects(things,concepts or entities)

Object oriented analysis

- empasize on finding & describing the objects or conceptsin the problem domain( use set of use cases, classdiagram & number of interaction diagram)

- OOA is requirement analysis activity

Ex: LIS: some of the concepts include Book,Library andrack- purpose of develop a model satisfy set of customerdefined statements


5/33

Object oriented Design:

- empasize on defining logical software objects(class) thatwill ultimately be implemented in an Object OrientedProgramming language

Ex: in the library system, a book s/w object may have title

attributes & a print method

Book S/W objectnamebook_no

issue()locate()


6/33

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


7/33

Summary:

- The essence of OOAD is to empasize considering aproblem domain and provide logical solution from theperspective of objects( things,concepts or entities)

AnalysisConstructionDesign

Investigation ofthe

problemCodeLogical Solution


8/33

WHAT IS OOAD?

- is a software engineering approach that models a systemas a group of interacting objects.

- Each object represents some entity of interest in thesystem being modeled, and is characterized by its class,its state (data elements), and its behavior.

- Various models can be created to show the staticstructure, dynamic behavior, and runtime deployment ofthese collaborating objects constraints

- There are a number of different notations for representingthese models, such as the Unified Modeling Language(UML).


9/33

WHAT IS OOAD?

- OOA: applies object-modeling techniques to analyze thefunctional requirements for a system

- OOD : elaborates the analysis models to produceimplementation specifications

- OOA : focuses on what the system does- OOD: how the system does it


10/33

WHAT IS UML?

- The Unified Modeling Language is a visual language

for specifying, constructing and documenting theartifacts of systems

3 ways to apply UML1. UML as Sketch : informal and incomplete diagram (WB)2. UML as blueprint : detailed design diagram used

1. existing code in UML diagram 2. code generation3. UML as programming language : Executable code will

be automatically generated, but is not normally seen or

modified by developers


11/33

Three Perspective to apply UML

- Conceptual Perspective: diagrams are interpreteddescribing things

- Specification Perspective: diagram descriptive s/wabstraction

- Implementation Perspective: diagram descriptive s/wimplements in a particular technology


12/33

What is Unified Process

S/w Development process: describe an approach tobuilding,deploying,maintanace- iteration process

UP: building object oriented System1. Inception

2. Elaboration3. Construction4. Transition

Inception: bussiness case for project

* establish project scope & boundary condition* Out line the use case & key requirement* Outline one or more candidate architecture


13/33

* Identify risks* prepare & priliminary project schedule and cost estimate2. Elaboration phase:* project team expected to capture a healthy majority ofthe system requirements

* create use case, conceptual diagram( class with onlybasic notation) & package diagram (architectural design)

* final estimation phase to deliver is a plan(including lastand schedule estimates)

3. Construction:* iteration results in the executable release to a s/w

*Activity, Sequence, Colaboration , state and interaction


14/33

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 salesand handle payments; it is typically used in a retail store.

It includes hardware components such as a computer and bar code scannerand software to run the system.

It interfaces to various service applications, such as a third-party taxcalculator and inventory control.

These systems must be relatively fault-tolerant - they must still be capable ofcapturing sales and handling at least cash payments.

A POS system increasingly must support multiple and varied client-sideterminals and interfaces


15/33


16/33

Inception is the initial short step to establish a common vision and basic scope for tproject.

It will include analysis of perhaps 10% of the use cases, analysis of the criticnonfunctional requirement, creation of a business case, and preparation of t

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 objectiveof the project

It may include the first requirement workshop, Planning for the first iteration andthen quickly moving forward to elaboration.

What Artifacts may start in Inception?

1. Vision and Business Case : Describes the high-level goals and constraints, thebusiness case


17/33

2.Use-Case Model : Describes the functional requirements most use cases will beidentified, and perhaps 10% of the use cases will be analyzed in

detail

3.Supplementary Specification: Describes other requirements, mostly nonfunction

4.Glossary : Key domain terminology, and data dictionary

5.Risk List & Risk Management Plan: business, technical,ressource, and schedule aideas 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 elaborationphase duration and effort

9.Development Case:Description of the customized UP steps


18/33

The purpose of inception is to collectjust enough information to establish a commvision, decide if moving forward is feasible, and if the project is worth serioinvestigation 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 thindicate what the system will do. Use case defines a contract of how a system wbehave

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


19/33

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 include1.Pre-conditions: in place before the use case is run

for example, must precede

2.Post-conditions that must be true once the Use Case is completeFor ex,

3. Invariants that must always be true throughout the time the Use Case operatesFor ex, an ordermust always have a customer number4. 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..


20/33

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


21/33

Actorshuman or machine entities that use orinteract with the system to perform a piece ofmeaningful work

three kinds of external actors* Primary actorhas user goals. Example: the cashier.

* Supporting actorprovides a service (for example, information).

* Offstage actorhas an interest in the behavior of the use caseExample: a government tax agency.

Use cases can be written in different formats and levels of formality:1.Brief:one-paragraph summary2.casual:Multiple paragraphs that cover various scenarios3.fully dressed: All steps and variations are written in detail


22/33

Fully dressed Use case: Example Process Sale

use cases show more detail and are structured

Use Case Section Comment

1.Use Case Name Start with a verb.

2.Scope The system under design

3.Level "user-goal" or "subfunction

4.Primary Actor Calls on the system to deliver its services.

5.Stakeholders and Interests what do they want?

6.Preconditions What must be true on start

7.Success Guarantee What must be true on successful completi

8.Main Success Scenario unconditional path scenario of success

9.Extensions scenarios of success or failure


23/33

Use Case Section Comment

10.Special Requirements Related non-functional requirements.

11.Technology and Data Variations List Varying I/O methods and data formats

12.Frequency of Occurrence investigation, testing, and timing ofImplementation.

13.Miscellaneous Such as open issues

What does the Section mean?

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


24/33

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 shortagesare 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 caEX - 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:


25/33

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 notimportant

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.


26/33

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 outpu

Technologies

The POS system must support credit account input using a card reader and thekeyboard

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 predmany customers will want digital signature capture.


27/33

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 SaleMain 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.


28/33


29/33

Using include with Asynchronous Event Handling:when a user is able to, at any time, select or branch to a particular functionThe basic notation is to use the a*, b*, ...Example - UC1: Process FooBarsMain Success Scenario:

1.

Extensions:a*. At any time, Customer selects to edit personal information: Edit Personal Informatiob*. 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(neverinstantiated)

Ex: Handle Credit payment

Base use case:A use case that includes another use case or that is extended or specialized by


30/33

A use case that includes another use case, or that is extended or specialized byanother 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 anaddition 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

ExampleHandle Gift Certificate PaymentTrigger: Customer wants to pay with gift certificate.

Extension Points: Payment in Process Sale.Level: Sub-functionMain Success Scenario:1. Customer gives gift certificate to Cashier.2. Cashier enters gift certificate ID.


31/33

Generali ation Relationship


32/33

Generalization Relationship:

superclass Payment represents a more general concept, and the subclasses morespecialized Ones.


33/33

End

ooad i unit

Documents