Области применения UML.
Можно классифицировать сложность системы следующим образом:
| Низкая сложность управления | Низкая техническая сложность | Высокая техническая сложность | Высокая сложность управления |
| 1. Малый масштаб. 2. Неформальные заказы. 3. Один пользователь. | 1. Использование макроязыков или высокоуровневых языков программирования 4-го поколения. 2. Реинжиниринг приложений баз данных. 3. Разработка учетно-расчетных приложений. | 1. Встроенные системы реального времени. 2. Распределенные высоконадежные системы. 3. Высокопроизводительные системы. | 1. Большой масштаб. 2. Контрактные заказы. 3. Много пользователей. |
К системам с высокой технической сложностью и высокой сложностью управления относятся – системы контроля воздушного пространства (аэронавигация), телекоммуникационные системы, системы организации войск и управления ими. Для проектирования таких систем с большой вероятностью потребуется применение UML.
Кроме того UML является стандартом в области создания программных средств и Web-приложений.
Использование языка UML в проектах по отраслевой принадлежности
1. Банки и инвестиционные фонды.
2. Связь и телекоммуникации.
3. Нефтегазовая промышленность.
4. Страховые фонды.
5. Энергетика.
6. Машиностроение.
7. Торговля.
8. Фармацевтическая промышленность.
9. Оборонная промышленность.
10. Федеральная таможенная служба.
11. Учебные заведения.
Средний проект по разработке информационной системы (необходимого ПО):
- 5-10 человек;
- 10-15 месяцев;
- 10-15 внешних интерфейсов (для сетевых приложений).
Взаимосвязь нотации, методологии и инструментальных средств
UML (Unified Modeling Language) – отраслевой стандарт OMG, поддерживают более 50 CASE-средств, основной инструмент в области программирования IBM Rational Rose/ IBM RSA (IBM Rational Software)
IDEF – семейство нотаций, стандарт МО США, рекомендован Правительством РФ для применения в государственных учреждениях, основной инструмент AllFusion Process Modeller (Computer Associations)
ARIS (ARchitecture of Integrated Information Systems) – методология и нотация для профессионального моделирования бизнес-процессов, инструмент ARIS Toolset (IDS Scheer AG)
UML
Unified Modeling Language — унифицированный язык моделирования для описания, визуализации и документирования объектно-ориентированных систем в процессе их анализа и проектирования. UML – это совокупность семантики и нотации.
Язык UML предоставляет стандартный способ написания проектной документации на системы, включая концептуальные аспекты, такие как бизнес-процессы и функции системы, а также конкретные аспекты, такие как выражения языков программирования, схемы баз данных и повторно используемые компоненты ПО.
1. Язык UML не является методологией.
2. Язык UML не является процессом.
3. Язык UML не является языком программирования.
4. Язык UML не является формальным языком.
Назначение языка UML
1. Предоставить разработчикам легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем различного целевого назначения.
2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.
3. Графическое представление моделей в нотации UML не должно зависеть от конкретных инструментальных средств проектирования.
4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.
5. Способствовать распространению объектных технологий и поощрять развитие рынка программных инструментальных средств
6. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.
Особенности изображения диаграмм в нотации UML
Графические узлы на плоскости, которые изображаются с помощью геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML.
Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические узлы.
Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы, которая не может увеличивать свои размеры, чтобы разместить внутри себя дополнительные символы.
Строки текста. Служат для представления различных видов информации в некоторой грамматической форме.
При составлении диаграмм нужно придерживаться простых и логичных правил (они излагаются в виде рекомендации, но их не соблюдение лишь приведет к путанице).
1. Каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области
2. Все сущности на диаграмме модели должны быть одного концептуального уровня
3. Вся информация о сущностях должна быть явно представлена на диаграммах
4. Диаграммы не должны содержать противоречивой информации
5. Диаграммы не следует перегружать текстовой информацией
6. Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов
Модель должна быть непротиворечивой (well-formed model) и адекватной, т.е. соответствовать правилам нотации или семантики языка UML (здесь могут быть использованы формальные критерии – соответствие спецификации языка UML) и достаточно полно и правильно отражающая предметную область или решаемую проблему называется адекватной. Для оценки адекватности могут быть использованы только неформальные критерии – субъективное мнение экспертов.
Канонические диаграммы языка UML 2.х.
Канонические диаграммы языка UML представлены на рис 2. После принятия стандарта UML 2.0 структура языка постоянно модернизируется, что отражается в добавлении новых типов диаграмм и расширении нотации.
Рис. 3.2. Диаграммы языка UML версии 2.x
Диаграмма классов (Class diagram) – статическая структурная диаграмма, описывающая структуру системы, она демонстрирует классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
- концептуальная точка зрения – диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
- точка зрения спецификации – диаграмма классов применяется при проектировании информационных систем;
- точка зрения реализации – диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Диаграмма компонентов (Component diagram) – статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонент могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма композитной/составной структуры (Composite structure diagram) – статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.
Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.
Диаграмма развёртывания (Deployment diagram) – служит для моделирования работающих узлов (аппаратных средств, node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость.
Диаграмма объектов (Object diagram) – демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) – структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.
Диаграмма деятельности (Activity diagram) – диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов – вложенных видов деятельности и отдельных действий (action), соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений. Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701-90.
Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) – диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.
Конечный автомат (англ. State machine) – спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.
Диаграмма прецедентов (Use case diagram, диаграмма вариантов использования) – диаграмма, на которой отражены отношения, существующие между акторами и прецедентами.
Основная задача – представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.
Диаграммы коммуникации и последовательности, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.
Диаграмма коммуникации (Communication diagram, в UML 1.x – диаграмма кооперации, collaboration diagram) – диаграмма, на которой изображаются взаимодействия между частями структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграмма последовательности (Sequence diagram) – диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграмма сотрудничества – Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта, и типы этих сообщений.
По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, некоторые инструментальные средства UML позволяют создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.
Диаграмма обзора взаимодействия (Interaction overview diagram) – разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма синхронизации (Timing diagram) – альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.
Диаграмма вариантов использования (use case diagram)
Диаграмма, на которой изображаются варианты использования проектируемой системы, заключенные в границу системы, и внешние актеры, а также определенные отношения между актерами и вариантами использования
Рис. 3.3. Пример диаграммы вариантов использования.
Назначение диаграммы вариантов использования:
- определить общие границы функциональности проектируемой системы в контексте моделируемой предметной области;
- специфицировать требования к функциональному поведению проектируемой системы в форме вариантов использования;
- разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей;
- подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Рис. 3.4. Основные обозначения на диаграмме вариантов использования
Актер (actor): любая внешняя по отношению к проектируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Примеры актеров: кассир, клиент банка, банковский служащий, президент, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон
Для верного определения роли актеров в процессе функционирования системы предлагается список вопросов для идентификации актеров в системе:
1. Какие организации или лица будут использовать систему?
2. Кто будет получать пользу от использования системы?
3. Кто будет использовать информацию от системы?
4. Будет ли использовать система внешние ресурсы?
5. Может ли один пользователь играть несколько ролей при взаимодействии с системой?
6. Могут ли различные пользователи играть одну роль при взаимодействии с системой?
7. Будет ли система взаимодействовать с законодательными, исполнительными, налоговыми или другими органами?
После определения сущностей, определяются условия отношений между актерами и системой.
Ассоциация (association) является одним из фундаментальных понятий в языке UML 2.х и может использоваться на различных канонических диаграммах при построении визуальных моделей.
Применительно к диаграммам вариантов использования отношение ассоциации может служить только для обозначения взаимодействия актера с вариантом использования.
Рис. 3.5.
Отношение зависимости (dependency) определяется как форма взаимосвязи между двумя элементами модели, предназначенная для спецификации того обстоятельства, что изменение одного элемента модели приводит к изменению некоторого другого элемента.
Отношение включения (include) специфицирует тот факт, что некоторый вариант использования содержит поведение, определенное в другом варианте использования
Рис. 3.6.
Отношение расширения (extend) определяет взаимосвязь одного варианта использования с некоторым другим вариантом использования, функциональность или поведение которого задействуется первым не всегда, а только при выполнении некоторых дополнительных условий.
Рис. 3.7.
Изображение отношения расширения с условием выполнения:
Рис. 3.8.
Отношение обобщения (generalization relationship) предназначено для спецификации того факта, что один элемент модели является специальным или частным случаем другого элемента модели (см. пример ниже).
Рис. 3.9.
Таким образом, диаграмма вариантов использования, например, для интернет-магазина может быть представлена в следующем виде.
Рис. 3.10.
Типичные ошибки при разработке диаграмм вариантов использования:
- превращение диаграммы вариантов использования в диаграмму деятельности за счет желания отразить все функциональные действия;
- инициатором действий является разрабатываемая система;
- спецификация атрибутов и операций классов до того, как сформулированы все варианты использования;
- задание слишком кратких имен вариантам использования;
- описание вариантов использования в терминологии, непонятной пользователям системы или заказчику;
- отсутствие описаний альтернативных последовательностей действий;
- тратится слишком много времени на решение вопросов о том, какие стереотипы и ассоциации использовать на диаграмме.
Показатели качества для модели вариантов использования.
1. Все ли функциональные требования описываются вариантами использования?
2. Не содержит ли модель вариантов использования ненужное поведение, которое отсутствует в требованиях?
3. Действительно ли в модели необходимы все выявленные связи включения, расширения и обобщения?
4. Правильно ли произведено деление модели на пакеты вариантов использования?
5. Стала ли модель в результате деление на пакеты проще и удобнее для восприятия и сопровождения?
6. Можно ли на основе модели вариантов использования составить четкое представление о функционировании системы в контексте ее пользователей?
Выполнение работы
Прежде чем приступить к работе с редактором UML необходимо составить описание функционирования системы.
1. Запустите программу StarUML.
2. Создайте новый проект: File -> New Project.
3. В открывшемся окне задайте имя проекта и выберите Blank Project
4. Дождитесь создания проекта.
5. Для создания в проекте диаграммы вариантов использования зайдите в меню Diagrams и выберите Use case diagrams. В менеджере диаграмм нажмите Add и дайте имя новой диаграмме. Нажмите «Ок» и закройте менеджер диаграмм.
6. В рабочем поле, слева, появятся все элементы диаграммы вариантов использования. Можете приступить к выполнению задания.
Рис. 4.1. Интерфейс инструментария UML (на примере StarUML.
Задание на выполнение
Сценарий №1 выполнения варианта использования "Снятие наличных по кредитной карточке"
| Система |
| Вариант использования: Снятие наличных по кредитной карточке Актеры: Клиент Банкомата, Злоумышленник, Банк, Служба безопасности банка Цель: Получение требуемой суммы наличными, только авторизованным клиентом банка. Краткое описание: Клиент использует свою карточку для снятия наличных. Клиент запрашивает требуемую сумму. Банкомат обеспечивает доступ к счету клиента, если он проходит авторизацию. Банкомат выдает клиенту наличные. Ссылки на другие варианты использования. Включает в себя ВИ: o Проверка ПИН-кода кредитной карточки. o Количество проверок ПИН-кода ограничено. Типичный ход событий 1. Клиент вставляет кредитную карточку в устройство чтения банкомата. 2. Банкомат передает информацию о кредитной карточке в Банк. 3. Банк проверяет информацию о кредитной карточке. Исключение №1: Кредитная карточка недействительна (утрачена). Исключение №2: Кредитная карточка просрочена. 4. Банкомат предлагает ввести ПИН-код. 5. Клиент вводит PIN-код. 6. Банкомат проверяет ПИН-код. Исключение №3: Введенный ПИН-код неверный. Исключение №4: Клиент ввел неверный ПИН-код 3 раза. 7. Банкомат отображает опции меню. 8. Клиент выбирает снятие наличных со своего счета. 9. Банкомат предлагает ввести требуемую сумму. 10. Клиент вводит требуемую сумму. 11. Банкомат делает соответствующий запрос в Банк. 12. Банк проверяет введенную сумму. Исключение №5: Требуемая сумма превышает сумму на счете клиента или сумму разовой выплаты. 13. Банк изменяет состояние счета клиента. Исключение №6: Клиент выбрал печать чека. 14. Банкомат предлагает клиенту забрать его кредитную карточку. 15. Клиент получает свою кредитную карточку. 16. Банкомат выдает наличные и предлагает забрать их клиенту. 17. Клиент получает наличные. 18. Банкомат отображает сообщение о готовности к дальнейшей работе. Исключения. Исключение №1. Кредитная карточка недействительна (утрачена) 4. Банкомат блокирует кредитную карточку информация поступает в службу безопасности. 18. Банкомат отображает сообщение о готовности к дальнейшей работе Исключение №2. Кредитная карточка просрочена 4. Банкомат предлагает клиенту забрать его кредитную карточку 15. Клиент получает свою кредитную карточку 18. Банкомат отображает сообщение о готовности к дальнейшей работе Исключение №3. Введенный ПИН-код неверный 4. Банкомат предлагает ввести ПИН-код 5. Клиент вводит ПИН-код Исключение №4: Клиент вводит неверный ПИН-код 3 раза 4. Банкомат блокирует кредитную карточку, информация поступает в службу безопасности. 18. Банкомат отображает сообщение о готовности к дальнейшей работе Исключение №5. Требуемая сумма превышает сумму на счете клиента 9. Банкомат предлагает ввести новую сумму 10. Клиент вводит новую требуемую сумму Исключение №6. Клиент выбрал печать чека 16.1. Банкомат предлагает клиенту забрать чек Примечание. Клиент может отказаться от выполнения транзакции "Снятие наличных по кредитной карточке" при введении ПИН-кода, при выборе типа транзакции и при вводе суммы. |
Содержание отчета
В отчете необходимо привести:
- формулировку цели и задания на выполнение работы;
- краткое описание используемых элементов UML;
- сценарий работы описываемой системы;
- описание процесса составления диаграммы;
- диаграмму вариантов использования.
Лабораторная работа №3