1 OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1. INTRODUCTION 1. AN OVERVIEW: OBJECT ORIENTED SYSTEM DEVELOPMENT 1.1 What is Object Oriented System Development? It refers to all activities that go into producing an information system solution. It consists of system analysis, modeling, design, implementation, testing and maintenance. 1.2 What is software development methodology? It is a series of process that, if followed, can lead to the development of an application. The process describes how the work is carried out. Each process consists of a number of steps and rules. 1.3 VIEW OF SOFTWARE: Algorithms +Data structures=Programs. A software system is a set of mechanisms for certain action on certain data. Object Oriented System Development centers on the object, which combine data and functionality. 1.4 OBJECT ORIENTED SYSTEM DEVELOPMENT METHODOLOGY: This development offers a different model from the traditional software which is based on Functions and Procedures. Simply it is a way to develop software by building self contained modules or objects. Object has attributes (data) and methods (functions). For example, Window object is responsible for things like opening, sizing and closing itself. 1.5 Why an Object Orientation? –Advantages: The systems are easier to adapt to changing requirements, easier to maintain, more robust and promote greater design and code reuse. An object orientation Allows working at a higher level of abstraction. Provides a seamless transition among different phases of software development. Encourages good development practices. Promotes reusability.
225
Embed
OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1…anujsinha.weebly.com/uploads/3/7/2/7/37270669/11150h71_-_ooad.pdf · 1 OBJECT ORIENTED ANALYASIS AND DESIGN UNIT -I 1. INTRODUCTION
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
OBJECT ORIENTED ANALYASIS AND DESIGN
UNIT -I
1. INTRODUCTION
1. AN OVERVIEW: OBJECT ORIENTED SYSTEM DEVELOPMENT
1.1 What is Object Oriented System Development?
It refers to all activities that go into producing an information system solution.
It consists of system analysis, modeling, design, implementation, testing and
maintenance.
1.2 What is software development methodology?
It is a series of process that, if followed, can lead to the development of an
application.
The process describes how the work is carried out.
Each process consists of a number of steps and rules.
1.3 VIEW OF SOFTWARE:
Algorithms +Data structures=Programs.
A software system is a set of mechanisms for certain action on certain
data.
Object Oriented System Development centers on the object, which
combine data
and functionality.
1.4 OBJECT ORIENTED SYSTEM DEVELOPMENT METHODOLOGY:
This development offers a different model from the traditional software which is
based on Functions and Procedures.
Simply it is a way to develop software by building self contained modules or objects.
Object has attributes (data) and methods (functions).
For example, Window object is responsible for things like opening, sizing and closing
itself.
1.5 Why an Object Orientation? –Advantages:
The systems are easier to adapt to changing requirements, easier to maintain, more robust
and promote greater design and code reuse.
An object orientation
Allows working at a higher level of abstraction.
Provides a seamless transition among different phases of software development.
Encourages good development practices.
Promotes reusability.
2
1.6 OVERVIEW OF THE UNIFIED APPROACH: 8m
The unified approach (UA) is methodology for software development that is proposed
by the author, UA based on methodologies by Booch, Rumbaugh, Jacobson to combine the
best practice, process and guidelines along with object.
UML: (Unified Modeling Language)
It is a set of notations and conventions used to describe and model an application.
The heart of unified approach is Jacobson‘s use case. The use case represents a
typical interaction between a user and a computer system to capture the user’s goals
and needs.
UA consists of following concepts:
o Use-case driven development.
o Object Oriented Development.
o Object Oriented Design.
o Repository of reusable classes and maximum reuse.
o The layered approach.
o Incremental development and prototyping.
o Continuous testing.
The unified approach road map contains
o Analysis
Identify the users/actors
Develop a simple business model process model
Develop the use case
Interaction diagrams
Classification
o Design
Apply design axioms to design classes, their attributes, methods,
associations, structures and protocols.
Design the access layer
Designing the view layer classes
Iterate and refine the design/ analysis.
o Prototyping and Testing
Prototype user interface
Usability and user satisfaction testing.
2. INTRODUCTION – OBJECT BASICS
2.1 OBJECT BASICS: 16m
A car is an object. It is real world entity.
Identifiably separated from its surroundings. A car has well defined set of attributes or
properties (color, manufacture, cost, and owner) and well defined set of thing you
normally do with it (drive it, lock it, tow it, and carry passengers in it). It is also called
a procedures or methods.
3
2.2 AN OBJECT ORIENTED PHILOSOPHY:
A fundamental characteristic of object oriented program is that it allows the base
concepts of the language to be extended to include ideas and terms closer to those of
its application.
The fundamental difference between object oriented system and their traditional
counter parts is the way in which you approach problems.
Traditional development methods are either Algorithm centric or Data centric.
1. Algorithm-Centric Methodology:
Think of an algorithm that can accomplish the task, and then build data structure
for that algorithm to use.
2. Data -centric Methodology:
Think how to structure the data, and then build the algorithm around the data.
In the object-oriented system, however the algorithm and data structures are
packed together as an object.
The attributes and methods are equal and inseparable parts of the object.
2.3 OBJECTS:
The term Object means a combination of data and logic represents some real world
entity.
For ex, Saab automobile
o Saab represents object.
o The data part is car’s name, color, number of doors, price etc.
o The logic part is the collection of programs such that show mileage, stop, go.
In an object oriented system every thing is an object.
When developing an Object Oriented Application two basics question arise.
1. What Objects does the application need?
2. What functionality should those objects have?
For ex, every Window application needs window object. Each object is responsible for
itself such that opening, sizing, closing itself.
2.4 OBJECTS ARE GROUPED IN CLASSES:
A Class is a set of object s that shares a common structure and common behavior.
A single object is simply an instance of a class.
In an object –oriented system a method or behavior of an object is defined by its class.
Each object is an instance of a class.
Each employee object is responsible for its own data such as number, address, salary,
etc,
4
Sue
Objects Bill
of class Ali
Employee Hal
David
FIGURE 2.1 Sue, Bill, Ali are instances or Objects of class Employee
2.5 ATTRIBUTES: OBJECT STATE AND PROPERTIES:
Properties represent the state of an object.
Fig2.2 The attributes of a car object:
We could represent each property in several ways.
Cost-dollar ,rupees
Color –red ,Number of red paint
Make-manufacture name, model number
2.6 OBJECT BEHAVIOR AND METHODS:
In the object model, object behavior is described in methods or procedures.
Car-> We normally do with it (drive it, lock it…)
Elephant -> It can do on its own (eat a banana, etc…..)
Behavior-> collection of methods.
2.7 OBJECT RESPOND TO MESSAGES:
o However, to do an operation, a message is sent to an object.
o Object performs operations in response to messages.
o For example, when you press on the break pedal of a car, you send a
stop message to the car object.
o The car object knows how to respond to the stop message.
o Breaks have been designed with specialized parts.
MESSAGES:
It’s essentially a nonspecific function calls.
A message is a different from of subroutine call, since different object
can respond to the same message in different ways.
Employee Class
Car
Cost
Color
Model
5
For example, car , motorcycle, bicycle all are respond to stop message,
but actual operations performed are object specific.
Fig 2.3 Object responsible to messages:
Brake
*7
Computepayroll
Methods are similar to functions, procedures or subroutines.
To draw chart
Draw -> message
Draw chart or draw line or draw circle -> chart, line, and circle is
different object.
Each object could act differently
It is important to understand the difference between methods and messages.
For example, you want to tell to make you tomato soup.
Instruction is message.
Way of preparation is method.
Tomato soup is an object
In other words, message is the instruction and method is the implementation.
2.8 ENCAPSULATION AND INFORMATION HIDING: 4m
The wrapping up of data and functions in to a single unit is known as
encapsulation.
Encapsulation protection mechanism, with public, private and protected
members.
Public members accessed from anywhere.
Private members access within a class.
Protected members can be accessed only from subclass.
An object is said to encapsulate the data and program.
This means the user cannot see the inside of the object ‘capsule’, but can use
the object by calling the objects methods.
An important factor in achieving encapsulation, using common protocol.
Example: A car engine.
Although engines may differ in implementation.
The interface between the driver and the car is through common protocol.
Step on the gas to increase power or star the car.
Let up on the gas to decrease power.
Since all drivers know this protocol.
All drivers can use this method in all cars, no matter what engine is in the car.
Car object
5 object
Employee
object
6
2.9 CLASS HIERARCHY:
Object oriented system organizes classes in to subclass-super class hierarchy.
Bus Air bus Omni 8 wheeler car sports car
Fig: 2.4 Class Hierarchy
A subclass inherits all the properties and methods defined in its super class.
Motor vehicle-> super class
Bus, Truck, Car-> subclass
Consider the Bus. Bus is- super class. Air bus, passenger bus –Sub class.
Sub class modifies the attributes of its super class car.
Fig: 2.5 Class hierarchy for ford class:
The Mustang class defines the behaviors of mustang.
The Ford class defines the behaviors of Ford.
The term Super class-> base class. The term sub class-> derived class.
2.9.1 INHERITANCE
Inheritance is a relationship between different classes which share common characteristics.
“If class B inherits class A, then both the operations and information structure in class A
will become part of class B”
Major benefits are simpler, clearer classes, at higher levels of abstraction
Employee, Managing, Director, Truck, Driver
Motor Vehicle
Bus Truck Car
Vehicle
Car
Taurus Mustang Thunder bird
Ford
7
"is an", "inherits from"
Generalization means extracting common properties from a collection of classes and
placing them higher in the inheritance hierarchy, in a ‘super class’.
Much care has to be taken when generalizing (as in the real world) that the property makes
sense for every single subclass of the super class. If this is not the case the property must
not be generalized.
Inheritance:
It allows objects to be built from other objects. (Objects of one class acquire the
properties of object of another class).
Inheritance is a relationship between classes where one class is the parent class or
super class or base class. Another one is the derived class.
Inheritance allows classes to share and reuse behaviors and attributes.
It allows reusability. For ex, The car class defines the general behavior of the car.
The ford class inherits the general behavior and adds specific behaviors.
I know how to stop
Stop method is reusable
I don’t know how to stop
Stop (my Mustang)
Fig: 2.6 Inheritance allows Reusability
Assume, all ford use same breaking system, behaviors share.
However the stop method is not defined in the Mustang class, it’s invoked from ford
Class.
But, Thunder bird has its own antilock breaking system. This class would redefine the
stop method so, the stop method of the ford class never be invoked.
Vehicle
Car
Taurus Mustang Thunder bird
Ford
8
Types of Inheritance:
1. Dynamic Inheritance.
2. Multiple Inheritance.
2.9.1 Dynamic Inheritance:
It allows objects to change and evolve over time.
Since base classes provide properties and attributes for objects, changing base
classes changes the properties and attributes of a class.
It refers to the ability to add, delete or change parents from objects at run time.
2.9.2 Multiple Inheritance: 4m
It permits a class to inherit its state and behaviors from more than one super class.
This kind of inheritance is referred to as multiple inheritance.
For example, a utility vehicle inherits attributes from both the car and Truck
classes.
The benefits of multiple inheritance in a language with single inheritance is to
inherit from the most appropriate class and then add an object of another class as
an attribute.
It is more difficult to understand programs written in multiple inheritance systems.
Fig: 2.7 Utility vehicles inherit attributes from both the car and truck classes.
2.10 POLYMORPHISM: 4m
Poly means “many”. Morph means “Form”. In the OO- System, it means objects that
can take on or assume many different forms.
It means that the same operation may behave differently on different classes.
For ex, The driving is a behavior perform with all cars, the specific behavior can
be different, depending on the kind of car we are driving.
Car Truck Bus
Motor Vehicle
Utility Vehicle
9
Polymorphism allows writing generic, reusable code more easily, because can specify
general instructions and delegate the implementation details to the object involved.
For ex, In a payroll system, Manager, production worker, office worker objects
all will respond to compute payroll message, but the actual operation performed
are object specific.
2.11OBJECT RELATIONSHIPS AND ASSOCIATION:
o Associations represent the relationship between objects and classes.
For ex, “A pilot can fly planes”
Can fly flown by
o Associations are bidirectional. It can traverse in both directions.
o An important issue in association is cardinality. This specifies how many instances
of one class may relate to a single instance of an associated class.
Ex: client-Account relationship where one client can have one or more accounts.
2.11.1 CONSUMER-PRODUCER ASSOCIATION:
It’s a special form of association.
Also known as a client –server association or a use relationship.
It can be viewed as one way interaction.
One object requests the service of another object.
The object makes the request is the customer (or) Client, and object receives the
request and provides the service is the producer or server.
Request for Printing
Fig: 2.9 The Consumer-Producer Association
2.12 AGGREGATION AND OBJECT CONTAINMENT 4m
All objects are composed of and may contain other objects.
For ex, (i) Spread sheet is an object composed of cells.
(ii) Cells are objects that may contain text, mathematical Formulas, video, etc.,
Breaking down objects into the objects from which they are composed is
called Decomposed.
Object attributes need not be simple data fields.
Attributes can reference other objects. This is known as Aggregation, Where an
attribute can be an object itself.
Pilot
c
Planes
Print Server Item
10
Example:
Fig: 2.10 A car is an aggregation of other objects such as engine, seat and wheel objects.
2.13 CASE STUDY- PAYROLL PROGRAM 16m
It process employee’s records. It consists of several classes of employees with particular
payroll requirements and rules for processing each. This company has three types of
employees:
1. Managers receive a regular salary.
2. Office workers receive an hourly wage and are eligible for overtime after 40 hours.
3. Production Workers are paid according to apiece rate.
2.13.1 Structured Approach:
(Refer Book)
2.13.2 The Object Oriented Approach:
The Object Oriented System development consists of
Object Oriented Analysis
Object Oriented Information Modeling
Object Oriented Design
Implementation
Testing, Iteration, Documentation
Each object is entirely responsible for itself. For ex., Employee object is responsible
for things like, computing payroll, printing paychecks, storing data.
First task in the Object Oriented –analysis to find the class of objects.
To identify the attributes of objects.
To identify the behavior.
Car
Engine Seat Wheel
11
Fig 2.11 Class Hierarchy:
2.14 ADVANCED TOPICS:
2.14.1 Object and Identity:
It is a special feature.
Every object it’s own unique identity.
This identity is never confused with another object.
This identity name never change even if all the properties of the object change
Object identity is implemented through some kind of object identifier (OID)
or Unique identifier(UID)
OID’s never reused.
Fig 2.12 The owner property of a car contains a reference to the person instance named Raj.
Car Instance (object)
Make: Saab
Color: red
Model:90os
Owner
Person Instance (object)
Name: Raj
Age: 30
Owns
Employee Name Address Salary
Office Worker
Data Entry Compute Payroll Print Report
Manager
Data Entry Compute Payroll Print Report
Production Worker
Data Entry Compute Payroll Print Report
12
In the object system, the relationship between the car and Raj can be implemented
and maintained by references. A reference is similar to the Pointer in other
programming languages.
Object references directly denote the object to which they refer.
Owner is the property of car Instance, referred to the person instance.
Owns is the property of person instance, referred to a car instance.
2.14.2 STATIC AND DYNAMIC BINDING:
Binding refers to the linking of a procedure call to the code to be executed in response
to the call.
The process of determining at run time which function to invoke is termed Dynamic
binding.
It occurs when polymorphic call issued.
Making this determination earlier, at compile time is called static binding. It optimizes
the calls.
Draw ( ) ->Procedure Call
2.14.3 Object Persistence:
Objects have a life time.
A file or database can provide support for objects having a longer life time
longer than a duration of the process for which they were created.
This Characteristic is called Object persistence.
2.14.4 Meta Classes:
In the O-O-System everything is an object. Numbers ,array, records, fields, file,
form etc.
A class belongs to a class called meta class (or) Class of Classes.
All objects are instances of a class and all classes are instances of Meta class.
OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE: 16m
Shape
Draw ()
Circle Object
Draw (circle)
Box Object
Draw (box)
Triangle Object
Draw (Triangle)
13
3.1 INTRODUCTION:
Software development process consists of analysis, design, implementation, testing
and refinement is to transform user needs in to software solution.
The emphasis is intended to promote the building of high quality software.
3.2 SOFTWARE DEVELOPMENT PROCESS:
System development can be viewed as a process.
The development itself, is a process of change, refinement, transformation or addition
to the existing product.
With in the process, it’s possible to replace one sub process with in a new one.
With this method of change, it’s possible to adapt a new process. The process can
be divide in to small,
Interacting phases called Sub process.
The sub process must be clear and defined.
Sub process must have the following:
A description in term of how it works.
Specification of the input required for the process.
Specification of the output to be produced.
The software development process also can be divided in to smaller, interacting sub
process.
The software development process can be viewed as a series of transformation.
The output of the transformation becomes the input of the subsequent transformation.
Transformation 1
Transformation 2
Transformation 3
TRANSFORMATION 1(ANALYSIS):
It translates the user needs into system requirements and responsibilities.
They use the system can provide insight into user’s requirements.
TRANSFORMATION 2(DESIGN):
Begins with a problem statement and ends with a detailed design.
This transformation includes bulk of the software development activity ,how to build
the software, It’s development and its testing.
Also include design description, program, testing materials.
TRANSFORMATION 3(IMPLEMENTATION):
What are the uses
of the system?
Problem Statement Analysis
Design Implementation Detail
System Software Product
14
It refines the detailed design into the system development that will satisfy the user’s
needs.
This takes in to account the equipment, procedure and people.
For ex, the new compensation method is programmed, new forms are put to use and
new reports can be printed.
An example of the Software development process is the Water fall approach.
THE WATER FALL SOFTWARE DEVELOPMENT PROCESS:
(i) What is to be done? (What is the problem)
(ii) How to accomplish them?
(iii) Which we do it?
(iv) Must test the result?
(v) Finally we use.
The Water fall model is the best way to manage a project with a well
understood product.
It’s based on well established engineering principles.
DISADVANTAGES:
In the real world, the problems are not always well defined.
For example, if a company has experience in building accounting systems, then
building accounting systems, then building another such product based on the
existing design is the best managed with water fall model, as it has been
described.
Where there is uncertainty regarding, what is required or how it can be built, the
water fall model fails.
ADVANTAGES:
It is a best way to manage a project with a well understood product.
It’s based on well established engineering principles.
However ,it’s failure can be traced it’s inability to accommodate
Software’s special properties, and it’s inappropriateness for resolving partially
understood issues.
In neither emphasis nor encourage software reusability.
How
What
Do It
Test
Use
15
3.3 BUILDING HIGH QUALITY SOFTWARE:
The software process transforms the user needs via application domain to a software
solution that satisfies those needs.
Once the system exists, we must test it’s a free of bugs.
High quality products must meet users and expectations.
The ultimate goal of building high quality software is user satisfaction.
To achieve high quality in software we need to answer the following.
How do we determine when the system is ready for delivery?
Is it an operation system that satisfies user’s need?
Does it pass an evaluation process?
There are 2 basic approaches to system testing.
1. How it has been built.
2. What it should do.
In Blum describes system evaluation in terms of four quality Measures
1. Correspondence
2. Correctness
3. Verification
4. Validation
Fig: 3.3 Quality Measures: Validation
Verification
Correctness
Correspondence
CORRESPONDENCE:
Measure how well the delivered system matches the needs of the operational environment
as described in original requirement statement.
VALIDATION:
It is the task of predicting correspondence. It begins as soon as project starts.
CORRECTNESS:
Measures the consistency of the product requirements with respect to the design
specifications.
Requirements Needs Design Software
16
VERIFICATION:
It is the exercise of determining the correctness.
Verification & Validation answer to the following questions:
Verification: Am I building the product right?
Validation: Am I building the right product?
Validation begins as soon as the project starts.
But verification can begin only after a specification has been accepted.
Both are independent of each other.
3.4 OBJECT ORIENTED SYSTEM DEVELOPMENT:
A USE-CASE DRIVEN APPROACH: 8m
The object oriented software development life cycle (SDLC) consists of three macro
process.
1. Object Oriented Analysis
2. Object Oriented Design
3. Object Oriented Implementation
The use case model can be employed throughout most activities of software development.
Analysis
IIIiiiii
Fig 3.4: The OOSD Approach.
Analysis
Ana
Build a Use-Case
Model
Object
Analysis Validate
/Test
Implementation
Design
Using Tools CASE
&/ OO Programming
Languages
User Satisfaction
Usability & QA
Test
Design Classes,
Define Attributes
& Methods
Build Object
& Dynamic
Model
User Satisfaction
Test, Usability Test
& QA Test
Build User
Interface
&
Prototype
17
JACOBSON LIFE CYCLE MODEL:
OOA: Identify Actors OOA: Use Case Model OOA: Course of Action
Dynamic Model OOA: Object Model OOD: Dynamic Model Testing: Usage Scenarios
In the lifecycle model of Jacobson , one can produce design that are traceable across
requirements, Analysis , design, and implementation and testing.
The main advantage is that , all design decisions can be traced back directly to user
requirements.
Usage scenarios can be come test scenarios.
In the Object Oriented System development includes these activities.
The object modeling technique (OMT)) by Jim Rumbaugh describes a method for analysis,
design and implementation of a system using oriented technique.
OMT identifies and models all the objects faster
Details such as class, attributes, methods, inheritance and association can be expressed easily.
Dynamic behavior of object within a system can be described by OMT dynamic model.
Process description and consumer - producer relationship can be expressed using OMT’s
functional model.
OMT consists four phases, which can be performed iteratively:
1. Analysis
The results are objects, dynamic and functional models.
2. System design
The results are a structure of the basic architecture of the system along with high level
strategy decisions.
3. Object design
Produces design document containing detailed objects static dynamic and functional
models.
4. Implementation
This activity produces reusable, extendible, and robust code.
1.1 THE OBJECT MODEL
The object model describes the structure of objects in the system: their identity, relationship to
other objects, attributes, and operations.
It is represented by object diagram.
Client Client
First Name Account Account
Last Name Transaction
PinCode
It is represented graphically with an object diagram. In object diagram classes are
interconnected by association lines.
Each class represents a set of individual objects classes. The association lines establish
relationships among the classes. Each association line represents a set of links from the objects
of one class to the objects of another class.
1.2THE OMT DYNAMIC MODEL
Dynamic Model is detailed consisting of states transitions, actions and events.
State Transition Diagram for the Bank Application user interface.
Client
First Name
Last Name
Pin Code
Account Number
Balance
Deposit
Withdraw Create Transaction
Transaction
Trans Date
Trans Time Trans Type Amount Post Balance
Checking Account
Withdraw
Saving Account
Account has been selected
Selected Checking
or savings account
Nothing is
selected
Select Checking
account
Select transaction
type (withdraw,
deposit, transfer)
Enter the
amount
Confirmation
The OMT state transition diagram is a network of states and events.
Each state receives one or more events, at which time it makes the transition to the next state.
The next state depends on current state as well as events.
1.3 THE OMT FUNCTIONAL MODEL
The OMT data flow diagram (DFD) shows the flow of data between different processes in a business.
An OMT DFD provides a simple and intuitive method for describing business processes.
Carsatium
Bank code
Account
DFD of the ATM System.
Data flow diagrams use four primary symbols
1. The Process is any function being performed; for example, verify password or PIN in the ATM
systems.
2. The Data Flow shows the direction of data element movement; for example: PIN code.
3. The Data Store is a location where data are stored; for example, account is a data store in the
ATM.
4. An External Entity is a source or destination of a data element; for example: the ATM card
reader.
ATM Card
reader
User keyboard
entry
User screen selection
ATM DFD System architect Comment OMT data flow
Select bank
Select card
Verify password
Select account
Update account
User
Process Data store Data flow External entity
Thus, Rumbaugh OMT methodology provides one of strongest tool sets for the analysis and
design of object oriented systems.
THE BOOCH METHODOLOGY
It is usually used object oriented method for designing the system using object
paradigm.
It covers the analysis and design phases of an object oriented system.
Booch defines a lot of symbols to document. Booch starts with class and object
diagrams in the analysis phase and refines these diagrams in various steps . While
generating code we design the symbols .
Booch method consists of the following diagrams.
o Class diagrams
o Object diagrams
o State transition diagrams
o Module diagrams
o Process diagrams
o Interaction diagrams
The Booch methodology prescribes a
o Macro development process and
o Micro development process.
THE MACRO DEVELOPMENT PROCESS
It serves as controlling framework for the micro process and can take weeks or even months.
It primarily concerns with technical management of the system .In macro process, the traditional
phases
of analysis and design are preserved to a large extents.
The steps in the macro development process are,
1. Conceptualization.
During conceptualization, you establish the core requirements of the system. You establish
asset of goals and develop a prototype to prove the concept.
OBJECT MODELING USING BOOCH NOTATION
Super class
Inherits
Inherits
Escort
2. Analysis and development of the model.
Class diagrams are used to describe the roles and responsibilities the objects are to carry
out in performing the desired behavior of the system . Then , you use the object diagram is
used to describe the behavior of the system in terms of scenarios or, alternatively, use the
interaction diagram to describe behavior of the system as scenarios.
3. Design or create the system architecture.
In the design phase, you use the class diagram to decide what classes exist and how they
relate to each other.
The object diagrams to decide what mechanisms are used to regulate how objects
collaborate.
Then the module diagram is used to map out where each class and object should be
declared.
The process diagram to determine to which processor to allocate a process. We also
determine the schedules for multiple processes on each relevant processor.
4. Evolution or Implementation.
Refine the system through many iteration. Produce a stream of software implementations
each of which is a refinement of the prior one.
5. Maintenance.
Make localized changes to the system to add new requirements and eliminate bugs.
Operator::Turn Off Alarm
ortEscoEeE
E
Taurus
Mustang
Car Color
Manufacture cost
cost
Ford
Enable Disable
Alarm Fixed
An alarm class state transition diagram with Booch notation.
THE MICRO DEVELOPMENT PROCESS
Each macro development process has its own micro development processes.
The micro is a description of day to day activities by a single or small group of software
developers.
The micro Development process consists of the following steps:
o Identify classes and objects.
o Identify class and object semantics.
o Identify class and object relationship.
o Identify class and object interfaces and implementation.
THE JACOBSON ET AL. METHODOLOGIES
The Jacobson et al. methodologies (e.g., OOBE,OOSE,and Objectory) cover the entire life
cycle and stress traceability between the different phases, both forward and backward.
This traceability enables reuse of analysis and design work, thus reducing development time.
Then reuse of code we have the use case concept, which evolved with objectory.
USE CASES
Use cases are scenarios for understanding system requirements.
A use case is an interaction between user and a system.
The use case model captures the goal of the user and responsibility of the system to its users.
In the requirement analysis, the use cases are described as one of the following:
Non formal text with no clear flow of events.
Text, easy to read but with a clear flow of events.
Formal style using pseudo code.
Enabled
Sound Alarm
Silence Alarm
Silence d Soundin
g
Disabled
The use case description must contain
o How and when the use case begins and ends.
o The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged.
o How and when the use case will need data stored in the system or will store data in the
system.
o Exceptions to the flow of events.
o How and when concepts of the problem domain are handled.
Every single use case should describe one main flow of events.
An Exceptional or additional flow of events could be added.
The Exceptional use case extends another use case to include additional one.
Some Use Case of a Library.
Library
Member
Supplier
o The use case model employs extends and uses relationships.
o The extends relationship is used when you have one use case that is similar to another
use case but does a bit more.
o It extends the functionality of the original use case.
o The uses relationships reuse the common behavior in different use cases.
o Use cases could be viewed as concrete or abstract.
o An abstract use case is incomplete and has no actors that initiate it but is used
by another usecase.
o This inheritance could be used in several levels.
o Abstract use cases also are the ones that have uses or extend relationships.
Checking out books
Getting an interlibrary loan
Reading books, newspapers
Purchasing supplies
Doing research
OBJECT ORIENTED SOFTWARE ENGINEERING :OBJECTORY
Object Oriented Software Engineering also called objectory. Objectory is a method of object
oriented development with the specific aim to fit the development of large real time systems.
The use case driven development says use case are used in several phases of development
including Analysis, design, validation and testing.
This is a process for industrialized development of software.
This method produces usable and robust system,adapting more easily to changing usage.
This objector is built on several different models.
Use Case Model
The use case model defines the outside actors and inside use case of the systems behavior.
Use Case Model
Express in Testing in
Structured by Realize by Implemented by
Domain Object Model Analysis Model Design Model Implementation Model Testing Model
Domain Object Model
The objects of the real world are mapped in to the domain object model.
Analysis Object Model
The analysis object model present how the source code should be carried out and written.
Implementation Model
It represents the implementation of the system.
Test Model
It constitutes the test plans, specification and reports.
A Process is created when first development project starts and is stopped when the developed
system is taken out of service.
OK
NOTOK
OBJECT ORIENTED BUSINESS ENGINEERING (OOBE)
It is the object modeling at enterprise level.
Use cases are the central vehicle for modeling, providing traceability throughout software
engineering Processes.
Analysis Phase
It defines the system to be built in terms of problem domain object model, requirement
and analysis model.
It reduces complexity and promotes maintainability over the life of the system.
It forms a base for requirements model. This process is iterative.
Jacobson suggests that prototyping with a tool might be useful during this phase to help
specify user interfaces.
Design and Implementation Phase
The implementation environment must be identified for the design model
o DBMS, Distribution of process, Constraints due to programming language.
o Component libraries and Incorporating GUI tools.
It may be possible to identify implementation can be concurrently identified with analysis.
The analysis objects are translated in to design objects for current implementation environments.
Testing Phase
Finally Jacobson describes several testing levels and techniques.
The level include
Unit testing, Integration testing and System testing.
PATTERNS
Any science or engineering discipline must have a vocabulary for expressing its concepts and a
language for relating them to each other.
The concepts of patterns serve for this purpose.
Design patterns was first introduced by a building architect called Christopher Alexander.
The main idea of using patterns is to provide documentation.
Definition
A pattern is instructive information that captures the essential structure and insight of a
successful family of proven solutions to a recurring problem that arises within a certain
context and system of forces.
A good pattern will do the following:
o It solves a problem. Pattern captures solution, not just abstract principles or strategies.
o It is a proven concept. Patterns capture solutions with a track record, not theories or
speculation.
o The solution is not obvious. The best patterns generate a solution to a problem
indirectly -a necessary approach for the most difficult problem of design.
o It describes a relationship. Patterns do not just describe modules, but describe deeper
system structures and mechanisms.
o The pattern has a significant human component. All software serves human comfort
or quality of life; the best patterns explicitly appeal to aesthetics and utility.
Mostly patterns focus on design problems.
Recent patterns encompass all aspects of software engineering including:
Development organization,
Software development process,
Project planning,
Requirements engineering and
Software management
GENERATIVE AND NON GENERATIVE PATTERNS
Generative patterns describe a recurring problem, tell how to generate something and can be
observed in the resulting system architecture they helped shape.
Non generative patterns are static and passive, they describe the recurring phenomena without
saying how to reproduce them.
PATTERN TEMPLATE
Every pattern is expressed as a rule (template) which establishes a relationship between a
context, a System of forces which arises in that context and a configuration which allows
forces to resolve themselves in the context.
Many pattern templates have been defined that represents a pattern.
A pattern should contain certain essential components. They are
1. Name
A meaningful name. A single word or a short phrase to refers to the pattern and the
Knowledge and structure it describes.
Good pattern name form vocabulary for conceptual abstractions.
When the pattern has more than one name it is practice to document these nicknames as
aliases. Some pattern forms also provide a classification of the pattern in addition to its name.
2. Problem
A statement of the problem that describes the goals and objective it wants to reach within the
given context and forces.
3. Context
The preconditions under which the problem are called context. It is the initial configuration of
the system before applying pattern.
4. Forces
A description of relevant forces and constraints and how they interact or conflict with
one another and with the goals we wish to achieve.
5. Solution
Static relationships and dynamic rules describing how to realize the desired outcome.
The static structure tells the form and organization of the pattern, but often the behavioral
dynamics is what makes the patterns “come alive”.
6. Examples
Examples help the reader understand the patterns use and applicability.
Visual examples and analogies are used.
Easy to comprehend examples are highly preferred.
7. Resulting Context
The state configuration of the system after pattern has been applied.
It describes the post condition and side effect of the pattern.
It is called resolution of forces because it describes which forces have been resolved and
which Unresolved and which patterns are applicable.
Documenting resulting context correlates initial context of other patterns.
8. Rationale
A justifying explanation of steps or rules in the pattern.
It explains how forces and constraints are orchestrated.
It tells how pattern works, why it works and why it is “good”.
Rationale provides insight into deep structures and key mechanism on the surface of the
system.
9. Related Patterns
The static and dynamic relationship between this pattern and other within the same
pattern language or system.
Related pattern share common forces.
They also frequently have an initial or resulting context that is compatible with the
resulting or initial context of another pattern.
10. Known Users
The Known occurrences of pattern and its application within existing systems.
It is a proven solution to a recurring problem.
Good pattern begin with an abstract.
This gives a clear picture of pattern and informs of any problems they wish to solve.
A pattern has to identify the target audience.
ANTI PATTERNS
A pattern represents a “best practice” but anti pattern represents “worst practice”.
Anti patterns come in two varieties:
o Those describing a bad solution to a problem that resulted in a bad situation.
o Those describing how to get out of a bad solution and how to proceed from there
to a good solution.
CAPTURING PATTERNS
The process of looking for patterns to document is called pattern mining. (Reverse architecting).
Some guidelines for capturing patterns are
o Focus on practicability.
o Aggressive disregard of originality.
o Non anonymous Review.
o Writes workshop instead of presentations.
o Careful editing.
FRAMEWORKS
Frameworks are a way of delivering application patterns to support best practice.
An experienced programmer almost never codes a program from scratch.
A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new model from scratch.
A framework is a way of presenting a generic solution to a problem that can be applied to all
levels in a development.
A framework is viewed as the implementation of a system of design patterns.
Difference between framework and design pattern.
FRAMEWORK
o Framework is executable software.
o Frameworks are of physical nature.
o They are physical realization of one or more software pattern solution.
o They are not abstract.
o It contains several design patterns
o They are highly specialized.
PATTERN
Patterns represent knowledge and experience about software
Patterns are of logical nature.
Patterns are the instructions for how to implement those solution
Design patterns are more abstract than frameworks.
Design pattern are smaller architectural elements than framework.
Design patterns are less specialized.
THE UNIFIED APPROACH
The unified approach establishes a unifying and unitary framework but utilizing
the unified Modeling Language (UML) to describe the model and document the software
development process.
The main idea is to combine the best practices, notation and diagrams for understanding object
oriented concepts and system development.
The unified approach to software development revolves around the following processes and concepts.
The Processes are,
Use case driven development,
Object Oriented Analysis,
Object Oriented Design,
Incremental development and prototyping,
Continuous testing
O-O Design
Continuous testing
Design Classes
their Attributes
Methods
Association
Structure
O-O Analysis
Develop use-case
Activity diagram
Prototyping
Develop
interaction
Diagram
Identify Classes
relationship
attributes
Refine
and
iterate
Continuous testing
Construction
Component Based Development
User satisfaction
usability tests, quality
Assurance test
Repository
Of use-case Design, UI and
past experiences
patter ns,
documentation
and traceability
Layered
Approach
UML Based
Modeling
Build UML class diagram
Apply design
Axiom
Design
view
And
access
layer and
prototypes
User
satisfaction
usability
tests based
on use case
The methods and technology used include
UML for modeling
Layered approach
Repository for object oriented system development patterns and frameworks.
Components based development. OBJECT ORIENTED ANALYSIS
Analysis is the process of extracting the needs of a system. The goal is to understand problem
domain and system responsibilities.
So we construct several models which concentrate on describing what the system does rather than how
it does it.
OOA process consists of the following steps:
1. Identify the actors.
2. Develop a simple business process model using UML activity diagrams.
3. Develop the use case.
4. Develop interaction diagrams.
5. Identify classes.
OBJECT ORIENTED DESIGN
Unified approach utilizes Jacobson et al’s analysis and interaction diagrams, Booch object diagrams
and Rum Baugh’s domain models.
OOD Process consists of
Designing classes, their attributes, methods, associations, structure and protocols, apply,
design, axioms.
Design the access layer.
Design and prototype UI.
User satisfaction and usability tests based on the Usage/Use Case.
Iterate and refine the design.
ITERATIVE DEVELOPMENT AND CONTINUOUS TESTING
We must iterate and reiterate till we are satisfied with the system.
After testing we repeat the process by reworking, re-prototyping and retesting.
Refining is continued until satisfied results.
During iterative Process, the prototypes will be incrementally transformed into the actual application.
UA starts testing phase from day one of the project.
Usage scenarios become testing scenarios
Usability testing is the process in which the functionality of the software is measured.
MODELING BASED ON UML
UML was developed by joint efforts of leading object technologists Grady Booch, Ivar
Jacobson and James Rumbaugh.
UML uses the best of notations used by Booch, Jacobson and Rumbaugh.
UML become universal language for modeling system.
UML expresses model of many different kinds and purposes.
UML has become standard notation for object oriented modeling systems.
The UA utilizes UML to describe and model the analysis and design phase of system
development.
The UA PROPOSED REPOSITORY
In modern business best practice sharing is a way to ensure that solutions to the process and
organization problems.
It eliminates duplicates of problem solving.
It is a constant goal of quality improvement.
It is applied for quality and productivity. We have to create a repository for maximum reuse of previous experience and
previously defined objects, patterns, frameworks and user interfaces.
The advantages of repository we can select from a repository –data element, diagram,
Symbols, definitions for reuse.
THE LAYERED TO SOFTWARE DEVELOPMENT
System developed with today CASE tools or client- server application development tends to follow
“two layered Architecture”: interface and data.
In a two layered system, user interface screens are tied to data through routines that sit directly behind
the screens.
Work Station
With every interface , we re create the business logic needed to run the screen.
This approach results in objects that are very specialized and cannot be reused in other projects.
Another approach is one that isolates the functions of the interfaces from the functions of the business.
It also isolate business from the details of the data access.
Work Station
We have the three layered approach, where we create objects that represent elements of business and
completely independent of how they are represented to the user (through interface) or how there are
physically stored in a database.
The three layered approach consists of
A view or user interface layer
A business layer
An access layer
OOD and
Prototyping
OOA
OOA,OOD &
Prototyping Three Layered Approach
Data
Data
Access Layer
Business Layer
View Layer
THE BUSINESS LAYER
The Business layer contains all the objects represent the business.
The responsibilities of the layer are
Model the objects of business and how they interact to accomplish the business Processes.
When creating the business layer, however, it is important to keep in mind a couple of things.
These objects should not be responsible for the following:.
Display details.
Display data access details.
Displaying Details
Business object should have no special knowledge of how they are being displayed and by whom.
The details of how to display an object should exist in the interface layer of the object displaying it.
Data Access Details
Business object also should have no special knowledge of” where they come from”.
We don’t bother whether the data are stored and retrieved via SQL or file I/O.
The business objects need to know only whom to talk about being stored or retrieved.
The User interface (view) Layer
This layer consists of objects with which the user interacts as well as the objects needed to
manage or control the interface. The UI layer also is called the view layer.
The applications of view layer are
Responding to user interaction.
Displaying business objects.
Responding to user interaction:
The UI objects must be designed to translate actions by user, such as clicking on a button or
selecting
from a menu, in to an appropriate response.
The response may be to open or close another interface.
Displaying business objects: This layer must paint the best possible picture of the business objects for the user.
Example: Entry fields, list Boxes or Graphs
The UI layer’s objects are identified during object-Oriented design phase.
The requirement for a UI or how a user will use the system is the responsibility of object-oriented
analysis.
Use cases can provide a very useful tool for understanding UI requirements.
THE ACCESS LAYER
It contains objects that know how to communicate with the place where the data actually
reside,
Whether it be a relational database, mainframe, internet or file)
The responsibilities of access layer are:
TRANSLATE REQUEST
The access layer must be able to translate any data- related requests from business layer in to
the appropriate protocol for data access.
(Eg. If customer needs 55552 to be retrieved, the access layer must be able to create the correct
SQL statement and execute it)
TRANSLATE RESULTS
The access layer also must be able to translate the data retrieved back into the appropriate
business objects and pass those objects back up in to the business layer.
Access objects are identified during object- oriented design.
UNIFIED MODELING LANGUAGE
A model is an abstract representation of a system, constructed to understand the system prior to
building or modifying it.
A model provides a means for conceptualization and communication of ideas in a precise form.
Modeling enables us to cope with the complexity of a system.
Modeling frequently is used during many of the phase of the software life cycle, such as
analysis,
design and implementation.
Some of the existing models are
1. Use Case Model:
It define outside (actor) and inside (use case) of the system’s behavior.
2. Domain Object Model:
Objects of the real world are mapped in to the domain object model.
3. Analysis Object Model:
It deals with how source code should be carried out and written.
4. Implementation Model:
It represents implementation of system.
5. Test Model:
It constitutes test plan, specification and reports.
We look at Unified Modeling Language (UML) notations and diagrams. The main idea is to get
exposed to UML Syntax, semantics and modeling constructs.
STATIC AND DYNAMIC MODELS
Models can represent static or dynamic situations.
STATIC MODEL
A static model is a snapshot of systems parameters at rest or at a specific point in time.
They represent the structural or static aspect of a system.
DYNAMIC MODEL
Dynamic model is a collection of procedures or behaviors that reflect the behavior of a system
over time.
Why Modeling?
Good models are essential for communication among project teams. A modeling language must
include.
Model element- Fundamental Modeling concepts and semantics.
Notation- Visual rendering of model elements.
Guidelines –Expression of usage within trade.
The benefits of models are
Clarity –errors are picked easily due to visual examination
Familiarity- used by the people currently works in problem domain.
Maintenance-Visual notation can improve the maintainability of system.
Simplification-It is simple and easily understandable.
Advantages of Modeling are
1. Models are easier to express complex ideas.
2. Easy to understand.
3. Enhance learning and training.
4. Low cost.
5. Manipulation is easier than real time system.
INTRODUCTION TO UML
UML is a graphical language with a set of rules and semantics.
It is a language for specifying, constructing, visualizing and documenting the software
system and its components.
The rules and semantics of a model are expressed in English, in a form known as object
constraint
language (OCL).
The Unified Modeling Language (UML) is a modeling language for specifying,
visualizing, constructing , and documenting the artifacts of a system-intensive process.
The design goals of UML are,
1. Provides user a ready to use so that they can develop and exchange meaningful models.
2. Provide extensibility and specialization.
3. Independent of programming language.
4. Formal basis for understanding modeling language.
5. Encourage the growth of the OO tools markets.
6. Support higher level development concepts.
7. Integrate best practices and methodologies.
UML DIAGRAMS
Every complex system is given by a set of independent views of a model.
Every model may be expressed at different levels.
The UML defines nine graphical diagrams.
Use-Case Diagrams
Class and Object Diagrams
Behavior Diagrams
State chart Diagrams
Activity Diagrams
Interaction Diagrams
Sequence Diagram
Collaboration Diagram
Implementation Diagrams
Component Diagram
Deployment Diagram
UML CLASS DIAGRAM
The UML class diagram referred to as object modeling is the main static analysis diagram.
Class Notation
A class is drawn as a rectangular with three compartment,
Top holds class name.
Middle holds general properties like attributes.
Bottom holds list of operations.
Italics font is used for abstract classes.
Normal (roman) font for concrete classes.
A static diagram is an instance of class diagram.
CLASS NOTATION
Class Interface Notation
Class interface notation is used to describe the externally visible behavior of a class.
Example: A person object may need to interact with bank account to get balance.
Notation is a small circle with name of the interface connected to class.
Length: meter
Fuel capacity
:Gal
Door: int
Boeing 737
Boeing 737
Boeing 737
Length: meter
Fuelcapacity:Gal
Door: int
Lift()
Break()
Person Bank Account
Interface Notation of a class
Binary Association notation
Binary association is a solid line connecting two class symbols.
Each association has two or more roles to which it is connected.
Works For
employer employee
UML uses association navigation or navigability to specify a role affiliated with each end of an
association relationship.
Association Notation.
Here association is navigate in only one direction, from Bank Account to person but not reverse.
Qualifier and Multiplicity
A qualifier is association attribute.
Example: A person is associated to Bank Object through the attribute account.
Qualifier is denoted by small rectangular attached to the end of an association path.
Multiplicity is the range of allowable associated classes .It is given by a range of integers of
the format.
Lower bound....Upper bound
An association can show multiplicity:
• a fixed value (such as 1, 2, or 10) , *
• an asterisk (*) which means many 0...1
• a range of values (for instance 0..3)
• a set of values like 1,3,5,7,11.....* Asociaction Qualifier and
multiplicity
OR Association
Company Person
Bank Account Person
Bank
Account#
Person
An OR Association indicates a situation in which one of the several potential association
may instantiated at one time for any single object.
{or}
Association class
An association having class properties is an association class. It is known by a class symbol attached
by a dashed line to an associate path.
N –ARY ASSOCIATION
It is an association among more than two classes. It is shown as a large diamond with a path
from the diamond to each participant class.
Semester *
* class student *
AGGREGATION AND COMPOSITION
Aggregation is a form of association. A hollow diamond is attached to one of end of the path
to denote aggregation.
Car
Company
Company Person
Works for
Salary
Year
Class Student
Grade Book
Grade
Exam
lab
Person
1 consists of
class
Composition, known as a part of is a form of aggregation with strong ownership to represent
the
component of a complex object. It is referred as part whole relationship.
GENERALIZATION
It is the relationship between more general class and more specific class. It is displayed as a
directed line with a closed, hollow arrow head at the super class end.
Separate target
CLASS DIAGRAM:
Team Player
Vehicle
Bus Truck
Car
USE CASE DIAGRAM
The Use case concept was introduced by Ivar Jacobson in object oriented software
engineering (OOSE).
Use case represent specific flow of events in the system.
Usecase define the outside (actor) and inside (usecase) of the system’s behavior.
A use case diagram is a graph of actors, a set of usecases enclosed by a system
boundary, communication (participation) association between the actors and the
use case, and generalization among the use case.
Use-Case Diagrams (Jacobson)
Interaction of Users with System Components
Actors
External Entity that Interacts with Software
Promote Simulation of Events
Can be People, Classes, Software Tools, etc.
Use-Case Diagram
Graph of Actors and Set of Use Cases Enclosed by System (High-Level) or Class
Boundary
Focus on What Actions, Methods, Functions, etc. are Utilized by Which Actors
Black Box View of System Components
Derived via User Interviews
A use-case diagram shows the relationship among the actors and use case within a
system. A client makes a call that is taken by an operator, who determine s the nature
of the problem. Some calls can be answered immediately; other calls require research
and a return call.
A use case is shown as an ellipse containing use case name. Use case nme can be
placed below or inside the ellipse.
An actor is shown as class rectangle with the level <<actor>> or the label and a stick
figure or just the stick figure with the name of the actor below the figure.
The three representations of an actor are equivalent.
The relationship show in use case diagram are:
1. Communication. The communication relationship of an actor in a use case is shown
by connecting the actor symbol to the usecase symbol with a solid path.
2. Uses. A uses relationship between use case is shown by a generalization arrow from
the use case.
3. Extends. The extends relationship is used when you have one use case that is similar
to.
.
UML INTERACTION DIAGRAM
The main idea in developing interaction diagram is simplicity.
But interaction diagram lose clarity with conditional behavior.
To capture complex behavior in a single diagram, we can go for activity diagrams.
Interaction diagrams are models that describe how groups of objects collaborate to get the
job done.
Interaction diagrams capture the behavior of a single use case, showing the pattern of
interaction among objects.
The diagram shows a number of example objects and the messages passed between
those objects within the use case.
There are two kinds of interaction models:
o Sequence Diagrams.
o Collaboration Diagrams.
UML SEQUENCE DIAGRAM
Sequence diagrams are easy and intuitive way of describing the behavior of a system by
viewing the interaction between the system and its environment.
A sequence diagram shown an interaction arranged in a time sequence.It shows the
objects participating in the interaction by their life lines and the messages they
exchange, arranged in a time sequence.
A sequence diagram has two dimensions:
1. The vertical dimension represents time.
2. The horizontal dimension represents different object.
An object is shown as a box at the top of a dashed vertical line.
The vertical line is called the object’s life line. The life line represents the object’s
existence during the interaction.
Each message is represented by an arrow between the life lines of two objects.
The order in which these messages occur is shown top to bottom of the page.
Message contains message name, arguments and some control information.
A sequence diagram is an alternative way to understand the overall flow of the control
of a program
UML COLLABORATION DIAGRAM
Another type of interaction diagram is the collaboration diagram. A collaboration diagram
represents collaboration, which is a set of messages exchanged among the objects within the
collaboration to achieve a desired outcome.
COMPARING SEQUENCE AND COLLABORATION DIAGRAM
The principal feature of the interaction diagram is their simplicity.
Sequence diagram puts emphasis on sequence. It is easy to see the order in which the
things occur.
Collaboration diagram uses the layout to indicate how objects are statically connected.
UML STATECHART DIAGRAM
A state chart diagram(also called a state diagram) shows the sequence of states that an
object goes through during its life in response to outside stimuli and massages.
The state is the set of values that describes an object at a specific point in time and is
represented by state symbols and the transitions are represented by arrows connecting the
state symbols.
A state chart diagram may contain sub diagrams. A state diagram represents the state of
the method execution and the activities in the diagram represent the activities of the object
that performs that method.
UML ACTIVITY DIAGRAM
An activity diagram is a variation or special case of a state machine, in which the states
are
activities representing the performance of operations and the transitions are triggered by the
completion of the operations.
Activity diagram are useful in connection with workflow and in describing behavior that
has a
lot parallel processing.
The core symbol is “Activity state” or “Activity ”.
Activity is a state of doing something
Either real world process (Example: type a letter)
Or execution of software runtime (Example: method on a class)
Activity diagram describes sequencing of activities, with support for conditional and parallel
behavior.
Activity diagram is a variant of state diagram in which states are activity states.
STATIC: COMPONENT DIAGRAM
Component Diagram: High-Level Interaction and Dependencies Among Software Components
Captures the Physical Structure of the Implementation
Built As Part of Architectural Specification
Purposes:
Organize Source Code
Construct an Executable Release
Specify a Physical Database
Main Concepts: Component, Interface, Dependency, Realization
Developed by Architects and Programmers
Captures the Physical Structure of the Implementation
STATIC: DEPLOYMENT DIAGRAM
Deployment Diagram: Focus on the Placement and Configuration of Components at Runtime
Purposes:
Specify the Distribution of Components
Identify Performance Bottlenecks
Main Concepts: Node, Component, Dependency, Location
Developed by Architects, Networking Engineers, and System Engineers
PACKAGES IN CLASS DIAGRAMS
Complex Class Diagrams are Abstracted
Packages Contain Multiple Classes and are Associated and Linked to One Another
Dependency Arrow is Dashed
Indicates that One Package Depends on Another
Means that Changes in Destination (Dependee - Arrow Head) Can Possible Force
Changes in the Source (Dependent – Arrow Tail)\
Supports Rudimentary SW Architecture Concepts
However, no Checking/Enforcement of Dependencies in Subsequent Diagrams
Example Package
UNIT-III
CHAPTER 6:
OBJECT ORIENTED ANALYSIS: Identifying Use Cases
OBJECTIVES :
At the end of this chapter, students should be able to
• Define and understand the object-oriented analysis process
• Explain the use case modeling process
• Identify actors
• Identify use cases
• Developing use case flow of event
1
Introduction to Object-Oriented Analysis
• Analysis focus on understanding the problem and its domain
• Main objective of analysis capture a complete, unambiguous, and consistent picture of the requirements of the system and what the system must do to satisfy the users’ requirements and needs.
• Analysis = process of transforming a problem definition from a fuzzy
set of facts a coherent statement of a system’s requirements.
• Analysis involves a great deal of interaction with the people who will
be affected by the system
2
Analysis is the process of extracting the needs of a system and what the system must do to satisfy the
users’ requirements.
By constructing models of the system that concerntrate on describing WHAT the system does rather than HOW it does
• Analyst has 4 major tools for extracting information about a system :
o Examination of existing system documentation
o Interviews
o Questionnaire
o Observation
• Why analysis is a difficult activity ?
• Business object analysis is a process of understanding the system’s
requirements and establishing the goals of an application
• The outcome of the business object analysis is to identify classes
that make up the business layer and the relationships that play a role
in achieving system goals
3
3 common sources of requirement difficulties [Norman] :fuzzy descriptionsincomplete requirementsunnecessary features
• To understand users’ requirements :
Find out how they “use” the system, by developing use
cases.
Where Should We Start?ANALYSIS-4 tools for extracting information about
system
• 1. Examination (checking, testing) of existing system documentation.
• 2. Interviews (meeting, discussion).
• 3. Questionnaire (feedback form).
• 4. Observation (inspection, study).
Requirements Difficulties
(WHY ANALYSIS IS A DIFFICULT PROCESS?)
Analysis is a creative activity that involves understanding the problem, its
associated constraints and methods of overcoming those constraints.
Three most common sources of requirements difficulties are:
1. Incomplete requirements.
2. Fuzzy descriptions.
3. Unneeded features
4
Use cases = scenarios for understanding system requirements
Incomplete requirements
• Certain requirements necessary for successful system development are not
included for variety of reasons
• This could include the users forgetting to identify them high cost, politics
within the business, or oversight (error, mistake, failure to notice) by the
system developer
Unneeded features
keep on mind every additional features could affect the performance,
complexity, maintenance, stability (strength) and support costs of an
application
a number of other factors also may affect the design of an application.
Note: Additional features and shortcuts can affect the product
5. classification – develop a static UML class diagram :
a. identify classes
b. identify relationships
c. identify attributes
d. identify methods
6. iterate and refine : if needed, repeat the preceding steps
Business process modelling
• Not necessary for all project
• When required business process and requirements can be modelled to any
level of detail
• Activity diagram support this modelling
• disadvantages
– Time consuming process
• Advantages
– familiarity
7
Use case model
• Senarios for understanding the system
• Interaction bw user and system
• Captures users goal and systems responsibility
• Used to discover classes and relationship
• Developed by talking to users
• Use case model
– Provides external view of the system
• Object model (UML class diagram)
– Provides internal view
Use cases and microscope
• A use case is a sequence of transaction in a system whose task is to yield results of measurable value to an individual actor of the system
• Actor
Go to counter and
return books
Go to counter and check out the books
Interlibrary loan
Search for book
Do research on
topics
Read news paper and magazine
yes
Return book?
yesyes
yes
yes
yesyes
no
no
no
no
borrow book?
Do search
Read newspaper?
Activty diagram –library system
8
– Role played by the user with respect to the system– Single actor may perform many use cases– Can be external system– Can be one get value from the system, or just participate in the use
case
Use-Case Model
• major concepts in Use-Case modeling :
• an actor represents anything that interacts with the
system
• a use case is a sequence of actions a system performs
that yields an observable result of value to a particular
actor
• A use-case model is a model of the system’s intended functions (use
cases) and its surroundings (actors)
• The same use-case model is used in requirement analysis, design, &
test
• Primary purpose is to communicate the system’s functionality and
behavior to the customer or end user
• Benefits of a use-case model :
To communicate with the end users and domain experts
9
ActorUse-case
To identify :
• who will interact with the system and what the system
should do
• what interfaces the system should have
to verify :
• all requirements are captured
• that the developers have understood the requirements
Identifying Actors
• Actors are not part of the system, they represent roles a user of the
system can play (user may play more than one role )
• Actor may actively interchange information with the system
• Actor may be a passive recipient of information
• Actor can represent a human, machine or another system
• The difference between users and actors :
10
Yati
Jamila
Salmi
USER
Borrow book
Check IDs
Order books
USE CASE
volunteer
employee
member
ACTORCan play the role of
performs
Uses and extends association
• Uses
– common sub flows are extracted and separate use case is created
– Relationship bw usecase and extracted one is called uses relationships
• Extends
– Used when use case is similar to other, but do bit more or more
speciliazed
Borrow books
Check library card
Get an interlibrary loan
Return books
Do research
Read books and news paper
Purchase supplies
memberCirculation clerk
supplier
extends
uses
uses
uses
11
• Abstract use case
– No initiating actor
– Used by concrete use cases
• concrete use cases
– Interacts with actors
• Candidates for actors can be found through the answers to the
following questions :
Who is interested in a certain requirement?
Where in the organization is the system used?
Who will supply the system with this information, use this
information, remove this information?
Who will use this function?
Who will support and maintain the system?
Does the system use an external resource?
What actors do the use cases needed?
Does one actor play several different roles? Do several actors
play the same role?
12
• Actors and system boundaries
Identifying Use-Cases
• A use case models a dialogue between actors and the system
• A use case is initiated by an actor to invoke a certain functionality in
the system
• A use case is a complete and meaningful flow of events
• All use-cases constitute all possible ways of using the system
• Steps for finding use-cases :
13
ATM system
Bank system
ATM maintenance
Bank teller
System boundary
For each actor, find the tasks and functions that the actor
should be able to perform or that the system needs the actor to
perform. The use case should represent a course of events that
leads to a clear goal
Name the use-cases
• Provide a general description of the use-case function
• The name should express what happens when an
instance of the use-case is performed
• Often expressed in the form of a verb (borrow) or verb
and noun (Borrow books)
Describe the use-cases briefly by applying terms with which the
user is familiar
• Sources of information for use-cases
System specification /problem statement
Domain relevant literature
Interviews with domain experts
Personal knowledge of the domain
Legacy systems
14
• Use-Case diagram is drawn to illustrate that use-cases and actors
interact by sending stimuli to one another
• Use-cases are connected to actors through association relationships.
• A line drawn from an actor to a use-case depicts an association
• At times a use-case includes the functionality, extends the
functionality, or generalizes the functionality of another use-case on
the diagram. This is shown using include(or uses), extend, and
generalization relationships.
• Includes association :
occurs when you are describing your use-cases and notice that
some of them have subflows in common
to avoid describing a subflow more than once in several use-
cases, you can extract the common subflow and make it a use-
case of its own
15
Conduct bank transactions
Maintain ATM machine
Run reports
ATM Maintenance
Customer Bank
represents the inclusion of the functionality of one use-case
within another
the arrow is drawn from the base use-case to the used use-case
• Extends association :
Used when you have one use-case that is similar to another use-
case BUT does a bit more, or is more specialized (like a
subclass)
Put the base or normal behavior in one use-case and the unusual
behaviors somewhere else
Represents the extension of the use-case to include optional
behavior
The arrow is drawn from the extension use-case to the base use-
case
• Generalization association :
Represents a specialized use-case to a more generalized one
More general use-case being higher than the lower use-cases
The arrow is drawn from the specialized use-case to the base
use-case
Refer to diagram, distribute in the class.
• Each use-case has to be described in a flow of events document. This
textual document defines what the system has to do when actor
activates a use-case.
• The structure of a use-case document can vary.
• Use-cases are documented in
16
• A brief description
o The purpose of the use-case in a few lines
• Detailed flow of events
o Description of the primary and alternate flow of
events that occur when the use-case is initiated
• Documentation should read like a dialogue between the
actor and the use-case
• Use-Case Flow of Events :
Each use-case :
• Has one normal, basic, sequence of transactions
• May have several alternative sequences of transactions
• Usually has several exceptional sequences of transactions
handling erroneous situations
• May also have well defined pre-and post-conditions
Describe only the events that belong to the use-case, and not
what happens in other use-cases
Avoid terminology such as “for example”, “etc.”, and “
information”
The flow of events should describe :• How and when the use-case starts and ends• When the use-case interacts with the actors• What information is excahnged between an actor and the
use-case ( do not describe the details of the user interface )
• The basic flow of events
17
• Any alternate flow of events
How detailed must a use case be? When to stop decomposing it and when
to continue
• Develop system use case diagram
• Draw package
– to represent business domains of the system . for each package
create child use case diagram
• Prepare at lest one scenario for each use case
– Each scenario shows different sequence of interaction , with all
decisions definite
• When the lowest use case level is arrived, which can’t be broken further,
sequence and collaboration diagram is drawn
Dividing use case into package
• Whole system is divided into many packages
• Each package encompasses multiple use cases
Refer to Use-Case Documentation example.
• Each use-case represent a scenario in the system• a design can be broken down into packages, and each of packages
consists multiple use-cases (refer to diagram , distribute in the class )
18
Developing effective 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.
• Important factor in making a decision about committing (assigning,
handover, giving) resources
• Mainly depends on rules and regulation
19
Who reads Use-Case documentation ?
customers
users
system developers
reviewers
system analysts / system
designer
system tester
project leader
technical writer
Guidelines for developing effective documentation:
According to Bell and Evans:
• Common cover
• 80-20 rule
• Familiar vocabulary
• Make the document as short as possible
• Organize the document
1.Common Cover
• All documents should share a common cover sheet that identifies the
document, the current version, and the individual responsible for the
content.
2)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.
3)Familiar Vocabulary
• Use a vocabulary (word, language, expression) that your readers understand
and are comfortable with.
• The main objective here is to communicate with readers and not impress
them with buzz words.
4)Make the Document as Short as Possible
• Eliminate all repetition;
• Present summaries, reviews, organization chapters in less than three pages;
20
• Make chapter headings task (mission) oriented so that the table of
contents also could serve as an index (catalogue, guide,key).
•
5)Organize the Document
Use the rules of good organization (such as the organization's standards,
college handbooks, Strunk and White's Elements of Style, or the University
of Chicago Manual of Style) within each section.
SUMMARY
Analysis is the process of extracting the needs of a system and what the system must do to satisfy the users’ requirements.OOA phase of the unified approach uses actors and use cases to describe the system from users’ perspective.A use-case model is a model of the system’s intended functions (use cases) and its surroundings (actors).A use case models a dialogue between actors and the system.
KEY TERMSUse caseActorUse case modelKEY TERM QUIZ
1. A use-case model is a model of the system’s intended functions (use cases) and its surroundings (actors).2. Use cases are scenarios that describe how actors use the system.3. An actor represents anything that interacts with the system
MULTIPLE CHOICE
1. A use-case model is a model of the system’s intended functions (use cases) and its surroundings (actors). (a) Use case model (b) use cases2. Use cases are scenarios that describe how actors use the system. (a) Use case model (b) use cases3. An actor represents anything that interacts with the system (a) use case model (b) usecases (c) actor
21
REVIEW QUESTIONS
1. What is a use case model?2. Describe the basic activities in OO analysis?3. Who are actors?4. Why are uses and extends associations useful in use case modeling?5. How do you identify actors?6. What is 80-20 rule?
References :
Bahrami, A.(1999). Object Oriented Systems Development,
using the unified modeling language, McGraw-Hill
Object Oriented Analysis and Design using UML, by Rational
Software Corporation
Dennis,A., Wixon,B.H., and Tegarden,D.(2002). Systems Analysis and
Design : An Object Oriented Approach with UML
22
CHAPTER 5:
OBJECT ANALYSIS – CLASSIFICATION
OBJECTIVES :
At the end of this chapter, students should be able to
• Identify classes using the noun phrase strategy• Identify classes using the common class pattern strategy• Identify classes using the CRC strategy• Identify classes using the use case analysis strategy• Identify attributes and methods for classes• Identify relationships between classes• Develop the interaction diagrams (sequence and collaboration diagrams)• Develop the class diagram
23
INTRODUCTION:
Object Analysis : Classification
• Identification of classes is the hardest part of part of OOAnalysis
• Object analysis a process by which we can identify the classes that
play role a role in achieving the system goals & requirements
• Booch states that “ There is no such a thing as the perfect class
structure, nor the right set of objects”
• Classification the categorization of input data (things) into identifiable classes through the extraction of significant features of attributes of the data from a background of irrelevant detail
• Classes are an important mechanism for classifying objects
• The main role of a class is to define the attributes, methods, and applicability of its instances
24
Approaches for identifying classes
• There are 4 alternative approaches for identifying classes :
Noun Phrase Approach
• Proposed by Rebecca Wirfs-Brock, Brian Wilkerson, & Lauren
Wiener
• Read through the requirements or use-cases looking for noun phrases
25
Noun phrase
Common class patterns Use-case
driven, sequence / collaboration modeling
Classes, Responsibilities, and Collaborators (CRC)
• Nouns are listed and divided into 3 categories :
• Guidelines for selecting classes in an application :
26
Nouns in textual description
Classes
Verbs in textual description
Methods of the classes
Considered to be
Considered to be
plurals singularChanged to
Relevant classes
Irrelevant classes
fuzzy classes
Scrap this classes, which either have no purpose or will be unnecessary
Look for nouns and noun phrases in the use-cases
Some classes are implicit or taken from general knowledge
All classes must make sense in the application domain; avoid computer implementation classes – defer them to the design stage
Carefully choose and define class names
• Guidelines in selecting candidate classes from the relevant and fuzzy
categories of classes in the problem domain :
Redundant classes ==> do not keep two classes that express the
same information
Adjectives classes ==> an adjective can suggest a different kind of object, different use of the same object, or it could be utterly irrelevant. If the use of the adjective signals that the behavior of the object is different, then make a new class
Attribute classes ==> objects that are used only as values should be defined or restates as attributes and not as a class
Irrelevant classes ==> each class must have a purpose and should be clearly defined and necessary. Formulate a statement of purpose for each candidate class
Refer figure 1.
27
Review redundant classes
Review irrelevant classes
Review attributes
Review adjectives
Figure 1 : the process of eliminating the redundant classes and refining the remaining classes is not sequential. You can move back and forth among these steps as often as you like
Initial list of noun classes : in vianet bank• Account• Account balance• Amount• Approval process• Atm card• Atm machine• Bank• Bank client• Card• Cash• Check• Checking• Checking account• Client• Client’s account• Currency• Dollar• Envelope• Four digits• Fund• Invalid pin• Message• Money• Password• PIN• Pin code• Record• Savings• Savings account• Step• System• Transaction• transaction history
diagrams) can be used to describe how the use case is realized
in terms of collaborating objects. These diagrams model the
detailed collaborations of the use-case realization.
Class diagrams can be used to describe the classes that
participate in the realization of the use-case, as well as their
supporting relationships. These diagrams model the context of
the use-case realization
37
Use case model Design model
Use case Use case realization
• For each use case realization :
Find classes from use-case behavior
Distribute use-case behavior to classes
• Find Classes from Use-Case Behavior
Technique for finding analysis classes uses 3 different
perspectives of the system to drive the identification of
candidate classes
These 3 perspectives are :
• The boundary between the system and its actors
• The information the system uses
• The control logic of the system
38
System boundary
System information
Use-case behavior coordination
<<boundary>>
<<control>>
<<entity>>
Identification of classes means just that : they should be
identified, named, and described briefly in a few sentences
Boundary Class :
• Intermediates between the interface & something outside
the system
• Types of boundary classes :
o User interface classes
o System interface classes
o Device interface classes
• One boundary class per actor/use-case pair
• Example : finding boundary classes:
Entity Class :
39
Register for courses
RegisterForCoursesForm CourseCatalogSystem
Course Catalog System
Student
• Represent stores of information in the system
• Used to represent the key concepts that the system
manages
• Entity objects (instances of entity classes) are used to
hold and update information about some phenomenon,
such as an event, a person, or some real-life object
• Main responsibilities of entity classes are to store and
manage information in the system
• Entity objects are identified by applying the nouns
approach
• Example : candidate entity classes : Register for Courses
(Create Schedule )
Control Class :
• Is a class used to model control behavior specific to one
or more use-cases
40
CourseOfferring
Student
Schedule
• They represent the dynamics of the system, handling the
main tasks and control flows
• One control class per use case
• Example : finding control classes
• Each control class is responsible for controlling the
processing that implements the functionality described in
the associated use case.
• Naming Classes
A class name should be a singular noun
Class names start with an upper case letter
Underscores are not used
• Names composed of multiple words are pushed together
and the first letter of each additional word is capitalized
41
Register for courses
RegistrationController
Course Catalog System
Student
Example : Student, BillingSystem, CourseRoaster
After naming a class, a brief concise description of the class
should be made
• Focus on the purpose of the class, NOT on the
implementation
The class name and description form the basis for a model
dictionary
Example :
Name : CourseWorking Definition : A class offered by the University
Name : ProfessorWorking Definition : A person teaching classes at the university
• Distribute Use-Case Behavior to Classes
For each use-case flow of events :
• Identify analysis classes
• Allocate use-case responsibilities to analysis classes
• Model analysis class interactions in interaction
diagrams
42
• Interaction Diagrams :
A graphical representation of interactions between objects
2 kinds of interaction diagrams : Sequence diagrams(time
ordered) and Collaboration diagrams (data flow)
• Sequence Diagram
Shows object interactions arranged in time sequence
The diagram shows
• The objects participating in the interaction
• The sequence of messages exchanged
Basic elements :
43
Use case Use-Case Realization
Sequence diagrams
Collaboration diagrams
• Actors : someone/something outside the system that
interacts with the system, either by giving or receiving
information, or both
• Objects: an entity with a well-defined boundary and
identity that encapsulates state and behavior
44
Math 101 Math 101 :
CourseOffering
: CourseOffering
Object nameObject name and Class name
Class name
Object representation in UML
• Messages: communication between two objects that
triggers an event
• Lifelines :represents the existence of the object at a
particular time
• Focus of control :shows the period of time during which
an object is performing an action, either directly or
through a subordinate procedure
• Collaboration Diagram
45
Message
:Prospective Buyer :PersonalPlannerForm
//maintain profile()
//prompt to create new profile()
:Prospective Buyer :PersonalPlannerForm
//maintain profile()
Alternate way to represent the messages exchanged by a set of
objects
The diagram shows object interactions organized around the
objects and their links to each other
Basic elements :
• Actors
• Objects
• Links : a pathway for communication between objects on
a collaboration diagram
• Messages
Example : Collaboration Diagram
The guidelines for naming classes: ◊ The class name should be singular.
46
1:enter id
2:validate id
3:enter current semester
4:create new schedule
5:display
6:get courses
Ali:Student
:AvailableClasses:ScheduleForm
:RegistrationForm
◊ One general rule for naming classes is that you should use names with which the users or clients are comfortable. ◊ The name of a class should reflect its intrinsic nature. ◊ Use readable name. Capitalize class names.
SUMMARY:
Identification of classes is the hardest part of part of OOAnalysis.Classification is the categorization of input data (things) into identifiable classes through the extraction of significant features of attributes of the data from a background of irrelevant detail. The guidelines for naming classes- The class name should be singular, One general rule for naming classes is that you should use names with which the users or clients are comfortable, the name of a class should reflect its intrinsic nature., Use readable name, Capitalize class names.
KEYTERMS
Classes ,Responsibilities, and Collaborators (CRC)ClassificationConcept classPlaces classOrganization classPerson class (or) people classTangible things and devices class
KEY TERM QUIZ
1. Concept class concept is a particular idea or understanding that we have of our world
2. Events class is points in time that must be recorded3. Organization class is a collection of people, resources, facilities, or groups
to which users belong, and their capabilities have a defined mission, whose existence is largely independent of individuals.
4. People class is Known as person, roles, and roles played class5. Places class is a physical locations that the system must keep information
about6. Tangible things and devices class which includes physical objects or
groups of objects that are tangible and devices with which the application interacts
47
7. Classes ,Responsibilities, and Collaborators (CRC) is a technique used for identifying classes’ responsibilities and therefore their attributes and methods
8. Classification is the categorization of input data (things) into identifiable classes through the extraction of significant features of attributes of the data from a background of irrelevant detail.
MULTIPLE CHOICE
1. Concept class concept is a particular idea or understanding that we have of our world
(a) concept class (b) event class (c) organization class (d) people class2. Events class is points in time that must be recorded (a) concept class (b) event class (c) organization class (d) people class3. Organization class is a collection of people, resources, facilities, or groups
to which users belong, and their capabilities have a defined mission, whose existence is largely independent of individuals.
(a) concept class (b) event class (c) organization class (d) people class4. People class is Known as person, roles, and roles played class (a) concept class (b) event class (c) organization class (d) people class5. Places class is a physical locations that the system must keep information
about (a)Places class (b) event class (c) organization class (d) people class6. Tangible things and devices class which includes physical objects or
groups of objects that are tangible and devices with which the application interacts
(a) concept class (b) event class (c) organization class (d) Tangible things and devices class
7. Classes ,Responsibilities, and Collaborators (CRC) is a technique used for identifying classes’ responsibilities and therefore their attributes and methods(a) CRC (B) classification
8. Classification is the categorization of input data (things) into identifiable classes through the extraction of significant features of attributes of the data from a background of irrelevant detail.
(a) CRC (B) classification
REVIEW QUESTIONS
48
1. What are the approaches to identify classes?2. Describe the noun phrase strategy for identifying tentative classes in the problem domain?3. Describe relevant, fuzzy, irrelevant classes.4. How do you select candidate classes from the list of relevant and fuzzy classes?5. Why is identifying classes an incremental process?6. Why is developing a sequence / collaboration diagram a useful activity in identifying classes?7. Mention the uses of CRC8. Why is identifying class hierarchy important in OO analysis?
At the end of this chapter, students should be able to define and understand:
• Analyzing relationship among classes• Identifying association• Association patterns• Class responsibilities
INTRODUCTION
The three types of relationships among objects are Association, Super-Sub structure (also known as generalization hierarchy), Aggregation and a-part-of structure. Association represents a physical or conceptual connection between two or more objects. Binary associations are shown as lines connecting two class symbols. Ternary and higher-order associations are shown as diamonds connecting to a class symbol by lines, and the association name is written above or below the line. We need to identify the system’s responsibilities because responsibilities identify problems that are to be solved. A responsibility serves as a handle for discussing potential solutions. Once the system’s responsibilities are understood, we can start identifying the attributes of the system’s classes.
50
Relationships
• All objects stand in relationship to others on whom they rely for
services and control
• The relationship among objects is based on the assumptions each
makes about the other objects, including what operations can be
performed and what behavior results
• 3 types of relationships among objects :
Association
Super-Sub structure (also known as generalization hierarchy)
Aggregation and a-part-of structure
• ASSOCIATION :
Represents a physical or conceptual connection between two or
more objects
The most general relationship and indicate communication only
Ex : if an object has the responsibility for telling another object
that a credit card number is valid or invalid, the two classes
have an association
Identifying associations begins by analyzing the interactions
between classes
Any dependency relationship between two or more classes is an
association
Examine the responsibilities to determine dependencies
51
The following questions can assists in identifying associations
[Wirfs-Brock, Wilkerson, &Wiener ]:
• Is the class capable of fulfilling the required task by
itself?
• If Not, what does it need ?
• From what other class can it acquire what it needs ?
Association Specifiers
• association names a label that clarifies the meaning of
the association
o usually verbs or verb phrase
o use either an association or a role name, NOT
both
o used during analysis, before sufficient information
exists to use role names
• role names a label that specifies the ‘face’ the class
plays in an association
o usually noun or noun phrase
o use either a role name , or an association name,
NOT both
o roles name are preferable, when information is
available
o always be used during design
52
• multiplicity the number of instances a class relates to
an instance of another class
o defined at both ends of the association line
o multiplicity Indicators :
Many *
Exactly one 1
Zero or More 0..*
One or More 1..*
Zero or One 0..1
Specified range 2..4
Example :
1)
53
1
Person CourseGive lecture
1..*
2)
• SUPER-SUB CLASS RELATIONSHIPS (GENERALIZATION)
A class is part of hierarchy of classes, where the top class is the
most general one and from it descend all other, more
specialized classes
Represents the inheritance relationships between related classes
Also known as generalization hierarchy
Advantage can build on what already have and more
important, reuse what already have
Inheritance allows classes to share and reuse behaviors and
Represents the situation where a class consists of several
component classes
A class that is composed of other classes does not behave like
its part; actually ,it behaves very differently
Example : Aggregation
2 major properties of an aggregation are :
• Transitivity : the property where, if A is part of B and
part B is part of C, then A is part of C.
o Ex : a carburetor is part of an engine, and engine
is aprt of a car, Therefore a carburetor is aprt of a
car
55
CAR
CARBURETOR
RADIOENGINE
• Antisymmetry : the property where, if A is part of B, then
B is not part of A.
o Ex : An engine is aprt of car, BUT car is not part
of an engine
Identifying Attributes
• attributes are things an object must remember
• an attribute is a data definition held by instances of a class (object)
• attributes do not have behavior they are NOT objects
• attribute are simple nouns or noun phrases
names must be unique within a class
• each attribute should have a clear, concise definition
• Example :
• Good attributes for the STUDENT class :
o Name : first and last name
o Major : major field of study
• Bad attribute for the STUDENT class :
o SelectedCourses
[ This is a relationship NOT an attribute ]
• An attribute value is the value of an attribute for a particular object
• Each object has a value for every attribute defined for its class
56
• Example : object of the “LECTURER “ class :
• identifying attributes of a system’s classes starts with understanding
the system’s responsibilities
• system’s responsibilities can be identified byd eveloping use cases
and the desired charactersitics of the applications, such as determining
what information users need from the system
• The following questions help in identifying the responsibilities of
classes and deciding what data elements to keep track of :
What information about an object should we keep track of ? to identify attributes of a class
What services must a class provide ? to identify a class’s methods
• Many attributes are discovered in the flow of events for the use cases
57
AttributesNameStaffIdSubject Taught
Dr.Mohd.AzimA0123Software Quality
Pn.NorhayanaA0224Software Requirement
• Look for nouns that were not considered good candidate
classes
• Others are discovered when the class definition is created
Identifying Methods/operation
• Objects not only describe abstract data but also must provide some
services
• In an object-oriented environment, every piece of data, or object is
surrounded by a rich set of rountines called methods. ( These methods
do everything from printing the object to initializing its variables )
• Operations (methods or behavior) in the object-oriented system
usually correspond to queries about attributes (and sometimes
association) of the objects
• An operation is a service that can be requested from an object to
effect behavior
• Methods are responsible for managing the value of attributes such as
query, updating, reading, and writing;
Example : operation GetBalance, return the value of an account’s
balance
58
• Operation should be name to indicate their outcome NOT the steps
behind the operation
Example :
calculateBalance ( ) poorly namedIt indicates the balance must be calculated this is an implementation decision
GetBalance ( ) Well namedIt indicates the outcome only
• Discovering operations from interaction diagrams
The messages displayed in sequence and/or collaboration
diagrams are usually oeprations of the receiving class
Messages are translated into operations and added to class
diagram
Example :
59
2. Add course
: RegistrationForm : RegistrationManager
RegistrationManager
AddCourse( )
Class Diagram
• A class diagram shows a set of classes, interfaces, and their
relationships
• Model the static view of the system, which supports the functional
requirements of the system
• Made up of the following basic elements :
Classes
Relationships
• Associations
• Aggregations
• Generalizations
• Example :
60
1 1
0..4
1
1
1
1
1
<<boundary>>ScheduleForm
<<entity>>CourseCatalog
<<entity>>StudentRecord
<<entity>>Course
<<control>>RegistrationManager
Adds student to
accesses
SUMMARY
The three types of relationships among objects are Association, Super-Sub structure (also known as generalization hierarchy), Aggregation and a-part-of structure. Association represents a physical or conceptual connection between two or more objects. Binary associations are shown as lines connecting two class symbols. Ternary and higher-order associations are shown as diamonds connecting to a class symbol by lines, and the association name is written above or below the line. We need to identify the system’s responsibilities because responsibilities identify problems that are to be solved. A responsibility serves as a handle for discussing potential solutions. Once the system’s responsibilities are understood, we can start identifying the attributes of the system’s classes. A-part-of relationship, also called aggregation, represents the situation where a class consists of several component classes. A class that is composed of other classes does not behave like its parts; actually, it behaves very differently.
KEY TERMS
AggregationAntisymmetryA part of relationshipAssociationTransitivity
KEY TEM QUIZ
1. ASSOCIATION represents a physical or conceptual connection between two or more objects
2. AGGREGATION (A-APRT-OF RELATIONSHIPS) represents the situation where a class consists of several component classes
61
3. Transitivity is the property where, if A is part of B and part B is part of C, then A is part of C.
4. Antisymmetry is the property where, if A is part of B, then B is not part of A.
MULTIPLE CHOICE
1. ASSOCIATION represents a physical or conceptual connection between two or more objects
(a) Association (b) Aggregation2. AGGREGATION (A-APRT-OF RELATIONSHIPS) represents the
situation where a class consists of several component classes (a) Association (b) Aggregation3. Transitivity is the property where, if A is part of B and part B is part of C,
then A is part of C. (a)Transitivity (b) Antisymmetry4. Antisymmetry is the property where, if A is part of B, then B is not part of
A. (a)Transitivity (b) Antisymmetry
REVIEW QUESTIONS
1. What is association?2. What is generalization?3. How would you identify a super- subclass structure?4. What is an a-part-of structure? Write their properties.5. What guidelines would you use to identify a-part-of structure?6. Is association different from an a-part-of relation?7. What are unnecessary associations? How would you know?8. How do you identify attributes?9. How do you identify methods?10. What are the unnecessary attributes?11. Why do we need to justify classes with one attribute?12. State why documentation is important part of analysis.
62
13. What are the similarities between classes and Use Cases?14. State the difference between the classes and Use Cases.
References :
Bahrami, A.(1999). Object Oriented Systems Development, using the unified modeling language, McGraw-Hill
Object Oriented Analysis and Design using UML, by Rational Software Corporation (2002)
63
UNIT-IV
OBJECT ORIENTED DESIGN
CHAPTER 9
OO Design Process and Design Axioms
OBJECTIVES:
At the end of this chapter, students should be able to
Define and understand the object-oriented design process
Explain the object-oriented design rules
INTRODUCTION
Main focus of the analysis phase of SW development “what needs
to be done”
Objects discovered during analysis serve as the framework for design
Class’s attributes, methods, and associations identified during analysis
must be designed for implementation as a data type expressed in the
implementation language
During the design phase, we elevate the model into logical entities,
some of which might relate more to the computer domain (such as
user interface, or the access layer) than the real world or the physical
domain (such as people or employees). Start thinking how to actually
implement the problem in a program.
The goal to design the classes that we need to implement the
system.
Design is about producing a solution that meets the requirements that
have been specified during analysis.
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)
Importance of Good Design
• Time spent on design decides the success of the software developed.
• Good design simplifies implementation and maintenance of a project.
• To formalize (celebrate, honor) design process, axiomatic (clear) approach is
to be followed
OO design process
Activities of OOD Process
1.Apply design axioms to design classes, their attributes, methods, associations,
structure and protocols.
• 1.1 Refine and complete the static UML class diagram by
adding details to the UML class diagram. This steps
consists of the following activities:
1.1.1 Refine attributes
1.1.2 Design methods and protocols by utilizing
a UML activity diagram to represent the
methods algorithm.
1.1.3 Refine association between classes (if
required)
1.1.4 Refine class hierarchy and design with
inheritance (if required).
1.2 Iterate and refine again.
(2) Design the access layer
• Create mirror classes: For every business class identified and
created, create one access layer
• . Eg , if there are 3 business classes (class1, class2 and class3),
create 3 access layer classes (class1DB, class2DB and
class3DB)
• Identify access layer class relationships
Simplify classes and their relationships – main goal is to eliminate redundant
classes and structures
– Redundant classes: Do not keep 2 classes that perform
similar translate request and translate results activities.
Select one and eliminate the other.
– Method classes: Revisit the classes that consist of only
one or two methods to see if they can be eliminated or
combined with existing classes.
• Iterate and refine again.
(3) Design the view layer classes
– Design the macro level user interface, identifying view layer objects
– Design the micro level user interface, which includes these activities:
(a) Design the view layer objects by applying
the design axioms and corollaries.
(b) Build a prototype of the view layer
interface
– Test usability and user satisfaction
– Iterate and refine
(4) Iterate and refine the whole design. Reapply the design axioms and if needed ,
repeat the preceding steps.
• An axiom is a fundamental truth that always is observed to be valid and for
which there is no counterexample or exception.
• They can not be proven or derived but they can be invalidated by
counterexamples or exceptions.
• A theorem is a proposition that may not be self-evident (clear) but can be
proved from accepted axioms.
• A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
Types of Axioms
• AXIOM-1 (Independence axiom): deals with relationships between system
components such as classes, requirements, software components.
• AXIOM-2 (Information axiom): deals with the complexity of design
Axioms of OOD
• The axiom 1 of object-oriented design deals with relationships between
system components (such as classes, requirements and software
components) and axiom 2 deals with the complexity of design.
• Axiom 1. The independence axiom. Maintain the independence of
components. According to axiom 1, each component must satisfy its
requirements without affecting other requirements. Eg. Let us design a
refrigerator door which can provide access to food and the energy lost
should be minimized when the door is opened and closed. Opening the door
should be independent of losing energy.
• Axiom 2. The information axiom. Minimize the information content of the
design. It is concerned with simplicity. In object-oriented system, to
minimize complexity use inheritance and the system’s built in classes and
add as little as possible to what already is there.
Origin of corollaries.
Types of corollaries
The design rules or corollaries derived from
design axioms are stated below.
• Corollary 1: Uncoupled design with less
information content.
• Corollary 2: Single purpose.
• Corollary 3: Large number of simple classes.
• Corollary 4: Strong mapping.
• Corollary 5: Standardization.
• Corollary 6: Design with inheritance.
Corollary 1: Uncoupled design with less information content.
Coupling
• Coupling is a measure of the strength of association established by a
connection from one object or software component to another.
• Coupling is a binary relationship.
• For example A is coupled with B.
• Coupling is important when evaluating a design because it helps us focus on
an important issue in design.
The degree of coupling
• How complicated the connection is ?
• Whether the connection refers to the object itself or something inside it.
• What is being sent or received?
Cohesion
• Cohesion can be defined as the interactions within a single object or
software component.
Corollaries
• Corollary 1: Uncoupled design with less information content. Highly
cohesive (interconnected) objects can improve coupling because only a
minimal amount of essential information need be passed between objects.
• Corollary 2: Single purpose. Each class must have a single, clearly defined
purpose. While documenting, one should be able to describe the purpose of
a class in few sentences.
• Corollary 3: Large number of simple classes. Keeping the classes simple
allows reusability.
• Corollary 4: Strong mapping. There must be a strong association between
the physical system (analysis’s objects) and logical design (design’s object).
• Corollary 5: Standardization. Promote standardization by designing inter
changeable components and reusing existing classes or components.
• Corollary 6: Design with inheritance. Common behavior (methods) must be
moved to super classes. The superclass-subclass structure must make logical
sense.
Corollary 1: Uncoupled Design with Less Information Content
• Coupling is a measure of the strength of association established by a
connection from one object or software component to another. Coupling is a
binary relationship. It is important for design because a change in one
component should have a minimal impact on the other components.
• The degree or strength of coupling between 2 components is measured by
the amount and complexity of information transmitted between them.
• Object oriented design has 2 types of coupling: interaction coupling and
inheritance coupling.
• Interaction coupling involves the amount and complexity of messages
between components. It is good to have little interaction. The general
guideline is to keep the message as simple and infrequent as possible.
• Objects connected to many complex messages are tightly coupled, meaning
any change to one invariably leads to a ripple (current, flow) effect of
changes in others.
• Inheritance is a form of coupling between super and sub classes.
• A subclass is coupled to its superclass in terms of attributes and methods.
We need high inheritance coupling. For this each specialization class should
not inherit lot of unrelated and unneeded methods and attributes.
• If the superclass is overwriting most of the methods or not using them, then
it is an indication that the inheritance coupling is low.
Types of coupling among objects or components (highest to lowest)
Name Degree of coupling
• Content coupling Very high
• Common coupling High
• Control coupling Medium
• Stamp coupling Low
• Data coupling Very low
• Cohesion: The interactions within a single object or software component is
called cohesion.
• Cohesion reflects the “single-purposeness” of an object.
• Highly cohesive components can lower coupling because only a minimum
of essential information need be passed between components.
• Method cohesion, means that a method should carry one function.
• A method that carries multiple functions is undesirable.
• Class cohesion means that all the class’s methods and attributes must be
highly cohesive, meaning to be used by internal methods or derived classes’
methods.
Corollary 2: Single Purpose
• Every class should be clearly defined and necessary in the context of
achieving the system’s goals.
• When we document a class, we should be able to explain its purpose in a
sentence or two.
• If we cannot, then the class should be subdivided into independent pieces.
• Each method must provide only one service.
• Each method should be of moderate size, no more than a page; half a page is
better.
Corollary 3: Large number of simpler classes, Reusability
• There are benefits in having a large number of simpler classes because the
chances of reusing smaller classes in other projects is high.
• Large and complex classes are too specialized to be reused.
• Object-oriented design offers a path for producing libraries of reusable parts.
Why reusability is not used? Coad and Yourdan
Software engineering textbooks teach new practitioners to build systems from
“first principles”; reusability is not promoted or even discussed
• The “not invented here” syndrome(condition,pattern) and the
intellectual(logical) challenge of solving an interesting software problem in
one’s own unique way mitigates against reusing someone else’s software
component.
• Unsuccessful experiences with software reusability in the past have
convinced many practitioners and development managers that the concept is
not practical.
• Most organizations provide no reward for reusability; sometimes
productivity (output, efficiecy) is measured in terms of new lines of code
written plus a discounted credit
Corollary 4: Strong mapping
• A strong mapping links classes identified during analysis and classes
designed during the design phase eg view and access classes.
• The analyst identifies objects’ types and inheritance, and thinks about events
that change the state of objects.
• The designer adds detail to this model perhaps designing screens, user
interaction, and client-server interaction.
Corollary 5: Standardization
• To reuse classes, we must have a good understanding of the classes.
• Most object-oriented systems come with several built-in class libraries.
• But these class libraries are not always well documented.
• Sometimes they are documented, but not updated.
• They must be easily searched, based on users’ criteria.
Corollary 6: Designing with inheritance
• When we implement a class, we have to determine its ancestor, what
attributes it will have, and what messages it will understand.
• Then we have to construct its methods and protocols.
• Ideally, one has to choose inheritance to minimize the amount of program
instructions.
• The primitive form of reuse is cut-and-paste reusability.
Achieving Multiple Inheritance in a Singe Inheritance System
• Single inheritance means that each class has only a single super class.
• The result of using a single inheritance hierarchy is the absence of
ambiguity as to how an object will respond in a given method;
• We simply trace up the class tree beginning with the object’s class, looking
for a method of the same name.
• But languages like LISP or C++ have a multiple inheritance scheme
whereby objects can inherit behavior from unrelated areas of the class tree.
• The complication here is how to determine which behavior to get from
which class, particularly when several ancestors define the same method.
• One way of resolving this is to inherit from the most appropriate class and
add an object of mother class as an attribute or aggregation. The other is to
use the instance of the class (object) as an attribute.
CommercialVehicle PrivateVehicle
Lisence
Lisencee
CommercialVehiclee PrivateVehiclee
FoodTruck
Restuarant
Lisencee
CommercialVehiclee PrivateVehiclee
FoodTruck
Restuarant
Design Patterns
• A design pattern provides a scheme for refining the subsystem or
components of a software system or the relationships among them.
• They allow systems to share knowledge about their design, by describing
commonly recurring structures of communicating components that solve a
general design problem within a particular context
SUMMARY
The basic goal of the axiomatic approach is to formalize the design process
and assist in establishing a scientific foundation for the object-oriented design
process, so as to provide a fundamental basis for the creation of systems. Without
scientific principles, the design field never will be systematized and so will be
difficult to comprehend, codify, teach and practice. The main activities in design
process are
◊ Designing classes (their attributes, methods, associations, structures, and
protocols) and applying design axioms. If needed, this step is repeated.
◊ Designing the access layer.
◊ Designing the user interface (view layer classes).
◊ Testing user satisfaction and usability, based on the usage and use cases.
◊ Iterating and refining the design.
An axiom is a fundamental truth that always is observed to be valid and for
which there is no counterexample or exception. The axioms cannot be proven or
derived but they cannot be invalidated by counterexamples or exceptions. There
are two design axioms applied to object-oriented design. Axiom 1 deals with
relationships between system components and Axiom 2 deals with the complexity
of design.
Axiom 1: The independence axiom. Maintain the independence of components.
Axiom 2: The information axiom. Minimize the information content of the
design.
A corollary is a proposition that follows from an axiom or another
proposition that has been proven. A corollary is shown to be valid if its referent
axioms and deductive steps are valid. The design rules or corollaries derived from
design axioms are stated below.
Corollary 1: Uncoupled design with less information content.
Corollary 2: Single purpose.
Corollary 3: Large number of simple classes.
Corollary 4: Strong mapping.
Corollary 5: Standardization.
Corollary 6: Design with inheritance.
KEY TERMS
Axioms
Cohesion
Corollary
Coupling
Design pattern
Theorem
KEY TERM QUIZ
1. An axiom is a fundamental truth that always is observed to be valid and for
which there is no counterexample or exception.
2. A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
3. Design Patterns provides a scheme for refining the subsystems or
components of a software system or the relationships among them
4. A theorem is a proposition that may not be self-evident but can be proven
from accepted axioms. Therefore, is equivalent to a law or principle.
5. Cohesion can be defined as the interactions within a single object or
software component.
6. Coupling deals with interactions between objects or software components.
MULTIPLE CHOICE
1. An axiom is a fundamental truth that always is observed to be valid and for
which there is no counterexample or exception.
(a) Axiom (b) corollary
2. A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
(a) Axiom (b) corollary
3. Design Patterns provides a scheme for refining the subsystems or
components of a sw system or the relationships among them
(a) Design pattern (b) Theorem
4. A theorem is a proposition that may not be self-evident but can be proven
from accepted axioms. Therefore, is equivalent to a law or principle.
(a) Design pattern (b) Theorem
5. Cohesion can be defined as the interactions within a single object or
software component.
(a) Cohesion (b) Coupling
6. Coupling deals with interactions between objects or software components.
(a) Cohesion (b) Coupling
REVIEW QUESTIONS
1.What is the task of design?
2. What is the significance of Occam’s razor?
3. Define axiom.
4. Define theorem and corollary.
5. What is coupling?
6. State the different type of coupling.
7. Define cohesion.
8. What is basic activity in designing an application?
9. List the Object Oriented design axioms and corollaries.
10. What is the relationship between coupling and cohesion?
References :
Bahrami, A.(1999). Object Oriented Systems Development,
using the unified modeling language, McGraw-Hill
Object Oriented Analysis and Design using UML, by Rational
Software Corporation (2002)
CHAPTER 10
Designing Classes
OBJECTIVES :
At the end of this chapter, students should be able to
Designing classes
Designing protocols and class visibility
Designing methods
Develop statechart diagrams
Develop packages
INTRODUCTION
Most important activity in designing an application is coming up with
a set of classes that work together to provide the needed functionality
Underlying the functionality of any application is the quality of its
design
This chapter focus on guidelines & approaches in designing classes
and their methods
Use the OCL (Object Constraint Language- a specification language,
provided by UML ) to specify the properties of a system
Designing Classes
• Object-oriented design requires taking the object identified during object-
oriented analysis and designing classes to represent them.
• As a class designer, we have to know the specifics of the class we are
designing and also we should be aware of how that class interacts with other
classes.
Object oriented design philosophy
• Here one has to think in terms of classes. As new facts are acquired, we
relate them to existing structures in our environment (model).
• After enough new facts are acquired about a certain area, we create new
structures to accommodate the greater level of detail in our knowledge.
• The important activity in designing an application is coming up with a set of
classes that work together to provide the functionality we desire.
• If we design the classes with reusability in mind, we will gain a lot of
productivity and reduce the time for developing new applications.
Designing Classes : the process
Class visibility: Designing well-defined public, private and protected protocols
• In designing methods or attributes for classes, we are confronted (dealed)
with two problems.
• One is the protocol or interface to the class operations and its visibility and
the other is how it is implemented.
• The class’s protocol or the messages that a class understands, can be hidden
from other objects (private protocol) or made available to other objects
(public protocol).
• Public protocols define the functionality and external messages of an object.
• Private protocols define the implementation of an object.
Visibility
• A class might have a set of methods that it uses only internally, messages to
itself. This private protocol of the class, includes messages that normally
should not be sent from other objects. Here only the class itself can use the
methods.
• The public protocol defines the stated behavior of the class as a citizen in a
population and is important information for users as well as future
descendants, so it is accessible to all classes. If the methods or attributes can
be used by the class itself (or its subclasses) a protected protocol can be
used. Here subclasses can used the method in addition to the class itself.
• The lack of well-designed protocol can manifest itself as encapsulation
leakage. It happens when details about a class’s internal implementation are
disclosed through the interface.
Encapsulation leakage
• Encapsulation leakage is lack of a well-designed protocol
• The problem of encapsulation leakage occurs when details about a class’s
internal implementation are disclosed through the interface.
• As more internal details become visible, the flexibility to make changes in
the future decreases.
Visibility types
Attribute representations :
• During design, OCL ( Object Constraint Language) can be used to define the
class attributes
OCL
• The rules and semantics of the UML are expressed in English, in a form
known as object constraint language.
• Object constraint language (OCL) is a specification language that uses
simple logic for specifying the properties of a system.
Attribute presentation suggested by UML :
Designing classes: Refining attributes
• Attributes identified in object-oriented analysis must be refined with an eye
on implementation during this phase.
• In the analysis phase, the name of the attribute is enough.
• But in the design phase, detailed information must be added to the model.
• The 3 basic types of attributes are:
(1) Single-value attributes
(2) Multiplicity or multivalue attributes
(3) Reference to another object or instance connection
Attributes
• Attributes represent the state of an object.
• When the state of the object changes, these changes are reflected in the value
of attributes.
• Single value attribute has only one value or state. (Eg). Name, address,
salary
• Multiplicity or multivalue attribute can have a collection of many values at
any time.
• (Eg) If we want to keep tact of the names of people who have called a
customer support line for help.
Multi value attribute
• Instance connection attributes are required to provide the mapping needed
by an object to fulfill its responsibilities.
• (E.g.) A person may have one or more bank accounts.
• A person has zero to many instance connections to Account(s).
• Similarly, an Account can be assigned to one or more person(s) (joint
account).
• So an Account has zero to many instance connection to Person(s).
Designing methods and protocols
• A class can provide several types of methods:
• Constructor: Method that creates instances (objects) of the class
• Destructor: The method that destroys instances
• Conversion Method: The method that converts a value from one unit of
measure to another.
• Copy Method: The method that copies the contents of one instance to
another instance
• Attribute set: The method that sets the values of one or more attributes
• Attribute get: The method that returns the values of one or more attributes
• I/O methods: The methods that provide or receive data to or from a device
• Domain specific: The method specific to the application.
Design goals
• To maximize cohesiveness (interconnection) among objects and software
components to improve coupling (combination, pairing), because only a
minimal amount of essential information should be passed between
components.
• Abstraction leads to simplicity and straight- forwardness and, at the same
time, increases class versatility (flexibility, resourcefulness, usefulness).
Five rules/ characteristics of bad design
• If it looks messy (confused, disorder), then it’s probably a bad design.
• If it is too complex, then it’s probably a bad design.
• If it is too big, then it’s probably a bad design.
• If people don’t like it, then it’s probably a bad design.
• If it doesn’t work, then it’s probably a bad design.
NOT NULL Description CHAR(25) NOT NULL Price DECIMAL
(9,2));
Data Manipulation Language and Query Capabilities
• Asking Questions, formally making queries of the data – is a typical and
common use of a database. A query is expressed through a query
language. A Data Manipulation Language (DML) is the language that
allows users to access and manipulate (such as create, save or destroy)
data organizations. The SQL is the standard DML for relational
DBMSs. The query usually specifies
• The domain of the discourse over which to ask the query
• The elements of general interest
• The conditions or constraints that apply
• The ordering, sorting or grouping of elements and the constraints that
apply to the ordering or grouping
DML
• Query processes have sophisticated “engines” that determine the best
way to approach the database and execute the query over it. The may
use the information in the database or knowledge of the whereabouts of
particular data in the network to optimize the retrieval of a query.
• DML are either procedural or nonprocedural. A Procedural DML
requires users to specify what data are desired and how to get the data.
• A non-procedural DML requires users to specify what data are needed
but not how to get the data. Object-oriented query and data
manipulation languages, such as Object SQL, provide object
management capabilities to the data manipulation language.
• In a relational DBMS, the DML is independent of the host
programming language.
• A host language such as C or COBOL would be used to write the body
of the application. SQL statements then are embedded in C or COBOL
applications to manipulate data.
• Once SQL is used to request and retrieve database data, the results of
the SQL retrieval must be transformed into the data structures of the
programming language.
• The drawback here is that the programmers code here in two
languages, SQL and the host language.
Logical and Physical Database Organization and Access Control
• Logical database organization refers to the conceptual view of database
structure and the relationships within the database. Physical database
organization refers to how the logical components are represented in a
physical form by operating system constructs eg objects may be
represented as files.
Shareability and Transactions
• Data and objects in the database need to be accessed and shared by
different applications. With multiple applications having access to the
object concurrently, it is likely that conflicts over object access will
arise. The database must detect and mediate these conflicts and
promote maximum amount of sharing without any data integrity
problem. This mediation process is managed through concurrency
control policies, implemented, by transactions.
Transactions
• Transaction is a unit of change in which many individual modifications
are aggregated into a single modification that occurs in its entirety or
not at all. Thus either all changes to objects within a given transaction
are applied to the database or none of the changes. A transaction is said
to commit if all changes can be made successfully to the database and to
abort if canceled because all change to the database cannot be made
successfully. This ability of transactions ensures atomicity of change
that maintains the database in a consistent state.
• Many transaction systems are designed for short transactions (lasting
for minutes). They are less suitable for long transactions, lasting hours.
Object databases are designed to support both short and long
transactions. A concurrent control policy dictates what happens when
conflicts arise between transactions that attempt to access to the same
object and how these conflicts are to be resolved.
Concurrency Policy
• When several users attempt to read and write the same object
simultaneously, they create a contention (conflict) for object. Then
concurrency control mechanism is established to mediate such conflicts
by making policies that dictate how they will be handled.
• To provide consistent view, the transactions must occur in serial order.
A user must see the database as it exists before a given transaction
occurs or after the transaction.
Concurrency issues
• The conservative way of enforcing serialization is to allow a user to lock
all objects or records when they are accessed and to release the locks
only after a transaction commits. This is called conservative or
pessimistic policy. It provides exclusive access to the object, despite
what is done to it. The policy is conservative because no other user can
view the data until the object is released.
• By distinguishing between querying (reading) the object and writing to
it, greater concurrency can be achieved. This policy allows many
readers of an object but only one writer.
• Under an optimistic policy, two conflicting transactions are compared in
their entirety and then their serial ordering is determined.
• A process can be allowed to obtain a read lock on an object already
write locked if its entire transaction can be serialized as if it occurred
either entirely before or entirely after the conflicting transaction.
• The reverse also is true. A process may be allowed to obtain a write
lock on an object that has a read lock if its entire transaction can be
serialized as if it occurred after the conflicting transaction. Now the
optimistic policy allows more processes to operate concurrently than the
conservative policy.]
Distributed Databases and Client-Server Computing
• In distributed databases, portions of the database reside on different
nodes and disk drives in the network.
• Each portion of the database is managed by a server.
• The server sends information to client applications and makes queries
or data requests to these client applications or other servers.
Client-Server Computing
• It is the logical extension of modular programming. In modular
programming we separate a large piece of software into its constituent
parts (modules). This makes development easier and gives better
maintainability.
• In client-server computing all those modules are not executed within the
same memory space or even on the same machine. Here the calling
method becomes “client” and the called module becomes the “server”.
• The important component of client-server computing is connectivity,
which allows applications to communicate transparently with other
programs or processes, regardless of their locations. The key element of
connectivity is the network operating system (NOS), known as
middleware. The NOS provides services such as routing, distribution,
messages, filing, printing and network management.
• Client programs manage user interface portion of the application,
validate data entered by the user, dispatch requests to server program
and executes business logic. The business layer contains all the objects
that represent the business.
• The client-based process is the front-end of the application, which the
user sees and interacts with. It manages the local resource with which
the user interacts, such as the monitor, keyboard, workstation, CPU and
peripherals.
• A key component of a client workstation is the graphical user interface
(GUI). It is responsible for detecting user actions, managing the
Windows on the display and displaying the data in the Windows.
• The server process performs back-end tasks.
• Client – Node that request for a service
• Server – Node that services the request.
• Client Server computing is the logical extension of modular
programming.
• The fundamental concept behind the modular programming is
decomposing the larger software in to smaller modules for easier
development and maintainability.
• Client Server computing is developed by extending this concept i.e,
modules are allowed to execute in different nodes with different
memory spaces.
• The module that needs and request the service is called a client and the
module that gives the service is called a server.
• The network operating system is the back bones of this client sever
computing.
• It provides services such as routing, distribution, messages, filing and
printing and network management. This Network Operating System
(NOS) is called middleware.
Client Program:
• It sends a message to the server requesting a service (task done by
server).
• Manages User Interface portion of the application.
• Performs validation of data input by the user.
• Performs business logic execution (in case of 2 tier).
• Manages local resources.
• Mostly client programs are GUI.
Server Program:
• Fulfills the task requested by the client.
• Executes database retrieval and updation as requested by the client.
• Manages data integrity and dispatches results to the client.
• Some cases a server performs file sharing as well as application services.
• Uses power full processors and huge storage devices.
• File Server – Manages sharing of files or file records. Client sends a
message to the file server requesting a file or file record. The File Server
checks the integrity and availability of file/record.
• Data Base Servers – Client pass the SQL query in the form of messages
to the server in turn server performs the query and dispatches the
result.
• Transaction Servers – Client sends message to the server for a
transaction (set of SQLstatements) where the transaction succeeds or
fails entirely.
• Application Servers – Application servers need not to be database
centric. They may Serve any of user needs such as sending mails,
regulating download.
Characteristics of Client Server Computing
1. A combination of client/ front end process that interacts with the user
and server/ backend process that interacts with the shared resources.
2. The front end and back end task have different computing resource
requirements.
3. The hardware platform and operating system need not be the same.
4. Client and Server communicate through standard well defined Application
Program Interface(API).
5. They are scalable.
File server Vs Database server
• The server can take different forms. The simplest form of server is a file
server. With a file server, the client passes requests for files or file records
over a network to the file server. This needs a large bandwidth and can slow
down a network with many users. Traditional LAN computing allows users
to share resources such as data files and peripheral devices.
• Advanced forms of servers are database servers, transaction servers, and
application servers and object servers. With database servers, clients pass
SQL requests as messages to the server and the results of the query are
returned over the network. Both the code that processes the SQL request
and the data reside on the server, allowing it to sue its own processing power
to find the requested data. This is in contrast to the file server, which
requires passing all the records back to the client and then letting the client
find its own data.
Transaction Servers
• With transaction servers, clients invoke remote procedures that reside
on servers, which also contain an SQL database engine. The server has
procedural statements to execute a group of SQL statements
(transactions), which either all succeed or fail as a unit.
• Applications based on transaction servers, handled by on-line
transaction processing (OLTP), tend to be mission-critical applications
that always require a 1-3 second response time and tight control over
the security and integrity of the database. The communication
overhead in this approach is kept to a minimum, since the exchange
consists of a single request and reply (as opposed to multiple SQL
statements in database servers).
N-tier architecutre
• In a two-tier architecture, a client talks directly to a server, with no
intervening server. This type of architecture is used in small environments
with less than 50 users. To scale up to hundreds or thousands of users, it is
necessary to move to a 3-tier architecture.
• Three-tier architecture introduces a server between the client and the server.
The role of the application or Web server is manifold. It can provide
translation services, metering services (transaction monitor to limit the
number of simultaneous requests to a given server) or intelligent agent
services (mapping a request to a number of different servers, collating the
results, and returning a single response to the client).
Basic characteristics of client-server architectures
• The client process contains solution-specific logic and provides the interface
between the user and the rest of the application system. The server process
acts as a software engine that manages shared resources such as databases,
printers, modems or processors.
• The front end task and back-end task have fundamentally different
requirements for computing resources such as processor speeds, memory,
disk speeds and capacities and i/o devices.
• The environment is heterogeneous and multivendor. The h/w platform and
o/s of client and server are not the same.
• They can be scaled horizontally and vertically. Horizontal scaling means
adding or removing client workstations with only a slight performance
impact. Vertical scaling means migrating to a larger and faster server
machine.
Distributed and Cooperative Processing
• Distributed processing means distribution of applications and business logic
across multiple processing platforms. It implies that processing will occur
on more than one processor to complete a transaction. The processing is
distributed across 2 or more machines, where each process performs part of
an application in a sequence. These processes may not run at the same time.
• Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction. Here programs interact and
execute concurrently on different processors
Common Object Request Broker Architecture
• It is used to integrate distributed, heterogeneous business applications
and data. The CORBA interface definition language (IDL) allows
developers to specify language-neutral, object-oriented interfaces for
application and system components. IDL definitions are stored in an
interface repository that offers object interfaces and services. For
distributed enterprise computing, the interface repository is central to
communication among objects located on different systems.
• CORBA implements a communication channel through which
applications can access object interfaces and request data and services.
• The CORBA common object environment (COE) provides system level
services such as life cycle management for objects accessed through
CORBA, event notification between objects and transaction and
concurrency control.
Microsoft’s ActiveX/DCOM
• Microsoft’s Component Object Model (COM) and its successor, the
distributed component object model (DCOM) are alternative to COR
BA. DCOM was bundled with Windows NT 4.0. DCOM is an Internet
and component strategy where ActiveX (formerly known as object
linking and embedding or OLE) plays the role of DCOM object.
DCOM is backed by web browser (Internet Explorer).
DISTRIBUTED DATABASES Many modern databases are distributed databases, which implies that portions of
the database reside on different nodes (computers) and disk drives in the network.
Usually, each portion of the database is managed by a server, a process responsible
for controlling access and retrieval of data from the database portion.
What is Client-server Computing Client-server computing is the logical extension of modular programming. The modular programming is hat separation of a large piece of software into its
constitute parts (“modules”) creates the possibility for easier development and
better maintainability.
Client-server computing extends this theory a step further by recognizing that all
those modules need not be executed within the same memory space or even on the
same machine. With this architecture, the calling module becomes the “client”
(that which requests a service) and the called module becomes the “server” (that
which provides the service)
Another important component of client-server computing is connectivity, which
allows applications to communicate transparently with other programs or
processes, regardless of their locations. The key element of connectivity is the
network operating system (NOS), also known as middleware . The NOS provides
services such as routing, distribution, messages, filing and printing, and network
management.
Client Process The client is a process (program) that sends a message to a server process
(program) requesting that the server perform a task (service).
Client programs usually manage the user interface portion of the application,
validate data entered by the user, dispatch requests to server programs, and
sometimes execute business logic.
The business layer contains all the objects that represent the business (real objects)
such as Order, Customer, Inventory. The client-based processes is the front-end of
the application, which the user sees and interacts with. The client process contains
solution-specific logic and provides the interface between the user and the rest of
the application system.
A key component of a client workstation is the graphical user interface (GUI),
which normally is a part of the operating system (i.e. the Windows manager). It is
responsible for detecting user actions, managing the Windows on the display, and
displaying the data in the Windows.
Server Process A server process (program)fulfills the client request by performing the task
requested. Server programs generally receive requests from client programs,
execute database retrieval and updates, manage data integrity, and dispatch
response to client requests. Sometimes, server programs execute common or
complex business logic. The server-based process “may” run on another machine
on the network. This server could be the host operating system or network file
server; the server then is provided both file system services and application
services. The server process acts as a software engine that manages shared
resources such as databases, printers, communication links or high-powered
processors. The server process performs the back-end task that are common to
similar applications.
More advanced forms of servers are database servers, transaction servers,
application servers, and more recently object servers. With database servers, clients
pass SQL requests as messages to the server and the results of the query are
returned over the network. Both the code that processes the SQL requests and the
data reside on the server,allowing it to use its own processing power to find the
requested data. This is in contrast to the file server, which requires passing all the
records back to the client and then letting the client find its own data.
With transaction servers, clients invoke remote procedures that reside on servers,
which also contain an SQL database engine. The server has procedural statements
to execute a group of SQL statements (transactions), which either all succeed or
fail as a unit.The server has procedural statements to execute a group of SQL
statements (transactions), which either all succeed or fail as a unit.
The application based on transaction servers, handled by on-line transaction
processing (OLTP), tend to be mission-critical applications that always require a 1-
3 seconds response time and tight control over the security and the integrity of the
database.
Interaction Between the client-server A typical client-server application consists of the following components: 1. User interface. This major component of the client-server application interacts
with users, screens, windows, windows management, keyboard and mouse
handling.
2. Business Processing. This part of the application uses the user interface data to
perform business tasks.
3. Database Processing. This part of the application code manipulates data within
the application. The data are managed by a database management system, object
oriented or not. Data manipulation is done using a data manipulation language,
such as SQL.
Distributed and Cooperative Processing Distributed Processing means distribution of applications and business logic
across multiple processing platforms. Distributed processing implies that
processing will occur on more than one processor in order for a transaction to
be completed. In other words, processing is distributed across two or more
machines, where each process performs part of an application in a sequence.
Example, in processing an order from a client, the client information may
process at one machine and the account information then may process on a
different machine.
Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction. Cooperative processing is related
to both distributed and client-server processing. Cooperative processing is a
form of distributed computing in which two or more distinct processes are
required to complete a single business transaction. Usually, these programs
interact and execute concurrently on different processors.
Cooperative processing also can be considered to be a style of distributed
processing, if communication between processors is performed through a message-
passing architecture.
Distributed Object Computing Distributed object Computing(DOC) promises the most flexible client-server
system, because it utilizes reusable software components that can roam anywhere
on networks, run on different platforms, communicate with legacy applications by
means of object wrappers.
Distributed objects are reusable software components that can be distributed and
accessed by users across the network. These objects can be assembled into
distributed applications. Distributed object computing introduces a higher level of
abstraction into the world of distributed applications. Applications no longer
consists of clients and servers but users, objects and methods. The user no longer
needs to know which server process performs a given function. All information
about the function is hidden inside the encapsulated object. A message requesting
an operation is sent to the object, and the appropriate method is invoked.
Distributed object computing resulted form the need to integrated mission-critical
applications and data residing on systems that are geographically remote,
sometimes from users and often from each other, and running on many different
hardware platforms. The business have had to integrate applications and data by
writing custom interfaces between systems, forcing develops to spend their time
building and maintaining an infrastructure rather than adding new business
functionality.
Object-relational systems
The object-oriented development creates a fundamental mismatch between the
programming model (objects) and the way in which existing data are stored
(relational tables).
To resolve the mismatch, a mapping tool between the application objects and the
relational data must be established. Creating an object model from an existing
relational database layout (schema) often is referred to as reverse engineering.
Conversely, creating a relational schema from an existing object model often is
referred to as forward engineering.
Tools that can be used to establish the object-relational mapping processes have
begun to emerge. The main process in relational and object integration is
defining the relationships between the table structures (represented as schemata)
in the relational database with classes (representing classes) in the object model.
Example Sun Java Blend allows the developer access to relational data as java
objects, thus avoiding the mismatch between the relational and object data
model.
Object- Relation Mapping
In a relational database, the schema is made up of tables, consisting of rows and
columns, where each column has a name and a simple data type. In an object
model, a table is a class, which has a set of attributes (properties or data
members). Object classes describe behavior with methods.
A tuple (row) of a table contains data for a single entity that correlates to an
object (instance of a class) in an object –oriented system. In addition, a stored
procedure in a relation database may correlate to a method in an object-oriented
architecture. A stored procedure is a module of precompiled SQL code
maintained within the database that executes on the server to enforce rules the
business has set about the data.
Therefore, the mapping essential to object and relational integration are between
a table and a class, between columns and attributes, between a row and an
object, and between a stored procedure and a method.
The relational data maps to and from application objects, it must have at least
the following mapping capabilities.
Table-class mapping
Table-multiple classes mapping
Table-inherited classes mapping
Tables- inherited classes mapping. The tool must describe both how the foreign key can be used to navigate among
classes and instances in the mapped object model and how referential integrity is
maintained. Referential integrity means making sure that a dependent table’s
foreign key contains a value that refers to an existing valid tuple in another
relation.
Table-Class Mapping Table-Class mapping is a simple one-to-one mapping of a table to a class and the
mapping of columns in a table to properties in a class. In this mapping, a single
table is mapped to a single class.
Table-multiple classes mapping In the table-multiple classes mapping, a single table maps to multiple noninheriting
classes. Two or more distinct, noninheriting classes have properties that are
mapped to columns in a single table. At run time, a mapped table row is accessed
as an instance of one of the classes, based on a column value in the table.
Table – Inherited Classes Mapping In table-inherited classes mapping, a single table maps to many classes that have a
common superclass. This mapping allows the user to specify the columns to be
shared among the related classes. The superclass may be either abstract or
instantiated. Tables – Inherited classes Mapping Another approach here is table-inherited classes mapping, which allows the
translation of is a relationships that exist among tables in the relational schema into
class inheritance relationships in the object model. In a relational database, an is-a
relationship often is modeled by a primary key that acts as a foreign key to another
table. In the object-model, is a is another term for an inheritance relationship.
OODBMS
• It is marriage of object oriented programming and database technology.
The defined operations apply universally and are not dependent on the
particular database application running at the moment.
• The data types can be extended to support complex data such as multimedia
by defining new object classes that have operations to support new kinds of
information.
• It should have object-oriented language properties and database
requirements.
Rules to make object-oriented system
• The system must support complex objects.
• Object identity must be supported
• Objects must be encapsulated
• System must support types or classes
• System must support inheritance
• System must avoid premature binding
• System must be computationally complete
• System must be extensible
• It must be persistent, able to remember an object state
• It must be able to manage large databases
• It must accept concurrent users
• Data query must be simple
• The system must support complex objects. System must provide simple
atomic types of objects (integers, characters, etc) from which complex
objects can be built by applying constructors to atomic objects.
• Object identity must be supported: A data object must have an identity and
existence independent of its values.
• Objects must be encapsulated: An object must encapsulate both a program
and its data.
• System must support types or classes: The system must support either the
type concept or class concept
• System must support inheritance: Classes and types can participate in a
class hierarchy. Inheritance factors out shared code and interfaces.
• System must avoid premature binding: This is also known as late binding or
dynamic binding. It shows that the same method name can be used in
different classes. The system must resolve conflicts in operation names at
run time.
• System must be computationally complete: Any computable function should
be expressible in DML of the system, allowing expression of any type of
operation.
• System must be extensible: The user of the system should be able to create
new types that have equal status to the system’s predefined types.
• It must be persistent, able to remember an object state: System must allow
the programmer to have data survive beyond the execution of the creating
process for it to be reused in another process.
• It must be able to manage large databases: System must manage access to
the secondary storage and provide performance features such as indexing,
clustering, buffering and query optimization.
• It must accept concurrent users: System must allow multiple concurrent
users and support notions of atomic, serializable transactions ,must be able
to recover from hardware and software failures
• Data query must be simple: System must provide some high-level
mechanism for ad-hoc browsing of the contents of the database.
Object oriented databases versus Traditional Databases
The responsibility of an OODBMS includes definition of the object
structures, object manipulation and recovery, which is the ability to maintain
data integrity regardless of system, network or media failure.
The OODBMs like DBMSs must allow for sharing; secure, concurrent
multiuser access; and efficient, reliable system performance.
The objects are an “active” component in an object-oriented database, in
contrast to conventional database systems, where records play a passive role.
Another feature of object-oriented database is inheritance. Relational
databases do not explicitly provide inheritance of attributes and methods.
The objects are an active component in an object-oriented database, in
contrast to conventional database systems, where records play a passive role.
The relational database systems do not explicitly provide inheritance of
attributes and methods while object-oriented databases represent
relationships explicitly (openly, clearly). (improvement in data access
performance )
Object oriented databases also differ from the traditional relational databases
in that they allow representation and storage of data in the form of objects.
(each object has its own identity or object-ID
Object Identity
Object oriented databases allow representation and storage of data in the form
of objects.
Each object has its own identity or object-ID (as opposed to the purely value-
oriented approach of traditional databases).
The object identity is independent of the state of the object.
Multidatabase Systems
• A different approach for integration object-oriented applications with
relational data environments is multidatabase systems or heterogeneous
database systems, which facilitate the integration of heterogeneous
databases and other information sources.
• Heterogeneous information systems facilitate the integration of
heterogeneous information sources, where they can be structured
(having regular schema), semi-structured and sometimes even
unstructured. Some heterogeneous information systems are constructed
on a global schema over several databases. So users can have the
benefits of a database with a schema to access data stored in different
databases and cross database functionality. Such heterogeneous
information systems are referred to as federated multidatabase systems.
• Federated multidatabase systems provide uniform access to data stored
in multiple databases that involve several different data models.
• A multidatabase system (MDBS) is a database system that resides
unobtrusively on top of, existing relational and object databases and file
systems (local database systems) and presents a single database illusion
to its users.
• The MDBS maintains a single global database schema and local
database systems maintain all user data.
• The schematic differences among local databases are handled by
neutralization (homogenization), the process of consolidating the local
schemata.
• The MDBS translates the global queries and updates for dispatch to the
appropriate local database system for actual processing, merges the
results from them and generates the final result for the user.
• MDBS coordinates the committing and aborting of global transactions
by the local database systems that processed them to maintain the
consistency of the data within the local databases.
• An MDBS controls multiple gateways (or drivers). It manages local
databases through gateways, one gateway for each local database.
• Open Data Base Connective (ODBC) is an application programming
interface that provides solutions to the multidatabase programming
problem. It provides a vendor-neutral mechanism for independently
accessing multiple database hosts.
• ODBC and other APIs provide standard database access through a
common client-side interface. It avoids the burden of learning multiple
database APIs. Here one can store data for various applications or data
from different sources in any database and transparently access or
combing the data on an as needed basis. Details of back-end data
structure are hidden from the user.
ODBC
• ODBC is similar to Windows print model, where the application
developer writes to a generic printer interface and a loadable driver
maps that logic to hardware-specific commands.
• This approach virtualizes the target printer or DBMS because the
person with the specialized knowledge to make the application logic
work with the printer or database is the driver developer and not the
application programmer.
• The application interacts with the ODBC driver manager, which sends
the application calls (such as SQL statements) to the database.
• The driver manager loads and unloads drivers, perform status checks
and manages multiple connections between applications and data
sources.
Designing Access Layer Classes
• The main idea behind creating an access layer is to create a set of classes
that know how to communicate with the place(s) where the data
actually reside. Regardless of where the data reside, whether it be a file,
relational database, mainframe, Internet, DCOM or via ORB, the access
classes must be able to translate any data-related requests from the
business layer into the appropriate protocol for data access.
• These classes also must be able to translate the data retrieved back into
the appropriate business objects.
• The access layer’s main responsibility is to provide a link between
business or view objects and data storage.
• Three-layer architecture is similar to 3-tier architecture. The view layer
corresponds to the client tier, the business layer to the application
server tier and the access layer performs two major tasks:
Access Layer tasks
• Translate the request: The access layer must be able to translate any
data related requests from the business layer into the appropriate
protocol for data access.
• Translate the results: The access layer also must be able to translate the
data retrieved back into the appropriate business objects and pass those
objects back into the business layer.
Advantage of this approach
• Here design is tied to any base engine or distributed object technology
such as CORBA or DCOM. Here we can switch easily from one
database to another with no major changes to the user interface or
business layer objects. All we need to change are the access classes’
methods.
• The access layer design process consists of the following activities:
• If a class interacts with nonhuman actor such as another system,
database or the web , then the class automatically should become an
access class.
Design the access layer (approach-1)
(1) For every business class identified ,mirror the business class package.: For
every business class identified and created, create one access class in the
access layer package.
Eg , if there are 3 business classes (class1, class2 and class3), create 3
access layer classes (class1DB, class2DB and class3DB)
(2) Identify access layer class relationships (or) define the relationships.
Simplify classes and their relationships – main goal is to eliminate redundant
classes and structures
– Redundant classes: Do not keep 2 classes that perform
similar translate request and translate results
activities. Select one and eliminate the other.
– Method classes: Revisit the classes that consist of only
one or two methods to see if they can be eliminated or
combined with existing classes.
• Iterate and refine again.
(3)Simplify classes and their relationships – main goal is to eliminate
redundant classes and structures.Inmost cases , combine simple access
class and simplify the super and subclass structures
– Redundant classes: Do not keep 2 classes that perform
similar translate request and translate results
activities. Select one and eliminate the other.
– Method classes: Revisit the classes that consist of only
one or two methods to see if they can be eliminated or
combined with existing classes.
(4) Iterate and refine again.
In this process, the access layer classes are assumed to store not only the
attributes but also the methods.This can be done by utilizing an OODBMS
OR Relational data base
Design the access layer process (approach-2)
• Let methods to be stored in a program (eg: a compiled c++ program
stored on a file) and store not only the persistent attributes
• (1) For every business class identified determine if class has persistent
data.An attribute can be either transient or persistent (non transient )
(2) For every business class identified ,mirror the business class package.: For
every business class identified and created, create one access class in the
access layer package.
Eg , if there are 3 business classes (class1, class2 and class3), create 3
access layer classes (class1DB, class2DB and class3DB)
(3) Identify access layer class relationships (or) define the relationships.
(4)Simplify classes and their relationships – main goal is to eliminate
redundant classes and structures.Inmost cases , combine simple access class
and simplify the super and subclass structures
– Redundant classes: Do not keep 2 classes that perform
similar translate request and translate results
activities. Select one and eliminate the other.
– Method classes: Revisit the classes that consist of only
one or two methods to see if they can be eliminated or
combined with existing classes.
(5) Iterate and refine again.
APPROACH(1)
SUMMARY
A package groups and manages the modeling elements, such as classes,
their associations, and their structures. Packages themselves may be nested within
other packages. A package may contain both other packages and ordinary model
elements. The entire system description can be thought of as a single high-level
sub-system package with everything else init. All kinds of UML model elements
and diagrams can be organized into packages. Persistence refers to the ability of
some objects to outlive the programs that created them. The persistent data are
those data that exist beyond the lifetime of the creating process. Some categories of
persistent data are:
◊ Data that exist between the executions of a program.
◊ Data that exist between the versions of a program.
◊ Data that outlive a program.
Essential elements in providing a persistent store are:
◊ Identification of persistent objects or reachability
◊ Properties of objects and their interconnections.
◊ Scale of the object store.
◊ Stability.
Schema or meta-data contains a complete definition of the data formats,
such as the data structures, types and constraints. The meta-data are usually
encapsulated in the application programs themselves. In DBMS, the format of the
meta-data is independent of any particular application data structure; therefore it
will provide a generic storage management mechanism. A concurrency control
policy dictates what happens when conflicts arise between transactions that attempt
access to the same object and how these conflicts are to be resolved. There are two
policies,
◊ Conservative or pessimistic policy
Allows a user to lock all objects or records when they are accessed
and to release the locks only after a transaction commits.
◊ Optimistic policy
Two conflicting transactions are compared in their entirety and
then their serial ordering is determined.
A database model is a collection of logical constructs used to represent the
data structure and data relationships within the database. The different database
models are,
Hierarchical model
Network model
Relational model
KEY TERMS
Data definition language(DDL)
Data base management system (DBMS)
ODBC
Multi database system (MDBS)
Homogenization
Common object request broker architecture (CORBA)
Distributed object computing (DOC)
Cooperative processing
KEY TERM QUIZ
1. Open database connectivity (ODBC) is an application programming
interface that provides solutions to the multidatabase programming problem.
2. A multi database system (MDBS) is database systems that resides
unobtrusively on top of existing relational and object databases, and file
systems and presents a single database illusion to its users.
3. Neutralization also called homogenization is the process of consolidating
the local schemata.
4. Common object request broker architecture (CORBA) is a standard
proposed as a means to integrate distributed heterogeneous business
components that can roam anywhere on networks, run on different
platforms, communicate with legacy applications by means of object
wrappers, and manage themselves and the resources thy control.
(a) Common object request broker architecture (b) Distributed object
computing (DOC) (c) homogenization
6. Cooperative processing is computing that requires two or more distinct
processors to complete a single transaction.
a. Cooperative processing (b) Data definition language
7. Data definition language (DDL) is the language used to describe the
structure of and relationships between objects stored in a database.
a. Cooperative processing (b) Data definition language
8. DBMS is a set of programs that enables the creation and maintenance of a
collection of related data
(a) Cooperative processing (b) Data definition language (c) DBMS
REVIEW QUESTIONS
1. Differentiate between transient data and persistent data? (Pg 238)
2. What is a DBMS? (Pg 239)
3. What is a relational database? Explain tuple, primary key and foreign key
(Pg 241)
4. What is a database schema? Differentiate between schema and meta-data
(Pg 242)
5. What is a DDL? (Pg 242)
6. What is a distributed database? (Pg 245)
7. What is concurrency control? (Pg 244)
8. Define shareability (Pg 243)
9. What is a transaction? (Pg 244)
10. What is concurrency policy? (Pg 244)
11. What is a query? (Pg 242)
12. Define client-server computing (Pg 245)
13. Name the different types of servers. Briefly describe each (Pg 246)
14. Why is DOC so important in the computing world? (Pg 250)
15. Describe CORBA, ORB and DCOM (Pg 251, 252)
16. What is an OODBMS? Differentiate between an OODBMS and object-
oriented programming (Pg 252, 254)
17. Differentiate between forward and reverse engineering (Pg 255)
18. Describe a federated multidatabase system (Pg 261)
19. Describe the process of creating the access layer classes (Pg 264)
20. Define object store and persistence (Pg 238)
References :
Object Oriented Analysis and Design using UML, by Rational
Software Corporation (2002)
Bahrami, A.(1999). Object Oriented Systems Development,
using the unified modeling language, McGraw-Hill
UNIT-V
SOFTWARE QUALITY AND USABILITY
CHAPTER 12
VIEW LAYER: Designing Interface Objects
OBJECTIVES :
At the end of this chapter, students should be able to
Identifying View (or User interface ) classes
Designing Interface objects
Prototyping the interface objects
INTRODUCTION
o Main goal of a user interface (UI) is to display & obtain needed
information in an accessible, efficient manner.
o A well-designed UI has visual appeal that motivates users to use yr
application.
o A graphical user interface (GUI) uses icons to represent objects, a
pointing device to select operations, and graphic imagery to
represent relationships
Designing View Layer Classes
View layer objects or interface objects the only exposed objects of
an application with which users can interact
They are objects that represent the set of operations in the business
that users must perform to complete their tasks
View layer objects responsible for 2 major aspects of the application :
1. Input responding to user interaction. The UI must be
designed to translate an action by the user
2. Output displaying or printing business objects. This layer
must paint the best picture possible of the business objects for
the user
The process of designing view layer :
Macro-Level Proces : Identifying View Classes
The view layer macro process consists of 2 steps :
1. The macro level UI design process – identifying
view layer objects ( identify classes that interact
with human actors by analyzing the use-cases,
sequence/collaboration diagram )
2. 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 usability and user satisfaction
4. Refining and iterating the design
1. for every class identified, determine if the class interacts with
a human actor. If so, perform the following ; otherwise, move
to the next class
1.1 identify the view(interface) objects for the class.
Zoom in on the view objects by utilizing
sequence/collaboration diagrams to identify the interface
objects, their responsibilities, and the requirements for
this class
1.2 define the relationships among the view (interface)
objects.
2. Iterate and refine
Designing View Layer Classes
Three Layer architecture used for software development, namely Access
layer, view layer and user-interface / business layer.
The separation of the view layer from the business and access layers is that,
when you design of UI objects, you have to think more explicitly about
distinctions between objects that are useful to users.
View layer classes or interface objects are objects that represent the set of
operations in the business that users must perform to complete their tasks, ideally
in a way they find natural, easy to remember, and useful.
Any objects that have direct contact with the outside world are visible in
interface objects.
The view layer objects are responsible for two major aspects of applications:
1. Input-responding to user interaction: The user interface must be designed
to translate an action by the user, such as clicking on a button or selecting
from a menu, into an appropriate response.
2. Output-displaying or printing business objects. This layer must paint the
best picture possible of the business objects for the user. In one interface,
this may mean entry fields and list boxes to display an order and its items. In
another, it may be a graph of the total price of a customer‟s orders.
The view layder classes is divided into four activities: 1. The macro level UI design process – identifying view layer objects. The
main objective of the macro process is to identify classes that interact with
human actors by analyzing the use cases developed in the analysis phase.
The each use case involves actors and the task they want the system to
do. These use cases should capture a complete, unambiguous, and consistent
picture of the interface requirements of the system.
In this phase, it is also need to address the issue of how the interface
must be implemented.
Sequence or collaboration diagrams can help by allowing us to zoom
in on the actor-system interaction and extrapolate interface classes that
interact with human actors; thus assisting us in identifying and gathering the
requirements for the view layer objects and designing them.
2 Micro level VI design activities:
2.1Designing the view layer objects by applying design axioms and
corollaries.
In designing view layer objects, decide how to use and extend the
components to support application-specific functions and provide the most
usable interface.
2.2 Prototyping the view layer interface. After defining a design model,
prepare a prototype of some of the basic aspects of the design. Prototyping
is particularly useful early in the design process.
3. Testing usability and user satisfaction. "We must test the application to
make sure it meets the audience requirements. To ensure user satisfaction,
measure user satisfaction and its usability along the way as the UI design
takes form. Usability experts agree that usability evaluation should be part of
the development process rather than a post-mortem or forensic activity.
4. Refining and iterating the design
Macro-level process: identifying view classes by analyzing use cases The interface object handles all communication with the actor but processes
no business rules or object storage activities. The interface object will operate as a
buffer between the user and the rest of the business objects.
For example, computing employee overtime is an example of a business
object service. However, the data entry for the employee overtime is an interface
object.
The interface object has a coordinating responsibility in the process, at least
responsibility for those tasks that come into direct contact with the use.
The view layer macro process consists of two steps:
1. For every class identified, determine if the class interacts with a human
actor.
1.1 identify the view (interface) objects for the class
1.2 Define the relationships among the view (interface) objects.
2. Iterate and refine
The advantage of utilizing use cases in identifying and designing view layer
objects is that the focus centers on the user, and including users as part of the
planning and design is the best way to ensure accommodating them.
Once the interface objects have been identified, we must identify the basic
components or objects used in the user tasks and the behavior and the
characteristics that differentiate each kind of object, including the relationships of
interface objects to each other and to the user.
The interface object handles all communication with the user but does not
process any business rules; that will do by the business objects.
Effective interface design is more than just following a set of rules. It also
involves early planning of the interface and continued work through the software
development process. The process of designing the user interface involves
clarifying the specific needs of the application, identifying the use cases and
interface object and then devising a design that best meets users' needs.
Micro-Level Process The design of the view layer objects must be user driven or user centered. A user-centered interface replicates the user‟s view of doing thins by
providing the outcomes users expect for any action.
The following is the process of designing view (interface) objects: 1. For every interface object identified in the macro UI design process, apply
micro-level UI design rules and corollaries to develop the UI.
2. Iterate and refine.
View objects
Business objects
Access objects
Relationship among view objects, business objects, access objects
UI design Rule 1. Making the interface simple
(Application of Corollary 2) The user interface should be so simple that users are unaware of the tools and
mechanism that make the application work. As applications become more
complicated, user must have an even simpler interface, so they can learn new
applications more easily. This rule is an application of Corollary 2 (Single purpose) in UI deign. It means that each UI class must have a single, clearly defined purpose. Similarly,
when you document, you should be able easily to describe the purpose of the UI
class with a few sentences.
UI Design Rule 2. Making the Interface Transparent and Natural
(Application of Corollary 4) The user interface should be so intuitive and natural that users can anticipate
what to do next by applying their previous knowledge of doing tasks without a
Micro level design process
Apply micro level UI design rules and GUI
guidelines to each interface object identified
to develop the UI
Done
Next interface objects refine and iterate
computer. An application, therefore, should reflect a real-world model of the user‟s
goals and the tasks necessary to reach those goals.
The second UI rule is an application of Corollary 4 (Strong Mapping) in UI
design. Here, this corollary implies that there should be strong mapping between
the user‟s view of doing things and UI classes.
A metaphor, or analogy, relates two otherwise unrelated things by using one
to denote the other, such as question Mark (?) to label a help button.
This principle also applies to UI design. Using metapors is a way to develop
the user‟s conceptual model of an application. Familiar metaphors can assist the
users to transfer their previous knowledge from their work environment to the
application interface and create a strong mapping between the user‟s view and the
UI objects.
Of ten an application design is based on a single metaphor. For example,
billing, insurance, inventory and banking applications can represent forms that are
visually equivalent to the paper forms users are familiar to seeing.
A goal of user interface design is to make the user interaction with the
computer as simple and natural as possible.
UI design Rule 3. Allowing Users to be in Control of the software
(Application of Corollary 1)
The users always should feel in control of the software, rather than felling
controlled by the software.
The second implication is that users, because of their widely varying skills
and preferences, must be able to customize aspects of the interface. The software
should reflect user settings for different system properties such as color, fonts or
other options.
The final implication is that the software should be as interactive and
responsive as possible. Avoid modes whenever possible.
A mode is a state that limits the user to specific interactions. There are
situations in which modes are useful; for example, selecting a file name before
opening it. The main idea here is to avoid creating a single UI class for several
business objects, since it makes the UI less flexible and forces the user to perform
tasks in a massive way. Some of the ways to put users in control are:
Make the interface forgiving Make the interface visual
Provide immediate feedback
Avoid modes Make the interface consistent.
Make the Interface Forgiving:
The user‟s actions should be easily reversed. They should be able to back up
or undo previous actions. An effective interface allows for interactive discovery.
Actions that are destructive and may cause the unexpected loss of data should
require a confirmation or better should be reversible or recoverable.
Even within the best designed interface, users can make mistakes. These
mistakes can be both physical (accidentally pointing to the wrong command or
data) and mental (making a wrong decision about which command or data to
select).
An effective design avoids situations that are likely to result in errors.
Users feel more comfortable with a system when their mistakes do not cause
serious or irreversible results.
Make the interface Visual. Deign the interface so users can see, rather than recall,
how to proceed.
Provide Immediate Feedback. Users should never press a key or select an action
without receiving immediate visual or audible feedback or both. For example, the color, emphasis, and selection indicators show users they can
select that choice. Avoid Modes. Modes force users to focus on the way an application works,
instead of on the task they want to complete. Modes, therefore, interfere with
user‟s ability to use their conceptual model of how the application should work. It
is not always possible to design a modeless application. The method for ending the mode should be easy to learn and remember. There are some of the modes that can be used in the user interface: Modal dialog: Sometimes an application needs information to continue, such as
the name of a file into which users want to save something. When an error occurs,
users may be required to perform an action before they continue their task. Spring-loaded modes: Users are in a spring-loaded mode when they continually
must take some action to remain in that mode; for example, dragging the mouse
with a mouse button pressed to highlighted a portion of text. In this case, the visual
cue for the mode is the highlighting. For example Cut and paste text Tool-driven modes: If you are in a drawing application, you may be able to choose
a tool, such as a pencil or a paintbrush for drawing. After you select the tool, the
mouse pointer shape changes to match the selected tool. Make the Interface Consistent Consistency is one way to develop and reinforce
the user‟s conceptual model of applications and give the user the feeling that he or
she is in control, since the user can predict the behavior of the system. User
interface should be consistent throughout the applications. The purpose of a View Layer Interface Each window should serve a clear, specific purpose. Windows commonly used
for:
Forms and data entry windows
It provide access to data that user can retrieve, display and change in
application.
Application windows (main windows)
It is container of application object or icons. It contains an entire
application with which users can interact.
Guidelines for Designing Forms and Data Entry Windows What kind of information will users work with and why? For example, a user
might want to change inventory information, enter orders, or maintain prices for
stock items. Do users need access to all the information in a table or just some information? –
use a query that selects the rows and columns users want. In what order do users want rows to appear? For example, users might want to
change inventory information stored alphabetically, chronologically or by
inventory number. Typical data entry tasks include the following:
Navigating rows in a table, such as moving forward and backward and moving
first and last record Adding and deleting rows
Changing data in rows
Saving and abandoning changes. Guidelines for Designing Dialog boxes and Error Messages
A dialog box provides an dialog between the user and the application.
Because dialog boxes generally appear after a particular menu item or a command
button.
If the dialog box is for an error message, use the following guidelines: Your error message should be positive. For example instead of displaying “you
have typed an illegal data format” display the message “Enter date format
mm/dd/yy”.
The error message should be constructive. For example, avoid messages
such as “You should know better! Use the OK button”; instead display “Press the
Undo button and try again”.
Guidelines for Designing Application Windows
A typical application window consists of a frame (or border) that defines its
extent and a title bar that identifies what is being viewed in the window. If the
viewable content of the window exceeds the current size of the window, scroll bars
are used. The windows also can include other components like menu bars, toolbars
and status bars. An application window usually contains common drop-down
menus. The File menu: It provides an interface for the primary operations that apply a file
such as open, Save, Save As… and Print. The Edit Menu : Include general purpose editing commands on the Edit menu.
These commands include the Cut, Copy and Paste commands and also includes
Undo, Find, Delete command.
The View Menu and other command Menus: Commands on the View menu should
change the user‟s view of data in the Window. For example Zoom or Outline,
Show Ruler. The Window Menu: use the window menu in multiple document, interface style
applications for managing the windows within the main workspace. The Help menu: It contains commands that provide access to Help information.
Such as Help Topic command – Contents, Index and Find Topic. Toolbars and Status Bars : It is special interface constructs for managing sets of
controls. A toolbar is a panel that contains a set of controls. A status bar is a special area within a window, typically at the bottom, that displays
information such as current state such as keyboard state. Guidelines for Using colors
For all objects on a window, use colors to add visual appeal to the form. Text
must be readable at all times: black is the standard color. Associate meanings to the
colors of your interface. For example, use blue for all the uneditable fields, green
to indicate fields that will update dynamically, and red to indicate error conditions.
Ensure color consistency from screen to screen and make sure the users know what
these various colors indicate.
Use identical or similar colors to indicate related information. For example,
savings account fields might appear in one color.
• For an object background, use a contrasting but complementary color. Make
sure that the background color contrasts with the date color so that the user
can easily read data in the field.
• Use bright colors to call attention to certain elements on the screen.
• Use colors consistently within each window and among all windows in the
application. For example, the colors for push buttons should be the same
throughout.
• Don‟t use too many colors, it will be visually distract the application and
make less interesting
• Allow the user to modify the color configuration of the application.
Guidelines for Using Fonts
Most commercial applications use 12-point System font for menus and 10-point
System font in dialog boxes. The most preferable font is Times New Roman.
• Use commonly installed fonts, not specialized fonts that users might not
have on their machines.
• Use Bold for control labels, so they will remain legible when the object is
dimmed.
• Use fonts consistently within each from and among all forms in the
application
• Using too many font styles, sizes and colors can be visually distracting and
should be avoided.
• To emphasize text, increase its font size relative to other words on the form
or use a contrasting color.
EXAMPLE : CASE STUDY DESIGNING USER INTERFACE FOR THE
VIANET BANK ATM
VIEW LAYER MACRO PROCESS
Determine if the class interacts with a human actor
ATMMachine
Identify the interface objects for the class(go thru the
sequence/collaboration diagram). Review the use cases that interact
directly with actors :
Bank transaction, Checking transaction history, Deposit checking,
validating a PIN code), DepositCheckingUI, DepositSavingsUI,
WithdrawCheckingUI, WithdrawSavingsUI
AccountTransactionUI
AccountTransactionUI
Account
Relation between the view class
AccountTransactionUI
and its associated
business class (account)
VIEW LAYER MICRO PROCESS
Based on the outcome of macro process :
BankClientAccessUI
MainUI
AccountTransactionUI
CheckingAccountUI
SavingsAccountUI
Apply micro-level UI design rules and collaries to develop UI
The AccountTransactionUI
Iterate and refine
KEY TERMS
UI (USER INTERFACE)
Graphical user interface (GUI)
KEY TERM QUIZ
1. User interface (UI) is to display & obtain needed information in an
accessible, efficient manner.
2. A graphical user interface (GUI) uses icons to represent objects, a pointing
device to select operations, and graphic imagery to represent relationships
MULTIPLE CHOICE
1. User interface (UI) is to display & obtain needed information in an
accessible, efficient manner.
(a) User interface (UI) (b) graphical user interface (GUI)
2. A graphical user interface (GUI) uses icons to represent objects, a pointing
device to select operations, and graphic imagery to represent relationships
(a) User interface (UI) (b) graphical user interface (GUI)
REVIEW QUESTIONS:
1. Why is User interface one of the most important components of any
software? (Pg 281)
2. Compare GUI with OOUI (Pg 281-283)
3. Why is OOUI easier to use? (Pg 282)
4. How can use cases help us design the view layer objects? (Pg 284)
5. Describe the macro and micro processes of view layer design
(Pg 285;287)
6. How can metaphors be used in the design of a user interface?
(Pg 290)
7. Describe the UI design rules (Pg 288;290;292)
CHAPTER-13
SOFTWARE QUALITY ASSURANCE
INTRODUCTION
Debugging is the process of finding out where something went wrong in the
application, what we develop and correcting the code to eliminate the errors or
bugs that cause unexpected results.
Error-based testing: This technique search a given class‟s method for
particular clues of interests, then describe how these clues should be tested.
Scenario-based testing/usage-based testing: It concentrates on what the
user does, not what the product does. This means capturing use cases and the tasks
users perform, then performing them and their variants as tests. They often are
more complex and realistic than error-based tests.
Scenario-based tests tend to exercise multiple subsystems in a single test,
because that is what users do.
Introduction Testing is very important for developing and delivering robust system. It is also
important to examine collective behaviors to ensure maximum operational
reliability. Verify each component will behave correctly.
Debugging is the process of finding out where something went wrong and
correcting the code to eliminate the errors.
Kind of Errors Language Error / Syntax error: Due to incorrectly constructed code, such as
incorrectly typed keyword or some necessary punctuation omitted.
Run-time errors occur and are detected as the program is running, when a
statement attempts an operation that is impossible to carry out. Ex: nonexistent
object, a file.
Logic errors occur when code might be syntactically valid and run without
performing any invalid operations and yet produce incorrect results. Logic errors
also can produce run-time errors.
Quality Assurance Testing The elimination of the syntactical bug is the process of debugging, whereas the
detection and elimination of the logical bug is the process of testing.
Testing vs. Quality Assurance
• Quality Assurance
– Responsible for test plans and system testing
– Monitor testing during development
– Keep statistics
• Testing is a necessary but insufficient part of a QA process
• QA addresses activities designed to
– prevent defects
– remove defects
• Testing helps in identifying problems and failures
• Testing helps QA by identifying them early.
Quality assurance testing can be divided into two major categories: error-based
testing and scenario-based testing
Error Based Testing These techniques search a given class‟s method for particular clues of interests,
then describe how these clues should be tested
Ex: Payroll computation method of an Employee class:
anEmployee.computePayroll(hours). To test this method try different values for
hours (say, 40,0,100 and -10) and also test the boundary conditions.
Scenario based Testing Scenario-based testing, also called usage-based testing., concentrates on what the
user does, not what the product does. This means capturing use cases and the tasks
users perform, then performing them and their variants as tests. These scenarios
also can identify interaction bugs. Disadvantages : The tests will not find everything but they will cover at least the
higher visibility system interaction bugs. Adv: This testing identifies the following:
An incorrect specification, the product doesn‟t do what the customer wants.
Interactions among subsystems, these are bugs where some action over there
sets up some state that crashes this subsystem over here.
TESTING STRATEGIES The extent of testing a system is controlled by many factors, such as the risks
involved, limitations on resources and deadlines. There are many testing strategies
such as block box testing, white box testing, top down testing and bottom up
testing. Black Box testing In black box, the test item is treated as “black”, since its logic is unknown; all that
is known is what goes in and what comes out or the input and output. In black box
testing, you try various inputs and examine the resulting output; you can learn what
the box does but nothing about how this conversion is implemented. White Box testing The main use of the white box is in error-based testing, assumes that the specific
logic is important and must be tested to guarantee the system‟s proper functioning.
It is also called path testing, makes certain that each path in a object‟s method is
executed at least once during testing. Two types of path testing are
Statement testing coverage is to test every statement in the object‟s method by
executing it at least once. It is unfeasible to test a program on every single
input, so you never can be sure that a program will not fail on some input.
Branch testing coverage is to perform enough tests to ensure that every branch
alternative has been executed at least once under some test.
Top-Down testing
Top-Down testing assumes that the object interaction and systems messes of the
application need more testing than an individual object‟s methods.
Top-down testing should find critical design errors early in the testing process
and significantly improve the quality of the delivered software because of the
iterative nature of the test.
A top-down strategy supports testing the user interface and event-driven
systems
This serves two purposes, First, top-down approach can test the navigation
through screens and verify that it matches the requirements.
Second, users can see, at an early stage, how the final application will look and
feel. This approach also is useful for scenario-based testing.
Top-down testing is useful to test subsystem and system integration. Bottom-Up testing
Bottom-up testing starts with the details of the system and proceeds to higher
levels by a progressive aggregation of details until they collectively fit the
requirements for the system.
This approach is more appropriate for testing the individual objects in a system.
This strategy makes sense because you are checking the behavior of a piece of
code before it is used by another.
Bottom-up testing leads to integration testing, which leads to systems testing.
Impact of Inheritance in Testing 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. If the base::inherited has been changed, the derived::inherited() may not have to be
completely tested.
Where it does depend on the base methods: otherwise it must be tested again.
Reusability of Tests If base ::redefined() and two different methods with different protocols and
implementations, each needs a different set of test requirements derived from the
use cases, analysis, design or implementation.
You need to write new tests only for those derived::redefined requirements not
satisfied by the base::redefined tests.
The models developed for analysis and design should be used for testing as well. For example, the class diagram describes relationships between objects; that is an
object of one class may user or contain an object of another class, which is useful
information for testing.
Furthermore, the use-case diagram and the highest level class diagrams can benefit
the scenario-based testing.
Since a class diagram shows the inheritance structure, which is important
information for error-based testing.
TEST PLAN A test plan is developed to detect and identify potential problems before delivering
the software to its users.
A test plan offers a road map for testing activities, whether usability, user
satisfaction, or quality assurance tests. It should state the test objectives and how to
meet them.
1. Objectives of the test: create the objectives and describe how to achieve
them and if the objective is usability of the system.
2. Development of a test case: develop test data, both input and excepted
output, based on the domain of the data and the excepted behaviors that must
be tested
3. Test analysis involves the examination of the test output and the
documentation of
the test results. If bugs are detected, then this is reported and the activity
centers on debugging. After debugging, steps 1 through 3 must be repeated
until no bugs can be detected. All passed tests should be repeated with the revised program, called regression
testing, which can discover errors introduced during the debugging process. When
sufficient
testing is believed to have been conducted, this fact should be reported, and testing
for this specific product is complete. Most software companies also use beta testing, a popular in expensive, and
effective way to test software on a select group of the actual users of the system. This is in contrast to alpha testing, where testing is done by inhouse testers, such as
programmers, software engineers, and internal users.
Guidelines for Developing Test plans Thomas developed the guidelines for writing test plans:
• specify the format of your test plan
• try to include as much as detail as possible about the tests.
• The test plan should contain a schedule and a list of required
resources.
• Identify what types of testing are necessary such as black box testing,
white box testing
The level of test plan required
CONTINUOUS TESTING A common practice among developers is to turn over applications to a quality
assurance (QA) group for testing only after development is completed. Testing the
whole system and detecting bugs is more difficult than testing smaller pieces of the
application as it is being developed. Testing must take place on a continuous basis,
and this refining cycle must continue throughout the development process until
satisfied with the results.
During this iterative process, prototypes will be transformed incrementally
into the actual application. The use cases and usage scenarios can become test
scenarios and therefore will drive the test plans.
SUMMARY
Debugging is the process of finding out where something went wrong in the
application, what we develop and correcting the code to eliminate the errors or
bugs that cause unexpected results. Error-based testing: This technique search a
given class‟s method for particular clues of interests, then describe how these clues
should be tested. Scenario-based testing/usage-based testing: It concentrates on
what the user does, not what the product does. This means capturing use cases and
the tasks users perform, then performing them and their variants as tests. They
often are more complex and realistic than error-based tests. Scenario-based tests
tend to exercise multiple subsystems in a single test, because that is what users do.
Testing becomes successful when the steps below are followed;
◊ Understand and communicate the business case for improved testing.
◊ Develop an internal infrastructure to support continuous testing.
◊ Look for leaders who will commit to and own the process.
◊ Measure and document your findings in a defect recording system.
◊ Publicize improvements as they are made and let people know what
they are doing better.
KEY TERMS
Black box testing
White- Box testing
Top- down Testing
Statement testing coverage
Branch testing coverage
White box testing
Path testing
Bottom - up Testing
KEY TERM QUIZ
1. In a Black box testing, the test item is treated as “black,” since its logic is
unknown; all that is known is what goes in and what comes out or input and
output. It may be used for Scenario- based testing.
2. White- Box testing assumes that the specific logic is important and must be
tested to guarantee the system‟s proper functioning. It is used mainly in the
error based testing.
3. Top- down Testing assumes that the main logic or object interactions and
systems messages of the application need more testing than an individual
object‟s methods or supporting logic. It can detect the serious design flaws
early in the implementation.
4. The main idea of statement testing coverage is to test every statement in
the object„s method by executing it at least once.
5. The main idea behind branch testing coverage is to perform enough tests to
ensure that every branch alternative has been executed at least once under
some test.
6. Path testing is one form of white box testing.
7. Two types of Path testing are Statement testing coverage and Branch testing
coverage
8. Bottom - up Testing starts with the details of the system and proceeds to
higher levels by a progressive aggregation of details until they collectively
fit the requirements for the system.
MULTIPLE CHOICE
1. In a Black box testing, the test item is treated as “black,” since its logic is
unknown; all that is known is what goes in and what comes out or input and
output. It may be used for Scenario- based testing.