-
Emerging Software Engineering12Chapter
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 soft-ware
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
-
Software Engineering: Concepts and Practices430
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
engi-neering 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 non-reusable
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 appli-cation 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 stan-dards, 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 soft-ware 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
-
Emerging Software Engineering 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 compo-nents. 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. Component- and 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.2 Types 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
-
Software Engineering: Concepts and Practices432
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 stan-dards,
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 imple-mentation
from its clients whereas implementation of the white-box reuse is
visible
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 Abstractlevel
Adaptive(porting)
Generative Instancelevel
In-the-small Customization reuse
In-the-large GenericCarried over
M12_SE_01_M12.indd 432 6/28/2013 11:21:14 AM
-
Emerging Software Engineering 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 reus-able 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
possi-bility 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-the-large 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 subse-quent
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 incre-mental
development. A new application system may inherit information
from
M12_SE_01_M12.indd 433 6/28/2013 11:21:14 AM
-
Software Engineering: Concepts and Practices434
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, refine-ment and
integration, and reuse measurement. In the subsequent paragraphs,
wewill discuss these aspects of reuse-based development.
Figure 12.1 Software development with reuse
Integration withdevelopment
Reuse repository
Domainengineering
New software
Searching Retrieval Reusemeasurement
Productrequirements
Domain EngineeringDomain 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 compo-nent 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 soft-ware domain, banking software domain,
telecommunication domain, and system software domain. From all
these domains, developers can design reusable compo-nents.
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
-
Emerging Software Engineering 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 RepositoryA 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 reengi-neering 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 mecha-nisms 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 compo-nents, 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 compo-nents, 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 RetrievalThe 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
keyword- and 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
-
Software Engineering: Concepts and Practices436
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 IntegrationComponent 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
applica-bility 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 effi-ciently. The integration of reusable
components highly reflects from the type of interfaces and their
signatures.
Reuse MeasurementReuse 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
-
Emerging Software Engineering 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 softwareReuse(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
-
Software Engineering: Concepts and Practices438
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 well-recognized 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 devel-oper 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 compo-nents 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
-
Emerging Software Engineering 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
-
Software Engineering: Concepts and Practices440
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 gener-ative 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
develop-ment 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 organi-zation should establish a set of standards, including
inspection and metrics for
M12_SE_01_M12.indd 440 6/28/2013 11:21:14 AM
-
Emerging Software Engineering 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 unam-biguous measurements among developers while reusing
components.
Create incentives for individuals/engineers for doing reuse Some
explicit finan-cial 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 techno-logical 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
-
Software Engineering: Concepts and Practices442
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 crosscut-ting 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 asso-ciated 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
-
Emerging Software Engineering 443
AdviceThe 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 when-ever 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 intro-duces
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 imple-ments 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.
AspectAn 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 cross-cutting).
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
-
Software Engineering: Concepts and Practices444
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 exter-nally 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
-
Emerging Software Engineering 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
imple-mentation 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
-
Software Engineering: Concepts and Practices446
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 interop-erable 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 inte-gration 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 service- oriented architecture is shown in
Figure 12.2.
M12_SE_01_M12.indd 446 6/28/2013 11:21:15 AM
-
Emerging Software Engineering 447
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 opera-tions 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
Figure 12.2 Service-oriented architecture
Serviceregistry
Serviceprovider
Serviceconsumer
UDDI
Bind
Search Publish(WSDL, XSD)
M12_SE_01_M12.indd 447 6/28/2013 11:21:15 AM
-
Software Engineering: Concepts and Practices448
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 mecha-nism 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 under-lying
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
-
Emerging Software Engineering 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 architec-ture. 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
-
Software Engineering: Concepts and Practices450
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 speci-fied 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
-
Emerging Software Engineering 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
non-interactive 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 interac-tion 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
-
Software Engineering: Concepts and Practices452
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 tech-nical specifications are
ineffective way of communicating with users. We create prototypes
to test them on the user through usability evaluation techniques.
Proto-typing 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 informa-tion 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
-
Emerging Software Engineering 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
-
Software Engineering: Concepts and Practices454
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 soft-ware 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. There-fore, 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, transfor-mations 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 transforma-tion 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
-
Emerging Software Engineering 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.
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. Computational-independent model (CIM),
platform-independent model (PIM), and platform-specific model (PSM)
are the three model types that have been largely adopted
Figure 12.3 Model-driven architecture
CORBA
UML
MOF XML
Model-drivenarchitecture
Java EE
.NET COM1
Telecom
Healthcare
Applicationdomains
Concreteexecutionplatforms
Modeling standardsand transformation tools
...
eCommerce
Finance
M12_SE_01_M12.indd 455 6/28/2013 11:21:15 AM
-
Software Engineering: Concepts and Practices456
by the software community.29 CIM model is a view of a system
from a computation-independent 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
develop-ment. 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: refac-toring 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
trans-formations convert a model element into a code fragment.
Model-to-code trans-formations 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.2 The 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
Figure 12.4 MDA pattern
Model
Code
Platform-independent model
Platform-specific model
Transformation
e.g., UML, XMI etc.
e.g., J2EE, XML etc.
M12_SE_01_M12.indd 456 6/28/2013 11:21:15 AM
-
Emerging Software Engineering 457
domain experts, platform experts, and application developers to
contribute their respective knowledge independently. An approach to
the model-driven develop-ment 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
compu-tation-independent models (CIM), platform-independent models
(PIM), and platform-specific models (PSM) of the MDA approach.
Figure 12.5 Model-driven development process
Computational-independent model (CIM)
Platform-independent model (PIM)
Platform-specific model (PSM)
Analysis model
Design model
Implementation model
UML, MOF, CWM and XML
CORBA, .NET, or J2EE
Finance, insurance,loan automation, etc. Business and models
System
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 system-atic 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
model-to-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 transfor-mations
are specified using open standards such as CORBA, UML, CWM,
etc.
Model-driven development is faster and has interactive ideas of
software devel-opment. 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
-
Software Engineering: Concepts and Practices458
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, group-ware 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, concur-rent 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. Typi-cally, the interaction of
the client and server processes follows a request-response pattern.
It is shown in Figure 12.6.
Figure 12.6 Client-server interaction
Request
Response
ServerClient
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 compo-nents
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
-
Emerging Software Engineering 459
Two-Tier ArchitectureTwo-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
archi-tecture, 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
data-base management server provides stored procedures and
triggers.
Figure 12.7 Two-tier architecture
Client environment
Client application
Client application
Internet
Database server environment
Database
Database server
Two-tier software architectures are used extensively in non-time
critical infor-mation 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
archi-tecture 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
manage-ment services using vendor proprietary database procedures
restricts flexibility and choice of database management systems
(DBMS) for applications.
Three-Tier ArchitectureThree-tier architecture (also known as
multi-tier architecture) emerged to over-come 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
-
Software Engineering: Concepts and Practices460
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: evolu-tionary approach that mak