VII Международная студенческая научная конференция Студенческий научный форум - 2015

ВВЕДЕНИЕ

Развитие современных информационных технологий приводит к усложнению информационных систем (ИС), которые создаются для различных областей деятельности человека.

Современные информационные системы характеризуются следующими особенностями:

• их сложно описать (большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними);

• отсутствуют прямые аналоги, что ограничивает возможность использования каких-либо типовых проектных решений и прикладных систем;

• необходима интеграция уже существующих и вновь разрабатываемых приложений;

• функционирование в неоднородной среде на нескольких аппаратных платформах.

Для успешной реализации проекта объект проектирования должен быть хорошо изучен и проанализирован. Цели проекта должны быть четкими и непротиворечивыми. Должны быть построены полные информационные модели. Нужно учитывать, потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.

Целью курсового проекта является анализ информационно-аналитической системы. Необходимо создать описание предметной области и выбрать средства реализации проекта автоматизированной системы, которая позволяет успешно решать текущие и будущие задачи предоставления информации о посещаемости и успеваемости студентов.

Начальным этапом создания информационной системы является изучение, анализ и моделирование работы web-приложения. В курсовой работе используются инструментальные средства для моделирования Rational Rose Enterprise Edition, который является средством для построения UML-диаграмм.

1 ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

На первом этапе проектирования информационной системы необходимо выполнить анализ предметной области, т.е. определить объекты предметной области и связи между объектами.

При выборе состава и структуры предметной области возможны два подхода: функциональный и предметный.

Функциональный подход реализует принцип движения «от задач» и применяется, когда определен комплекс задач, для обслуживания которых создается информационная система. В этом случае можно выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

В предметном подходе объекты предметной области определяются с таким расчетом, чтобы их можно было использовать при решении множества разнообразных, заранее не определенных задач.

Предметная область данной информационно-аналитической системы (ИАС) – это сбор, хранение и анализ информации о студентах. Основная информация, которую должна предоставить пользователю ИАС – это личные данные студентов, обучающихся на кафедре, а так же информацию об успеваемости и посещаемости этих студентов.

Именно аналитические системы решают все поставленные задачи по обеспечению пользователей нужной им информацией. Данные системы имеют целый ряд уникальных достоинств и возможностей.

В первую очередь это:

• возможность компактно хранить большие объемы информации;

• возможность структурировано отображать хранимую информацию;

• возможность быстрого поиска нужных документов или даже их фрагментов в огромных массивах данных.

2 МЕТОДОЛОГИИ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

Методология создания информационных систем заключается в организации процесса построения информационной системы и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований, как к самой системе, так и к характеристикам процесса разработки.

Основными задачами, решение которых должна обеспечивать методология создания информационных систем (с помощью соответствующего набора инструментальных средств), являются следующие:

• обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по автоматизации деловых процессов;

• гарантия создания системы с заданными параметрами в течение заданного времени в рамках оговоренного заранее бюджета;

• простота сопровождения, модификации и расширения системы с целью обеспечения ее соответствия изменяющимся условиям работы предприятия;

• обеспечение создания информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

• возможность использования в создаваемой системе разработанных ранее и при меняемых на предприятии средств информационных технологий (программного обеспечения, баз данных, средств вычислительной техники, телекоммуникаций).

На сегодняшний день существует не так много методологий, особенно полных, т. е. учитывающих все стадии жизненного цикла программного обеспечения. Именно методология определяет, какие языки и системы будут применяться для разработки программного обеспечения и, во многом, рекомендует, какой технологический подход будет при этом использован. Выделяют две основных методологии: функциональная методология и объектно-ориентированная.

2.1 Объектно-ориентированная методология

Объектно-ориентированная технология развивается в различных областях вычислительной техники как средство решения проблем связанных со сложностью создаваемых систем. Объектный подход применяется не только в программировании, но также в проектировании интерфейса пользователя, баз данных, баз знаний и компьютерной архитектуры. Смысл такого широкого подхода состоит в том, что он позволяет применить объектную ориентацию для решения всего круга проблем, связанных со сложными системами.

Объектно-ориентированный подход наиболее естественно соответствует реальному процессу разработки систем и не только программных, который является итеративным и может потребовать внести изменения в уже разработанные и отлаженные компоненты системы.

Составными частями объектно-ориентированной методологии (ООМ) являются:

• объектно-ориентированный анализ;

• объектно-ориентированное проектирование;

• объектно-ориентированное программирование.

Объектно-ориентированное программирование — это методология программирования, которая основана на представлении программы в виде совокупности объектов, каждый из которых является реализацией определенного класса, а классы образуют иерархию на принципах наследования.

В данном определении можно выделить три части:

1. объектно-ориентированное программирование использует в качестве элементов конструкции объекты, а не алгоритмы;

2. каждый объект является реализацией определенного класса;

3. классы организованы иерархически.

Объектно-ориентированное проектирование — это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления как логической и физической, так статической и динамической моделей проектируемой системы.

В данном определении содержатся две важные части:

• объектно-ориентированное проектирование ведет к объектно-ориентированной декомпозиции;

• используется многообразие приемов представления моделей, отражающих логическую (структуры классов и объектов) и физическую (архитектура модулей и процессов) структуру системы.

Именно поддержка объектно-ориентированной декомпозиции отличает объектно-ориентированное проектирование от структурного проектирования.

Объектно-ориентированный анализ (ООА) направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих словарь предметной области.

На результатах ООА формируются модели, на которых основывается объектно-ориентированное проектирование; объектно-ориентированное проектирование в свою очередь создает основу для окончательной реализации системы с использованием методологии объектно-ориентированного программирования.

Главными достоинствами ООМ по сравнению со структурными методами являются:

• возможность преодолеть ограничения, связанные со сложностью разрабатываемых систем;

• использование на стадии анализа моделей близких к реальности;

• применение как при анализе и проектировании информационных систем, так и систем реального времени и аппаратно-программных комплексов;

• обеспечение возможности повторного использования разработанного программного обеспечения, позволяющего существенно сократить сроки и снизить затраты на разработку каждой последующей системы;

• поддержка итеративного, а не лавинообразного, как в структурном подходе, процесса проектирования;

• естественная работа с разнородной информацией, используемой в мультимедиа системах;

• создание более открытых систем;

• полное использование описательных возможностей объектно-ориентированных языков программирования.

Объектная модель, которая является концептуальной базой объектно-ориентированной методологии, имеет четыре главных элемента:

• абстрагирование;

• ограничение доступа или инкапсуляция;

• модульность;

• иерархия.

Кроме главных имеется три дополнительных элемента:

• типизация;

• параллелизм;

• сохраняемость или устойчивость (persistence).

Эти элементы полезны в объектной модели, но не обязательны.

Примером ООМ может служить диаграмма, построенная на языке UML

Рисунок 1 – Диаграмма на языке UML

2.2 Функциональная методология

Методология IDEF0 (второе название SADT – техника структурного анализа и проектирования) – это технология анализа системы в целом как набора связанных между собой действий или функций. Данная модель описывается вне рамок времени, т.е. это модель статического моделирования.

Модель нотации представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина древовидной структуры представляет собой общее описание системы и ее взаимодействия с вешней средой. Эту диаграмму, т.е. диаграмму верхнего уровня, называют контекстной. (Чтобы увидеть дерево всех диаграмм в проекте BPwin, необходимо перейти в режим NodeTree).

После описания системы в целом производят ее разбиение на крупные фрагменты, т.е. производится ее декомпозиция. Такое разбиение продолжается до тех пор, пока в этом есть практическая необходимость.

Синтаксис описания системы в целом и каждого его фрагмента одинаков во всей модели. Работы (Activity) обозначаются в виде прямоугольника:

Рисунок 2 – Функциональный блок

В зависимости от направления стрелки и стороны функционального блока в которую входит (выходит) дуга различают 4 основных вида интерфейсных дуг:

1. Вход - это данные и объекты, потребляемые или изменяемые процессом

2. Выход - это основной результат процесса, конечный продукт (должна быть хотя бы одна дуга).

3. Управление - стратегии и процедуры, которыми управляется процесс (должна быть хотя бы одна дуга)

4. Механизм - ресурсы, исполняющие процесс (исполнитель).

Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления.

Модель представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы.

Рисунок 3 – Декомпозиция диаграмм

IDEF3. Process Description Capture (документирование технологических процессов) — методология документирования процессов, происходящих в системе (например, на предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 — каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3.

DFD (Data Flow Diagrams) — диаграммы потоков данных. Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.

Информационная система принимает извне потоки данных. Для обозначения элементов среды функционирования системы используется понятие внешней сущности. Внутри системы существуют процессы преобразования информации, порождающие новые потоки данных. Потоки данных могут поступать на вход к другим процессам, помещаться (и извлекаться) в накопители данных, передаваться к внешним сущностям.

Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

Кроме того, нотация DFD поддерживает понятие подсистемы — структурной компоненты разрабатываемой системы.

Нотация DFD — удобное средство для формирования контекстной диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в коммуникации с внешней средой. Это — диаграмма верхнего уровня в иерархии диаграмм DFD. Ее назначение — ограничить рамки системы, определить, где заканчивается разрабатываемая система и начинается среда. Другие нотации, часто используемые при формировании контекстной диаграммы — диаграмма SADT, диаграмма вариантов использования.

3 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ

3.1 Для проектирования информационно-аналитической системы используется инструментальные средства для моделирования IBM Rational Rose Enterprise Edition и MySQL Workbench.

Rational Rose – популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования. Rational Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Также Rational Rose имеет весь необходимый набор визуальных средств проектирования и поможет решить проблемы с кодогенерацией на определенном языке программирования. Данное программное обеспечение осуществляет такие подходы, как прямое и обратное проектирование, а так же Round Trip Engineering. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.

Rational Rose Enterprise. Абсолютно полная версия продукта, которая покрывает весь спектр задач по проектированию, анализу и кодогенерации.

Данный продукт включает в себя возможности таких программ как:

• Rational Rose Modeler. Данная версия позволит аналитикам и проектировщикам проводить анализ бизнес-процессов и выстраивать систему. Данная редакция подразумевает только моделирование без кодогенерации.

• Rational Rose Professional. Профессиональная редакция продукта. Имеет в своем наборе весь спектр изобразительных средств. В зависимости от выбранного языка программирования осуществляет прямое и обратное проектирование. Rose Professional заказывается только в определенной конфигурации (например, Rose Professional С++ или Rose Professional С++ DataModeler). Rational Rose Professional не создает 100% исполняемого кода. На выходе разработчик получает шаблон информационной системы на определенном языке программирования, который впоследствии нужно запрограммировать.

• Rational Rose RealTime. Версия продукта для создания 100% исполняемого кода в реальном масштабе времени. RealTime позволяет проводить прямое и обратное проектирование на языках С или С++. На выходе модель автоматически компилируется и собирается в исполняемый файл. Продукт направлен на разработчиков.

Как уже было сказано, Rational Rose для построения диаграмм использует язык моделирования UML.

UML (Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.

Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

Преимущества UML:

• UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;

• UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

• Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

• UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;

• UML получил широкое распространение и динамично развивается.

MySQL Workbench — инструмент для визуального проектирования баз данных, интегрирующий проектирование, моделирование, создание и эксплуатацию БД в единое бесшовное окружение для системы баз данных MySQL.

MySQL Workbench предлагается в двух редакциях:

• Community Edition , которая распространяется под свободной лицензией GNU GPL.

• Standard Edition, которая доступна по ежегодной оплачиваемой подписке. Эта версия включает в себя дополнительные функции, которые повышают производительность разработчиков и администраторов БД.

Первая версия MySQL Workbench была выпущена в сентябре 2005 года.

MySQL Workbench был первым семейством продуктов, который был доступен в двух вариантах. Чтобы привлечь разработчиков в основную команду разработки, коммерческая стандартная версия программы (Standard Edition) предлагается поверх свободной версии (Community Edition), распространяемой под лицензией GNU GPL. «Community Edition» является полнофункциональным продуктом, обладающим всеми основными возможностями коммерческого варианта. Являясь основой для всех будущих релизов, он будет получать пользу от всех будущих усилий, прилагаемых для развития продукта. «Standart Edition» расширяет «Community Edition» серией модулей и плагинов, позволяющих оптимизировать рабочий процесс и, тем самым, сэкономить время и избежать ошибок.

Возможности программы:

• Позволяет наглядно представить модель базы данных в графическом виде.

• Наглядный и функциональный механизм установки связей между таблицами, в том числе «многие ко многим» с созданием таблицы связей.

• Reverse Engineering — восстановление структуры таблиц из уже существующей на сервере БД (связи восстанавливаются вInnoDB, при использовании MyISAM — связи необходимо устанавливать вручную).

• Удобный редактор SQL запросов, позволяющий сразу же отправлять их серверу и получать ответ в виде таблицы.

• Возможность редактирования данных в таблице в визуальном режиме.

Несмотря на то, что UML - достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

• Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций.

• Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные.

• Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.

3.2 Построение объектно-ориентированной модели

Для создания объектно-ориентированной модели информационно-справочной системы были построены диаграммы на языке UML. Данная модель включает в себя следующие диаграммы:

• диаграмма компонентов;

• диаграмма вариантов использования;

• диаграмма состояний.

3.1.1 Диаграмма вариантов использования. Это диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.

Рисунок 4 – Диаграмма вариантов использования

На данной диаграмме присутствуют два актера: администратор и обычный пользователь. Для каждого из актеров отражены свои варианты использования информационно-аналитической системы.

Таблица 3.1 – Диаграмма состояний

Актер	Краткое описание
Администратор	Пользователь, который может редактировать данные пользователя.
Пользователь	Пользователь, который может авторизоваться и просматривать информацию, а так же изменять успеваемость и посещаемость студентов.

Рассмотрим теперь, какие возможности должна предоставлять наша система:

• актер Администратор использует систему редактирования рабочей программы и управления информацией о пользователях системы;

• актер Пользователь использует систему для авторизации, просмотра информации и получения и отправки сообщений, использует систему для изменения информации, редактирования посещаемости и успеваемости студентов;

3.2.2 Диаграмма состояний. Это, по существу, диаграмма состояний из теории автоматов со стандартизированными условными обозначениями, которая может определять множество систем от компьютерных программ до бизнес-процессов.

Рисунок 5 – Диаграмма состояний

Процесс начинается с начальной точки, затем следует самый первый переход в состояние «Загрузка страницы авторизации». После этого осуществляется переход в состояние «Ожидание ввода логина и пароля».

Из состояния «Ожидание ввода логина и пароля» возможны два перехода. Метка одного из них включает условие. Условный переход выполняется в случае, когда условие принимает значение «истина» или «ложь». Из данного состояния переход может быть осуществлен в состояние «Загрузка главной страницы».

Из конкретного состояния может быть осуществлен только один переход в состояние «Ожидание действий пользователя». Из данного состояния возможны три перехода: «Загрузка страницы группы», «Загрузка страницы студента», «Загрузка страницы расписание». Из каждого следующего состояния возможет только один переход «Ожидание выбора студента», «Ожидание выбора студента» и «Ожидание работы с расписанием».

3.2.3 Диаграмма компонентов. Это статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами.

Рисунок 6 – Диаграмма компонентов

На данной диаграмме присутствуют два вида компонентов: страницы сайта и таблицы базы данных. Для каждого компонента отражены его связи с другими компонентами.

Страницы сайта:

• главная страница;

• страница «Карта студента»;

• страница «Расписание»;

• страница «»Вход»;

• страница «Группа».

Таблицы базы данных «Диплом»:

• lecturers;

• report_type;

• report_prog;

• lp_prog;

• users;

• semesters;

• lectures_group;

• trining_form;

• subject_group;

• students;

• lp_plan;

• subject;

• report_plan;

• lp_type;

• groups.

3.3 Построение логической модели

Созданием логической модели является построение диаграммы ERD (Entity Relationship Diagram). ERD-диаграммы состоят из трех частей: сущностей, атрибутов и взаимосвязей. Сущностями являются существительные, атрибуты - прилагательными или модификаторами, взаимосвязи - глаголами.

ERD-диаграмма позволяет рассмотреть систему целиком и выяснить требования, необходимые для ее разработки, касающиеся хранения информации.

ERD-диаграммы можно подразделить на отдельные куски, соответствующие отдельным задачам, решаемым проектируемой системой. Это позволяет рассматривать систему с точки зрения функциональных возможностей, делая процесс проектирования управляемым.

Во всех этих случаях взаимосвязи отражают взаимодействие между двумя сущностями, называемое «один-ко-многим». Это означает, что один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности. Взаимосвязи отображаются линиями, соединяющими две сущности с точкой на одном конце и глаголом, располагаемым над линией.

Рисунок 7 – Логическая модель информационно-аналитической системы

3.4 Построение физической модели

Целью создания физической модели является обеспечение администратора соответствующей информацией для переноса логической модели данных в СУБД.

MySQL Workbench поддерживает автоматическую генерацию физической модели данных для конкретной СУБД. При этом логическая модель трансформируется в физическую по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключи становятся индексами.

Рисунок 8 – Физическая модель информационно-аналитической системы

ЗАКЛЮЧЕНИЕ

В современном мире ни у кого не вызывает сомнения необходимость использования информационных систем для автоматизации деятельности человека.

Проектирование информационных систем позволяет детально изучить предметную область, описать взаимодействие процессов, выявить потоки данных, присутствующие в ней.

В ходе выполнения данной работы были рассмотрены различные методологии проектирования информационных систем и были изучены основы работы в Rational Rose Enterprise Edition и MySQL Workbench. Также определена предметная область, основные компоненты информационно-справочной системы, взаимосвязи и состояния этих компонентов. В завершении были построены логическая и физическая модели хранилища данных.

На практике была спроектирована информационно-аналитическая система мониторинга деятельности студентов.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Балабанов И.Т. Современные моделирования./ И.Т. Балабанов– СПб: Питер, 2002. – 120 с.: ил. – (серия “Основы”).
2. Глотова Т.В. Объектно-ориентированная методология. Разработка сложных систем / Т.В.Глотова. – Пенза, 2010.

3. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина–Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.1 – 146 с.

4. Пахчанян А. Обзор информационных систем // Директор информационной службы. – 2001.

5. Федоров Н.В. Проектирование информационных систем на основе современных CASE-технологий. / Н.В. Федоров – М.: МГИУ, 2008. − 287 с.

6. Википедия. Свободная энциклопедия [Электронный ресурс]:[справочный листок]. Википедия, 2012. – Режим доступа: http://ru.wikipedia.org/wiki/Диаграмма_сосотояний_(UML).

7. Википедия. Свободная энциклопедия [Электронный ресурс]:[справочный листок]. Википедия, 2012. – Режим доступа: http://ru.wikipedia.org/wiki/ UML.

8. IT Teach [Электронный ресурс]:[справочный листок]. IT Teach, 2012. – Режим доступа: http://itteach.ru/bpwin/sozdanie-logicheskoy-modeli/logicheskie-vzaimosvyazi.

ПРИЛОЖЕНИЕ А

(обязательное)

Электронные материалы к курсовой работе

Код для цитирования: Скопировать