Учебное пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ москва 2002 2 аннотация
 Скачать 0.53 Mb.
|
|
Раздел Описание Имя Инициировать решение (). Обязанно- сти Выполнить задание и вывести пользователю полученные результаты Тип Системная Ссылки Вариант использования Выполнить задание Примеча- ния Предусмотреть возможность прерывания про- цесса решения пользователем Исключе- ния 1. Если в задании указаны не все исходные данные, то вывести сообщение об ошибке 2. Если при указанных исходных данных реше- ние задачи указанным методом не возможно, то вывести сообщение об ошибке Вывод – Предусло- вия Предполагает наличие всех исходных данных задания Постусло- вие Получен результат Диаграммы деятельностей. В зависимости от степени детализации диаграммы деятельностей так же, как диаграммы классов, могут использоваться на разных этапах разработки. На этапе анализа требований и уточнения спецификаций диаграммы дея- тельностей позволяют конкретизировать основные функции разрабатываемого ПО. Под деятельностью в данном случае понимают задачу (операцию), которую необ- ходимо выполнить вручную или с помощью средств автоматизации. Каждому варианту использования соответствует своя последовательность задач. В теоретическом плане диаграммы деятельности – обобщенное представление алгоритма, реализующего ана- 47 лизируемый вариант использования. На диаграмме деятельность обозначается прямо- угольником с закругленными углами (рис. 5.11, а). Диаграммы деятельности позволяют описывать альтернативные и параллельные процессы. Для обозначения альтернативных процессов используют ромб (рис. 5.11, б), условие указывают рядом, а альтернативы «да», «нет» – рядом с соответствующими выходами. С помощью этого же блока можно построить циклический процесс. Множе- ственность активации деятельности обозначают символом «*», помещенным рядом со стрелкой активации деятельности, и при необходимости уточняют надписью вида «для каждой строки». Для обозначения параллельных процессов используют линейки синхронизации (рис. 5.11, в), причем условие синхронизации можно уточнить, указав его на диаграм- ме. На рис. 5.12 показано, что «Деятельность 1» и «Деятельность 2» могут выполняться параллельно. На этапе определения спецификаций имеет смысл уточнять только те варианты ис- пользования, краткое описание которых недостаточно для понимания сущности ре- шаемых проблем. Диаграммы деятельностей таким образом можно использовать вме- сто описания вариантов использования или в дополнение к ним. Пример 5.4. Построить диаграмму деятельности, уточняющую вариант использо- вания Выполнение задания системы решения комбинаторно-оптимизационных задач. Разбиваем процесс на операции, учитывая описание предметной области в виде контекстной диаграммы классов, и показываем их на диаграмме деятельности (рис. 5.13). 6. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ Разработка структуры программного обеспечения при объектном подходе Основная задача логического проектирования при объектном подходе – разработка классов для реализации объектов, полученных при объектной декомпозиции, что пред- полагает полное описание полей и методов каждого класса. Физическое проектирова- ние при объектном подходе включает проектирование объединения классов и других программных ресурсов в программные компоненты и размещения этих компонентов на конкретных вычислительных установках. 48 Большинство классов можно отнести к определенному типу, который примени- тельно к классам называют стереотипом, например: классы-сущности (классы пред- метной области), граничные (интерфейсные) классы, управляющие классы, исключения и т.д. Классы-сущности используют представления сущностей реального мира или внут- ренних элементов системы, например, структур данных. Обычно они не зависят от ок- ружения и, соответственно, могут использоваться в различных приложениях. Для вы- явления классов-сущностей, как правило, изучают описания вариантов использования, концептуальную модель и диаграммы деятельностей. Полученный таким образом спи- сок классов-кандидатов фильтруют, удаляя слова, не относящиеся к предметной облас- ти, языковые выражения и т.п. Среди оставшихся отбирают классы-кандидаты, объекты которых обладают как состоянием, так и поведением. Граничные классы обеспечивают взаимодействие между действующими лицами и внутренними элементами системы. К этому типу относятся как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с техниче- скими средствами или программными системами. Для обнаружения граничных клас- сов изучают пары «действующее лицо – вариант использования». Управляющие классы служат для моделирования последовательного поведения, за- ложенного в один или несколько вариантов использования. Если количество классов-кандидатов и других ресурсов велико, то их целесообраз- но разбить на группы – пакеты. Пакетом при объектном подходе называют совокупность описаний классов и дру- гих программных ресурсов, в том числе пакетов. Объединение в пакеты используют только для удобства создания больших проектов, количество классов в которых велико. При этом в один пакет обычно собирают классы и другие ресурсы единого назначения. Диаграмма пакетов показывает, из каких частей состоит проектируемая программ- ная система, и как эти части зависят друг от друга. Связь между пакетами фиксируют, если изменения в одном пакете могут повлечь за собой изменения в другом. Она определяется зависимостью классов и других ресур- сов, объединенных в пакет. Возможны различные виды зависимости классов, напри- мер: • объекты одного класса посылают сообщения объектам другого класса; • объекты одного класса обращаются к компонентам объектов другого; 49 • объекты одного класса используют объекты другого в списке параметров мето- дов и т.п. На рис. 6.1 приведены обозначения UML, которые допустимо использовать на диа- граммах пакетов. Кроме указанных обозначений на диаграммах пакетов допустимо по- казывать обобщения (рис. 6.2), что подразумевает наличие единого интерфейса не- скольких пакетов. В этом случае фиксируется связь от подтипа к супертипу. Пример 6.1. Разработать структуру системы решения комбинаторно- оптимизационных задач. Анализ концептуальной модели и вариантов использования позволяют выделить следующие группы классов или пакеты: * пользовательский интерфейс – классы, реализующие объекты интерфейса с поль- зователем; * библиотека интерфейсных компонентов – классы, реализующие интерфейсные компоненты: окна, кнопки, метки и т.п.; * объекты управления – классы, реализующие сценарии вариантов использования; * объекты задачи – классы, реализующие объекты предметной области системы; * интерфейс с базой данных – классы, реализующие интерфейс с базой данных; * база данных; * базовые структуры данных – классы, реализующие внутренние структуры дан- ных, такие как деревья, n-связные списки и т.п.; * обработка ошибок – классы исключений, реализующие обработку нештатных си- туаций. Последние два пакета объявим глобальными, так их элементы могут использовать- ся классами всех пакетов. Предположим зависимости классов и изобразим диаграмму (рис. 6.3). Определение отношений между объектами После определения основных пакетов разрабатываемого ПО переходят к детально- му проектированию классов, входящих в каждый пакет. Классы-кандидаты, которые предположительно должны войти в конкретный пакет, показывают на диаграмме клас- сов этапа проектирования и уточняют отношения между объектами указанных клас- сов.. Пример 6.2. Определить классы-кандидаты пакета Объекты задачи. 50 Используя рекомендации, данные в § 6.1, выполним анализ концептуальной моде- ли предметной области (рис. 5.8), описания основного варианта использования Реше- ние задачи (см. § 5.2) и его диаграммы деятельностей (рис. 5.13). Список классов-кандидатов, полученный на основе данного анализа, выглядит сле- дующим образом: • класс Задание – объекты данного класса должны создаваться каждый раз, когда пользователь инициирует новое задание; • семейство классов с базовым классом Алгоритм – объекты данного класса должны создаваться, когда определен алгоритм решения задачи; • класс Данные – объекты данного класса должны создаваться при определении (вводе или выборе из базы) данных; • класс Результаты – объекты данного класса должны создаваться при решении конкретной задачи конкретным алгоритмом с использованием конкретных данных. Исходный вариант диаграммы классов пакета Объекты задачи показан на рис. 6.4. Основой для проектирования классов является уточнение взаимодействия объектов этих классов в процессе реализации вариантов использования. При этом применяют диаграммы последовательности действий и диаграммы кооперации. Если же необхо- димо описать взаимодействие объектов при обработке конкретного сообщения, удобны именно диаграммы последовательностей. Диаграммы последовательностей этапа проектирования. Диаграммы последо- вательностей этапа проектирования отображают взаимодействие объектов, упорядо- ченное по времени. В отличие от диаграмм последовательностей этапа анализа на ней показывают и внутренние объекты, а также последовательность сообщений, которыми обмениваются объекты в процессе реализации фрагмента варианта использования, обычно называемого сценарием. Объекты изображают в виде прямоугольников, внутри которых указана информа- ция, идентифицирующая объект: имя, имя объекта и имя класса или только имя класса (рис. 6.5). Каждое сообщение представляют в виде линии со стрелкой, соединяющей линии жизни двух объектов. Эти линии помещают на диаграмму в порядке генерации сооб- щений (сверху вниз и слева направо). Сообщению приписывают имя, но можно ука- зать аргументы и управляющую информацию, например, условие формирования или 51 маркер итерации (*). Возврат при передаче синхронных сообщений подразумеваются по умолчанию. Если объект создается сообщением, то его рисуют справа от стрелки сообщения так, чтобы стрелка сообщения входила в него слева. Диаграммы последовательностей также позволяют изображать параллельные про- цессы. Асинхронные сообщения, которые не блокируют работу вызывающего объекта, показывают половинкой стрелки (рис. 6.6, а). Такие сообщения могут выполнять одну из трех функций: * создавать новую ветвь процесса; * создавать новый объект (рис. 6.6, б); * устанавливать связь с уже выполняющейся ветвью процесса. На линии жизни для параллельных процессов дополнительно показывают актива- ции, которые обозначаются прямоугольником, наложенным поверх линии жизни (рис. 6.6, в). Уничтожение объекта показывают большим знаком «Х» (рис. 6.6, г). При необходимости линию жизни можно прервать, чтобы не уточнять обработку, не связанную с анализируемыми объектами (рис. 6.6, д). Пример 6.3. Разработать диаграмму последовательностей для сценария Решение задачи (фрагмент варианта использования Выполнение задания от момента инициали- зации пользователем процесса решения до его завершения). Анализ описания варианта использования показывает, что необходимо рассмотреть три варианта последовательности действий: нормальный процесс, прерывание процесса пользователем и возникновение исключения при выполнении алгоритма. Нормальный процесс предполагает, что при выдаче команды Создать создается объект Решение, управляющий данным сценарием. Следующее сообщение Начать ак- тивизирует этот объект. Объект Решение запрашивает у объекта класса Задание тип объекта Алгоритм, создает объект требуемого класса и активизирует его, сохраняя спо- собность получать и обрабатывать сообщения (параллельный процесс). Объект класса Алгоритм, реализующий метод, запрашивает у объекта класса Зада- ние данные и начинает обработку, используя вспомогательные объекты. Нормально завершив обработку, объект класса Алгоритм, реализующий метод, передает объекту класса Задание результаты и возвращает объекту Решение признак нормального завер- шения. Объект Решение уничтожает объект класса Алгоритм, реализующий метод, и 52 возвращает вызвавшему его объекту признак нормального завершения решения (рис. 6.7, а). В случае прерывания процесса объект Решение прерывает процесс решения, унич- тожает объект Алгоритм и возвращает признак прерванного выполнения (рис. 6.7, б). В последнем случае при выполнении обработки возникает аварийная ситуация, ре- зультатом которой является генерация исключения. Обрабатывая исключение, объект класса Решение, выдает соответствующее сообщение пользователю, уничтожает объект класса Алгоритм, реализующий метод, и возвращает признак завершения с ошибкой (рис. 6.8). Диаграммы кооперации. Диаграммы кооперации – это альтернативный способ представления взаимодействия объектов в процессе реализации сценария. В отличие от диаграмм последовательностей действий диаграммы кооперации показывают потоки данных между объектами классов, что позволяет уточнить связи между объектами. Пример 6.4. Разработать диаграммы кооперации для сценария Процесс решения. Изобразим на одной диаграмме все три случая, которые возможны при реализации сце- нария (рис. 6.9), нумеруя сообщения в порядке их возможной генерации. Такое представление позволяет описать потоки данных, передаваемых между объ- ектами классов Решение, Задание и Алгоритм, реализующий метод, для сценария Про- цесс решения. Уточнение отношений классов Процесс проектирования классов начинают с уточнения отношений между ними. На этапе проектирования помимо ассоциации и обобщения различают еще два типа от- ношения между классами: агрегацию и композицию. К сожалению, до настоящего времени не существует единой устоявшейся терми- нологии объектно-ориентированного проектирования. В табл. 6.1 приведены соответ- ствия между основными терминами, используемыми наиболее известными авторами в этой области. Таблица 6.1 UML Класс Ассоциация Обобщение Агрегация Буч Класс Использование Наследование Включение Коад Класс, Связь экземпляров Обобщение- Часть-целое 53 объект специализа- ция Якобсон Объект Ассоциация родст- ва Наследование Состоит из Оделл Тип объекта Связь Подтип Композиция Рамбо Класс Ассоциация Обобщение Агрегация Шле- ер/Меллор Объект Связь Подтип Не опреде- лена Агрегацией называют ассоциацию между целым и его частью или частями. Агрега- цию вместо ассоциации указывают, если отношение «целое-часть» в конкретном слу- чае существенно. Например, если колесо нас интересует только как часть автомобиля, то между соответствующими классами целесообразно указать отношении агрегации, а если колесо – товар, так же как и автомобиль, то связь целое часть не существенна. Композиция – более сильная разновидность агрегации, которая подразумевает, что объект-часть может принадлежать только единственному целому. Объект-часть при этом создается и уничтожается только вместе со своим целым. Уточненные отношения между классами фиксируют на диаграмме классов. Для этого используют специальные уловные обозначения (рис. 6.10). Поскольку отношение ассоциации и его подвиды: агрегация и композиция означа- ют наличие обмена сообщениями между объектами классов, целесообразно уточнить направление передачи сообщений. Навигацию (направление ассоциации) показывают стрелкой на конце линии ассоциации. Если стрелки указаны с обеих сторон, то это оз- начает двунаправленную ассоциацию. Специальное обозначение на диаграмме классов этапа проектирования используют для указания абстрактных классов и методов: на диаграмме классов их имена выделяют курсивом, либо перед именем класса указывают стереотип «abstract». UML также включает специальную нотацию для обозначения параметризованных классов или шаблонов (рис. 6.11). Получение из класса-шаблона класса с конкретными типами элементов называют связыванием. Связывание можно обозначить двумя способами, явно указав тип- параметр (рис. 6.12, а) и используя условное обозначение уточнения (рис. 6.12, б). 54 Диаграммы классов позволяют также отобразить ограничения, которые невозможно показать, используя только понятия, рассмотренные выше (ассоциации, обобщения, ат- рибуты, операции). Например, показать, что средний балл студентов должен опреде- ляться по соответствующей формуле. Подобную информацию на диаграмме классов можно представить в виде записи на естественном языке или в виде математической формулы, поместив их в фигурные скобки. Особое место в процессе проектирования классов занимает проектирование интер- фейсов. Интерфейсы. Интерфейсом в UML называют класс, содержащий т о л ь к о объ- явление операций. Отдельное описаний интерфейсов улучшает технологические каче- ства ПО. Интерфейсы широко применяют при разработке сетевого ПО, которое должно функционировать в гетерогенных средах, а также для организации взаимодействия с базами данных и т.п., так как механизм полиморфного наследования позволяет созда- вать различные реализации одного и того же интерфейса. С точки зрения теории объектно-ориентированного программирования интерфейс представляет собой особый вид абстрактного класса, отличающийся тем, что он не со- держит методов, реализующих указанные операции, и объявления полей. Другими сло- вами абстрактные классы позволяют определить реализацию некоторых методов, а ин- терфейсы требуют отложить определение всех методов. На диаграмме классов интерфейс можно показать двумя способами: с помощью специального условного обозначения (рис. 6.13, а) или, объявив для класса стереотип «interface» (рис. 6.13, б). Реализацию интерфейса также можно показать двумя способами: сокращенно (рис. 6.14, а) или, используя отношение реализации (рис. 6.14, б). Для остальных классов, ассоциированных с интерфейсом, следует уточнить ассо- циацию, показав отношение зависимости. Это отношение в данном случае означает, что класс использует указанный интерфейс (рис. 6.15). Одновременно с уточнением отношений классов в пакете следует продумать и от- ношения классов, включенных в различные пакеты между собой. |