How to set up smartphones and PCs. Informational portal
  • home
  • Interesting
  • Modeling of information systems. General requirements for course work

Modeling of information systems. General requirements for course work

Tasks and functions of the information system.

IS can solve two groups of problems. The first group is related to the purely information support of the main activity (selection of the necessary messages, their processing, storage, search and issuance to the subject of the main activity with a predetermined completeness, accuracy and efficiency in the most appropriate form). The second group of tasks is related to the processing of the received information/data in accordance with certain algorithms in order to prepare solutions to the problems 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, examinations and expert assessments or judgments, decision-making, management, recognition, accumulation of knowledge, training. The tasks of the first group are the tasks of informatization of society "in breadth".

Tasks of the second group - informatization tasks

society "deeper".

To solve the tasks set, 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;

 storage of information in the IS memory, its updating and maintenance of integrity;

 processing, search and issuance of information in accordance with the requirements set by the SOD. Processing may also include the preparation of options for solving user application problems.

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

Functional structure of the information system.

It is expedient to single out three independent functional subsystems in IS.

Information selection subsystem. An information system can process/process only the information that is entered into it. The quality of the work of an IS is determined not only by its ability to find and process the necessary information in its own array and give it to the user, but also by the 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 arranges these data, forming an information profile of IS.

The subsystem for input, processing/processing and storage of information converts 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 implies the presence of an apparatus for describing information (coding systems, a data description language (DDL), 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 preparing and issuing information directly implements the satisfaction of the information needs of IS users (internal and external). To accomplish this task, the subsystem conducts the study and analysis of information needs, determines the forms and methods of their satisfaction, the optimal composition and structure of the output information products, and organizes the process of information support and maintenance.

The performance of these functions requires the presence of a device for describing and analyzing information needs and their expression in the IS language (including DDL, IEL, indexing language, etc.), as well as a device for direct information support (procedures for searching and issuing information, languages ​​for manipulating data etc.). Many functions of IS subsystems are duplicated or intersected, which is the subject of optimization in the design of IS. In this regard, IS automation is accompanied by a redistribution of IS elements.

Automation involves a formalized representation (structuring) of both the IS functions and the information itself processed in the IS, which allows you to enter, process / process, store and search for 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 structuring" of information. There are three levels of information structuredness: 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 of the original information itself.

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

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

Methodologies for building information systems.

The industry for the development of automated information management systems originated in the 1950s and 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 continues to some extent today. Within the framework of “patchwork automation”, support for individual functions is quite well provided, but there is almost no strategy for the development of an integrated automation system.

The next stage is connected 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 whole range 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 should satisfy the needs of many users.

The very idea of ​​using a universal program imposes significant restrictions on the ability of developers to form a database structure, screen forms, and to choose calculation algorithms. The rigid framework laid down "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 of implementing the system and fine-tuning it to the requirements of the customer usually significantly exceed the planned figures.

According to statistics compiled by the Standish Group (SSL), out of 8,380 projects surveyed in the SSL in 1994, more than 30% of the projects were unsuccessful, with a total value of over $80 billion. 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 enabling the integrated use of corporate data in managing and planning their activities. Thus, there was an urgent need 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 sequentially transforming a number of consistent models at all stages of the life cycle (LC) of an IS. At each stage of the life cycle, specific models are created for it - organizations, requirements for

IS. IS project. application requirements, etc. Usually, the following stages of creating an IS are distinguished: the formation of system requirements, 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 an organization and realizing its goals. The organization model, described in terms of business processes of business functions, allows us to formulate the basic requirements for IS.

IS design is based on domain modeling. In order to obtain an IP project adequate to the subject area in the form of a system of correctly functioning programs, it is necessary to have a holistic, systemic representation of the model, which reflects all aspects of the functioning of the future information system. At the same time, a domain model is understood as some system that imitates the structure or functioning of the subject domain under study and meets the main requirement - to be adequate to this domain.

Preliminary modeling of the subject area allows you to reduce the time and timing of design work and get a more efficient and high-quality project. Without domain modeling, there is a high probability of making a large number of errors in solving strategic issues, leading to economic losses and high costs for the 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 that provides an unambiguous description of the structure of the subject area;

Clarity for customers and developers based on the use of graphical means of displaying the model;

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

Providing an estimate 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 recognized back in the late 70s, when the US Air Force proposed and implemented

The IDEF methodology (ICAM Definition) allows you to explore the structure, parameters and characteristics of production-technical and organizational-economic systems (hereinafter, where it does not cause misunderstanding - systems). The general IDEF methodology consists of three particular modeling methodologies based on the graphical representation of systems:

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

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

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

To date, the IDEF0 and IDEF1 (IDEF1X) methodologies, which have received the status of federal standards in the United States, are the most widespread and used. The IDEF0 methodology, the features and methods of 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 - a method of structural analysis and design). The basis of the approach and, as a result, of the IDEF0 methodology, is a graphical language for describing (simulating) systems, which has the following properties.

To correctly display 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 helps a lot in solving such problems.

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

Let us define the key concepts of the structural analysis of the activity of an enterprise (organization).

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

Function - a set of operations grouped according to a certain attribute.

A business process is a connected set of functions during which certain resources are consumed and a product (subject, service, scientific product) is created.

discovery, idea) that 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 proposed activities of an enterprise. There are various methodologies for structural modeling of the subject area, among which it is necessary to single out functionally-oriented and object-oriented methodologies.

Describing a system using IDEF0 is called a functional model. The functional model is intended to describe existing business processes, which use both natural and graphic languages. To convey information about a particular 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, a description of the system as a whole and its interaction with the outside world (context diagram) is carried out, after which a 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 required degree of detail is reached.

BPwin tool environment.

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

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 side, the model navigator - Model Explorer).

When creating a new model, a dialog appears in which you should specify whether the model will be created again or whether 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 mentioned above, BPwin supports three methodologies - IDEF0, IDEF3 and DFD, each of which solves its specific problems. In BPwin, it is possible to build mixed models, i.e. a model can contain both IDEF0, 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 viewed as a set of activities, each of which operates on some set of data. Work is shown 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 some property of the object.

At the initial stages of creating an IS, it is necessary to understand how the organization that is going to be automated works. The manager knows the work well in general, 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 his colleagues work. Therefore, to describe the work of the 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 business process modeling language is IDEF0, where the system is represented as a set of interacting activities or functions. Such a purely functional orientation is fundamental - the functions of the system are analyzed independently of the objects they operate on. 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 describing the system as a whole, containing the definition of the modeling subject, purpose and point of view on the model.

Activities refer to named processes, functions, or tasks that take place over time and have recognizable outcomes.

Items are shown as rectangles. All works must be named and identified. The job name must be a verbal noun denoting an action (for example, "Company activities", "Order taking", etc.). The "Company Activities" work could have, for example, the following definition: "This is a tutorial model that describes the activities of a company." When creating a new model (File/New menu), a context diagram is automatically created with a single job depicting the system as a whole.

Arrows (Arrow) describe the interaction of work and represent some information expressed by nouns. (For example, "Customer calls", "Rules and procedures", "Accounting system".)

"Computer mathematical modeling" Problems of studying the section. Mastering modeling as a method of cognition of the surrounding reality (research nature of the section) - it is shown that modeling in various fields of knowledge has similar features, it is often possible to obtain very similar models for various processes; - the advantages and disadvantages of a computer experiment in comparison with a full-scale experiment are demonstrated; - it is shown that both the abstract model and the computer provide an opportunity to know the world around, to control it in the interests of man. Development of practical skills of 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, all stages of modeling are practically 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. Identification of the student's propensity for research activities, development of creative potential, orientation towards the choice of a profession related to scientific research. Overcoming subject disunity, integration of knowledge. As part of the course, models from various fields of science are studied using mathematics. Development and professionalization of computer skills. Mastery of software of general and specialized purpose, programming systems.







































1 of 38

Presentation on the topic: Information systems modeling

slide number 1

slide number 2

Description of the slide:

The purpose of the course is to deepen core subjects (computer science, mathematics); formation of competencies for professional activities in the field of information modeling Motivation of students when choosing an EC. - testing by students of their abilities and interest in creative, research activities in the field of information modeling; - preparation for entering a university for specialties related to information modeling and computer technology: applied mathematics, modeling, computer systems, etc.

slide number 3

Description of the slide:

slide number 4

Description of the slide:

Contents of the textbook Chapter 1. Modeling of information systems 1.1. Information systems and systemology 1.2. Relational model and databases (Access) 1.3. The spreadsheet is an information modeling tool 1.4. Application programming (VBA elements for Excel) Chapter 2. Computer mathematical modeling 2.1. Introduction to modeling 2.2. Tools for computer mathematical modeling (Excel, MathCad, VBA, Pascal) 2.3. Modeling of optimal planning processes 2.4. Computer Simulation Applications

slide number 5

Description of the slide:

"Modeling and development of information systems" The objectives of the study of the section The general development and formation of the worldview of students. The main ideological component of the content of this section of the course is the formation of a systematic approach to the analysis of the surrounding reality. Mastering the basics of the methodology for building information reference systems. Students gain an understanding of the stages of information system development: the design stage and the implementation stage. The creation of a multi-table database takes place in the MS Access relational DBMS environment. Students learn how to build a database, applications (queries, reports), interface elements (dialog boxes). Development and professionalization of computer skills. The skills acquired in the basic course are further developed. - working with vector graphics when building structural models of systems - in-depth study of the capabilities of the MS Access DBMS - using MS Excel as a means of working with a database - programming in VBA in Excel to develop an interface - when working on abstracts, it is recommended to use Internet resources; prepare material for protection in the form of a presentation (Power Point)

slide number 6

Description of the slide:

Project-based teaching method Statement of the problem: Subject area: secondary school Project goal: creation of the information system "Educational process" Purpose of the information system: inform users: About the student composition of the classes About the teaching staff of the school About the distribution of the teaching load and class management About the progress of students

slide number 7

Description of the slide:

slide number 8

Description of the slide:

slide number 9

Description of the slide:

slide number 10

Description of the slide:

slide number 11

Description of the slide:

slide number 12

Description of the slide:

Application development Applications: queries, reports Task. It is required to obtain a list of all girls from the ninth grade, whose annual grades in computer science are fives. Subschema Concept Using a hypothetical query language.choosing STUDENTS.SURNAME, STUDENTS.FIRST, STUDENTS.CLASS for STUDENTS.CLASS='9?'and STUDENTS.SEX='w' and GROWTH.SUBJECT='computer science' and GROWTH.YEAR=5 sort PUPILS.SURNAME in ascending order

slide number 13

Description of the slide:

slide number 14

Description of the slide:

slide number 15

Description of the slide:

VBA Application Programming Private Sub CommandButton1_Click() "Variable declaration Dim i, j, n As Integer Dim Flag As Boolean "Data initialization Flag = False "The number of rows in the list of schools is determined n = Range("A3").CurrentRegion.Rows. Count "Search the list for the number of the school specified in the 'TextBox1 input field" For i = 3 To n+2 If Cells(i, 1).Value = Val(UserForm1.TextBox1.Text) Then Flag = True Exit For End If Next Fragment of the event handler "Click on the SEARCH button"

slide number 16

Description of the slide:

"Computer mathematical modeling" The tasks of studying the section Mastering modeling as a method of cognizing the surrounding reality (research nature of the section) - it is shown that modeling in various fields of knowledge has similar features, often very close models can be obtained for various processes; - the advantages and disadvantages of a computer experiment in comparison with a full-scale experiment are demonstrated; - it is shown that both the abstract model and the computer provide an opportunity to know the world around, to control it in the interests of man. Development of practical skills of 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, all stages of modeling are practically 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. Identification of the student's propensity for research activities, development of creative potential, orientation towards the choice of a profession related to scientific research. Overcoming subject disunity, integration of knowledge. As part of the course, models from various fields of science are studied using mathematics. Development and professionalization of computer skills. Mastery of software of general and specialized purpose, programming systems.

slide number 17

Description of the slide:

slide number 18

Description of the slide:

Modeling of optimal planning processes The task of planning the operation of a service station Statement of the problem Let a car service station perform two types of service: TO-1 and TO-2. Cars are accepted at the beginning of the working day and issued to customers at the end. Due to the limited parking area, a total of no more than 140 cars can be serviced per day. The working day lasts 8 hours. If all cars passed only TO-1, then the station's capacity would allow servicing 200 cars a day, if all cars passed only TO-2, then 50. The cost (for the client) of TO-2 is twice as high as TO-1. In reality, some cars pass TO-1, and some, on the same day, TO-2. It is required to draw up such a daily maintenance plan in order to provide the enterprise with the greatest cash receipts.

slide number 19

Description of the slide:

Modeling of optimal planning processes Formalization and mathematical model of the problem Planned indicators x - daily production plan TO-1; y is the daily plan for the production of TO-2. The system of inequalities follows from the statement of the problem. The greatest profit will be achieved at the maximum value of the function The function f(x, y) is called the objective function, and the system of inequalities is called the system of constraints. Got a linear programming problem

slide number 20

Description of the slide:

slide number 21

Description of the slide:

Modeling of optimal planning processes Methods for solving a linear programming problem Simplex method - a universal way to solve a linear programming problem Simplex table Basis St. member. x1 ¼ xi ¼ xr xr+1 ¼ xj ¼ xn x1 b1 1 ¼ 0 ¼ 0 a1,r+1 ¼ a1j ¼ a1n xi bi 0 1 ¼ 0 ai,r+1 ¼ aij ¼ ain ¼ ¼ ¼ ¼ ¼ ¼ ¼ ¼ xr br 0 0 ¼ 1 ar,r+1 ¼ arj ¼ Arn f 0 0 0 ¼ 0 gr+1 ¼ gj ¼ gn

slide number 22

Description of the slide:

slide number 23

Description of the slide:

slide number 24

Description of the slide:

slide number 25

Description of the slide:

Modeling Optimal Scheduling Processes Private Sub CommandButton1_Click() Dim d(5, 9) As Variant Dim i, j, r, n, k, m As Integer Dim p, q, t As String Dim a, b As Double For i = 1 To 5 For j = 1 To 9 d(i, j) = Range("a6:i10").Cells(i, j).Value Next j Next in = 7: r = 3 " Analysis of the optimality of the current solution' t = "next" Do While t = "next" Simplex Method Program in VBA for Excel (fragment)

slide number 28

Description of the slide:

slide number 29

Description of the slide:

Modeling of optimal planning processes The problem of planning work on the construction of the road Statement of the problem There are two points - the initial H and the final K; from the first to the second it is necessary to build a road, which consists of vertical and segments. The cost of construction of each of the possible segments is known (shown in the figure). In reality, the road will be some broken line connecting the points H and K. It is required to find such a line that has the least cost. This is a dynamic programming problem

Description of the slide:

slide number 33

Description of the slide:

Computer simulation The apparatus of mathematical statistics is used Random events: - time interval between two transactions - transaction service time Functions of probability density distribution of random events Uniform distribution Gaussian normal distribution Poisson distribution

Description of the slide:

Planned learning outcomes for EC. Students should know: the purpose and composition of information systems; stages of creating a computer information system; basic concepts of systemology; existing varieties of system models; what is an infological domain model; what is a database (DB); database classification; relational database structure (RDB); database normalization; what is a DBMS; how relationships are organized in a multi-table database; what types of database queries exist; what is the structure of the query command for fetching and sorting data; What are the possibilities for working with databases has a spreadsheet processor (MS Excel); how to create and execute a macro in MS Excel; what is an object-oriented application; basics of programming in VBA; the content of the concepts "model", "information model", "computer mathematical model";

slide number 36

Description of the slide:

stages of computer mathematical modeling, their content; composition of tools for computer mathematical modeling; the capabilities of the spreadsheet processor Excel in the implementation of mathematical modeling; the capabilities of the MathCAD system in the implementation of computer mathematical models; specifics of computer mathematical modeling in economic planning; examples of meaningful tasks from the field of economic planning, solved by computer simulation; formulation of problems solved by the method of linear programming; formulation of problems solved by the method of dynamic programming; the basic concepts of probability theory necessary for the implementation of simulation modeling: a random variable, the law of distribution of a random variable, the probability density of distribution, the reliability of the result of a statistical study; methods for obtaining sequences of random numbers with a given distribution law; formulation of problems solved by simulation in queuing theory.

slide number 37

Description of the slide:

Students should be able to: design a simple information and reference system; design a multi-table database; navigate in the MS Access DBMS environment; create a database structure and fill it with data; to carry out select queries in MS Access using the query designer; work with forms to carry out requests with obtaining the final data; receive reports; organize single-table databases (lists) in MS Excel; select and sort data in lists; filter data; create pivot tables; record macros for MS Excel using a macro recorder; write simple event handling programs in VBA. apply the scheme of a computer experiment in solving meaningful problems where there is a need for computer mathematical modeling; select factors influencing the behavior of the system under study, perform ranking of these factors;

slide number 38

Description of the slide:

build models of the processes under study; choose software tools for the study of the constructed models; analyze the results obtained and explore the mathematical model for various sets of parameters, including boundary or critical ones; use simple optimization economic models; build the simplest models of queuing systems and interpret the results. to implement simple mathematical models on a computer, creating algorithms and programs in the Visual Basic language; use the capabilities of TP Excel to carry out simple mathematical calculations and illustrate the results of mathematical modeling with graphs and bar charts; use the tool "Search for a solution" TP Excel to solve problems of linear and non-linear programming; use the MathCAD system to carry out simple mathematical calculations, graphic illustration of the simulation results; use the MathCAD system to solve problems of linear and nonlinear optimization.


The concept of a model is a key one 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 its feasibility by available means.
In efficiency theory and informatics, a model of an object (system, operation) is a material or ideal (mentally representable) 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 simple than the original in other aspects .
The classification of the main modeling methods (and the models corresponding to them) is shown in fig. 3.1.1.
In the study of economic information systems (EIS), all modeling methods are used, however, in this section, the main attention will be paid to semiotic (sign) methods.
Recall that semiotics (from the Greek semeion - sign, sign) is the science of the general properties of sign systems, i.e. systems of concrete or abstract objects (signs), each of which is associated with a certain value. 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 explores the syntax of sign systems without regard to any interpretations and problems associated with the perception of sign systems as a means of communication and communication.
Semantics studies the interpretation of the statements of a sign system and, from the point of view of modeling objects, occupies the main place in semiotics.
Pragmatics explores the attitude of the user of 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 conditions of informatization of modern society and the introduction of formal methods in all spheres of human activity, we single out mathematical ones that display 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 system analysis, efficiency theory 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 for the application of the simulation method
  2. Section III BASES OF MODELING THE SYSTEM OF MARKETING SERVICES
  3. CHAPTER 1. CONTROLLED DYNAMIC SYSTEMS AS AN OBJECT OF COMPUTER SIMULATION
  4. Fundamentals of structural modeling of the marketing system of medical services
  5. Section IV EXAMPLE OF APPLIED USE OF THE MARKETING SYSTEM MODEL IN SIMULATION MODELING
  6. The concept of modeling the financial sphere of marketing systems

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.

Hosted at http://www.allbest.ru/

Omsk State Service Institute

Modeling information systems using the UML language

Guidelines for the implementation of the course work

I.V. Chervenchuk

  • Introduction
  • 2 . Unified Modeling LanguageUML
  • 4. Development of a software system model by means ofUML
  • 5. Issues of implementation of the information system
  • 6. Themes of term papers
  • 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 on 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. Given options for assignments for coursework.

The guidelines are intended for students of the specialty "Applied Informatics" and can be used in the course work, preparing for the exam, as well as in the process of independent work.

1. General requirements for the course work

Course work on the discipline "Information systems and processes. Modeling and management" is the final stage of the study of 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 using the unified modeling language UML with its subsequent implementation. As a typical option for the task, 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 proposed as a task. In this case, the main necessary requirement is the use of an object-oriented approach and the construction of a UML model.

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

Introduction

1. A meaningful overview of the subject area. Basic system requirements

2. Detailed model of the information system

2.1 View in terms of use cases

2.2 Design view

2.3 Implementation view

2.4 Process view (if required)

2.5 Deployment view (if necessary)

3. Implementation of the information system

Conclusion

Application Listing of a program or head module

In the introduction, one can point out the use of information technologies 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 the explanatory note, providing them with detailed comments, and the program texts should be included in the application.

The process view should be given when developing 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 options for the course work.

When covering system implementation issues in a note, it is desirable to justify the choice of a programming environment and 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 conclusion, the main results of the work are briefly summarized: a UML model of the system has been developed, the system has been implemented using such and such a programming environment that the developed system allows, the advantages of the approaches used (based on modeling) to system design.

modeling information system language

Coursework should contain 20-30 pages of printed text with illustrations. Diagrams of precedents, classes, interactions must be given without fail.

2. Unified Modeling Language UML

The rational development of an information system involves a deep preliminary analytical study. First of all, it is necessary to outline the range of tasks performed by the developed system, then, to develop a model of the system, and finally, to determine the ways of implementation. 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.

UML modeling language tools (Unified Model Language, - a unified programming language) make it possible to expressively and quite easily make 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 information system being developed as a software product.

UML is a language for visualizing, specifying, constructing and documenting the artifacts of software systems based on an object-oriented approach.

UML, like any other language, consists of a vocabulary and rules that allow you to combine the words in it and get meaningful constructs. In the modeling language, the vocabulary and rules are focused on the conceptual and physical representation of information systems. Modeling is necessary to understand the system. However, 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. When applied to software systems, this means that a language is needed that can be used to describe representations of a system's architecture from various points of view throughout its development cycle.

UML is a visualization language, and UML is not just a set of graphic symbols. There are well-defined semantics behind each of them (see ) Thus, a model written by one developer can be unambiguously interpreted by another or even by a tool.

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 UML is not a visual programming language, 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 to relational database tables or persistent object-oriented database objects. Those concepts that are preferably conveyed graphically are represented in the UML; those that are best described in textual form are expressed using a programming language.

Such a mapping of the model to the programming language allows direct design: code generation from the 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 tools 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 provide consistency between both representations.

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

UML is a documentation language

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

system requirements;

architecture;

project;

source;

project plans;

tests;

prototypes;

versions, etc.

Depending on the development methodology adopted, some works are performed more formally, others less so. The referenced documents are not just deliverable 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.

UML offers the developer and management its own solution to the problem of documenting the system architecture and all its details, offers a language for formulating system requirements and defining tests, and, finally, provides tools for modeling work at the stage of project planning and version control.

Consider the development of an information system model using the UML language using the example of the development of an automated workplace of the secretary of the department (hereinafter referred to as the workstation of the secretary of the department).

3. Description of the subject area

The concept of the subject area of ​​a database is one of the basic concepts of computer science and does not have a precise definition. Its use in the context of IS assumes the existence of a time-stable correlation between names, concepts and certain realities of the outside world, independent of the IS itself and its circle of users. Thus, the introduction to the consideration of the concept of the subject area of ​​the database limits and makes visible the space of information retrieval in the IS and allows you to execute queries in a finite time.

By the description of the subject area we will understand 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 main terms (the dictionary of the system) are introduced, the types of users and their rights are defined, and the tasks that the developed system should solve are formulated. At the same time, when describing, it is supposed to use the means of a common language and standard business graphics (figures, diagrams, tables).

When developing a system dictionary, it is necessary to define the names of entities ("student", "teacher", "discipline"). At the same time, the term entity 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 turned into entities by the analyst.

An entity is the result of abstracting a real object. There are two problems with objects: identification and adequate description. For identification use the name, which must be unique. At the same time, it is assumed that there is a rejection of its meaning, which is inherent in natural language. Only the name pointer function is used. A name is a direct way of identifying an object. Indirect methods of identifying an object include the definition of an object through its properties (characteristics or features).

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 inclusion relationship. Thus, all information about objects and entities of the subject area is described using statements in natural language.

You can specify structural relationships, 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 tools for describing the subject area, for example, UML language tools.

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

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

teachers - teachers of the department;

students- university students of the given 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 supervisor;

discipline- taught discipline (subject, course).

Maintained entities have a number of attributes that we will define later.

We manage two types of users: ordinary user(further user, And administrator. It is assumed that user can access the system with a request, display reports, administrator can additionally modify the 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 introduced terms, the developed system should provide:

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

information support for management decisions, the formation of complete and reliable information about educational processes and the results of the department;

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

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

convenient user interface;

differentiation of powers of ordinary users and administrator.

In this example, we are solving a particular problem - we are developing an workstation for the secretary of the department, so the department, which we will have in mind by default, is taken as the structural unit of the highest level for us, that is, it is assumed that all elements of the model apply only to this department, which is not explicitly specified . Structures of a higher level, such as a faculty, a university, will not be considered by us.

4. Development of a software system model using UML

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

A UML diagram is a graphical representation of a set of elements, most often depicted as a connected graph with vertices (entities) and edges (relations). Diagrams characterize the system from different points of view. The diagram is, in a sense, one of the projections of the system. As a rule, diagrams give a collapsed view of the elements that make up the system. The same element can be present in all diagrams, or only in a few (the most common), or not present in any (very rare). Theoretically, 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, there are nine types of diagrams in the UML:

class diagrams

object diagrams;

use case diagrams;

sequence diagrams;

cooperation diagrams;

state diagrams;

action (activity) diagrams;

component diagrams;

deployment diagrams.

Conceptual UML Model

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

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

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

Sequence 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 a system. At the same time, sequence diagrams reflect the temporal ordering of messages, and cooperation diagrams reflect the structural organization of objects exchanging messages. These diagrams are isomorphic, that is, they can be transformed into each other.

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

An activity diagram is a special case of a state diagram; it represents the transitions of the flow of control from one activity to another within the system. Activity diagrams refer to the dynamic view of the 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 that exist between them. Component diagrams refer to the static view of a system from an implementation point of view. They can be related to class diagrams, since a component is usually mapped 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 node usually hosts one or more components.

This 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 the view in terms of use cases

Modeling begins with the definition of the main tasks of the system being developed and the actions that it must perform. Use case diagrams are used for this purpose. As already mentioned, use case diagrams indicate use cases and actors, as well as the relationships between them.

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

An actor is a connected set of roles that users of use cases perform while interacting with them. Typically, an actor represents a role played by a person, a hardware device, or even another system 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 the use cases. At the same time, it is desirable to give the names of precedents so that they indicate the behavior, often such names contain verbs, for example, "generate a report", "find data by a criterion", etc. You can name use cases with nouns that suggest some action, for example, "authorization", "search", "control".

Returning to modeling the workstation of the secretary of the department, we highlight the precedents:

Editingdata,

Searchstudent,

Searchteacher,

extraditionlisttaughtdisciplines,

Authorization.

Use case diagram elements (use cases and actors) must be related.

The most common relationship between use cases, use cases, and actors is association. In some cases generalization relations 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 - the inclusion relation and the extension relation.

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). An included use case never exists autonomously, but is only instantiated as part of an enclosing use case. You can think of the base use case as borrowing the behavior of the included ones. Due to the presence of inclusion relations, it is possible to avoid multiple descriptions of the same flow of events, since the general behavior can be described as an independent precedent included in the base ones. An include relationship is an example of delegation, where a set of system responsibilities are described in one place (in an included use case), and other use cases include those responsibilities in their set as needed.

Inclusion relationships are depicted as dependencies with the "include" stereotype. 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 relationship is used to model parts of a use case that the user perceives as optional behavior of the system. This way you can separate required and optional behavior. Extension relationships are also used to model individual subflows that run only under certain circumstances. Finally, they are used to model multiple threads that can be triggered at some point in a script as a result of explicit interaction with an actor.

An extension relationship is depicted as a dependency with the "extend" stereotype. Base scenario extension points are listed in the optional section. They are simply labels that can appear in the base use case stream.

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

In our case, the precedent editingdata includes precedents: inputdata, removaldata, changedata.

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

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

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

When developing a view in terms of use cases, it is often necessary to provide an extended description of the use case (in the abbreviated version, only its name is indicated). As a rule, at the beginning of work, the flow of events of a use case is described in textual form. As the requirements for the system become more precise, it will be more convenient to move to a graphical depiction of flows in activity and interaction diagrams.

Event streams can be described using unstructured text, structured text (containing function words: IF,BEFORETHOSEPORTILL etc.), a specialized formal language (pseudocode).

When describing a precedent by 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 starts when the system prompts the user for their login name (Login) and password (Password). The user can enter it from the keyboard. End input by pressing the key Enter. After that, the system checks the entered Login and password, and if they correspond to the administrator, confirms the administrator's authority. This is where the precedent ends.

Exceptional flow events. The client can terminate the transaction at any time by pressing the key Cancel. This action restarts the use case. There is no entry into the system.

Exceptional flow events. The Client may, at any time before pressing the Enter key, delete his Login and password.

Exceptional flow events. If the client has entered Login and password that do not correspond to the administrator, he is prompted to re-enter or log in as a regular user.

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

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

Similar diagrams can also explain the execution of other use cases, thus complementing the view of the system in terms of use cases.

Rice. 2. User authorization. Activity diagram.

4.2 Design view from a design point of view

The design view is the main step in conceptualizing a model. At this stage, the main abstractions are introduced, classes and interfaces are defined through which the solution of the tasks is implemented. If the precedents 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 precedents 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, collaborations, as well as relationships 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 you should decide which entities are more convenient to model as classes, and which as their attributes. For example, if it were required within the faculty to specify a head for each department, it would be better to specify the entity managerdepartments make it a class attribute department indicating the class teachers ( one-to-one association ), rather than introducing a separate class managerdepartments.

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 domain or solution domain;

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

maintains a clear separation of abstraction specifications and its implementation;

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

As part of the development of the AWP model of the secretary of the department, we define the classes: teachers, students, graduate students, disciplines, groups. Obviously, the first of them have many common attributes, so we introduce an abstract class Person, which will encapsulate all properties related to a person in the context of the system being developed (last name, first name, address, etc.). In this case a person will be a superclass and be associated by a generalization relation with 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). It should be noted 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 (displayed as a dotted arrow with an open tip, the arrow points from dependent to independent). In our case, changing the class structure 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 primitive type T_ POSTIDX, defined as a six-digit decimal number. Primitive types are modeled by the stereotype " type" , the range of values ​​is specified through the restrictions enclosed in curly braces.

In the class teacher Let's highlight specific attributes that apply only to the teacher: position, uch. degree(academic degree), uch. rank ( academic title) discharge(category of the unified tariff scale). Attributes uch. degree And uch. rank it is better to define specialized types via an enum. Enums are modeled by a class with the stereotype " enum" (enumeration - enumeration), valid values ​​are written as attributes, labels that determine the visibility of attributes are suppressed. In the example under consideration, through the enumeration, we introduce specialized classes T_Must, T_UchSt, T_UchSv, defining, respectively, possible positions, academic degrees, academic titles through enumerations. In this case, as elsewhere in similar cases, when creating classes that specify the attributes of the main class, dependency relationships are established.

For class student a specific attribute is entered roomstudent's books. Specific attributes are defined for the postgraduate class the formlearning And date ofreceipts. The form of training is determined by a special class through enumeration T_FormEducation(full-time, part-time).

Class Group has attributes: title, the form learning, numberstud. ( number of students ). Given that the teachers of the department in question can conduct classes with 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 defined through enumerations.

Class discipline has attributes: room, title, cycle. Attribute cycle by means of a specialized type introduced via an enumeration T_cycles determines to 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, all the more you cannot specify them in the class speciality. These attributes refer to a pair of specialty-discipline and are defined in the class - associations Disciplines-specialties.

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

When visualizing the structure of classes, you should pay attention to the visibility of attributes. All considered attributes must be accessible and have the visibility Public (denoted by a "+" sign or an icon without a padlock). In the considered classes, we focused on the structure, not on the behavior (operations were not described and are not supposed to be described), therefore, to facilitate the perception of the diagram, it is desirable to suppress the representation of operations.

On the introduced set of classes, it is necessary to redefine the links. Generalization relationships and dependencies have already been defined, it remains to define associations.

students formed in groups, in this case the association will look like an aggregation. Aggregation implies a part-whole relationship, denoted by a solid line with a rhombus at the end from the side of the whole (in our case groups). The multiplicity of the student-group relationship is many-to-one. Each Group refers to a certain specialty, in turn, several groups can correspond to a certain specialty, so the group-specialty association also has a many-to-one multiplicity type.

In this case, as in most others, the direction of the 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 according to the "many-to-many" type: a teacher can lead several disciplines, some disciplines can be taught by several teachers. Between disciplines And specialties a many-to-many association is also established: the curriculum of specialties contains many disciplines, most of the disciplines are found in the work plans of several specialties. An 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 groups And teachers: teachers conduct classes in groups, the type of multiplicity association is many-to-many. direct association between groups And disciplins does not need to be defined, since this relationship is traced through the linking class speciality.

In order to display the presence of a supervisor in a graduate student, it is necessary to introduce an association between the graduate student and the teacher according to 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. Class diagram of the workstation of the secretary of the department (option 2)

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

PhD students can also lead classes in a certain discipline with certain groups: many-to-many associations postgraduate groups, graduate students-disciplines. Some graduate students may not teach classes, 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

Given that both graduate students and teachers teach classes, you can introduce an additional abstract class, for example, teaching, which is a descendant of the class a person and superclass for classes teacher And graduate student, which will reduce the number of connections somewhat. (Fig. 4.). In this case, from classes discipline And Group associations will go to class teaching, assuming association with classes teacher And graduate student through inheritance (generalization relation). To class teaching attributes can be removed bid(0.5 bet, full bet) and discharge.

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

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

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

Interface (Interface) is a set 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 defines only specifications of operations (signatures), never their implementations. The graphical interface is depicted as a circle, under which its name is written. An interface rarely exists on its own - it's usually attached to an implementing class or bean. An interface always assumes the existence of some "contract" between the party that declares the execution of a number of operations and the party that implements these operations.

Put a class on the diagram electronictable, which encapsulates all the properties and operations of a spreadsheet that allows editing data. The structure of this class will not be disclosed 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 the TTable class, which encapsulates the capabilities of a spreadsheet. Class descendants electronictable are specific spreadsheets containing specific data on teachers, graduate students, students, groups, disciplines and specialties. 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). It is assumed that in the class electronictable these features have been implemented.

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

Define Interfaces Searchteacher, Searchdisciplines, by attaching them to the corresponding classes with implementation relations. We will not disclose the composition of the operations of these interfaces (it is rather trivial), so we will display the interfaces in an abbreviated form (in the form of a circle). Recall that an implementation relation attached to an interface in short form is shown 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 displayed as a dotted 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. To facilitate 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(encoded table) containing passwords ( password) and input names ( login) administrator users. It is assumed that the capabilities of the utility class CodirTable prevent unauthorized users from reading user passwords. At this design stage, 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 access rights management are implemented.

Indicate the dependency 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 class diagram of the workstation of the secretary of the department

The final diagram is shown in fig. 6.

So, the development of an object-oriented model of the department secretary's workstation using the UML class diagram at this stage can be considered complete. Naturally, it is possible to return to it and revise some elements in the course of system design, when adjusting tasks, when clarifying individual details. The process of designing information systems 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 (the implementation is assumed in the classes corresponding to the interface), or a public class operation, 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 consider the process of creating a new record about a student using sequence diagrams.

Creating a new record requires administrator rights, so the actor in this interaction will be the administrator ( admin). This element has already been entered in the Use Case Diagram, so let's drag it onto the Sequence Diagram from the Use Case View Browser.

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

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

The forminput- user interface element, is a typical form for entering data about a student (last name, first name, patronymic, address, etc.). In our case, it is a slightly predefined 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 the 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 explicitly specifies the class of which it is an instance - students.

Petrov- a specific record about student Petrov, a new element of the table about students. Here we explicitly indicate the introduced class entryaboutstudent. Such objects usually exist temporarily to send the 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 re-created if the information needs to be edited.

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

The diagram of the sequence of entering a new record about a student in the workstation of the secretary of the department is shown in fig. 7.

Rice. 7. Entering student data. Sequence diagram.

On the sequence diagram, we define the transfer of messages between objects: createnewentry(broadcast from object to object to the end of the chain as a message saveentry); openform(to the input form); enterF.AND ABOUT.,the address. ( data entry for a student), then these data are broadcast by messages saveF.AND ABOUT.,the address. From managertransactions a message is sent to collect informationaboutstudent, providing feedback to the database, and finally a reflective message managertransactions named as saveentryinDB, 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 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 precedents.

4.3 Designing a relational database profile

In the event that an object-oriented DBMS (OODBMS) is used to implement the system, the object diagram built in the previous section is the final model and 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 the information system, it is necessary to develop another diagram, a relational database profile diagram.

The UML profile for a database project is a UML extension that keeps the UML metamodel intact. A profile for a database project adds stereotypes and tagged values ​​attached to those stereotypes, but does not change the underlying UML metamodel. To visualize the design elements of the database and the rules for designing relational databases, the corresponding icons are added to the profile (hereinafter simply databases). The database is described using tables, columns and relationships. A profile has elements that extend the database, such as triggers, stored procedures, constraints, user-defined types (domains), views, and others. The profile shows how and where all these elements are used 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) is a possible key chosen to identify table rows.

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

Representation ( View) - a virtual table that behaves from the user's point of view in the same way as a regular table, but does not exist on its own.

Stored procedure ( A stored procedure is an independent procedural function that runs 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 information system "Educational and methodological resource".

    term paper, added 05/28/2009

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

    presentation, added 10/14/2013

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

    presentation, added 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 development of information technologies. Types of information technologies.

    term paper, added 06/17/2003

    The concept of CASE-tools as software tools that support the processes of creating and maintaining information systems (IS). Features of IDEF-technologies for IS development. Description of IDEF0 notation. Development of functional business process models.

    presentation, added 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 learning process. Implementation of a given information system.

    thesis, added 02/17/2015

    Development of information systems. The modern market of financial and economic applied software. Advantages and disadvantages of introducing 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 GUI forms and databases.

    thesis, added 06/23/2015

    Information security solution. Systems for data centers. What is data center equipment. Basic concepts and principles of modeling. Choosing a method for solving problems. Seutendijk admissible direction method, Frank–Wulf algorithm.

    term paper, added 05/18/2017

    The concept of an information system. 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.

Top Related Articles