Here the overall logical and runtime view of the framework is defined

Here the overall logical and runtime view of the framework is defined for easy understanding of architecture.

Figure 9 describes the logical view of the architecture considering all the 11 characteristics and contains five of the 11 characteristics in it. In the interdependence between modules, the dependencies are modified with newer versions. There are different layers at which modifications take place which is shown as part of Levels. There are many legacy structures having different kinds of connection between parent, child, and interfaces. Module communication are also defined prior to the execution, and original architectures have factors like re-adjustment of the file system, operations on folders to change security permission or anything, using third-party libraries can also create dependencies in the code.

Get quality help now

Prof. Finch

Verified writer

Proficient in: Computers

4.7 (346)

“ This writer never make an mistake for me always deliver long before due date. Am telling you man this writer is absolutely the best. ”

+84 relevant experts are online

Hire writer

Figure 10 describes the dynamic decision-making strategies that need to be used in the attributes inscribed in it. Regulated flow processing contains control unit processing, updates of IO values, IO format updates, modifications in connections links and modifies external interfaces. All of these needs to take dynamic decisions while execution of the program and cannot be embedded statically in the code. It is harder to trace the root cause in case of dynamic models, since values changes at runtime and there can be a chain of attributes that have caused the breakdown of the system. Simultaneous refinement needs a different kind of parallelism techniques like data parallel, task parallel, etc. Threads are used for multitasking, but care needs to be taken about the synchronization techniques and connection sharing problems since an only limited number of threads are allowed to access the databases simultaneously.

Dispersed modules lead to performing the computations at distinct locations in parallel by passing the required data to the machines. It uses the concept of peer-to-peer network, client-server architecture, and various protocols and communications mechanisms supporting this. Database access also creates the connection dynamically using connection strings. Adding accessor type, changes in access privileges, modifying attachments, modifying repositories are a common task performed on any database management systems. As the computation is becoming desperate the module communication needs to be adjusted to carefully utilize the bandwidth of the network. Whenever a new node enters into the network alert is send to all other nodes regarding the event. Listeners keep on listening to a specific port waiting for the completion of the event. Nodes can register for new events and deregister from old events after its completion. Module deployment basically deals with the hardware and location parameters of the cluster.

Let us describe the whole process of creating a framework and how organizations can use it to create a consensus along with no degradation in the architecture. Figure 11 is described here. Changes can be directly or indirectly from any real-world entity. Those desired changes will be given to the change impact analysis framework. First, it will see what is the impact of the change on the Inspiration characteristic. It will have to pass the test, else if it causes severe changes by the root causes of these characteristics, this change should roll back and developers should try to find a better alternative for the same. Similarly, it will pass through origin, significance, developer experience, change extent and attribute. Then it can be either of the four forms: logical, runtime, characteristics and quality. The final cumulative result from the framework will be provided to the analysis module, where it will assess the change impact. The output of this module will give a full description of what is affected, how much it is affected, along with the explanation of the nature of change and its root causes, and then gives a suggestion whether this change should be committed or not. As changes keep on arriving for various reasons like user requirements, bugs, etc, this cycle keeps repeating. All of these makes it easier to understand the phenomenon along with all developers able to agree on a valid decision.