Object-oriented modeling: Maxim Kidruk. Mathematical foundations of vector graphics. Creating a Class Diagram

Mikhail Vasiliev, Igor Khomkov, Sergei Shapovalenko

Almost at all stages life cycle Information systems (IS) - both design, when the main 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 it this architecture IP to meet growing needs? Which bottlenecks require the most attention? What investments are necessary for the IP to remain in 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. Corporate analysis 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 are most often used computer models IS.

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 graphical representation 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 lowest level abstractions used 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 The 7500 and the NS7000, which has multiple network cards and performs 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 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 details that are essential for consideration and use and omits those that are currently unimportant or distract attention”*1. So, in one situation, when describing a computer, it is enough to define it as a source of traffic, without going into detailed description 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 real life experience. 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 traffic sources or sinks, and are also used to model complex software systems, taking 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, such as the presence and parameters of the internal bus, which allows you to simulate the internal flow 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 transferring 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, 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. 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 the most flexible description within the model workload networks and behavior of traffic sources. 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 node processor, but in the context of interaction with disk subsystem 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 existing network infrastructure networks.

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 technological 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 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. 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 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.

From this we can see that the parameterization gives ample opportunities to expand the core 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 tasked with building a 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 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 tutorial contains: summary UML language - that part of it that can be used as the basis for a language for modeling complex dynamic systems; description and capabilities of the new modeling language proposed by the authors based on hybrid automata, which is an extension of UML; historical overview and examples of different approaches to designing modeling tools; object-oriented analysis of complex dynamic systems. The book is the second of three books united under the general title Modeling of Systems.

The need for a unified model description language.
Traditional technology for designing complex systems that does not require preliminary computer modeling, includes the following main stages: formulation of requirements for future system, development of design documentation based on them, creation of a prototype, its testing for compliance with requirements and maintenance of the industrial design.

In an ideal case, a complete functional specification, developed by system analysts or automatically using computer technology, is already a design solution; all that remains is to build a physical model according to this specification, which will be the system being designed. Unfortunately, it is not. Creation real system, corresponding to the developed functional specifications, requires creative, non-formalized engineering solutions and manual labor.

Even the seemingly fully formalized “soft part” of modern technical systems - embedded software - is most often executed on special embedded computers or microprocessors with special exchange channels, special operating systems and other features that require “manual” fine-tuning of the developed software. Without this “manual”, poorly formalized, stage, it is difficult to ensure the special requirements for reliable operation of the system at given temperatures, vibrations, overloads, radiation levels, volume and weight restrictions. Chapter 5 discusses the conditions under which automatic generation embedded software but functional specifications, and these conditions are still very far from today's realities.

Table of contents
Table of contents
Preface
Chapter 1. Object-Oriented Approach to Modeling
The need for a unified model description language
Classes, instances and multi-component systems
Using UML at the initial design stage
Class Diagrams
Attributes
Behavior
Operations and methods
Abstract and concrete classes. Interfaces
Classes and relationships
Association
Generalization
Aggregation
Inheritance
Polymorphism
Behavior. State diagrams
Structured classifiers
Components
Events and signals
Packages
Model
Chapter 2. Object-oriented modeling of complex dynamic systems based on the hybrid automaton formalism
Active class and active dynamic object
Packages and model
Using Passive Objects
Variables
Data types
Scalar types
Real type
Integer types
Boolean type
Enum types
Character types
Regular types
Vectors
Matrices
Arrays
Lists
Combined type (record)
Explicitly defined types
Signals
Automatic type casting
System of equations
Behavior map
States
Transitions
Structural scheme
Objects
Connections
Regular structures
Class inheritance
Adding new description elements
Overriding Inherited Elements
Polymorphism
Parameterized classes
Chapter 3. Modeling of hybrid systems and object-oriented approach in various packages
Modeling of hybrid systems in tools for mainframe computers
SLAM II language
NEDIS language
Hybrid models in modern instruments modeling
Modeling of hybrid systems in the Simulink package ("block modeling")
Modeling of hybrid systems in the Modelica language (" physical modeling")
Hybrid direction
Object-oriented modeling languages
Simula-67 and NEDIS
ObjectMath
Omola
Modelica
Block Modeling Tools
Analysis of existing OOM languages ​​in relation to modeling complex dynamic systems
Chapter 4. Multi-object models
Chapter 5. Object-Oriented Modeling and Object-Oriented Analysis
Complex technical system
Object-oriented analysis in the development of complex technical systems
Object-oriented modeling at subsequent stages of development and maintenance of complex technical system
System-analytical model as the basis of “end-to-end” design technology
Literature
Further reading for Chapter 1
Further reading for Chapter 2
Further reading for Chapter 3
Further reading for Chapter 4
Further reading for Chapter 5
Subject index.

Download the e-book for free in a convenient format, watch and read:
Download the book Modeling of Systems, Object-Oriented Approach, Kolesov Yu., Senichenkov Yu., 2012 - fileskachat.com, fast and free download.

Download pdf
You can buy this book below best price at a discount with delivery throughout Russia.

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 We are not able to cope with the increasing complexity of programs and their development, nor 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 in 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 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 lower level a concept will not be obtained whose further specification 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), is a general-purpose visual modeling language that is designed for specifying, visualizing, designing, and documenting software components, business processes, and other systems. This language can be used to build conceptual, logical and graphical models of 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 of the same language is a graphical specification for visually representing the semantics of the language.

Within the UML language, all representations of the model complex system are recorded in the form of special graphic designs - 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. However, the use case diagram represents the most general conceptual model 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 the physical components of a 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 see that time is like most important attribute 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 the final diagrams (component diagrams and deployment diagrams), it is necessary to explicitly indicate the technical characteristics of the hardware, for example, such as the number of workstations (AWS), processor clock speed, network transmission speed, storage capacity, etc. It is clear that overestimated 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 objects simulation model. The most important diagrams that carry necessary information, in this case, are a use case diagram and a 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 most general sense, an object is an entity, usually extracted from the vocabulary of a domain or solution, and a class is a description of a set of similar objects. 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".

UML (English Unified Modeling Language - unified modeling language) - language graphic description for object modeling in software development. UML is a general language, an open standard that uses graphical notation to create an abstract model of a system, called a UML model. UML was created to define, visualize, design, and document primarily software systems. UML is not a programming language, but code generation is possible based on UML models. (wiki)

Rapid development in the 1980s.

Main not a procedure or function, but an object.

For various languages, libraries of standard object classes have been created that can perform actions.

Funds have appeared visual programming(RAD), where the programmer creates a program with the mouse, and the program code is generated automatically. The programmers' attention switched from writing code to the previous stages - analyzing the subject area and designing the program.

Methods of object-oriented analysis and OOA/OOD design appeared. They allow systems to be designed before code is written, so that the design is documented. Using the model, you can correct shortcomings at no cost.

2 types of diagrams:

1) Structural models

2) behavior patterns

Subsequently, UML began to be used not so much for IS design, but for the analysis and redesign of power supply systems.

Business modeling using UML involves building two models:

1) precedent model (question 16)

2) object model (analysis of the structural model, described by the external structure of the business, etc.) (question 17).

Precedent business model

Just as for precedents and for actors, a distinction is made between the concepts of class and instance. Class – describes General characteristics of a certain type of actor, and an instance is the characteristics of a specific actor. A use case diagram typically displays use case classes and actor classes. Moreover, their location can be arbitrary. Actors belonging to different classes may have common characteristics or common obligations to the business. It is possible to introduce a generalized class of actors that combines the common characteristics of several more specific classes. For example, for the classes furniture buyers and computer buyers, a common class buyer can be introduced. In this case, a generalization relationship is established between the generalized type of actors and a more specific one.

A communication relationship is established between precedents and actors. They model information and material flows, i.e. exchange of precedents with environmental subjects of material and information nature (data, documents, raw materials, etc.).

A specification is drawn up for each element of the model. The actor specification specifies the name, stereotype, description, and a list of subdiagrams and documents associated with the use case. The most important document for describing use cases is a document called a flow of events. It describes a scenario for implementing use cases as a sequence of process steps.

Each step or event of a use case represents some action that transfers the use case to a new state. In turn, the new state of the use case is an incentive to perform the next step or event. Thus, a precedent is considered as a sequence of states and events.

Business object model.

The case model illustrates the functions of a business. However, to fully understand the business, a model is needed that shows by whom and with what help precedents are implemented. The object model reveals the internal structure of a business: what types of resources are used and how they interact. This model is also called the business analysis model. The main concept of this model is the concept of an object.

Business model objects represent the people involved in executing processes and the various kinds of entities that are processed or created by the business. Participants in processes are called active objects, entities - passive. Similar objects are grouped into classes, each specific object is considered as an instance of a certain class. For example, objects corresponding to specific employees can be combined into the class "employees". The property of an object is described using characteristics called attributes, and the composition of the attributes is the same for the entire class. The “employee” class can have attributes: last name, length of service, etc. Different objects will have different values ​​(which may change over time). Behavior is represented by a set of operations that an object can perform. Example of “employee” class operations: Accept an order, execute an agreement, accept payment, etc.

Types of BP analysis.

There are different classifications of types of analysis. Classification according to the object of analysis allows us to distinguish:

1. Environmental analysis

~ Analysis of the macroenvironment (Political, Economic, technological)

~ Analysis of the microenvironment (customers, suppliers, competitors)

2. Business analysis (Products, Equipment, Personnel).

Analysis of the macroenvironment includes analysis of tax policy, labor legislation, study of the political system of the region, analysis of the latest achievements in production, etc.

The most important areas of microenvironment analysis are the study of customer requirements, analysis of suppliers and partners and analysis of the company’s competitive position. In the process of business analysis, the analysis of business processes, technologies for their implementation, analysis of manufactured products, analysis and assessment of personnel are carried out.

Classifications in accordance with the analyzed states of the system (current, past, future) - allows you to highlight comparative, retrospective and prognostic analysis.

Classification by analysis methods - allows us to distinguish two main groups:

· quantitative (based on objective measurement and further processing of quantitative parameters)

1) statistical (correlation, regression, cluster)

2) economic (deterministic factor analysis, balance)

3) computing ( linear programming, sensitivity analysis, etc.)

· qualitative analysis (based on opinions, subjective judgments and expert assessments). In this case, as a rule, informal or weakly formalized methods are used, such as: Export assessment methods, DELPHI method, morphological analysis, scenario method and decision tree construction method.