Home About IUP Magazines Journals Books Amicus Archives
     
A Guided Tour | Recommend | Links | Subscriber Services | Feedback | Subscribe Online
 
The IUP Journal of Systems Management :
Influence Factors for Software Architecture of Object-Oriented System
:
:
:
:
:
:
:
:
:
 
 
 
 
 
 
 

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 stakeholders—clients, developers and management people, who have their specific requirements—and 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'.

 
 
 

Influence Factors for Software Architecture of Object-Oriented System,system, development, architecture, requirements, processes, objectoriented, domains, characteristics, standard, applicable, developers, influence, Jacobson, architectural, nonfunctional, complete, communicate, explicitly, flexible, structures, Unified, domain, engineers, environment, Colemann, Ambler, functionality