11.1. Routine object-oriented tasks Of his quick objects hath the mind no part, Nor his own vision holds what it doth catch... William Shakespeare. Sonnet 113 If you are not at all familiar with OOP, then this chapter will teach you nothing. And if you understand what OOP is in Ruby, then it’s probably not worth reading.

Object-Oriented Programming and VBA As a result of its evolution Visual Basic evolved into an (almost) object-oriented programming language. Although mastering the techniques of working with objects is a bit of a challenge when you first get started with VBA, you can expect

Chapter 12. Object-oriented programming. In This Chapter...~ Conceptualizing Objects~ Understanding the Properties, Methods, and Events - the Main Components of VBA Objects~ Working with Object Models~ Using Forms as Objects~ Finding and Setting Object Properties~

Object-oriented programming Abstraction, inheritance, polymorphism, encapsulation When talking about OOP (object-oriented programming), we cannot ignore these four basic concepts. Therefore, a brief description of them will be given below. Abstraction -

OBJECT-ORIENTED PROGRAMMING IN JAVA 7. CLASSES The basic element of object-oriented programming in Java language is the class. In this chapter, you will learn how to create and extend your own classes and work with instances of these classes. Let us remind you that

2.4. Object-Oriented Approach Recall our array specification in the previous section. We talked about how some users might want an ordered array, while most would probably be happy with an unordered one. If

Procedural-Oriented Programming Part II introduced the basic components of the C++ language: built-in data types (int and double), class types (string and vector), and the operations that can be performed on data. In Part III we will see how these components are used to build

V. Object-Oriented Programming Object-oriented programming extends object programming by introducing type-subtype relationships through a mechanism called inheritance. Instead of reimplementing common properties, the class

17.1.1. Object-Oriented Design What makes up object-oriented design for the four types of queries discussed above? How are the problems of their internal representation solved? Using inheritance, you can determine the relationships between

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 most general sense, an object is an entity, usually retrieved from a dictionary subject area or solutions, 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".

Mikhail Vasiliev, Igor Khomkov, Sergei Shapovalenko

At almost all stages of the life cycle information systems(IS) - both design, when the basic characteristics of the system are laid down, and maintenance and management of an already built IS - many questions arise that are of paramount importance. Will this IS architecture 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, cost-effectiveness and security;

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 different 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, which divides the system under study according to its active principles, i.e., the processes occurring in it in a certain order, and object-oriented, which makes it possible 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 a standard sequence of 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 IS project, or the system administrator maintaining it, to separate the most significant features of its 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, while in another, a detailed consideration of such characteristics as, say, the number of processors and disk subsystem parameters may be required.

*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, clearly correlated with 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 another 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. The constantly updated library of objects of various classes that are part of 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, which allow you to create abstract representations for global networks, also inherit the properties of their 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. Forwarding 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 virtual connections- depending on the routing algorithm on the highway or in the subnet containing this 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 number of 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 model the current network load and provide a detailed description of the behavior of the 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 infrastructure of the network.

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. Such important technological decisions 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 simulate local network, which uses a random access method with carrier sensing and collision detection at the MAC sublayer (CSMA/CD, a class of multiple access connections), however, the link layer standard proposed by the network equipment manufacturer is somewhat different from the “native” IEEE 802.3. This 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 performs the parameterization of 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.

Expand basic set classes is possible with 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 the standard description of COMNET III, the bus is described by two parameters: bandwidth and frequency. It is clear that such a description is not enough for us. However, we have an object at our disposal that allows us to describe the tire as separate device, - connection. In general, this is not a completely standard solution, but by 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, an 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 IS.

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. An object approach will be called a system approach formalized on the basis of the concept of an object. Technologies built on the basis of the object approach will be called 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 development unification and suitability for reuse models that have already been created and proven to work.

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 of 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 OOM concepts 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 is created for constructing simulation models of various subject areas.

The object form of representation best meets the tasks of simulation modeling, since it allows each object, phenomenon or process of the real world and their relationships to be uniquely assigned to the corresponding information analogue.

Currently, the recognized standard for modeling complex systems is the unified modeling language UML ( Unified Modeling Language). The UML language was developed by 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 representing dynamic real-time systems. System Model Vision Studio is a simplified (laboratory) version of the system AnyLogic.