The architecture of a software system plays an important role especially in the partial modification and reusability of the software. A number of standard processes, techniques and methods are available for the development of a complete software system. Though some of them describe the software architecture during the development of the software, most of them do not explicitly apply architecture. Hence, it becomes very difficult to modify or reuse the software system. This paper describes the important factors, called the influence factors, developed especially for the use of object-oriented concepts. The paper also discusses the important influence factors which are driven from the problem domain.
The
software architecture of a program or computer system, as
defined by Bass et al. (2003), is the structure or
the structures of the software system, comprising components,
their properties and relationships. This is generally used
to handle and communicate the complexity of software system
structures. As software architecture has not been explicitly
described in the standard Object-Oriented methods and processes,
it is seen as a difficult concept to comprehend and communicate.
One of the important reasons for having insufficient focus
on architecture is related to the generality of the object-oriented
methods and processes. Though most authors claim that it is
applicable in all domains, it has been observed that different
domains have different characteristics and requirements to
fulfill, and thereby, the necessity to use different architectural
solutions and patterns. If a general method or process should
handle all combinations of characteristics and requirements
and their related architectural solutions and patterns, the
general process will be complex; for example, the Rational
Unified Process (RUP), which is applicable in all domains.
Object-oriented software development systems are developed
by using object-oriented languages, and the object-oriented
methods and processes such as the RUP (Wirfs-Brock et al.,
1990; Rumgaugh, 1991; Jacobson, 1992; Colemann, 1994; Jacobson,
1999; Booch, 2000; RUP, 2003; Kruchten, 2004; Nalbone, 2004;
and Ambler and Visdos, 2005). A primary goal of the RUP is
to support software engineers working with Unified Modeling
Language (UML) (Rumgaugh, 1999), which, according to Schewe
(2001), is a "modern dinosaur". Though RUP claims
to be applicable in all systems, Michael et al. (2006)
feel that it is not flexible enough for a software development
environment. Craig Larman et al. (2001) feel that RUP
is a confusing development process. According to Michael Harris
et al. (2006), from the developer's point of view,
RUP is not a flexible process. It can be as rigid as a formal
waterfall approach. Jackson (1995) argues that development
methods should not only reflect the system characteristics,
but also the problems of the system. Software developers often
follow standard object-oriented methods or processes for software
development, resulting in a system that fulfills the requirements
of functionality, which, though important, is not sufficient,
as stakeholdersclients, developers and management people,
who have their specific requirementsand organizations
are interested in the construction of a complete software
system. Hence, the object-oriented software systems are also
expected to achieve non-functional requirements. The functional
and non-functional requirements of all the stakeholders of
a system are referred as `system requirements'. |