Object-oriented modeling of information systems. Object-oriented approach to system modeling. Types of BP analysis

Concept object-oriented modeling(OOM) is certainly related to object-oriented programming(OOP). This approach to software development, which emerged in the mid-1980s, was originally aimed at solving problems arising from the inevitable growth and complexity of programs, as well as data processing and manipulation tasks. At that time it became obvious that traditional methods Procedural programming is unable to cope either with the increasing complexity of programs and their development, or with the need to improve their reliability. At the same time, computational and computational-algorithmic tasks, especially in the field of business support, gradually began to fade into the background, and the tasks of data processing and manipulation began to occupy the first place.

The fundamental concepts of OOP are the concepts of class and object. At the same time, under class some abstraction of the totality is understood objects who have general set properties and have the same behavior. Each object in this case is considered as an instance of the corresponding class. Objects that do not have exactly the same properties or behavior cannot, by definition, be classified into the same class. Although the above definition of a class can be refined by taking into account other OOP concepts, it is general and sufficient for conducting OOM.

An important feature of classes is the possibility of their organization in the form of some hierarchical structure, which appearance resembles a classification scheme for concepts of formal logic. In this regard, it should be noted that each concept in logic has a scope and content. The scope of a concept refers to all other conceivable concepts for which the original concept can serve as a defining category or part. The content of a concept is the totality of all its signs and attributes that distinguish this concept from everyone else. In formal logic, the law of the inverse relationship is known: if the content of concept A is contained in the content of concept B, then the scope of concept B is contained in the scope of concept A.

The hierarchy of concepts is constructed as follows. The most general concept or category is taken to be the concept that has the largest volume and, accordingly, the smallest content. This is the highest level of abstraction for a given hierarchy. Then the general concept is specified in some way, thereby reducing its volume and increasing its content. A less general concept appears, which in the hierarchy diagram will be located one level below the original concept. This process of concretizing concepts can be continued until at the lowest level a concept is obtained, further concretization of which is impossible or impractical.

Obviously, if we take a certain model as the most abstract concept to achieve OOM goals, then the conceptual scheme of object-oriented modeling can be represented as shown in Fig. 4.5.

Currently, the language that implements object-oriented approaches (including business process modeling) is the language UML (Unified Modeling Language), which is a general-purpose visual modeling language that is designed for the specification, visualization, design and documentation of components software, business processes and other systems. This language can be used to build conceptual, logical and graphical models complex systems for various purposes.

The formal description of the subject area using UML is based on the hierarchical structure of model representations (see Fig. 4.5), consisting of four levels: 1) meta-metamodel; 2) megamodels; 3) models; 4) objects.

Rice. 4.5.

The meta-metamodel level forms the initial basis for all metamodel views. Its main purpose is to define a language for specifying the metamodel. The meta-metamodel defines the formal language itself high level abstraction and is its most compact description. In this case, a meta-metamodel can specify several metamodels, thereby achieving the potential flexibility of including additional concepts.

A metamodel is an instance or instantiation of a meta-metamodel. The main task of this layer is to define the language for specifying the model. This level is more constructive than the previous one, since it has a more developed semantics of basic concepts.

A model in the context of the UML language is an instance of a metamodel in the sense that any specific model of a system must use only the concepts of the metamodel, specifying them in relation to a given situation. This is a level for describing information about a specific subject area. However, if UML language concepts are used to build a model, then complete consistency of model-level concepts with metamodel-level language concepts is necessary. The concretization of model concepts occurs at the level of objects.

From the most general point of view, UML consists of two interacting parts: language semantics and notation. Semantics defined for two types of models: structural models and behavioral models. Structural models, also known as static models, describe the structure of entities or components (elements) of some system, including their attributes and relationships. Behavior models, sometimes called dynamic models, describe the behavior or functioning of system objects, the interaction between them, as well as the process of changing the states of individual elements and the system as a whole. It should be noted that it was to display the behavioral aspect of systems that UML was created in the first place. Notation the same language is a graphical specification for visual representation semantics of language.

Within the UML language, all ideas about the model of a complex system are recorded in the form of special graphical structures - diagrams. Defined in UML terms the following types diagrams (Fig. 4.6):

• use case diagram ( Use Case Diagram);
• class diagram ( Class Diagram);
• behavior charts ( Behavior Diagrams);
• implementation diagrams ( Implementation Diagrams).

Rice. 4.6.

Each of these diagrams details and concretizes a different view of a complex system model in UML terms. At the same time, a use case diagram represents the most general conceptual model of a complex system, which is the starting point for constructing other diagrams. A class diagram is essentially a logical model that reflects the static aspects of the structural design of a system.

A special role is played by behavior diagrams, designed to reflect the dynamic aspects of the functioning of a complex system. This type of diagram includes:

• state diagram ( Statechart Diagram);
• activity diagram (Activity Diagram);
• interaction diagrams (Interaction Diagrams):
• - sequence diagram (Sequence Diagram);
• - cooperation diagram (Collaboration Diagram).

Finally, implementation diagrams serve to represent physical components complex system. These include:

• component diagram (Component Diagram);
• deployment diagram (Deployment Diagram).

In modern literature, all of the listed diagrams and objects of the metamodel level are considered in some detail.

From the point of view of business process modeling, visual modeling in IJML can be represented as a certain process of level-by-level descent from the most general and abstract conceptual model of the source system to the logical, and then to the physical model of the corresponding software system. To achieve these goals, a model is first built in the form of a so-called use case diagram (Use Case Diagram), which describes the functional purpose of the system or, in other words, what the system will do during its operation. A use case diagram is the initial conceptual representation or conceptual model of a system during its design and development process.

Developing a use case diagram has the following goals:

• determine the general boundaries and context of the modeled subject area at the initial stages of system design;
• formulate General requirements to the functional behavior of the designed system;
• develop an initial conceptual model of the system for its subsequent detailing in the form of logical and physical models;
• prepare initial documentation for the interaction of system developers with its customers and users.

The essence of this diagram is as follows: the designed system is represented as a set of entities or actors interacting with the system using so-called use cases. Wherein actor or an actor is any entity that interacts with the system from the outside. It could be a person technical device, program or any other system that is capable of serving as a source of influence on the simulated system as determined by the developer himself. In its turn, use case serves to describe the services that the system provides to the actor. In other words, each use case defines a certain set of actions performed by the system during a dialogue with the actor. However, nothing is said about how the interaction of actors with the system will be implemented.

The main objects of the use case diagram are summarized in Table. 4.1.

Basic UML Use Case Diagram Objects

Table 4.1

End of table. 4.1

	Designation	Purpose
Relationships in a Use Case Diagram
association relationship		The association specifies the semantic features of the interaction of actors and use cases in graphic model systems
extend relationship		An extension relationship defines the relationship between instances of a particular use case and a more general use case, the properties of which are determined based on the way these instances are combined together
Generalization relation generalization relationship		A generalization relation is used to indicate the fact that some use case A can be generalized to use case B. In this case, option A will be a specialization of option B
Inclusion relationship (include relationship)		An inclusion relationship between two use cases indicates that some specified behavior for one use case is included as a constituent component in the sequence of behaviors of the other use case.

An example of a use case diagram is shown in Fig. 4.7.

Rice. 4.7.

From a simulation modeling perspective, the use case diagrams and behavior diagrams are of greatest interest. It is these diagrams that are designed to describe the functionality (activity, movement) of the system components. In addition, the totality of these diagrams completely determines the conceptual level of description of a complex system (conceptual model). In this regard, it is necessary to consider these diagrams in more detail. As an example, let’s take the sales and marketing department of a certain company as a complex system. The main purpose of modeling this system is to automate the work of the department, i.e. in the creation and implementation of a sales management information system. It is assumed that there is no automation of production activities in the department.

Without going into a description of the semantics of the UML language (it is well covered in the relevant literature), we will only present the results of the object-oriented analysis shown in Fig. 4.8-4.12.

It is easy to notice that time, as the most important attribute of any behavioral model, is present in the above diagrams only indirectly. This means that when analyzing behavior (or changes in states), only qualitative assessments such as “not earlier than...”, “only after...”, etc. are possible. However, when analyzing, for example, a state diagram (see Fig. 4.9), the following questions naturally arise: “How often do orders arrive?”, “How long do they take to process?”, “What is the ratio of the number of automated workstations (AWS) and the number of managers ?”, “What should the server performance be?” etc. It is obvious that it is simply impossible to obtain answers to these questions from the diagrams given without the use of simulation modeling.

Rice. 4.8.

Rice. 4.9.

Rice. 4.10.

Rice. 4.11.

Rice. 4.12.

At the same time, we note that when constructing final diagrams (component diagrams and deployment diagrams), it is required to explicitly indicate specifications hardware, for example, such as the number of workstations (AWS), clock frequency processors, network transmission speed, storage capacity, etc. It is clear that inflated indicators can lead to unjustified costs, and underestimated ones can lead to a decrease in the efficiency of the entire system. Therefore, justification of the required values ​​of all technical indicators is possible only based on the results of simulation modeling.

UML diagram objects that model system behavior can be associated with simulation model objects. The most important diagrams that carry the necessary information in in this case are use case diagram and state diagram. The relationship between the objects of these diagrams and the objects of the simulation model is shown in Table. 4.2.

Table 4.2

Relationship between UML diagram objects and simulation model objects

	Statechart object	Simulation model object

Use case diagram object	Statechart object	Simulation model object

Analysis of the table 4.2 shows that, despite the sufficient expressiveness of the UML language for constructing a visual simulation model, its tools are clearly insufficient. The given abstract objects of the simulation model constitute a conceptual model of the functioning of the sales and marketing department.

There are several approaches to modeling in software development. The most important of them are algorithmic (structural) and object-oriented.

The structured method represents the traditional approach to creating software. The basic building block is a procedure or function, and attention is paid primarily to issues of control transfer and decomposition of large algorithms into smaller ones.

The most modern approach to software development is object-oriented. Here the basic building block is an object or class. In the very in a general sense an object is an entity, usually extracted from a domain or solution vocabulary, and a class is a description of a set of objects of the same type. Each object has an identity (it can be named or otherwise distinguished from other objects), a state (usually there is some data associated with the object) and behavior (you can do something with it or it itself can do something with other objects).

As an example, consider a three-tier billing system architecture consisting of a user interface, middleware, and a database. The interface contains specific objects - buttons, menus and dialog boxes. The database also consists of specific objects, namely tables representing domain entities: customers, products and orders. Middleware includes objects such as transactions and business rules, as well as more abstract representations of domain entities (customers, products, and orders).

If you accept an object-oriented view of the world, you need to answer a number of questions. What structure should a good object-oriented architecture have? What artifacts should be created during the project? Who should create them? And finally, how to evaluate the result?

Visualization, specification, construction and documentation of object-oriented systems is the purpose of the UML language.

Object-oriented modeling languages ​​emerged from the mid-70s to the late 80s, when researchers, faced with the need to take into account the new capabilities of object-oriented programming languages ​​and the demands of increasingly complex applications, were forced to begin developing various alternative approaches to analysis and design.

The technology for developing software systems, which is based on the paradigm of representing the surrounding world in the form of objects that are instances of the corresponding classes, is called object-oriented analysis and design (OOAP) - OOA&D (Object-Oriented Analysis/Design). Within this technology, the UML language is a means of graphically representing the results of modeling not only software, but also broader classes of systems and business applications, using object-oriented concepts. At the same time, the relationship between the basic concepts for conceptual and physical level models is explicitly ensured, and model scalability is achieved, which is especially important for complex multi-purpose systems.

The language developers themselves define it as "a general-purpose visual modeling language designed for specifying, visualizing, designing, and documenting software components, business processes, and other systems".

The most obvious formalization of the systems approach to the study of complex systems is carried out on the basis of the concept “ an object” as a basic element of the system. We will call the object approach systems approach, formalized on the basis of the concept of an object. Technologies built on the basis object approach, we will call object-oriented technologies(OOT).

Object-oriented modeling(OOM) provides a number of significant advantages:

1. The use of an object-based approach significantly increases the level of unification of development and the suitability for reuse of already created and proven models.

2. The use of OOM leads to the construction of systems based on stable intermediate descriptions, which simplifies the process of making changes. This allows the system to develop gradually and does not lead to its complete redesign even in the event of significant changes in the original requirements.

3. Object-oriented models are often more compact. This means not only a reduction in the volume of program code, but also a reduction in the cost of the project due to the use of previous developments, which results in a gain in cost and time.

4. An object model reduces the risk of developing complex systems through clearly defined design steps and an integrated model creation process that extends over the entire development period rather than becoming a one-time event.

5. The object model allows you to fully use the expressive capabilities of modern object-oriented programming languages.

Comparison of object definitions in the literature revealed important points OOM:

Object analysis reveals behavior and structure for objects;

Ambiguity in the representation is resolved by assigning the term to the concepts "Class", and for specific physical objects the term "an object".

Thus, OOM involves support for classes and instances of (static and dynamic) objects, encapsulation, inheritance and polymorphism. The concepts of class and instance are supported either explicitly or implicitly by almost all simulation languages. Otherwise, it is quite difficult to model systems with many similar blocks and impossible to model systems with a dynamic structure.

More complex concepts OOMs are inheritance and polymorphism. Inheritance allows you to transfer elements of the description of an existing class into the description of a new class with the addition of new ones. Polymorphism means the possibility of using an instance of any of its derived classes instead of an instance of a block of some base class.

Another principle of OOM is the principle modularity, which involves dividing the system into parts called modules, each of which contains groups of classes. The presence of extensive class libraries is a serious advantage of a particular simulation modeling system. In this case, the model can be built mechanically from instances of standard classes with their parametric settings. Based on the developed class libraries, a bank of blocks for construction is created simulation models various subject areas.

Object representation form the best way meets the tasks of simulation modeling, as it allows you to uniquely match each object, phenomenon or process real world and their relationships have a corresponding information analogue.

Currently, the recognized standard for modeling complex systems is the unified modeling language UML ( Unified Modeling Language). UML language was developed by the company Rational Software and its partners. It is the successor to modeling languages ​​based on Booch's object analysis and design methods. OOSE Jacobson, OMT Rambo et al.

Visual models provide a clear representation of the selected architectural solutions and allow you to understand the system being studied or developed in its entirety. The complexity of systems and projects continues to increase, and therefore the relevance of creating modeling complexes using visual modeling technology is increasing.

One of the few MI tools that uses UML structure diagrams as a basis is AnyLogic, which is mainly used to study dynamic continuous systems, through the use of "hybrid" state maps and UML-RT active objects created specifically for representation dynamic systems real time. System Model Vision Studio is a simplified (laboratory) version of the system AnyLogic.

Mikhail Vasiliev, Igor Khomkov, Sergei Shapovalenko

At almost all stages of the life cycle of information systems (IS) - both design, when the main characteristics of the system are laid down, and the maintenance and management of an already built IS - many questions arise that are of paramount importance. Will it this architecture IP to meet growing needs? Which bottlenecks require the most attention? What investments are needed for IP to remain working condition in a year?.. three years?.. five years? What is the effectiveness of the IP used?

Answering all these questions is by no means easy. It's even harder to answer them correctly. Analyzing a corporate information system at any stage of its existence is a complex matter.

We can say that the complexity of corporate information systems is not accidental, but rather a necessary property. It is determined by a number of reasons, among which are the following:

The complexity of the problem being solved;

Complexity of IS development;

The difficulty of ensuring such parameters as adequacy, scalability, reliability, economic efficiency and safety;

Difficulty in describing individual IS subsystems.

Objective assessments can be provided by the use of modeling technologies. Building a model, analyzing it and obtaining answers to the questions “what will happen if...?” allow us to predict the behavior of the IS in various situations. Bench prototyping and construction of computer models of ICs are most often used.

Currently, there are three leaders in the information systems modeling tools market. These are American companies MIL3 (OPNET modeling system), Make Systems (NetMaker XA system) and CACI Products Company (COMNET system). In Fig. 1 shows the main window of the OPNET system. (In PC Week/RE, No. 34/98, p. 36, Fig. 2 shows a window for graphical presentation of results in the OPNET system.) Let us dwell on one of these systems and the approach implemented in it in more detail.

IC modeling technology using COMNET III

The obvious way to model complex systems is to decompose them according to the ancient principle of Divide et impera (Divide and conquer - Latin). Hierarchical representation of complex IS as a set of interconnected subsystems is the key to uncovering the situation. The subsystems obtained as a result of such decomposition can in turn be divided into subsystems of the next level of the hierarchy, and so on ad infinitum. It is the ability to decompose complex systems that allows us to create their models. However, on this path it is extremely important to be able to stop in time.

The final stage of the decomposition process is determined by the lowest level of abstraction applied in each specific model. Excessively detailed fragmentation can lead to a result that is exactly the opposite of what was expected: instead of simplifying the modeled system, you can end up with its complexity, in what is called “you can’t see the forest for the trees.” Thus, choosing the right level of abstraction is essential for successful modeling.

The next step to facilitate the modeling of complex systems is the discovery and isolation of common abstractions. Let's assume that we have already decomposed the modeled IS and obtained a certain hierarchy of entities. For example, Cisco router 7500 and the NS7000 computer, equipped with several network cards and performing software routing can be considered both as two completely different objects, and as two objects belonging to the same class of routers. Decomposition of the system using the class metaphor in combination with a correctly selected level of abstraction allows you to radically simplify the construction of an IS model.

Rice. 1. Main window of the OPNET system

Usually two main types of decomposition are considered: algorithmic, dividing the system under study according to its active principles, i.e., the processes occurring in it in in a certain order, and object-oriented, which allows you to divide the system under study into classes of similar abstractions. Both types of decomposition have found their way into COMNET III.

The approach to building models in COMNET III can be presented as standard sequence steps:

Description of the IC topology and determination of equipment parameters;

Description of traffic sources and their behavior, description of network load;

Definition of the simulation scenario.

Determining the IS topology and the connections between traffic sources and topology nodes is an ideal field for applying object-oriented decomposition. Algorithmic decomposition is required to describe the behavior of traffic sources and changes in network load over time.

As already mentioned, the boundary conditions for IS decomposition depend on the required level of abstraction. Abstraction allows the developer creating an IP project, or system administrator who is accompanying her, to separate the most significant features of her behavior from how exactly they are implemented. “A good abstraction is one that emphasizes the details that are essential for consideration and use and omits those that are not this moment are insignificant or distracting”*1. So, in one situation, when describing a computer, it is enough to define it as a source of traffic, without going into a detailed description of the architecture; in another, it may be necessary detailed consideration such characteristics as, say, the number of processors and disk subsystem parameters.

*1. Shaw M. Abstraction Techniquest in Modern Programming Languages. - IEEE Software, Oct. 1984, v. 1(4), p.10.

The COMNET system fully applies the object-oriented decomposition method, which can significantly reduce modeling time and make its process intuitive and clearly correlated with the real system. The model is created from objects, a kind of “building blocks”, familiar to the user from experience real life. The COMNET system comes with a large library of such objects - models of real network equipment and methods of access to the environment. Let's take a closer look at the COMNET object model (Fig. 2).

Rice. 2. Basic COMNET III class library

Objects in this system can be divided into two classes: those used, firstly, to describe the topology and, secondly, to describe the traffic and load characteristics of the network. The basic COMNET III screen with a set of library classes is shown in Fig. 3.

Rice. 3. COMNET system main screen

Description of topology in COMNET III

Such basic topology concepts in the COMNET III system as nodes, connections, arcs were described in PC Week/RE, No. 34/98, p. 34.

In addition to nodes, connections and arcs for describing hierarchical topologies and modeling independent routable domains, the COMNET system includes one more additional class, the objects of which can also be located at the vertices of the graph - a subnet.

The use of inheritance mechanisms, including multiple ones, expands the range of classes used.

The node class is inherited by four new classes.

Class “Computer and Communications Node” (C&C Node, Computer and Communications Node)

These objects can serve as sources or receivers of traffic, and are also used to model complex software systems that take into account the load of the processor and disk subsystems. IC nodes described using C&C Node can also be used to model software routers.

Computer Group Node class

The object can only be used for modeling computer systems, since their functionality includes only a source and receiver of traffic. As a rule, it is used to describe groups of computers that have identical behavior.

Router Node class

Objects of this type are used to model hardware routers. Just like C&C Node, Router Node can act as both a source and receiver of traffic and run applications that use the node’s hardware resources (processors, disk subsystems). For a more detailed description of the hardware implementation of the simulated objects, a number of additional properties have been introduced, such as the presence and parameters of the internal bus, which allows you to simulate the internal passage of traffic between the input and output ports of the object.

Switch Node class

Objects of the Switch Node type, having the ability to route, are used to model switches that spend a negligible amount of time transmitting traffic between internal ports. However, these objects, unlike the three previous ones, cannot be used either as a source or as a receiver of traffic.

Objects of the C&C Node, Computer Group Node and Router node classes for modeling complex software systems include a repository of commands that use the already mentioned object properties, such as the characteristics of the disk subsystem. To a constantly updated library of objects various classes COMNET includes a wide range of models of real-life hardware devices.

The link object inherits two new objects.

Class “Point-to-Point Link”

This class is used to describe channels between two nodes. Examples of such connections include leased lines connecting routers in wide area networks or connections in circuit-switched networks.

Class “Multiaccess link”

The application field for this class is situations where several nodes have access to the same data transmission medium. In turn, this object is inherited by a number of new objects that describe specific facts of the implementation of the medium access method, such as Carrier Detection, Token Passing, SONET, etc. (see Fig. 2).

So far we have considered cases where a parent object is inherited by a single child object. However, the object-oriented approach also allows for more complex situations with multiple inheritance. This form of inheritance is also applicable in the COMNET system. Here, multiple inheritance is used to create objects of such important classes as Transit Network and WAN Cloud.

Both classes are descendants of two parent classes - Subnet and Link. The form of inheritance is shown in Fig. 2. Let's consider this option in more detail.

Subnet class

An extremely important class. Used to create hierarchical IC topologies, it allows you to correctly describe subnets with different routing algorithms, independent of the algorithm used on the backbone. In addition, subnets are used to hide excessive detail when modeling complex ICs. In COMNET, they are used to describe systems with arbitrary nesting depth. Connections between the internal subnet topology and the backbone topology are made using access points, the number of which can be arbitrary (see Fig. 3).

Class “Transit Net”

A child of subnets and connections is an object that combines the properties of its parent objects. A transit network can be considered both a connection and a subnetwork at the same time. As a connection, it forwards packets from the output buffer of one node to the input buffer of another. In the form of a subnet, the transit network creates within its boundaries an area with its own routing algorithm.

Class “Cloud” (WAN Cloud)

Objects of this class that allow you to create abstract representations for global networks, also inherit the properties of parent objects - Subnet and Link. From a topology perspective, the WAN Cloud object functions like a connection object, with its icon connecting directly to nodes. In terms of its internal structure, the cloud consists of a set of virtual circuits and access links, a type of point-to-point connection for modeling global networks.

Description of traffic and network load in COMNET III

As we have already said, the IS model in COMNET includes two parts: a description of the system topology and a description of traffic sources and network load. We have looked at the basic range of objects associated with topology. Now let's turn to objects that describe traffic.

COMNET provides a wide range of tools for describing traffic.

Message class

Objects belonging to this class allow you to send a single message to either one recipient object or multiple objects. The forwarding of such messages is treated as a sequence of datagrams, where each packet is routed independently of the others.

Class “Response”

Objects of this class can only be used to send response messages. They are controlled by the arrival of messages created by objects of the Message or Response classes. The recipient of messages of the Response class will always be an object of the Node class to which the source of control messages (of the Response or Message class) is connected.

Class “Call”

Objects of the Call class are used to create models of circuit-switched networks. The call source is described by a set of parameters such as distribution law, duration and, taking into account the routing class, bandwidth requirements.

Session class

These objects are used to model sessions that include sets of messages or messages routed over virtual connections. A session is initiated by sending a session setup packet and receiving an acknowledgment packet. Subsequently, an arbitrary number of messages can be sent within the session, also described in the Session class object. Such messages are routed either as datagrams or as virtual connections, depending on the routing algorithm on the backbone or subnet containing the object.

Note also that COMNET III uses so-called external traffic files, which can be obtained using various traffic analyzers.

Of particular interest are objects of the “Application” class, which is the result of multiple inheritance of the Message, Response, Call and Session classes (see Fig. 2). Its objects allow you to most flexibly describe the workload of the network and the behavior of traffic sources within the model. Moreover, when using them, almost any type of software system can be easily simulated, including distributed ones, such as DBMS, postal systems etc.

The real application described by objects of this class includes three components. First, these are the parameters of the node to which the Application class object is connected. Using these parameters, you set the characteristics and quantity required processors and disk subsystems. Secondly, these are the so-called command repositories that use the above-mentioned node characteristics. And thirdly, this is the Application object itself, which controls the sequence of execution of these commands.

The node's command repository, and therefore the Application class object, can contain the following commands:

Transport Message (transmit message). This command is the result of an object inherited by the Application class from a parent object of the Message class.

Setup is the result of inheriting the Session class.

Answer Message is an inheritor of the Response class.

Filter Message (filter messages). This command allows you to pause all operations described in the Application class object until a message is received that satisfies the filtering conditions.

Process. This command simulates processing that causes CPU load.

Read and Write (read and write). These two commands also allow you to simulate the busyness of the host processor, but in the context of interaction with the disk subsystem for reading and writing files.

Thus, using the Application, Message, Response, Session and Call classes, it is possible to both flexibly simulate the current network load and detailed description behavior of software systems included in the IS. It is extremely important that these classes allow you to model complex distributed software systems and their impact on the existing network network infrastructure.

COMNET III Objects: Parametric Abstraction

When talking about the core set of COMNET III classes, it is extremely important to mention the applicability of so-called parametric abstraction to them. This approach allows you to create new objects - instances of a class with different properties. Important technology solutions such as, say, Gigabit Ethernet can be very simply modeled by changing the parameters of the abstraction in question - the properties of the selected class.

Let's look at an example. Let's say we are modeling a local network that uses a random access method with carrier sensing and collision detection (CSMA/CD, a class of connections with multiple access), however, the link layer standard proposed by the network equipment manufacturer is somewhat different from the “native” IEEE 802.3. Similar situation when using a product that does not implement an object-oriented approach, could cause some inaccuracies. The developer would be forced to use the standard offered by the product manufacturer, most likely classic 802.3. In Fig. Figure 4 shows the COMNET III interface window, with which the user can edit the parameters of this standard - the number of retransmissions in case of collision detection, the length of the frame header, etc. In other words, the user himself parameterizes the object.

Rice. 4. Parameterization of 10BaseT connection according to IEEE 802.3 standard

So, we decide on the correspondence between the reference standard and the manufacturer's standard. Our further actions boil down to replenishing the library of CSMA/CD class objects with a new standard defined by the user. To do this, just add new parameters. We can do the same with hardware nodes, traffic sources, WAN Cloud parameters, etc.

This shows that parameterization provides ample opportunities to expand the basic library of objects, allowing the model developer to make more flexible decisions.

You can expand the basic set of classes by further use mechanism of inheritance.

Intermodel copy-paste mode

Let's assume that we are building a large model that has a very complex topological description. Here we can go in two ways: combine the entire system topology in one file or build several fragments and subsequently combine them. The second option is more convenient for the developer for a number of reasons. This includes ease of debugging of each individual fragment, good visibility, and, ultimately, greater reliability.

In the future, the whole problem is to transfer objects from one model to another. To solve this, it is convenient to use the COMNET III Intermodel copy-paste mode (copying and pasting an external model), which ensures the transfer from model to model of newly created objects with all properties except those that are local to the source model.

Let's give an example. Let's say we transfer a network fragment that has some load from one model to another. Traffic is described by objects of the Message class. A property of such objects that is local to the source model is its destination. The remaining properties will be transferred without changes from objects that inherit the Node classes (C&C node, Computer group, Router, Switch), Link, etc., not tied to the source model.

The parameterization procedure in this case is very simple. In particular, for a message you can specify its direction in accordance with the list of names from the new model, which is automatically attached to the object.

The use of the described method opens up wide possibilities for constructing any models from a flexible, expandable set of objects - building blocks, allowing you to significantly reduce modeling costs.

Modular construction nodes

Let's consider the procedure for creating an object of a new class based on multiple inheritance.

Suppose a developer is given the task of building detailed model hardware device(for example, a router, several interface modules of which are connected by an interface bus). The purpose of building the model is to determine the delay on the interface bus. IN standard description The COMNET III bus is described by two parameters: throughput and frequency. It is clear that such a description is not enough for us. However, we have at our disposal an object that allows us to describe the bus as a separate device - a connection. In general, this is not entirely standard solution, but after carrying out the necessary parameterization of the Link class object, we will obtain a model of the bus as a fully functional device that implements, for example, the arbitration function. Shown in Fig. 5, the MPRouter object is modeled in exactly this way. The interface bus here works using the Token Bus algorithm.

Rice. 5. Parameterization of traffic source during transfer

model fragment to another model (Session Source)

It should be said that the developer should not abuse such techniques, since, as already mentioned, too precise a description of each object in some situations can have the opposite effect, which is expressed in reducing the reliability of the model as a whole. This technique is applicable in cases where a detailed description of the characteristics of objects is necessary.

Ability to set object states

Any object in COMNET can be in several states. For example, for objects of the Link and Node classes, the possible states are up, down, failure (on, off, error). You can also simulate transitions between these states and analyze the effect of the transition on the simulated IC (Fig. 6).

Rice. 6. Determining the parameters of the current state of the object (Node Properties)

This gives the developer ample opportunity to create dynamic scenarios like “what happens if...?” and thereby significantly increases the flexibility of the created model.

So, we looked at the main tools and the most common techniques for building models in COMNET III. The authors plan to devote further articles to modeling various solutions, widely used in modern ICs.

The fundamental difference between the functional and object approaches lies in the way the system is decomposed. The object-oriented approach uses object decomposition, where the static structure is described in terms objects and connections between them, and the behavior of the system is described in terms messaging between objects. The purpose of the methodology is to build a business model of the organization, allowing the transition from the model use cases to a model that defines individual objects involved in the implementation of business functions.

The conceptual basis is the object model, which is built taking into account the following principles:

• abstraction;
• encapsulation;
• modularity;
• hierarchy;
• typing;
• parallelism;
• sustainability.

Basic concepts object-oriented approach are object and class.

Object - an object or phenomenon that has a clearly defined behavior and has a state, behavior and personality. The structure and behavior of similar objects determine their common class. A class is a set of objects related by common structure and behavior. The next group of important concepts of the object approach are inheritance and polymorphism. Concept polymorphism can be interpreted as the ability of a class to belong to more than one type. Inheritance means building new classes based on existing ones with the ability to add or override data and methods.

An important quality of the object-based approach is the consistency of the organization’s activity models and the models of the designed information system from the stage of requirements formation to the implementation stage. Using object models, one can trace the mapping of real entities of the modeled subject area (organization) into objects and classes of the information system.

Majority existing methods object-oriented approach include modeling language and a description of the modeling process. Process is a description of the steps that must be followed when developing a project. As modeling language object approach uses a unified modeling language UML, which contains a standard set of diagrams for modeling.

A Diagram is a graphical representation of a set of elements. Most often, it is depicted as a connected graph with vertices (entities) and edges (relationships) and represents a certain projection of the system.

Object-oriented approach has the following advantages:

• Object decomposition makes it possible to create smaller models by using common mechanisms that provide the necessary savings in expressive means. Using the object-based approach significantly increases the level of development unification and reusability, which leads to the creation of a development environment and the transition to assembly model creation.
• Object decomposition allows you to avoid creating complex models, since it assumes an evolutionary path of model development based on relatively small subsystems.
• The object model is natural because it is focused on human perception of the world.

To the disadvantages object-oriented approach include high start-up costs. This approach does not provide immediate benefits. The effect of its use is felt after the development of two or three projects and the accumulation of reusable components. Diagrams reflecting the specifics of the object approach are less clear.

Comparison of existing methods

IN functional models(DFD- data flow diagrams, SADT diagrams) the main structural components are functions (operations, actions, works), which are interconnected in the diagrams streams of objects.

Undoubted advantage functional models is the implementation structural approach to IC design based on the "top-down" principle, when each function block can be decomposed into many subfunctions, etc., thus performing a modular IC design. For functional models characterized by procedural rigor of IS decomposition and clarity of presentation.

At functional approach object data models in the form of ER-diagrams "object - property - relationship" are developed separately. To check the correctness of modeling the subject area, one-to-one relationships are established between functional and object models.

Main disadvantage functional models is that processes and data exist separately from each other - in addition to the functional decomposition, there is a data structure that is in the background. In addition, the conditions for performing information processing processes, which can change dynamically, are not clear.

Listed disadvantages functional models filmed in object-oriented models, in which the main structure-forming component is a class of objects with a set of functions that can access the attributes of this class.

Object classes are characterized by a generalization hierarchy that allows inheritance not only attributes (properties) of objects from a higher class of objects to a lower class, but also functions (methods).

In the case of function inheritance, you can abstract from the specific implementation of procedures ( abstract data types), which differ for certain subclasses of situations. This makes it possible to contact similar software modules By common names (polymorphism) and implement reuse program code when modifying software. Thus, the adaptability of object-oriented systems to changes in the subject area compared to functional approach much higher.

With an object-oriented approach, the principle also changes IC design. First, classes of objects are identified, and then, depending on the possible states of objects (the life cycle of objects), processing methods (functional procedures) are determined, which ensures the best implementation of the dynamic behavior of the information system.

For object-oriented approach graphical methods for modeling the subject area have been developed, generalized in the unified modeling language UML. However, in terms of the clarity of presenting the model to the customer user, object-oriented models are clearly inferior to functional models.

When choosing a methodology for modeling a subject area, the degree of its dynamism is usually used as a criterion. For more regulated tasks, functional models are more suitable, for more adaptive ones business processes(workflow management, implementation dynamic queries to information repositories) - object-oriented models. However, within the same IS, different classes of tasks may require different kinds models describing the same problem area. In this case, combined domain models.