Emerging Software Engineering: Hapter

Chapter
12
Emerging Software Engineering

As we discussed in Chapter 1, the trends of software engineering approaches
have been changing since the inception of software development in 1950. With
the increasing demand of software systems, software engineering processes will
evolve significantly over the next decades. Between now and 2025, the ability of
organizations and their products, systems, and services to compete, adapt, and
survive will depend increasingly on software.1 Software provides competitive
differentiation as well as rapid adaptability to competitive changes. The delivered
software-intensive systems face ever-increasing demands to provide safe, secure,
and reliable systems; to provide competitive discriminators in the marketplace;
to support the coordination of multicultural global enterprises; to enable rapid
adaptation to change; and to help people cope with complex masses of data
and information. These demands will cause major differences in the processes
currently used to analyze, design, develop, deploy, and evolve a diverse variety of
software-intensive systems.
There have been several software engineering processes developed. Each of these
has its own development approach. In this chapter, we will discuss the following
emerging software engineering disciplines that provide the required quality software products:

Software reuse
Aspect-oriented software engineering
Service-oriented software engineering
Usability engineering
Model-driven software engineering
Client-server software engineering
Computer-aided software engineering (CASE)
12.1 SOFTWARE REUSE

We have studied in Chapter 1 the software problems that software practitioners face
in software development. The development of faster (in a small cycle time), better
(a good quality product), and cheaper (with small budget) software is a significant
challenge for the software industry. A possible way to produce software products
M12_SE_01_M12.indd 429
6/28/2013 11:21:14 AM
430 Software Engineering: Concepts and Practices
in this way is development with software reuse. Software reuse is an efficient way
of implementing or updating software systems with existing software components.
Software reuse is the process of producing software systems from existing software
systems rather than building software from scratch. Reuse-based software engineering allows producing reusable components only once and saves development
effort multiple times.2
Software reuse has a great impact on achieving high productivity and quality.
Also, if the requirements change, the required component can be added and software
can be modified. Reuse-based development using components/modules improves
the maintainability of software. The production of reusable components requires
more effort and resources than the development of components customized for
one project.3 Reuse requires an extensive upfront planning effort to identify and
avail reusable components. Also, it requires extra time for writing, managing, and
retrieving reusable components, thereby reducing the benefits from writing nonreusable components. Although the benefits of systematic reuse can be high, most
organizations lack success in implementing and getting reuse potential.
Software reuse provides a means for reducing the efforts of developing an application software system. Software reuse is a viable idea but it is not free from an
economic perspective. Reusability is the degree to which a reuse entity can be
reused. It has two major aspects, namely, usability and usefulness. Usability is the
degree to which an asset is easy to use in the sense of the amount of effort that
is needed to use an asset. It involves comprehensibility, compliance with standards, ease of development, etc. Usefulness is the frequency of suitability for use.
It depends on functionality, generality, and quality of the component. Software
reuse can occur at many levels, ranging from the reuse of small functions within an
application system to the reuse of large software across many application systems.
Reuse measures the predictability of time to market a product.
12.1.1 Reusable Components

Reusable components are self-contained entities which may be any software
document or work product generated during the software development process.4
Components can be independent executable units but these are connected via
interfaces for the purpose of reuse. A component can be any well engineered and
documented software life cycle object or software part. An artifact is the result of
software development activity; it can be a document or a software product. A software asset is a collection of interrelated software artifacts/components. It refers to
high-quality software work products as well as documents, tools, processes, and
compiled knowledge that can be reused by the business. A component can be made
reusable by measuring the adaptability, extendibility, and concurrency features of
reusable components.
Reusable components have been illustrated and identified in various ways by
researchers and a summary of their investigations is presented here. The reusable
components are as follows:
M12_SE_01_M12.indd 430
6/28/2013 11:21:14 AM
431
Requirements analysis document (software requirements, subsystems)

Design models (architectural design, component-level design, user interface
design, database design)
Software architectures (frameworks, component interface, interconnection
between components, platform configuration)
Programs (classes, functions, exceptions, packages, constants, garbage collection,
routines)
Design patterns
Data
Documentation
Test cases and test plans, expertise
Experienced practices (life cycle model reuse, quality assurance, application
area knowledge, solutions)
Algorithms
Information products (texts, graphics, hypermedia)
Data models
Domain descriptions
Semantics, proofs, and logic
There are three aspects of reusable components: concept, content, and context.5
Concept corresponds to the abstract functionality of a component, such as a formal
algorithm specification, an abstract data type, etc. Content is the implementation
of a component, which involves the selection of a programming language and a
design. The transition from concept to content involves moving from the problem
domain to solution domain. Context is the environment needed to use the components. Context for code components might be the required machine, operating
system, compiler version, and so on.
There are several technologies that provide reuse services for development with
reuse. Some of these are COM/DCOM, EJB, CORBA, and Active-X. Componentand framework-based middleware technologies such as CORBA, J2EE, and .NET
have become mainstream for reuse-based development. Object-oriented design
techniques such as UML and patterns and OO programming languages such as
C++, Java, and C# are helpful in software development with reuse and produce
reusable codes.
12.1.2Types of Reuse
These days there is a rapid growth of reuse-related products and services, such as
components, consulting, and library tools that support the design and construction
of reusable software. The success of reuse depends on the types of reuse strategies
implemented in the organization. There are several types of reuse strategies listed
in Table 12.1 from various literatures, with their advantages and disadvantages.6,7
Various types of reuse can be classified with respect to proper management of reuse
mechanism, domain scope, modification of reusable components, development
scope, technical approaches of reuse, and frequently reused entities.
M12_SE_01_M12.indd 431
6/28/2013 11:21:14 AM

Table 12.1 Types of reuse
Reuse
management
Domain
scope
Modifications
Development
scope
Reuse
approach
Reused
entity
Ad hoc
(informal)
Vertical
White box
Internal
(private)
Layered
Source
code
Systematic
(formal)
Horizontal
Black box
(verbatim)
External
(public)
Tailored
Abstract
level
Generative
Instance
level
In-the-small
Customization
reuse
In-the-large
Generic
Adaptive
(porting)
Carried over
Reuse management refers to the degree to which reuse is performed systematically.

Ad hoc (informal) and systematic (formal) reuse are the main reuse management
strategies. In the ad-hoc strategy, reuse is not a part of a repeatable mandated
organizational process. Ad-hoc reuse is the programmer-derived informal reuse,
usually ill-documented code used by particular programmers from their own
libraries. Systematic reuse is a process-driven activity that requires common standards, procedures, and practices applied consistently across a given domain. All
the reusable components are well documented with features that allow unfamiliar
developers to search and integrate the reusable components effectively.
Domain scope refers to the occurrence of reuse within a family of systems or
between a family of systems. It covers horizontal and vertical reuse strategies.
Horizontal reuse involves those software components that are used for a wide variety
of applications such as email packages; word processing program; huge library of
component such as stack class, GUI functions, character handling functions, etc.
On the other hand, vertical reuse refers to the functional areas or domains which
may be utilized by a family of systems with similar functionality. Vertical reuse is
helpful to produce more efficient products than horizontal reuse. Vertical reuse can
be achieved by domain engineering. Domain engineering is an iterative life cycle
process that an organization uses to pursue the business objectives. It increases the
productivity of application engineering projects through the standardization of
a product family and an associated production process.
Reuse modification dictates the amounts reusable components are changed
within the reuse repository of system development. In this class of reuse, there are
three modes of reuse: black-box, white-box, and adaptive reuse. Black-box reuse is
the reuse of reusable components without any modification such as standardization,
wrapping techniques, etc. White box is the reuse of components by modification and
adaptation such as copy and paste, inheritance, etc. Black-box reuse hides its implementation from its clients whereas implementation of the white-box reuse is visible
M12_SE_01_M12.indd 432
6/28/2013 11:21:14 AM
433
and can be modified by clients. Black-box reuse is preferable over white-box reuse.
Adaptive reuse strategy uses large software structures as invariants and restricts
variability to low-level, isolated locations. Changing arguments to parameterized
modules is an example of adaptive reuse.
Development scope means that reusable components are available either
from a source external or internal to a project. It involves external reuse level and
internal reuse level to identify the development scope of reusable components.
Internal reuse level (also known as private reuse) is the ratio between the number
of lower-level items (not from an external repository) and the total number of
lower-level items (not from an external repository). For example, out of 50 reusable components, there may be a possibility of reusing 30 components from ones
own (i.e., internal) reuse library and remaining from other sources. Here, private
refers to the extent to which modules within a product are reused within the same
product. External reuse level (also known as public reuse) is the ratio between
the number of lower-level items from an external repository in a higher-level item
and the total number of lower-level items in the higher-level item. For example, out
of 50 reusable components for the development of software, there may be a possibility of reusing 30 components from the external reuse repository and 20 from
the in-house reuse repository. In external reuse, the development team considers
theuse of licensed third party reusable components.
Reuse approach refers to different technical methods for implementing reuse.
Layered reuse is used to describe the case where reusable functions or operations
are viewed as abstract primitives. These primitives may be used by the client; for
example, network layered software, runtime kernel, mathematical packages, string
handling utilities, etc. In tailored reuse approach, the configuration of reusable
components is required to interoperate properly with the client software; for
example, the generic data structures that allow the client software to create stack,
queue, lists, etc. Other examples of tailored reuse are database management systems,
spreadsheets, statistical packages, and expert systems. Generative reuse occurs
when the reusable components are used as a generator program rather than being
incorporated directly into the final application system; for example, compilers, test
case generators, fourth generation languages, parser generators, etc. Reuse in-thelarge is the use of large, self-contained packages such as spreadsheets and operating
systems. Reuse in-the-small is the reuse of components which are dependent upon
the environment of the application for full functionality. Carryover reuse occurs
when one version of a software component is considered to be used as is in a subsequent version of the same system.
Reused entity is the type of reused objects used for application development.
Source code reuse is the low-level modification of an existing source to change
its performance characteristics. Abstract reuse is the use of high-level abstractions
within an object-oriented inheritance structure as the foundation for new ideas or
additional classification schemes. Instance-level reuse is the most common form
of reuse that can be defined as simply creating an instance of an existing class.
Customization reuse is the use of object-oriented inheritance to support incremental development. A new application system may inherit information from
M12_SE_01_M12.indd 433
6/28/2013 11:21:14 AM
an existing class, overriding certain methods and adding new behaviors. Generic
reuse is reuse of generic packages such as templates for packages or subprograms.
12.1.3 Software Development with Reuse

Software development with reuse is executed by reusing the already developed
components. Software development with reuse is shown in Figure 12.1. It involves
domain engineering, reuse repository, component searching and retrieval, refinement and integration, and reuse measurement. In the subsequent paragraphs,
wewill discuss these aspects of reuse-based development.
Reuse repository
Domain
engineering
Product
requirements
Searching
Retrieval
Integration with
development
Reuse
measurement
New software
Figure 12.1 Software development with reuse
Domain Engineering
Domain engineering identifies reusable artifacts and operations in a set of related
systems having similar functionalities in specific functional areas, along with the
roles and responsibilities. It provides domain vocabularies, domain models, possibly
reusable components, and classification schemes. A reuse domain is basically a set
of application areas. The content of application domain and the required component of the software product can be characterized by patterns of similarity between
components. The reusable components under domain analysis can be identified by
the domain concepts, techniques, technologies, terminologies, and by reviewing
among peers.
For example, reuse domain can be a business software domain, accounting software domain, banking software domain, telecommunication domain, and system
software domain. From all these domains, developers can design reusable components. Identified reusable components can be classified according to the application
domain. The classified reusable components are stored systematically into physical
devices for faster retrieval to integrate them with the system under development.
The systematic organization of reusable components within the reuse repository
system can reflect in the development activity. Reusable components need to be
M12_SE_01_M12.indd 434
6/28/2013 11:21:14 AM
435
systematically classified in order to achieve efficient storage scheme and quick

retrieval. The effectiveness of component reuse depends on the coupling amongst
reusable components and their binding to specific application domain. A classified
collection is not useful if it does not provide the search and retrieval mechanisms.
There have been several reuse classification and retrieval approaches designed
depending upon the developers requirements, available technologies, and reuse
software systems.
Reuse Repository
A software repository contains a large number of reusable components over a wide
range of application domains for software reuse. A reuse repository system is a
kind of software library where reusable components are managed systematically
for easy access for future development. It becomes necessary to set up and maintain
this repository for the success of reuse. If it is designed systematically, the efforts of
developers to produce an effective and quality product will be reduced.
Designing a repository of reusable artifacts can provide availability of sufficient
knowledge for developers. The efficiency of a repository is mainly based on the
organization of reusable components. The connectivity among reusable components
and their retrieval for reuse depends on the effectiveness of repository. Reusable
components can be either extracted from the existing software through reengineering or produced during development of new software from scratch.
There exist several reuse repositories that heavily rely on data structures, such
as link lists, indexing, prototyping, etc. The classification and retrieval mechanisms in these repositories depend on the developers requirements, available
technologies, and reuse software systems. One of the simplest forms of repository
is software libraries. Many software libraries (e.g., C++, Java, Ada, etc.) provide
reusable components. Another reuse repository system consists of three components, namely, identification and classification of reusable components, reuse
repository, and information retrieval.8
The identification and classification component is responsible for the generation
of reusable components using domain analysis, classification of reusable components, and defining interfaces. Reuse repository is the main component that
describes the storage mechanism of reusable components. Identified components
can be stored in the reuse repository for further reuse. The information retrieval
component consists of three activities, namely, reuse requirements, searching and
retrieval, and refinement and integration.
Component Searching and Retrieval
The searching process allows developers to put queries in natural languages,
including keywords. The searching and matching of reusable artifacts according
to the application domain make the retrieval process faster. The simple keywordand semantic-based retrieval approach is used, in which experts extract keywords
by facets into a classification scheme. A major part of this approach is signature
matching. Signature matching is the process of checking the compatibility of two
M12_SE_01_M12.indd 435
6/28/2013 11:21:14 AM
components in terms of their signatures. It defines the interface of components.

Signatures may include the component name, number and order of arguments, type
of arguments, return types, etc. Different components can have different signatures.
Retrieval of reusable components from reuse repository goes through the
searching and signature matching process. There are various approaches to
component storage and retrieval. The most popular are the simple keyword and
string match, faceted classification and retrieval, signature matching, and behavior
matching.
Refinement and Integration
Component retrieval from reuse repository is not enough for development with
reuse. Instead, developers emphasize finding the relevance and applicability of the
delivered components with the working context of software development. Also,
reusable components stored in the repository can be either concrete or abstract.
In the case of concrete components, developers find all other components that the
concrete components depend on and create relationships among them. Abstract
components are difficult to accommodate with the working context of the application.
Abstract components provide some common features or responsibilities that all
reusers need. Also, abstract components are generic or incomplete in some way and
must be refined before integrating them with development with reuse.
Refinement of reusable components deals with the relevance and applicability of the retrieved components with the working context. Refinement of
the retrieved components is needed for specialization, restriction, extension,
optimization, implementation, and convenience. Abstract components can be
refined with development with reuse using a wide range of generalization and
specialization techniques. For example, parameterization, configuration and
module interconnection language, extension points, uses, inheritance, generators,
etc., can be utilized for integration of components. The selection of right kind
of mechanism for each component helps to build a small and coherent set of
appropriately generic components. These components can then be integrated in
a variety of ways to produce the desired application systems quickly and efficiently. The integration of reusable components highly reflects from the type of
interfaces and their signatures.
Reuse Measurement
Reuse metrics measure the performance of reusable things and identify highly
reusable components and the specific business area for providing greater benefits
to the organization. Reuse metric is a quantitative measurement of an attribute of
a reusable component. Reusable components that need to be measured can be
architectural, such as stability and extendibility, component level, and application
system. Component-level measures include component size, component quality,
cost of customizing components, difficulties in integrating components, component
complexity, and cohesion. Application system measures involve reuse level, quality,
defect level and causes, cost, and losses of changing application system, etc. There
M12_SE_01_M12.indd 436
6/28/2013 11:21:14 AM
437
are various types of reuse metrics: cost-benefit analysis, maturity assessment,

amount of reuse, failure modes analysis, reusability assessment, and reuse library
metric. It is also reported that reuse can be measured in terms of reuse level and
size, cost-benefit analysis, and reuse investment analysis.
The amount of reuse is the quantity of reuse in a given product in terms of size.
Size is some measure of the amount of text or function within a work product.
Let a software system S consist of components C1, C2 Cn. Size of a system S can
be described as a function Size(S) with the following properties:
1. Size cannot be negative.
2. Size is expected to be zero when a system does not contain any component.
3. When components do not have elements in common, size will be additive.9
Thus, the size of a system is given as:
Size(S) = C + C + + Cn.
Size(S) = Size(C); where C is a component of S.
The amount of reuse of a reusable component existing in the reuse repository
can fall in three categories, namely, component without modification, extensively
modified component, and slightly modified reusable component. The reuse of a
component C without modifying in a system S can be given as:
Reuse(C) = Size(C)
The reuse of a component with modification can be given as:
Reuse(C) = (1 - %Change) Size(C).
Where %Change represents the percentage of C added or modified from the
existing component. The percentage of change of a component C can be computed
as follows: if component C is modified more than 25%, then Reuse(C) = 0 and if the
component is modified less than 25%, then Reuse(C) = Size(C). If the component C
is either completely written or modified, then reuse can be given as:
Reuse(C) = 0
Hence, the reuse of a system is the sum of reuse of individual components. The
amount of reuse of a system S can be presented in terms of reuse level or reuse rate,
Rs. Thus, reuse rate is defined as the ratio of the size of work products designed
from reusable components to the size of the system. Therefore,
Reuse rate = R = Reused software/Total software
Reuse(S) = Reuse(C); where C is a reusable component of S
Reuse level = Reuse(S /Size(S))
Reuse rate is used to monitor the reuse and to estimate the cost, time, quality, and
productivity. The total cost saving of reusable asset can be deduced by weighing the
costs and benefits of the producer as well as the costs and benefits of the consumer.
Thus, the cost of software can be measured as:
M12_SE_01_M12.indd 437
6/28/2013 11:21:14 AM
Total cost of system development with reuse (CS)

= Cost of reused software + Cost of software without reuse
= (Relative cost of reuse software reused software)
+ (Relative cost of software without reuse software without reuse)
Total cost saving for system development with reuse
= Cost of system development without reuse
- Cost of system development with reuse
12.1.4 Reuse Benefits and Reuse Barriers

Adopting reuse-based software development process attracts a number of wellrecognized economic and psychological benefits to both end users and developers.10,11
These include the following.
Savings in development costs and time In reuse-based development, the developer uses already tested and predefined components. Therefore, the development
and latter set of activities take less time and therefore cost less.
Improvement in productivity of the organization Reusable artifacts are viewed
as high-level language abstract concepts in a problem domain. The developer is
given an opportunity to work with more abstract notions related directly to the
problem at hand and to ignore low-level implementation details. In this way,
development productivity is increased.
Increase in reliability As the reusable components managed in reuse library are
well tested, this leads to an improved reliability of systems built of reusable components rather than of those built entirely from scratch.
Increase in quality Reuse-based products are built from replaceable components
and these are tested and certified. The quality of such products is higher than the
products developed from scratch.
Increase in the ease of maintenance Software systems constructed of reusable
parts are usually simpler, smaller, and more abstract. Reusable components have
loose coupling and these can be replaced with other reliable components. Their
design is closer to the problem domain and reliability is greater. Therefore, maintaining
a component of software has less effect on other components of software and it also
eases the maintenance task.
Improvement in documentation and testing Reusable components are normally
accompanied by high-quality documentation and by previously-developed tests
plans and cases. New software development uses these reusable components and
thus their documentation and tests will have to be much easier to develop as well.
High-speed and low-cost replacement of aging systems As reuse-based systems
are developed using reusable components, they are significantly less complex
and much smaller in size than those developed from scratch. Such systems will
M12_SE_01_M12.indd 438
6/28/2013 11:21:14 AM
439
therefore need less effort during porting or adaptation to new hardware and software
environments.
Improvement in the predictability of the process The analyst, along with
domain experts, decides early the availability of reusable components. Inclusion of
reusable components helps in predicting the outcomes of software processes.
In spite of the above advantages of the reuse-based development, there are
certain drawbacks of its implementation. Some of the claims are as follows:
It takes too much effort and time to introduce reuse in an organization.
Reuse of components may lead to legal responsibility in case of software
failure.
Management is not trained in software development methods with reuse.
Risks of wrong component selection
Worry about ongoing support
Tradeoffs require adapting certain components.
Worries about component quality
Uncertain internal costing to compare costs
Availability of quality, high-value components
12.1.5 Success and Failure Factors of Reuse

Reuse requires a shift in the software development paradigm. This affects the entire
IT organization. Although, the benefits of systematic software reuse can be high,
most of the organization lacks success in implementing and achieving the reuse
potential. The success of reuse involves management-related as well as technical
factors. Some of the most frequent pitfalls and obstacles occurring while trying to
achieve reuse benefits are as follows.
Managerial and organizational Sometimes the management is unable to
introduce reuse which adds to the business due to lack of money for the upfront
costs, for human resources, and for developing belief in the value. Producing
reusable asset for multiple uses requires more effort than producing software for
a single use. Reuse developers hesitate in producing reusable assets because they
are time consuming and are used by others also. Hence, some incentives need to
be set up that reward creating reusable software. A reuse program changes the
organizational work. Therefore, reuse scope must be broader with good business
cases for implementing reuse.
Economical Reuse benefits can only be obtained after initial costs for training,
infrastructure, etc, are borne. Different taxation, charge back, and accounting
schemes are needed to compensate the extra effort for reuse startup. Upfront
investment includes organizational, technical, and process change; support tools;
training staff for new tools and change.
Technical It is difficult to design, maintain, and identify appropriate assets for a
given problem. Therefore, an effective reuse repository system is needed to store
M12_SE_01_M12.indd 439
6/28/2013 11:21:14 AM
and retrieve suitable assets. In spite of this, there are two basic approaches to
reuse: parts-based reuse and generative reuse. The part-based approach assumes a
software engineer integrating software components into an application. The generative approach considers that domain knowledge is encoded into an application
generator or a programming language so that components can be selected and
integrated automatically.
Psychological Adaptation of new methods and techniques for reuse development may introduce risks. The organization and people involved in reuse need to
build confidence to reuse assets and their quality produced by other developers.
Political The people involved in the reuse program have benefits and powers
over some architectural decisions and authorization. This may lead to provide
advantage to some people and disadvantage to others.
Legal An organization requiring to reuse components to which other entities
have proprietary rights, copyrights, and legal claims will face legal constraints.
Some authentication is required to reuse third-party components. Authentication
avoids any illegal access of the reuse repository by unauthorized people. Also,
reusers of the asset take on the risk of the cost incurred from failure of the reusable
component.
Despite these obstacles, people should concentrate on the following critical
reuse success factors. These conditions assist in determining the reuse potential in
a given context.
Focus on domain analysis and adopt a product line approach The software
must address a domain through domain analysis and adopt a product line approach
that has considerable commonality. This helps to determine the right product line
for the organization and develop domain-specific software.
Focus on achieving black-box reuse White-box reuse incurs a cost in each
modification. Therefore, black-box reuse of components, in which components are
used through specifying parameters, reduces the effort.
Establish reuse-oriented development process and organization Create processes
that support reuse. It is required to have reuse asset certification, reuse repository
management, version and configuration control, and adaptation of reuse.
Adopt reuse in an incremental manner Introduce reuse in an incremental
manner rather than all at one time so that the resources can be managed and
changes can be controlled easily.
Produce large volume of software The majority of reusable components enhance
reuse activity and help to catch the market opportunities. However, the quality of
reusable asset should be kept in consideration.
Certify reuse components to build trust and ensure quality The reuse organization should establish a set of standards, including inspection and metrics for
M12_SE_01_M12.indd 440
6/28/2013 11:21:14 AM
441
components certification. Publication of success stories, education, and good

experiences motivate people to reuse components designed by others.
Plan reuse program over a long period of time It helps to bear the cost of new
procedures for reuse. For this, management planning and additional resources are
required.
Organize training for staff It is important to make the staff familiar with the
available reusable assets and to demonstrate procedure to reuse them. Reuse engineers
need to learn new skills to develop and test components. Therefore, training is
provided to reuse engineers so that a common terminology related to reuse could
be developed among developers. Also, it allows clear communication and unambiguous measurements among developers while reusing components.
Create incentives for individuals/engineers for doing reuse Some explicit financial or job incentives need to be created and revised regularly for reuse managers
and engineers to keep motivation for change as the reuse business grows. Such kinds
of rewards improve cooperation, trust, and creativity among individuals.
Develop reuse experience Developers must have the knowledge of recognizing
and understanding the reuse patterns and reuse models of a company. Also, they
must have the knowledge of the availability of various components.
Keep track of technological development to avoid obsolescence It is important
that the architecture and the asset in the reuse program are evolved with technological development.
Use reuse metrics in order to manage reuse program It is required to keep track
of progress of the reuse program in order to perform according to the business
objectives. There are various matrices collected to measure the progress of participants
in the reuse program.
12.2 ASPECT-ORIENTED SOFTWARE ENGINEERING

As we saw earlier, there are various programming approaches for developing
good-quality software products. The procedural approach has been widely used
to develop software but the representation of real world entities and complexity
management in software development were the major limitations. Object-oriented
approach was successful in modeling and implementing complex software systems
but it still has its own limitations of separation. Aspect-oriented approach is a new
paradigm which supports separation of concerns in software development. That
is, it entails partitioning a program into distinct parts called concerns, a cohesive
area of functionality. It provides unique and advanced techniques of structuring
and modularization of programs. Aspect-oriented software development (AOSD)
techniques result in better implementation and have positive impact on many
quality attributes such as reusability and complexity.
M12_SE_01_M12.indd 441
6/28/2013 11:21:14 AM
It is observed that some concerns at the early life cycle phases cannot be mapped
to single modular units but tend to crosscut over multiple modules. The crosscutting concerns cut across multiple abstractions in a program. Aspects at the early
life cycle phases have been termed as early aspects so as to distinguish them from
aspects at the code level. For example, modules could be requirements, use cases,
architectural components, interaction diagrams, etc. Aspects should be identified
early in the software development life cycle, i.e., during the requirements analysis,
domain analysis, and architecture design phases.
Crosscutting concerns are aspects of a program which affect (crosscut) other
concerns.12 These concerns often cannot be clearly distinguished from the rest of
the system, both for design and implementation. This results in either scattering/
tangling of the program or both. For instance, writing an application for handling
medical records, bookkeeping, and indexing of such records is a core concern
while logging a history of changes to the record database or user database or an
authentication system would be crosscutting concerns since they exist in most
parts of the program. Core concern is related to the core or central functionality of
a problem. Crosscut concerns are related to additional information which is associated with the core concern.
12.2.1 Components of Aspect Orientation

AOSD is a software development methodology that primarily focuses on identifying
crosscutting concerns known as aspect. Aspect is then modularized and integrated
with other modules throughout the development life cycle. The components of
aspect orientation are discussed in the following paragraphs.
Join Points
In aspect-oriented programming language, aspects are invoked only at well-defined
points in program execution. These points are referred to as join points. A join
point is considered to be a location in a code where concern crosscuts to represent
aspect. Assignment statements, method or constructor call, variable references,
static and dynamic initializations are a few examples of join points. There are two
types of join points, namely, static join points and dynamic join points. A static join
point is a location in the structure of a component program whereas a dynamic
join point is a location in the execution of a component program.
Join point model is a representation of a conceptual framework which describes
the different types of join points and associated restriction on their use. It also
defines the interaction points between aspects and base modules. It is observed that
UML extension has been used to represent join points and is not satisfactory due to
some limitations. Join points can be represented using pointcuts.13
Pointcut
Pointcut is a way to specify join points. It identifies specific events with which
advice should be associated. In other words, it is a statement that defines join points
where the associated aspect advice should be executed.
M12_SE_01_M12.indd 442
6/28/2013 11:21:15 AM
443
Advice
The method which executes conditionally on happening of an event is called
advice. Advice declaration is used to define the aspect code that runs at join points.
Advice consists of pointcut declaration and a body which gets executed whenever the pointcut matches. The different types of advices are around advice, before
advice, and after advice. These are defined as follows.
Around advice When advice code is run at a join point and it can check the
conditions to control the selection of advice code, it is known as around advice.
Before advice When advice code is run before the method starts running, it is
known as before advice.
After advice When advice code is run at the moment method returns the control,
it is known as after advice.
Introduction
An introduction is a member of a type (class), but it defines or modifies a member
of another type (class). Introduction is a static crosscutting instruction that introduces changes to the classes, interfaces, and aspects of the system. It adds fields
and methods to an existing class, extends an existing class with another, and implements an interface in an existing class.
Weavers
Weavers are a specific kind of compilers used for aspect languages. Many of the
aspect languages are simply the extension of OO languages. Weavers primary task
is to transfer the aspect language program into OO program where the aspect
code is inserted into the OO implementation modules.
Aspect
An aspect is similar to a class by having a type; it can extend classes and other
aspects. An aspect can be abstract or concrete and have fields, methods, and types as
members. It is a modular unit designed to implement a concern. Aspects are
modular units of crosscutting implementation. Aspects define precisely how
behavioral and structural crosscutting has to take place by means of pointcuts
(specifying fix points for behavioral crosscutting), advice (specifying code for
behavioral crosscutting), and introductions (specifying code for structural crosscutting). Furthermore, an ordinary Java member with no crosscutting effects
may be declared, for example, to specify aspect-specific helper methods or to
accommodate aspect-specific state information. Aspects may be specialized by
inheritance. Just like standard UML classes, sub-aspects inherit all features from
their super-aspects; they may override only ordinary Java operations and abstract
pointcuts, though.
AspectJ is an aspect-oriented programming language. AspectJ extends Java
with support for two kinds of crosscutting implementation. It has two additional
M12_SE_01_M12.indd 443
6/28/2013 11:21:15 AM
features. The first makes it possible to define additional implementation to run at

certain well-defined points in the execution of the program. The second makes it
possible to define new operations on existing types. Aspects are units of modular
crosscutting implementation, composed of pointcuts, advice, and ordinary Java
member declarations.
12.2.2 AOSD Process

AOSD has originated from the concept of aspect-oriented programming. It has
been found that aspect-oriented ideas are technologically very rich but lack in
development process standardization. There are many AOSD techniques and
technologies used throughout the software development life cycle.14 The activities
of AOSD process are as follows.
Aspect-oriented requirements engineering (AORE) It is an early phase of
AOSD process which handles the tangled representation of the crosscutting
concerns at the requirement level. The techniques of AORE are used to identify
and specify the crosscutting concerns at the requirement determination level of the
development life cycle. Non-aspect-oriented requirement approaches deal only
with one type of concerns. Other approaches work on the required functionality of
the system. Aspect-oriented approaches consider that all the concerns are equally
important and should be treated consistently. It has also been found that all kinds
of requirements possess crosscutting influence on other requirements.
Aspect-oriented architecture (AOA) The architecture of a program or computing
system is the structure of the system comprised of software components, the externally visible properties of the components, and relation among them. In AOA,
design approaches focus on localization and specification of crosscutting concerns
in architectural design.
Aspect-oriented design (AOD) It focuses on the representation of crosscutting
concerns through design languages. It provides the means for modularization and
composing concern at the later stage of life cycle. It also helps in resolving conflicts
between concerns and specifies cooperation of concerns. One major contribution
of AOD is to provide traceability of concerns to life cycle stages, both pre-design
and post-design.
Aspect-oriented programming (AOP) It is a set of programming techniques and
tools used to represent aspects, to express pointcut, and to implement advice at the
source code level. Most of the languages used in AOP are the extension of OO
languages, which together encapsulate the AO concepts. Aspect-oriented programs
are developed using AspectJ, AspectC#, AspectC++, PHPaspect, etc. AspectJ
is identified as the most prominent and mature aspect-oriented programming
language.
Verification of aspect-oriented programs Though AO techniques are used to
modularize crosscutting concerns, concerns can be dependent on each other.
M12_SE_01_M12.indd 444
6/28/2013 11:21:15 AM
445
Further, an aspect can be dependent on other aspects. To ensure that aspects

actually add the intended crosscutting properties to the system, validation and
verification techniques are needed in AOP.
UML is a graphical language available to specify, visualize, construct, and
document the artifacts of software systems. Since object-oriented approach is
contained in aspect-oriented approach, UML, defined as standard modeling
language for object-oriented approach, is also being extended for aspect-oriented
approach. If aspects are defined at an early stage of development life cycle, their
design components can be made more reusable and automatic code generation can
be made possible for aspect-oriented programming systems.
12.2.3 AOP Benefits and Limitations

AOP is helpful to separate concerns to overcome the problems with crosscutting
concerns. The benefits of AOP are the same benefits that come out of the ability to
modularize implementations of crosscutting concerns. AOP also overcomes the
problems caused by code tangling and code scattering. AOP addresses each concern
separately with minimal coupling, which results in a modularized implementation
if there is the presence of other crosscutting concerns. There is little chance of code
duplication. Modularized implementation of a system is easier to understand and
maintain. Functionality can be added by creating new aspects. Modularized implementation of crosscutting concern also makes code more encapsulated and hence
it supports software reuse.
In spite of the above advantages, there are certain limitations of AOP. AOP is a
new technology; it is not well tested and documented. There is a limited amount
of developing tools for AOP today. AspectJ is a leading AOP implementation,
and there are others, but all in early versions. This makes it hard to estimate risks
using AOP.
12.3 SERVICE-ORIENTED SOFTWARE ENGINEERING

The software market has grown rapidly in the last two decades, especially in
web applications. As more software companies and organizations enter the web
application market, the number of web-based capabilities and services available
to software developers are rapidly increasing on the Internet. This phenomenon
influences the software development process. Instead of building software from
scratch, developers are encouraged to assemble new applications from openly
available services provided by third parties.
Service-oriented software engineering (SOSE) deals with theories, principles,
methods, and tools for building enterprise-scale solutions as the collaboration of
loosely-coupled application services that provide particular business functionality
are distributed within and across organizational boundaries.15 SOSE is a software
engineering paradigm that aims to support development of rapid, low-cost, and
easy composition of distributed applications, even in heterogeneous environments.
M12_SE_01_M12.indd 445
6/28/2013 11:21:15 AM
In SOSE, services are the basic elements for developing applications and software
solutions. The software in this paradigm is presented as a web service known by
the term SaaS (Software as a Service). A web service is a software component
available on the Internet with web interfaces, which is accessed remotely using
Internet protocols and infrastructure.
SOSE is based on service-oriented computing, but it is also evolved to include
cloud computing. In SOSE, a service-oriented architecture (SOA) provides the
architectural style, standard protocols, and interfaces required for application
development whereas cloud computing delivers the needed services to users. SOSE
focuses on the development of software systems by composition of reusable services
provided by other service providers. Since it involves composition, it shares many
features of component-based software engineering, the composition of software
systems from reusable components, but it adds the ability to dynamically locate
necessary services at runtime. These services may be provided by others as web
services, but the essential element is the dynamic nature of the connection between
the service users and the service providers. SOSE utilizes services as fundamental
elements for developing applications and solutions. Important areas of research
within SOSE include service foundations, service composition, service management
and monitoring, and service-oriented engineering.
12.3.1 Service-Oriented Architectures

In software engineering, a service-oriented architecture (SOA) is a set of principles
and methodologies for designing and developing software in terms of interoperable services. These services are well-defined business functionalities that are
built as software components that can be reused for different purposes. SOA
isa way through which a software system can be designed by providing services
to applications or other services through published and discoverable interfaces.
SOA design principles are used during the phases of systems development and
integration. Web services are probably the most visible way of achieving SOA.
SOA gives an approach in which a software component provides its functionality
as a service that can be used by other software components. Components (or
services) represent reusable software building blocks. SOA also allows the integration of existing systems, applications, and users into a flexible architecture that
can easily accommodate changing needs. Integrated design, reuse of existing IT
investments, and, above all, industry standards are the elements needed to create
a robust SOA.
SOA is comprised of a set of components as services that can be invoked
and whose interface descriptions are published and discovered. Service is a unit
of solution logic specially designed to attain interoperability, federation, agility,
loose coupling, and other strategic goals of service-oriented computing (SOC).
Itis a self-contained, stateless business function that accepts multiple requests and
returns multiple responses through a well-defined standard interface. A serviceoriented architecture is shown in Figure 12.2.
M12_SE_01_M12.indd 446
6/28/2013 11:21:15 AM
447
UDDI
Service
registry
Publish
(WSDL, XSD)
Search
Service
consumer
Bind
Service
provider
Figure 12.2 Service-oriented architecture
There are three main entities in SOA architecture, namely, a service provider,
a service requester, and a service registry.16 The service provider defines service
descriptions of a collection of services, supplies services with functionalities, and
publishes the descriptions of the services for discovery. The service registry contains
service descriptions and references to service providers and provides mechanisms
for service publishing and discovery, for example, Universal Description Discovery
and Integration (UDDI). The service requester is a client that calls a service provider
which can be an end-user application or other services. A service requester searches
a specific service in the service registry via the service interface description. When
the service interfaces match with the criteria of the service requester, the service
requester will use the service description and make a dynamic binding with the
service provider, invoke the service, and interact directly with the service.
In SOA, services are usually implemented as web services (WS) and delivered
using technologies such as Extensible Markup Language (XML), Web Services
Description Language (WSDL), Simple Object Access Protocol (SOAP), Universal
Description Discovery and Integration (UDDI), and Business Process Execution
Language (BPEL).17 XML is fundamental to web services. It provides a way to
describe information. WSDL is used to describe WS interfaces which define operations and then binds them to one or more protocols. SOAP defines an envelope
and rules for representing information sent in that envelope. SOAP messages
are commonly conveyed using HTTP. UDDI stores registrations describing web
services and provides unique names for elements in the registrations. BPEL is the
standard for assembling a set of discrete services into an end-to-end process flow,
radically reducing the cost and complexity of process integration initiatives.
12.3.2 Principles of Services in SOSE

SOSE requires services to be designed with respect to service-oriented principles
since these principles provide guidance during service-derivation process and
assurance that the resulting services provide the feature of the corresponding
service. That is, the identification and development of services in compliance with
service-oriented principles is crucial to ensure services reusability and flexibility.
Following are some of the principles of SOA.18
M12_SE_01_M12.indd 447
6/28/2013 11:21:15 AM
Loose coupling Service-oriented architecture promotes loose coupling between

service consumers and service providers. Coupling is increased when service
consumers require a large amount of information about the service provider to
use the service. SOA accomplishes loose coupling through the use of contracts and
bindings. A consumer asks a third-party registry for information about the type of
service it wishes to use. The registry returns all the services available that match
the consumers criteria. The consumer chooses which service to use, binds to it over
a transport, and executes the method on it, based on the description of the service
provided by the registry. The consumer does not depend directly on the services
implementation but only on the contract the service supports.
Abstraction Service hides its logic from the outside world. The information
published in a service contract is limited to what is required to utilize the service
effectively. The processing details are hidden from and irrelevant to all service
requestors.
Reusability Services aim to support reusability. The possibility of being able to
accommodate future requirements with less development effort can be increased
by applying this principle at the analysis phase. When designing for potential reuse,
a service can be part of multiple complex services.
Composability A service can involve other services, and developers can coordinate
and assemble services to form a composite one. Composite web services provide
multiple services to the service consumers.
Statelessness Services do not maintain state information specific to an activity to
remain loosely coupled, such as a service request.
Discoverability Services allow service consumer to use service discovery mechanism and understand their descriptions. Web service discovery mechanism refers
to the design of a service so that it becomes as discoverable as possible, regardless
of whether a discoverability product or extension actually exists in its surrounding
implementation environment. Service discoverability supports avoiding unintentional
creation of redundant services/logic at the design phase.
Service autonomy Autonomy refers to the ability of a service to control underlying runtime execution environment, which minimizes unpredictable external
influences. It is a key consideration when deciding how to set an explicit boundary
for application logic to be divided into services and which operations should be
grouped together within a service context to avoid redundancy.
Service normalization Services are decomposed and integrated to a level of
normal form to minimize redundancy. Services can be de-normalized for specific
purposes, such as, performance optimization, access, and aggregation.
12.3.3 Phases of SOSE

Services and compositions of services need to be engineered in order to create
a new process. This process is known as service-oriented software engineering.
M12_SE_01_M12.indd 448
6/28/2013 11:21:15 AM
449
At the global level, the SOSE life cycle is not much different from the classical
software life cycle. The SOSE life cycle consists of phases such as service-oriented
analysis, service-oriented design, service architecture, service implementation,
and deployment.19,20
Analysis The goal of service-oriented analysis is to capture the characteristics
and requirements of the problem domain and transform them into a set of service
candidates providing the necessary functionality. A service, whether it is simple or
a large composite service, models a business process. The first step in the analysis
phase stipulates the service to include which business process will be handled
by the service, what the start and end are, who the participants are, and input and
output of the process. The first step determines the boundaries for the steps to
follow.
Architecture The architecture phase begins with a decomposition of the process
into its constituent process steps and their interactions. Workflow modelling
notations and languages are used for this purpose. Usage scenarios are devised and
are used to manually test the process flow developed and identify any missing steps.
These usage scenarios then help to decide which services can be grouped into a
composite service. The next step is to compose a specific service-oriented architecture. Service layers, web services standards to be used, as well as rules for how the
web services are to be applied are determined.
Design The design phase is subdivided into two activities such as design of
services and their interfaces. In terms of SOA style, this concerns the detailed
design of the service layers and the coordination layer.
Implementation In the implementation phase, abstract service interfaces are
expressed using platform-specific interface definition languages such as Web
Services Description Language (WSDL). Basic services are realized through
implementation in code or through integration of preexisting tools for composite
services mechanisms like BPEL. .NET framework provides facility to develop web
services.
Deployment In this phase, the service is deployed on a host location from where
it can be accessed by the user.
12.4 USABILITY ENGINEERING

Usability is one of the key features of software. ISO 9241-11 defines usability as:
Usability is the extent to which a product can be used by the specified users to
achieve the specified goals with effectiveness, efficiency, and satisfaction in a
specified context of use.21 That is, a product is usable if it is appropriate for a
purpose, comprehensible, learnable, ergonomic, and possesses other quality
attributes. Usability is a quality attribute that assesses how easy user interfaces
are to use. Usability relates to how the system interacts with the user of the system.
Usability has the following five quality components.22
M12_SE_01_M12.indd 449
6/28/2013 11:21:15 AM
Ease of learning The system should be easy to learn so that the user can rapidly
start getting some work done with the system. Ease of learning is usually assessed
by measuring the time a user spends working with the system before that user can
complete certain tasks in the time it would take an expert to complete the same
tasks. This attribute is very important for novice users.
Efficiency of use The system should be efficient to use, so that once the user
has learned using the system, a high level of productivity is possible. In a specified time duration, maximum speed of user task performance is expected.
The higher the system usability the faster the user can perform the task and
complete the job.
Memorability The system should be easy to remember, so that a casual user is
able to return to the system after some time, without having to learn everything all
over again. Memorability can be measured by performing a standard user test with
casual users who have been away from the system for a specified amount of time,
and measure the time they need to perform some typical test task.
Error frequency and severity How many errors do users make, how severe are
these errors, and how easily can they recover from the errors? Error frequency and
severity reflects how well the user remembers how the system works after a period
of non-usage. Users should make as few errors as possible when using a computer
system. The systems error rate is measured by counting the number of errors made
by users while performing some specified task.
Satisfaction How pleasant is it to use the design? This shows a users subjective
impression of the system. Subjective satisfaction might be measured by simply
asking the users their subjective opinion.
Usability engineering is a discipline that provides structured methods for
achieving usability in user interface design during product development.23 It is
a methodical engineering approach to user interface design and evaluation,
involving practical, systematic approaches to developing requirements, analyzing
a usability problem, developing proposed solutions, and testing those solutions.
Usability engineering deals with design of websites, computer portals, computer
keyboard design, car dashboard design, TV remote key layouts, washing machine
front panel layout, etc.
There are various principles of usability. Some of the important principles of
usability are as follows.
Visibility It specifies what the software looks like to the user.
Feedback It is the response from the users. The system should send back to the
user information about what action has actually been done and what result has
been accomplished.
Structure The system should be designed in such a way that a user can easily
control the system. There should be proper icons and exit points.
M12_SE_01_M12.indd 450
6/28/2013 11:21:15 AM
451
Reuse The system should be consistent so that it can be reused in other environment.
Simplicity System should be simple and help users to diagnose the errors and to
overcome them.
12.4.1 Usability and HCI

Usability issues are not tolerable during system use, especially in the case where
we have never used the system or we use a system which is difficult and complex
to use. People dont have patience to wait before using the system. Therefore, it is
required that the system which we are using must be highly usable. Before usability
engineering, human-computer interaction (HCI) was used. It was used as technical
support for the users and helped in interaction, visualization, and collaboration.
The design of a software system affects its acceptance and use for the customer.
Therefore, systems should be designed for the needs and capabilities of the people
for whom they are intended. User interface (UI) design describes any kind of
interface design of an interactive system and also the information design of noninteractive systems. Thus, user interface design is a subset of usability engineering.
There is a difference between the visible part of the user interface (buttons,
pull-down menus, checkboxes, background color, and so forth) and the interaction part of the system. Interaction describes the coordination of the information
exchange between the user and the system. It is important to consider the design
of interaction when designing the rest of the system, not just when designing
the visible part of the user interface. The system should be designed so it can
frequently send information to the user interface to keep the user informed
about the operations current status. The system could display this information
as a percentage-completed bar, as in some software installation programs. The
development team must consider user interaction from the beginning of the
development process. Consideration and understanding of the interaction will
affect the final products usability.
Usability engineering decreases software development time and costs. Late
discovery of defects in a system will necessitate reengineering time and cost.
Through systematic usability engineering, the user gets satisfaction instead of
frustration. He can easily learn to handle the system.
12.4.2 Usability Engineering Process

Usability engineering is a set of activities that ideally take place throughout the
life cycle of a product, with significant activities happening at the early stages
before the user interface has even been designed. It is a part of development
context. The involvement of human factors with a particular product may ultimately
have the greatest impact on future product releases. The usability engineering
process goes through various phases as there are different software phases. There
are also several usability engineering life cycles. Usability engineering approaches
often have the following phases in common.24
M12_SE_01_M12.indd 451
6/28/2013 11:21:15 AM
Requirements analysis In this phase, we understand the users and their needs,
expectations, interests, behaviors, and responsibilities, all of which characterize
their relationship with the system. Here, user profiles are conceived. Two important
activities are performed at this stage: task analysis and platform capabilities and
constraints. Task analysis reveals task requirements and the current workflow as
well as specific conditions of use. Task analysis describes a set of techniques people
use to get things done. Platform capabilities and constraints are recognized at this
phase. Usability benchmarks are defined to assess the value of usability attributes
for the system under development.
Conceptual model design It includes reengineering the workflow and writing
down the application structure. In the conceptual design phase, we define the basic
user-system interaction and the objects in the UI and the contexts in which the
interaction takes place. The findings of the user and task analysis are the basis for
conceptual design. The deliverables from this phase are typically paper prototypes
such as pencil drawings or screen mock-ups and a specification which describes
the UIs behavior.
Prototyping Prototypes are crucial for performing usability testing in early
development phases. The design of prototypes is important because abstract technical specifications are ineffective way of communicating with users. We create
prototypes to test them on the user through usability evaluation techniques. Prototyping techniques employ paper mock-ups, Wizard of Oz technique, scenarios,
storyboards, and snapshots.
Implementation At this stage, the user interface is finally developed for the
system. After implementation, it is delivered and installed at the customer site.
Evaluation and refinement Requirements lead to an update of the product,
repeating the usability engineering process. Usability evaluation is performed
in the usability process. It can determine the current versions usability level and
whether the design works.
12.4.3 Usability Methods

There are various methods of usability and some of the most widely used methods
are user profiling, user scenarios, usability testing, inspection, etc.25,26,27 These
methods are discussed below.
User profiling User profiling is a process of collecting all the known information about the audience of a specific product, and then breaking it into specific
profiles. The collected information is organized in a document for each of these
groups. The document includes information such as technology used by the users,
population characteristics (age, gender, socio-economic breakdown, etc.), and
relevant experience.
Heuristic evaluation A heuristic evaluation is an evaluation of an interface by one
or more human factors experts. Evaluators measure the usability, efficiency, and
M12_SE_01_M12.indd 452
6/28/2013 11:21:15 AM
453
effectiveness of the interface based on usability heuristics. Usability heuristics, which

have continued to evolve in response to user research and new devices, include
visibility of system status, match between system and the real world, user control
and freedom, consistency and standards, recognition rather than recall, and so on.
User scenarios A scenario is an encapsulated description of an individual user,
using a specific set of computer facilities to achieve a specific outcome under
specified circumstances over a certain time interval. The data collected from the
user profiling may have different scenarios. In these scenarios, a persona uses
the software to reach a specific goal. The scenarios are useful to express and
understand the way users eventually will interact with the future system. Also,
user scenarios are used to get user feedback without the expense of constructing
a running prototype.
Task analysis Task analysis is the process of identifying how people think about
tasks and how they complete them. The purpose is to make sure that the interface
designed matches the users mental model of that task closely. This will help users
to do things at every point quickly and easily. Task analysis would be used to identify
what information users needed at each point, what their concerns were at every
step, and what options they used.
Prototyping Prototyping is a way to reduce testing efforts in early development
stages at a low price and effort. Prototypes cut down either on the number of
features or the depth of functionality of features to perform usability evaluation
as early as possible in the design cycle. Prototypes with different levels of realism,
interactivity, and production effort can be used according to the current test.
Usability testing Usability testing is the empirical testing of interface design with
representative users. It is a process which should discover if given usability targets
are fulfilled. It includes a range of methods that examine how users in the target
audience interact with a system. In a typical approach, a user performs a variety
of tasks with the application while an observer records notes on how successful
the user is in performing each task: how fast users go, what mistakes they make,
where they are confused, what solution paths they take, how many learning trials
are involved, and so forth. During usability testing, developers are not expected to
explain their product to the user or argue about its merits.
Usability inspection In usability inspection, usability experts analyze if the
usability guidelines are implemented correctly. Usability testing concentrates on
real test users. Usability inspection is based on having evaluators inspect the interface.
It is aimed at finding usability problems in a design.
12.5 MODEL-DRIVEN SOFTWARE ENGINEERING

Model-driven software engineering (MDSE) is becoming a widely-used approach
for developing complex applications. MDSE advocates the use of models as the key
M12_SE_01_M12.indd 453
6/28/2013 11:21:15 AM
artifacts in all phases of development process, from system specification and analysis
to design and testing. In MDSE, software developers concentrate on the problem
space (models) and not on the (platform-specific) solution space. MDSE is the
application of model-driven engineering to software engineering, i.e., it consists of
systematically using models as primary engineering artifacts throughout the software engineering life cycle. Model-driven engineering (MDE) refers to the use of
generative and transformational techniques for software engineering where system
implementations are semi-automatically derived from models or specifications.28
Model-driven engineering is supported by model-driven architecture (MDA).
Applications are modeled at a platform-independent level and are transformed by
means of model transformations to platform-specific implementations. The most
common types of models of software systems used today are UML models and
several types of formal models. The three primary goals of MDA are portability,
interoperability, and reusability through architectural separation of concerns. Therefore, a system should be specified independently from the platform that supports it.
Based on platform specifications and the choice of a specific platform the system
specification should be transformed into the specific platform. In general, transformations can be between any types of models, for example, platform-independent
models to platform-specific models and also from models to code.
The main focus of MDSE is to achieve greater productivity in creating new
software. There are numerous applications of MDSE. Model-driven engineering
technologies offer a promising approach to address the inability of third generation
languages to alleviate the complexity of platforms and express domain concepts
effectively. MDSE is useful in data-centric applications. That is, model describes
the data, constraints, relationships, and workflow. The forms, form validation, SQL
code, correct control flow, etc., are all generated from domain model. MDSE is also
useful in function critical applications to perform model checking. Also, it is widely
used in mobileapplicationdevelopment; that is, writing the same application for
multiple platforms.
12.5.1 Model-Driven Architecture

Model-driven architecture (MDA) is an approach to application design and
implementation. MDA is evolved from object management architecture (OMA),
which provides a framework for distributed systems. It is based on a set of
emerging standards for how to define a set of models, notations, and transformation rules. The MDA approach provides an open, vendor-neutral basis for system
interoperability via Object Management Groups (OMG) established modeling
standards: Unified Modeling Language (UML), Meta-Object Facility (MOF), and
Common Warehouse Metamodel (CWM). Platform-independent descriptions of
applications can be built using these modelling standards and can be transformed
into a major open or proprietary platform, including CORBA, J2EE, .NET, XMI/
XML, and web-based platforms.
Model-driven architecture is called as a platform-independent model
(PIM), which is transformed to a platform-specific model (PSM) by means of a
M12_SE_01_M12.indd 454
6/28/2013 11:21:15 AM
455
transformation. For example, an illustration of MDA is shown in Figure 12.3. The

MDA approach provides the facility to understand complex and real world systems
while providing an abstraction of the physical system. Here, UML, MOF, and XMI
are used as modeling standards and transformation tools. These ensure an open,
vendor-neutral approach to system interoperability and allow transformations to
major open execution platforms. CORBA, COM+, .NET, and J2EE are the concrete
execution platforms. Application domains such as finance, telecom, ecommerce,
healthcare, and so on are shown at the outer layer of the architecture.
Application
domains
Modeling standards
and transformation tools
Finance
CORBA
Telecom
eCommerce
UML
.NET
Model-driven
architecture
MOF
COM1
XML
Concrete
execution
platforms
Java EE
Healthcare
...
Figure 12.3 Model-driven architecture
Models play a major role in MDA. A system is specified independently from

the platform that supports it. Based on platform specifications and the choice of a
specific platform, the system specification should be transformed into the specific
platform. The MDA pattern is shown in Figure 12.4. The platform-independent
model (PIM) is transformed to a platform-specific model (PSM) by means of a
transformation.
The OMG has established a conceptual framework that relies on a specific set
of layers and transformations to represent the MDA approach. Computationalindependent model (CIM), platform-independent model (PIM), and platformspecific model (PSM) are the three model types that have been largely adopted
M12_SE_01_M12.indd 455
6/28/2013 11:21:15 AM

Platform-independent model
Model
e.g., UML, XMI etc.
Transformation
Platform-specific model
Code
e.g., J2EE, XML etc.
Figure 12.4 MDA pattern
by the software community.29 CIM model is a view of a system from a computationindependent viewpoint. The intended meaning is less about abstracting from
computation but about details about the structure of a system. PIM model is
independent of the features of a platform of any particular type. PIMs can be
targeted for a technology-neutral virtual machine, a general kind of platform, or
an abstract platform. PSM model is targeted for a specific platform. It is derived
from a platform-independent model by a transformation, thereby combining
the platform-independent specification with platform-specific details. A PSM
provides details (more or less) depending on its purpose. If it comprises all the
details needed for automatically generating an implementation from the model,
then it represents a platform-specific model of the implementation. The resulting
code is then obtained by serializing the model. Otherwise, a PSM may require
further refinements before getting a platform-specific implementation model.
Model transformations are important within any MDA style of development. Model transformations involve using a model as one of the inputs in
the automation process to produce outputs as another model or varying levels
of executable code. There are three common model transformations: refactoring transformations, model-to-model transformations, and model-to-code
transformations.30 Refactoring transformations reorganize a model based on
some well-defined criteria. The output is a revision of the original model called
the refactored model. Model-to-model transformations convert information from
one model or models to another model or set of models, typically where the flow
of information is across abstraction boundaries; for example, the transformation of
a set of entity classes into a matched set of database schema and XML-formatted
mapping descriptor files. Model-to-code transformations are familiar to anyone
who has used the code generation capability of a UML modeling tool. These transformations convert a model element into a code fragment. Model-to-code transformations can be developed for nearly any form of programming language or
declarative specification; for example, generating Data Definition Language (DDL)
code from a logical data model expressed as a UML class diagram.
12.5.2The MDSE Approach

Model-driven software development offers a significantly more effective approach.
The approach to model-driven engineering uses the concept of MDA. MDA allows
M12_SE_01_M12.indd 456
6/28/2013 11:21:15 AM
457
domain experts, platform experts, and application developers to contribute their

respective knowledge independently. An approach to the model-driven development process is depicted in Figure 12.5.31,32 The main phases of the process are
analysis, design, and model-driven implementation. These correspond to computation-independent models (CIM), platform-independent models (PIM), and
platform-specific models (PSM) of the MDA approach.
Finance, insurance,
loan automation, etc.
Business and models
Analysis model
Computational-independent model (CIM)
UML, MOF, CWM and XML

Design model
Platform-independent model (PIM)
CORBA, .NET, or J2EE

Implementation model
Platform-specific model (PSM)
System
Figure 12.5 Model-driven development process
The analysis phase aims to gather a stable set of requirements. As we discussed

in Chapter 7, functional requirements are captured by means of specialized use
cases and content requirements are represented by a class model. The design
phase has a series of models for the content, navigation, process, and presentation
concerns at a platform-independent level. Transformations implement a systematic construction of dependent models by generating default models. Stereotypes
can be used for transition from the requirements model to the design models.
Finally, a platform-specific implementation model is obtained to code by modelto-code transformations.
Different kinds of models make us to think of software system development
as a series of refinements between different model representations. Such models
are considered as metamodels. For example, the UML metamodel describes the
meaning of a class, an attribute, and their relationships. Models and the transformations are specified using open standards such as CORBA, UML, CWM, etc.
Model-driven development is faster and has interactive ideas of software development. It is more cost-effective than traditional approaches. It increases product
quality, productivity, and supports portability and interoperability. It leads to
M12_SE_01_M12.indd 457
6/28/2013 11:21:16 AM
meaningful validation and empowers domain experts. Also, it has certain limitations.
The MDA approach introduces a lot of rigidity in development. The roles of
project members are quite different. Sometimes there is a difficulty to support
version control. The requirements team needs to understand what is allowed
and what is not.
12.6 CLIENT-SERVER SOFTWARE ENGINEERING

In a client-server model, the client process makes use of the services provided by
the server process. Although the client-server idea can be used by programs within
a single computer, it is a more important concept in a network-based system.
Ina network, the client-server model provides a convenient way to interconnect
programs that are distributed efficiently across different locations. The examples of
client-server system are database servers, file servers, transaction servers, groupware servers, etc.
The client system has a customized user interface and performs front-end
processing of data, initiation of server remote procedure calls, and access to
database server across the network. The server system performs centralized data
management, data integrity and database consistency, database security, concurrent operations, and centralized processing. The client-server architecture was
emerged to overcome the limitations of file sharing architectures. Client-server
describes the relationship between two computer programs. The client makes
a service request from another program and the server fulfils the request. Typically, the interaction of the client and server processes follows a request-response
pattern. It is shown in Figure 12.6.
Request
Response
Client
Server
Figure 12.6 Client-server interaction
12.6.1 Client-Server Architectures

The client-server model is designed for large networks where users are localized
and connected from a variety of outside places. In client-server computing, end
user applications consist of three components: presentation, processing, and data.
A vast majority of client-server architectures can be defined by how these components are split up among software entities and distributed on a network. There
are a variety of ways for dividing these resources and implementing client-server
architectures. The client-server model consists of two major architecture types,
namely, two-tier and three-tier architectures. In the following paragraphs, we will
discuss these architectures.
M12_SE_01_M12.indd 458
6/28/2013 11:21:16 AM
459
Two-Tier Architecture
Two-tier architecture is the simplest of the architecture types, consisting of only the
server and the client application. It is shown in Figure 12.7. With the two-tier architecture, the user system interface is usually located in the clients environment and
the database management services are usually in a server, which is a more powerful
machine that services many clients. Processing management is split between the
client environment and the database management server environment. The database management server provides stored procedures and triggers.
Client application
Database
Internet
Database server
Client application
Client environment
Database server environment
Figure 12.7 Two-tier architecture
Two-tier software architectures are used extensively in non-time critical information processing, where management and operations of the system are not
complex. This design is used frequently in decision support systems where the
transaction load is light. Two-tier software architectures require minimal operator
intervention. The two-tier design is simple to adopt. The two-tier architecture is a
good solution for distributed computing when work groups are defined as a dozen
to 100 people interacting on a LAN simultaneously. The two-tier architecture does
have a number of limitations. The most important limitation of the two-tier architecture is that it is not scalable because each client requires its own database session.
When the number of users exceeds 100, performance begins to deteriorate. A second
limitation of the two-tier architecture is the implementation of processing management services using vendor proprietary database procedures restricts flexibility and
choice of database management systems (DBMS) for applications.
Three-Tier Architecture
Three-tier architecture (also known as multi-tier architecture) emerged to overcome the limitations of the two-tier architecture. In the three-tier architecture, a
middle tier was added between the user system interface client environment and
the database management server environment. There are a variety of ways of
implementing this middle-tier such as transaction processing monitors, message
servers, or application servers. The middle tier can perform queuing, application
execution, and database staging. The three-tier architecture is shown in Figure 12.8.
M12_SE_01_M12.indd 459
6/28/2013 11:21:16 AM
Client application
Database server
Internet
Business logic
Database
Client application
Business tier
Client tier
Data tier
Figure 12.8 Three-tier architecture
For example, if the middle tier provides queuing, the client can deliver its request
to the middle layer and disengage because the middle tier will access the data and
return the answer to the client. In addition, the middle layer adds scheduling
and prioritization for work in progress. Three-tier architecture has been shown
to improve performance for groups with a large number of users and improves
flexibility when compared to the two-tier approach. Flexibility in partitioning can
be as simple as dragging and dropping application code modules onto different
computers in some three-tier architectures. A limitation with three-tier architectures
is that the development environment is reportedly more difficult to use than the
visually-oriented development of two-tier applications.
12.6.2 Client-Server Tools and Technologies

The development of software for client-server systems uses two approaches: evolutionary approach that makes use of object-oriented technology and component-based
software engineering (CBSE). The evolutionary process model begins with requirements elicitation. Functionality is allocated to subsystems of components, which
are then assigned to either the client or the server side of the architecture.
Client-server systems are developed using the classic software engineering
activities, viz., analysis, design, construction, and testing. The system evolves from
a set of general business requirements to a collection of validated software components that have been implemented on client and server machines. Because an
evolutionary approach to software engineering is applied for client-server systems,
implementation decisions on the overall client-server approach may be made
during early analysis and design iterations. The architectural design of a clientserver system is often characterized as a communicating processes style. The goal is
to achieve the quality of scalability.
Because modern client-server systems are component based, object request
broker (ORB) architecture is used to implement this synchronous or asynchronous
communication. At the architectural level, CORBA Interface Description Language
(IDL) is used to specify the interface details. The use of IDL allows application
M12_SE_01_M12.indd 460
6/28/2013 11:21:16 AM
461
software components to access ORB services without knowledge of their internal

workings. ORB also has the responsibility for coordinating communication among
components for both the client and server. To accomplish this, the designer specifies
an object adapter (also called a wrapper) which ensures that component implementations are registered, interpreted and reconciled, mapped to the corresponding
component implementation, activated and deactivated, methods (operations) are
invoked when messages are transmitted, and the security features are implemented.
To accommodate COTS components supplied by different vendors and in-house
components that may have been implemented using different technologies, the
ORB architecture must be designed to achieve interoperability among components.
To accomplish this, CORBA uses a bridging concept. The client-server software
subsystems are implemented by components (objects) that must be capable of interacting with one another within a single machine (either client or server) or across
the network. An ORB is middleware that enables an object that resides on a client to
send a message to a method that is encapsulated by an object that resides on a server.
In essence, ORB intercepts the message and handles all communication and coordination activities required to find the object to which the message was addressed. ORB
invokes its method, passes appropriate data to the object, and transfers the resulting
data back to the object that has generated the message in the first place.
Three widely-used standards that implement an object request broker philosophy
are CORBA, COM, and JavaBeans. Fundamental Internet tools are used in clientserver software development. A web browser (e.g., Netscape Navigator, Google
Chrome, Mozilla Firefox, Internet Explorer, etc.) is a software application for
retrieving, presenting, and traversing information resources on the World Wide
Web. Search engines are designed for searching the Internet for sites and resources.
Network utilities are software utilities designed to analyze and configure various
aspects of computer networks.
12.6.3 Applications, Advantages, and Limitations

Client-server applications are important in offering services throughout the
Internet. Some of the applications of client-server architectures are as follows.33
Mobile computing Mobile computing is a technology for handheld devices
which allows people to access data and information at every corner of the earth.
It can use cell phone connections to make phone calls as well as for connecting to
the Internet.
Remote procedure calls (RPC) RPC is an inter-process communication that
allows a computer program to cause a subroutine or procedure to execute in
another address space without the programmer explicitly coding the details for
this remote interaction.
Net banking Net banking has replaced the conventional way of banking. Now
you are not required to stand in long queues for depositing money, withdrawing
money, or updating your account. All such facilities are available on your machine.
M12_SE_01_M12.indd 461
6/28/2013 11:21:16 AM
Online education system In online education system, a student is not required

to go to an institute and register himself to attend classes. A student can avail all
educational facilities at the click of a mouse.
Electronic commerce It is the buying and selling of products or services over
electronic systems such as the Internet and other computer networks. Electronic
commerce draws on such technologies as electronic funds transfer, supply chain
management, Internet marketing, online transaction processing, electronic data
interchange (EDI), inventory management systems, and automated data collection
systems.
Satellite communication It involves only simple communications between the
client and the server. In satellite communication, signal transferring between the
sender and receiver is done with the help of satellite. All signal transferring happens
in space.
Military system Military is one potential field for IT research. With computerbased information systems, military managers can manage all aspect of the army
including supply, ammunition, and fuel for the army.
There are several advantages of client-server systems, which include the
following.
Portability The server can be installed on a variety of machines and operating
systems and functions in a variety of networking environments.
Transparency The server might itself be distributed, but it should provide a
single logical service to the user.
Performance The client should be customized for interactive display-intensive
tasks. The server should provide CPU-intensive operations.
Scalability The server has spare capacity to handle larger number of clients. The
number of nodes can be increased in a network.
Flexibility The client-server systems are usable for a variety of user interfaces.
Reliability A system should survive individual node and/or communication link
problems.
In spite of the above advantages, client-server systems have certain limitations.
They do not provide peer-to-peer communication. Two-tier architectures are not
suitable for dispersed, heterogeneous environment with rapidly changing business
rules. The bulk of application logic is on the client. There is problem of client software version control and new version redistribution. Security may be complicated
because user may require separate password for accessing each SQL server. The
three-tier architecture requires more processing on the web server. It has a more
complex structure which is difficult to set up and maintain. The physical separation
of application servers containing business logic functions and database servers
containing databases may moderately affect performance.34
M12_SE_01_M12.indd 462
6/28/2013 11:21:16 AM
463
12.7 COMPUTER-AIDED SOFTWARE ENGINEERING (CASE)

Computer-aided software engineering (CASE) is a tools support for software
development, management, and maintenance activities. The use of CASE tools
eases and reduces the development, management, and maintenance effort.
Automated tools accelerate the development activities. The CASE tools help the
developers, managers, and other key personnel to improve their productivity in
the development team.
Here, we will discuss various CASE tools and their benefits in software development and other activities.
12.7.1 CASE Environment

Software development life cycle activities can be assisted by the use of software tools.
Programmers can use automated tools for development, maintenance, management,
and planning purposes. The CASE environment of various automated tools is shown
in Figure 12.9. Some of the widely used tools are project planning tools, project
management tools, analysis and design tools, documentation tools, system software
tools, quality assurance tools, database tools, software configuration management
tools, prototyping tools, coding tools, testing tools, reengineering tools, etc.35,36
Quality
assurance tools
Project management
tools
Analysis and design

tools
Configuration
management tools
Documentation
tools
Central
repository
System
software tools
Reengineering
tools
Database
tools
Coding tools
Testing tools
Prototyping
tools
Project planning
tools
Figure 12.9 CASE tools
Project management tools Project management tools can be used to design

project schedule, activity plan, etc.
Database management tools The database for relational and object-oriented database management system is designed to provide support for the CASE repository.
M12_SE_01_M12.indd 463
6/28/2013 11:21:17 AM
Analysis and design tools These tools help to produce analysis and design
models of the system to be built. These models describe the problem and the solutions
of the system in the context.
Programming tools Compilers, editors, debuggers, programming environments,
fourth generation languages, graphical programming environments, applications
generators, and database query generators are the programming tools used for
programming purposes.
Integration and testing tools These tools are basically used for data preparation,
static and dynamic measurements, simulation, and test planning.
Project planning tools These tools are useful for cost and effort estimation and
project scheduling activities.
Prototyping tools These tools help to design screen layouts, data design, and
report generation.
Reengineering tools Reengineering tools are used during system migration
from an old platform to a new platform. There are various reengineering tools such
as reverse engineering to specification tools, code restructuring and analysis tools,
and online system reengineering tools.
System software tools There are various tools that assist to work in desktop and
network systems. For example, network system software, object management
services, distributed component support, and communications software.
Documentation tools These tools are useful to produce documentation of the
work products that pave the software development process.
Software configuration management tools The configuration management
tools assist configuration management activities such as configuration identification,
version control, change control, auditing, status accounting, etc.
Quality assurance tools The quality assurance tools are the auditing tools used
to determine compliance with language standards or to ensure the quality of software
being built.
12.7.2 Advantages of the CASE Tools

The CASE tools are used for routine development, management, planning, and
maintenance activities. The CASE tools are beneficial to achieve the following
benefits:
These are helpful in automating manual activities. This reduces the effort of
development and human mistakes.
The use of CASE tools saves development cost of all development phases.
The CASE tools improve the overall quality of the product due to the fact that
tasks are carried out in an automated manner instead of by human efforts.
M12_SE_01_M12.indd 464
6/28/2013 11:21:17 AM
465
They are highly useful in software maintenance tasks.

Requirement and configuration management with the CASE tools is more
effective. Systematic management of requirements and change requests
improves communication among team members and speeds up the development process.
Also, they increase the productivity of the software development process.
The CASE tools save manual documentation of huge documents. Automated
tools help to generate documents of software products.
Modeling tools are helpful in designing the prototypes of software.
SUMMARY
In this chapter, we have focused on the emerging software engineering
approaches. The main aspects are software reuse, aspect-oriented software engineering, service-oriented software engineering, usability engineering, model-driven
software engineering, client-server software engineering, and computer-aided
software engineering (CASE).
The development of faster, better, and cheaper software products can be
achieved with software reuse. Software reuse is an efficient way of implementing or
updating software systems with the existing software components. Software reuse
is the process of producing software systems from the existing software systems
rather than building software from scratch. Reuse-based software engineering
allows producing reusable components only once and saves the development effort
multiple times.
Aspect-oriented approach is a new paradigm that deals with the separation of
concerns in software development. It provides unique and advance techniques
of structuring and modularization for programs. Aspect-oriented development
techniques results in better implementation and have positive impact on many
quality attributes such as reusability and complexity.
Service-oriented software engineering deals with theories, principles, methods,
and tools for building enterprise-scale solutions as the collaboration of looselycoupled application services that provide particular business functionality and are
distributed within and across organizational boundaries. In this approach, services
are the basic elements for developing applications and software solutions. The
software in this paradigm is presented as a web service known by the term SaaS
(Software as a Service). A web service is a software component available on the
Internet with web interfaces, accessed remotely using Internet protocols and
infrastructure. It is based on service-oriented computing, which is supported by
service-oriented architecture (SOA), which provides the architectural style, standard
protocols, and interfaces required for application development. Service-oriented
software engineering focuses on the development of software systems by composition
of reusable services provided by other service providers.
Software usability is a quality attribute that assesses how easy user interfaces
are to use. Usability relates to how the system interacts with the user of the system.
M12_SE_01_M12.indd 465
6/28/2013 11:21:17 AM
Usability has five quality components: ease of learning, efficiency of use, memorability,
error frequency and severity, and satisfaction. Usability engineering is defined as a
discipline that provides structured methods for achieving usability in user interface
design during product development.37 Usability engineering deals with design of
websites, computer portals, computer keyboard design, car dashboard design, TV
remote key layouts, washing machine front panel layout, etc.
Model-driven software engineering advocates the use of models as the key
artifacts in all phases of the development process, from system specification and
analysis to design, and implementation and testing. Here, software developers
concentrate on the problem space (models) and not on the (platform-specific)
solution space. MDSE consists of systematically using models as primary engineering artifacts throughout the software engineering life cycle. Model-driven
engineering is supported by the model-driven architecture (MDA). In MDA,
applications are modeled at a platform-independent level and are transformed by
means of model transformations to platform-specific implementations.
The concept of client-server software engineering is important in a networkbased software development. Client-server describes the relationship between
two computer programs. The client makes a service request from another program
and the server fulfils the request. The client-server model is designed for large
networks, where users are localized and connected from a variety of outside places.
Client-server architectures can be defined by how these components are split up
among software entities and distributed on a network.
The CASE tools are the supporting tools for software development, management, and maintenance activities. The use of the CASE tools eases and reduces the
development, management, and maintenance effort. Automated tools speed up the
development activities. Some of the widely used tools are project planning tools,
project management tools, analysis and design tools, documentation tools, system
software tools, quality assurance tools, database tools, software configuration management tools, prototyping tools, coding tools, testing tools, reengineering tools, etc.
EXERCISES
1. Choose the correct answer:

(i) What is advantage of software reuse?

(A) Increase in productivity

(B) Increase in reliability

(C) Reduction in development cost and time

(D) All of the above

(ii) Which is a reusable artifact?

(A) Documentation
(B) Data

(C) Test cases
M12_SE_01_M12.indd 466
6/28/2013 11:21:17 AM
467
(iii) _________ is the reuse of reusable components without any modification such as standardization, wrapping techniques, etc.
(A) White-box reuse
(B) Black-box reuse
(C) Adoptive reuse
(D) None of the above
(iv) A _______ is a kind of software library where reusable components are managed systematically for easy access for future development.
(A) Reuse support system
(B) Reuse management system
(C) Reuse repository system
(v) Reuse level can be defined as

(A) Reuse (S)/Size(S)
(C) Reuse (S) + Size (S)
(vi) A location in a code where concern crosscuts to represent aspect is known as

(A) Pointcut
(B) Advice
(C) Join point
(D) Aspect
(vii) Which is a kind of compiler used for aspect languages?

(A) Advice
(B) Pointcut
(C) Weavers
(viii) Which of the following languages is used for aspect-oriented implementation?

(A) AspectJ
(B) UML
(C) Java
(B) Reuse (S) Size (S)

(ix) SOAP in SOA stands for

(A) System object access program
(C) System-oriented access protocol
(x) ________ is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.
(A) Reusability
(B) Usability
(C) Understandability
(D) Operability
(xi) Which is the principle of usability engineering?

(A) Visibility
(B) Feedback
(C) Reuse
(xii) Which one of the following is the model of the MDSE approach?
(A) Platform-independent models
(B) Platform-specific models
(C) Computation-independent models
(xiii) CORBA stands for

(A) Common Object Requirement Broker Architecture
(B) Common Object Request Broker Architecture
(C) Computer Object Requirement Broker Architecture
(D) Computer Object Request Broker Architecture
(xiv) Which is an important task in MDA style of development?

(A) Model transformations
(B) Modeling
(C) Program generation
(D) Model testing
M12_SE_01_M12.indd 467
(B) Simple object access protocol

(D) Simple object access program
6/28/2013 11:21:17 AM

(xv) Which is not present in the two-tier client-server architecture?

(A) Data tier
(B) Business tier

(C) Application tier

(xvi) Which is a part of the three-tier architecture?

(A) Data tier
(B) Business tier

(C) Application tier
(xvii) CASE stands for

(A) Computer-aided software engineering

(B) Component-aided software engineering

(C) Component-aided system engineering

(D) Computer-aided system engineering
(xviii) ______ is a tool support for software development, management, and maintenance
activities.

(A) UML
(B) CORBA

(C) CASE
(D) EJB

(xix) _______tool is used to design project schedule, activity plan, etc.

(A) Project management
(B) Analysis and design

(C) Testing
(D) Configuration

(xx) Which is a component-based technology?

(A) CORBA
(B) COM/DCOM

(C) JavaBeans
2. What is software reuse? What can be reused? What are the benefits and limitations of reuse-based
development?
3. What are different types of reuse? Explain with examples.
4. Describe an approach to software development with reuse? Explain its different aspects.
5. What is the purpose of reuse measurement? Explain the metrics for reuse size and cost estimation.
6. Explain the success and failure factors of software reuse.
7. What is the purpose of aspect-oriented software engineering? Explain its various components.
8. What are the major phases of aspect-oriented software engineering? Explain each of them.
9. What is service-oriented software engineering? Explain the service-oriented architecture for
service-oriented software engineering.
10. Describe the principles of services in service-oriented software engineering.
11. What are the different phases in service-oriented software engineering? Explain each with its
purpose.
12. Define usability and usability engineering. How does usability engineering differ from HCI?
13. Discuss the various phases of the usability engineering process. What methods are used in the
usability engineering process?
14. What is model-driven software engineering? Enumerate the importance of model-driven
software engineering.
15. What is MDA? Describe the pattern of MDA.
M12_SE_01_M12.indd 468
6/28/2013 11:21:17 AM
469
16. Discuss the process of model-driven software engineering. What tools and technologies are
used in the model-based software development?
17. What is client-server software architecture? Differentiate between two-tier and three-tier clientserver architectures.
18. What are the approaches to and technologies of client-server software engineering? Explain.
19. Discuss the applications, advantages, and limitations of client-server software architectures.
20. What is CASE? What are its advantages?
21. What are various CASE tools? Describe various CASE tools.
Answers
1. Choose the correct answer:

(i) D
(ii) D
(iii) B
(iv) C
(v) A
(vi) C
(vii) C
(viii) A
(ix) B
(x) B
(xi) D
(xii) D
(xiii) B
(xiv) A
(xv) B
(xvi) D
(xvii) A
(xviii) C
(xix) A
(xx) D
REFERENCES
1. Berry Boehm, Some Future Trends and Implications for Systems and Software Engineering
Processes, Systems Engineering, vol. 9, no. 1, Wiley Periodicals, Inc., 2006.
2. E. Lee, Software Reuse and Its Impact on Productivity, Quality and Time to Market, IEEE
Software, Texas, September 1999.
3. Ivar Jacobson, M. Griss, and Patrick Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Pearson Education, New Delhi, 2004.
4. Ibid.
5. Ibid.
6. E. Lee, Software Reuse and Its Impact on Productivity, Quality and Time to Market, IEEE
Software, Texas, September 1999.
7. Ivar Jacobson, M. Griss, and Patrick Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Pearson Education, New Delhi, 2004.
8. U. Suman and M. Ingle, Designing Reuse Repository System for an Effective Software Development with Reuse, PCTE Journal of Computer Science, vol. 2, issue 2, pp. 3847, Ludhiana, July
December 2006.
9. U. Suman and M. Ingle, Systematic Software Reuse: Reuse Factors, Productivity and Quality,
Proc. of International Conference on Information and Communication Technology, IICT07,
pp. 967973, Dehradun, India, 2628 July 2007.
M12_SE_01_M12.indd 469
6/28/2013 11:21:17 AM
10. Ivar Jacobson, M. Griss, and Patrick Jonsson, Software Reuse: Architecture, Process and Organization
for Business Success, Pearson Education, New Delhi, 2004.
11. U. Suman and M. Ingle, Systematic Software Reuse: Reuse Factors, Productivity and Quality,
Proc. of International Conference on Information and Communication Technology, IICT07,
pp. 967973, Dehradun, India, 2628 July 2007.
12. J. Brichau and T. D. Hondt, Aspect-Oriented Software Development (AOSD) - An Introduction, Wiley Encyclopedia of Computer Science and Engineering, 2008.
13. Kirti Muley, U. Suman, and M. Ingle, Representing Join Point in UML Using Pointcuts, Proc.
of International Conference on Computer and Communication Technology, ICCCT10, IEEE
Xplore, pp. 557561, Allahabad, India, 1719 September 2010.
14. J. Brichau and T. D. Hondt, Aspect-Oriented Software Development (AOSD) - An Introduction,
Wiley Encyclopedia of Computer Science and Engineering, 2008.
15. Zoran Stojanovic and Ajantha Dahanayake, Service-Oriented Software System Engineering:
Challenges and Practices, Idea Group Publications, 2005.
16. T. Erl., Service-Oriented Architecture: Concepts, Technology & Design, Prentice Hall International,
Boston, 2005.
17. Ibid.
18. Ibid.
19. Zoran Stojanovic and Ajantha Dahanayake, Service-Oriented Software System Engineering:
Challenges and Practices, Idea Group Publications, 2005.
20. T. Erl., Service-Oriented Architecture: Concepts, Technology & Design, Prentice Hall International,
Boston, 2005.
21. Ergonomic Requirements for Office Work with Visual Display Terminals, ISO 9241-11, ISO,
Geneva, 1998.
22. Xavier Ferr et al., Usability Basics for Software developers, IEEE Software, pp. 2229, January/
February 2001.
23. Ibid.
24. The HCI Space, The Usability Engineering Life Cycle, http://www.tauweb.de/hci/space/x11.html,
1999.
25. Ergonomic Requirements for Office Work with Visual Display Terminals, ISO 9241-11, ISO,
Geneva, 1998.
1999.
27. Jakob Nielsen, Usability Engineering, Academic Press, Boston, 1993.
28. Sami Beydeda, Matthias Book, Volker Gruhn, Model-Driven Software Development, Springer
Verlag, Berlin Heidelberg, 2005.
29. Ibid.
30. Stephen J. Mellor et al., MDA Distilled: Principles of Model-Driven Architecture, Addison Wesley,
2004.
M12_SE_01_M12.indd 470
6/28/2013 11:21:17 AM
471
31. Sami Beydeda, Matthias Book, Volker Gruhn, Model-Driven Software Development, Springer
Verlag, Berlin Heidelberg, 2005.
32. Stephen J. Mellor et al., MDA Distilled: Principles of Model-Driven Architecture, Addison Wesley,
2004.
33. Rajib Mall, Fundamentals of Software Engineering, Third Edition, PHI, 2011.
34. R. S. Pressman, Software Engineering: A Practitioners Approach, International Edition, Tata
McGraw Hill, 2005.
35. Ibid.
36. Rajib Mall, Fundamentals of Software Engineering, Third Edition, PHI, 2011.
1999.
M12_SE_01_M12.indd 471
6/28/2013 11:21:17 AM
M12_SE_01_M12.indd 472
6/28/2013 11:21:17 AM

Emerging Software Engineering: Hapter

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Emerging Software Engineering: Hapter

Загружено:

Авторское право:

Доступные форматы

Chapter

Emerging Software Engineering

12.1 SOFTWARE REUSE

430 Software Engineering: Concepts and Practices

12.1.1 Reusable Components

Emerging Software Engineering

Requirements analysis document (software requirements, subsystems)

432 Software Engineering: Concepts and Practices

Reuse management refers to the degree to which reuse is performed systematically.

Emerging Software Engineering

434 Software Engineering: Concepts and Practices

12.1.3 Software Development with Reuse

Figure 12.1 Software development with reuse

Emerging Software Engineering

systematically classified in order to achieve efficient storage scheme and quick

436 Software Engineering: Concepts and Practices

components in terms of their signatures. It defines the interface of components.

Emerging Software Engineering

are various types of reuse metrics: cost-benefit analysis, maturity assessment,

438 Software Engineering: Concepts and Practices

Total cost of system development with reuse (CS)

12.1.4 Reuse Benefits and Reuse Barriers

Emerging Software Engineering

12.1.5 Success and Failure Factors of Reuse

440 Software Engineering: Concepts and Practices

Emerging Software Engineering

components certification. Publication of success stories, education, and good

12.2 ASPECT-ORIENTED SOFTWARE ENGINEERING

442 Software Engineering: Concepts and Practices

12.2.1 Components of Aspect Orientation

Emerging Software Engineering

444 Software Engineering: Concepts and Practices

features. The first makes it possible to define additional implementation to run at

12.2.2 AOSD Process

Emerging Software Engineering

Further, an aspect can be dependent on other aspects. To ensure that aspects

12.2.3 AOP Benefits and Limitations

12.3 SERVICE-ORIENTED SOFTWARE ENGINEERING

446 Software Engineering: Concepts and Practices

12.3.1 Service-Oriented Architectures

Emerging Software Engineering

Figure 12.2 Service-oriented architecture

12.3.2 Principles of Services in SOSE

448 Software Engineering: Concepts and Practices

Loose coupling Service-oriented architecture promotes loose coupling between

12.3.3 Phases of SOSE

Emerging Software Engineering

12.4 USABILITY ENGINEERING

450 Software Engineering: Concepts and Practices

Emerging Software Engineering

12.4.1 Usability and HCI

12.4.2 Usability Engineering Process

452 Software Engineering: Concepts and Practices

12.4.3 Usability Methods

Emerging Software Engineering

effectiveness of the interface based on usability heuristics. Usability heuristics, which

12.5 MODEL-DRIVEN SOFTWARE ENGINEERING

454 Software Engineering: Concepts and Practices

12.5.1 Model-Driven Architecture

Emerging Software Engineering

transformation. For example, an illustration of MDA is shown in Figure 12.3. The

Figure 12.3 Model-driven architecture