Analysis of “Modifiability” in Software Systems

ABSTRACT:

Quality attributes are responsible for the quality of the system. Quality is often categorized based on attributes that are system properties or software properties. The quality-attribute evaluation of software architectures is recognized as an important activity to mitigate risks, evaluate design alternatives, and avoid costly implementation commitments. Modifiability is a quality attribute that refers to the ability of a given system to accommodates changes. The paper addresses and analyzes the internal potential problems due to modifiability using scenario-based analysis. A structured polyglot model for scenario based architectural analysis is presented and analyzed with respect to applying modifiability tactics. The end results are the architectural constraints observed and analyzed and how well these tactics apply to a real time software model

Keywords: Software Architecture, Quality Attributes, Modifiability, Software Architectural Analysis, Applications of modifiability tactics

INTRODUCTION:

In software architecture, elements are divided into functional and non-functional piece blocks. Some non-functional requirements tend to be expressed in terms of quality attributes. A quality attribute is a measurable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders. Modifiability, as a quality attribute in software systems is the extent to which it can be modified efficiently with minimal tradeoffs and defects that affect the architecture of the system. Modifiability is also a design quality attribute of a system and is closely related to maintainability and cost of the software system as a modification of an element at any part of the system can have an adverse effect on other elements in the system. These are termed as “modifiability effects” which are the consequences of change in the architecture of the system. An ideal software system would be a one that can accommodate these changes and deal with these consequences in a reasonable manner that minimizes the cost of change.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Essay Writing Service

This brings us to important architectural tactics in aspects of modifiability. An architectural tactic is a design decision that influences the control of a quality attribute response. Tactics provide a means of how to control various elements or parameter components in a system to improve the response and behavior. A collection of these architectural tactics would be considered an architectural strategy.

Project I choose to apply modifiability on:

Open Source Management:This project provides a Software Platform for local businesses to register with a central authority ”the platform” and sell their merchandise to registered customers by delivering the products to user-inputted addresses. Consumers of the platform can browse local businesses that are registered and select products to be delivered to a location of the user’s choosing.

How this project differs from other platforms:

This is different from other in market competitors in that the cost of delivery and operation is spread fairly amongst the consumers with each order. The software platform will support business administration of merchandise and information and consumer registration solely depending on the microservices for additional functionality.

LINK: https://github.com/CCorrado/ssw690ossmgmt

“Modifiability” impact on the project: The platform follows a distributed microservices based architecture wherein new elements of functionality can be implemented and incorporated into the polyglot software platform. There would be several factors influencing this implementation of new additional functionalities which I choose to address on in later parts of the paper.

ANALYSIS OF MODIFIABILITY TACTICS:

The goal of modifiability is to control the complexity of making changes as well as the time and cost to make these changes. To do so, there are certain established practices and architectural tactics to be followed:

• Reduce size : Splitting larger modules into smaller parts always makes change easier. This makes identification of the piece parts that have been changed easier and reduces complexity in complex. This refers to the decomposition of various elements of the components into structural piece parts that achieve maintainability.
• Localize Changes (increase cohesion): Cohesion refers to the measure of how well the software module fits together. It is a measure of the degree to which the elements of the module are functionally related and to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion.
• Increase semantic coherence: This may involve creating a new module or it may involve moving a responsibility to an existing module

The eventual aim of localizing changes would be to restrict modifications to a small set of modules to reduce the cost. This can be done by assigning responsibilities to modules such that the results of any change are anticipated. Example: If  modules have 2 responsibilities that don’t serve the same purpose,  these responsibilities should be split across various other modules

• Prevent Ripple Effects (reduce coupling) – Coupling is defined as the extent to which a system, subsystem, method or module connects with (depends on) others. In other words, it measures interdependency. In general, a ripple effect is the metric that shows what impact the changes to an underlying software system will have on the rest of the system. Encapsulation, isolating changes within one module and preventing changes from propagating to others and proper design strategies for the interface are some techniques for preventing ripple effects to a software system.
• Encapsulate: Encapsulation reduces the probability that a change to one module propagates to other modules. The strengths of coupling that previously went to the module now go to the interface for the module
• Use an intermediary: The purpose of using an intermediary is to reduce the reliability of dependencies. The type of intermediary depends on the type of dependency which can be either a data dependency or a service dependency. The data repository such as a database acts as an intermediary between the producer and consumer of data, If This Then That, an online platform that lets you connect different applications, acts as a service intermediary between several systems and translates actions and data from one system to the other.
• Restrict dependencies: Restrict dependencies is a tactic that restricts the number of modules a given module interacts with or depends on.

In practice, this is achieved by restricting a module’s visibility and by authorization.

• Refactor:  Refactor is a tactic undertaken when two modules are affected by the same change, because they are at least partially duplicates of each other. This restricts the modules that a given module interacts with or depends on. This tactic is often applied when you create architecture in an incremental way
• Abstract common services: This tactic is used to make sure you’re not duplicating functionality and responsibilities. In a situation where similar services are needed; you can often implement them only once in a slightly more general form so they can be reused by others.
• Defer Binding-time– These are tactics that deal with cost considerations. This follows the principle that the later the modification occurs in a software system, the lesser the modification costs incur. For this tactic to be implemented a “suitable preparation” must be implemented that distinguishes a planned change form an unplanned one. Ideally, the change to be implemented must be planned beforehand and the release must be suited accordingly. Bonding parameters at a later time,  gives flexibility in later stages.

With the following being said, one can come up with a robust tactic to sustain and balance as many reusable components in a software system from the development of the architectural state. Creating these components would increase the functional flexibility of a project and make it scalable to needs of changes implemented.

ANALYSIS OF MODIFIABILITY TACTICS:

Analysis of quality attributes is an important aspect to inspect the quality of a system based on its architecture. They can be broadly classified based on “external” and “internal” analysis methods. The purpose of external analysis of quality attributes is to keep track of the project and test it overall whereas the internal analysis can be carried out by an architect in the earliest stages of devising a plan suitable to change for the software to be built upon. The paper tangents around these internal attributes of the project proposed above and gives a brief structural analysis of evaluating modifiability tactics.

The evolution of software over time is one of the main reasons for modifiability in a software system. The approach of implementing the following modifiability tactics addressed above is to ease the software system into accepting these changes. Analysis of modifiability tactics would be structured to predict future changes and would thus revolve around the changes of what might change in a software system, ,the functions, platforms and the environment impacts the change brings, the cost of change and implicit business concerns which concrete the change.

In order to analyze modifiability tactics, I choose to proceed with a scenario-based analysis of my project and classify the elements. Ideally, the piece parts of a scenario would be divided up into 6 main classifiers based on priority of the components in a system. They are : Source, Stimulus, Environment, Artifacts, Response and Response Time.

SOURCE:This would refer to the developer, system administrator or an end user who can request or introduce change to a system

STIMULUS:This would refer to the conditions that a change would bring to an existing system.

ENVIRONMENT:The condition of the software system in which the stimulus occurs is categorized as the environment of the system.

ARTIFACTS: This refers to the code, data, interfaces and the components of the system with their resources and configurations.

RESPONSE:The activity of the system with arrival of the stimulus and how it reacts to the change would be considered as the response.

RESPONSE MEASURE:The degree to which a response occurs in accordance with the stimulus should be scalable and this is termed as the response measure.

With the following criteria, a scenario-based evaluation for the various components and their interactions can be implemented in the following Open source project mentioned above.

SCENARIO BASED EVALUATION:

Scenarios have been widely used to gather requirements and to choose design attributes for a software model. The process of analysis and design reflect how well a software system is structured and scenario-based evaluation techniques provide a deeper understanding to enable a robust system susceptible to modifiability.  Scenario based analysis provides a way to structurally decompose elements in a software system  to provide a comprehensive understanding of concurrency, response times and their dependencies. Moreover, it is the base on which the software architecture may be built for a system and clarifies the architectural drivers and describes the operation of the system. It can be said as the architectural vision of the software system.

This paper aims to determine a criteria level for the detail of the architectural representation. The reason for choosing scenario-based analysis and change scenarios is because they are usually very concrete and provide a detailed analysis about the impact.

Listed below are five scenarios(based on prioritization) from the project and their ease of modifiability on the software system:

Scenario 1: Change UI code at design time

Scenario 2:  Initiate orders for business(for large number of users -1000/minute)

Scenario 3: Restrict  and differentiate user/admin access to modify the system (Security issues)

Scenario 4: Cancellation of orders from Business

Scenario 5: Error handling and availability of the system in case of failure

The evaluation of the following scenarios was then prioritized to identify the ones that are important to refine and tackle. This was done to create a general overview of the priorities and the architectural requirements for the project. The goal of refining these scenarios would be to structure the requirements about quality.

DISCUSSION AND RESULTS:

ACHIEVING MODIFIABILITY TACTICS IN THE SOFTWARE MODEL:

The architectural style implemented for the software model mentioned above is distributed in nature and follows a microservices pattern. Ideally the constraints faced in the model would emerge from the inclusion of additional functionality provided by the microservices to the existing platform.

REDUCE SIZE: The distributive nature of the project helps for the easy decomposition of the software models into piece parts and enable an easier breakdown of the interactions between the models.  This was achieved in the project by restricting modifications to small sets of modules(microservices), keeping the rest of the services as a skeletal backbone.

INCREASING SEMANTIC COHERANCE (LOACLIZE CHANGES): In the following model, the roles and responsibilities of the software system assigned at each level would increase the degree of cohesion, thus rendering a model effective to change. This is implemented in the following by routing the functionality across microservices. The microservices are constructed in a distributive manner and enable developers to create instances of the number of services to be provided.

In our system, this can be achieved as the change in the module that is responsible for the orders and business should affect the modules that is responsible for user analytics. We want low coupling between these two modules.

This results in an efficient use of non-overlapping functionality across functions or methods in the same class.

REDUCE COUPLING (PREVENTING RIPPLE EFFECTS):

Encapsulation in the project enables for reducing coupling. This is done by implementing the API with transparency through the microservices. The elements in the software system can directly interact with various modules through this interface. Also, by the se of wrappers, external entities can only see (but depend on the microservice) for the internal functionality of the domain.

Use an intermediary: The API Gateway us an intermediary with minimal routing capabilities in the project. This is used as the transporter in the entire project with the microservices being the brains behind it. In general, using the API Gateway allows one to consume a managed API over REST/HTTP. These would target multiple internal microservices for a single request from a user and thus reduces latency.

Restrict Dependencies: To prevent changes from propagating to other parts of the system, the model proposed above created a separate new instance of the class that is to be created. For existing changes to the class, the model uses data that is in multiple locations for data localization (Database).

Refactoring: Refactoring is done across various parts of the software project by the type-system and the compiler. Sharing and extraction of microservices is done for one service at a time by the use basing our microservices migration on a bounded context with respect to the domain

Abstract common services: This tactic is used to make sure you’re not duplicating functionality and responsibilities. A centralized functionality of a domain system such as order and business viewing platforms in the project was implemented and all the elements in the software would know the contents and structure of this to implement further actions on this.

Defer Binding Time:This tactic was implemented in the following software system by binding values at deployment time using configuration time binding. This provided us with flexibility of endpoint services and behavior data at deployment. This provides us to deploy endpoint services at the later stages as we would give permission to the administrator to deploy changes after creating a service.

By implementing the following tactics, we were able to manage and develop a software platform which could accept changes in a distributed fashion.

USE CASE PRIORITIZATION:

Use cases were jotted down, prioritized and built in the following manner on GitHub:

The project made sure abstraction and localization of users and business owners were in order.

ADDITIONAL TACTICS WHICH COULD HAVE BEEN IMPLEMENTED:

• One of the interesting features to of applying a modifiability tactic to a system to estimate its evolvability. This is a future concern for many  projects especially in its early stage of architectural development.
• Another useful tactic to be implemented would be building out the microservices functioning on the API. This would be a faster method and approach, but completely ignored the concept of our project being more focused on order, inventory and business management.
• More focus on the refactoring techniques to untangle class associations and improve the portability could have been achieved

RISKS AND OBSTACLES:

This is implemented in an automated CI/CD pipeline (GitHub) was used from the beginning and made development setup easier. However, risks would arise due to the complete automation of these entire setups as ripple effects would tend to be unrecognized in the polyglot software model mentioned above. Moreover, open source makes it a harder factor for integrations of the project.

Also, abstraction of common services was a minor issue as the elements were evenly distributed across the platform. In order to improve the speed or retrieval, some functionality in the database was implemented by the front-end.

CONCLUSION:

In this paper, an approach to apply the tactics revolving around modifiability, their analysis by the use of use of scenario-based evaluations and further additional tactics to be implemented and their risks were discussed. Using the modifiability tactics in the following microservices architecture, the maintainability, lines of code and code coverage were effectively measured and maintained. The respective tactics were organized in sets according to their goals. The following software model was designed and implemented through the tactics.

REFERENCES:

1) Analyzing Software Architectures for Modifiability – PerOlof Bengtsson* , Nico Lassing**, Jan Bosch* and Hans van Vliet**

2) Modifiability Tactics:  Bachmann, Felix ; Bass, Len ; Nord, Robert

3) Evaluating the Modifiability of Software Architectural Designs – Günther Ruhe, Mikael Lindvall

4) Illustrating Software Modifiability — Capturing Cohesion and Coupling in a Force-Optimized Graph– Johannes Holvitie ; Ville Leppänen

5) Experiences with ALMA: Architecture-Level Modifiability Analysis Architecture Analysis Experiences Nico Lassing* , PerOlof Bengtsson**, Hans van Vliet* and Jan Bosch***

6) Architectural modifiability considerations for designing a multi-device web application platform: Heiko Desruelle∗ , Frank Gielen

7) Designing Modifiability in Software Architectures – Flavio Oquendo, Jair Leite, Thaís Batista

8) Scenario-Based Analysis of Software Architecture: Rick Kazman, Len Bass, Gregory Abowd, Paul Clements

9) ASAAM: aspectual software architecture analysis method: B. Tekinerdogan

10) A survey on software architecture analysis methods: L. Dobrica ;E. Niemela

11) Computing Ripple Effect for Object Oriented Software: Haider Bilal , Sue Black

12) Scenario-based requirements analysis techniques for real-time software systems: A comparative evaluation: Hossein Saiedian,  Prabha Kumarakulasingam, Muhammad Anan