8_m12_se_01_m12_se_research.pdf

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


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


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


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


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


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


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


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


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 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


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


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


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


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


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


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


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


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


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


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


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


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


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 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


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


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


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


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


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


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

8_m12_se_01_m12_se_research.pdf

Documents

software problems

software reusewe

maintainability of software

software industry

software engineering

existing software systems

existing software components

software products m12