I.

Macro and Micro Development Process

Macro Means the Big Picture

When you adopt a macro perspective, you are analyzing how your business is performing using big-picture
concepts such as sales growth, number of new customers, and number of products or services sold. You are also
looking at your company’s position in the marketplace relative to your competition, how the economy and other
external influences are affecting your business, employee diversity, and employee satisfaction.
Micro Gives a Deep Dive

With a micro perspective, you are taking a deep dive into every detail that underlies your daily activities and
processes. The goal is to find out how things are working on a level that can be measured, as opposed to
stepping back and looking at the big picture.
Differences Between Macro and Micro

The main difference between a macro perspective and a micro perspective is that in a macro view you are
always stepping back for a big-picture view. You’re not concerned with the details of how things are being
done, but instead, you’re trying to figure out how your company is working in major areas that determine
success or failure. For example, a macro perspective could tell you that your profit margin has shrunk over the
past six months, but a micro perspective would then tell you the reasons why this has happened when you dive
into a detailed view of your sales and marketing operations.

In contrast, a micro view is always going to be focused on the small details that can give you answers about the
big picture. In a micro perspective, details are essential, and the ability to measure performance through the use
of metrics is the hallmark of this perspective. Put simply, a macro perspective tells you where your business is
at any given time, and a micro perspective tells you why your business is in that position. For true success, you
should try to adopt a balance that utilizes both perspectives.

II. Advantages/ Benefits and Disadvantages/Pitfalls of OOAD

Benefits of Object-Oriented Approach

Object-oriented databases make the promise of reduced maintenance, code reusability, real world modeling, and
improved reliability and flexibility. However, these are just promises and in the real world some users find that
the object-oriented benefits are not as compelling as they originally believed. For example, what is code
reusability? Some will say that they can reuse much of the object-oriented code that is created for a system, but
many say there is no more code reusability in object-oriented systems than in traditional systems. Code
reusability is a subjective thing, and depends heavily on how the system is defined. The object-oriented
approach does give the ability to reduce some of the major expenses associated with systems, such as
maintenance and development of programming code. Here are some of the benefits of the object-oriented
approach:
Reduced Maintenance: The primary goal of object-oriented development is the assurance that the system will
enjoy a longer life while having far smaller maintenance costs. Because most of the processes within the
system are encapsulated, the behaviors may be reused and incorporated into new behaviors.

Real-World Modeling: Object-oriented system tend to model the real world in a more complete fashion than
do traditional methods. Objects are organized into classes of objects, and objects are associated with
behaviors. The model is based on objects, rather than on data and processing.

Improved Reliability and Flexibility: Object-oriented system promise to be far more reliable than traditional
systems, primarily because new behaviors can be "built" from existing objects. Because objects can be
dynamically called and accessed, new objects may be created at any time. The new objects may inherit data
attributes from one, or many other objects. Behaviors may be inherited from super-classes, and novel behaviors
may be added without effecting existing systems functions.

High Code Reusability: When a new object is created, it will automatically inherit the data attributes and
characteristics of the class from which it was spawned. The new object will also inherit the data and behaviors
from all superclasses in which it participates. When a user creates a new type of a widget, the new object
behaves "wigitty", while having new behaviors which are defined to the system.

The downside of the Object Technology

There are several major misconceptions which must be addressed when considering the use of an object-
oriented method:

Object-oriented Development is not a panacea - Object-oriented Development is best suited for dynamic,
interactive environments, as evidenced by its widespread acceptance in CAD/CAM and engineering design
systems. Wide-scale object-oriented corporate systems are still unproved, and many bread-and-butter
information systems applications (i.e. payroll, accounting), may not benefit from the object-oriented approach.

Object-oriented Development is not a technology - Although many advocates are religious in their fervor for
object-oriented systems, remember that all the "HOOPLA" is directed at the object-oriented approach to
problem solving, and not to any specific technology.

Object-oriented Development is not yet completely accepted by major vendors - Object-oriented

Development has gained some market respectability, and vendors have gone from catering to a "lunatic fringe"
to a respected market. Still, there are major reservations as to whether Object-oriented development will
become a major force, or fade into history, as in the 1980's when Decision Support Systems made great
promises, only to fade into obscurity.

Cannot find qualified programmers and DBA's

When one investigates the general acceptance of object-oriented systems in the commercial marketplace, you
generally find that most managers would like to see an object technology approach, but they do not have the
time to train their staffs in object-oriented methods. Other will say that the object-oriented method is only for
graphical workstation systems, and that there is no pressing need for object-oriented system within mainstream
business systems.

Even though commercial object-oriented programming languages have been on the market for several years,
systems written with object-oriented languages comprise less than 1% of systems today.

III. Macro and Micro Development Process in View Layer Design

The macro development process consists of the following steps:
Conceptualization
Establish the core requirements and develop a prototype.
Analysis and development of the model
Use the class diagram to describe the roles and responsibilities of objects. Use the object diagram to describe
the desired behavior of the system.
Design or create the system architecture.
Use the class diagram to decide what classes exist and how they relate to each other, the object diagram to
decide what mechanisms are used, the module diagram to map out where each class and object should be
declared, and the process diagram to determine to which processor to allocate a process.
Evolution or implementation-
Refine the system through much iteration.
Maintenance-Make localized changes to the system to add new requirements and eliminate bugs.

Macro Level Design Process

Micro Development process

The micro process is a description of the day-to-day activities by a single or small group of software developers.
It consists of the following steps.
  Identify classes and objects.
 Identify class and object semantics.
 Identify class and object relationships.
 Identify class and object interface and implementation.

Micro Level Design Process

Designing view layer objects:

o Effective interface design is following the set of rules.

o It also involves early planning of the interface and continued work through the software
development process.
o The process of designing the user interface involves,
 Classifying the specific need of the application.
 Identify the use cases and interface objects.
 Devising the design that best meets user’s needs.

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 at the software.

Rule 1: Making the interface simple

Each UI class must have a single, clearly defined purpose.
Factors for affecting Design application:
  Deadlines may require you to deliver a product to market with a minimal design process.
 Comparative evaluations may force you to consider additional features.

Rule 2: Making the interface transparent and natural.

There showed be strong mapping between the user’s view of doing things and UI classes.
Example: Billing, Insurance, Inventory and Banking applications can represent forms that are visually
equivalent to the paper forms users are accustomed to seeing.
UI Design:

 UI should not make users focus on the mechanism of an application.

 A good user interface doesn’t bother the user with mechanics.
 A goal of user interface design is to make the user interaction with the computer as simple and natural as
possible.

Rule 3: Allowing users to be in control at the software.

Users always should “feel in control of the software” rather than “feeling controlled by the software”.
Rule:

 UI object should represent, at most, one business object, perhaps that some services of that business
object.
 Main idea is to avoid creating a single UI class for several business objects, since it makes the UI less
flexible and faces the user to perform tasks in a monolithic way.

Ways to put users in control:

o Make the interface forgiving

o Make the interface visual.
o Provide immediate feedback
o Avoid modes like,
 Modal dialog
 Spring-loaded modes.
 Tool-driven modes.
 Make the interface consistent.

IV.Patterns and Frameworks

pattern (design pattern)

In software development, a pattern (or design pattern) is a written document that describes a general solution to
a design problem that recurs repeatedly in many projects. Software designers adapt the pattern solution to their
specific project. Patterns use a formal approach to describing a design problem, its proposed solution, and any
other factors that might affect the problem or the solution. A successful pattern should have established itself as
leading to a good solution in three previous projects or situations.

In object-oriented programming, a pattern can contain the description of certain objects and object classes to be
used, along with their attributes and dependencies, and the general approach to how to solve the problem. Often,
programmers can use more than one pattern to address a specific problem. A collection of patterns is called
a pattern framework.

Design Patterns are reusable solutions to commonly occuring problems(in the context of software design).
Design patterns were started as best practices that were applied again and again to similar problems encountered
in different contexts. They become popular after they were collected, in a formalized form, in the Gang Of Four
book in 1994. Originally published with c++ and smaltalk code samples, design patterns are very popular in
Java and C# can be applied in all object oriented languanges. In functional languages like Scala, certain patterns
are not necesary anymore.

Design patterns include the following types of information:

o Name that describes the pattern

o Problem to be solved by the pattern
o Context, or settings, in which the problem occurs
o Forces that could influence the problem or its solution
o Solution proposed to the problem
o Context for the solution
o Rationale behind the solution (examples and stories of past successes or failures often go here)
o Known uses and related patterns
o Author and date information
o References and keywords used or searching
o Sample code related to the solution, if it helps

Design pattern is a general reusable solution or template to a commonly occurring problem in software design.
The patterns typically show relationships and interactions between classes or objects. The idea is to speed up the
development process by providing tested, proven development paradigm.

Goal:
• Understand the problem and matching it with some pattern.
• Reusage of old interface or making the present design reusable for the future usage.
Example:
For example, in many real world situations we want to create only one instance of a class. For example, there
can be only one active president of country at a time regardless of personal identity. This pattern is called
Singleton pattern. Other software examples could be a single DB connection shared by multiple objects as
creating a separate DB connection for every object may be costly. Similarly, there can be a single configuration
manager or error manager in an application that handles all problems instead of creating multiple managers.

Types of Design Patterns

There are mainly three types of design patterns:
1. Creational
These design patterns are all about class instantiation or object creation. These patterns can be further
categorized into Class-creational patterns and object-creational patterns. While class-creation patterns use
inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the
job done.
Creational design patterns are Factory Method, Abstract Factory, Builder, Singleton, Object Pool and Prototype.
2. Structural
These design patterns are about organizing different classes and objects to form larger structures and provide
new functionality.
Structural design patterns are Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data
and Proxy.
3. Behavioral
Behavioral patterns are about identifying common communication patterns between objects and realize these
patterns.
Behavioral patterns are Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null
Object, Observer, State, Strategy, Template method, Visitor
Gang of Four Design Patterns

Design patterns provide solutions to common software design problems. In the case of object-oriented
programming, design patterns are generally aimed at solving the problems of object generation and interaction,
rather than the larger scale problems of overall software architecture. They give generalised solutions in the
form of templates that may be applied to real-world problems.

Design patterns are a powerful tool for software developers. However, they should not be seen as prescriptive
specifications for software. It is more important to understand the concepts that design patterns describe, rather
than memorising their exact classes, methods and properties. It is also important to apply patterns appropriately.
Using the incorrect pattern for a situation or applying a design pattern to a trivial solution can overcomplicate
your code and lead to maintainability issues.

The first type of design pattern is the creational pattern. Creational patterns provide ways to instantiate
single objects or groups of related objects. There are five such patterns:

 Abstract Factory. The abstract factory pattern is used to provide a client with a set of related or dependant
objects. The "family" of objects created by the factory are determined at run-time.

 Builder. The builder pattern is used to create complex objects with constituent parts that must be created in
the same order or using a specific algorithm. An external class controls the construction algorithm.

 Factory Method. The factory pattern is used to replace class constructors, abstracting the process of object
generation so that the type of the object instantiated can be determined at run-time.

 Prototype. The prototype pattern is used to instantiate a new object by copying all of the properties of an
existing object, creating an independent clone. This practise is particularly useful when the construction of a
new object is inefficient.

 Singleton. The singleton pattern ensures that only one object of a particular class is ever created. All further
references to objects of the singleton class refer to the same underlying instance.

Structural Patterns
The second type of design pattern is the structural pattern. Structural patterns provide a manner to
define relationships between classes or objects.

 Adapter. The adapter pattern is used to provide a link between two otherwise incompatible types by
wrapping the "adaptee" with a class that supports the interface required by the client.

 Bridge. The bridge pattern is used to separate the abstract elements of a class from the implementation
details, providing the means to replace the implementation details without modifying the abstraction.

 Composite. The composite pattern is used to create hierarchical, recursive tree structures of related objects
where any element of the structure may be accessed and utilised in a standard manner.

 Decorator. The decorator pattern is used to extend or alter the functionality of objects at run-time by
wrapping them in an object of a decorator class. This provides a flexible alternative to using inheritance to
modify behaviour.

 Facade. The facade pattern is used to define a simplified interface to a more complex subsystem.

 Flyweight. The flyweight pattern is used to reduce the memory and resource usage for complex models
containing many hundreds, thousands or hundreds of thousands of similar objects.
 Proxy. The proxy pattern is used to provide a surrogate or placeholder object, which references an
underlying object. The proxy provides the same public interface as the underlying subject class, adding a
level of indirection by accepting requests from a client object and passing these to the real subject object as
necessary.

Behavioural Patterns
The final type of design pattern is the behavioural pattern. Behavioural patterns define manners of
communication between classes and objects.

 Chain of Responsibility. The chain of responsibility pattern is used to process varied requests, each of
which may be dealt with by a different handler.

 Command. The command pattern is used to express a request, including the call to be made and all of its
required parameters, in a command object. The command may then be executed immediately or held for
later use.

 Interpreter. The interpreter pattern is used to define the grammar for instructions that form part of a
language or notation, whilst allowing the grammar to be easily extended.

 Iterator. The iterator pattern is used to provide a standard interface for traversing a collection of items in an
aggregate object without the need to understand its underlying structure.

 State. The state pattern is used to alter the behaviour of an object as its internal state changes. The pattern
allows the class for an object to apparently change at run-time.

 Strategy. The strategy pattern is used to create an interchangeable family of algorithms from which the
required process is chosen at run-time.

 Template Method. The template method pattern is used to define the basic steps of an algorithm and allow
the implementation of the individual steps to be changed.

 Visitor. The visitor pattern is used to separate a relatively complex set of structured data classes from the
functionality that may be performed upon the data that they hold.

Frameworks

Frameworks usually contain implementations of many cooperating design patterns

Framework. A framework, or software framework, is a platform for developing software applications. It

provides a foundation on which software developers can build programs for a specific platform. ...
A framework may also include code libraries, a compiler, and other programs used in the software development
process
V.Testing and Quality Assurance Metrices

Once a program code is written, it must be tested to detect and subsequently handle all errors in it. A number of
schemes are used for testing purposes.
Another important aspect is the fitness of purpose of a program that ascertains whether the program serves the
purpose which it aims for. The fitness defines the software quality.

Testing Object-Oriented Systems

Testing is a continuous activity during software development. In object-oriented systems, testing encompasses
three levels, namely, unit testing, subsystem testing, and system testing.

Unit Testing
In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented as per
design and whether the methods and the interfaces are error-free. Unit testing is the responsibility of the
application engineer who implements the structure.

Subsystem Testing
This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead. It
involves testing the associations within the subsystem as well as the interaction of the subsystem with the outside.
Subsystem tests can be used as regression tests for each newly released version of the subsystem.

System Testing
System testing involves testing the system as a whole and is the responsibility of the quality-assurance team. The
team often uses system tests as regression tests when assembling new releases.

Object-Oriented Testing Techniques

Grey Box Testing
The different types of test cases that can be designed for testing object-oriented programs are called grey box
test cases. Some of the important types of grey box testing are −
 State model based testing − This encompasses state coverage, state transition coverage, and state
transition path coverage.
 Use case based testing − Each scenario in each use case is tested.
 Class diagram based testing − Each class, derived class, associations, and aggregations are tested.
 Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested.

Techniques for Subsystem Testing

The two main approaches of subsystem testing are −
 Thread based testing − All classes that are needed to realize a single use case in a subsystem are integrated
and tested.
 Use based testing − The interfaces and services of the modules at each level of hierarchy are tested.
Testing starts from the individual classes to the small modules comprising of classes, gradually to larger
modules, and finally all the major subsystems.

Categories of System Testing

 Alpha testing − This is carried out by the testing team within the organization that develops software.
  Beta testing − This is carried out by select group of co-operating customers.
 Acceptance testing − This is carried out by the customer before accepting the deliverables.

Software Quality Assurance

Software Quality
Schulmeyer and McManus have defined software quality as “the fitness for use of the total software product”.
A good quality software does exactly what it is supposed to do and is interpreted in terms of satisfaction of the
requirement specification laid down by the user.

Quality Assurance
Software quality assurance is a methodology that determines the extent to which a software product is fit for use.
The activities that are included for determining software quality are −

 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system
Quality Factors
 Correctness − Correctness determines whether the software requirements are appropriately met.

 Usability − Usability determines whether the software can be used by different categories of users
(beginners, non-technical, and experts).
 Portability − Portability determines whether the software can operate in different platforms with different
hardware devices.
 Maintainability − Maintainability determines the ease at which errors can be corrected and modules can
be updated.
 Reusability − Reusability determines whether the modules and classes can be reused for developing other
software products.

Object-Oriented Metrics
Metrics can be broadly classified into three categories: project metrics, product metrics, and process metrics.

Project Metrics
Project Metrics enable a software project manager to assess the status and performance of an ongoing project.
The following metrics are appropriate for object-oriented software projects −

 Number of scenario scripts

 Number of key classes
 Number of support classes
 Number of subsystems
Product Metrics
Product metrics measure the characteristics of the software product that has been developed. The product metrics
suitable for object-oriented systems are −
  Methods per Class − It determines the complexity of a class. If all the methods of a class are assumed to
be equally complex, then a class with more methods is more complex and thus more susceptible to errors.
 Inheritance Structure − Systems with several small inheritance lattices are more well–structured than
systems with a single large inheritance lattice. As a thumb rule, an inheritance tree should not have more
than 7 (± 2) number of levels and the tree should be balanced.
 Coupling and Cohesion − Modules having low coupling and high cohesion are considered to be better
designed, as they permit greater reusability and maintainability.
 Response for a Class − It measures the efficiency of the methods that are called by the instances of the
class.

Process Metrics
Process metrics help in measuring how a process is performing. They are collected over all projects over long
periods of time. They are used as indicators for long-term software process improvements. Some process metrics
are −

 Number of KLOC (Kilo Lines of Code)

 Defect removal efficiency
 Average number of failures detected during testing
 Number of latent defects per KLOC

V.Types of Metrices

 Product non-reliability metrics, assessing the number of remaining defects.

 Functionality metrics, assessing how much useful functionality the product provides.
 Performance metrics, assessing a product's use of available resources: computation speed, space
occupancy.
 Usability metrics, assessing a product's ease of learning and ease of use.
 Cost metrics, assessing the cost of purchasing and using a product.
 Internal product metrics include:
 Size metrics, providing measures of how big a product is internally.
 Complexity metrics (closely related to size), assessing how complex a product is.
 Style metrics, assessing adherence to writing guidelines for product components (programs and
documents).
 Process metrics include:
 Cost metrics, measuring the cost of a project, or of some project activities (for example original
development, maintenance, documentation).
 Effort metrics (a subcategory of cost metrics), estimating the human part of the cost and typically
measured in person-days or person-months.

 Advancement metrics, estimating the degree of completion of a product under construction.
 Process non-reliability metrics, assessing the number of defects uncovered so far.
 Reuse metrics, assessing how much of a development benefited from earlier developments.
