М И Н О Б Р Н А У К... Федеральное государственное бюджетное образовательное учреждение высшего образования
advertisement
МИНОБРНАУКИ РОССИИ Федеральное государственное бюджетное образовательное учреждение высшего образования «Омский государственный педагогический университет» (ФГБОУ ВО «ОмГПУ») Факультет математики, информатики, физики и технологии Кафедра прикладной математики и информатики Использование языка UML при моделировании объекта автоматизации, на примере регистратуры детской стоматологии Курсовая работа Направление __________________________________________________________ Направленность (профиль)_______________________________________________ Дисциплина ___________________________________________________________ Выполнила: студентка Группы ПИ-33 Черногородова Наталья Алексеевна ______________________ (подпись) Научный руководитель: Чеботарев Николай Александрович к.т.н., доцент кафедры прикладной информатики и математики Оценка________________ «__» _______________ 2015г. __________________ (подпись) Омск, 2015 Оглавление ВВЕДЕНИЕ .............................................................................................................. 4 ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ЯЗЫКА UML ................................... 5 1.1 История развития UML ................................................................................. 5 1.2 Правила языка UML ...................................................................................... 7 1.2.1 Диаграмма вариантов использования ...................................... 9 1.2.2 Диаграмма классов .................................................................... 9 1.2.3 Диаграмма коопераций ........................................................... 10 1.2.4 Диаграмма последовательности ............................................. 12 1.2.5 Диаграмма состояний .............................................................. 13 1.2.6 Диаграмма деятельности ......................................................... 15 1.2.7 Диаграмма компонентов ......................................................... 17 1.2.8 Диаграмма развертывания ...................................................... 18 ГЛАВА 2. Проектирование объекта автоматизации на примере регистратуры детской стоматологии. .......................................................................................... 20 Работа № 1 ............................................................................................... 20 «Формирование модели функционирования программного средства с использованием UML» ..................................................................................... 20 Работа № 2 ............................................................................................... 24 «Разработка логической структуры программного средства с использованием UML» ..................................................................................... 24 Работа № 3 ............................................................................................... 25 «Разработка структуры состояний и динамической модели программного средства с использованием UML» ......................................... 25 Работа № 4 ............................................................................................... 28 2 «Разработка физического представления процесса функционирования программного средства с использованием UML» ....... 28 ЗАКЛЮЧЕНИЕ ..................................................................................................... 30 СПИСОК ЛИТЕРАТУРЫ..................................................................................... 31 3 ВВЕДЕНИЕ Язык UML – это графический язык моделирования общего назначения, предназначенный для спецификации, визуализации, проектирования и документирования всех артефактов, создаваемых при разработке программных систем[1]. Основное назначение UML — предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное, и, с третьей стороны, достаточно универсальное средство, позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций. UML предназначен для решения различных задач, соответственно он может быть использован и практически используется по-разному. Способы использования UML: Графическое представление объектов моделирования. Обмен информацией. Спецификация систем. Повторное использование архитектурных решений. Генерация кода. Имитационное моделирование. Верификация моделей. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками: является языком визуального обеспечивает разработку моделирования, репрезентативных который моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; содержит механизмы расширения и специализации базовых концепций языка. 4 ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ЯЗЫКА UML 1.1 История развития UML Решающую роль в создании языка UML сыграли Гарди Буч, Джеймс Рамбо и Айвар Джекобсон и созданные ими следующие методы моделирования различных сторон сложных систем: Метод Буча (Booch'93), ориентированный, в первую очередь, на моделирование программного обеспечения сложных систем. Метод Рамбо (ОМТ-2), ориентированный на анализ процессов обработки данных в информационных системах. Метод Джекобсона (метод OOSE), ориентированный на анализ требований к бизнес-приложениям. Авторы этих унифицированного методов языка объединились моделирования с целью сложных создания систем. Они сформулировали следующие требования к унифицированному языку, который был назван UML. Язык UML: Позволяет моделировать как программное обеспечение сложных систем, так и широкие классы самих систем и бизнесприложений, с использованием объектно-ориентированных понятий и методов. Обеспечивает взаимосвязь между базовыми понятиями моделей концептуального, программного и физического уровней. Понятен системным аналитикам и программистам. Поддерживается специальными инструментальными программными средствами, реализованными на различных компьютерных платформах. В 1996 г. была создана первая версия языка UML 0.9. После этого ведущие компьютерные фирмы Microsoft, IBM, Oracle и многие другие осознали, что язык UML имеет стратегическое значение для их бизнеса. В 5 результате был организован консорциум UML, деятельность которого оплачивается за счет ежегодных денежных взносов фирм членов консорциума. Важную роль в создании языка UML сыграла его поддержка группой по управлению объектами OMG (Object Management Group). Язык UML приобрел статус второго стратегического направления деятельности OMG. В 1997 г. были созданы версии языка UML 1.0 и 1.1. В 1998 г была создана версия UML 1.2, а в 1999 г - версия UML 1.3. В настоящее время разработаны инструментальные программы поддержки языка UML. Наиболее известной из них является программы Rational Rose 2000 фирмы Rational Software[2]. 6 1.2 Правила языка UML Строительные блоки UML нельзя произвольно объединять друг с другом. Как и любой другой язык, UML характеризуется набором правил, определяющих, как должна выглядеть хорошо оформленная модель, то есть семантически самосогласованная и находящаяся в гармонии со всеми моделями, которые с нею связаны. В языке UML имеются семантические правила, позволяющие корректно и однозначно определять: имена, которые можно давать сущностям, отношениям и диаграммам; область действия (контекст, в котором имя имеет некоторое значение); видимость (когда имена видимы и могут использоваться другими элементами); целостность (как элементы должны правильно и согласованно соотноситься друг с другом); выполнение (что значит выполнить или имитировать некоторую динамическую модель). Модели, создаваемые в процессе разработки программных систем, эволюционируют со временем и могут неоднозначно рассматриваться разными участниками проекта в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые: содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие); неполные (отдельные элементы пропущены); несогласованные (целостность модели не гарантируется). Появление не слишком хорошо оформленных моделей неизбежно в процессе разработки, пока не все детали системы прояснились в полной мере. Правила языка UML побуждают - хотя не требуют - в ходе работы над 7 моделью решать наиболее важные вопросы анализа, проектирования и реализации, в результате чего модель со временем становится хорошо оформленной. В UML всего определено 8 канонических типов диаграмм: вариантов использования (use case diagram); классов (class diagram); кооперации (collaboration diagram); последовательности (sequence diagram); состояний (statechart diagram); деятельности (activity diagram); компонентов (component diagram); развертывания (deployment diagram); Рассмотрим каждую диаграмму подробнее. 8 1.2.1 Диаграмма вариантов использования Диаграмма использования (use case diagram) — это наиболее общее представление функционального назначения системы. Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире? На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений: ассоциация между действующим лицом и вариантом использования; обобщение между действующими лицами; обобщение между вариантами использования; зависимости между вариантами использования. На диаграмме использования, как и на любой другой, могут присутствовать примечания. Основные элементы, применяемые на диаграмме использования, показаны на рис. 1.1. Рис. 1.1 – Диаграмма использования. 1.2.2 Диаграмма классов Диаграмма классов (class diagram) — основной способ описания структуры системы. 9 На диаграмме классов применяется один основной тип сущностей: классы, между которыми устанавливаются следующие основные типы отношений: ассоциация между классами (с множеством дополнительных подробностей); обобщение между классами; зависимости (различных типов) между классами и между классами и интерфейсами. Основные элементы, применяемые на диаграмме классов, показаны на рис. 1.2. Рис. 1.2 – Диаграмма классов. 1.2.3 Диаграмма коопераций Реализация отдельного варианта использования требует участия и взаимодействия определенных экземпляров актеров и классов. Диаграмма кооперации прежде всего отображает структуру взаимодействия и содержит следующие элементы: 10 экземпляры актеров и классов, участвующих в реализации варианта использования; ассоциации между экземплярами актеров и классов; сообщения, передаваемые между экземплярами актеров и классов. взаимодействие между экземплярами актеров и объектами моделируется посредством сообщений, отображаемых над ассоциациями. Сообщение – это спецификация факта передачи информации между сущностями с ожиданием выполнения определенных действий со стороны принимающей сущности. Сущность, отправляющую сообщение, называют клиентом, а принимающую – сервером. Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают выполнения сервером определенных действий или передачу (возврат) клиенту необходимой информации. Если принимающей сообщение сущностью является объект, то оно представляет собой операцию (метод) объекта-сервера. Прием сообщения обычно трактуется, как возникновение события на сервере[6]. Сообщения изображаются стрелкой с обязательным указанием направления (остриё стрелки указывает на сервер) и его спецификации. Сообщения могут быть следующих видов: – синхронное сообщение (передача управления). Клиент посылает сообщение серверу и ждет, пока тот примет и обработает сообщение. Как правило, в кооперации один объект передает синхронное сообщение второму, второй – третьему и т. д., образуя вложенный поток сообщений. В любом случае клиент, инициирующий поток сообщений, должен дождаться завершения вложенного потока, т. е. возврата управления. Это самый распространенный тип сообщений; 11 – асинхронное сообщение. Клиент посылает сообщение серверу и, не дожидаясь ответа, продолжает выполнять свою работу дальше; – возвращающее сообщение (возврат управления), обозначающее возврат значения или управления от сервера обратно клиенту. Стрелки этого вида зачастую отсутствуют на диаграммах кооперации, поскольку неявно предполагается их существование после окончания процесса выполнения операции. 1.2.4 Диаграмма последовательности Диаграмма последовательности вместо структуры взаимодействия более наглядно показывает его временной аспект. На диаграмме последовательности отображаются те же элементы, что и на диаграмме кооперации (экземпляры актеров, объекты и сообщения), а также ряд специфичных элементов: Линия жизни – отображается пунктирной вертикальной линией, ассоциированной с соответствующим объектом. Линия жизни служит для обозначения периода времени, в течение которого объект может потенциально участвовать во взаимодействии. Если он существует в течение всего взаимодействия, то и его линия жизни должна продолжаться от самой верхней части диаграммы до самой нижней[6]. Не обязательно создавать все объекты в начальный момент времени. Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность. В этом случае объект изображается не в верхней части диаграммы, а в том месте, где он создается. Для обозначения факта уничтожения объекта в UML используется специальный символ X (рис. 1.3). 12 Рис.1.3 – Пример обозначения линии жизни и символа уничтожения объекта В процессе взаимодействия одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия, или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, на диаграмме можно использовать элемент фокус управления. Он изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а нижняя сторона – окончание фокуса управления (окончание активности). 1.2.5 Диаграмма состояний Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах. Диаграмма состояний (автомат) представляет собой связный ориентированный граф, вершинами которого являются состояния, а дуги служат для обозначения переходов из состояния в состояние. 13 В UML различают два вида операций: действие и деятельность. Действие – это атомарная операция, выполнение которой не может быть прервано, приводящая к смене состояния или возвращающая значение. Примерами действий служат операции создания или уничтожения объекта, расчет факториала и т. д. Деятельность – это составная (неатомарная) операция, реализуемая экземпляром в конкретном состоянии, выполнение которой может быть прервано. В частности, под деятельностью можно понимать процедуры расчета допускаемых скоростей или шифрования данных. В качестве события могут выступать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий. Различаются следующие виды событий: Событие вызова (call event) - событие, возникающее при вызове метода класса. При срабатывании данного вида события объектом ассинхронно создается Сигнал, который принимается другим объектом. Для указания на то, что некоторая операция посылает сигнал, можно воспользоваться зависимостью со стереотипом send. Событие сигнала (signal event) - событие, возникающее при посылке сигнала. Если событие сигнала представляет возбуждение сигнала, то событие вызова предназначено для описания выполнения операции. Т.е. переход осуществляется при получении сигнала от другого объекта. В то время как сигнал является событием асинхронным, событие вызова обычно синхронно. Сигнал также может быть представлен на диаграмме в виде объекта со стереотипом «signal». Событие таймера (time event) - возникает, когда истек заданный интервал времени с момента попадания автомата в данное 14 состояние. В UML событие времени моделируется с помощью ключевого слова after(после), за которым следует выражение, вычисляющее некоторый промежуток времени. Событие изменения (change event) - событие, которое возникает, когда некоторое логическое условие становится истинным, будучи до этого ложным. Данное событие моделируется с помощью ключевого слова when Состояние отображается в виде прямоугольника со скругленными углами, внутри которого записывается имя (рис. 1.4). Рекомендуется в качестве имени использовать глаголы в настоящем времени (звенит, печатает, ожидает) или причастия (занято, передано, получено). Рис. 1.4 – Способы отображения состояний 1.2.6 Диаграмма деятельности Диаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов. Деятельность выполняется, только тогда, когда готовы все его «входы», после выполнения, деятельность передает управление и(или) данные на свои «выходы». Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали слева направо или сверху вниз. Чтобы указать, где именно находится процесс, используется абстрактная точка «маркер» (или «токен»). Визуально на диаграмме маркер 15 не показывается, данное понятие вводится только для удобства описания динамического процесса. Переход маркера осуществляется между узлами. Маркер может не содержать никакой дополнительной информации (пустой маркер) и тогда он называется маркером управления (control flow token) или же может содержать ссылку на объект или структуру данных, и тогда маркер называется маркером данных (data flow token). Для создания диаграммы деятельности используются следующие узлы: Узел управления (control node) – это абстрактный узел действия, которое координирует потоки действий; Начальный узел деятельности (или начальное состояние деятельности) (activity initial node) является узлом управления, в котором начинается поток (или потоки) при вызове данной деятельности извне; Конечный узел деятельности (или конечное состояние деятельности) (activity final node) является узлом управления, который останавливает (stop) все потоки данной диаграммы деятельности. На диаграмме может быть более одного конечного узла; Конечный узел потока (или конечное состояние потока) (flow final node) является узлом управления, который завершает данный поток. На другие потоки и деятельность данной диаграммы это не влияет; Объект, над которым выполняются действия. Это не обязательный элемент диаграммы, но в некоторых случаях необходимо показать объект инициирующий выполнение действий, или являющийся результатом его. 16 Для отображения расширений сценария на диаграмме деятельности используются, так называемые узлы решения. Узел решения предназначен для определения правила ветвления и различных вариантов дальнейшего развития сценария. Рис. 1.5 – Пример узла решения 1.2.7 Диаграмма компонентов Диаграмма компонентов позволяет определить состав программных компонентов, в роли которых может выступать исходный, бинарный и исполняемый код, а также установить зависимости между ними. При разработке диаграмм компонентов преследуются цели: спецификация общей структуры исходного кода системы; спецификация исполнимого варианта системы. Данная диаграмма обеспечивает согласованный переход от логического к физическому представлению системы в виде программных компонентов. Одни компоненты могут существовать только на этапе компиляции программного кода, другие – на этапе его исполнения. Основными элементами диаграммы являются компоненты, интерфейсы и зависимости между ними. Кроме этого, на ней могут отображаться ключевые классы, входящие в компоненты. Компонент – это физическая часть системы. Компоненты, представляющие собой файлы с исходным кодом классов и исполняемые 17 модули, должны обладать согласованным набором интерфейсов. Для их графического представления используется символ (рис. 1.6). Рис. 1.6 – Примеры компонентов 1.2.8 Диаграмма развертывания Диаграмма развертывания предназначена для визуализации элементов и компонентов системы, существующих лишь на этапе ее исполнения (runtime), к которым относятся исполнимые файлы, динамические библиотеки, таблицы БД и т. д. Те компоненты, которые не используются на этапе исполнения (например, исходные тексты программ), на диаграмме не показываются. Основные цели, преследуемые при разработке диаграммы развертывания: распределение компонентов системы по ее физическим узлам; отображение физических связей между узлами системы на этапе исполнения; выявление узких мест системы и реконфигурация ее топологии для достижения требуемой производительности. Элементами диаграммы развертывания являются узлы, компоненты и связи между ними. Узел представляет собой некоторый физически существующий элемент системы. В качестве узла могут рассматриваться компьютеры, датчики, принтеры, модемы, цифровые камеры, сканеры и т.д. Графически узел изображается в форме трехмерного куба, внутри которого указывается его имя и, возможно, дополнительная информация в виде помеченного значения (рис. 1.7). 18 Рис. 1.7 – Примеры узлов В качестве канала связи между узлами выступает физическое соединение. Соединения показываются в виде ассоциации и изображаются линиями без стрелок. Наличие такой линии указывает на необходимость организации канала для обмена информацией между соответствующими узлами (рис. 1.8). Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением. Рис. 1.8 – Пример соединения между узлами 19 ГЛАВА 2. Проектирование объекта автоматизации на примере регистратуры детской стоматологии. Были выполнены работы по моделированию информационной системы «детская стоматология» на языке UML в среде Rational Rose. Результатом их выполнения стали диаграммы вариантов использования, коопераций, классов, состояний, деятельности, последовательностей, компонентов программного средства и развертывания программного средства. Работа № 1 «Формирование модели функционирования программного средства с использованием UML» Программное средство регистратуры детской стоматологической клиники, имеющее агентов: секретарь, врачи и клиенты. Функции секретаря– внесение, исключение записей в базе данных (или подтверждение по запросам клиентов через интернет), запрос расписания врачей, определение времени приёма по справочнику, исключение или перенос записей по требованию врача с уведомлением клиентов, связь с врачом. Функции врача– анализ заявок на обслуживание и формирование предложений по оптимизации записей при наличии ошибок или иным обстоятельствам, заполнение карточки по результатам приёма; функции клиентов – поиск информации о расписании врачей, получение информации об опыте, образовании и достижениях врачей, запись на приём (по телефону, лично у секретаря или через интернет), запрос на справку у врача, связь с секретарём через интернет или телефон. Задание 1 Полностью раскрыть все варианты использования, включая те, которые не упомянуты в задании. Вариантов использования в одном варианте должно быть не менее 15-20. Актёров (интерфейсов) не менее 3-х. Логика функционирования программного средства должна быть полностью описана. 20 В результате должен быть сформирован список актёров (интерфейсов) и их функций (вариантов использования) в виде уровневого списка или таблицы. 1. Клиент: Запись на сеанс: По телефону; Через интернет; Лично у секретаря; Запрос на справку у врача; Получение информации о враче: Об образовании врача; О достижениях врача; Об опыте врача; Поиск информации о расписании врачей; 2. Секретарь: Запись на прием; Определение времени приема по справочнику; Перенос/отмена записей по требованию врача, с уведомлением клиента; Получение информации о враче: Об образовании врача; О достижениях врача; Об опыте врача; 3. Врач: Заполнение карточки по результатам приема; Перенос/исключение записей; Определение времени приема по справочнику; Предоставление услуг; 21 Задание 2 Сформировать диаграмму вариантов использования с использованием программы Rational Rose, полностью описывающую функциональное назначение программного. Диаграммы вариантов использования представлены на рис. 2.1, 2.2, 2.3. Рис. 2.1. – диаграмма вариантов использования для актера врач Рис. 2.2 – диаграмма вариантов использования для актера секретарь 22 Рис. 2.3 – диаграмма вариантов использования для актера клиент Задание 3 Сформировать диаграмму кооперации. Диаграмма представлена на рис. 2.4. Рис. 2.4 – диаграмма кооперации 23 Работа № 2 «Разработка логической структуры программного средства с использованием UML» Задание 1 Разработать диаграмму классов для заданного варианта. Классы в диаграмме должны иметь не менее 2-х видов ассоциаций. Все отношения должны быть поименованы. Должны присутствовать классы с атрибутами и классы с операциями. Один или более классов должны быть представлены в виде объектов. Диаграмма классов представлена на рис. 2.5. Рис. 2.5 – диаграмма классов 24 Работа № 3 «Разработка структуры состояний и динамической модели программного средства с использованием UML» Задание 1 Для диаграммы вариантов использования и диаграммы классов, построенных в предыдущих лабораторных работах выбрать не менее 2 вариантов использования и 2-х классов, имеющих динамические характеристики. Варианты использования : 1. Звонок клиента секретарю; 2. Отмена приёма врачом; Классы: 1. Секретарь; 2. Клиент; Задание 2 Сформировать для каждого выбранного варианта использования и класса диаграммы состояний, описав в них все состояния, события, переходы и условия. В одной или более диаграмм должны содержаться сложные переходы. Диаграммы состояний представлены на рис. 2.6, 2.7, 2.8, 2.9. Рис. 2.6 – диаграмма состояний для варианта использования «звонок клиента» 25 Рис. 2.7 – диаграмма состояний для варианта использования «отмена сеанса врачом» Рис. 2.8 – диаграмма состояний для класса «секретарь» 26 Рис. 2.9 – диаграмма состояний для класса «клиент» Задание 3 Сформировать диаграмму деятельности с дорожками для самого сложного варианта использования. Диаграмма деятельности представлена на рис. 2.10. Рис. 2.10 – диаграмма деятельности 27 Задание 4 Сформировать диаграмму последовательности для варианта использования, для которого не строилась диаграмма деятельности. Диаграмма последовательности представлена на рис. 2.11. Рис. 2.11 - диаграмма последовательностей Работа № 4 «Разработка физического представления процесса функционирования программного средства с использованием UML» Задание 1 Для варианта, выполненного на 1-й лабораторной работе на основе вариантов использования разработать диаграмму компонентов программного средства. Диаграмма компонентов программного средства представлена на рис. 2.12. 28 Рис 2.12 – диаграмма компонентов программного средства Задание 2 Для варианта, выполненного на 1-й лабораторной работе на основе вариантов использования разработать диаграммы развертывания программного средства. Диаграмма развёртывания программного средства представлена на рис. 2.13. Рис 2.13 – диаграмма развертывания программного средства 29 ЗАКЛЮЧЕНИЕ В результате курсовой работы была спроектирована автоматизированная информационная система «Детская стоматология». Данная система удовлетворяет всем требованиям, предъявленным в заданиях, и реализует большинство необходимых сотрудникам стоматологии функций. В результате выполнения курсовой работы был сделан вывод, о преимуществах языка UML: UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно- ориентированных языках; UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы; Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом; UML получил широкое распространение и динамично развивается. 30 СПИСОК ЛИТЕРАТУРЫ 1. Ф.Новиков, Д.Иванов, Моделирование на UML //Моделирование на UML – Режим доступа: http://book.uml3.ru/sec_1_2 2. История языка UML// Helpikc.org – Режим доступа: http://helpiks.org/299890.html 3. Краткая история UML// ЕДИНЫЙ ЦЕНТР ДИСТАНЦИОННОГО ОБРАЗОВАНИЯ АКЕСО– Режим доступа: http://www.maksakovsa.ru/ModelUML/IstorUML/index.html 4. В. Грекул, Проектирование информационных систем // НОУ ИНТУИТ. – Режим доступа:http://www.intuit.ru/studies/courses/2195/55/lecture/1638 5. Г. Буч, Д. Рамбо, А. Джекобсон, Язык UML Руководство пользователя// Режим доступа: http://dit.isuct.ru/ivt/books/CASE/case11/ch2.htm 6. В.И. Грекул Г.Н. Денищенко Н.Л. Коровкина «Проектирование информационных систем» / Интернет-Университет Информационных Технологий М., 2005 7. Язык моделирования UML// Russika.ru – Режим доступа: http://www.russika.ru/ef.php?s=4785 8. Российская Академия Естествознания «ТЕНДЕНЦИИ В РАЗВИТИИ ЯЗЫКА UML И РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ» // Режим доступа: http://www.rae.ru/monographs/141-4637 9. Д. Ю. ИВАНОВ, Ф. А. НОВИКОВ, УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML, Санкт-Петербург , Издательство Политехнического университета, 2010 10.А. Бабич, Введение в UML // НОУ ИНТУИТ. – Режим доступа: http://www.intuit.ru/studies/courses/1007/229/lecture/5954?page=2 11.А. Леонтьев, Нотация и семантика языка UML // НОУ ИНТУИТ. – Режим доступа: http://www.intuit.ru/studies/courses/32/32/lecture/1004?page=3 31
