Унифицированный язык UML при проектировании информационных систем
Познакомиться с возможностями унифицированного языка UML при проектировании информационных систем. Познакомиться со средой визуального проектирования информационных систем Enterprise Architect
1988-92 – Предпосылки к созданию UML. 1994 – объединение двух методов, Booch, созданный Грейди Бучем и ОМТ ( Object Modeling Technique), автором которого является Джеймс Рамбо. Октябрь 1995 года – первая пробная версия 0.8 Унифицированного Метода ( Unified Method ), к разработке присоединился Айвар Джекобсон с методом OOSE (Object-Oriented Software Engineering)
июнь 1996 года вышла версия 0.9 языка UML. В январе 1997 года UML 1.0 был представлен Группе по управлению объектами ( Object Management Group, OMG) на конкурс по созданию стандартного языка моделирования. В июне 1998 года вышла версия UML 1.2, а осенью 1998 – UML 1.3. В 2001 году вышла версия UML 1.4.2, сейчас это международный стандарт ISO В 2005 – UML 2.0 В 2010 – UML 2.3, пока это последняя версия
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Модель IDEF0 Применяются также модели DFD и IDEF3
Достоинства Возможность проведения глубокого анализа бизнес-процессов, выявления узких мест: комплексное применение позволяет выявить все возможные рассогласования и неточности Применение универсальных графических языков моделирования IDEF 0, IDEF 3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов Методология проверена временем, широко распространена среди аналитиков и разработчиков
Недостатки Низкая наглядность для неподготовленных пользователей модели: при увеличении количества уровней представления, анализ и модификация моделей становятся затруднительными. Сложность восприятия иерархически упорядоченной информации. Необходимость следования жёсткой структуре. Вывод: Рекомендуется применять для правильного, точного и полного определения требований к ИС на начальных этапах
Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщений между объектами UML диаграммы
Достоинства Сравнительная легкость, наглядность, эффективность моделей Гибкость, возможность адаптировать методологию UML собственными элементами и видами диаграмм. Возможность автоматической генерации кода на основе построенных моделей
Недостатки Невозможность проведения детального анализа процессов. Неполнота и незавершенность некоторых видов диаграмм, возможность их неверной интерпретации. Вывод: Язык UML может выступает в роли сильного инструмента для грамотных проектировщиков и программистов.
Система ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД СТРУКТУРНЫЙ ПОДХОД Декомпозиция на объекты и понятия Декомпозиция на функции и процессы Сертификат Сотрудник Допуск Свидетельство Система Учет сертификатов и допусков Подготовка списков Обучение Отправка документов
Диаграмма классов ( Class Diagram ) Диаграмма компонентов ( Component Diagram ) Диаграмма объектов ( Object Diagram ) Диаграмма составных структур ( Composite Structure Diagram ) Диаграмма развертывания ( Deployment Diagram ) Диаграмма пакетов ( Package Diagram ) Диаграмма последовательности ( Sequence Diagram ) Коммуникационная диаграмма ( Communication Diagram ) Диаграмма обзора взаимодействия ( Interaction Overview Diagram ) Временная диаграмма ( Timing Diagram ) Диаграмма деятельности ( Activity Diagram ) Диаграмма прецедентов ( Use Case Diagram ) Диаграмма состояний ( State Machine Diagram ) Диаграммы взаимодействия ( Interaction Diagram ) Диаграммы UML Диаграммы структуры ( Structure Diagram ) Диаграммы поведения ( Behavior Diagram )
Диаграмма прецедентов (диаграмма вариантов использования). Описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.
Структурные элементы Актер Вариант использования Взаимосвязи Ассоциация Расширение Обобщение Включение
Диаграмма классов ( class diagram ) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать различные взаимосвязи между объектами и подсистемами, а также описывает их внутреннюю структуру и типы отношений.
Структурные элементы Отношения Ассоциация Агрегация Обобщение Композиция
На диаграмме Состояний отображают жизненный цикл одного объекта, начиная с момента его создания и заканчивая разрушением. С помощью таких диаграмм удобно моделировать динамику поведения класса.
Структурные элементы Взаимосвязи
Диаграмма состояний класса Учащийся
Диаграмма состояний класса Администратор
Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени. На диаграмме последовательности изображаются только те объекты, которые непосредственно участвуют во взаимодействии.
Структурные элементы Сообщения
Диаграмма последовательности для Учащегося
Диаграмма последовательности для Администратора
Разрабатывается программная система, автоматизирующая продажу и бронирование билетов в кассе железнодорожного вокзала. Проведены работы по сбору требований к системе. Согласно собранным сведениям, с системой должен работать кассир. С помощью системы он должен выполнять следующие функции: забронировать билеты с указанием поезда, даты, вагона мест, получить данные о наличии свободных мест в данном поезде на данную дату, отменить бронирование по желанию клиента. Также при продаже билета без бронирования предварительно проверяется наличие свободных мест. После продажи билета кассир должен внести изменения в данные о наличии свободных мест. Предусмотреть идентификацию пользователей и защиту паролями.
