Тема 1.4. Основи об'єктно-орієнтованого проектування мовою uml

Мета – опанувати прийоми використання діаграм UML при аналізі предметного середовища і алгоритмізації задач.

Завдання – показати графічні засоби мови UML, послідовність і прийоми їх застосування, навчити користуванню UML як інструменту проектування.

Очікувані результати (компетенції):

Здійснювати аналіз і порівневий опис предметного середовища засобами UML.

Розробляти систему діаграм UML і корегувати її в процесі аналізу і проектування.

Раціонально використовувати побудовані діаграми при розробці програм засобами ООП.

Лекция составлена по материалам книги Фаулер М., Скотт К. UML. Основы. - СПб: Символ-Плюс, 2002. - 192 с.

Частина перша

1. Основи мови uml, її призначення і засоби.

Основной причиной использования языка UML является общение разработчиков между собой.

Что такое uml

UML (Унифицированный язык моделирования Unified Modeling Lan­guage) - предназначен для графического представления различных процессов. В том числе и процессов выполнения программ.

UML является преемником методов объектно-ориентированного анализа и проектирования (OOA&D), которые появились в конце 80-х и начале 90-х годов.

Он непосредственно унифицирует методы Буча, Рамбо (ОМТ) и Джекобсона, однако обладает большими возможностями.

Язык UML прошел процесс стандартизации в рамках консорциума OMG (Object Management Group) и в настоящее время является стандартом OMG.

ВНИМАНИЕ! В методы проектирования, кроме языка моделирования, входят еще и Процессы. Язык - это нотация (главным об­разом, графическая), которую используют методы для описания про­ектов.

Процесс - это рекомендация относительно этапов, которые не­обходимо выполнить при разработке проекта.

Поэтому у разных методов проектирования программ язык может быть один - UML, а процессы - разные.

2. Графічна нотація і метамоделі.

Язык UML определяет нотацию и мета-модель.

Нотация - совокупность графических элементов, которые используются в моделях; она является синтаксисом данного языка моделирования.

Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и кратность.

Для достижения некоторой формализации объектно-ориентированных методов, они основываются на определении некоторой метамодели определяющей их нотацию. В UML это диаграммы (как правило, диаграммы классов).

Метамодель задает правила составления моделей процессов, т.е. определяет, как описывать процесс выполнения программы с помощью диаграмм UML

Вот графические элементы и их композиции, входящие в метамодель:

К ласс

:

Обобщение

Объект

Примечание

Ассоциация

Кратности

Диаграмма классов: Интерфейсы

Диаграмма деятельности

3. Основи процесу розробки засобами uml.

Язык UML позволяет сообщать о своих идеях более наглядно, нежели другие способы. Естественный язык слиш­ком неточен и приводит к путанице, когда он сталкивается с более сложными понятиями. Программный код точен, но слишком насы­щен деталями реализации.

Схема процесса разработки программ

Фаза построения состоит из многих итераций, на каждой из которых выполняются по­строение, тестирование и интеграция высококачественного программ­ного обеспечения, удовлетворяющего некоторому подмножеству требований к проекту.

В началь­ной фазе разрабатывается экономическое обоснование проекта и опре­деляются его границы. Определяет­ся, какова его приблизительная стоимость и размер ожидаемого до­хода.

Начальная фаза должна занимать несколько дней работы, в течение которых следует решить, стоит ли проводить в фазе исследования бо­лее глубокий анализ, который может затянуться на несколько месяцев.

В фазе исследование уточняются более детально требования, вы­полняются высокоуровневый анализ и проектирование для построения базовой архитектуры и создается план для фазы построения.

В фазе исследование желательно попытаться лучше понять суть проблемы:

Что вы на самом деле собираетесь создать?

Как вы собираетесь это сделать?

При формировании требований к программе следует также понять, что может привести к провалу проекта? Например, существуют риски, связанные с требованиями. Каковы требования к системе? Большая опасность заключается в том, что вы построите совсем не ту систему, которая будет выполнять вовсе не то, что нужно пользо­вателям.

Технологические риски. С какими технологическими рисками вам придется столкнуться? Действительно ли позволяет выбранная ва­ми технология реализовать ваш проект? Каким образом следует ин­тегрировать различные части проекта?

Фактически, исследование состоит в построении модели предметной области задачи.

Для построения модели предметной области особенно полезны следую­щие два метода языка UML.

Основным методом является диаграмма классов, рассматриваемая с концептуальной точки зрения. Эти диаграммы могут быть использованы для представления понятий, которые применяют бизнес-аналитики при исследовании соответствующей бизнес-системы, и для представления особенностей объединения этих понятий в единой модели. Во многих случаях именно диаграммы классов опреде­ляют некоторый терминологический словарь для описания соответст­вующей предметной области.

Если предметная область также обладает явно выраженным элемен­том потока работ, строят диаграммы деятельности. Главной особенностью диаграмм деятельности является их способность изображать параллельные про­цессы, которые очень важны для исключения ненужных последова­тельностей в бизнес-процессах.

Некоторые разработчики предпочитают пользоваться диаграммами взаимодействия для исследования взаимодействия раз­личных ролей в бизнес-системе. Рассматривая совместно исполните­лей и деятельности, они приходят к лучшему пониманию соответству­ющего бизнес-процесса..

В модель включаются наиболее важные детали проекта.

Большинство деталей выявится в ходе итеративной разработки.

Как только определены варианты использования, они позволят управ­лять дальнейшим моделированием предметной области. При появле­нии очередных вариантов использования команда разработчиков должна оценить, содержат ли они нечто такое, что способно оказать сильное влияние на модель предметной области. Если содержат, то их нужно исследовать и далее, а если нет, то такие варианты использова­ния следует отложить на некоторое время в сторону.

Команда, занятая построением модели предметной области, должна представлять собой небольшую группу (от двух до четырех человек), в состав которой входят разработчики и эксперты предметной области.

Для понимания требований к системе следует построить прототип (упрощенную программу) для любых составных частей вариантов использования.

Диаграммы классов разрабатывают для того, чтобы быстро получить представление о том, какие виды абстракций существуют в системе и где расположены наименее проработанные части модели, требующие последующего уточнения.

Нет никакой необходимости показывать каждое свойство каждого класса; вместо этого следует указать лишь наиболее важные детали. С точки зрения обмена информацией крат­кий документ намного лучше большого по объему, а понимание того, что следует исключить из описания, является искусством.

Диаграммы классов, используемые для иллюстрации моделей классов, одновременно как хороши, так и плохи для изучения объектов. Модели классов столь же удобны, как и модели данных; многие принципы построения хорошей модели данных также пригодны для построения хорошей модели классов.

Основная проблема в использовании диаграмм классов состоит в том, что можно легко разработать модель классов, которая ориентирована на данные, а не на ответственность.

Диаграммы взаимодействия показывают, как классы кооперируются между собой. Эти диаграммы иллюстрируют основные аспек­ты поведения системы.

Диаграммы взаимодействия оказываются очень полезными, поскольку позволяют наглядно представить структуру сообщения и тем самым выявить излишне централизованные проекты, в которых один объект выполняет всю работу.

Диаграммы вариантов использования описывают роли «участников» процесса при решении отдельных задач.

Вариант использования представляет собой некий моментальный снимок одного из аспектов вашей системы.

Совокупность всех вариантов использования образует внешнее представление вашей системы, которому предстоит пройти долгий путь, объясняя, что эта система будет делать.

Хороший набор вариантов применения - это главное для понимания потребностей ваших пользователей.