Types of Use Cases Use cases could be viewed as concrete or abstract.

An abstract use case is not complete and has no initiation actors but is used by a concrete use case, which
does interact with actors.
Identifying the Actors
i. The term actor represents the role a user plays with respect to the system.
ii. ii. When dealing with actors, it is important to think about roles rather than people or job titles.
iii. iii. Who affects the system? Or,
iv. iv. Which user groups are needed by the system to perform its functions? These functions can be
both main functions and secondary functions, such as administration.
v. v. Which external hardware or other systems (if any) use the system to perform tasks?
vi. vi. What problems does this application solve (that is, for whom)?
vii. vii. And, finally, how do users use the system (use case)? What are they doing with the system?

Guidelines for Finding Use Cases
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.
Name the use cases.
Describe the use cases briefly by applying terms with which the user is familiar.

Separate Actors From Users
Each use case should have only one main actor.
Isolate users from actors.
Isolate actors from other actors (separate the responsibilities of each actor).
Isolate use cases that have different initiating actors and slightly different behavior.
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
Effective Documentation: Common Cover All documents should share a common cover sheet
that identifies the document, the current version, and the individual responsible for the content.
8020 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
Familiar Vocabulary
Use a vocabulary that your readers understand and are comfortable with.
The main objective here is to communicate with readers and not impress them with buzz words.

Make the Document as Short as Possible
Eliminate all repetition;
Present summaries, reviews, organization chapters in less than three pages.
Make chapter headings task oriented so that the table of contents also could serve as an index.

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.

The main objective of the analysis is to capture a complete, unambiguous, and consistent picture of
the requirements of the system. Construct several models and views of the system to describe what
the system does rather than how. Capturing use cases is one of the first things to do in coming up
with requirements. Every use case is a potential requirement. The key in developing effective
documentation is to eliminate all repetition; present summaries, reviews, organization chapters in
less than three pages. Use the 8020 rule: 80 percent of the work can be done with 20 percent of the
documentation.

Object Analysis: Classification

The concept of classification
How to identify classes
Intelligent classification is intellectually hard work and may seem rather arbitrary. Martin and Odell have
observed in object-oriented analysis and design, that In fact, an object can be categorized in more than one
way. Approaches for I dentifying Classes
noun phrase approach
common class patterns approach
use-case driven approach

classes, responsibilities, & collaborators (CRC) approach
Noun Phrase Approach It examine Use cases, conduct interviews, and read requirements
specification carefully, dividing noun phrases into three categories

























CRC Cards CRC cards are 4" x 6" index cards. All the information for an object is written on a
card.


CRC starts with only one or two obvious cards. If the situation calls for a responsibility not already covered by
one of the objects: Add, or create a new object to address that responsibility.
Finding classes is not easy.
The more practice you have, the better you get at identifying classes.
There is no such thing as the right set of classes.
Finding classes is an incremental and iterative process.

Guidelines for Naming Classes
The class should describe a single object, so it should be the singular form of noun.
Use names that the users are comfortable with.
The name of a class should reflect its intrinsic nature.
By the convention, the class name must begin with an upper case letter.
For compound words, capitalize the first letter of each word - for example, Loan Window.
3.3 Identifying Object Relationships, Attributes, and Methods
Goals:
Analyzing relationships among classes
Identifying association
Association patterns
Identifying super- & subclass hierarchies

Three Types of Objects Relationships
Association
Super-sub structure (also known as generalization hierarchy)
Aggregation and a-part-of structure

Guidelines for I dentifying Super-sub Relationships: Top-down
for noun phrases composed of various adjectives on class name.



Bottom-up




Reusability

reate very specialized classes at the top of hierarchy.


Multiple inheritance

multiple inheritance system.

Class Responsibility: I dentifying Attributes and Methods

tes, methods, and
relationships among classes.

I dentifying Class Responsibility by Analyzing Use Cases and Other UML Diagrams

Guidelines For I dentifying Attributes Of Classes





UNIT IV OBJECT ORIENTED DESIGN
Access Layer
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 residewhether 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 layers 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: 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. 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. A
Date Base Management System (DBMS) is a set of programs that enables the creation and maintenance (access,
manipulate, protect and manage) of a collection of related data.
The purpose of DBMS is to provide reliable, persistent data storage and mechanisms for efficient, convenient
data access and retrieval.
Persistence refers to the ability of some objects to outlive the programs that created them.
Object lifetimes can be short for local objects (called transient objects) or long for objects stored indefinitely
in a database (called persistent objects).

Most object-oriented languages do not support serialization or object persistence, which is the process of
writing or reading an object to and from a persistence storage medium, such as disk file.
Unlike object oriented DBMS systems, the persistent object stores do not support query or interactive user
interface facilities.
Controlling concurrent access by users, providing ad-hoc query capability and allowing independent control
over the physical location of data are not possible with persistent objects.
The access layer (AL), which is a key part of every n-tier system, is mainly consist of a simple set of code that
does basic interactions with the database or any other storage device. These functionalities are often referred to
as CRUD (Create, Retrieve, Update, and Delete).
The data access layer need to be generic, simple, quick and efficient as much as possible. It should not include
complex application/ business logics.
I have seen systems with lengthy, complex store procedures (SP), which run through several cases before
doing a simple retrieval. They contain not only most part of the business logic, but application logic and user
interface logic as well. If SP is getting longer and complicated, then it is a good indication that you are burring
your business logic inside the data access layer.

4.4 Object Storage & Object InteroperabilityAtkinson describe 6 broad categories for the lifetime of a data.
Transient results to the evaluation of expressions Variables involved in procedure activation Global variables
and variables that are dynamically allocated Data that exist between the execution of a program Data that exist
between the versions of a program Data that outlive a program. The first 3 are transient data, data that cease to
exist beyond the lifetime of the creating process. The other 3 are non transient, or persistent data. The
programming languages provide excellent support for transient data. The non-transient data are well supported
by DBMS or a file system. In traditional file processing, each application defines and implements the files it
requires.
In DBMS, a single repository of data is maintained, which can be defined once and subsequently accessed by
various users.
DBMS contains not only the data but a a complete definition of the data formats it manages, known as Schema
or Meta-data, which contains a complete definition of the data formats, such as the data structures, types and
constraints.
In file processing applications, such meta data are encapsulated in the application programs themselves. But in
DBMS, the format of the meta-data is independent of any particular application data structure.

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.

Unit V SOFTWARE QUALITY AND USABILITY
5.1 Designing Interface Objects
5.2 Software Quality Assurance
5.3 System Usability & Measuring User Satisfaction 5.1 Designing Interface Objects
In computing an object-oriented user interface (OOUI) is a type of user interface based on an object-oriented
programming metaphor. In an OOUI, the user interacts explicitly with objects that represent entities in the
domain that the application is concerned with. Many vector drawing applications, for example, have an OOUI -
the objects being lines, circles and canvases. The user may explicitly select an object, alter its properties (such
as size or color), or invoke other actions upon it (such as to move, copy, or re-align it). If a business application
has any OOUI, the user may be selecting and/or invoking actions on objects representing entities in the business
domain such as customers, products or orders.
Jakob Nielsen defines the OOUI in contrast to function-oriented interfaces: "Object-oriented interfaces are
sometimes described as turning the application inside-out as compared to function-oriented interfaces. The main
focus of the interaction changes to become the users' data and other information objects that are typically
represented graphically on the screen as icons or in windows Dave Collins defines an OOUI as demonstrating
three characteristics:


e context of what users are trying to do, all the user interface objects fit together into a coherent overall
representation.

Jef Raskin suggests that the most important characteristic of an OOUI is that it adopts a 'noun-verb',
rather than a 'verb-noun' style of interaction, and that this has several advantages in terms of
usability.

5.2 Software Quality Assurance
Bugs and Debugging
Testing strategies.
The impact of an object orientation on testing.
How to develop test cases.
How to develop test plans.

I ntroduction Two issues in software quality are:
Validation or user satisfaction
Verification or quality assurance.
Elimination of the syntactical bug is the process of debugging.
Detection and elimination of the logical bug is the process of testing.
Error Types:
Language errors or syntax errors
Run-time errors
Logic errors

I dentifying Bugs and Debugging
The first step in debugging is recognizing that a bug exists.
Sometimes it's obvious; the first time you run the application, it shows itself.
Other bugs might not surface until a method receives a certain value, or until you take a closer look at the
output

There are no magic tricks for debugging. However, these steps might help:
Selecting appropriate testing strategies.

Developing test cases and sound test plan.
Debugging tools.
Debugging Tools
Debugging tools are a way of looking inside the program to help us determine what happens and why.
It basically gives us a snapshot of the current state of the program.

Testing Strategies There are four types of testing strategies These are:
Black Box Testing
White Box Testing
Top-down Testing
Bottom-up Testing

Black Box Testing
In a black box, the test item is treated as "black" whose logic is unknown.
All that's known is what goes in and what comes out, the input and output
Black box test works very nicely in testing objects in an O-O environment.

White box testing assumes that specific logic is important, and must be tested to guarantee systems proper
functioning.

One form of white box testing is called path testing.
It makes certain that each path in a program is executed at least once during testing.
Two types of path testing are:
Statement testing coverage, and
Branch testing coverage

Top-down Testing It assumes that the main logic of the application needs more testing than supporting logic.
Bottom-up Approach
It takes an opposite approach.
It assumes that individual programs and modules are fully developed as standalone processes.
These modules are tested individually, and then combined for integration testing.

5.3 System Usability & Measuring User Satisfaction
Verification - "Am I building the product right?"
Validation - "Am I building the right product?"
Two main issues in software quality are validation or user satisfaction and verification or quality assurance.
The process of designing view layer classes consists of the following steps:

1. In the macro-level user interface (UI) design process, identify view layer objects.
2. 2. In the micro-level UI, apply design rules and GUI guidelines. 3. Test usability and user satisfaction. 4.
Refine and iterate the design. Usability and User Satisfaction Testing Two issues will be discussed: 1.
Usability Testing and how to develop a plan for usability testing. 2. User Satisfaction Test and
guidelines for developing a plan for user satisfaction testing.


The International Organization for Standardization (ISO) defines usability as the effectiveness, efficiency, and
satisfaction with which a specified set of users can achieve a specified set of tasks in particular environments.
Defining tasks. What are the tasks?
Defining users. Who are the users?
A means for measuring effectiveness, efficiency, and satisfaction.
The phrase two sides of the same coin is helpful for describing the relationship between the usability and
functionality of a system.
Usability testing measures the ease of use as well as the degree of comfort and satisfaction users have with the
software.
Usability testing must begin with defining the target audience and test goals.
Run a pilot test to work out the bugs of the tasks to be tested.
Make certain the task scenarios, prototype, and test equipment work smoothly.
Guidelines for Developing Usability Testing
Focus groups" are helpful for generating initial ideas or trying out new ideas.

It requires a moderator who directs the discussion about aspects of a task or design.
Apply usability testing early and often.
Include all of softwares components in the test.
The testing doesnt need to be very expensive, a tape recorder, stopwatch, notepad and an office can produce
excellent results.
Tests need not involve many subjects.
More typically, quick, iterative tests with a small, well-targeted sample of 6 to 10 participants can identify 80
90 percent of most design problems.
Focus on tasks, not features.
Remember that your customers will use features within the context of particular tasks.
Make participants feel comfortable by explaining the testing process.
Emphasize that you are testing the software, not the participants.
If they become confused or frustrated, it is not a reflection on them.
Do not interrupt participants during a test.
If they need help, begin with general hints before moving to specific advice.
Keep in mind that less intervention usually yields better results.
Record the test results using a portable tape recorder, or better, a video camera.
You may also want to follow up the session with the user satisfaction test.
The test is inexpensive, easy to use and it is educational to those who administer it and those who fill it out.

Even if the results may never be summarized, or filled out, the process of creating the test itself will provide us
with useful information.