SE Module 3
SE Module 3
Object-Oriented Design
In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The
state is distributed among the objects, and each object handles its state data. For example, in a Library
Automation Software, each library representative may be a separate object with its data and functions
to operate on these data. The tasks defined for one purpose cannot refer or change data of other
objects. Objects have their internal data which represent their state. Similar objects create a class. In
other words, each object is a member of some class. Classes may inherit features from the superclass.
Object-Oriented Design
Objects: All entities involved in the solution design are known as objects. For example, person,
banks, company, and users are considered as objects. Every entity has some attributes
associated with it and has some methods to perform on the attributes.
Messages: Objects communicate by message passing. Messages consist of the integrity of the
target object, the name of the requested operation, and any other action needed to perform the
function. Messages are often implemented as procedure or function calls.
Encapsulation: Encapsulation is also called an information hiding concept. The data and
operations are linked to a single unit. Encapsulation not only bundles essential information of an
object together but also restricts access to the data and methods from the outside world.
Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or
sub-classes can import, implement, and re-use allowed variables and functions from their
immediate superclasses.This property of OOD is called an inheritance. This makes it easier to
define a specific class and to create generalized classes from specific ones.
Polymorphism: OOD languages provide a mechanism where methods performing similar tasks
but vary in arguments, can be assigned the same name. This is known as polymorphism, which
allows a single interface is performing functions for different types. Depending upon how the
service is invoked, the respective portion of the code gets executed.
DESIGN REUSE
Reuse-based software engineering is an approach to development that tries to maximize the reuse of
existing software. The software units that are reused may be of radically different sizes.
For example:
1. System reuse Complete systems, which may be made up of a number of application programs, may be
reused as part of a system of systems .
2. Application reuse An application may be reused by incorporating it without change into other
systems or by configuring the application for different customers. Alternatively, application families or
software product lines that have a common architecture, but that are adapted to individual customer
requirements, may be used to develop a new system.
4. Object and function reuse Software components that implement a single function, such as a
mathematical function, or an object class may be reused. This form of reuse, designed around standard
libraries, has been common for the past 40 years. Many libraries of functions and classes are freely
available. You reuse the classes and functions in these libraries by linking them with newly developed
application code. In areas such as mathematical algorithms and graphics, where specialized, expensive
expertise is needed to develop efficient objects and functions, reuse is particularly cost-effective
Design reuse is the process of building new software applications and tools by reusing
previously developed designs. New features and functionalities may be added by incorporating
minor changes.
Design reuse involves the use of designed modules, such as logic and data, to build a new and
improved product. The reusable components, including code segments, structures, plans and
reports, minimize implementation time and are less expensive. This avoids reinventing existing
software by using techniques already developed and to create and test the software.
Design reuse is used in a variety of fields, from software and hardware to manufacturing and
aeronautics.
Design reuse involves many activities utilizing existing technologies to cater to new design
needs. The ultimate goal of design reuse is to help the developers create better products
maximizing it's value with minimal resources, cost and effort.
Today, it is almost impossible to develop an entire product from scratch. Reuse of design
becomes necessary to maintain continuity and connectivity. In the software field, the reuse of
the modules and data helps save implementation time and increases the possibility of
eliminating errors due to prior testing and use.
Design reuse requires that a set of designed products already exist and the design information
pertaining to the product is accessible. Large software companies usually have a range of
designed products. Hence the reuse of design facilitates making new and better software
products. Many software companies have incorporated design reuse and have seen
considerable success. The effectiveness of design reuse is measured in terms of production,
time, cost and quality of the product. These key factors determine whether a company has
been successful in making design reuse a solution to its new software needs and demands.
With proper use of existing technology and resources, a company can benefit in terms of cost,
time, performance and product quality.
A proper process requires an intensive design reuse process model. There are two interrelated
process methodologies involved in the systematic design reuse process model.
1. Retrieve
2. Reuse
3. Repair
4. Recover
These are generally referred to as the four Rs. In spite of these challenges, companies have
used the design reuse concept as a successfully implemented concept in the software field at
different levels, ranging from low level code reuse to high level project reuse.
Software Reuse
A definition of software reuse is the process of creating software systems from predefined
software components.
A reusable component may be code, but the bigger benefits of reuse come from a broader and
higher-level view of what can be reused. Software specifications, designs, tests cases, data,
prototypes, plans, documentation, frameworks, and templates are all candidates for reuse.
Software reuse can cut software development time and costs. The major advantages for
software reuse are to:
Key factors that you should consider when planning reuse are:
1. The development schedule for the software If the software has to be developed quickly,
you should try to reuse complete systems rather than individual components. Although the fit to
requirements may be imperfect, this approach minimizes the amount of development required.
2. The expected software lifetime If you are developing a long-lifetime system, you should
focus on the maintainability of the system. You should not just think about the immediate
benefits of reuse but also of the long-term implications. Over its lifetime, you will have to adapt
the system to new requirements, which will mean making changes to parts of the system. If you
do not have access to the source code of the reusable components, you may prefer to avoid
off-the_shelf components and systems from external suppliers. These suppliers may not be able
to continue support for the reused software. You may decide that it is safer to reuse
open-source systems and components (Chapter 7) as this means you can access and keep copies
of the source code.
3. The background, skills and experience of the development team All reuse technologies are
fairly complex, and you need quite a lot of time to understand and use them effectively.
Therefore, you should focus your reuse effort in areas where your development team has
expertise.
4. The criticality of the software and its non-functional requirements For a critical system
that has to be certified by an external regulator you may have to create a safety or security case
for the system . This is difficult if you don’t have access to the source code of the software. If
your software has stringent performance requirements, it may be impossible to use strategies
such as model-driven engineering . MDE relies on generating code from a reusable
domain-specific model of a system. However, the code generators used in MDE often generate
relatively inefficient code.
6. The platform on which the system will run Some components models, such as .NET, are
specific to Microsoft platforms. Similarly, generic application systems may be platform-specific,
and you may only be able to reuse these if your system is designed for the same platform.
Approaches of reuses