Software structure

The set of programs designed to solve problems on the SVT and in the AU is called software (SW). The composition of the CBT and AC software is called software configuration. Software can be divided into 3 categories:

  • system software (public programs) that perform various auxiliary functions, for example, making copies of the information used, issuing reference information about the computer, checking the performance of computer devices, etc .;
  • application software that ensures the performance of the necessary work on a PC: editing text documents, creating drawings or pictures, processing information arrays, etc .;
  • instrumental software (programming systems), providing the development of new programs for a computer in a programming language.

Protection of the first category of software is implemented by built-in protection means and will not be considered within the framework of this topic. For CBT and AS to continue to exist, their software must provide the necessary performance, be of good quality and be affordable. All of these parameters are influenced by the architecture and structure of the software.

Architecture is the basic organization of a system, embodied in its components, their relationships with each other and with the environment, as well as the principles that govern the design and development of the system.

Architecture is a set of significant decisions about the organization of a software system, a set of structural elements and their interfaces with the help of which the system is assembled, together with their behavior determined in the interaction between these elements, the arrangement of elements into gradually enlarging subsystems, as well as an architecture style that directs this organization – elements and their interfaces, interactions, and layout.

The software architecture of a system or set of systems consists of all the important design decisions about program structures and the interactions between these structures that make up the systems.

The software architecture

So the software architecture is:

  • defines the software structure;
  • defines the behavior of software elements;
  • concentrates on significant elements;
  • implements decisions based on rationale;
  • takes into account the influence of the external environment.

In the IMI language, component and deployment diagrams are used to describe architecture, to describe the structure of a class diagram, objects, use cases, and interaction.

Static software modules (

  • class diagrams – depict a variety of classes, interfaces, collaborations and their relationships and are used to illustrate the static view of the system from a design point of view;
  • object diagrams – show a variety of objects and relationships between them to illustrate the data structure, that is, static “snapshots” of instances of those entities that are presented in the class diagram refer to the static view of the system from the point of view of processes, but focus on real or model precedents;
  • component diagrams – show the set of components and the relationships between them, with their help they illustrate the static view of the system from the point of view of implementation, since a component is usually mapped to one or more classes, interfaces or cooperatives;
  • deployment diagrams – represent nodes and relationships between them and illustrate a static view of the system in terms of deployment, relate to component diagrams, since a node usually contains one or more components.

Dynamic software modules (behavior diagrams – used to visualize, specify, design and document dynamic aspects of the system and represent its changing parts. Dynamic aspects of a software system cover such elements as the flow of messages in time and the physical movement of components over the network):

  • use case diagrams – describe the organization of system behavior;
  • sequence diagrams – focus on the temporal ordering of messages;
  • cooperation diagrams – focused on the structural organization of objects that send and receive messages;
  • state diagrams – describe the change in the state of the system in response to events;
  • activity diagrams – demonstrate the transfer of control from one activity to another.

Leave a Reply

Your email address will not be published. Required fields are marked *