Send your good work in the knowledge base is simple. Use the form below

Students, graduate students, young scientists who use the knowledge base in their studies and work will be very grateful to you.

Posted on http://www.allbest.ru/

Omsk State Institute of Service

Modeling information systems using the UML language

Methodical instructions for the implementation of term paper

I.V. Chervenchuk

• Introduction
• 2 . Unified Modeling LanguageUML
• 4. Development of a software system model by meansUML
• 5. Questions of the implementation of the information system
• 6. Topics of coursework
• Bibliographic list

Introduction

The paper deals with the development of information systems using the unified modeling language UML, which is the basis for the course work in the discipline "Information systems and processes. Modeling and management". The main stages of a rational unified process of developing information systems are being worked out, examples and illustrations are given. Options for assignments for coursework are given.

Methodical instructions are intended for students of the specialty "Applied Informatics" and can be used in coursework, preparation for the exam, as well as in the process of independent work.

1. General requirements for the implementation of term paper

Course work on the discipline "Information systems and processes. Modeling and management" is the final stage of studying this course and is designed to consolidate in practice the basic theoretical knowledge of modeling information systems. The work consists in developing a model of some information system by means of the unified modeling language UML with its subsequent implementation. As a typical variant of the assignment, it is proposed to develop an information and reference system based on a database, but at the request of the student, in agreement with the teacher, the development of a WEB application, test system or hardware device can be offered as an assignment. At the same time, the main prerequisite is the use of an object-oriented approach and the construction of a UML model.

The typical title of the term paper looks like "Development of an information and reference system _ title _ "

Introduction

1. Substantial overview of the subject area. Basic system requirements

2. A detailed model of the information system

2.1 View from the perspective of use cases

2.2 Design view

2.3 Implementation view

2.4 Process perspective (if applicable)

2.5 View from the deployment point of view (if necessary)

3. Implementation of the information system

Conclusion

Application Listing of a program or head module

In the introduction, one can point to the use of information technology in various fields of activity, including the service sector, the advantages of electronic accounting, the problems of building specialized information systems, etc.

These guidelines contain detailed recommendations for the main sections of the explanatory note and design examples. It should be noted that the main subject of this course work is the development of a UML-model of an information system, therefore it is strongly recommended that UML-diagrams be given in the main part of an explanatory note, providing them with detailed comments, and the texts of programs should be placed in the application.

The process view should be given when designing multitasking systems. The deployment view assumes a distributed information system. These types, and the corresponding sections of the explanatory note, are not mandatory for the implementation of this course work, their use is assumed when performing only certain variants of the course work.

When highlighting the issues of system implementation in a note, it is advisable to justify the choice of a programming environment, to provide a user manual. A mandatory element is the inclusion of screen forms (screen-shorts) of the implemented program in the text, the use of reverse engineering tools is encouraged.

In the conclusion, the main results of the work are briefly summarized: a UML-model of the system has been developed, the system is implemented using such and such a programming environment that the developed system allows, the advantages of the approaches used (based on modeling) to the design of systems.

modeling information system language

Course work should contain 20-30 pages of printed text with illustrations. Diagrams of use cases, classes, interactions must be provided without fail.

2. Unified Modeling Language UML

Rational development of an information system presupposes a deep preliminary analytical study. First of all, it is necessary to outline the range of tasks performed by the system being developed, then, to develop a model of the system, and finally, to determine the implementation methods. A deep study of the architecture of the information system being developed at the initial design stages, as a rule, pays off later, especially when developing large-scale projects with long-term support.

The tools of the modeling language UML (Unified Model Language, - a unified programming language) allow expressively and quite easily to carry out a preliminary conceptual development of an information system, and at the same time, methodically accompany the entire development process, including the entire further life cycle of the developed information system as a software product.

UML is an object-oriented language for visualizing, specifying, constructing and documenting artifacts of software systems.

The UML, like any other language, consists of a vocabulary and rules that allow you to combine the words included in it and get meaningful constructions. In a modeling language, vocabulary and rules are focused on the conceptual and physical representation of information systems. Modeling is essential for understanding the system. That being said, a single model is never enough. On the contrary, to understand any non-trivial system one has to develop a large number of interrelated models. As applied to software systems, this means that a language is needed with which it is possible to describe from various points of view the representations of the architecture of the system throughout its development cycle.

UML is a visualization language, and UML is not just a collection of graphical symbols. Each of them has well-defined semantics (see). Thus, a model written by one developer can be unambiguously interpreted by another, or even by a toolkit.

UML is a specification language. In this context, specification means building accurate, unambiguous, and complete models. The UML allows the specification of all significant analysis, design, and implementation decisions that must be made during the development and deployment of a software system.

UML is a design language. Although the UML is not a visual programming language, the models created with it can be directly translated into various specific programming languages. In other words, the UML model can be mapped to languages ​​such as Java, C ++, Visual Basic, and even relational database tables or persistent object-oriented database objects. Those concepts that are preferably conveyed graphically are represented in the UML; those that are better described in text form are expressed using a programming language.

This mapping of a model to a programming language allows direct design: the generation of code from a UML model into a specific language. You can also solve the inverse problem: restore the model from the existing implementation. Naturally, the model and implementation involves the use of a number of specific entities. Therefore, reverse engineering requires both tooling and human intervention. The combination of forward code generation and reverse engineering allows you to work in both graphical and textual representations as long as the tools ensure consistency between both representations.

In addition to direct mapping to programming languages, the UML, due to its expressiveness and unambiguity, allows you to directly execute models, simulate the behavior of systems and control operating systems.

UML is a documentation language

A software company produces other documents in addition to executable code, including:

system requirements;

architecture;

project;

source;

project plans;

tests;

prototypes;

versions, etc.

Depending on the adopted development methodology, some works are performed more formally, others less. The documents referred to are not just supplied parts of the project; they are necessary for management, for evaluating the result, and also as a means of communication between team members during system development and after its deployment.

The UML provides the developer and management with their own solution to the problem of documenting the system architecture and all its details, provides a language for formulating system requirements and defining tests, and finally provides a means for modeling work during the project planning and version control phase.

Let us consider the development of a model of an information system by means of the UML language using the example of the development of an automated workstation for a department secretary (hereinafter referred to as a department secretary's AWP).

3. Description of the subject area

The concept of a database subject area is one of the basic concepts of computer science and has no precise definition. Its use in the context of IP presupposes the existence of a stable correlation over time between names, concepts and certain realities of the external world, independent of the IP itself and its circle of users. Thus, the introduction into consideration of the concept of the database domain limits and makes the information retrieval space visible in the IS and makes it possible to execute queries in a finite time.

Under the description of the subject area, we mean the description of the environment of the system being developed, the types of users of the system, while also indicating the main tasks, the solution of which is assigned to the system.

In the preliminary description of the subject area, the basic terms are introduced (system vocabulary), the types of users and their rights are determined, the tasks that the developed system must solve are formulated. In this case, the description is supposed to use the means of ordinary language and standard business graphics (pictures, diagrams, tables).

When developing a system dictionary, it is necessary to define the names of entities ("student", "teacher", "discipline"). In this case, the term essence is understood by us as a component of the domain model, that is, as an object already identified at the conceptual level. The objects allocated in the subject area are transformed by the analyst into entities.

Entity is the result of abstraction of a real object. There are two problems associated with objects: identification and adequate description. For identification, a name is used, which must be unique. In this case, it is assumed that there is a rejection of its meaning, which is inherent in natural language. Only the indicative function of the name is used. The name is a direct way of identifying an object. Indirect methods of object identification include the definition of an object through its properties (characteristics or signs).

Objects interact with each other through their properties, which gives rise to situations. Situations are relationships that express relationships between objects. Situations in the subject area are described by means of statements about the subject area. At this stage, you can use the methods of propositional calculus and predicate calculus, that is, formal, mathematical logic. For example, the statement "The programmer and the manager are employees of the company" describes an inclusive relationship. Thus, all information about objects and entities of the domain is described using statements in natural language.

You can specify structural links, highlight static and dynamic situations (thus introducing a time parameter into the model), however, for a detailed study of the model, it is more convenient to use advanced means of describing the domain, for example, means of the UML language.

So, the task is to develop a system "workstation of the secretary of the department" that would allow for automated accounting of data on employees and students of the department of ICT of OmSTU, provide flexible opportunities for solving planned and unplanned specific tasks of processing credentials.

As part of solving the problem of developing an automated workplace for the secretary of the department, we will single out the following entities:

teachers - teachers of the department;

students- students of the university of this specialty;

students study in groups, group is an organizing (unifying) entity for students;

graduate students, have the peculiarity that, on the one hand, they themselves can conduct classes, on the other hand, they themselves are students and have a scientific advisor;

discipline- the taught discipline (subject, course).

Inserted entities have a number of attributes, which we will define later.

We conduct two types of users: private user(further user, and administrator... It is assumed that user can access the system with a request, display reports, administrator additionally can modify data. For example, the assistant secretary of the department can act as a user, the secretary himself or the responsible teacher can act as an administrator.

Taking into account the terms introduced, the system being developed should provide:

organization of complete and reliable accounting of all employees and students of the department;

informational support of management decisions taken, the formation of complete and reliable information about educational processes and the results of the department's activities;

reduction of labor costs for the preparation of primary documents and reports;

elimination of duplication when entering information and the resulting mechanical errors;

user friendly interface;

differentiation of the powers of ordinary users and the administrator.

In this example, we solve a particular problem - we develop the AWP for the secretary of the department, therefore, the department is taken as a structural unit of the highest level for us, which we will have in mind by default, that is, it is assumed that all elements of the model relate only to this department, which is not explicitly specified ... We will not consider higher-level structures, such as a faculty, a university.

4. Development of a software system model using UML

The UML is a language for specification and visualization, its main units are diagrams.

A UML diagram is a graphical representation of a set of stencils, most often depicted as a connected graph with vertices (entities) and edges (relationships). The diagrams characterize the system from different points of view. A diagram is, in a sense, one of the projections of the system. Typically, charts provide a collapsed view of the elements that make up a system. One and the same element can be present in all diagrams, or only in several (the most common variant), or not present in any one (very rarely). In theory, diagrams can contain any combination of entities and relationships. In practice, however, a relatively small number of typical combinations are used, corresponding to the five most common types that make up the architecture of a software system (see the next section). Thus, in the UML, nine types of diagrams are distinguished:

class diagrams

object diagrams;

use case diagrams;

sequence diagrams;

cooperation diagrams;

state diagrams;

action (activity) diagrams;

component diagrams;

deployment diagrams.

UML conceptual model

A class diagram shows classes, interfaces, objects, and collaborations, and their relationships. When modeling object-oriented systems, this type of diagram is used most often. Class diagrams correspond to the static design view of the system. Class diagrams that include active classes correspond to the static view of the system from a process perspective.

An object diagram represents objects and the relationships between them. They are static "photographs" of the entity instances shown in class diagrams. Object diagrams, like class diagrams, refer to a static view of a system from a design or process perspective, but with a view to a real or mock implementation.

The use-case diagram shows use cases and actors (a special case of classes), as well as the relationships between them. Use case diagrams refer to a static view of a system in terms of use cases. They are especially important when organizing and modeling the behavior of a system.

Sequence diagrams and cooperation diagrams are special cases of interaction diagrams. Interaction diagrams represent relationships between objects; shows, in particular, the messages that objects can exchange. Interaction diagrams refer to the dynamic view of the system. In this case, sequence diagrams reflect the temporal ordering of messages, and cooperation diagrams - the structural organization of objects exchanging messages. These diagrams are isomorphic, that is, they can be transformed into each other.

Statechart diagrams represent an automaton that includes states, transitions, events, and types of actions. State diagrams refer to the dynamic view of the system; they are especially important when modeling the behavior of an interface, class, or cooperation. They focus on the behavior of an object, depending on the sequence of events, which is very useful for simulating reactive systems.

An activity diagram is a special case of a state diagram; it shows the transitions of the flow of control from one activity to another within the system. Activity diagrams refer to a dynamic view of a system; they are most important in modeling its functioning and reflect the flow of control between objects.

The component diagram shows the organization of a set of components and the dependencies between them. Component diagrams refer to a static view of a system from an implementation point of view. They can be related to class diagrams, since a component usually maps to one or more classes, interfaces, or collaborations.

The deployment diagram shows the configuration of the processing nodes of the system and the components placed in them. Deployment diagrams refer to a static view of a system's architecture from a deployment perspective. They are related to component diagrams because a subassembly usually contains one or more components.

Here is a partial list of diagrams used in the UML. The tools allow you to generate other diagrams as well, such as database profile diagrams, web application diagrams, and so on.

4.1 Designing a View from a Use Case Perspective

Modeling begins with defining the main objectives of the system being developed and the actions that it should perform. Use case diagrams are used for these purposes. As discussed earlier, use case diagrams indicate use cases and actors and the relationships between them.

Precedent (Use case) is a description of a sequence of actions performed by the system that produces an observable result that is significant for a certain Act e ra (Actor). Use case is used to structure the behavioral entities of the model. The use case only declares a description of some action of the system, answering the question "what to do?", But does not indicate by what means. The concrete implementation of the behavior specified by the use case is provided by a class, class collaboration, or component.

An actor is a coherent set of roles that use case users play when interacting with them. Typically, an actor represents the role that a person, hardware device, or even another system plays in a given system. In the developed system "Workstation of the secretary of the department" the actors are the administrator (admin) and user.

Graphically, a precedent is depicted as an ellipse bounded by a continuous line, usually containing only its name, the actor has a "little man" icon.

In order to build a use case diagram, it is necessary to identify the elementary actions performed by the system and compare them with use cases. At the same time, it is desirable to give the names of use cases so that they indicate the behavior, often such names contain verbs, for example, "generate a report", "find data by criterion", etc. It is possible to give names to use cases with nouns that suggest some actions, for example, "authorization", "search", "control".

Returning to the modeling of the automated workplace of the secretary of the department, let us highlight the precedents:

Editingdata,

Searchstudent,

Searchteacher,

Issuancelisttaughtdisciplines,

Authorization.

Use case diagram elements (use cases and actors) must be linked by relationships.

The most common relationship between use cases, use cases, and actors is association. In some cases, generalization relationships can be used. These relationships have the same meaning as in the class diagram.

In addition, two specific dependencies are defined between use cases in the UML — an inclusion relationship and an extension relationship.

An inclusion relationship between use cases means that at some point in the base use case the behavior of another use case is incorporated (included). The included use case never exists autonomously, but is instantiated only as part of the enclosing use case. You can think of the base use case as borrowing the behavior of the include. Due to the presence of inclusion relations, it is possible to avoid multiple descriptions of the same stream of events, since the general behavior can be described as an independent use case included in the base ones. An inclusion relationship is an example of delegation, in which a number of responsibilities of the system are described in one place (in the included use case), and the rest of the use cases, when necessary, include these responsibilities in their set.

Inclusion relationships are depicted as dependencies with the stereotype "include". To specify a place in the flow of events where a base use case includes the behavior of another, you simply write the word include followed by the name of the use case to include.

An extension relation is used to model parts of a use case that the user perceives as optional system behavior. This allows you to separate required and optional behaviors. Extension relationships are also used to model individual substreams that only run under certain circumstances. Finally, they are used to simulate multiple streams that can be triggered at some point in the script as a result of explicit interaction with the actor.

The extension relationship is depicted as a dependency with the stereotype "extend". The base script extension points are listed in an additional section. They are simply labels that can appear in the flow of the underlying use case.

An example of using this relationship can be access to a database with an operational part and an archive. In this case, if the request is provided with data from the operational part, the main (basic) access to the data is performed, if the data from the operational part is not enough, the archive data is accessed, that is, access is performed according to the advanced scenario.

In our case, the precedent editingdata includes use cases: inputdata, deletiondata, the changedata.

The diagram of the precedents of the AWP of the secretary of the department is shown in Fig. 1.

Rice. 1. Diagram of the precedents of the AWP of the secretary of the department

Precedent Searchstudent involves search by last name and search by results of academic performance.

When designing a view in terms of use cases, it is often necessary to provide an extended description of the use case (only the name is given in the abbreviated version). Typically, the flow of events of a use case is described in text form at the start. As you refine your system requirements, it will be more convenient to move to a graphical representation of flows in activity and interaction diagrams.

Streams of events can be described by means of unstructured text, structured text (containing service words: IF,BEFORETHOSEPORBYE etc.), a specialized formal language (pseudocode).

When describing a use case as a flow of events, it is important to also designate the main and alternative flows of the system's behavior.

For example, consider the description of the flow of events of the use case authorization.

Basic flow events. The use case begins when the system asks the user for his Login and Password. The user can enter it from the keyboard. The entry ends with a key press. Enter. After that, the system checks the entered Login and password, and if they match the administrator, confirms the administrator's authority. This concludes the precedent.

Exceptional flow events. The client can terminate the transaction at any time by pressing the key Cancel. This action starts the precedent all over again. There is no entry into the system.

Exceptional flow events. The client can erase his Login and password at any time before pressing the Enter key.

Exceptional flow events. If the client entered Login and password that do not correspond to the administrator, he is offered to re-enter or log into the system as an ordinary user.

Obviously, the description of a use case by a stream of events presupposes some kind of algorithm that can be represented in an activity diagram (Fig. 2).

The algorithm diagram must contain the start and end vertices, with only one start and one end. The diagram contains executable vertices - activities (indicated by rounded rectangles), conditional vertices (decision - selection, recognition, indicated by diamonds) and links.

Similar diagrams can explain the execution of other use cases, thus complementing the view of the system from the point of view of use cases.

Rice. 2. User authorization. Activity diagram.

4.2 Developing a design view

The design view is the main stage in the conceptual study of the model. At this stage, the basic abstractions are introduced, classes and interfaces are defined through which the solution of the tasks is implemented. If the use cases only declare the behavior of the system, then at the stage of developing the view from the design point of view, it is determined by what means these use cases will be implemented. Static aspects of this type are developed through class diagrams, dynamic - through interaction and state diagrams (automaton).

Class diagrams contain classes, interfaces, cooperations, as well as connections between them. The development of a class diagram should begin with the definition of classes corresponding to the main entities of the system, which, as a rule, are determined at the initial stages of development when describing the subject area. Here it is necessary to decide which entities are more convenient to model as classes, and which ones as their attributes. For example, if it was required within the faculty to indicate the head for each department, it would be better to specify managerChairs make it a class attribute chair indicating the class teachers ( one-to-one association ), rather than introducing a separate class managerChairs.

When modeling, it must be remembered that each class must correspond to some real entity or conceptual abstraction from the area that the user or developer is dealing with. A well-structured class has the following properties:

is a well-defined abstraction of some concept from the vocabulary of the problem area or area of ​​solution;

contains a small, well-defined set of responsibilities and performs each of them;

maintains a clear separation between abstraction specifications and its implementation;

understandable and simple, but at the same time allows expansion and adaptation to new tasks.

As part of the development of the model of the automated workplace of the secretary of the department, we will define the classes: teachers, students, graduate students, disciplines, group... Obviously, the first of them have many common attributes, so let's introduce an abstract class PEerson, which will encapsulate all human-related properties in the context of the system being developed (last name, first name, address, etc.). In this case a person will be the superclass and communicate by generic relationship with the classes teachers, students, graduate students.

Attribute the address has its own structure, to reflect it you can introduce an additional class, let's call it T_ ADR(as is customary in many programming systems, class names begin with the letter T). Note that the attribute the address class a person is an instance of the class T_ ADR, that is, a dependency relationship is established between these classes (shown by a dashed arrow with an open tip, the arrow is directed from the dependent to the independent). In our case, changing the structure of the class T_ ADR entails a class change a person through the structure of the corresponding attribute ( the address).

When modeling a class T_ ADR attribute index set by means of a primitive type T_ POSTIDX, defined as a six-digit decimal number. Primitive types are stereotyped " type" , the range of values ​​is specified through the constraints enclosed in curly braces.

In class teacher let's highlight the specific attributes related only to the teacher: position, uch. degree(academic degree), uch. rank ( academic rank), discharge(category of a single tariff scale). Attributes uch. degree and uch. rank it is better to define specialized types via enumeration. Enumerations are modeled by a class with the stereotype " enum" (enumeration - enumeration), allowed values ​​are written as attributes, labels that determine the visibility of attributes are suppressed. In the considered example, through the enumeration, we introduce specialized classes T_Must, T_UCHST, T_UchZv, respectively defining possible positions, academic degrees, academic titles through transfers. In this case, as elsewhere in similar cases, when creating classes that specify the attributes of the main class, dependency relations are established.

For class student a specific attribute is introduced roomrecord books... Specific attributes are defined for the postgraduate class formlearning and datereceipts... The form of study will be determined by a special class through an enumeration T_FormObuch(full-time, part-time).

Class group has attributes: title, form learning, numberstud. ( number of students ). Considering that the teachers of the department in question can teach groups from other faculties, an additional class is introduced speciality, with attributes room(specialty), title(specialty ), faculty whose types are not specified in this model, although they can be determined through enumerations.

Class discipline has attributes: room, title, cycle. Attribute cycle by means of a specialized type introduced through an enumeration T_Cycles determines which cycle the discipline belongs to: the cycle of humanitarian and socio-economic disciplines, mathematical and natural science disciplines, general professional disciplines, special disciplines.

Attributes numberhours, numbersemesters cannot be specified in the class discipline, since they depend on the specialty, the more you cannot indicate them in the class speciality... These attributes relate to the specialty-discipline pair and are defined in the class - association Disciplines-specialties.

Rice. 3. Class diagram of the AWP of the secretary of the department (option 1)

When rendering a class structure, pay attention to the visibility of the attributes. All considered attributes must be available and have the visibility Public (denoted by a "+" sign or an icon without a padlock). In the considered classes, we focused on structure rather than behavior (operations were not described and are not supposed to be described), therefore, to make the diagram easier to read, it is desirable to suppress the operations.

On the introduced set of classes, it is necessary to redefine the links. The connections of generalization and dependencies have already been determined, it remains to define the associations.

Students formed in group, in this case the association will be in the form of aggregation. Aggregation assumes a part-whole relationship, denoted by a solid line with a rhombus at the end from the whole side (in our case group). The plurality of many-to-one student-group relationships. Each group refers to a specific specialty, in turn, several groups can correspond to a certain specialty, therefore the group-specialty association also has the type of multiplicity "many to one".

In this case, as in most others, the direction of associations is two-way, so it is better to suppress navigation (uncheck the Navigable field of the Detail Role option)

Let's define an association between teachers and taught disciplines as "many-to-many": a teacher can teach several disciplines, some disciplines can be taught by several teachers. Between disciplines and specialties the association "many-to-many" is also established: the curriculum of specialties contains many disciplines, most disciplines are found in the work plans of several specialties. The association class is attached to this association. Disciplines-specialties with attributes indicating the course, the number of semesters and the number of hours of a given discipline in a given specialty.

Similarly, we introduce an association between in groups and teachers: Teachers teach in groups, multi-to-many association type. Direct association between in groups and disciplins you do not need to define, since this relationship is traced through the binder class speciality.

In order to display the presence of a supervisor for a graduate student, it is necessary to introduce an association between a graduate student and a teacher of the "many-to-one" type; one supervisor can have several graduate students. On this association on the part of the teacher, you can explicitly indicate the role: supervisor.

Rice. 4. Diagram of classes of AWP of the secretary of the department (option 2)

In each groupse there is a group leader, this fact can be displayed by an additional association (let's give it a name headman) from group to students with the type of multiplicity "one to one". In this case, you can explicitly specify the navigation.

Postgraduate students can also teach specific disciplines to specific groups: many-to-many associations postgraduate groups, postgraduate disciplines. Some graduate students may not be teaching, so the multiplicity type at the ends of the association will be 0. n.

The final class diagram is shown in Fig. 3.

Rice. 5. Simplified class diagram

Considering that both graduate students and teachers teach classes, an additional abstract class can be introduced, for example, teaching which is a descendant of the class a person and a superclass for the classes teacher and graduate student, which will slightly reduce the number of connections. (fig. 4.). In this case, from the classes discipline and group associations will go to class teaching, assuming a link to the classes teacher and graduate student through inheritance (generalization relation). To class teaching you can take out the attributes bid(0.5 rate, full rate) and discharge.

The resulting diagram is quite complex and loaded with elements, but the modeling of the classes is far from complete: some utility classes and interfaces still need to be defined. In order to unload the class diagram, we will construct a new view of it (on a separate diagram), leaving the image of the main classes and suppressing the display of auxiliary ones that determine the types of attributes (Fig. 5).

In fig. 5, along with the main classes corresponding to the conceptual elements of the system, the class is also shown T_ ADR, revealing the structure of the address, this class is also important, since it contains the necessary data elements for teachers and graduate students- descendants of the class a person.

Let's move on to defining the interfaces. Classes interact with the outside world through interfaces.

Interface (Interface) is a collection of operations that define a service (set of services) provided by a class or component. Thus, an interface describes the externally visible behavior of an element. An interface can represent the behavior of a class or component in whole or in part; it only defines the specifications of the operations (signatures), but never their implementation. The graphical interface is depicted as a circle, under which his name is written. An interface rarely exists on its own — it is usually attached to an implementing class or component. The interface always presupposes the existence of some kind of "contract" between the party that declares the execution of a number of operations and the party that implements these operations.

Place the class on the diagram electronictable, which encapsulates all the properties and operations of the spreadsheet that allows you to edit the data. We will not reveal the structure of this class due to its great complexity. So, in modern application development tools, the user uses ready-made classes and templates, inheriting their capabilities, for example, the VCL library (Delphi) contains a TTable class that encapsulates the capabilities of a spreadsheet. Descendants of the class electronictable are specific spreadsheets containing specific data for faculty, graduate students, students, groups, disciplines and specialties. By making the corresponding classes descendants of the class electronictable, we declare for these classes all the properties and operations inherent in spreadsheets (registration in the system, insertion, deletion, data editing, sorting, etc.).

For class electronictable, and, accordingly, for all its descendants, we define the interface editing, implying all possible data editing operations (insert, delete, change data). In this case, it is assumed that in the class electronictable these possibilities are implemented.

Using a custom class electronictable and inheritance avoided defining special properties and data editing interfaces for each spreadsheet.

Let's define the interfaces Searchteacher, Searchdisciplines by attaching them to their respective classes with an implementation relationship. We will not disclose the composition of operations of these interfaces (it is quite trivial), therefore, we will display the interfaces in an abbreviated form (in the form of a circle). Recall that an implementation relationship attached to an interface in abbreviated form is displayed as a simple solid line (as an association).

Interface Searchstudent will be displayed with an indication of the list of operations through a stereotyped class, while the implementation relation is shown by a dashed arrow with a closed tip.

Naturally, it is assumed that the introduced interfaces are implemented by means of the classes to which they are attached by the implementation relation, that is, the corresponding classes contain operations and methods that implement the declared interfaces. For ease of perception, these mechanisms are not visualized.

To manage access rights and user authorization, we introduce the class manageraccess... The access manager has a private access type attribute tablepasswords which is an instance of the class CodirTable(Coded table) containing passwords ( password) and input names ( login) of administrator users. It is assumed that the service class capabilities CodirTable do not allow an unauthorized user to read user passwords. At this stage of the design, we simply declare such capabilities, not dwelling on the mechanism for their implementation, but assuming that they are encapsulated in a class CodirTable.

Class manageraccess contains open transactions inputpassword and granting administrator rights, by means of which authorization and management of access rights are realized.

Let us indicate the dependence between the data editing interface ( editing) and an access manager, assuming that only users with administrator rights have full data editing capabilities.

Rice. 6. The final diagram of the classes of the AWP of the secretary of the department

The final diagram is shown in Fig. 6.

So, at this stage, the development of an object-oriented model of the workstation of the secretary of the department by means of the UML class diagram can be considered complete. Naturally, it is possible to return to it and revise some elements during the design of the system, when adjusting tasks, when specifying individual details. The information systems design process is iterative. It should be noted that the developed class diagram contains elements that explicitly or implicitly implement all the use cases of the use case diagram. Each use case of a use case diagram must correspond to either an interface or an interface operation (implementation is assumed in the classes corresponding to the interface), or a public operation of the class, or a set of public operations (in this case, the use case is implemented directly by the corresponding class or set of classes).

Let's look at the process of creating a new student record using a sequence diagram.

Creating a new record assumes administrator rights, so the administrator will be the protagonist of this interaction ( admin). This element has already been entered in the use case diagram, so drag it onto the sequence diagram from the use case view browser.

It should be noted that objects appear in interaction diagrams, that is, concrete instances of classes (the name of an object is always underlined).

We manage objects: forminput, managerrecords, student record Petrov(as a concrete example of a student record), managertransactions... This set of objects is typical when modifying a record in a database table.

Forminput- an element of the user interface, which is a typical form for entering data about a student (last name, first name, patronymic, address, etc.). In our case, it is a somewhat extended concrete implementation of the standard interface editing class electronictable. Since we did not specifically introduce the interface for editing student data on the class diagram, therefore, explicitly specify the class for the object forminput we will not.

Managerrecords- an object that has a standard set of data management capabilities when working with a spreadsheet. This set of capabilities is inherited by the class students from class electronictable... For object Managerrecords the class of which it is an instance is explicitly indicated - students.

Petrov- a specific record about student Petrov, a new element of the table about students. Here we explicitly indicate the introduced class recordingOstudent... Such objects usually exist temporarily to send relevant information to the database during transactions. After the end of the transaction, this object can be destroyed. The object corresponding to the record can be created again if it is necessary to edit the information.

Managertransactions- an object that ensures the execution of a completed operation on the database, in this case, the creation of a new record about student Petrov. This object is also responsible for performing a number of system functions that accompany the transaction. Examples of transaction managers are, for example, BDE (used to access Paradox, Dbase, etc. databases from Delphi applications), ADO (used to access MS Access databases from various applications).

The sequence diagram for entering a new record about a student in the AWS of the department secretary is shown in Fig. 7.

Rice. 7. Entering student data. Sequence diagram.

In the sequence diagram, we define the transfer of messages between objects: createnewrecording(broadcasted from object to object to the end of the chain as a message saverecording); openshape(to the input form); to introduceF.AND ABOUT.,the address. ( student data entry), then these data are broadcast by messages saveF.AND ABOUT.,the address. From managertransactions send message collect informationOstudent providing feedback to the database, and finally a reflexive message managertransactions named as saverecordingvDB, ensures the end of the transaction.

If desired, this interaction can be represented by a cooperation diagram, illustrating, first of all, the structural aspect of the interaction (Fig. 8). This diagram can be built from the previous one in automatic mode (in Rational Rose by pressing the F5 key).

Rice. 8. Entering student data. Cooperation diagram.

If necessary, the project can be supplemented with other interaction diagrams that reveal the work of use cases.

4.3 Developing a relational database profile

In the event that an object-oriented DBMS (OODBMS) is used to implement the system, the object diagram constructed in the previous section is the final model and a direct guide to the implementation of the information system. In the same case, when a relational database (RDB) is supposed to be used as the information core of an information system, it is necessary to develop another diagram, a profile diagram of a relational database.

The UML Profile for a Database Project is a UML extension that keeps the UML metamodel intact. The profile for a database project adds stereotypes and tagged values ​​appended to these stereotypes, but does not change the underlying UML metamodel. To visualize the designed database elements and design rules for relational databases, the corresponding icons have been added to the profile (hereinafter simply databases). The database is described using tables, columns and relationships. The profile contains elements that extend the database, such as triggers, stored procedures, constraints, user-defined types (domains), views, and others. The profile shows how and where to use all these elements in the model. The following entities are defined on the UML Database Profile:

table ( Table) - a set of records in the database for a specific object, consists of columns.

Column ( Column) is a table component containing one of the table attributes (table field).

Primary key ( Primary key) - a possible key chosen to identify table rows.

External key ( Foreign key) - one or more columns of one table, which are the primary keys of another table.

Representation ( View) is a virtual table that behaves from the user's point of view exactly like a regular table, but does not exist on its own.

Stored procedure ( Stored procedure) is an independent procedural function executed on the server.

Domains ( Domains) is a valid set of values ​​for an attribute or column.

In addition to these entities, some additional entities can be introduced that reflect specific aspects of the database model.

Similar documents

Methodologies for the development of information systems in domestic and foreign literature. State and international standards in the field of software development. Development of a fragment of the educational-methodical resource information system.

term paper, added 05/28/2009


Definition of the concept of "system". The history of development and features of modern information systems. The main stages of the development of an automated information system. Use of domestic and international standards in the field of information systems.

presentation added on 10/14/2013


The main idea of ​​the methodology and principles of RAD-development of information systems, its main advantages. Reasons for the popularity, features of the technology application. Formulation of the basic principles of development. Development environments using RAD principles.

presentation added on 04/02/2013


The role of the management structure in the information system. Examples of information systems. Structure and classification of information systems. Information Technology. Stages of information technology development. Types of information technology.

term paper added 06/17/2003


The concept of CASE-tools as software tools that support the creation and maintenance of information systems (IS). Features of IDEF-technology of IS development. Description of IDEF0 notation. Development of functional models of a business process.

presentation added on 04/07/2013


The essence of the unified modeling language, its conceptual model and principle of operation, general rules and mechanisms. Modeling the concept of "competence". Class diagram describing the educational process. Implementation of a given information system.

thesis, added 02/17/2015


Development of information systems. The modern market for financial and economic applied software. Advantages and disadvantages of implementing automated information systems. Methods for designing automated information systems.

thesis, added 11/22/2015


The concept of an information system, types of information systems. Analysis of tools for the development of automated information systems. Requirements for the program and software product. Development of forms of graphical interface and databases.

thesis, added 06/23/2015


Information security solution. Systems for data centers. What is data center hardware. Basic concepts and principles of modeling. The choice of a method for solving problems. Zoitendijk method of admissible directions, Frank – Wolfe algorithm.

term paper added 05/18/2017


Information system concept. Stages of development of information systems. Processes in the information system. Information system for finding market niches, for reducing production costs. The structure of the information system. Technical support.

The concept of a model is key in general systems theory. Modeling as a powerful - and often the only - research method implies the replacement of a real object with another - material or ideal.
The most important requirements for any model are its adequacy to the object under study within the framework of a specific task and the feasibility of the available means.
In efficiency theory and computer science, a model of an object (system, operation) is a material or ideal (mentally imaginable) system created and / or used in solving a specific problem in order to obtain new knowledge about the original object, adequate to it in terms of the studied properties and more simpler than the original in other respects.
The classification of the main modeling methods (and their corresponding models) is shown in Fig. 3.1.1.
In the study of economic information systems (EIS), all modeling methods are used, however, this section will focus on semiotic (sign) methods.
Recall that semiotics (from the Greek semeion - sign, feature) is the science of the general properties of sign systems, that is, systems of concrete or abstract objects (signs), with each of which a certain meaning is associated. Examples of such systems are any languages

Rice. 3.1.1. Classification of modeling methods

(natural or artificial, for example, data description or modeling languages), signaling systems in society and the animal world, etc.
Semiotics includes three sections: syntactics; semantics; pragmatics.
Syntactics studies the syntax of sign systems without regard to any interpretations and problems associated with the perception of sign systems as means of communication and communication.
Semantics studies the interpretation of statements of a sign system and, from the point of view of modeling objects, occupies the main place in semiotics.
Pragmatics examines the attitude of the person using the sign system to the sign system itself, in particular - the perception of meaningful expressions of the sign system.
Of the many semiotic models, due to the greatest distribution, especially in the context of informatization of modern society and the introduction of formal methods in all spheres of human activity, we will single out mathematical ones that reflect real systems using mathematical symbols. At the same time, taking into account the fact that we are considering modeling methods in relation to the study of systems in various operations, we will use the well-known methodology of systems analysis, the theory of efficiency and decision making.

More on the topic 3. TECHNOLOGY OF SIMULATION OF INFORMATION SYSTEMS Methods of modeling systems:

1. Simulation models of economic information systems Methodological foundations of the application of the method of simulation
2. Section III BASES FOR MODELING A SERVICE MARKETING SYSTEM
3. CHAPTER 1. CONTROLLED DYNAMIC SYSTEMS AS A COMPUTER SIMULATION OBJECT
4. Fundamentals of structural modeling of the marketing system of medical services
5. Section IV EXAMPLE OF APPLIED USE OF A MARKETING SYSTEM MODEL IN IMITATION MODELING
6. The concept of modeling the financial sphere of marketing systems

Tasks and functions of the information system.

IS can solve two groups of problems. The first group is associated with purely information support of the main activity (selection of the necessary messages, their processing, storage, search and delivery to the subject of the main activity with a predetermined completeness, accuracy and efficiency in the most acceptable form). The second group of tasks is associated with the processing of the received information / data in accordance with certain algorithms in order to prepare solutions to the tasks facing the subject of the main activity. To solve such problems, the IS must have the necessary information about the subject area. To solve such problems, the IS must have a certain artificial or natural intelligence. Information system - a system for supporting and automating intellectual work - search, administration, expertise and expert assessments or judgments, decision-making, management, recognition, knowledge accumulation, training. The tasks of the first group are the tasks of informatization of society "in breadth".

Tasks of the second group - tasks of informatization

society "deep".

To solve the assigned tasks, the IS should perform the following functions:

 selection of messages from the internal and external environment, necessary for the implementation of the main activity;

 input of information into IS;

 storing information in the memory of the IS, updating it and maintaining its integrity;

 processing, searching and issuing information in accordance with the requirements set by the ODS. Processing can also include preparation of options for solving user applied problems.

Information system (IS) is an interconnected set of tools, methods and personnel used for storing, processing and issuing information in order to achieve the set goal. The modern understanding of the information system involves the use of a personal computer as the main technical means of information processing. An IS is an environment, the constituent elements of which are computers, computer networks, software products, databases, people, various kinds of technical and software communications, etc. Although the very idea of ​​IP and some principles of their organization arose long before the advent of computers, however, computerization increased the efficiency of IP by tens and hundreds of times and expanded the scope of their application.

The functional structure of the information system.

In IS, it is advisable to distinguish three independent functional subsystems.

Information selection subsystem. The information system can process / process only the information that is entered into it. The quality of IS work is determined not only by its ability to find and process the necessary information in its own array and issue it to the user, but also by its ability to select relevant information from the external environment. Such selection is carried out by the information selection subsystem, which accumulates data on the information needs of IS users (internal and external), analyzes and organizes this data, forming an IS information profile.

The subsystem for input, processing / processing and storage of information transforms input information and requests, organizes their storage and processing in order to meet the information needs of IS subscribers.

The implementation of the functions of this subsystem assumes the presence of an apparatus for describing information (coding systems, data description language (DL), etc.), organizing and maintaining information (logical and physical organization, procedures for maintaining and protecting information, etc.), a processing apparatus and information processing (algorithms, models, etc.).

The subsystem for the preparation and issuance of information directly implements the satisfaction of information needs of IS users (internal and external). To accomplish this task, the subsystem conducts a study and analysis of information needs, determines the forms and methods of their satisfaction, the optimal composition and structure of output information products, organizes the process of information support and maintenance itself.

The implementation of these functions requires a device for describing and analyzing information needs and their expression in the IS language (including LOD, IPL, indexing language, etc.), as well as an apparatus for information support itself (procedures for searching and issuing information, data manipulation languages etc.). Many functions of IC subsystems are duplicated or overlapped, which is the subject of optimization in IC design. In this regard, the automation of IS is accompanied by a redistribution of IS elements.

Automation presupposes a formalized representation (structuring) of both the IS functions and the information processed in the IS itself, which allows the input, processing / processing, storage and retrieval of information using a computer. Any formalization is characterized by one or another level of adequacy of the created image of reality (model) of reality itself. Moreover, the adequacy of the model of reality is determined both by the properties of reality itself and by the capabilities of the apparatus used for its formalized representation.

From this point of view, the "level of automation" of IS is closely related to the "degree of structuredness" of information. There are three levels of structured information: Rigidly structured information (data) - information, the formalized representation of which by modern means of its structuring (in particular, data description languages) does not lead to the loss of the adequacy of the information model itself

information. Weakly structured information is information, the formalized presentation of which leads to significant losses in the adequacy of the information model of the initial information itself.

Unstructured information is information for which currently there are no means of its formalized presentation with an acceptable level of adequacy in practice. The means of presenting such information must have high semantic and expressive abilities. The development of such tools is currently going along the line of creating languages ​​for describing knowledge and IPL with high semantic power.

Information systems construction methodologies.

The industry for the development of automated information management systems originated in the 1950s - 1960s and by the end of the century acquired completely finished forms.

At the first stage, the main approach in the design of IS was the "bottom-up" method, when the system was created as a set of applications that are most important at the moment to support the activities of the enterprise. This approach is partly retained today. Within the framework of "patchwork automation", support for individual functions is quite well provided, but there is practically no strategy for the development of an integrated automation system

The next stage is associated with the realization of the fact that there is a need for fairly standard software tools for automating the activities of various institutions and enterprises. From the entire spectrum of problems, the developers have identified the most noticeable: automation of accounting, analytical accounting and technological processes. Systems began to be designed "top-down", i.e. on the assumption that one program must meet the needs of many users.

The very idea of ​​using a universal program imposes significant restrictions on the ability of developers to form the structure of the database, screen forms, and the choice of calculation algorithms. The rigid framework imposed "from above" does not make it possible to flexibly adapt the system to the specifics of the activity of a particular enterprise. Thus, the material and time costs for the implementation of the system and its fine-tuning to the customer's requirements usually significantly exceed the planned indicators.

According to statistics compiled by the Standish Group (SSL), of the 8,380 projects surveyed by SSL in 1994, more than 30% of projects with a total value of more than $ 80 billion failed. At the same time, only 16% of the total number of projects were completed on time, and cost overruns amounted to 189% of the planned budget.

At the same time, IS customers began to put forward more and more requirements aimed at ensuring the possibility of complex use of corporate data in the management and planning of their activities. Thus, an urgent need arose to form a new methodology for building information systems.

According to modern methodology, the process of creating an IS is a process of building and sequential transformation of a number of agreed models at all stages of the IS life cycle (LC). At each stage of the life cycle, specific models are created - organizations, requirements for

IP. IP project. application requirements, etc. Usually, the following stages of creating an IS are distinguished: the formation of requirements for the system, design, implementation, testing, commissioning, operation and maintenance.

The initial stage of the process of creating an IS is the modeling of business processes occurring in the organization and realizing its goals and objectives. The organization model, described in terms of business processes of business functions, allows you to formulate the basic requirements for IS.

The IS design is based on domain modeling. In order to obtain an IS project adequate to the subject area in the form of a system of correctly working programs, it is necessary to have an integral, systematic representation of the model, which reflects all aspects of the functioning of the future information system. In this case, a domain model is understood as a certain system that imitates the structure or functioning of the studied domain and meets the basic requirement - to be adequate to this domain.

Preliminary modeling of the subject area allows you to reduce the time and terms of design work and get a more efficient and high-quality project. Without modeling the domain, there is a high probability of making a large number of mistakes in solving strategic issues, leading to economic losses and high costs for subsequent redesign of the system. As a result, all modern IS design technologies are based on the use of domain modeling methodology.

The following requirements are imposed on domain models:

Formalization, providing an unambiguous description of the structure of the subject area;

Comprehensibility for customers and developers based on the use of graphic means of displaying the model;

Realizability, implying the availability of means of physical implementation of the domain model and IS;

Providing an assessment of the effectiveness of the implementation of the domain model based on certain methods and calculated indicators.

Functional modeling IDEF0: basic definitions and provisions.

The program of integrated computerization of production ICAM (ICAM - Integrated Computer Aided Manufacturing) is aimed at increasing the efficiency of industrial enterprises through the widespread introduction of computer (information) technologies. In the United States, this circumstance was realized back in the late 70s, when the US Air Force proposed and implemented

The IDEF (ICAM Definition) methodology makes it possible to study the structure, parameters and characteristics of production-technical and organizational-economic systems (in the future, where it does not cause confusion - systems). The general IDEF methodology consists of three specific modeling methodologies based on graphical representations of systems:

IDEF0 is used to create a functional model that displays the structure and functions of the system, as well as the flows of information and material objects connecting these functions.

IDEF1 is used to build an information model that displays the structure and content of information flows required to support the system's functions;

IDEF2 allows you to build a dynamic model of the time-varying behavior of functions, information and system resources.

By now, the most widespread and applied methodologies are IDEF0 and IDEF1 (IDEF1X), which have received the status of federal standards in the United States. The IDEF0 methodology, the features and application of which are described in this Guidance Document (GD), is based on the approach developed by Douglas T. Ross in the early 70s and called SADT (Structured Analysis & Design Technique - method of structural analysis and design). The approach and, as a consequence, the IDEF0 methodology are based on a graphical language for describing (modeling) systems, which has the following properties.

For the correct display of the interactions of IS components, it is important to carry out joint modeling of such components, especially from the content point of view of objects and functions.

The methodology of structural systems analysis greatly helps in solving such problems.

It is customary to call a structural analysis a method for studying a system, which begins with its general overview, and then is detailed, acquiring a hierarchical structure with an increasing number of levels. Such methods are characterized by: division into levels of abstraction with a limited number of elements (from 3 to 7); bounded context, including only the essential details of each level; use of strict formal recording rules; consistent approximation to the result.

Let's define the key concepts of the structural analysis of the enterprise (organization).

Operation is an elementary (indivisible) action performed at one workplace.

Function - a set of operations grouped according to a specific feature.

A business process is a related set of functions, during the execution of which certain resources are consumed and a product is created (object, service, scientific

discovery, idea), which is of value to the consumer.

A sub-process is a business process that is a structural element of some business process and is of value to the consumer.

A business model is a graphically structured description of a network of processes and operations associated with data, documents, organizational units and other objects that reflect the existing or intended activities of the enterprise. There are various methodologies for structural domain modeling, among which function-oriented and object-oriented methodologies should be distinguished.

Describing a system using IDEF0 is called a functional model. The functional model is intended to describe existing business processes, which uses both natural and graphical languages. To convey information about a specific system, the source of the graphical language is the IDEF0 methodology itself.

The IDEF0 methodology prescribes the construction of a hierarchical system of diagrams - single descriptions of system fragments. First, the system as a whole and its interaction with the outside world are described (context diagram), after which functional decomposition is carried out - the system is divided into subsystems and each subsystem is described separately (decomposition diagrams). Then each subsystem is broken down into smaller ones, and so on until the desired level of detail is achieved.

Tool environment BPwin.

Business process modeling is usually performed using case tools. These tools include BPwin (PLATINUM technology), Silverrun (Silverrun technology), Oracle Designer (Oracle), Rational Rose (Rational Software), etc. The functionality of the structural modeling tools for business processes will be discussed using the example of the BPwin case tool.

BPwin supports three modeling methodologies: functional modeling (IDEF0); description of business processes (IDEF3); data flow diagrams (DFD). BPwin has a fairly simple and intuitive user interface. When you start BPwin, by default, the main toolbar appears, the tool palette (the appearance of which depends on the selected notation) and, on the left, the model navigator - Model Explorer).

When creating a new model, a dialog appears in which you should specify whether the model will be created anew or it will be opened from a file or from the ModelMart repository, then enter the name of the model and select the methodology in which the model will be built.

As noted above, BPwin supports three methodologies - IDEF0, IDEF3 and DFD, each of which solves its own specific problems. In BPwin, it is possible to build mixed models, that is, a model can contain both IDEF0 and IDEF3 and DFD diagrams at the same time. The composition of the tool palette changes automatically when switching from one notation to another.

A model in BPwin is considered as a collection of activities, each of which operates on a certain set of data. Work is depicted as rectangles, data as arrows. If you click on any object of the model with the left mouse button, a context menu appears, each item of which corresponds to the editor of a certain property of the object.

At the initial stages of creating an IP, it is necessary to understand how the organization that is going to automate works. The manager knows the work as a whole well, but is not able to delve into the details of the work of each ordinary employee. An ordinary employee knows well what is happening in his workplace, but may not know how colleagues work. Therefore, to describe the work of an enterprise, it is necessary to build a model that will be adequate to the subject area and contain the knowledge of all participants in the organization's business processes.

The most convenient language for modeling business processes is IDEF0, where the system is represented as a set of interacting activities or functions. This purely functional orientation is fundamental - the functions of the system are analyzed independently of the objects with which they operate. This allows you to more clearly model the logic and interaction of the organization's processes.

The process of modeling a system in IDEF0 begins with the creation of a context diagram, a diagram of the most abstract level of the description of the system as a whole, containing the definition of the subject of modeling, the goal and point of view on the model.

Activities refer to named processes, functions, or tasks that occur over time and have recognizable results.

Works are depicted as rectangles. All jobs must be named and defined. The name of the job must be expressed by a verbal noun denoting an action (for example, "Company activity", "Taking an order", etc.). The work "Company Activities" may have, for example, the following definition: "This is a learning model describing company activities." When creating a new model (menu File / New), a context diagram is automatically created with a single work depicting the system as a whole.

Arrows describe the interaction of jobs and represent some kind of information expressed in nouns. (For example, "Customer Calls", "Rules and Procedures", "Accounting System".)

"Computer mathematical modeling" Objectives of studying the section. Mastering modeling as a method of cognizing the surrounding reality (scientific research nature of the section) - it is shown that modeling in various fields of knowledge has similar features, often for different processes it is possible to obtain very similar models; - demonstrates the advantages and disadvantages of a computer experiment in comparison with a full-scale experiment; - it is shown that both the abstract model and the computer provide an opportunity to cognize the surrounding world, to control it in the interests of man. Development of practical skills in computer modeling. The general methodology of computer mathematical modeling is given. On the example of a number of models from various fields of science and practice, practically all stages of modeling are implemented, from the formulation of the problem to the interpretation of the results obtained in the course of a computer experiment. Promoting vocational guidance for students. Revealing the student's aptitude for research activities, the development of creative potential, orientation towards the choice of a profession related to scientific research. Overcoming subject dissociation, knowledge integration. The course examines models from various fields of science using mathematics. Development and professionalization of computer skills. Mastering software for general and specialized purposes, programming systems.

Textbook for universities

2nd ed., Rev. and add.

2014 G.

Circulation 1000 copies.

Format 60x90 / 16 (145x215 mm)

Execution: paperback

ISBN 978-5-9912-0193-3

BBK 32.882

UDC 621.395

Grif UMO
Recommended by the UMO for education in the field of telecommunications as a textbook for students of higher educational institutions studying in the specialties "Networks and Switching Systems", "Multichannel Telecommunication Systems"

annotation

Algorithms for modeling discrete and continuous random variables and processes are considered. The principles and algorithms for modeling information signals described by Markov processes with discrete and continuous time are stated. The principles of modeling queuing systems are considered. The features of the description and use of fractal and multifractal processes for modeling telecommunication traffic are described. Methods and examples of modeling information systems using specialized software packages Matlab, Opnet, Network simulator are analyzed.

For students enrolled in the specialties "Networks and Switching Systems", "Multichannel Telecommunication Systems", "Information Systems and Technologies".

Introduction

1 General principles of system modeling
1.1. General concepts of model and modeling
1.2. Model classification
1.3. Model structure
1.4. Methodological foundations of formalizing the functioning of a complex system
1.5. Component Modeling
1.6. Stages of the formation of a mathematical model
1.7. Simulation modeling
Control questions

2 General principles of building communication systems and networks
2.1. The concept of building communication systems and networks
2.2. Layered network models
2.2.1. Three-tier model
2.2.2. TCP / IP protocol architecture
2.2.3. OSI Reference Model
2.3. Communication network structure
2.3.1. Global networks
2.3.2. Local area networks
2.3.3. Computer network topologies
2.3.4. Local Ethernet networks
2.4. Frame Relay networks
2.5. IP telephony
Control questions

3 Simulation of random numbers
3.1. Understanding random numbers
3.2. Programmatic methods for generating uniformly distributed random numbers
3.3. Formation of random variables with a given distribution law
3.3.1. Inverse function method
3.3.2. Approximate methods for converting random numbers
3.3.3. Screening Method (Neumann Generation Method)
3.4. Methods Based on the Central Limit Theorem
3.5. Algorithms for Modeling Frequently Used Random Variables
3.6. Algorithms for Modeling Correlated Random Variables
3.7. Formation of realizations of random vectors and functions
3.7.1. Modeling an n-dimensional random point with independent coordinates
3.7.2. Formation of a random vector (within the framework of the correlation theory)
3.7.3. Formation of implementations of random functions

4 Modeling discrete distributions
4.1. Bernoulli distribution
4.2. Binomial distribution
4.3. Poisson distribution
4.4. Simulation of trials in a random event scheme
4.4.1. Simulation of random events
4.4.2. Modeling opposite events
4.4.3. Modeling a discrete random variable
4.4.4. Modeling a complete group of events
4.5. Streams of events
4.6. Processing of simulation results
4.6.1. Precision and number of realizations
4.6.2. Primary statistical data processing
Control questions

5 Algorithms for modeling stochastic signals and interference in communication systems
5.1. Algorithm for modeling non-stationary stochastic processes
5.2. Algorithms for modeling stationary random processes
5.3. Methods for modeling signals and noise in the form of stochastic differential equations
5.4. Examples of models of stochastic processes in communication systems
5.4.1. Information process models
5.4.2. Interference Models
5.4.3. Characteristics of the main types of interference
Control questions

6 Markov stochastic processes and their modeling
6.1. Basic concepts of a Markov stochastic process
6.2. Basic properties of discrete Markov chains
6.3. Continuous Markov Chains
6.3.1. Basic concepts
6.3.2. Semi-Markov processes
6.3.3. Death and reproduction processes
6.4. Models of continuous-valued Markov random processes based on stochastic differential equations
6.5. Modeling Markov Stochastic Processes
6.5.1. Modeling discrete processes
6.5.2. Modeling scalar continuous-valued processes
6.5.3. Modeling continuous-valued vector processes
6.5.4. Modeling a Gaussian process with fractional-rational spectral density
6.5.5. Modeling multiply connected sequences
6.5.6. Modeling Markov Processes Using Shaping Filters
6.5.7. Algorithm for statistical modeling of Markov chains
Control questions

7 Examples of Markov models
7.1. Markov models of speech dialogue of subscribers
7.1.1. Speech states
7.1.2. Dialogue models
7.2. Markov models of speech monologue
7.3. Markov-driven Poisson process in speech models
7.4. Markov models of digital sequences at the output of the G.728 codec
7.5. Statistical multiplexing of the source of speech packets taking into account the Markov model of telephone dialogue
7.6. Markov model of a wireless channel with ARQ / FEC mechanism
7.7. Batching errors
7.8. Calculation of error stream characteristics by model parameters
7.8.1. Estimating the parameters of the error stream
7.8.2. Evaluation of the adequacy of the error flow model
7.9. Markov models for assessing the QoS of real-time multimedia services on the Internet
7.9.1. Real-time multimedia services concept
7.9.2. Analysis and modeling of delays and losses
7.10. Models of multimedia traffic streams
Control questions

8 Queuing systems and their modeling
8.1. General characteristics of queuing systems
8.2. Queuing system structure
8.3. Queuing systems with waiting
8.3.1. Service system M / M / 1
8.3.2. Service system M / G / 1
8.3.3. Networks with a large number of nodes connected by communication channels
8.3.4. Priority service
8.3.5. Service system M / M / N / m
8.4. Failure queuing systems
8.5. General principles of modeling queuing systems
8.5.1. Statistical test method
8.5.2. Block models of systems functioning processes
8.5.3. Features of modeling using Q-circuits
Control questions

9 Modeling information systems using typical technical means
9.1. System modeling and programming languages
9.2. Understanding the GPSS Language
9.2.1. Dynamic objects GPSS. Transaction-oriented blocks (operators)
9.2.2. Hardware-oriented blocks (operators)
9.2.3. Multichannel service
9.2.4. GPSS Statistical Blocks
9.2.5. Operating units GPSS
9.2.6. Other GPSS blocks
9.3. Simulation of the ETHERNET network in the GPSS environment
Control questions

10 Modeling of information transmission systems
10.1. Typical data transmission system
10.2. Immunity of transmission of discrete signals. Optimal reception
10.3. Estimation of the probability of erroneous reception of discrete signals with fully known parameters
10.4. Immunity of discrete signals with random parameters
10.5. Immunity of discrete signals with incoherent reception
10.6. Immunity of discrete signals with random essential parameters
10.7. Algorithms for the formation of discrete signals
10.8. Algorithm for generating interference
10.9. Algorithm for demodulation of discrete signals
10.10. The structure of the imitation complex and its subroutines
10.11. Mathworks Matlab software environment and Simulink visual modeling package
10.11.1. Technical description and interface
10.11.2. Simulink Visual Simulation Package
10.11.3. Subsystem creation and masking
10.11.4. Communications Toolbox Extension Pack
10.12. Modeling the blocks of the WiMAX data transmission system
10.12.1. Transmitter simulation
10.12.2. Modeling a transmission channel
10.12.3. Receiver simulation
10.12.4. Implementation of the model in the Mathlab system
10.13. Results of WiMAX System Simulation
Control questions

11 Self-similar processes and their application in telecommunications
11.1. Fundamentals of the theory of fractal processes
11.2. Multifractal processes
11.3. Estimation of the Hurst exponent
11.4. Multifractal analysis using software
11.4.1. Description of the software
11.4.2. Examples of assessing the degree of self-similarity
11.5. Algorithms and software for multifractal analysis
11.6. Influence of self-similarity of traffic on the characteristics of the service system
11.7. Methods for modeling self-similar processes in TV traffic
11.8. Exploring the Self-Similar Structure of Ethernet Traffic
11.9. Self-similar traffic congestion control
11.10. Fractal Brownian motion
11.10.1. RMD algorithm for generating FBD
11.10.2. SRA FWA Generation Algorithm
11.12. Fractal Gaussian noise
11.12.1. FFT algorithm for FGS synthesis
11.12.2. Evaluation of simulation results
Control questions

12 Modeling a telecommunications network node
12.1. Fundamentals of Frame Relay Protocol
12.2. Frame Relay Host Design
12.3. Simulation results of an FR router with G.728 codecs at the input
12.4. Impact of self-similarity of traffic on QoS
Control questions

13 Specialized systems for simulation of computer networks
13.1. General characteristics of specialized software packages for network modeling
13.2. General principles of modeling in the OPNET Modeler environment
13.3. OPNET Application Examples
13.3.1. Model for assessing the quality of service
13.3.2. Implementation of the local network model
Control questions

14 Simulation with Network simulator 2
14.1. History and architecture of the NS2 package
14.2. Create a simulator object
14.3. Creating a network topology
14.4. Setting generator parameters
14.4.1. Exponential On / Off
14.4.2. Pareto On / Off
14.5. Two main queuing algorithms
14.6. Adaptive Routing in NS2
14.6.1. User-level API
14.6.2. Internal architecture
14.6.3. Extensions to other classes
14.6.4. Flaws
14.6.5. List of commands used to simulate dynamic scripting in NS2
14.6.6. An example of dynamic routing in NS2
14.7. Running a script program in NS2
14.8. Simulation results processing procedure
14.9. An example of modeling a wireless network
14.10. An example of simulation of the quality of streaming video transmission using the NS 2 package
14.10.1. The structure of the hardware and software complex for assessing the quality of streaming video
14.10.2. PAK functional modules
14.10.3. Video quality assessment