Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методы и средства проектирования информационных систем и технологий. Основы UML. Учебное пособие.pdf
Скачиваний:
0
Добавлен:
07.09.2026
Размер:
2 Мб
Скачать
☆
Что следует запомнить
• 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
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]