Behavior and Structure in Software Architecture

Introduction

Although software architecture has varied definition, it is a core aspect of software. However, the widely accepted definition is by Less Ban (2007) which states that software architecture is the “the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them” (Medvidovic and Taylor 2010). Based on this definition, there are three main aspects of software architecture: a structure or structures, elements, and relationships. A structure is basically a set of components held together by a particular relationship. Software systems comprise of many structures (Mens, Magee and Rumpe 2010). As such, it is not possible for a single structure to be considered the architecture. Each structure comprises of elements which are relate in various ways. The relationships enable the structure to function. Lastly, relationships involve how different elements within a structure and different structures within a system work affect each other and influence how the structure or system functions (Falessi et al., 2011). Since software architecture comprises of structures which are related in various ways and the structures are made of elements, it means that software architecture consists of software elements and the elements have a particular kind of relationship that allows the architecture to function properly (Malka 2011). It also implies that architecture omits particular information about elements which is not important. As such, architecture is an abstraction which chooses certain details and omits others.

Elements in a software system interact through interfaces. The interfaces partition details about the elements into private and public parts. Architecture focuses on the public side. The private details, which are normally concerned with internal implementation, are not architectural. Every software system has software architecture (Rozanski and Woods 2011). Software systems are made of elements and relationships which qualify them as software architecture. However, while every software system is architecture, it does not imply that the architecture must be known. There can be a scenario whereby all individuals who designed a system are gone, the documentation is lost or was never produced, and the source code is lost or was never delivered. Software architecture also includes behavior. The behavior of elements is part of software architecture provided the behavior is used to explain the system (Kang and Hong 2015). The behavior entails how elements interact and affect each other. This implies that box-and-line drawings which are normally considered to be architectures are, in real sense, not architectures.

While there are many structures that make up software architectures, all of them can be categorized into three groups: module structures, component-and-connector structures, and allocation structures. Module structures entail the decisions made on how an architectural system should be structured (Ebrom et al., 2013). Some of the issues module structures address include: the functionality responsibility of each module; the software elements a module should use; the software a module depends on and uses; and the relationship among modules. The component-and-connector structures are concerned with decision on how an architectural system should be structured in terms of elements which have components and connectors (Vogel et al., 2011). Elements in these structures are runtime components, which are principal computation units, and connectors, which are communication vehicles. Some of the issues that component-and-connector structures address include: the main executing components and their interaction, the main shared data stores, the parts of a system that need to be replicated, how data progresses through the architectural system, whether the structure of the system can change and how, and which parts can operate in parallel (Garlan 2014). Lastly, the allocation structures involve the decisions on the kind of relationship a software architectural system will have with non-software structures such as networks, file systems, and CPUs.

After defining and describing each aspect of software architecture, the next question is why software architecture is important. Software architecture is important because of various reasons. One of them is that it influences the ability of a system to exhibit its needed quality attributes. Some of the qualities that desired of s system include high performance, modifiability, security, scalability, and reusability (Qian et al., 2010). The strategies that can be used to achieve these qualities are exclusively architecture. However, it is important to note that architecture alone does not determine the required quality or functionality of a system. Other factors such as poor implementation decisions and downstream design can dent the quality of an architectural design. The decisions made in all stages of a system’s life cycle, starting from deign to implementation, influences the quality of the system (Weinreich and Buchgeher 2012). As such, quality is not entirely a function of architecture.

Software architecture allows an architect and other concerned parties to analyze and manage change. Almost all software systems go through constant change over their life cycle in order to incorporate new features and adapt to new environments (Medvidovic and Taylor 2010). There are three categories of change that software systems go through: architectural, local, and non-local. Architectural change affects the way elements interact. Architectural changes have far reaching consequences on the system in that it may require changes in many areas of a system. Local change is focused on only one element. Local change modifies aspects of an element and does not affect the way the element interacts with other elements in the system (Rozanski and Woods 2011). Lastly, nonlocal change modifies several elements although it does not affect the basic architectural approach. The most preferred change is the local change since its effect is limited.

Making decisions on when there is need for change, determining the strategies to use to effect the change, evaluating the effects of the changes, and determining the priorities and sequences for the changes need insight into behaviors, performance, and relationships of the software elements within a system (Ebrom et al., 2013). Software architecture highlights these behaviors, relationships, and likely performance. It thereby allows one to reason about and manage the required changes.

Software architecture helps in predict the qualities of a system. Software does not only infuse systems with certain qualities, it does this in a way that makes it easy for one to predict those qualities. It is possible to predict the qualities of a system by simply evaluating its software architecture (Garlan 2014). Consequently, it is possible for an architect or any other concerned party to make architectural decisions that are aimed to infuse particular qualities in a system. Software architecture also allows one to determine whether certain decisions on quality have been made and depending on how they have been made, one is able to confidently predict the kind of qualities a software system will exhibit (Kang and Hong 2015).

Software architecture also enhances communication among stakeholders. Software architecture is a common abstraction that can be used by most of the stakeholders involved with the system for developing mutual understanding, communicating with each other, and forming consensus (Vogel et al., 2011). Most parts of architecture are abstract enough to make it possible for nontechnical individuals to understand it well (Qian et al., 2010). On the other hand, it is possible to refine the abstraction into technical specifications that can guide implementation.

Different stakeholders are concerned with different aspects of the system. For instance, users are normally concerned with reliability, speed, and availability (Rozanski and Woods 2011). On the other hand, the manager is usually concerned with cost and schedule. Software architecture acts as a common language through which the various concerns are expressed, analyzed, and resolved. Without software architecture, it is hard to achieve both usefulness and quality in a system.

Software architecture also carries the early design decisions made about a system. The early decisions have a huge influence with regard to development, deployment, and maintenance of a software system (Medvidovic and Taylor 2010). Architecture also provides an opportunity for the scrutiny of the early decisions made about a system. Any design in whatever discipline is normally a set of decisions. For example, before creating a work of art, an artist must make decisions about the material to use, the size of the work, the color, and so on. These decisions must be made before the work is started (Mens, Magee and Rumpe 2010). Similarly, and architecture design is a set of decisions which are implemented later during the development of the system. The early decisions limit the decisions made later within a particular scope. One can thereby determine the early decisions made about a system and assess whether they were good.

However, there are a number of problems stakeholders encounter with software architecture. For example, software architecture is not explicitly shown in the code. In addition, the continuously evolving in technologies change the system so the architecture for the system changes too (Malka 2011). The incorporation of new technologies results in significant changes in the initial design. It is thereby hard to analyze a system using the initial architecture. Lastly, software architecture is rarely documented in a proper manner so conceptual architecture no longer represents the true nature of its implemented one (Weinreich and Buchgeher 2012). All the above issues make it hard to change or upgrade a software system. There is thereby the need get for architecture recovery to recover the architecture from source code.

The architecture can be lost with development especially that MSA are operated by multiple teams and disciplines. Moreover, these architectures also follow evolutionary design, which is very hard to manage, govern and keep track of the architectural constraints that may be put in place by architects. A solution to these problems would be to recover the architecture of existing micro service system systems to allow developers understand their implemented structure .However, while the existing Architecture Recovery approaches provide support for object-oriented systems, it does not support emerging micro-service architectural style.

References

Ebrom, M.P., Glotzbach, M.E. and Mccoy, R.A., Whirlpool Corp, 2013. Software architecture system with embedded virtual router. U.S. Patent 8,621,049.

Falessi, D., Cantone, G., Kazman, R. and Kruchten, P., 2011. Decision-making techniques for software architecture design: A comparative survey. ACM Computing Surveys (CSUR), 43(4), p.33.

Garlan, D., 2014, May. Software architecture: a travelogue. In Proceedings of the on Future of Software Engineering (pp. 29-39). ACM.

Kang, T.W. and Hong, C.H., 2015. A study on software architecture for effective BIM/GIS-based facility management data integration. Automation in Construction, 54, pp.25-38.

Malka, L., 2011, October. Vmcrypt: modular software architecture for scalable secure computation. In Proceedings of the 18th ACM conference on Computer and communications security (pp. 715-724). ACM.

Medvidovic, N. and Taylor, R.N., 2010, May. Software architecture: foundations, theory, and practice. In Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 2 (pp. 471-472). ACM.

Mens, T., Magee, J. and Rumpe, B., 2010. Evolving software architecture descriptions of critical systems. Computer, (5), pp.42-48.

Qian, K., Fu, X., Tao, L. and Xu, C.W., 2010. Software architecture and design illuminated. Jones & Bartlett Learning.

Rozanski, N. and Woods, E., 2011. Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley.

Vogel, O., Arnold, I., Chughtai, A. and Kehrer, T., 2011. Software architecture: a comprehensive framework and guide for practitioners. Springer Science & Business Media.

Weinreich, R. and Buchgeher, G., 2012. Towards supporting the software architecture life cycle. Journal of Systems and Software, 85(3), pp.546-561.