SEZ6C/SEE6C/PED2A OBJECT ORIENTED ANALYSIS AND DESIGN … · SEZ6C /SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 2 / 75 UNIT-I ¾ System Development ¾ Object Basics ¾ Development

SEZ6C/SEE6C/PED2A

OBJECT ORIENTED

ANALYSIS AND DESIGN

Unit : I -V

TM

SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 2 / 75

UNIT-I

System Development

Object Basics

Development Life Cycle

Methodologies

Patterns

Frameworks

Unified Approach

UML.

TM

SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 3

Why an Object Orientation

• Higher Level of abstraction

• Seamless transition among different phases of software

development.

• Encouragement of good programming techniques.

• Promotion of Reusability.

What kind of language can alleviate difficulties with

communication & complexity hopefully well?

!@#$

%

ooad

TM

SEZ6C//SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 4

WATERFALL APPROACH

TM


OBJECT BASICS

• An "object" is anything to which a concept applies, in our awareness

• Things drawn from the problem domain or solution space. – E.g., a living person in the problem domain, a software component in the solution

space.

A structure that has identity and properties and behavior

It is an instance of a collective concept, i.e., a class.

https://www.youtube.com/watch?v=OkC7HKtiZC0

https://www.youtube.com/watch?v=OkC7HKtiZC0

TM


Encapsulation

a.k.a. information hiding

Objects encapsulate:

property

behavior as a collection of methods invoked by

messages

…state as a collection of instance variables

Abstraction

Focus on the essential

Omits tremendous amount of details

…Focus on what an object “is and does”

What is Object-Orientation

- Abstraction and Encapsulation

TM


What is Object-Orientation?

- Class

• What is CLASS?

– a collection of objects that share common properties, attributes, behavior and semantics.

– A collection of objects with the same data structure (attributes, state variables) and behavior (function/code/operations) in the solution space.

• Classification

– Grouping of common objects into a class.

Class Car

Attributes

Model

Location

#Wheels =

4

Operations

Start

Accelerate

<<instanceOf>

>

<<instanceOf>

>

<<instanceOf>

>

TM



- Subclass vs. Superclass

A

B

C

A

B

A

B

C

A

B

c: C

A

B

c: C

<<instanceOf>> <<instanceOf>>

A

B

<<instanceOf>>

A

B

<<instanceOf>>

TM



- Polymorphism

Objects of different classes respond to the same message

differently.

payTuition

Person

name SSN

Student

std-id level

Employee

emp-id

In-State Student

state

payTuition payTuition

Out-of-State Student

payTuition

TM


What is Object-Orientation?

-State

• What is STATE? "State" is a collection of association an object has with other objects

and object types. • What is STATE CHANGE? A "state change" is the transition of an object from one state to

another. • What is EVENT? An "event" is a noteworthy change in state [Rumbaugh]

TM


Systems Engineering

Requirements Analysis

Project Planning

Architectural Design

Detailed Design

Implementation

Release

Maintenance

Quality

Assura

nce

Software Lifecycle

How to Do OOAD

– Where to Use OO?

Something missing?

What’s yours like?

TM


How to Do OOAD

OMT as Object-Oriented Methodology OMT (Object Modeling Technique) by James Rumbaugh

Object Model: describes the

static structure of the objects in

the system and their

relationships -> Object

Diagrams.

Dynamic Model: describes the

interactions among objects in

the system -> State Diagrams.

Functional Model: describes the

data transformation of the

system

-> DataFlow Diagrams.

TM

SEZ6C/SEE6A/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 3

https://www.youtube.com/watch?v=0po_wmSEW1Q

Booch method

• Class diagrams-

describe roles and responsibilities of objects

• Object diagrams

describe the desired behavior of the system in terms of scenarios

• State transition diagrams

state of a class based on a stimulus

• Module diagrams

to map out where each class & object should be declared

• Process diagrams

to determine to which processor to allocate a process

• Interaction diagrams

describes behavior of the system in terms of scenarios



TM

SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 1 4

https://www.youtube.com/watch?v=OEfSFrk_KEI

JACOBSON METHODOLOGIES

• Use Cases.

• Object Oriented Software Engineering.

• Object Oriented Business Engineering.

https://www.youtube.com/watch?v=OEfSFrk_KEI

TM


OO SOFTWARE

DEVELOPMENT LIFE

CYCLE

TM


UML

https://www.youtube.com/watch?v=JCbzrUbZOEY

The UML consists of the following diagrams:

https://www.youtube.com/watch?v=JCbzrUbZOEY

TM


Use-Case Models

Object Analysis

Object relations

Attributes

Methods

Class and Object responsibilities

Case Studies.

UNIT-II

TM


OBJECT ORIENTED

ANALYSIS PROCESS

• Identifying use cases

• Object Analysis

• Classification

• Identifying Object relationships

• Attributes and Methods.

• Analysis is the process of transforming a problem definition from

a fuzzy set of facts and myths into a coherent statement of a

system’s requirements.

WHAT IS ANALYSIS?

TM


Where Should We Start?

• 1. Examination of existing system documentation.

• 2. Interviews.

• 3. Questionnaire.

• 4. Observation.

Three most common sources of requirements difficulties are:

1. Incomplete requirements.

2. Fuzzy descriptions (such as fast response).

3. Unneeded features.

Requirements Difficulties

TM


The Object-Oriented Analysis

(OOA) Process

• The process consists of the following steps:

• 1. Identify the actors:

– Who is using the system?

– Or, in the case of a new system, who will be using system?

2. Develop a simple business process model using UML activity diagram.

3. Develop the use case:

What the users are doing with the system?

Or, in the case of a new system, what users will be doing with the

system?

4. Prepare interaction diagrams:

Determine the sequence.

Develop collaboration diagrams.

5. Classification—develop a static UML class diagram:.

https://www.youtube.com/watch?v=yPAB2M_fuGA

https://www.youtube.com/watch?v=yPAB2M_fuGA

TM


The OOA Process (Con’t)

• 6. Iterate and refine: If needed, repeat the preceding steps.

Refineanditerate

Identify Actors

Develop Use-Cases, ADs

DevelopInteractionDiagrams

Identify Classes,Relationships,Attributes &Methods

O-O Analysis

prototyping

Use case. Use case is a special flow of events through the system.

Actors. An actor is a user playing a role with respect to the system.

In a system. This simply means that the actors communicate with the system's use

case.

USE CASE KEY CONCEPTS

TM


Extends Associations

• The extends association is used when you have one use case

that is similar to another use case but does a bit more or

• Is more specialized; in essence, it is like a subclass.

Library

Borrow books

Reading booksNewspaper

Member

Supplier

Purchasing Supplies

Inter library loan

extends

uses

uses

Performing research

Return Books

Circulation Clerk

Checking Library Card

TM


Use case Driven

• Capture the user’s needs (requirements - in users context)

- Helps in Project Scheduling

• Analyse to specify the needs

• Design to realize the needs

• Implement to implement the needs

• Test to verify the needs

Use cases Test

Test1

Test2

Test3

Verified by

Implementation

Implemented by

Design

Design2

Design1

Design3

Design4

Realized by

Analysis

Specified by

TM


Use Case Diagram Notation

Actor

Association

Use Case

Use case with Extension points

<<Uses>>

<<Extends>>

TM


Documentation

• An effective document can serve as a communication vehicle

among the project's team members, or it can serve as initial

understanding of the requirements.

All documents should share a common cover

sheet that identifies the document, the current

version, and the individual responsible for the

content.

https://www.youtube.com/watch?v=18_kVlQMavE

https://www.youtube.com/watch?v=18_kVlQMavE

TM


80–20 Rule

• 80 percent of the work can be done with 20 percent of the

documentation.

• The trick is to make sure that the 20 percent is easily accessible and

the rest (80 percent) is available to those (few) who need to know.

Use a vocabulary that your readers understand and are

comfortable with.

The main objective here is to communicate with readers

and not impress them with buzz words.

FAMILIAR VOCABULARY

TM


Classification

• “The identification of classes and objects is the hardest part of

object-oriented design.” – Booch

• Discovery – recognize key abstractions and mechanisms from

problem domain

• Invention – devise generalized abstractions and new mechanisms

that specify how objects collaborate

TM


Approaches for Identifying

Classes

• The noun phrase approach.

• The common class patterns approach.

• The use-case driven approach.

• The class responsibilities collaboration (CRC) approach.

Using this method, you have to read through the Use cases, interviews,

and requirements specification carefully, looking for noun phrases.

NOUN PHRASE APPROACH

TM


https://www.youtube.com/watch?v=P2X9N4-xEvc

NOUN PHRASE APPROACH

•All plurals are changed into singular

•Nouns are listed

•List divided into three categories

•Relevant classes

•Fuzzy classes (those classes that are not sure about)

•Irrelevant classes




TM


https://www.youtube.com/watch?v=3deUvPIOTeA

COMMON CLASS PATTERNS

APPROACH

•Concept class

•Event Class

•Organizations Class

•People Class

•Places Class

•Tangible things and devicesClass

https://www.youtube.com/watch?v=3deUvPIOTeA

TM


USE CASE DRIVEN

APPROACH

Actor Class

Synchronous message Asynchronous message

Return message Focus of Control

lifeline Termination

SEQUENCE DIAGRAM

https://www.youtube.com/watch?v=3cmzqZzwNDM

https://www.youtube.com/watch?v=3cmzqZzwNDM

TM


CASE STUDY- EXAMPLE

TM


Design Processes

Design Axioms

Class Design

Object Storage

Object Interoperability

Case Studies

UNIT-III

TM


Object-Oriented Design Process

and Design Axioms • Analysis Phase

– Class’s attributes, methods and associations are identified – Physical entities, players and their cooperation are identified

– Objects can be individuals, organizations or machines

• Design Phase – Using Implementation language appropriate data types are assigned

– Elevate the model into logical entities (user interfaces)

– Focus is on the view and access classes (How to maintain information

or best way to interact with a user)

https://www.youtube.com/watch?v=vNHpsC5ng_E&list=PLF206E9

06175C7E07

https://www.youtube.com/watch?v=vNHpsC5ng_E&list=PLF206E906175C7E07

https://www.youtube.com/watch?v=vNHpsC5ng_E&list=PLF206E906175C7E07

TM


Corollary 1

•Uncoupled design with less information content

Corollary 2

•Single process

Corollary 3

•Large number of simple classes

Corollary 4

•Strong mapping

Corollary 5

•Standardization

Corollary 6

•Design with inheritance

COROLLARY

TM


https://www.youtube.com/watch?v=yRJ1rRoMnIM&list=PLF206E906175

C7E07&index=2

THE ORIGIN OF

COROLLARY

https://www.youtube.com/watch?v=yRJ1rRoMnIM&list=PLF206E906175C7E07&index=2

https://www.youtube.com/watch?v=yRJ1rRoMnIM&list=PLF206E906175C7E07&index=2

TM


Design Patterns:

•Pattern name

•Rationale and motivation

•Classes

•Advantages/Disadvantages

•Examples

Designing Classes: The Process Apply design axioms to design classes, their attributes, methods ,

associations , structures and protocols.

Refine and complete the static UML class diagram by adding

details to that diagram.

Refine attributes

Design methods and the protocols by utilizing a UML activity

diagram to represent the methods’s algorithm. Refine the associations between classes

Refine the class hierarchy and design with inheritance.

Iterate and refine.

TM


Class Visibility: •Private Protocol

•Public Protocol

•Protected protocol

Designing classes: Refining Attributes

In the design phase, detailed information must be added to the

model. The main goal of this activity is to refine existing attributes or

add attributes that can elevated the system into implementation.

Attributes Types:

1.Single-value attributes

2.Multiplicity or multivalue attributes

3.Reference to another object, or instance connection.

TM


UML Attribute Presentation: The following is the attribute presentation suggested by UML:

Visibility name:type-expression=initial-value

Where visibility is one of the following:

+ public visibility

# protected visibility

- private visibility

Designing methods and protocols: A class can provide several types of methods:

Constructor

Destructor

Conversion method

Copy method

Attribute set

Attribute get

SEZ6C/SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN

TM

40

1.If it looks messy, then it’s probably a bad design

2.If it is too complex, then it’s probably a bad design. 3.If it is too big, then it’s probably a bad design. 4.If people don’t like it, then it’s probably a bad design.

5.If it doesn’t work, then it’s probably a bad design. Design issues: Avoiding Design pitfalls

Keep a careful eye on the class design and make sure that an

object’s role remains well defined. If an object loses focus, you need to modify the design. Apply corollary 2.(single purpose)

Move some functions into new classes that the object would use.

Apply corollary1(uncoupled design with less information content)

Break up the class into two or more classes. Apply

corollary3(large number of simple classes)

Rethink the class definition based on experience gained.

FIVE RULES FOR A GOOD

DESIGN

TM


CORBA

TM


COOPERATIVE PROCESSING

TM


Rules of object-oriented system: 1.The system must support complex objects.

2.Object identity must be supported.

3.Object must be encapsulated.

4.The system must support types or classes.

5.The system must support inheritance.

6.The system must avoid premature binding.

7.The system must be computationally complete.

Rules make it a DBMS:

1.It must be persistent, able to remember an object

state.

2.It must be able to manage very large database.

3.It must accept concurrent users.

4.It must be able to recover from hardware and

software failures.

5.Data query must be simple.

https://www.youtube.com/watch?v=ICTCH2KQgUs

https://www.youtube.com/watch?v=ICTCH2KQgUs

TM


• Object –oriented database

management systems:

TM


Object –Relation mapping: 1.Table-Class mapping

2.Table-multiple classes mapping

3.Table-inherited classes mapping

4.Tables-inherited classes mapping

MULTI DATABASE SYSTEMS

https://www.youtube.com/watch?v=KwBwKZcoG24

https://www.youtube.com/watch?v=KwBwKZcoG24

TM


Designing access layer classes: 1.Translate the request

2.Translate the results.

The Process: 1.For every business class identified, mirror the

business class package.

2.Define relationships.

3.Simplify classes and relationships.

1.Redundant classes

2.Method classes

4. Iterate and refine.

TM


https://www.youtube.com/watch?v=fJW65Wo7IHI

OBJECT ORIENTED

DESIGN PROCESS

https://www.youtube.com/watch?v=fJW65Wo7IHI

TM


Attributes types

1. Single –value attributes

2. Multiplicity or multivalue attributes

3. References to another object

Attributes presentation :

+ public visibility

# protected visibility

- private visibility

REFINING ATTRIBUTES

TM


User Interface Design

View layer Classes

Micro-Level Processes

View Layer Interface

Case Studies.

UNIT-IV

TM


USER INTERFACE DESIGN

• Designing effective interfaces

for software systems

Objectives

• To suggest some general design principles for user interface design

• To explain different interaction styles

• To introduce styles of information presentation

• To describe the user support which should be built-in to user

interfaces

• To introduce usability attributes and system approaches to system

evaluation

TM


DESIGNING VIEW LAYER

CLASSES :

https://www.youtube.com/watch?v=J3nDAkF-Fa8

•1.Designing View Layer classes

•2.Macro level UI design process

•Micro level UI design activities

•2.1 Designing the view layer objects by applying design axioms and

corollaries

•2.2 Prototyping the view layer interface

•3. Testing the usability and user satisfaction

•4. Refining and iterating the design




TM


DESIGNING ACCESS LAYER

•Translate the request

•Translate the result

TM


UI DESIGN RULES:

1. UI design rule 1: Making the interface simple(Application of

Corollary 2)

2. UI design rule 2: Making the interface transparent and

natural.(Application of Corollary 4)

3. UI design rule3:Allowing users to be in control of the

software(Application of Corollary 1)

-- Make the interface forgiving.

– Make the interface visual

– Provide immediate feedback.

– Avoid modes.

https://www.youtube.com/watch?v=GH1WR1IT_c0



TM


GRAPHICAL USER

INTERFACES

• Most users of business systems interact with these systems through

graphical interfaces although, in some cases, legacy text-based

interfaces are still used

They are easy to learn and use.

Users without experience can learn to use the system

quickly.

The user may switch quickly from one task to

another and can interact with several different applications.

Information remains visible in its own window when

attention is switched.

Fast, full-screen interaction is possible with immediate access to

anywhere on the screen

ADVANTAGES:

TM


USER INTERFACE DESIGN

PROCESS

Executableprototype

Designprototype

Produce paper-based design

prototype

Producedynamic design

prototype

Evaluate designwith end-users

Implementfinal userinterface

Evaluate designwith end-users

Analyse andunderstand user

activities



TM


CONTROL PANEL

INTERFACE

Title

Method

Type

Selection

NODE LINKS FONT LABEL EDIT

JSD. example

JSD

Network

Process

Units

Reduce

cm

Full

OUIT

PRINT

Grid Busy

TM


FORM-BASED INTERFACE

Title

Author

Publisher

Edition

Classification

Date ofpurchase

ISBN

Price

Publicationdate

Number ofcopies

Loanstatus

Orderstatus

NEW BOOK

TM


MULTIPLE USER

INTERFACE

Operating system

GUImanager

Graphical userinterface

Commandlanguage

interpreter

Commandlanguageinterface

TM


INFORMATION

PRESENTATION

Information tobe displayed

Presentationsoftware

Display

TM


TEXTUAL HIGHLIGHTING

The filename you have chosen has beenused. Please choose another name

Ch. 16 User interface design!

OK Cancel

https://www.youtube.com/watch?v=sOMZtz7Nmk4

https://www.youtube.com/watch?v=sOMZtz7Nmk4

TM


COLOR USE GUIDELINES

• Don't use too many colours

• Use colour coding to support use tasks

• Allow users to control colour coding

• Design for monochrome then add colour

• Use colour coding consistently

• Avoid colour pairings which clash

• Use colour change to show status change

• Be aware that colour displays are usually lower

resolution





TM


DESIGN FACTORS IN

MESSAGE WORDING

Context The user guidance system should be aware of what the user isdoing and should adjust the output message to the currentcontext.

Experience As users become familiar with a system they become irritatedby long, ‘meaningful’ messages. However, beginners find itdifficult to understand short terse statements of the problem.The user guidance system should provide both types of messageand allow the user to control message conciseness.

Skill level Messages should be tailored to the user’s skills as well as theirexperience. Messages for the different classes of user may beexpressed in different ways depending on the terminology whichis familiar to the reader.

Style Messages should be positive rather than negative. They shoulduse the active rather than the passive mode of address. Theyshould never be insulting or try to be funny.

Culture Wherever possible, the designer of messages should be familiarwith the culture of the country where the system is sold. Thereare distinct cultural differences between Europe, Asia andAmerica. A suitable message for one culture might beunacceptable in another.

TM


Guidelines for designing forms and Data entry

windows:

•Navigating rows in a table, such as moving forward and backward, and going

to the first and last record.

•Adding and deleting rows.

•Changing data in rows.

•Saving and abandoning changes

•We can put controls anywhere on a window.

•When entering data, users expect to type information from left to right and top

to bottom.

TM


Guidelines for designing

Dialog boxes and Error

messages: • A dialog box provides an exchange of

information or a dialog between the user and

application.

• Your error message should be positive. For

eg., instead of displaying “you have typed an illegal date format,”display the message “Enter date format mm/dd/yyyy”.

• Your error message should be constructive.

• Your error message should be brief and

meaningful.

TM


UNIT-V

Quality Assurance Tests

Testing Strategies

Object orientation on testing

Test Cases

test Plans

Continuous testing

Debugging Principles

System Usability

Measuring User Satisfaction

Case Studies.

TM


Quality Assurance Tests

•To develop and deliver robust systems, we need a high

level of confidence that

•Each component will behave correctly.

•Collective behavior is correct

•No incorrect collective behavior will be produced.

TM

SEZ6C-/SEE6C/PED2AOBJECT ORIENTED ANALYSIS AND DESIGN 67

Types of Errors:

•Language Errors

•Run-time Errors

•Logic Errors

TM


QUALITY ASSURANCE

TESTS

Quality assurance (QA) is a way of

preventing mistakes or defects in

manufactured products and avoiding

problems when delivering solutions or

services to customers; which ISO 9000

defines as "part of quality

management focused on providing

confidence that quality requirements

will be fulfilled".

TM


Black Box Testing:

Black Box Testing, also known as BehavioralTesting, is a

software testing method in which the internal structure/ design/

implementation of the item being tested is not known to the tester

TM


D/F B/W BLACK BOX AND

WHITE BOX

TM


TOP-DOWN TESTING

Top-down testing is an approach to integratedtesting where

the top integrated modules are testedand the branch of the module

is tested step by step until the end of the related module

TM

SEZ6C-/SEE6C/PED2AOBJECT ORIENTED ANALYSIS AND DESIGN 72

BOTTOM –UP TESTING

Bottom-up testing is an approach to integrated testing where the

lowest level components are tested first, then used to facilitate

the testing of higher level components

TM


•The base class contains methods inherited() and redefined()

•The derived class redefines the redefined()method.

•The derived::redefined has to be tested afresh since it is a

new code.

•Some types of errors could become less plausible.

•Some types of errors could become more plausible.

•Some new types of errors might appear.

IMPACT OF OBJECT-

ORIENTATION ON TESTING

IMPACT OF INHERITANCE IN TESTING

TM


EXAMPLE FOR TEST CASE

DOCUMENT

https://www.youtube.com/watch?v=R5GXwRcIT9Y

https://www.youtube.com/watch?v=R5GXwRcIT9Y

TM


Guidelines for developing Quality Assurance

Test Cases: •Developing which feature or service your test attempts to cover.

•If the test case is based on a use case, it is a good idea to refer to the

use-case name.

•Specify what you are testing and which particular methods, then specify

what you are going to do to test the feature.

•Test the abnormal but reasonable use of the object’s methods.

https://www.youtube.com/watch?v=hMfPCdF07hA

https://www.youtube.com/watch?v=hMfPCdF07hA

TM


Steps to create a Test plan: 1.Objectives of the test.

2.Development of a test case

3.Test analysis

https://www.youtube.com/watch?v=Vdm1Lh540LM

https://www.youtube.com/watch?v=Vdm1Lh540LM

TM


Myers’s Debugging principles: 1.Bug Locating principles.

Think

If you reach an impasse, sleep on it.

If the impasse remains, describe the problem to someone else.

Use debugging tools.

Experimentation should be done as a last resort.

Debugging Principles

•Where there is one bug, there is likely to be another.

•Fix the error, not just the symptom of it.

•The Probability of the solution being correct drops as the

size of the program increases.

•Beware of the possibility that an error correction will

create a new error

TM


Usability Testing. The ISO defines Usability as

Effectiveness

Efficiency

Satisfaction with which a specified set of users can

achieve a specified set of tasks in particular

environments.

The ISO definition requires:

Defining tasks. What are the tasks?

Defining users. Who are the users?

A means for measuring effectiveness, efficiency and

satisfaction.

TM


Guidelines for Developing Usability Testing:

•The usability testing should include all of a software’s components. •Usability testing need not be very expensive or elaborate.

•All tests need not involve many subjects. Quick , iterate tests with a

small, well-targeted sample of 6 to 10 participants can identify 80-

90npercent of most design problems.

•Apply usability testing early and often.

Recording the Usability Test:

Record the test results using

1.A portable tape recorder

2.Video camera

TM


CUSTOMER FEEDBACK

Documents

SEZ6C/SEE6C/PED2A OBJECT ORIENTED ANALYSIS AND DESIGN … · SEZ6C /SEE6C/PED2A-OBJECT ORIENTED ANALYSIS AND DESIGN 2 / 75 UNIT-I ¾ System Development ¾ Object Basics ¾ Development