Kollaborative Klassroom Template

Business Information Systems
Application Development -II

Object Oriented TechniquesSystem Development Life Cycle

Prithwis Mukerjee, Ph.D.

What shall we cover here

Languages and Environments

Computer Languages

Development Environments

Activities

What are the steps required to create an application

World of Objects

What and why ?

Business application design

Software development life cycle

Water fall method

Iterative Method

Rational Unified Process

Data Modelling >> Object Orientation

Data Modelling

ENTITY : something about which we store information in a structured manner

Multiple instances of an entity exist

ATTRIBUTE(s) : a set of values defined for all instances of an entity

Instances of the entity have different values for the attribute

C-R-U-D operations are performed on instances through

Insert, Select, Update Delete in SQL

Object Oriented techniques are based on the idea of ..

CLASS(es) : a collection of instances of something that are similar in terms of..

1. ATTRIBUTE(s) : a set of values defined for all instances of a class

Instances of the class have different values of the attribute

2. METHOD(s) : a set of actions that affect an instance of the class

Change Attribute values

Create / Delete instance

Rigidity >> Flexibility

Entity

Must be reflected as TABLE in a relational database system

Eg EMPLOYEE Table

Instances are individual RECORDS in the TABLE

One record for each employee

Attribute

Is reflected as a COLUMN

All activity is defined in terms of

insert, select, update, delete

Class

No common, rigid structure

TABLE may be used to define classes

Instances of a class are called OBJECTS

Eg prithwis is an object of class EMPLOYEE

Attribute

No common, rigid structure

prithwis.name, prithwis.age are attributes of prithwis

Methods are more intuitive

recruit, promote, terminate could be methods for class employee

Examples of Classes

Physical Objects

AUTOMOBILE

Instances : Civic, Santro, Qualis,

Attributes : Price, Horsepower, Weight

Or alternatively, SANTRO

Instances : my Santro, your Santro, his Santro !

Attributes : Owner, Registration Number, Colour

Human entities

PERSON

Instances : Ram, Shyam, Madhu

Attributes : Name, Gender, Age, ...

Or alternatively, STUDENT

Instances : Ram, Shyam, Madhu

Attributes : Roll Number, Course, Grade ...

Or alternatively, EMPLOYEE

Attributes : Salary, Department ...

INHERITANCE is the phenomenon by which one CLASS inherits ATTRIBUTES from another classes

More Classes ...

Collections of data

ORDERS

Instances : Order from ITC, Tata Steel ...

Attributes : Value, Quantity, Delivery Date ...

BANKACCOUNT

Instances : Account of Ram, Shyam, Madhu

Attributes : Name, Number, PAN, balance

INVENTORY

Instances : Soap, Detergents, Biscuits ..

Attribute : SKU, units, location, ....

Elements of a Systems Environment !!

WINDOWS

Instances : OrderCreation, OrderModification

Attributes : Size, Title, Scrollable or Not ...

Methods + Attributes = Classes

Recollect

Algorithms + Data Structures = Programs

Database + Application = Systems

Classes consist of

Attributes

Pieces of data that distinctly indentify OBJECTS ( instances ) of CLASS

Methods or Functions

Instructions common to a CLASS that have an impact on Attributes of an OBJECT

Coded in language like C++

Class STUDENT

Attribute

Name

Roll Number

Standard

Method

ENROLL

Create new OBJECT with Name (prithwis)

Assign Roll Number

Assign Standard = 1

PROMOTE

Change Standard from Current Value to Current Value + 1

Each Class has own Attributes / Methods

Class STUDENT

Attributes : Name, Roll Number, Standard

Methods : Enroll, Promote, Graduate

Class EMPLOYEE

Attributes : Name, Emp Number, Designation, Salary

Methods : Hire, Promote, RaiseSalary, Fire

Method

A set of instructions in a language like C++ or Java that cause certain changes to happen to the attributes

The same METHOD could mean different things when it applies to different CLASSes

PROMOTE : STUDENT change value of STANDARD attribute

PROMOTE : EMPLOYEE change value of DESIGNATION and SALARY

POLYMORPHOSIM is the phenomenon by which the same METHOD could mean different things in different CLASSes

Object Oriented Techniques

Deal with CLASSes which are defined as a bundle of

Attributes : That is DATA

Methods : That is a way of changing the DATA in a meaningful way

Have OBJECTs that are instances of a CLASS with

Specific values ATTRIBUTE that are

Modified by invoking METHODs appropriate for this class

Ensure integrity of data by

Allowing change to happen in the values of attributes ONLY through an execution of a METHOD

Consider Class EMPLOYEE

Salary cannot be changed by SIMPLE SQL update to any arbitrary value

Salary must change through METHOD promote which will ensure that salary change is as per company defined rules

Encapsulation of Data and Logic in a single artefact

OO Application Development

Model user requirement with an appropriate number of

CLASSes which are defined in terms of

ATTRIBUTES

METHODS

A Method in One class can invoke a Method in another class

Method ORDER.fullfillORDER can invoke INVENTORY.reduceINVENTORY

Define CLASSes along with ATTRIBUTES and METHODS using

A pure object oriented language like C++ or Java

A hybrid but easier-to-use alternative could be ...

Visual Basic

ZOHO !!

A large and complex application that manages the internals of a big company can have hundreds of classes, each with its own attributes and methods. Managing all this is not easy !!

We need to define a process for doing all this ...

OO Application Development

Creates a model of a real world solution

Using an object oriented language like C++ or Java

In terms of a number of CLASSes

A CLASS is an artefact that allows

Encapsulation or bundling definition of

Data in ATTRIBUTES

Logic in Methods

Inheritance

Allows instances of one class to acquire attributes and methods from another

Polymorphism

Allows the same method to mean diferent things in different classes

Instances or OBJECTs that are specified by values of the attributes

A potential violation ?

Encapsulation is the process of bundling

Data

Attributes

Are we violating the principles of keeping data and logic separate ?

In a sense we are ...

But not if we introduce the concept of ...

Persistence

When an object of a class outlives the application or method that manipulates it

Consider the Similarity

ENTITY in Data Model

CLASS in OO Application

Consider the Difference

ENTITY is represented by a TABLE in an RDBMS

TABLE exists in computer even when computer switched off

OBJECTS along with data are lost when computer shuts down

Persistence

CLASS

A set of instructions that define ATTRIBUTES, METHODS in an OO Language

Persists in computer even when it is switched off

OBJECTS

Created, or instantiated with appropriate values of ATTRIBUTE

Does not persist when computer is shut off. All Data is lost.

ENTITY

A TABLE in an RDBMS defined in terms of COLUMNS

Persists in computer even when it is switched off

RECORDS

Created and manipulated with appropriate SQL statements

Either directly

Or through a method

PERSISTS in the computer even when it is shut off. No data is lost

Making OBJECTs persist

Application Server

Machine Starts

Application is created

Class, Attributes Defined

Application Saved

Application is executed

Object1 created with data

Object1 made persistent

Application Stops

Object1 destroyed with data

Machine Stops

Application Saved

Class, Attribute Definition Saved

Data with Object1 LOST

Database Server

Machine Starts

RDBMS starts

Waits for Application request

...

Recieves Object1

Persists Object1 in TABLE / RECORD

Waits for next request

....

RDBMS stopped

Machine Stops

Persistent Copy of Object1 stored in Table

The Next Day

Application Server

Machine Starts

Application retrieved

Application Starts

Object1 created with blank data

Data of Object1 recovered from Persistent copy

Data for Object1 modified by methods

Object1 made persistent

Application Stops

Object1 destroyed with data

Machine Stops

Database Server

Machine Starts

RDBMS Starts

Waits for Application Request

...

Sends Persistent copy of Object1

...

..

Persists modified copy of Object1

..

RDBMS stops

Machine Stops

Modified copy of Object1 saved

Three Tier Architecture

CLASS definitionO2O3O4O1

CLASS definitionApplication in Execution

Application Not Executing

Relational Database

Non Relational Database

OR

transient objects in application

persistent objects in database

Commercial, business applications RARELY use NON RELATIONAL database

User Interface

System Development Life Cycle

Functional Specification

Program Review ChecklistComplexityDetermination / EstimateTechnicalSpecification

Test

SupportUnit Test PlanProgram Source CodeCode Bundle / DemoUnit Test ResultsSupport(optional)Pre-Production Support

Technical ReviewClient
Review Client
Review Programmer DrivenUSER DrivenFunctional
Design EstimateTechnical
DesignDeliverTestSupportDevelopMethodology ComponentCommunication & Coordination
(all teams)

Technical Design WalkthroughCode ReviewClient Sign Off

LegendTask With DeliverableTask Without DeliverableOptional Service AreaProcess Checkpoint

The WaterFall Method A simplified view

Analysis

Design

Coding

Test / Deploy

Users define what they wantfrom the system

Programmers re-define what theybelieve the users want in a morestructured manner

Actual program is built usingan appropriate computerlanguage like C, Java, VisualBasic

Application is tested and thendeployed in the end users machine

The WaterFall Method Deliverables

Analysis

Design

Coding

Test / Deploy

Requirements Analysis Documentwritten in simple English language

Systems Specifications written in terms of e.g. TABLES, COLUMNS, METHODS, FUNCTIONS

Programs written in an appropriatelanguage and tested individually.Unit Test Report for each program

All programs tested together toensure compatibility and consistencyIntegration Test Report

Waterfall Process Assumptions

Requirements are known up front before design

In reality, users do not know what they want

They certainly cannot visualise what the final thing will look like

Requirements rarely change

They always will, however much you hate it

Design can be conducted in a purely abstract space, or trial rarely leads to error

The technology will all fit nicely into place when the time comes (the apocalypse)

Waterfall Process Limitations

Big Bang Delivery Theory

The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced.

Late deployment hides many lurking risks:

technological (well, I thought they would work together...)

conceptual (well, I thought that's what they wanted...)

personnel (took so long, half the team left)

User doesn't get to see anything real until the very end, and they always hate it.

System Testing doesn't get involved until later in the process.

What did the customer really want ?

An Iterative Development Process...

Recognizes the reality of changing requirements

Caspers Joness research on 8000 projects

40% of final requirements arrived after the analysis phase, after development had already begun

Promotes early risk mitigation, by breaking down the system into mini-projects and focusing on the riskier elements first

Allows you to plan a little, design a little, and code a little

Encourages all participants, including testers, integrators to be involved earlier on

Allows the process itself to modulate with each iteration, allowing you to correct errors sooner and put into practice lessons learned in the prior iteration

Focuses on component architectures, not final big bang deployments

An Incremental Development Process...

Allows for software to evolve, not be produced in one huge effort

Allows software to improve, by giving enough time to the evolutionary process itself

Forces attention on stability, for only a stable foundation can support multiple additions

Allows the system (a small subset of it) to actually run much sooner than with other processes

Allows interim progress to continue through the stubbing of functionality

Allows for the management of risk, by exposing problems earlier on in the development process

Goals and Features of Each Iteration

The primary goal of each iteration is to slowly chip away at the risk facing the project, namely:

performance risks

integration risks (different vendors, tools, etc.)

conceptual risks (ferret out analysis and design flaws)

Perform a mini-waterfall project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctives

The result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach

Click to edit the title text format

Click to edit the outline text format

Second Outline Level

Third Outline Level

Fourth Outline Level

Fifth Outline Level

Sixth Outline Level

Seventh Outline Level

Eighth Outline Level

Ninth Outline Level

Prithwis Mukerjee

Click to edit the outline text format

Second Outline Level

Third Outline Level

Fourth Outline Level

Fifth Outline Level

Sixth Outline Level

Seventh Outline Level

Eighth Outline Level

Ninth Outline Level