Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы и средства проектирования информационных систем и технологий. Основы UML. Учебное пособие.pdf

Что следует запомнить
• UML поддерживает весь жизненный цикл разработки,
от концептуализации и анализа, архитектуры и дизайна до строитель-
ства и документации.
• UML используется для систем моделирования, а не только
для программного обеспечения.
• UML используется для малых и больших систем.
• UML предназначен для понимания людьми и программными
инструментами.
• UML объединяет как объектно-ориентированные, так и не-
объектно-ориентированные подходы к проектированию систем.
• UML можно использовать для традиционных, объектно-
ориентированных и смешанных систем.
Цели UML версии 1.3 расширились. Эти новые цели были неявно продолжены для остальных версий UML:
1. Предоставить пользователям готовый, выразительный язык визуально-
го моделирования для разработки и обмена полезными моделями.
2. Предоставить механизмы расширяемости и специализации для расши-
рения основных понятий.
3. Предоставить поддержку спецификаций, которые не зависят от кон-
кретных языков программирования и процессов разработки.
4. Обеспечить формальную основу для понимания языка моделирования.
5. Поощрять рост рынка объектных инструментов.
6. Поддерживать концепции разработки более высокого уровня, такие как
компоненты, совместная работа, структуры и шаблоны.
7. Интегрировать лучшие практики.
11

В поддержку этих дополнительных целей UML расширился и включает
следующие функции:
− поддерживает метод обмена с использованием XMI (XML METADATA
INTERCHANGE), который позволяет инструментам UML обмениваться моделями;
− включает в себя профиль и стереотипные возможности, которые позво-
ляют проекту или команде адаптировать UML для своих собственных нужд.
Языки, полученные из UML, предназначены для специализированных рынков,
таких как язык моделирования системного проектирования (SysML) для моделирования системного проектирования и SPEM для моделирования процессов
разработки программного обеспечения;
− не зависит от языка программирования;
− спецификация UML использует формальную метамодель для захвата
абстрактного синтаксиса;
− существует множество инструментов UML, конкурирующих по раз-
личным ценовым показателям и возможностям. Инструменты поддерживают
дополнительные языки, такие как португальский, испанский, русский и корейский;
− поддерживает концепции организации более высокого уровня, включая
совместную работу, составные структуры, иерархические конечные автоматы и
повторное использование, а также компоненты.
К 2000 году стало ясно, что необходимы некоторые существенные изменения, в том числе переформулировка, основанная на сетях Петри для диаграмм
действий, а не на конечных автоматах, улучшенное описание поведения в целом и более формальный подход к определению абстрактного синтаксиса.
На этом этапе ADTF проголосовал за выпуск RFP для UML 2.08.
UML 2.0 использовал два документа для описания стандарта: документ
UML INFRASTRUCTURE и документ UML SUPERSTRUCTURE. Версии UML
2.0 пришли как UML 2.0 (2005), 2.1.1 (2007), 2.1.2 (2007), 2.2 (2009), 2.3 (2010),
2.4 (2011), 2.4.1 (2011).
12

Что следует запомнить
• Инструменты UML используют XMI для обмена моделями.
• Проект или команда могут адаптировать UML для своих соб-
ственных целей, используя профили и стереотипы.
• UML является основой для нескольких производных языков в
специализированных областях, технологиях совместного использова-
ния и инфраструктуре.
• поскольку UML не зависит от выбора языка программирова-
ния, возможно использовать UML с различными языками программи-
рования.
• UML имеет формальную метамодель, которая определяет аб-
страктный синтаксис (грамматику).
• Существует обширный международный выбор инструментов,
поддерживающих UML.
И снова OMG представила версию 2.4.1 ISO JT1-SC7, который утвердил её
как ISO / IEC 190504-1 / 2: 2012.
Версия 2.5 официально является незначительным пересмотром спецификации UML 2.4.1. Этот процесс упрощения объединил инфраструктуру и надстройку в один документ, который был значительно проще и лучше организован.
UML был разработан для моделирования программно-интенсивных систем
и областей, в которых такие системы должны работать. Тем не менее, имеется
возможность смоделировать и другие системы, имеющие чёткие границы (и их
свойства, отношения и поведение). Поскольку UML нацелен на системы с интенсивным использованием программного обеспечения, он предполагает, что
время, сообщения и поведение (в основном) дискретны.
13

Хотя аналоговые системы, биологические системы и системы окружающей
среды могут иметь структуры, которые можно моделировать, UML не должен
быть первым выбором для их моделирования.
Как и при любом моделировании, необходимо учитывать целевую аудиторию. UML был разработан таким образом, чтобы типичные заинтересованные
стороны, которые могут иметь различные навыки и интересы, понимали, какие
диаграммы они обычно показывают. Если диаграмму, ориентированную на заинтересованные стороны, перегрузить всеми возможными подробностями, которые она может содержать, впоследствии почти никто её не поймет. Поэтому
модель и диаграммы следует сделать настолько простыми, насколько это возможно, всегда помня об аудитории, сохраняя при этом полную информационность для областей применения.
UML будет используемым языком, если необходимо создать программное
обеспечение для IT-систем. Если моделируется бизнес-процесс с помощью правил, существуют специальные языки, подобные UML, которые имеют тенденцию к большей интерпретации бизнес-типами, например, нотация моделирования бизнес-процессов.
Как показано в табл. 1.1, ключевые цели моделирования включают анализ,
проектирование, реализацию и коммуникацию.
1.1. Общие цели моделирования UML
Key Purpose Основные типы моделирования
Анализ Анализ предметной области
Анализ вариантов использования
Анализ требований
Проектирование Концептуализация
Архитектура
Детальное пректирование
14

Key Purpose Основные типы моделирования
Реализация Реализация вручную
Автоматическая генерация кода
Моделирование / выполнение
Обратный инжиниринг
Прямое и обратное моделирование
Отладка
Общение с людьми
с другими инструментами
Продолжение табл. 1.1
Каждая из этих целей имеет различные типы моделирования, поддерживающие эту цель. В типичном проекте понадобятся только некоторые из этих
типов моделирования, и они могут иметь разные формальные определения. Тем
не менее, необходимо знать общую информацию о типах и целях моделирования.
Анализ охватывает моделирование объектов в реальном мире, чтобы
улучшить понимание того, с чего вы начинаете. Это также включает моделирование того, что требует проект, но не того, как это должно быть выполнено. Как
должны быть реализованы процессы – задача проектирования. Отделение проектирования от анализа позволяет предоставить новый дизайн для той же модели анализа, если по какой-то причине оригинальный проект не сработал или если имеется более одной конкурентоспособной команды разработчиков.
Анализ предметной области – моделирование предметной области, объектов в реальном мире, чтобы понять, как работает текущая или унаследованная
система, – требуется, чтобы получить основу для включения в конечном итоге в
замещающую систему. Текущая система может быть полностью механической
или ручной. Моделирование анализа предметной области обычно выполняется
так, чтобы заинтересованные стороны и пользователи могли проверить модель
15

и определить её достоверность в реальной системе. Таким образом, используемая терминология соответствует терминологии унаследованной системы, чтобы пользователи и заинтересованные стороны могли понять модель. Поскольку
эти модели рассматривают объекты реального мира, а не программные конструкции, они будут концентрироваться на диаграммах классов, состояний и,
возможно, последовательностей, обращая внимание на определения используемых терминов.
Анализ вариантов использования концентрируется на целях, для которых
существующие пользователи или будущие пользователи планируют использовать систему. Такое моделирование использует диаграммы вариантов использования, хотя другие диаграммы также могут использоваться в качестве дополнений. Анализ варианта использования создаёт неформальные требования для
планируемой системы, которые могут быть преобразованы в формальные требования, если проект требует такой формальности.
Анализ вариантов использования – это мост между пользователями (так
называемыми актёрами) и разработчиками моделей для определения потребностей, которые должна удовлетворить система. Следовательно, анализ варианта
использования также должен использовать терминологию пользователей, чтобы они могли определить недостающие потребности.
Анализ требований начинается с внешних заданных требований или вместо требований с формулировки проблемы. Изучив входной текст, можно идентифицировать существительные и глаголы, а также создать отображающие объекты и модели поведения в создаваемой модели. Такой подход, основанный на
подчёркивании имён, звучит упрощённо; на практике это требует значительных
знаний. Тем не менее, это может быть хорошим способом начать моделирование, если собраны входные данные высокого качества. В этом подходе модели
должны использовать терминологию требований, потому что заинтересованные
стороны, как правило, являются авторами документа требований. Этот подход
имеет тенденцию концентрироваться на диаграммах классов, состояний и диаграмм действий.
16

Что следует запомнить
• Аналитическое моделирование фиксирует текущую ситуацию
и что нужно сделать, без принятия каких-либо проектных решений.
• Анализ предметной области фиксирует ситуацию таким обра-
зом, что как команда, так и заинтересованные стороны могут анализи-
ровать и критиковать её.
• Анализ варианта использования фиксирует функциональность
и потребности, которые пользователи новой системы хотят, чтобы
система делала. Это также делается таким образом, чтобы как коман-
да, так и заинтересованные пользователи могли просматривать и кри-
тиковать ситуацию.
Проектирование включает моделирование того, что выбрано в области используемых решений и подходов, которые приняты, основываясь на понимании
продуктов анализа. Принимая продукты анализа в качестве входных данных,
проектирование охватывает моделирование дополнительных объектов, которые
выбраны в качестве части решения, используемых подходов, повторяемых моделей принятых новых решений, исходя из удовлетворения потребностей пользователей и системных требований.
Концептуализация охватывает высокоуровневые подходы к проектированию того, как система будет работать, включая основные системы и подсистемы, которые необходимо будет создать. Часто также рассматриваются основные принципы архитектуры. Поскольку усилия по концептуализации раскрывают базовые подходы к решению, концептуализация часто используется для
получения более точной оценки стоимости и графика проекта. В этом типе модели могут использоваться все диаграммы UML.
Архитектура охватывает моделирование, необходимое для передачи организации и связанных с ней принципов новой системы. Модели UML должны
17

будут охватывать структуру, поведение и другие виды системы. Специальные
представления являются общими, например, представление безопасности.
В UML не нужны диаграммы. Можно удалить все диаграммы, оставив базовую модель без изменений. Диаграммы – это просто взгляд на модель. Модель – это просто хранилище для всех элементов модели в системе, база данных, соответствующая грамматике UML. Диаграммы – это разные перспективы
одной и той же реальности, одной и той же базы данных. Элементы диаграммы,
т.е. то, что помещено на диаграмму, могут использоваться для создания элемента модели, если он ещё не существует, но в конечном итоге они являются
просто представлениями элемента модели. Несколько диаграмм могут содержать один и тот же элемент, отображать разные аспекты или детали одного и
того же элемента диаграммы. Это один и тот же элемент модели, который можно показать, изменив некоторые свойства базового элемента модели; все диаграммы изменятся, чтобы отразить новую реальность (см. рис. 2.3). Фактически, один и тот же элемент может появляться несколько раз на одной и той же
диаграмме или на нескольких диаграммах.
Возможность потенциально иметь на нескольких диаграммах более одного
элемента диаграммы для элемента модели, позволяет разработчикам создавать
несколько диаграмм с перекрывающимся контентом, предназначенных для разных целей и аудитории. Рекомендуется задокументировать цель и аудиторию
на диаграмме, что возможно в названии диаграммы. Эта информация поможет
напомнить о целях по мере того, как будет составляться диаграмма. Когда цели
диаграммы будут учтены, можно ожидать лучшего обзора и обратной связи,
лучшего согласования с планами и лучшего выполнения намерений.
Возможно, возникнет необходимость построить более одного уровня диаграмм для одной и той же аудитории, во-первых, диаграмму высокого уровня,
показывающую обзор, и другие диаграммы, показывающие больше деталей.
Одна из специальных целей построения диаграмм, которую часто забывают, – это общение с вашим будущим я. Часто люди находят, что если они смотрят на код, который был написан год назад, они забывают все детали того, как
18

он работает. Поэтому следует избегать сложных диаграмм и необходимо размещать комментарии на любой нестандартной диаграмме.
Другая специальная цель построения диаграмм – это обучение новых людей в проекте, будь то новые программисты, обслуживающий персонал или
пользователи.
Документация – это особый тип общения с людьми. Документация может
потребоваться для проекта, но даже если она не требуется, обычно рекомендуется документировать, особенно для проектов с долгим сроком службы. Компания может рассчитывать на смену инструментов и технологий в течение
10 лет. Хотя нотация UML может выдержать испытание временем, формат инструмента – нет. Хранение бумажной копии или PDF поможет этой информации быть доступной для будущего обслуживания и модификации.
Связь с другими инструментами: есть несколько причин использовать модели UML для взаимодействия с другими инструментами. UML предоставляет
стандартный механизм обмена моделями, который поддерживает экспорт и импорт моделей в другие инструменты. SIG в OMG, называемая Model Interchange
SIG, тестирует взаимодействие инструментов с помощью этого механизма, называемого XMI (обмен метаданными на основе XML).
Если инструмент поддерживает XMI, он может экспортироваться в другой
инструмент UML или в инструмент, который использует XMI для ввода модели, например, инструмент вычисления метрик модели. Существуют автономные инструменты, которые принимают XMI, оценивают содержимое пакета
UML и зависимости между пакетами и предлагают перемещать элементы из
одного пакета в другой для улучшения инкапсуляции.
Существуют принципы моделирования, которые необходимо соблюдать,
чтобы получить хорошие результаты.
Разработка программного обеспечения принципиально рискована. Обычно
около 40% проектов реализованы вовремя и в рамках бюджета, с необходимыми функциями и функциональностью. Если проект включает моделирование в
19

свои списки задач, это потому, что моделирование даёт снижение некоторого
предполагаемого риска.
Важным принципом моделирования является ограничение количества деталей до необходимого минимума. Карта города 1:1 не будет полезна, она будет
не только слишком сложной, но и нечитаемой. Лучше иметь несколько карт,
каждая из которых имеет свое собственное назначение, чем объединять их в
одну. Представление одной карты дорог, одной карты для коммунальных услуг,
одной карты для школьных округов, т.е. одной карты для одной цели. Всё гораздо проще, если содержание карты (или диаграммы) связано с одной целью.
Это заставляет нас обозначать цель на диаграмме, чтобы сфокусировать на этом
внимание. Возможно, понадобится обзорная карта, чтобы было можно связать
отдельные карты вместе, но одноцелевые карты и диаграммы намного проще и
полезнее, чем несфокусированные диаграммы.
Все карты, рассмотренные выше, должны ограничивать количество деталей на карте, чтобы сделать их наиболее читаемыми. Следовательно, необходимо абстрагировать основные функции, чтобы отобразить или смоделировать
их и скрыть ненужные или не относящиеся к делу детали, потому что ненужные детали могут привести к путанице. Должна быть возможность увидеть лес,
не теряясь в деревьях. Эта абстракция является очень мощной техникой, и она
имеет прямую поддержку UML, а также является распространённой объектноориентированной техникой.
С абстракцией связано скрытие информации. Можно определить, что
именно не показывать, определив, от чего не должны зависеть пользователи.
Если бы на нашей карте электрических сетей было указано название и назначение каждого провода в городе, то, как только был проведён какой-либо ремонт,
карта сразу бы устарела. Если вы не хотите, чтобы пользователи вашей диаграммы зависели от каждой показанной детали, не показывайте детали.
В качестве примера программного обеспечения можно рассмотреть сортировку некоторого списка объектов; рецензенты должны знать, что решается
именно эта задача. Тем не менее, может потребоваться скрыть или исключить
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
