Lecture
The level of development of modern technology is so high that it makes it possible to build an IS of any scale, complexity and functionality. However, given business requirements based on the indicators of various business assessments, additional difficulties arise, and resolving them comes down to ensuring a rational approach to the process of designing, implementing and subsequently operating an IS.
Proceeding from this, the chosen architecture can unequivocally be regarded as one of the main indicators of the effectiveness of the IS being created and, consequently, of the success of the business.
The architecture of an IS is its concept, which defines the model, structure, functionality and interrelation of its components.
By the architecture of software systems we shall understand the set of decisions regarding:
- the organization of the software system;
The architecture of a software system covers not only its structural and behavioral aspects, but also the rules and possibilities of:
The concept of the IS architecture should be formed as early as the feasibility study stage and should be chosen so that the cost of ownership is minimal.
As part of architecture development, the following are defined:
For the architecture, the following are defined and described
When considering the architecture of large organizations, it is customary to use the notion of «enterprise architecture». It can be represented as a combination of several types of architecture [22]:
The enterprise architecture model is shown in Fig. 3.2.
Fig. 3.2. Enterprise architecture model
Technical architecture is the first level of an IS architecture. It describes all the hardware used in performing the declared set of functions, and it also includes the means of providing network communication and reliability. Technical architecture specifies peripheral devices, network switches and routers, hard drives, RAM, processors, connecting cables, uninterruptible power supplies, and so on.
Software architecture is a set of computer programs intended to solve specific tasks. This type of architecture is needed to describe the applications that make up the information system. At this level, software interfaces, components and behavior are described.
Data architecture combines both physical data stores and data management facilities. In addition, it includes logical data stores, and if the company in question is oriented toward working with knowledge, a separate level may be distinguished - knowledge architecture (Knowledge architecture). At this level, logical and physical data models are described, integrity rules are defined, and constraints on the data are established.
The IT architecture level should be singled out in particular, since it is the connecting one. It is where the basic set of services is formed that are used both at the software architecture level and at the data architecture level.
The main function of IT architecture is to ensure the operation of important business applications in order to achieve the stated business goals. If a certain function is required in several applications at once, it should be moved to the IT architecture level, thereby increasing the integration of the system and reducing the complexity of the application architecture.
The last in the hierarchy is the level of business architecture, or business process architecture. At this level, business strategies, management methods, organizational principles and the key processes of enormous importance to the business are defined.
Microarchitecture and macroarchitecture. The terms microarchitecture and macroarchitecture are used to a greater extent to describe software systems. In accordance with the model of IS architecture levels considered above, microarchitecture can be assigned to the levels of software architecture and data architecture, and macroarchitecture to the level of IT architecture.
Microarchitecture describes the internal design of a particular component or subsystem, whereas macroarchitecture describes the design of the entire IS as a combination of its components or subsystems.
The complexity of software systems is constantly increasing. This is due to the growth in the volume of information transmitted and processed, the growing complexity of the information processing tasks themselves, and the increase in the number of such tasks. Without applying some architectural approach when building complex systems, their creation, maintenance and modification will ultimately become unprofitable for the business.
Thus, when developing a software system - for example, one that is part of the infrastructure of a large organization - it is represented as a set of modules, each of which performs a particular function, while together they perform the functions of the system itself. In this case, the organization of each module will be the microarchitecture, and the ways the modules interact within the system will be the macroarchitecture.
A reduction in the complexity of implementing the system is achieved by breaking complex tasks down into several simpler ones. As a result, this may lead to the emergence of a large set of simple tasks on the basis of which any task, even a very complex one, can be implemented.
There are two principles that make it possible to assess the mutual influence of system components on one another:
The Low Coupling principle promotes the distribution of functions among system components in such a way that the degree of coupling between them remains low.
The degree of coupling (coupling) is a measure of the interdependence of subsystems. This principle is related to one of the fundamental principles of the systems approach, which requires minimizing information flows between subsystems.
A subsystem with a low degree of coupling (or loose coupling) has the following properties:
The High Cohesion principle, in turn, specifies the property of strong cohesion within a subsystem. As a result, the subsystems turn out to be focused, manageable and understandable.
Cohesion (functional cohesion) - is a measure of how related and focused the functions of a subsystem are. A subsystem has a high degree of cohesion if its functions are closely related to one another and it does not perform large amounts of work.
A subsystem with a low degree of cohesion performs many different functions that are in no way related to one another. It is undesirable to create such subsystems, since they give rise to the following problems:
Subsystems with a low degree of cohesion have no clear functional purpose and perform functions that are too disparate and could easily be distributed among other subsystems.
It should be noted that coupling is a characteristic of the system as a whole, whereas cohesion characterizes an individual subsystem.
Coupling and cohesion are system-wide characteristics and can be applied in the design of any systems.
Among the platform solutions for designing an IS architecture, the following stand out:
It should be noted that, like any classification, this classification of IS architectures is not absolutely rigid. In the architecture of any particular IS one can find the influence of several general architectural solutions.
Most IS design processes involve drawing on experience from implementing similar projects. It is hard to imagine a system for whose implementation it would be impossible to apply ready-made solutions or the experience gained in creating them.
An architectural style can be characterized as a similarity in the approaches to accomplishing the tasks at hand that is grounded in experience. It defines the list of system components and the ways and conditions of their interaction. Architectural styles are divided into the following five groups (Fig. 3.3).
Fig. 3.3. Classification of architectural styles
In batch sequential processing systems, the task to be solved is divided into a set of subtasks whose solution mechanisms are implemented in separate software modules combined into a linear structure. The output data of one subtask is the input data for another.
The «pipes and filters» style can be considered a generalization of batch sequential processing. Its structure consists of a set of modules, each of which performs one or more processes. The results of one process can be passed to one or to several modules, and in various ways. Such systems implement the pipeline principle, in which feedback loops may be present.
A good example of this approach is a compiler, which sequentially performs lexical analysis, semantic analysis, optimization and code generation.
Systems that operate by means of calls with returns are synchronous software architectures whose client side suspends operation while the server services its request. Such architectures can include an arbitrary number of nesting levels. There are several types of systems of this kind:
The «main program and subroutines» style is an implementation of the ideas of structured programming and implies the presence of a main controlling program (a controller) responsible for the operating process, and a set of subroutines that implement the functionality. A variety of this approach is considered to be the «master-slave» architecture (Master-Slave Architecture), in which the main program and the subroutines run at the same time (in parallel). The controller acts as the process dispatcher, while the subroutines carry out assignments and, upon completing them, request new ones from it.
Object-oriented systems are a special case of «main program and subroutines» systems. Communication between objects, which include (encapsulate) code and data, is carried out either through procedure calls or through messages. It should be noted that the calling object must know where the called object is located; in addition, it needs to know the set of interfaces it can use. Encapsulation hides the details of an object's implementation, as a result of which it becomes possible to make changes to it without notifying end users, which is an indisputable advantage of this type of architecture. Its merits also include natural support for parallelizing processes.
Client-server systems can also be considered a special case of the «main program and subroutines» style, with the sole difference that the controller and the subroutines may be located on different network nodes.
For large-scale systems, the hierarchically layered style is used, in which each of the existing layers can be regarded as a set of services for the layer above it. Accordingly, the upper layer is the client and the lower layer is the server. This style is justifiably used to create protocol stacks or operating systems. Its main advantage is the ability to develop each of the layers independently. It is worth noting that not all algorithms can be implemented as a layered structure, so its use is not always justified.
Systems that operate on the principle of independent components use a mechanism of implicit invocation of operators, i.e. the interacting operators can work independently and be located on different network hosts. Two types of such systems are distinguished:
- systems of communicating processes (Communicating Sequential
Processes);
- event-based systems (Event-Based Systems).
The main operating principle of communicating process
systems is the exchange of messages between independent processes.
In event-driven systems, processes are started only at the moment a particular event occurs; however, the recipient of the event message may not know about the sender, nor the sender about the recipient. Interrupt-driven systems have similar operating principles.
When a system has a publicly accessible centralized information store, it is classified as the centralized data (repository) style. With this approach, data is entered into the system once and supplemented as needed. This provides shared access to the data by several applications and the ability to exchange data, eliminates duplication and simplifies scaling. There are two varieties of such systems:
Systems built on the blackboard principle are characterized by the presence of a common shared memory (a database) that stores the results of the actions performed by the processes. In such systems it is possible to notify interested processes of changes in the information they require.
Virtual machines are special emulators that provide a software interface different from the one in use. Virtual machines can work directly with the hardware platform or be add-ons to the operating system. If an IS is viewed as a layered structure, the virtual machine will be the top layer, providing interaction with user applications, which include:
Interpreters are intended to ensure the operability
of various kinds of programs originally created for different platforms. For example, running and debugging Linux applications in a Windows environment.
Rule-based systems represent all data and logic as a set of specialized rules. In such systems, for each task there is a set of facts and a set of rules. To solve the task, the rules are applied to the facts until a result is obtained. An example of such systems is CLIPS.
The suitability of using various architectural styles is given in Table 3.1.
Table 3.1
Suitability of applying the styles
|
Style name |
Suitability of application |
|
Batch sequential |
The task to be solved can be divided into subtasks that use a single input-output operation |
|
Pipes and filters |
The task-solving process can be represented as a sequence of repeating operations on independent data of the same type |
|
Main program and subroutines |
A fixed order of operations, idle time due to waiting for responses from components |
|
Object- oriented |
The ability to use inheritance mechanisms, placement of objects on different hosts |
|
Client-server |
The ability to represent the task to be solved as a set of requests from clients to the server and responses |
|
Hierarchically layered |
The ability to represent the task as a set of layers with defined interfaces, the need for various options for implementing business logic, portability, use of existing implementations |
|
Communicating processes |
The mechanism of interaction between processes is message exchange, the volume of long-term centralized data is small |
|
Event-driven |
Asynchronous operation of the system, the system can be represented as independent processes |
|
Centralized database |
A DBMS is available, tasks are divided into producers and consumers of data, the execution order of components is determined by the sequence of incoming requests |
|
Blackboard |
A large number of clients communicating with each other |
|
Interpreter |
There is a need to smooth out platform specifics and to provide a specific working environment |
|
Rule-based |
The solution of the task can be represented as a set of rules and the conditions for applying them |
Comments