Object Oriented Analysis & Design-SAE6C

Two Mark – UNIT I to UNIT V

1. Why an object orientation?

i. Higher level of abstraction
ii. Seamless transition among different phases of software
development
iii. Encouragement of good programming techniques
iv. Promotion of reusability
2. Define: class and object
a. Class- collection of an object, a class is a specification of structure,
behavior, and inheritance for objects.
b. Object-instance of an class, example saab automobile. The saab can be
represented in a computer program as an object.
3. Define: Inheritance
i. Derived class existing from a base class.
ii. Baseclass also called as parent, super classes
iii. Derived class also called as child, sub classes
4. Multiple inheritance:
a. More than one base class and one derived class is called as multiple
inheritance.
5. Polymorphism:
a. It takes more than one form. Poly means many , morphism means form.
6. Association
a. It represents the relationships between objects and classes
7. Aggregation:
a. Each object has an identity; one object can refer to other objects. This is
known as aggregation.
8. Object references:
a. It directly denote the object to which they reference.
9. Difference between static and dynamic binding.
a. Static binding- making this determination earlier, at compile time is
called static binding
b. Dynamic binding – the process of determining at run time which
functions to invoke is termed dynamic binding.
10.Define Object Persistence.
a. A file or database can provide support for object having a longer lifeline-
longer than the duration of the process for which they were created.
b. From language perspective, this characteristic is called object persistence.
11.Meta-data
a. Data about data is called meta-data.
12.RAD
a. Rapid Application Development is a set of tools and techniques that can
be used to build an application faster than typically possible traditional
methods.
13.Define: Pattern
a. A pattern is an instructive information that captures the essential structure
an insight of a successful family proven solutions to a recurring problem
that arises within a certain context an system of forces.
14.Define: Framework
a. A framework is a set of cooperating classes that make up a reusable
design for a specific class of software.
15.Difference between static model and dynamic model.
a. Static model – it can be viewed as a snapshot of a system’s parameters at
rest or at specific point in time.
b. Dynamic model – a dynamic model, in contrast to a static model, can be
viewed as a collection of procedures that taken together reflect the
behavior of a system over time
16.Qualifier :
a. A qualifier is an association attribute. Example, a person object may be
associated to a bank objects. An attribute of this association in the
account#. The account# is the qualifier of this association.
17.Multiplicity:
a. Multiplicity specifies the range of allowable associated classes.
18.Generalization
a. It is the relationship between a more general class and more specific
class.
19.Define: lifeline
a. It represents the object’s existence during the interaction. Vertical line is
called object’s lifeline.
20.What are the steps involved in CRC process?

CRC Process Consist of following three steps

 Identify classes’ responsibilities
 Assign responsibilities
 Identify Collaborators
21.Naming classes
1. The class name should be singular
2. Use simple names
3. Use readable names
4. The name of the class should reflect its intrinsic nature.
22.Ternary association:
a. Ternary or n-ary association is an association among more than two
classes
23.Persistence:
a. It refers to the ability of some objects to outlive the programs that created
them.
24.Effective documentation :( how to develop effective documentation?)
1. Common cover
2. 80-20 rule
3. Familiar vocabulary
4. Make the documents as soon as possible
5. Organize the document
25.Define: Coupling.

Coupling measures of the strength of association established by a

connection from one object or software component to another. Coupling is a
binary relationship. A is coupled with B.
26.Types of coupling
1. content coupling
2. common coupling
3. control coupling
4. stamp coupling
5. data coupling
27.Define :cohesion
Coupling deals with interaction between objects or software components.
We also need to consider interactions within a single object or software
component, called cohesion.
28.Define: Design Pattern
Design pattern are devices that 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.
29.Define : OCL
a. OCL- Object Constraint Language
i. It is a specification language that uses simple logic for specifying
the properties of a system.
30.Attributes types
a. Single value attribute
b. Multi-value attributes
c. Reference to another object
31.UML attribute Representation
a. Visibility name : type –expression =initial value
i. Visibility name:
ii. + Public( accessibility to all classes)
iii. #protected( accessibility to subclasses operations)
iv. –private(accessibility only operations on class)
32.UML Operation Representation
a. Visibility name(parameter list): return type expression
i. Visibility name:
ii. + Public( accessibility to all classes)
iii. #protected( accessibility to subclasses operations)
iv. –private(accessibility only operations on class)
33.Referential integrity
It means making sure that dependent table’s foreign key contains a value
that refers to an existing valid tuple in another relation.
34.Define: User centered interface
a. A user –centered interface replicates the user’s view of doing things by
providing the outcomes users expect for any action.
 35.Define: KISS
a. Keep It Simple and Straightforward,
b. An expert in user interface designs a standard.
36.Define Metaphor
a. It relates two otherwise unrelated things by using one to denote the other
37.What is Spring loaded modes?
a. When they continually must take some action to remain in that mode; for
example dragging the mouse with a mouse button pressed to highlight a
portion of text.
38.What is Tool – driven modes?
a. If you are in a drawing a application, you may be able to choose a tool,
such as a pencil or a paintbrush for drawing.
39.Define debugging.
It is the process of finding out where something went wrong an
correcting the code to eliminate the errors or bugs that cause unexpected
results.
40.What kind of error occurred in testing?
a. Language(Syntax) error
b. Run-time Error
c. Logic error
41.List the Myer’s debugging principles.
The Myer’s bug location and debugging principles
1. Bug locating principles
2. Debugging principles

Five Mark – UNIT I to UNIT V

1. Explain about Object Modeling Technique.

a. It presented by Jim Rumbaugh an gis coworkers describes a method for
the analysis, design and implementation of a system using an object-
oriented technique.
b. OMT is a fast approach.
 c. A process description and consumer-producer relationships can be
expressed using OMT’s functional model.
d. It consists of four phases
i. Analysis - the results are objects and dynamic and fuctional
models.
ii. System Design – architecture of the design
iii. Object design – produces design document
iv. Implementation – produces reusable and robust code.
e. Object Model – it represent with an object diagram. The object diagram
contains classes interconnected by association lines. Each class
represents individual objects. The association lines establish relationships
among the classes
f. Dynamic Model- it represents 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
g. Functional Model – it represent data flow diagram. DFD use four primary
symbols, process, data flow, data store, external entity.
2. Discuss about Booch Methodology.
a. Booch defines a lot of symbols to document almost every design design.
b. Booch method defines following diagrams
i. Class diagrams
ii. Object diagrams
iii. State transition diagram
iv. Module diagrams
v. Process diagrams
vi. Interaction diagram
c. Macro development Process:
d. Conceptualization – establish core requirements of the system
e. Analysis – to describe roles and responsibilities object are carry out in
performing the desire behavior of the system.
f. Design- to decide what classes exist and how they relate to each other.
g. Implementation – refine the system through much iteration.
h. Maintenance – to add new requirements and eliminate bugs.
i. Micro Development process
j. Identify classes an objects
 k. Identify class and object object semantics
l. Identify class and object object relationships
m. Identify class and object object interfaces and implementation.
3. Discuss about Jacobson methodologies.
a. Use case - use cases are scenarios for understanding system
requirements. A use case is an interaction between users and a system.
b. Object-Oriented Sofware Engineering also called Objectory.
c. The development process, called use case driven development, stresses
that use cases are involved in several phases of the development,
including analysis, design, validation and testing.
d. Usecase model – it defines the outside an inside of the system’s behavior.
e. Domain object model- the objects of the “real” world are mapped into the
domain object model.
f. Analysis object model – how the source code should be carried out and
written.
g. Implementation model- implementation of the system
h. Test model- it constitutes the test plans, specifications and reports.
i. Object oriented business engineering
j. Analysis phase- it defines the system to be built in terms of the problem-
domain object model, requirement model and the analysis model.
k. Design and implementation phase – identified by the design models
l. Testing phase – the levels include unit-testing, integration testing, and
system testing.
4. Discuss about pattern template
a. Name : a meaningful name.
b. Problem – a statement of the problem that describes its intent
c. Context - the preconditions under which the problem and its solution
seem to recur and for which the solution is desirable.
d. Forces – a description of the relevant forces and constraints and how
they interact.
e. Solution – static relationships and dynamic rules describing how to
realize the desired outcome.
f. Examples – one or more sample applications of the pattern that illustrate
a specific initial context
 g. Rationale- a justifying explanation of steps or rules in the pattern and
also of the pattern as a whole in terms of how and why it resolves its
forces in a particular way to be in an alignment with desired goals.
h. Resulting context – the state or configuration of the system after the
pattern has been applied.
i. Related patterns – the static and dynamic relationships between this
pattern and others within the same pattern language or system.
j. Known uses – the known occurrence of the pattern and its application
within existing systems.
5. Describe about layered technology.
a. Two layer architecture – direct communication between client and
server.
b. Three layer architecture – it is also called as middleware technology.
i. Workstation transmits the request and response.
c. The business layer – the business layer contains all the objects that
represents the business. Responsibilities of the business layer how they
interact to accomplish the business process.
d. Displaying details – business objects should have no special knowledge
of how they are being displayed and by whom.
e. Data access details – business objects also should have no special
knowledge of “where they come from”
f. The user interface layer(view layer) – it consists of objects with which
the user interacts as well as the objects needed to manage control the
interface.
i. Responding to user interaction-
1. The user interface designed to translate an action by the
user, such as clicking on a button or selecting from a menu,
into an appropriate response.
ii. displaying or printing business objects
1. This layer must paint the best picture possible of the
business objects for the user.
g. Access layer – the access layer contains objects that know how to
communicate with the place where the data is actually reside, whether it
be a relational database, mainframe, internet or file.
 i. Translation request – the access layer must be able to translate
any data-related requests from the business layer into the
appropriate protocol for data access.
ii. Translate results – the access layer also must be able to translate
the data retrieved back into the appropriate business objects.
6. Write a short note on class hierarchy.
a. An object oriented system organizes classes into a suber-sub class
hierarchy.
b. Different properties and behaviors are used as the basis for making
distinctions between classes and subclasses.
c. At the top of the class hierarchy are the most general classes and at the
bottom are the most specific
d. A subclass inherits all of the properties an methods defined in its
superclass.
e. For example, ford car classes that define ford car objects. Objects are
Mustang, Taurus, Thunderbird, they are considered subclasses of class
ford and the ford class is their superclass.
f. The ford class defines the behavior of ford cars, and the mustang class
defines the behavior of Mustang.

vehicle

car

ford

Mustang Taurus Thunderbird

7. Write short on:

a. Information hiding
b. Encapsulation
 i. Information hiding – the internal data and procedures of an object
and providing an interface to each object in such a way as to reveal
as little as possible about its inner working.
ii. For example, simula provides no protection, or information hiding
for objects, meaning that an object’s data.
iii. Encapsulation – wrapping of data
iv. Encapsulation protection mechanism with public, private, and
protected members.
v. Public members from accessed from anywhere. Private members
only from within a class. Protected members accessed only from
subclasses.
vi. An object is said to encapsulate the data and a program. This
means the user cannot see the inside of an object
vii. Per-class protection- it can access any object of that class and not
just the receiver.
viii. Per-object protection – it can access only one receiver.
ix. A car engine is an example of encapsulation.
8. Discuss about Super-sub class Relationship.
 The super-sub class relationship represents the inheritance relationship
between related classes, and the class hierarchy determines the lines of
inheritance between classes.
 Sub classes more specialized versions of their super classes.
 Superclass-subclass relationships, also known as generalization
hierarchy, allow objects to be built from other objects
 The super-sub class hierarchy is a relationship between classes, where
one class is the parent class another one class is the derived (child)class.
 Guide lines for identifying super-sub relationship, a generalization
o Top-own
o Bottom-up
o Reusability
o Multiple inheritance

Top down- look for noun phrases composed of various adjectives in a

class name.
Bottom-up- look for classes with similar attributes or methods
 Reusability – move attributes behaviors as high as possible in the
hierarchy.
Multiple inheritance- more than one base class and one derived class.
9. Explain the concept of Design Pattern.
a. Design pattern are devices that 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.
b. Pattern Name: Facade
c. Rationale and motivation:
i. The façade pattern can make the task of accessing a large number
of modules
ii. Using this pattern helps to simplify .
iii. But it is difficult to understand
d. Classes
i. Any number of classes involved in façade system
ii. Façade system at least four are more classes are required.
iii. One client, the façade and the classes
e. Advantages:
i. Interacting between many modules and classes
f. Disadvantages:
i. May lose some functionality
g. Examples:
i. Buildings
1. The client that ordered that program has determined that
there will be a need for only a finite number of objects
a. (e.g, windows,screen,projectors)
10.Discuss about Database Models.
a. Hierarchical model – the hierarchical model represents data as a single
rooted tree. Each node in the tree represents a data object and the
connections represent a parent- child relationship.

Motor vehicle

Bus truck car

Network model

A network database model is similar to a hierarchical database, with one

distinction. A network model record can have more than one parent.

Customer Soup

Order
Relational model

The relational model has the simplest, most uniform structure. The
columns of each table are attributes that define the data or value domain for entries in
that column. The rows of each table are tuples representing individual data objects
being stored. Primary key is the unique key.

Soup table Soup id Soup price

name

customer table Cust-id Name Address

Order table Order id Soup id Cust id

11.Prototyping the user interface
a. Prototyping involves a number of iterations. Through each iteration, we
add a little more to the application, and as we understand the problem a
little better, we can make more improvements.
b. It is highly desirable a prepare a prototype of the user interface during the
analysis to better understand the system requirements.
c. Create the user interface objects
d. Link or assign the appropriate behaviors
e. Test or debug
12.Write shot note on Impact of object orientation on testing,
a. Some types of error could become less plausible( not worth testing for)
b. Some types of error could become more plausible( worth testing now)
c. Some new types of error might appear
d. Impact of inheritance in testing
i. Base class contains methods
1. Inherited()
2. Redefined()
ii. Derived class contains method
1. Redefined()
e. Reusability of tests
i. If base:: redefined() and derived :: redefined() are 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.
13.Describe about Usability testing
a. Usability testing measures the ease of use as well as the degree of
comport and satisfaction users have with the software Products with door
usability can be difficult to learn, complicated to operate, and misused or
not used at all.
b. Low product usability leads to high costs for users and a bad reputation
for the developers. Usability is one of the most crucial factors in the
design and development of a product, especially the user interface.
 c. Usability testing must be a key part of the UI design process. Usability
testing should begin in the early stages of product development;
d. For example, it can be used to gather information about how users do
their work and find out their tasks, which can complement use cases.
Usability testing continues to provide valuable input for analyzing initial
design concepts and, in the later stages of product development can be
used to test specific product tasks the UI.
e. Usability test cases begin with the identification of use cases that can
specify the target audience, tasks, and test goals. When designing a test,
focus on use cases or tasks, not features. The main advantage is that all
design traces directly back to the user requirements Use cases and usage
scenarios can become test scenarios; Use case will drive the usability,
user satisfaction, and quality assurance test cases.
14.Discuss about User satisfaction testing.
a. User satisfaction testing is the process of quantifying the usability test
with some measurable attributes of the test, such as functionality, cost, or
ease of use. Usability can be assessed by defining measurable goals, such
as 95 percent of users should be able to find how to withdraw money
from the ATM machine without error and with no formal training.
b. 70 percent of all users should experience the new function as “a clear
improvement over the previous one”.90 percent of consumers should be
able to operate the VCR within 30 minutes
c. If the product is being built incrementally, the best measure of user
satisfaction is one product itself
d. In addition to prototyping and usability testing, another tool that can
assist us in developing high-quality software is measuring and
monitoring user satisfaction during software development process, during
 the design and development of the user interface. The principles
objective of the user satisfaction test
e. As communication vehicle between designers, as well as between users
and designers. To detect and evaluate changes during the design process.
To provide a periodic indication of divergences of opinion about the
current design. To enable pinpointing specific areas of dissatisfaction for
remedy. To provide a clear understanding of just how the completed
design is to be evaluated. The process of creating the test itself will
provide useful information.
15.Write a shot note on Test plan.
a. A test plan is developed to detect and identify potential problems before
delivering the software to its user.
b. Following steps needed to create a test plan
i. Objectives of the test
ii. Development of test case
iii. Test analysis
c. All passed tests should be repeated with the revised program is called
regression testing.
d. Guidelines for developing test plans
i. The test plan should contain a schedule and a list of required
resources
ii. A configuration control system provides a way of tracking the
changes to the code
iii. At the end of each month or as you reach each milestone, take time
to complete routine updates.
 Ten Mark (UNIT I to UNIT V)

1. Discuss about Use case model

Borrow books
uses

extends Check library card

uses
Get interlibrary loan
Member
Return books

clerk
Read books news paper

 Use case

 A use case is an interaction between users and a system.

 For eg, borrow a book

 Actors.

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

 A Single Actor may perform many use case

 Member is also example for an actor. Member can perform many use
case example of an library

 In a System:

 actors communicate with the system’s use case.

 Measurable Value:

 A use case must help the actor to perform a task that has identifiable
value

 For eg, borrowing books is something of value for a member of the

library

 Transaction:

 A transaction is an atomic set of activities that are performed either

fully or not at all.

 Examples of use cases:

 Borrow books:

 A member takes books from the library to read at home, depending on

the member record

 Get an inter- library loan.

 A member requests a book that the book does not have the library but
the book is located at another library and ordered through interlibrary
loan.

 Return books:

 A member brings borrowed books back to the library

 Check library book.

 A member submits his or her library card to the clerk, who checks the
borrower’s record.
 Extends Association:

 one use case that is similar to another use case but does a bit more
specialized.

 For eg, in the library example borrow books and get an interlibrary loan both
are similar use cases

 Uses Association:

 It occurs when you are describing your use case and notice that some of
them have sub flows in common.

 For library example, checking a library card is common among borrow

book, return book, and interlibrary loan use cases.

Guidelines for finding use cases

1. For each actor, find the tasks and functions that the actor should be able to
perform

2.name the use cases

3.Describe the use cases briefly by applying terms in which the user is familiar

Dividing use cases into Packages

 Each use case represents a particular scenario in the system. A design is

broken into packages.

 For library example, various scenario involves Do research and borrow

books.

 Its broken into two packages. They are borrow books, Do research
 2. Explain about identifying approaches.

 Noun Phrase Approach

 Common Class Patterns Approach

 The Use Case Driven Approach

 Class Responsibilities, And Collaborators(CRC)

Approach

Noun phrase approach

 All plurals are changed to singular, the nouns are listed, and the listed divided
into three categories

 Relevant classes

 Fuzzy classes

 Irrelevant classes

Relevant classes Fuzzy classes Irrelevant classes

Selecting classes from the Relevant and fuzzy categories

 Redundant classes

 Adjectives classes

 Attribute classes

 Irrelevant classes

Redundant classes:

 If more than one word is being used to describe the same idea, select the one
that is the meaningful in the context system.

Adjectives classes
  An adjective can suggest a different kind of object, different use of the same
object

Attribute classes

 Tentative objects that are used only as values be defined as attributes and not as
a class.

Irrelevant classes

 Each class must have a purpose and every class should be clearly defined as
necessary.

 You must formulate a statement of purpose for each candidate class

Review Redundant classes

Review irrelevant classes Review adjectives

Review Attributes

Example:ATM System

Common class Pattern approach

 Concept class

 Events class

 Organization class
  People class

 Places class

 Tangible things and device class

 Concept Class

 A concept is a particular idea or understanding that we have of our world

 To communicate with others

 Example:

 Performance is an example of concept class object

 Events Class

 Events classes are points in time that must be recorded

 Associated with things remembered are attributes such as who, when, where,
how, or why.

 Example:

 Landing, interrupt, request, and order are possible events.

 Organization Class

 An organization class is a collection of people, resources, facilities, or groups to

which the users being;

 Example:

 An accounting department might be considered a potential class

 People Class:

 (also known as person, roles, and roles played class)

 The people class represents the different roles users play in interacting with the
application

 Example:
  Employee, client, teacher, and manager are examples of people.

 Places Class:

 Context:

 Places are physical locations that the system must keep information about.

 Example:

 Buildings, stores, sites and offices are examples of places

 Tangieable things an devices class

 This class includes physical objects or groups.

 Example:

 Car is an example of tangible things

Classes,Resposibilities, and collaborators

CRC Process Consist of following three steps

 Identify classes’ responsibilities

 Assign responsibilities

 Identify Collaborators
Identify
classes and
Responsibility

Identify Assign
collaboration Responsibility

 Classes are identified and grouped by common attributes, which also provides
candidates for super classes.

 The class names then are written onto CRC cards

  The idea in locating collaborators is to identify how classes interact.

 Classes ,Responsibilities and collaborators cars 4” * 6” index cards.

Example: Bank ATM

 Account and Transaction provide the banking model
 The class Account is responsible mostly to the Bank Client class and it
collaborators with several object to fulfill its responsibilities

3. Discuss about Object Oriented design axiom.

a. A theorem is a proposition that may not be self-evident but can be proven
from accepted axioms.
b. A corollary is a proposition that follows from an axiom or another
proposition that has been proven.
Axiom 1.
i. The Independence axiom.
Maintain the independence of components.
Axiom 2
ii. The information axiom.
Minimize the information content of the design
Corollary 1.
 Uncoupled design with less information content.
Highly cohesive objects can improve coupling because only
a minimal amount of essential information need be passed
between objects.
Coupling :
Coupling measures of the strength of association established by a
connection from one object or software component to another. Coupling
is a binary relationship. A is coupled with B.
Types of coupling
6. content coupling
7. common coupling
8. control coupling
9. stamp coupling
10.data coupling
Cohesion
Coupling deals with interaction between objects or software components. We
also need to consider interactions within a single object or software component,
called cohesion.
Corollary 2.
 Single Purpose.
a. Each class must have a single, clearly defined purpose, when
you document, you should be able to easily describe the
purpose a class in a 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 and
logical design.
Corollary 5:
 Standardization
Promote standardization by designing interchangeable components
and reusing existing classes or components
Corollary 6.
 Design with inheritance.
Common behavior must be moved to super classes. The super
class-subclass structure must make logical sense

Corollary 4

Corollary 1

Axiom 1
Corollary 2

Corollary 3
Axiom 2

Corollary 6 Corollary 5
4. Discuss about designing view layer classes
a. Two-major aspects
i. Input-responding to user interaction
1. The user interface designed to translate an action by the
user, such as clicking on a button or selecting from a menu,
into an appropriate response.
ii. Output- displaying or printing business objects
1. This layer must paint the best picture possible of the
business objects for the user.
b. Four major activities
i. Macro level UI design process – used for identifying view layer
objects.
1. The main objective of the macro process is to identify
classes that interact with human actors by analyzing to use
cases developed in the analysis phase.
ii. Micro level UI design process –
1. Designing the view layer objects by applying design axioms
and corollaries.
2. Prototyping the view layer interface.
iii. Testing usability and user satisfaction
iv. Refining and iterating the design

Macro – level process

i. For every class identified, determine if the class interacts with a

human actor.
a. Identify the view objects for the class
b. Zoom in by utilizing sequence or collaboration diagrams
c. Define the relationships among the view objects

ii. iterate and refine

advantage – utilizing use cases in identifying and designing view layer objects.

Micro – level process

  A user –centered interface replicates the user’s view of doing
things by providing the outcomes users expect for any action.
 For example, If the goal of an application is to automate what was
a paper process, then the tool should be simple and natural.
i. For every interface object identified in the macro UI design process, apply
micro-level UI design rules and corollaries to develop the UI.

ii. Iterate and refine.

UI design rules:

Rule 1: Making the Interface Simple

Rule 2: making the interface transparent and natural

Rule 3: allowing users to be in control of the software.

5. What is the Purpose of view layer interface.

a. Forms and data entry windows. Data entry windows provide access to
data that users can retrieve, display , and change in the application.
b. Dialog boxes: dialog boxes display status information or ask users to
supply information or make a decision before continuing with a task
c. Application window : an application window is a container of application
objects or icons.
d. Guidelines for designing forms and data entry windows
i. Adding and deleting rows
ii. Changing data in rows
iii. Saving and changes.
e. Guidelines for designing forms and dialog boxes and error messages
i. Your error message should be positive. For example instead of
displaying “ you have typed an illegal date format. “display the
message “ enter date format mm/dd/yyyy
ii. Your error message should be constructive. For example, avoid
messages such as “ you should know better! Use OK button”;
instead of display “press the Undo button and try again”
iii. Your error message should be brief and meaningful.
 f. Guidelines for designing application windows
i. File Menu – file menu provides an interface for the primary
operations that apply to a file, commands such as open , new, save,
save as, print .print preview etc
ii. Edit menu – include general purpose editing commands on the edit
menu. These commands include the cut, copy, paste…etc
iii. View menu – commands on the view menu should change the
user’s view of data in the window.(zoom, outline)
iv. Window menu – window menu in multiple document, interface-
style applications
v. Help menu – the help menu contains commands that provide acess
to help information.
g. Guidelines for using Fonts
i. Most commercial applications use 12-points system font for menus
and 10-point system font in dialog boxes.
ii. Using too many font styles, sizes and colors
iii. Use bold for control labels
6. Discuss about various testing strategies.

Black Box Testing, also known as Behavioral Testing, is a software

testing method in which the internal structure/ design/ implementation of
the item being tested is not known to the tester. These tests can be
functional or non-functional, though usually functional.
 This method is named so because the software program, in the eyes of the
tester, is like a black box; inside which one cannot see. This method
attempts to find errors in the following categories:

 Incorrect or missing functions

 Interface errors
 Errors in data structures or external database access
 Behavior or performance errors
 Initialization and termination errors

White Box Testing

White box testing is a testing technique, that examines the program structure
and derives test data from the program logic/code. The other names of glass box
testing are clear box testing, open box testing, logic driven testing or path
driven testing or structural testing.
White Box Testing Techniques:
 Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure that all
branches are tested at least once.
 Path Coverage - This technique corresponds to testing all possible paths which
means that each statement and branch is covered.
 A testing strategy is a general approach to the testing process rather than a
method of devising particular system or component tests. Different testing
strategies may be adopted depending on the type of system to be tested and the
development process used. There are two different strategies available: Top-
Down Testing and Bottom-Up Testing.
 In Top-Down Testing, high levels of a system are tested before testing the
detailed components. The application is represented as a single abstract
component with sub-components represented by stubs. Stubs have the same
interface as the component but very limited functionality.
 After the top-level component has been tested, its sub-components are
implemented and tested in the same way. This process continues recursively
until the bottom - level components are implemented. The whole system may
then be completely tested. Top-down testing should be used with top-down
program development so that a system component is tested as soon as it is
coded. Coding and testing are a single activity with no separate component or
module testing phase.
 If top-down testing is used, unnoticed design errors may be detected at an
early stage in the testing process. As these errors are usually structural errors,
early detection means that extensive re-design re-implementation may be
avoided. Top-down testing has the further advantage that we could have a
prototype system available at a very early stage, which itself is a psychological
boost. Validation can begin early in the testing process as a demonstrable
system can be made available to the users.
 Bottom-Up Testing is the opposite of Top-Down. It involves testing the
modules at the lower levels in the hierarchy, and then working up the hierarchy
of modules until the final module is tested. This type of testing is appropriate
for object-oriented systems in that individual objects may be tested using their
own test drivers. They are then integrated and the object collection is tested.

7. Discuss the use case approach of object-oriented system development.

o 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
o Object-oriented system development includes these
activities:
o Object-oriented analysis- use case driven
o Object-oriented design
o Prototyping
o Component based development
o Incremental testing

Object –oriented analysis- Use-Case Driven

o The object-oriented analysis phase of software development is

concerned with determining the system requirements the
identifying classes and their relationship to other classes in the
problem domain.
o To understand the system requirements, need to identify the users
or the actors.
o A use case is an interaction between users and a system.
o The intersections among objects roles to achieve a given goal are
called collaboration.
o The scenarios represent only one possible example of the
collaboration.
o Expressing these high-level processes and interactions with
customers in a scenarios and analyzing it is referred to as use-case
modeling.
 o The use-case model represent the user view of the system or user
needs
o For example, the objects in the incentive payroll system might
include the examples:
o The employee, worker, supervisor, office administrator.
o The paycheck
o The product being made
o The process used to make the product
o Documentation is another important activities, which does not end
with object-oriented analysis.
o 80-20 rule generally applies for the documentation.
o 80 percent of the work can be done with 20 percent documentation.

Object-oriented design

o the goal of object-oriented design(OOD) is to design the classes

identified during the analysis phase and the user interface.
o For example during the design phase, need to add objects for the
user interface to the systems( for e.g, data entry windows, browser
windows)
o Build the object model based on objects and their relationships,
then iterate and refine the model;
 Design and refine classes
 Design and refine attributes
 Design and refine methods
 Design and refine structures
 Design and refine associations
o A few guidelines to use in object-oriented design:
  Reuse, rather than build, a new class. Know the
existing classes.
 Designs the large number of simple classes, rather
than a small number of complex classes
 Design methods
 Critique what you have proposed. If possible, go back
and refine the classes

Prototyping

o The object oriented analysis and design describe the system

features, it is important to construct a prototype of some of the key
system components shortly after the products are selected
o A prototype enables to fully understand how easy or difficult, it
will be to implement some of the features of the system
o Prototyping provides the developer a means to test and refine the
user interface and increase the usability of the system.
o Prototyping have been categorized in various ways
o A horizontal prototype is a simulation of the interface
o A vertical prototype is a subset of the system features with
complete functionality.
o The analysis prototype is an aid for exploring the problem
domain.
o A domain prototype is an aid for the incremental development of
the ultimate software solution.

Component based Development

 o Component-based development (CBD) is an industrialized
approach to the software development process.
o Application development moves from custom development to
assembly of prebuilt, pretested, reusable software components that
operations with each other.
o Two basic ideas underlie component-based development
o First, the application development can be improved significantly if
applications can be assembled quickly from prefabricated software
components.
o Second, an increasingly large collection of interpretable software
components could be made available to developers in both general
and specialist catalogs.
o A CBD developers can assemble components to construct a
complete software system.

Rapid application development

o Rapid application development (RAD) is a set of tools and techniques

that can be used to build an application faster than typically possible with
traditional methods.
o RAD application achieved a substantial reduction in time to market but
realized no significant reduction in the individual software cycles.

Incremental testing

o The problem was that developers would turn over applications to a

quality assurance (QA) group for testing only after development was
completed.
o The SQA group wasn’t included in the initial plan, it had no clear picture
of the system characteristics until it came time to test.