UNIT-I

CHAPTER-1

An Overview of Object Oriented Systems Development

CHAPTER OBJECTIVES:

You should able to define and understand:

 The object oriented philosophy and why we need to study it
 The unified approach

INTRODUCTION:

A software development methodology is a series of processes that lead to the development of

an application. A software development activity consists of:
 System analysis
 Modeling
 Design
 Implementation
 Testing and
 Maintenance

Software process: It describes how the work is to be carried out to achieve the original goal
based on the system requirement. Each process consists of number of steps and rules that should
be performed during development.

TWO ORTHOGONAL VIEWS OF SOFTWARE:

 Traditional technique

 Object oriented methodologies

Programs=Algorithm + Data Structures

1
 TRADITIONAL APPROACH OBJECT ORIENTED SYSTEM
DEVELOPMENT
Collection of procedures(functions) Combination of data and functionality
Focuses on function and procedures, Focuses on object, classes, modules that
different styles and methodologies for can be easily replaced, modified and
each step of process reused.
Moving from one phase to another phase Moving from one phase to another phase
is complex. is easier.
Increases duration of project decreases duration of project
Increases complexity Reduces complexity and redundancy

OBJECT ORIENTED SYSTEMS DEVELOPMENT METHODOLOGY

 Object oriented systems development methodology develops software by building objects

that can be easily replaced , modified and reused.
 It is a system of cooperative and collaborating objects.
 Each objects has attributes (data) and methods (functions).

Why an object orientation?

Object oriented systems are

 Easier to adapt to changes

 More robust

 Easier to maintain

 Promote greater design and code reuse

 Creates modules of functionality

Reasons for working of object oriented systems:

 Higher level of abstraction

 Seamless transition among different phases of software development

 Encouragement of good programming techniques

 Promotion of reusability

2
  Higher level of abstraction
 Object orientation approach support abstraction at object level.
 Object encapsulates both data and functions. So they work at higher level of
abstraction.
 So designing, coding, testing and maintaining the system are much simpler.

 Seamless transition among different phases of software development

TRADITIONAL APPROACH OBJECT ORIENTED SYSTEM
DEVELOPMENT
Collection of procedures(functions) Combination of data and functionality
Focuses on function and procedures, Focuses on object, classes, modules
different styles and methodologies for that can be easily replaced, modified
each step of process and reused.
Moving from one phase to another Moving from one phase to another
phase is complex. phase is easier.
Increases duration of project decreases duration of project
Increases complexity Reduces complexity and redundancy

 Encouragement of good programming techniques

 Changing one class has no impact on other classes
 But there is communication between classes through interface
 Promote clear design
 Implementation is easy
 Provides for better overall communication

 Promotion of reusability
 Objects are reusable because they are modeled directly out of real world problem
domain.

OBJECT ORIENTATION:

Object oriented methods enable us to create sets of objects that work together
synergistically to produce software that better module their problem domains than similar
systems produced by traditional techniques. The system created using object oriented methods
are easier to adapt changing requirements, easier to maintain, more robust, promote greater
design.

The reasons why object orientation works

 High level of abstraction.
 Seamless transition among different phases of software development.
 Encourage of good programming techniques.
 Promotion of reusability.

3
High level of abstraction:

Top-down approach:
It supports abstraction of the function level.

Objects oriented approach :

It supports abstraction at the object level. The object encapsulate both the data (attributes) and
functions (methods), they work as a higher level of abstraction. The development can proceed at
the object level, this makes designing, coding, testing, and maintaining the system much simpler.

Seamless transition among different phases of software development

Traditional Approach:
The software development using this approach requires different styles and
methodologies for each step of the process. So moving from one phase to another requires more
complex transistion.

Object-oriented approach:
We use the same language to talk about analysis, design, programming and
database design. It returns the level of complexity and reboundary, which makes clearer and
robust system development.

Encouragement of good programming techniques:

A class in an object-oriented system carefully delineates between its interface and the
implementation of that interface. The attributes and methods are
encapsulated within a class (or) held together tightly. The classes are grouped into subsystems
but remain independent one class has no impact on other classes. Object oriented approach is not
a magical one to promote perfect design (or) perfect code. Raising the level of abstraction from
function level to object level and focusing on the real-world aspects of the system, the object
oriented method tends to

 Promote clearer designs.

 Makes implementation easier.
 Provide overall better communication.

Promotion of Reusability:

Objects are reusable because they are modeled directly out of real world. The classes are
designed generically with reuse. The object orientation adds inheritance, which is a powerful
technique that allows classes to built from each other. The only different and enhancements
between the classes need to be designed and coded. All the previous functionality remains and
can be reused without change.

4
OVERVIEW OF UNIFIED APPROACH:

The UML (Unified Modeling Language) is a set of notations and conventions used to describe
and model an application.The Unified Approach (UA) specifies the tasks or steps to develope an
application,The heart of UA is Jacobson’s usecase.The UA consists of the following concepts:
 Usecase driven approach
 Utilizing the UML for modeling
 Object oriented analysis
 Object oriented design
 Repositories of reusable classes and maximum reuse
 The layered approach
 Incremental development and prototyping
 Continuous testing

5
6
SUMMARY

A software development methodology is a series of processes that lead to the

development of an application. Software process: It describes how the work is to be carried out
to achieve the original goal based on the system requirement. Each process consists of number of
steps and rules that should be performed during development. The reasons for working of object
oriented systems:
 Higher level of abstraction
 Seamless transition among different phases of software development
 Encouragement of good programming techniques
 Promotion of reusability

The UML (Unified Modeling Language) is a set of notations and conventions used to
describe and model an application.The Unified Approach (UA) specifies the tasks or steps to
develope an application. The heart of UA is Jacobson’s usecase.The UA consists of the
following concepts:
 Usecase driven approach
 Utilizing the UML for modeling
 Object oriented analysis
 Object oriented design
 Repositories of reusable classes and maximum reuse
 The layered approach
 Incremental development and prototyping
 Continuous testing

KEY TERMS

Unified Approach (UA)

Unified Modeling Language (UML)

KEY TERM QUIZ

1. The unified modeling language (UML) is a language for specifying

constructing, visualizing and documenting the software system and its
components.
2. Unified Approach (UA) is the methodology for software development.

7
MULTIPLE CHOICE

1. The unified modeling language (UML) is a language for specifying

constructing, visualizing and documenting the software system and its
components.
(a) UML (b) UA

2. Unified Approach (UA) is the methodology for software development.

(a) UML (b) UA

3. Algorithm-centric methodology: You think of an algorithm that can accomplish

the task, and then build data structures for that algorithm to use.
(a) Algorithm-centric methodology (b) Data- centric methodology

4. Data- centric methodology: You think how to structure the data, and then build
the algorithm around that structure.
(a) Algorithm-centric methodology (b) Data- centric methodology

REVIEW QUESTION

1. What is software development methodology? (Pg 3)

2. What are orthogonal views of software? (Pg 4)
3. What is Object Oriented system development methodology? (Pg 4)
4. How does the OO approach differ from the traditional top-down approach? (Pg 5)
5. What are the advantages of OO development? (Pg 5-6)
6. Name the concepts used in the unified approach. (Pg 11)

8
 CHAPTER-2

Object Basics

 INTRODUCTION TO THE OO APPROACH

 Object-oriented approaches attempt to build models that mimic the “real world”

 Many systems we want to build involve things that exhibit behaviour as well as

having structure, and also may exhibit time-dependent aspects

 OO approaches attempt to consistently capture ALL these aspects [Dennis Hart

2001, Chris Loken 2002]

Functional model (behaviour)

object model (structure)

Dynamic model (temporal aspects)

 Object orientation emerged during the 1970s, particularly in programming

languages like Simula, Smalltalk, Eiffel and, later, C++ and Java

9
  Now there are also object-oriented analysis and design techniques and tools (e.g.

UML), databases and development

 Object-orientation attempts to unify many aspects of the systems analysis and

design process that were disparate before

 Important aspect of OO ==> potential for re-use of development work when OO

techniques are used

 Object-orientation has also been argued to be a more natural approach than other

techniques

 OO CONCEPTS

Attributes Concept of
Object and messages Encapsulation
and method & information
classes hiding

Object
Class Basics aggregation
hierarchy

polymorphism Object
relationships
&
associations

10
 OBJECT AND CLASSES

WHAT IS AN
OBJECT ?

 informally , an object represents an entity, either physical, conceptual, or software

 physical entity

 conceptual entity
Chemical
process
 software entity

Linked List
 A more formal definition

An object is a concept,
abstraction, or thing
with sharp boundaries
and meaning for an

 In an OO system, everything is an object

 Classes are used to distinguish one type of object from another

 A Class = a set of objects that share a common structure and a common behaviour

11
  A single object is simply an instance of a class

 A class is a specification of structure (instance variables), behavior(methods), and

inheritance for objects

 Classes are an important mechanism for classifying objects

 Main role of a class is to define the properties and procedures (the state &

behavior) and applicability of its instances

 Ex :
Class : CAR
Defines the property = color
Each individual car will have a
value for this property, such as
maroon, red, blue or black

 In an OO system, a method or behavior of an object is defined by its class

 Each object is an instance of a class

 ATTRIBUTES AND METHODS

 Objects can be described by their properties (attributes ) and methods (operations)

 Ex:

 CAT
Class name

Colour
Methods Food preference
Size
Weight
Attributes
Class
Catch mouse diagram
Eat
miaow

12
  object behavior is described in methods or procedures

 a method = a function or procedure that is defined for a class and typically can

access the internal state of an object of that class to perform some operation

 operations are things an object does or can have done to it

 in an object model, all data is stored as attributes of some object

 the attributes of an object are manipulated by the operations

 CONCEPT OF MESSAGES

 Objects interact with each other by sending and receiving messages

 Messages are similar ro procedure calls in traditional programming languages

 Objects perform operations in response to messages

Ex : when you press on the brake pedal of a car, you send a STOP message to the car

object. The car object knows how to respond to the STOP message

 ENCAPSULATION & INFORMATION HIDING

 Information hiding is the principle of concealing the internal data and procedures

of an object and providing an interface to each object in such a way as to reveal

as little as possible about its inner workings

 An object is said to encapsulate the data and a program

User cannot see the inside of the object

“capsule”, but can use the object by
calling the object’s methods

13
  Encapsualtion or information hiding is a design goal of an OO system

In object-oriented system, everything is an object and each object is responsible for itself.

For example:
 Windows applications needs windows object that can open themselves on screen and
either display something or accept input.

 Windows object is responsible for things like opening, sizing, and closing itself.

 When a windows display something, that something is an object. (ex)chart.

 Chart object is responsible for maintaining its data and labels and even
for drawing itself.

Review of objects:

The object-oriented system development makes software development easier and more natural
by raising the level of abstraction to the point where applications can be implemented. The name
object was chosen because “everyone knows what is an object is ”. The real question is “what do
objects have to do with system development” rather that “what is an object?”

Object:
A car is an object a real-world entity, identifiably separate from its surroundings. A car
has a well-defined set of attributes in relation to other object.

14
Attributes:
 Data of an object.
 Properties of an object.

Methods:
 Procedures of an object.or
 Behaviour of an object.

The term object was for formal utilized in the similar language. The term object means a
combination or data and logic that represent some real-world entity.

When developing an object oriented applications, two basic questions arise

 What objects does the application need?
 What functionality should those objects have?

Programming in an object-oriented system consists of adding new kind of objects to the

system and defining how they behave. The new object classes can be built from the objects
supplied by the object-oriented system.

Object state and properties (Attributes):

Properties represent the state of an object. In an object oriented methods we want to refer
to the description of these properties rather than how they are represented in a particular
programming language.

15
For example:
An employee object knows how to compute salary. To compute an employee salary, all
that is required is to send the compute payroll message to the employee object.So the
simplification of code simplifies application development and maintenance.

Objects Respond to Messages:

The capability of an object’s is determined by the methods defined for it. To do an
operation, a message is sent to an object. Objects represented to messages according to the
methods defined in its class.

16
For example:
When we press on the brake pedal of a car, we send a stop message to the car object. The
car object knows how to respond to the stop message since brake have been designed with
specialized parts such as break pads and drums precisely respond to that message.

Different object can respond to the same message in different ways. The car, motorcycle
and bicycle will all respond to a stop message, but the actual operations performed are object
specific.It is the receiver’s responsibility to respond to a message in an appropriate manner. This
gives the great deal or flexibility, since different object can respond to the same message in
different ways. This is known as polymorphism.

Objects are grouped in classes:The classification of objects into various classes is based
its properties (states) and behaviour (methods). Classes are used to distinguish are type of object
from another. An object is an instance of structures, behaviour and inheritance for objects. The
chief rules are the class is to define the properties and procedures and applicability to its
instances.

Class Hierarchy:

An object-oriented system organizes classes into a subclass super class hierarchy. The properties
and behaviours are used as the basis for making distinctions between classes are at the top and
more specific are at the bottom of the class hierarchy. The family car is the subclass of car. A
subclass inherits all the properties and methods defined in its super class.

17
Inheritance:

It is the property of object-oriented systems that allow objects to be built from other objects.
Inheritance allows explicitly taking advantage of the commonality of objects when constructing
new classes. Inheritance is a relationship between classes where one class is the parent class of
another (derived) class. The derived class holds the properties and behaviour of base class in
addition to the properties and behaviour of derived class.

18
Dynamic Inheritance:
Dynamic inheritance allows objects to change and evolve over time. Since base classes provide
properties and attributes for objects, hanging base classes changes the properties and attributes of
a class.

Example:
A window objects change to icon and basic again. When we double click the folder the contents
will be displayed in a window and when close it, changes back to icon. It involves changing a
base class between a windows class and icon class.

Multiple Inheritances:
Some object-oriented systems permit a class to inherit its state (attributes) and behaviour from
more than one super class. This kind or inheritance is referred to as multiple inheritances.

For example:
Utility vehicle inherits the attributes from the Car and Truck classes.

Encapsulation and Information Hiding:

Information hiding is the principle of concealing the internal data and procedures of an
object. In C++ , encapsulation protection mechanism with private, public and protected
members.

In per-class protection:
Class methods can access any objects of that class and not just the receiver.

In per-object protection:
Methods can access only the receiver. An important factor in achieving encapsulation is
the design at different classes of objects that operate using a common protocol. This means that
many objects will respond to the message using operations tailored to its class. A car engine is an
example of ncapsulation. Although engines may differ in implementation, the interface between
the driver and car is through a common protocol.

19
Polymorphism:

Poly _ ”many”
Morph _ “form”

It means objects that can take on or assume many different forms.Polymorphism means
that the same operations may behave differently on different classes. Booch defines
polymorphism as the relationship of objects many different classes by some common super class.
Polymorphism allows us to write generic, reusable code more easily, because we can specify
general instructions and delegate the implementation detail to the objects involved.

 POLYMORPHISM

 Poly means “many” and morph means “form”, Polymorphism = many forms

 The same operation may behave differently on different classes

 Mechanism by which several methods can have the same name and implement the

same abstract operation

Ex : Adding two matrices is a different process from adding two integers, BUT it

is still Addition (the message/method invoked)

 OBJECT RELATIONSHIPS & ASSOCIATIONS

 Association represents the relationships between objects and classes

Ex :

Pilot Can fly Flown by Planes

 associations are bidirectional ==> traversed in both directions

 important issue in association is cardinality ==> how many instances of one class

may relate to a single instance of an associated class

20
 AGGREGATIONS

 All objects except the most basic ones, are composed of and may contain other

objects

Ex : a spreadsheet is an object composed of cells, and cells are objects that may

contain text, mathematical formulas, ect.,

 Breaking down objects into the obejcts from which they are composed is

decomposition

 Aggregation  where an attribute can be an object itself

Ex : A car object is an agrregation of engine, seat, wheels and other objects

Car

engine seat wheel

21
Object Relationship and associations:

Association represents the relationships between objects and classes. Associations are
bidirectional. The directions implied by the name are the forward direction and the opposite is
the inverse direction.

A pilot “can fly” planes. The inverse of can fly is “is flown by “. Plane “is flown by” pilot

Cardinality:
It specifies how many instances of one class may relate to a single instance of an associated
class. Cardinality constrains the number of related objects and often is described as being “one”
or “many”.

Consumer-producer association:

A special form or association is a consumer-producer relationship, also known as a client-server

association (or) a use relationship. It can be viewed as one-way interaction. One object requests
the service or another object. The object that makes the request is the consumer or client and the
object that receives the request and provides the service is the producer (or) server

Aggregations:

All objects, except the most basic ones, are composed of and may contain other objects.
Breaking down objects in to the objects from which they are composed is de composition. This is
possible because an objects attributes need not be simple data fields, attributes can reference
other objects. Since each object has an identity, one object can refer to other objects. This is
known as aggregation. The car object is an aggregation of other objects such as engine, seat and
wheel objects.

22
Static and Dynamic Binding:
Determining which function has to be involved at compile time is called static binding. Static
binding optimized the calls. (Ex) function call. The process of determining at run time which
functions to involve is termed dynamic binding. Dynamic binding occurs when polymorphic call
is issued. It allows some method invocation decision to be deferred until the information is
known.

Example:
Cut operation in a edit submenu. It pass the cut operation to any object on the desktop, each or
which handles the message in its own way.

Object Persistence:
Objects have a lifetime. They are explicitly created and can exist for a period of time that has
been the duration of the process in which they were created. A file or database can provide
support for objects having a longer lifeline, longer than the duration of the process for which
they are created. This characteristic is called object persistence.

Meta-Classes:
In an object-oriented system every thing is an object, what about a class? Is a class an object?.
Yes, a class is an object. So, If it is an object, it must belong to a class, such a class belong to a
class called a meta-class (or) class or classes.

23
24
25
 Summary

Finding out about the objects (or more correctly, Classes) involved in a system,
their behavior, the way they change over time, and their interactions with each other, is
the task of Object-Oriented Analysis and Design. Information hiding is the principle of
concealing the internal data and procedures of an object and providing an interface to
each object in such a way as to reveal as little as possible about its inner
workings.Protocol is the set of rules that governs the communication.Static binding is
the process of determining which functions to invoke at compile time is termed as static
binding. The process of determining which functions to invoke at runtime are called as
dynamic binding.

26
 KEY TERMS

Association
Class
Object
Protocol
Information hiding
Static binding
Dynamic binding

KEY TERM QUIZ

1. Association is the relationship between object and classes

2. A Class is a set of objects that share a common structure and a common behaviour
3. A single object is simply an instance of a class
4. Information hiding is the principle of concealing the internal data and procedures of an
object and providing an interface to each object in such a way as to reveal as little as
possible about its inner workings
5. Protocol is the set of rules that governs the communication.
6. Static binding is the process of determining which functions to invoke at compile time
is termed as static binding.
7. The process of determining which functions to invoke at runtime are called as dynamic
binding.

MULTIPLE CHOICE

1. Association is the relationship between object and classes

(a) association (b) aggregation
2. A Class is a set of objects that share a common structure and a common behaviour
(a) class (b) object
3. A single object is simply an instance of a class
(a) class (b) object
4. Information hiding is the principle of concealing the internal data and procedures of an
object and providing an interface to each object in such a way as to reveal as little as
possible about its inner workings
(a) Information hiding (b) encapsulation
5. Protocol is the set of rules that governs the communication.
(a) protocol (b) object (c) class
6. Static binding is the process of determining which functions to invoke at compile time
is termed as static binding.
(a)static binding (b) dynamic binding
7. The process of determining which functions to invoke at runtime are called as dynamic
binding.
(a)static binding (b) dynamic binding

27
REVIEW QUESTIONS:

1. What is an object? (Pg 15)

2. What is the main advantage of OO development? (Pg 14-15)
3. What is polymorphism? (Pg 25)
4. Differentiate between object methods and object attributes
a. (Pg 17-18)
5. What is a class? Explain the class hierarchy. (Pg 21-23)
6. Define inheritance (Pg 23)
7. What is data abstraction? (Pg 21)
8. Why is encapsulation important? (Pg 20)
9. What is data hiding? (Pg 20)
10. What is a protocol? (Pg 21)
11. Differentiate between method and message (Pg 18-19)
12. How are objects identified in an OO system? (Pg 32-33)
13. What is association? (Pg 26)
14. What is a consumer-producer relationship? (Pg 26)
15. Differentiate between static and dynamic binding. (Pg 34)
16. Define object persistence (Pg 34)
17. What are meta-classes? (Pg 34)

28
 CHAPTER-3

Object-oriented Systems Development Life Cycle

CHAPTER OBJECTIVES:

You should be able to define and understand

 The software development process

 Building high quality software
 Object oriented systems development
 Use case driven systems development
 Prototyping
 Component based development
 Rapid application development
INTRODUCTION

Software development

• Analysis, design, implementation, testing & refinement to transform users’ need into

software solution that satisfies those needs

• Object-oriented approach

– more rigorous process to do things right

– more time spent on gathering requirements, developing requirements model &

analysis model, then turn into design model

– need not see code until after 25% development time

SOFTWARE DEVELOPMENT PROCESS

• Process to change, refine, transform & add to existing product

• transformation 1(analysis) - translates user’s need into system’s requirements &

responsibilities

29
 – how they use system can give insight into requirements, eg: analyzing incentive

payroll - capacity must be included in requirements

• transformation 2 (design) - begins with problem statement, ends with detailed design

that can be transformed into operational system

– bulk of development activity, include definition on how to build software, its

development, its testing, design description + program + testing material

• transformation 3 (implementation) - refines detailed design into system deployment

that will satisfy users’needs

– takes account of equipment, procedures, resources, people, etc - how to embed

software product within its operational environment, eg: new compensation

method prg needs new form, gives new report.

Software process – transforming needs to software product

30
Waterfall Model – from ‘what’ to ‘use’

Why waterfall model fails

• When there is uncertainity regarding what’s required or how it can be built

• Assumes requirements are known before design begins

– sometimes needs experience with product before requirements can be fully

understood

• Assumes requirements remain static over development cycle

– product delivered meets delivery-time needs

• Assumes sufficient design knowledge to build product

– best for well-understood product

– inable to cater software special properties or partially understood issues

– doesn’t emphasize or encourage software reuse

• Problem if environment changes

– request changes in programs

31
Building high quality software

• Goal is user satisfaction

– how do we determine system is ready for delivery

– is it now an operational system that satisfies users’needs

– is it correct and operating as we thought it should ?

– Does it pass an evaluation process ?

Approaches to systems testing

• Test according to

– how it has been built

– what it should do

• 4 quality measures

– correspondence
• measures how well delivered system matches needs of operational
environment, as described in original requirements statement
– validation
• task of predicting correspondence (true correspondence only determined
after system is in place)
– correctness
• measures consistency of product requirements with respect to design
specification
– verification
• exercise of determining correctness (correctness objective => always
possible to determine if product precisely satisfies requirements of
specification)

32
 4 Quality Measures

Verification vs Validation
• Verification
– am I building the product right ?
– Begin after specification accepted
• Validation
– am I building the right product ?
– Subjective - is specification appropriate ? Uncover true users’ needs , therefore
establish proper design ?
– Begins as soon as project starts

• Verification & validation independent of each other

– even if product follows spec, it may be a wrong product if specification is wrong
– eg: report missing, initial design no longer reflect current needs
– If specification informal, difficult to separate verification and validation

Object-oriented approach: A use-case driven approach

• Object-oriented software development life cycle consists of
– Object-oriented analysis
– Object-oriented design
– Object-oriented implementation
• Use-case model can be employed throughout most activities of software development

33
– designs traceable across requirements, analysis, design, implementation & testing
can be produced
– all design decisions can be traced back directly to user requirements
– usage scenarios can be test scenarios

Object-oriented Systems Development Approach

34
Using Jacobson et al. life cycle model – traceable design across development

35
Object-oriented software development

• Activities

• Object-oriented analysis - use case driven

• Object-oriented design

• Prototyping

• Component-based development

• Incremental testing

• Encourages

– viewing of system as a system of cooperative objects

– incremental development

Object-oriented analysis - use-case driven

• Use Case, is a name for a scenario to describe the user–computer system interaction.

• Determine system requirements, identify classes & their relationship to other classes in

domain

• To understand system requirements

– need to identify the users or actors

• who are the actors ? How do they use system ?

– Scenarios can help (in traditional development, it is treated informally, not fully

documented)

• Jacobson introduces concept of use case - scenario to describe user-

computer system interaction

36
Use case

• 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

– 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

collaboration

– several scenarios (usual & unusual behaviour, exceptions) needed to understand

all aspects of collaboration & all potential actions

• use cased modeling

– expressing high level processes & interactions with customers in a scenario &

analyzing it

– gives system uses, system responsibilities

• developing use case is iterative

– when use case model better understood & developed, start identifying classes &

create their relationship

Identifying objects

• 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 help establish workable system

– work iteratively between use-case & object models

37
 – incentive payroll - employee, supervisor, office administrator, paycheck, product

made, process used to make product

• Intangible objects ?

– Data entry screens, data structures

• Documentation

– 80-20 rule

– 80% work can be done with 20% documentation

– 20% easily accessible, 80% availbel to few who needs to know

– modeling & documentation inseparatable

• good modeling implies good documentation

Object-oriented Design

• Goal : to design classes identified during analysis phase & user interface

• Identify additional objects & classes that support implementation of requirements

– Eg. add objects for user interface to system (data entry windows, browse

windows)

• Can be intertwined with analysis phase

– Highly incremental, eg. 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, grown not built

Object-oriented Design

• First, build object model based on objects & relationship

• Then iterate & refine model

38
 – Design & refine classes

– Design & refine attributes

– Design & refine methods

– Design & refine structures

– Design & refine associations

Guidelines in Object-oriented Design

• 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

Prototyping

• Prototype – version of software product developed in early stages of product’s life cycle

for specific, experimental purposes

– Enables us to fully understand how easy/difficult it will be to implement some

features of system

– Gives users chance to comment on usability & usefulness of user interface design

– Can assess fit between software tools selected, functional specification & user

needs

– Can further define use cases, makes use case modeling easier

• prototype that satisfies user + documentation -> define basic courses of

action for use cases covered by prototype

39
 • Important to construct prototype of key system components shortly after products are

selected

– Pictures worth a thousand words

– Build prototype with use-case modeling to design systems that users like & need

Prototyping: old & new

• Before: prototype thrown away when industrial strength version developed

• New trend: (eg. rapid application development) prototype refined into final product

– Prototype used as means to test & refine user interface & increase usability of

system

– As underlying prototype design becomes more consistent with application

requirements, more detail can be added to application

– Test, evaluate & build further till all components work properly

Categories of Prototypes

• Horizontal prototype

– Simulation of interface (entire interface in full-featured system)

– Contain no functionality

– Quick to implement, provide good overall feel of system

• Vertical prototype

– Subset of system features with complete functionality

– Few implemented functions can be tested in great depth

• Hybrid prototypes

– Major portions of interface established, features having high degree of risk are

prototyped with more functionality

40
 • Analysis prototype

– Aid in exploring problem domain, used to inform user & demonstrate proof of

concept

– Not used as basis of development, discarded when it has serve purpose

– Final product use prototype concepts, not code

• Domain prototype

– Aid for incremental development of the ultimate software solution

– Often used as tool for staged delivery of subsystems to users/other members of

development team

– Demonstrate the feasibility of implementation

– Eventually evolve into deliverable product

Developing prototypes

• Typical time from few days to few weeks

• Should be done parallel with preparation of functional spec

– Can result in modification of spec (some problems/features only obvious after

prototype built)

• Should involve representation from all user groups that will be affected by project

– To ascertain all that the general structure of the prototype meets requirements

established for overall design

• Purpose of review

– Demo that prototype has been developed according to spec & that final spec is

appropriate

– Collect info about errors & problems in systems, eg user interface problems

41
 – Give management & everyone connected with project glimpse of what technology

can provide

• Evaluation easier if supporting data readily available

• Testing considerations must be incorporated in design & implementation of systems

Implementation: Component-based development

• No more custom development, now assemble from prefabricated components

– No more cars, computers, etc custom designed & built for each customer

– Can produce large markets, low cost, high quality products

– Cost & time reduced by building from pre-built, ready-tested components

– Value & differentiation gained by rapid customization to targeted customers

Component-based development

• Industrialised approach to system development, move form custom development to

assembly of pre-built, pre-tested, reusable software components that operate with each

other

– Application development improved significantly if applications assembled

quickly from prefabricated software components

– Increasingly large collection of interpretable software components could be made

available to developers in both general & specialist catalogs

• Components themselves can be constructed from other components, down to prebuilt

components/old-fashioned code written in prg languages like C

• Visual tools/actual code can be used to glue together components

– Visual glue – Digitalk’s Smalltalk PARTS, IBM VisualAge

• Less development effort, faster, increase flexibility

42
Application Wrapping

• Application/component wrapper

– surrounds complete system, both code & data

– Provides interface to interact with both new & legacy software systems

– Off the shelf not widely available, mostly home-grown within organization

• Software component

– Functional units of prgs, building block offering collection of reusable services

– Can request service form another component or deliver its own services on

request

– Delivery of services independent, component work together to accomplish task

– Components can depend on one another without interfering one another

– Each component unaware of context/inner workings of other components

• Aspects of software development

– OO concept – analysis, design, programming

– Component-based – implementation, system intergration

43
 Component wrapping technology

Component wrapper Component wrapper

Subselect and enter title here

Legacy programs Legacy data

Open Connectivity

Component wrapper Component wrapper

Legacy screens Legacy software packages

Rapid Application Development (RAD)

• Set of tools & techniques to build application faster than typically possible with

traditional methods

• Often used with software prototyping

• Iterational development

– Implement design & user requirements incrementally with tools like Delphi,

VisualAge, Visual Basic, or PowerBuilder

– Begins when design completed

• Do we actually understood problem (analysis) ?

• Does the system do what it is supposed to do (design) ?

• Make improvement in each iteration

44
Incremental testing

• Software development and all of its activities including testing are an iterative process.

• Waiting until after development waste money & time

• Turning over applications to quality assurance group not helping since they are not

included in initial plan

Reusability

• Major benefit of Object-oriented approach

• For objects to be reusable, much effort must be spent of designing it

– Design reusability

• Effectively evaluate existing software components

– Has my problem been solved ?

– Has my problem been partially solved ?

– What has been done before to solve problem similar to this one ?

• Need

– detailed summary info about existing software components

– Some kind of search mechanism

• Define candidate object simply

• Generate broadly/narrowly defined query

Reuse Strategy

• Information hiding
• Conformance to naming standards
• Creation & administration of an object repository
• Encouragement by strategic management of reuse as opposed to constant redevelopment
• Establish target for % of object in project to be reuse

45
  The SW Development Process

 System development can be viewed as a process

 Development = is a process of change, refinement, transformation, or addition to
the existing product
 Generally, the SW development process can be viewed as a series of
transformations, where the output of one transformation becomes the input of the
subsequent transformation. Refer figure 1 :
figure 1 : SW process reflecting transformation from needs to a SW product that satisfies those

needs

Transformation 1

problem

statements
What are the uses of
the system ? analysis

Transformation 2

design
problem system
problem
implementation
software
detail
product

Transformation 3

46
  Transformation 1 (analysis) – translates the user’s needs into system

requirements & responsibilities

 Transformation 2 (design) – begins with a problem statement and ends

with a detailed design that can be transformed into an operational system

 Transformation 3 (implementation) – refines the detailed design into the

system deployment that will satisfy the user’s needs

 The emphasis on the analysis & design aspects of the SW life cycle, is intended to

promote building high-quality SW (meeting the specifications and being adaptable

for change )

47
SUMMARY

KEY TERMS
System Development process
Transformation analysis
Prototypying
Rapid Application Development (RAD)
Component-based development (CBD)

KEY TERM QUIZ

1. System Development process is the process to change, refine, transform & add to
existing product
2. Transformation analysis means translates user’s need into system’s requirements &
responsibilities
3. Prototyping is important to construct a prototype of some of the key system components
shortly after the products are selected
4. Rapid Application Development (RAD) is a set of tools and techniques that can be used
to build an application faster than typically possible with traditional methods.
5. Component-based development (CBD) is an industrialized approach to the Software
development process

48
MULTIPLE CHOICE
1. System Development process is the process to change, refine, transform & add to
existing product
(a) system development process (b) system methodology
2. Transformation analysis means translates user’s need into system’s requirements &
responsibilities
(a) Transformation analysis (b) Transformation design
3. Prototyping is important to construct a prototype of some of the key system components
shortly after the products are selected
(a)Prototyping (b) Horizontal prototype
4. Rapid Application Development (RAD) is a set of tools and techniques that can be used
to build an application faster than typically possible with traditional methods.
(a)RAD (b) CBD
5. Component-based development (CBD) is an industrialized approach to the Software
development process
(a)RAD (b) CBD

REVIEW QUESTIONS
1. What is the waterfall SDLC?
2. What is software development process?
3. What is software correspondence?
4. What is software correctness?
5. What is software validation?
6. What is software verification?
7. How is software verification different from validation?
8. What is prototyping and why is it useful?
9. Write the advantages and disadvantages of prototyping?
10. What is Use Case modeling?
11. What is RAD?
12. Why is CBD important?
13. Why is reusability important?
14. What are the types of prototyping?
15. Define class with example.
16. List the transformation involved in the software development process.

49