Преподаватель который помогает студентам и школьникам в учёбе.

Применение объектно-ориентированного подхода при проектировании информационной системы (Классификация и особенности анализа информационных систем)

Содержание:

Введение

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

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

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

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

В конце 60-х гг. в США было отмечено такое явление, как «software crisis», то есть кризис программирования. Оно проявлялось в том, что большие проекты стали выполнятся с отставанием от графика или с превышением сметы расходов, разработанный продукт не обладал требуемыми функциональными возможностями, производительность его была низка, качество получаемого программного обеспечения не устраивало потребителей.

Аналитические исследования и обзоры, выполняемые в течение ряда последних лет ведущими зарубежными аналитиками, показывали не слишком обнадеживающие результаты. Так, например, в 1995г. компания Standish Group, которая проанализировала работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов, связанных с разработкой ПО, и сделали следующие выводы:

Только 16% проектов завершились в срок и не превысили запланированный бюджет, 52,7% завершились с опозданием, так и не реализовав все функции, а 31,1% проектов были аннулированы до завершения. При этом последние две категории превысили бюджет в среднем на 89%, а срок выполнения на 122%.

В 1998 г. Процентное соотношение перечисленных категорий стало немного лучше.

В числе причин неудач фигурируют: недостаточное вовлечение пользователей в работу над проектом, нечеткая и неполная формулировка требований к ПО, неудовлетворительное планирование и т.п.

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

Два наиболее популярных подхода проектирования, это структурный и объектно-ориентированный.

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

Глава 1. Теоретические основы объектно-ориентированного подхода

1.1 Классификация и особенности анализа информационных систем

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

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

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

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

По типу хранимых данных ИС делятся на фактографические и документальные. Фактографические системы используются для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции. В документальных системах информация представлена в виде документов, состоящих из наименований, описаний и текстов. Поиск по неструктурированным данным осуществляется с использованием семантических признаков. Отобранные документы предоставляются пользователю, а обработка данных в таких системах практически не производится. В приложении1. на рисунке 1 более подробно описаны виды классификации информационных систем.

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

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

Для успешной реализации ИС обязательным условием является чёткое и наиболее полное формирование требований на разработку. Д.А. Марк пишет: «На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях». Из этого можно сделать вывод, что адекватное, чёткое и однозначное описание процессов необходимо уже на стадии проектирования.

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

1.2 Сущность объектно-ориентированного подхода

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

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

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

Применяя объектно-ориентированное проектирование, мы создаем открытые для изменений программы, построенные из ограниченного числа универсальных блоков (компонентов)

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

Согласно Г.Бучу и А.В. Леоненкову объект – это абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением.

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

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

Структура и поведение объектов, схожих между собой, определяют общий для них класс. Термины «экземпляр класса» и «объект» эквивалентны. Состояние объекта характеризуется перечнем существующих (статических) свойств этого объекта и текущими значениями (динамическими) каждого свойства. Поведение характеризует воздействие объекта на другие объекты и, наоборот, относительно изменения cocтояния этих oбъектов и передачи cooбщений. Иначе гoворя, пoведение oбъекта пoлнocтью oпределяется егo дейcтвиями. Индивидуальность – это свойства объекта, отличающие его от всех других объектов.

Говоря об объекте «поезд», будет правильным не обобщенное понятие поезд, как нечто состоящее из вагонов, а конкретный пассажирский поезд с номером 758, весом 3500 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 666 и так далее. Степень абстракции с точки зрения решаемой задачи может быть меняться. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности отличать друг от друга электровозы ВЛ80Т с серийными номерами 666 и 053.

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

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

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

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

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «треугольник» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет контура и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус и d диаметр).

Полиморфизмом называется принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateP() (рассчитать периметр) для классов «треугольник» и «параллелограмм», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

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

1.3 Преимущества и недостатки объектно-ориентированного подхода

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

Достоинства ООП заключаются в следующем:

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

К недостаткам ООП относятся:

усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области и для которых невозможно найти человека, понимающего эту предметную область в целом, также требует использования традиционных подходов в виду их большей доступности для неспециалистов;
сложность реализации. Объектно-ориентированные проекты и их программная реализация на объектно-ориентированном языке требуют больших временных затрат и приводят к построению более сложной и требовательной к ресурсам программы, нежели классические методы, которые могут оказаться более эффективными для некоторых задач.

Глава 2. Базовые составляющие объектно-ориентированного подхода

2.1 Готовые обобщённые решения

Стадии проектирования используют так называемые шаблоны проектирования.

Шаблон это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Обычно этот паттерн содержит текстовое описание и одну (или несколько) диаграмм UML. Таких как диаграммы коммуникации, последовательности или классов, графически иллюстрируя состав и структуру классов, особенности взаимодействия в условиях решения поставленной задачи.

Шаблоны являются эффективными и проверенными решениями. Обычно, но не всегда, оптимально решают задачу. За счёт этого применение шаблонов повышает качество разработки ПО и сокращает затраты.

2.2 Структура Унифицированного процесса

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

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

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

Существуют базовые концепции унифицированного процесса:

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

2.3 Унифицированный язык моделирования

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

Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода. С того времени выпущено несколько версий спецификации UML, две из них носят статус международного стандарта:

UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");
UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

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

Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний.

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста.

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

Определено 3 типа сущностей:

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

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

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

Таблица 1.

Сущности в UML

Тип	Наименование	Обозначение	Определение (семантика)
Поясняющая	Примечание (comment)		Комментарий к элементу. Присоединяется к комментируемому элементу штриховой линией
Группирующая	Пакет (package)		Общий механизм группировки элементов. В отличие от компонента, пакет – чисто концептуальное (абстрактное) понятие. Частными случаями пакета являются система и модель
	Фрагмент (fragment)		Область специфического взаимодействия экземпляров актеров и объектов
	Раздел деятельности (activity partition)		Группа операций (зона ответственности), выполняемых одной сущностью (актером, объектом, компонентом, узлом и т.д.)
	Прерываемый регион (interruptible activity region)		Группа операций, обычная последовательность выполнения которых может прервана в результате наступления нестандартной ситуации
Структурная	Класс (class)		Множество объектов, имеющих общую структуру и поведение
	Объект (object)		Абстракция реальной или воображаемой сущности с четко выраженными концептуальными границами, индивидуальностью (идентичностью), состоянием и поведением. С точки зрения UML объекты являются экземплярами класса (экземплярами сущности)
	Актер (actor)	Инженер службы пути	Внешняя по отношению к системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Таким образом актер – это внешний источник или приемник информации
	Вариант использования (use case)		Описание выполняемых системой действий, которая приводит к значимому для актера результату
	Состояние (state)		Описание момента в ходе жизни сущности, когда она удовлетворяет некоторому условию, выполняет некоторую деятельность или ждет наступления некоторого события
Структурная	Кооперация (collaboration)		Описание совокупности экземпляров актеров, объектов и их взаимодействия в процессе решения некоторой задачи
	Компонент (component)		Физическая часть системы (файл), в том числе модули системы, обеспечивающие реализацию согласованного набора интерфейсов
	Интерфейс (interface)	iРасчет	Совокупность операций, определяющая сервис (набор услуг), предоставляемый классом или компонентом
	Узел (node)		Физическая часть системы (компьютер, принтер и т. д.), предоставляющая ресурсы для решения задачи

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

Таблица 2

Декомпозируемые сущности

Наименование	Обозначение	Диаграмма
Скрытое составное состояние		Диаграмма автоматов
Скрытый фрагмент взаимодействия		Диаграмма последовательности
Деятельность		Диаграмма деятельности

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

Таблица 3.

Отношения

Наименование	Обозначение	Определение (семантика)
Ассоциация (association)		Связь между двумя и более сущностями значима. Наиболее общий вид отношения
Агрегация (aggregation)		Связь "часть"–"целое", в котором "часть" может существовать обособленно от "целого". Ромб обозначается со стороны "целого". Отношение ставится только между сущностями одного типа
Композиция (composition)		"Части" не могут находиться отдельно от "целого". Как правило, "части" создаются и уничтожаются единовременно с "целым"
Зависимость (dependency)		Изменение в одной независимой сущности может влиять на состояние или поведение другой сущности-зависимой. Независимая сущность указывается со стороны стрелки.
Обобщение (generalization)		Отношение между обобщенной сущностью (предком, родителем) и специализированной сущностью (потомком, дочкой). Треугольник ставится со стороны родителя. Отношение существует только между сущностями одного типа
Реализация (realization)		Одна сущность определяет действие, которое обязуется выполнить другая сущность. Отношения используются в двух случаях: между вариантами использования и кооперациями, и между интерфейсами и классами. Со стороны стрелки указывается сущность, определяющее действие (интерфейс или вариант использования)

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

*– любое количество экземпляров, в том числе и ни одного;
целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5);
диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5);
диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*);
перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*).

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

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

Таблица 4

Механизмы расширения

Наименование	Обозначение	Определение (семантика)	Пример
Стереотип (stereotype)	« »	Обозначение, уточняющее семантику элемента нотации	зависимость со стереотипом «include» рассматривается, как отношение включения, а класс со стереотипом «boundary» – граничный класс
Сторожевое условие (guard condition)	[ ]	Логическое условие	[A > B] или [идентификация выполнена]
Ограничение (constraint)	{ }	Правило, ограничивающее семантику элемента модели	например, {время выполнения менее 10 мс}
Помеченное значение (tagged value)	{ }	Новое или уточняющее свойство элемента нотации	{version = 3.2}

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

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

Таблица 5.

Виды диаграмм

Название диаграммы	Назначение	Применение
Диаграмма классов	Показывает статическую структуру понятий, типов и классов, виды соотношений между ними (наследования и всевозможные ассоциации).	Занимает центральное место в объектно-ориентированном подходе. Начинает формироваться на этапе концептуализации, когда выявляются объекты и заканчивает – на этапе реализации, когда окончательно проясняются детали реализации классов.
Диаграмма последовательности	Показывает последовательность взаимодействия нескольких объектов в рамках одного варианта использования.	Основной вид диаграмм описывающих взаимодействие между объектами.
Диаграмма кооперации	Показывает последовательность взаимодействия нескольких объектов в рамках одного варианта использования.	Применяется в случае сложной последовательности взаимодействий большого количества объектов.
Диаграмма деятельности	Показывает поведение вместе со структурой управления. Позволяет изобразить реализацию метода и параллельные процессы.	Является развитием давно известного метода визуализации алгоритмов в виде блок-схем.
Диаграмма вариантов использования	Множество типовых сценариев взаимодействия пользователя с системой. Пользовательские требования, оформленные в графической форме.	Используется при разработке интерфейсов многопользова-тельских систем. Предоставляет множество способов описания вариантов использования.
Диаграмма состояний	Показывает особенности поведения объекта в нескольких вариантах использования	Используются при реализации систем реального времени (п/о работающее в приборах) или систем со сложным многопользовательским интерфейсом.
Диаграмма пакетов	Показывает группы классов и зависимости между ними	Используется при создании больших систем, когда она разбивается на как можно менее зависимые части. Часть системы оформляется на диаграмме в виде пакета. Пакет может использоваться, когда не важна внутренняя структура части системы.
Диаграмма развертывания	Показывает физическое размещение компонентов на узлах аппаратуры.	Используется при реализации сложных программно-аппаратных комплексов для визуализации размещения программного обеспечения и его взаимодействия с аппаратурой.

Глава 3. Программные продукты

3.1 Обоснование выбора средств объектно-ориентированного подхода

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

Для проектирования и документации простых информационных систем вполне подходят не специализированные программы, такие как Word. Это не требует дополнительных затрат на покупку ПО, а с грамотным знанием UML и способов проектирования, результат является не менее качественным.

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

Так же многие разработчики могут ориентироваться на используемую ими операционную систему, так как они так же могут не поддерживать то или иное решение.

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

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

Ещё один важный параметр в программах подобного типа, это поддержка удобного экспорта артефактов, произведённых в нём. Должны быть доступны разные форматы экспорта – хотя бы html и doc. Шаблоны документов должны легко модифицироваться.

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

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

Обоснованием подробного рассмотрения именно этих программ является их большая известность, популярность в пользовательских кругах и личные предпочтения.

3.2.1 Visio

В обучении (в колледжах и университетах) самым популярным, пожалуй, является редактор диаграмм Microsoft Visio. Это программное обеспечение для рисования различных диаграмм: блок-схем, организационных диаграмм, планов зданий, поэтажных планов, диаграмм потоков данных, технологических схем, моделирования бизнес-процессов, swim lane блок-схем, 3D-карт.

На сегодня MS Visio выпускается в трёх редакциях: Standard, Professional и Pro for Office 365

Полнофункциональная версия Microsoft Visio Professional используется для создания и редактирования монограмм и диаграмм. А в стандартный набор программ MS Office входит только средство для просмотра и печати диаграмм Microsoft Visio Viewer. Полноценный продукт никогда в пакет Microsoft Office не входил и всегда распространяется отдельно.

Visio создан в 1990-х компанией из Сиетла Shapeware Corparation.

Visio 1.0 был первым продуктом компании и, выпущен в 1992 г. (с 1990 по 1992 год компания носила название Axon Corporation).

Продукт быстро получил признание, и в 1995, компания была переименована в Visio Corporation, которое и остается вплоть до 2001 г.

Деятельность компании связана с разработкой, продажей и поддержкой программного обеспечения в области деловой графики. На главном сайте компании «www.visio.com» значилась главная цель компании- стать единственным мировым стандартом для создания, хранения и обмена деловых рисунков и диаграмм.

За несколько лет продукт прошел версии от первой до пятой, после них появился Visio 2000.

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

В 1999-2000 гг. компания занимала ведущее место в области деловой компьютерной графики. По пресс-релизу 1999 г. Visio Corporation насчитывала более 3 млн. инсталляций продуктов из линейки Visio в 45 странах на 12 языках.

Цель, озвученная ранее, почти была достигнута, однако в 2001 г. бывший главный сайт компании стал переадрисовывать посетителей на «www.microsoft.com»; а продукты Visio получили приставку MS Visio, при этом название самой фирмы практически перестало упоминаться.

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

Еще во времена Visio Corporation предлагалось пять основных продуктов:

Visio Standard 5.0 - базовая версия продукта.
Visio Technical 5.0 - усилена работа с двумерными рисунками и техническими схемами.
Visio Professional 5.0 - ориентирован на реинженеринг ODBC-совместимых баз данных, сетевые схемы, Web-сайты.
Visio Enterprise 5.0 - еще более углубляет Visio Professional, обеспечина синхронизация моделей с базами данных.
IntelliCAD® 98 by Visio - совместимость с Autodesk AutoCAD.

Так же существовали расширения:

Visio Maps - применение технологии Visio в геоинформационных системах.
Visio Network Equipment - применение Visio для сетевых разработок.

При переходе к Microsoft Visio 2000 основных продуктов стало четыре, а номера версий продукта Visio стали соответствовать версии Office:

Microsoft Visio Standard 2000 - средство для создания различных бизнес-диаграмм, включая диаграммы общего назначения, схемы и планы помещений;
Microsoft Visio Technical 2000 - средство для инженеров, позволяющее создавать двухмерные технические диаграммы и схемы;
Microsoft Visio Professional 2000 - средство для IT-менеджеров и руководителей проектов, позволяющее документировать информационные системы и бизнес-процессы;
Microsoft Visio Enterprise 2000 - средство для IT-специалистов и разработчиков, позволяющее документировать сетевые конфигурации, моделировать и разрабатывать базы данных, моделировать программы и компоненты.

В Microsoft Visio 2002 версии Technical и Professional слились в одну - Professional. Получились три продукта, каждый из которых ориентировался на свою группу пользователей:

Microsoft Visio Standard 2002 предлагает средства для бизнеса. С его помощью сотрудники компаний (менеджеры проектов, специалисты по сбыту и маркетингу, персонал отделов кадров, администраторы предприятий и т. д.) могут представлять в визуальной форме информацию о людях, проектах и процессах, и обмениваться ею.
Microsoft Visio Professional 2002 ориентируется на технических специалистов - профессионалов в области ИТ, разработчиков и инженеров. Он обеспечивает представление в визуальной форме существующих и новых идей, информации и систем. Visio Professional включает и средства построения диаграмм для бизнеса, входящие в состав Visio Standard.
Microsoft Visio Enterprise Network Tools 2002 (надстройка для Visio Professional 2002) включает мощные средства построения сетевых диаграмм и документирования сети, предназначенные для ИТ-специалистов. Надстройка поставляется вместе с годовой подпиской центра Visio Network Center, пользователям которого предлагаются решения, трафареты и другие ресурсы для построения сетевых диаграмм.

В Microsoft Visio 2003 остаются только версии Technical и Professional. Сетевые решения вливаются в версию Professional, функциональность Visio Enterprise Network Tools переместилась в Microsoft Visual Studio:

Microsoft Visio Standard 2003 - средства для бизнеса.
Microsoft Visio Professional 2003 - средства для технических специалистов. Включают в себя и Microsoft Visio Standard 2002.

Microsoft Visio 2007 сохраняет то же деление:

Microsoft Visio Standard 2007 - сокращенная поставка - только средства для бизнеса.
Microsoft Visio Professional 2007 - полный вариант - для бизнеса и технических специалистов.

Для каждой версии есть еще несколько вариантов поставки. Коробочная версия поставляется в вариантах: обычный, версия для учебных организация, обновление до текущей версии. Такое же разнообразие у лицензий.

Кроме основного продукта существуют так же дополнительные пакеты для разработчиков. В первую очередь это Visio Software Development Kit (SDK). В SDK входят такие полезные вещи, как:

Microsoft Office Visio Code Librarian Samples - база данных с примерами работы с объектной моделью Visio на языках Microsoft Visual Studio 6.0, Microsoft Visual Studio .NET 2003, Microsoft Visual C#. База включает оболочку для просмотра примеров;
Sample applications - примеры приложений на платформе Visio, демонстрирующие основные аспекты разработки;
Tools - инструменты разработчика: Persistent Events, Print ShapeSheet, Solution Publishing, Event Monitor и даже законченная среда для разработки шейпов - ShapeStudio;
Документация.

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

Выпускаются также особые приложения как для автоматизации отдельных функций, и целых технологий. Если первые часто бывают бесплатными (VisiClean 2003 - удаляет неиспользуемые мастер-шейпы, уменьшая объем файла рисунка; VisiExam 2003 - производит контроль рисунка на несовместимость и ошибки), то вторые могут стоить порядка $500 (например, LANsurveyor - сканирование, управление и документирование сетей.)

В Microsoft Visio 2010 снова добавлена третья версия:

Microsoft Visio 2010 Standard - как и в предыдущей версии, сокращенная поставка. В первую очередь рисование диаграмм всевозможных типов.
Microsoft Visio 2010 Professional - почти полный вариант - для бизнеса и технических специалистов. Обновляемые схемы, синхронизированные с данными, совместная групповая работа на SharePoint с возможностью просмотра документов через броузер даже при отсутствии установленного Visio.
Microsoft Visio 2010 Premium – включает в себя средства моделирования бизнес процессов, в том числе BPMN и SharePoint Workflow, валидация схем.

Microsoft Visio 2013 - две последние версии объединены в одну, добавлена версия, связанная с облачными технологиями:

Microsoft Visio 2013 Standard - сокращенная поставка.
Microsoft Visio 2013 Professional - полный вариант.
Microsoft Visio 2013 Pro for Office 365 - работа по подписке на Office 365.

Возможности, доступные только в облаке:

Power BI - визуализирующий данные иструмент на основе облачных технологий, помогающий извлекать полезную информацию из сложных наборов данных.
Data Visualizer - иструмент, преобразующий схемы процессов из Excel в основанные на фактических данных схемы в Visio.
Visio Viewer для iOS - просмотр и редактированиеь схем Visio на iPad и iPhone.
PowerPoint Slide Snippets - инструмент, позволяющий выбирать определенные части схемы, присваивать им имена и экспортировать их в виде слайдов в PowerPoint. Таким образом, разбивая сложные диаграммы на отдельные части, можно создать целую презентацию PowerPoint для облегчения понимания

Выпущенные далее версии имели тот же состав.

Visio 2016 (16.0; Standard, Professional, Pro for Office 365)
Visio 2019 (16.0; Standard, Professional, Pro for Office 365)

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

Используя web браузер можно организовать общий доступ к просмотру схем. При дополнительной установке SharePoint Server и Microsoft Lync 2013 у пользователей появляется возможность комментировать схемы, осуществлять совместную работу с ними и обмениваться сообщения.

Каждую фигуру из схемы можно связать с набором данных из Excel, SharePoint, службы SharePoint Business Connectivity Services и SQL Server. Для наглядного представления данных можно использовать большое количество графиков и цветовых схем.

Для проверки корректности создаваемых схем в Visio встроены правила, позволяющие контролировать правильность применения элементов. Эти правила заданы для стандартных нотаций, таких как BPMN . При необходимости, такие правила можно задавать самостоятельно.

3.2.2 PowerDesigner

Ещё одна программа для проектирования информационной системы была выбрана из статьи на специализированном сайте, где бизнес/системный аналитик делилась опытом выбора и внедрения подобного программного обеспечения. «Хотя PowerDesigner в разы дороже других, мы выбрали его».

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

AMC*Designor был разработан в 1989 году компанией SDP Technologies, изначально использовался только для ее внутренних нужд. Однако уже в 1990 году продукт был выпущен на французский рынок, а в 1992 году – на рынок США, уже под названием S-Designor. Можно отметить, что окончание «or» в названии продукта ссылается на название СУБД Oracle, на поддержку которой был рассчитан продукт изначально, а в скором времени была добавлена поддержка всех основных СУБД.

В 1995 году компанией Sybase была приобретена компания Powersoft, с этого времени продукт приобрел новое имя, известное в настоящее время– PowerDesigner, а на французском рынке стал называться PowerAMC.

Потом в период с 1990 по 1996 год PowerDesigner развивался только как инструмент для моделирования данных, за это время были добавлены такие функции как:

1991 - возможность работы с несколькими моделями в одном инструменте;
1992 - корпоративная версия;
1996 - моделирование хранилищ данных.

Последней версией в этой цепочке стал PowerDesigner 6.0.

Сформировалось осознание необходимости выхода за пределы моделирования данных, что стало толчком к добавлению в продукт моделей абсолютно новых типов. С 1996 по 1999 годы разработчики работали над этой задачей, и в 1999 году вышел PowerDesigner 7.0, поддерживающий язык моделирования UML.

После этого, в ходе развития программы, с 7 по 9.5 версию появляется достаточно обширный набор средств, для разработчиков приложений. С 9.5 версии, программа содержит полный набор UML диаграмм, а так же, в девятой версии, добавляется функция моделирования бизнес процессов. Одновременно с этим развивался список поддерживаемых языков программирования, для которых существовала возможность генерации кода и обратного проектирования. Таких, как: Java/J2EE, PowerBuilder, VB.Net, С#.

В 2004 году, с выходом PowerBuilder 10 значительно увеличена модель построения бизнес-процессов, а так же была добавлена возможность их симуляции. В этом релизе так же была добавлена XML модель, позволяющая проектировать XSD схемы. Все новые типы моделей, которые были добавлены в PowerDesigner, связывались с уже имеющимися. Это помогало выстраивать процедуру сквозного моделирования: бизнес-процессы - к логической и физической модели данных с одной стороны, и к модели приложения- с другой.

В 2004 году появилось представление, что эту связь необходимо развивать и усиливать. В связи с этим, новая версия PowerDesigner 11, вышедшая в 2005 году, уже содержала новую модель требований, а также – впервые появилась возможность проведения Impact Analysis - анализа влияний. Он давал понимание взаимосвязи объектов моделей разных типов между собой.

Версии PowerDesigner 12 и PowerDesigner 12.5 продолжили выбранный ранее путь: в них увеличилось количество возможных связей между моделями, появился и начал развиваться редактор мэппингов, который давал возможность связывать между собой объекты классов из объектно-ориентированной модели, объекты XML-модели и объекты различных моделей данных.

Версия PowerDesigner 15 вышла в 2008 году и стала поддерживать модель Архитектуры предприятия, что вывело PowerDesigner на новый уровень и замкнуло цепочку сквозного моделирования.

В 2011 г. была выпущена PowerDesigner 16.0, содержащая с новую оболочку, с удобным пользовательским интерфейсом на основе ролей, глоссарием, анализом воздействия на хранилище, мастером эталонной архитектуры Sybase IQ, а так же поддержкой новой базы данных, enhance улучшениями веб-портала

Ещё через 2 года, в 2013году вышла версия PowerDesigner 16.5 с функциями , поддерживающими SAP Platform: SAP HANA , SAP BusinessObjects , SAP NetWeaver и SAP Solution Manager.

На сегодняшний день, самой актуальной является версия PowerDesigner 16.6, вышедшая в марте 2016 года с поддержкой представлений вычислений SAP HANA и базовых служб данных (CDS) SAP HANA. В PowerDesigner Web появилась возможность редактировать модели архитектуры предприятия и требований

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

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

3.2.3 Edraw Max

И последним рассматриваемым инструментом будет программа, которую предлагает поисковая система гугл по первой ссылке запроса «uml диаграммы программы». На Июнь 2020 года это программа UML Diagram Maker.

Созданная в конце 2004 года, она значительно отличается от приведённых выше программных средств именно своей простотой.

UML Diagram Maker - это мощная лёгкая программа для создания диаграмм UML. Она позволяет легко создавать диаграммы UML с профессиональным внешним видом при помощи встроенных символов и шаблонов. Легко сделать диаграмму последовательности UML, диаграмму использования, диаграмму классов UML, диаграмму деятельности UML, диаграмму развертывания UML и многие другие.

Последняя версия Edraw Max, доступна в двух редакциях: Free Viewer Version и Professional Editable Version – включает в себя дополнительные шаблоны и примеры для создания диаграмм.

В отличие от описанных выше программ, Edraw Max сохраняет содержимое только в одном формате - XML. Суффикс .edx является форматом файла по умолчанию. Суффикс .edxz - это сжатый формат файла xml, используемый для обмена.

Последней актуальной версией считается Edraw Max 9,4. И имеет условно-бесплатную лицензию.

Начиная с версии 8.0, вышедшей в марте 2016 эта программа считается кроссплатформенной и подходит для всех трёх основных операционный систем: Windows, Mac, Linux. До этой версии инструмент был заточен для работы только с Windows.

Программа позицианируется как «альтернатива Visio для создания диаграммы UML на Mac Windows и Linux по более дешевой цене», однако хоть и содержит точные символы, охватывает не все типы диаграмм UML. Одновременно с этим содержит множество разных шаблонов и помогает создать необходимую модель.

Доступные типы диаграмм UML: диаграммы деятельности, класса, взаимодействия, развертывания, последовательности, диаграммы состояний, вариантов использования языка UML и диаграммы компонентов.

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

В завершении хочется отметить, что в настоящее время существует так же тенденция к объединению в одном инструменте функций CASE-средства и среды разработки программ. Так, последние версии программных продуктов (Delphi, JBuilder, Eclipse, Together Architect, Rational Application Developer и др.) снабжены не только функциями, предназначенными для программистов (написание кода, запуск и отладка программ), но и функциями проектирования и визуализации архитектуры разрабатываемых продуктов на базе UML. В этих продуктах широко развит инструмент синхронизации моделей системы с исходным кодом программ. Так, любые изменения диаграмм мгновенно приводят к автоматической корректировке кода и наоборот. Таким образом, надежды разработчиков по более тесной интеграции работ и их результатов для стадий проектирования и программирования становятся реальностью.

Заключение

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

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

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

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

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

Список использованной литературы

ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.
ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств).
Буч Г. и др. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. – СПб : М.: Бином, 2001. – С. 560.
Буч Г. Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя //М., СПб.: ДМК Пресс, Питер. – 2004– С. 432.
Боровская Е. Давыдова Н. Программирование. Учебное пособие. – Litres, 2014. – 240 с.-
Вендров Л.М. Проектирование программного обеспечения экономических информационных систем: Учебник. — 2-е изд., перераб. и доп. — М.: Финансы и статистика, 2005. . – С. 544
Гранд, М. Шаблоны проектирования в Java / М. Гранд. - М.: Новое знание, 2004. - – С. 559
Крачтен, Ф. Введение в Rational Unified Process Издательский дом «Вильямс», 2002. – С. 240.
Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос.: Издательский дом «Вильямс», 2001. - – С. 496
Леоненков А. В. Самоучитель UML 2. – БХВ-Петербург, 2007– С. 576.
Михайлов Л. Объектно-ориентированная технология разработки программных систем. — М.: Финансы и статистика, 2005. . – С. 298
Соловьев Н, Чернопрудова Е. Системы автоматизации разработки программного обеспечения– Litres, 2017. – 292 с.
Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 1998. - 672
Якобсон А., Буч Г., Рамбо Д. Унифицированный процесс разработки программного обеспечения – СПб.: Питер, 2002. С.496
Chambers C. The design and implementation of the self compiler, an optimizing compiler for object-oriented programming languages : дис. – Stanford University, Department of Computer Science, 1992.
Mössenböck H. Costs and Benefits of OOP //Object-Oriented Programming. – Springer, Berlin, Heidelberg, 1993. – С. 215-220.

Электронные ресурсы:

Википедия. URL: ru.wikipedia.org (дата обращения 09.06.2020)
Учебно-методические материалы и результаты научных исследований В.В. Анисимова URL: sites.google.com/site/anisimovkhv (дата обращения 09.06.2020)
Программирование URL: prog-cpp.ru (дата обращения 09.06.2020)
Хабр URL: habr.com (дата обращения 09.06.2020)
Edraw visualization solutions URL: edrawsoft.com (дата обращения 09.06.2020)
Visioport URL: visioport.ru (дата обращения 09.06.2020)
Национальная библиотека им. Н. Э. Баумана Bauman National Library URL: ru.bmstu.wiki (дата обращения 09.06.2020)

приложение

[image]

Рисунок 1. Классификации информационных систем