International Journal of Engineering Trends and Technology (IJETT) – Volume 18 Number 4 – Dec 2014

Software Engineering Design Issues

1
Soma Akhil, Soma Anvesh2
1
Accenture, India, 2TCS, India
G-15, Krishna Arcade, Nizampet, Kukatpally, Hyderabad, Telangana, India-500090

Abstract— Research in software engineering is concerned with

the automation and the enhancement of the processes of building
some computer related application systems. In this paper, we
mentioned some significant software engineering problems from
the context of developing very large information systems. The
aim of the paper is to investigate applicability of object-oriented
software design patterns in the context of aspect-oriented design.
The main assumption is that there exist design patterns that solve
software engineering paradigm independent design problems
and that such patterns, in the contrast to the patterns solving
paradigm-specific design problems, can be expressed in terms of
any software engineering paradigm.

Keywords- VLSI View point, Software Development issues, System Information Systems Pyramid
evolution, Paradigm problem, Large scale Integration, GoF23
patterns.
The operational scope of the VLIS across different levels can be
characterized as a pyramid structure in business activities. As if we
consider the case with embedded systems, VLIS development is
I. INTRODUCTION
mainly concerned with the performance of software and the
functional complexity. In essence, the complexity of a VLIS is
The ultimate aim of research in software engineering (SE) is rooted in the demographic complexity of the application environment
to improve the quality and productivity associated with both the and the size of the system. SE research therefore needs to contain a
products and processes of software development. The foreseen strong empirical component and should be grounded by data
benefits are improvements in the management of the development generated from the industrial experiences. The formulation of
process, increases in user satisfaction, and the delivery of greater research problems and the strengths and weaknesses of the
functionality to the market place in the form of software and related alternative approaches need to be subjected to the test of time
products. A number of software engineering paradigms, approaches constraints, resource limitations, industrial practices and economic
and methodologies exist today. Although the object-oriented (OO) pressures.
paradigm still remains one of most popular, it is gradually replaced
by the aspect-oriented (AO) because of the concern crosscutting III. Software Development Issues
problem.
This mainly describes some of the issues associated with the
Some of the major problems associated with the automation of software development process in the context of VLIS. Here in each
software development occur with respect to requirements case we define the issues, find the sources of its existence, and
specification, design, reusability, maintenance, validation, discuss the implications of what to do accordingly. And then we see
verification, and testing. The approach to research on the problems of these issues as highly interdependent with other and regard the
software engineering is founded on a different class of application approach to an overall solution as necessarily dependent on
domains; namely that of very large information systems (VLIS). In concurrent development in each and every area.
the following sections we briefly define and characterize VLIS and
the problems associated with VLIS development. The intent is to
contrast the nature of the software development problems. As a A. System Evolution
result we hope to illuminate new perspectives on the software
engineering problem and construct a foundation from which an Currently, the process of maintenance is too often similar to that
integrated, productive research program can be launched for software of patching of software bugs. The software maintainability is
engineering issues in VLIS. assumed wrongly to be a natural byproduct of good systems
development. These perceptions are faulty and thus results to the
maintenance crisis being experienced today. So today in order to
II. VLSI View point support the scope of maintenance, it must be recognized that
software systems need to evolve and that this evolution of systems
cannot be treated in the same manner as initial development.
VLIS are federations of subsystems developed according
to a system wide design plan to provide information to support
The ability to continuously evolve is crucial for VLIS.
the operational, decision-making, managerial and analytical
Information systems are typically a critical arm for the business and
functions of an organization.

ISSN: 2231-5381 [Link] Page 184

 International Journal of Engineering Trends and Technology (IJETT) – Volume 18 Number 4 – Dec 2014
it must adapt continuously to the changing business environment. Design of the software development is categorized by a necessity to
Change is not the exception for these software systems, it is just the deal simultaneously with a large number of diverse constraints. In
norm. Unless they can effectively adapt to the needs of the company, general the design problems are intractable. However, we believe that
the competitive position of the company and the stability will be the combination of the restricted domain of VLIS development, the
jeopardized. knowledge accumulated from the experience of building a large
number of VLIS and the simplicity of its algorithmic requirements
So in order to support system evolution, information required provides good insights into the available expertise, known
during maintenance must be available and processes which directly alternatives and solutions. Mainly our intention is to exploit the
support maintenance must be developed. Taken together, design natural structure in ways that allow us to reduce the complexity of
rationale and the maintenance processes must help the designer (1) the problem to manageable levels. We mention several issues that
understand the structure, functionality and behavior of a system (2) help focus some of the design process concerns.
assess the level of impact of alternative changes, and finally (3)
control of the impact of necessary changes that are made. Of course,
maintainability and the integrity of the system must be preserved. 1) The Paradigm Problem:

The paradigm problem mentions to the failure to develop and

Supporting system evolution must be viewed as a major factor in recognize a productive, manageable, economically feasible process
shaping an approach to formalizing the design process, Maintenance model for SE. Attention has been focused on the development of new
requires more information because an existing system represents a software engineering paradigms, but till now no results have proven
large set of constraints which does not exist during initial design and completely satisfactory for VLIS development. Any successful
the design tradeoffs made during maintenance differ from those in model must deal with the interdependent facts of making design
the initial design process. For example, data structure decisions decisions while recognizing the need for adequate leverage and
maybe driven by efficiency and quality during initial development project management.
but by minimization of impact during maintenance.
2) Bridging the Functional to Technical Gap:
B. Leveraging Expertise and Experience
A notable portion of the design process occurs when
Necessarily large size of VLIS development team members translating the business problem description in to a high level
combine with the relative scarcity of highly experienced builders systems design. Today, the techniques at this level of the
mandate the judicious use of less experienced personnel in most of development process are not clearly understood. The result is we
the phases of development. Leveraging expertise and experience is cannot able to map problem requirements to technical solutions. No
concerned with the ability to successfully complete and manage large good languages have been developed in which the requirements of
software development projects with a relatively small percent of the problem can be expressed and ultimately transformed to technical
highly experienced and proven resources. This is the critical issue solutions.
given that the success of a project development is directly correlated
with the levels of experience and talent across members of the
project team. 3) Design Evaluation:

The main focus of SE research should be on supporting the high So in order to make good design techniques and decisions,
level design activities where the dividing of high level problems into one must have the ability to assess the quality and validity of a
relatively independent components takes place. The simple particular design decision or can able to weigh the relative merits of
functional demands of individual programs allows for their competing design alternatives. The lack of evaluation ability
construction by less experienced members. definitely leads to inadequacies in assessing the impacts of a design
decision on all factors of the design process. Under the umbrella title
C. The Design Process of evaluation we include testing, verification, validation and, as a
specific instance, prototyping.
The design process is the task of generating or creating design 4) The Representation Problem:
byproducts and subsequently refining, evaluating, integrating, and
modifying these byproducts until the final result satisfies the initial
requirements that are taken according to the problem definition. In The representation problem is a elementary requirement for
essence, the design process is the task of mapping problem advancement in each of the areas mentioned above. The issue is the
requirements to design solutions. The design process should be ability to manipulate, express and make inferences about design
guided by a economic, productive and controllable methodology that decisions and processes. Currently, major development takes place at
will ensure a high quality product. very low level design for at least two reasons. Firstly, current
methods of software engineering encourages the designers to think in
terms of low level issues such as data structures, performance
The reasons why the design problem is important are necessary. measures, database, screens, and interfaces etc because these
Good design decisions made early have a positive effect on the representations are the only mechanisms that provide evaluation
efficiency of the development process and the quality of the ultimate feedback and feasibility measures. So as a result designers move to
product. Poor design decisions declines the efficiency, quality and lower levels without adequately investigating alternative early design
cost of the development process and the design products. decisions. Second, the nature of the business is that cost pressures
often do not allow for a need to investigate on high level design

ISSN: 2231-5381 [Link] Page 185

 International Journal of Engineering Trends and Technology (IJETT) – Volume 18 Number 4 – Dec 2014
alternatives. As a result, projects designs are often inadequate and objects to clone its instances (i.e., create several instances of the
easily damaged. same class based on already existing instance). However, in AOP no
one needs to clone the aspects. Even if it is possible to use several
5) Large Scale Integration: instances of aspects per object or per control flow, it is not possible
to control instantiation in the way to support cloning. Thus, Singleton
and Prototype design patterns are senseless in AO paradigm.
The major problems of large scale integration is concerned with Senseless is also the Composite pattern because, in the case of OO
the understanding, usage and exploitation of the functionalities, paradigm, its implementation requires to hold the references from
protocols, standards and communication interfaces of a one to another instance of Composite object. In the case of AO
heterogeneous set of technologies in developing large systems. paradigm, the solution results in an eternal loop when only one
Integration of different component systems differing both in container aspect is defined and this aspect is referenced in a tree at
functionality and platform is important because systems within the least two times.
commercial environment can no longer be treated as isolated entities.
In fact there is great discourage to do so. We use UML class diagrams to model both OO and AO patterns.
To represent aspects in UML models we use stereotypes: Aspect,
The large scale integration problem mainly points out the need to Advice, Pointcut, and Joinpoint. The latter one represents the relation
understand the interrelationships of all systems within a company. between the pointcut, described in the aspect, and its actual
Efforts need to be concentrated on large scale design at the joinpoints in classes. While modelling the AO patterns by UML, we
enterprise, or companywide level before detail design and use the traditional UML relations such as inheritance, association,
implementation of a particular component is undertaken. and dependency. For a better understanding of the diagrams.
Understanding the enterprise level connectivity and integration issues
is extremely important and will have tremendous impact upon the
design process.
V. Conclusions

IV. AO Solutions of Paradigm Independent Design The intent of this paper is to discuss the suggestions that
Problems the process of developing very large information systems (VLIS) has
on the approach to the software engineering problem. Although the
same SE problems are found in many domains, they take on a unique
set of constraints when considered in the context of developing
If GoF23 pattern can be applied in AspectJ by using AO only, it
VLIS. It is our position that possibilities for enhancing the software
can be viewed as a pattern that, respecting for OO and AOP
development process are functions of the domain in which one
paradigms, solves a paradigm-independent design problem. Despite
participates. The paper proposes a classification of the ways of
of it, in such a case, both OO and AO patterns solve the same design
solving design problems using OO and AO design patterns. The
problem, their usage differs. The OO patterns solves this problem for
proposed classification contributes to the better understanding of
objects, whereas the AO patterns solves it for aspects. Let us briefly
relations among the design problems and the design patterns. The
consider the suggested methodology, to rewrite paradigm-
paper proposes also a technique for redesigning object-oriented
independent GoF23 design patterns for aspects.
patterns into pure aspect-oriented ones and demonstrates application
of this technique for the GoF23 design patterns.
If a GoF23 pattern, maybe with a reduced significance, can be
implemented using only singletons, this pattern is considered
as a candidate to be a paradigm independent pattern for References
rewriting in AspectJ.
[1] Craig Gaskell and Armstrong A. Takang,Professional issues in
All the classes in the candidate pattern should be replaced software engineering the werswective-of UK academics
with aspects and all object constructors should be replaced by
the AspectJ static method aspectOf, which allows us to access [2] Zilvinas VAIRA, Albertas C APLINSKAS Vilnius University
the cite of the aspect. Institute of Mathematics and Informatics Software Engineering
Paradigm Independent Design Problems, GoF 23 Design Patterns,
The candidate pattern should be analyzed in order to discover and Aspect Design
and remove irrelevant data members and methods. Some data
members and methods can become irrelevant because the [3] David NotkinAutumn Quarter 2008 Software engineering issues
aspects which replaced the classes are singletons and because
of transformation of some pattern members to fit the point cut
model in the pattern. [4] RICHARD H. THAYER, ARTHUR B. PYSTER, AND ROGER
C. WOOD, Major Issues in Software Engineering Project
Management.
A. Investigation of the Applicability of GoF23 Patterns
to Design the Aspects [5] Jochen L. Leidner School of Informatics, University of
Edinburgh, Current Issues in Software Engineering for Natural
Firstly, let us discuss these GoF23 patterns – Singleton, Prototype, Language Processing.
and Composite – that are pointless in the aspect-oriented paradigm.
The Singleton pattern becomes trivial after rewriting it in AspectJ
and disappears. The essence of Prototype pattern is the ability of

ISSN: 2231-5381 [Link] Page 186