Учебник Технология программирования. Технология программирования
 Скачать 7.85 Mb.
|
|
Пример 6.3. Построить концептуальную модель для системы решения комбинаторно- оптимизационных задач. Множество понятий-кандидатов для данной разработки включает следующие словосочетания: Задание, тип задачи, список типов задач, способ задания данных, ввод данных, выбор данных из базы, алгоритм решения задачи, список конкретных алгоритмов решения задачи, полнота описания задания, результаты, данные, база данных. Попробуем выделить основные понятия и связать их между собой. Цель основного варианта использования системы - выполнение задания. Полное описание задания включает: тип задачи, данные и указание на алгоритм. С ним же будут связаны и полученные результаты. Данные могут 180 Таблица 6.1 Категория понятий-кандидатов Примеры Физические или материальные объекты Спецификации, элементы дизайна или описания объекта - сохраняются в системе даже при отсутствии объектов Место Роль человека Контейнеры других объектов Содержимое контейнеров Другие компьютеры или внешние системы по отношению к разрабатываемой Абстрактные понятия Организации События Процессы и их части* Правила и политика Записи финансовой, трудовой, юридической и другой деятельности, руководства, книги Самолет - как целое Цвет, спецификация товара Аэропорт, город Продавец, покупатель, преподаватель Самолет - как совокупность частей, ката- лог - как совокупность описаний Часть, элемент Система бронирования билетов Летательный аппарат Фирма, предприятие, НИИ Встреча, покупка билета Покупка билета, оплата стоимости Правила аннулирования заказа билета Чек, книга учета, должностная инструк- ция * Представляется в виде класса, если не анализируются элементы процесса. сохраняться в базе и вводиться. Описание задания и все, что с ним связано, может сохраняться в базе. Определим возможные обобщения: 1) способ задания данных: ввод данных, выбор данных из базы; 2) алгоритм: алгоритм решения задачи: конкретный алгоритмы решения задачи. Переходим к построению концептуальной модели. Основной класс-понятие, исходя из описания, Задание. Связываем с ним классы-понятия Данные, Алгоритм и Результаты. В разрабатываемой системе планируется реализовать алгоритмы решения задач трех типов: поиск цикла минимальной длины, проходящего через все вершины; поиск кратчайшего пути и поиск минимального покрывающего дерева. Следовательно, класс- понятие Алгоритм является супертипом для классов Алгоритм поиска цикла минимальной длины, Алгоритм поиска кратчайшего пути и Алгоритм поиска минимального покрывающего дерева 181 (рис. 6.9). От которых, в свою очередь, будут наследоваться Алгоритмы, реализующие конкретные методы. Алгоритм также связан с Данными и Результатами. Данные и Задания должны храниться в Базе данных, что показывают ассоциациями соответствующих классов. Способ задания данных для понимания основной концепции проектируемой системы пока не очень существенен. Вид задачи в нашем случае, скорее, атрибут класса Задание, чем самостоятельный класс, так как в реальном мире - это имя, которое позволяет 182 уточнить группу возможных алгоритмов решения, а также структуры исходных данных и получаемых результатов. Для алгоритма очень существенной характеристикой является его точность, соответственно добавим атрибут Точность. Другие атрибуты пока не проявились. 6.4. Описание поведения. Системные события и операции Концептуальная модель характеризует статические свойства разрабатываемого программного обеспечения. Для описания особенностей его поведения, т. е. возможных действий системы, целесообразно использовать: диаграммы последовательностей системы, системные события, системные операции, диаграммы деятельностей, а при необходимости и диаграммы состояний объектов (см. § 7.4). Диаграмма последовательностей системы. Системные события и операции. Диаграмма последовательностей системы - графическая модель, которая для определенного сценария варианта использования показывает генерируемые действующими лицами события и их порядок. При этом система рассматривается как единое целое. Для построения диаграммы последовательностей системы необходимо: • представить систему как «черный ящик» и изобразить для нее линию жизни - вертикальную пунктирную линию, подходящую к блоку снизу; • идентифицировать каждое действующее лицо и изобразить для него линию жизни (много действующих лиц бывает в вариантах совместного ис пользования программного обеспечения); • из описания варианта использования определить множество систем ных событий и их последовательность; • изобразить системные события в виде линий со стрелкой на конце между линиями жизни действующих лиц и системы, а также указать имена событий и списки передаваемых значений. В отличие от внутренних событий, события, которые генерируются для системы действующими лицами, называют системными. Системные события инициируют выполнение соответствующего множества операций, также называемых системными. Каждую системную операцию называют по имени соответствующего сообщения. Множество всех системных операций определяют, идентифицируя системные события всех вариантов использования. Для наглядности системные операции изображают в виде операций абстрактного класса (типа) System. Если необходимо разделить множество операций на подмножества, инициируемые разными пользователями, то используют несколько абстрактных классов: System I, System2 и т. д. Каждую системную операцию необходимо описать. Обычно описание системной операции содержит: 183 • имя операции и ее параметры; • описание обязанности; • указание типа; • названия вариантов использования, в которых она используется; • примечания для разработчиков алгоритмов и т. д.; • описание обработки возможных исключений; • описание вывода неинтерфейсных сообщений; • предположение о состоянии системы до выполнения операции (пре дусловие); • описание изменения состояния системы после выполнения операции (постусловие). Пример 6.4. Разработать диаграмму последовательностей системы для варианта использования Выполнение задания решения комбинаторно-оптимизационных задач. Анализируем описание варианта использования и определяем, что действующее лицо должно инициировать девять системных событий, включая загрузку задания из базы, которая логически следует из операции сохранения. Покажем эти события на диаграмме последовательностей (рис. 6.10). В скобках укажем параметры, которые должны формировать эти события. 184 Следовательно, система должна обеспечивать выполнение соответствующих операций. Полученное множество операций приписывается классу System (рис. 6.11). Далее каждую операцию необходимо описать. Для примера опишем операцию Инициировать решение (): Раздел Описание Имя Инициировать решение() Обязанности Выполнить задание и вывести результаты пользователю Тип Системная Ссылки Вариант использования Выполнить задание Примечания Предусмотреть возможность прерывания процесса решения пользователем Исключения 1. Если в задании указаны не все исходные данные, то вывести сообщение об ошибке 2. Если при указанных исходных данных решение задачи укачанным методом невозможно, то вывести сообщение об ошибке Вывод - Предусловия Предполагается наличие всех исходных данных задания Постусловие Получен результат 185 Диаграммы деятельностей. В зависимости от степени детализации диаграммы деятельностей так же, как диаграммы классов, используют на разных этапах разработки. На этапе анализа требований и уточнения спецификаций диаграммы деятельностей позволяют конкретизировать основные функции разрабатываемого программного обеспечения. Под деятельностью в данном случае понимают задачу (операцию), которую необходимо выполнить вручную или с помощью средств автоматизации. Каждому варианту использования соответствует своя последовательность задач. В теоретическом плане диаграммы деятельности являются обобщенным представлением алгоритма, реализующего анализируемый вариант использования. На диаграмме деятельность обозначается прямоугольником с закругленными углами (рис. 6.12, а). Диаграммы деятельностей позволяют описывать альтернативные и параллельные процессы. Для обозначения альтернативных процессов используют ромб (рис. 6.12, б), условие указывают над ним слева или справа, а альтернативы «да», «нет» - рядом с соответствующими выходами. С помощью этого же блока можно построить циклический процесс. Множественность активации деятельности обозначают символом «*», помещенным рядом со стрелкой активации деятельности, и при необходимости уточняют надписью вида «для каждой строки». Для обозначения параллельных процессов используют линейки синхронизации (рис. 6.12, в), причем условие синхронизации можно уточнить, указав его на диаграмме. На рис. 6.13 показано, что «Деятельность 1» и «Деятельность 2» могут выполняться параллельно. На этапе определения спецификаций имеет смысл уточнять только варианты использования, краткое описание которых недостаточно для понимания сущности решаемых проблем. Диаграммы деятельностей, таким образом, можно использовать вместо описания нарiюн гон использования или кик дополнение к ним. 186 Пример 6.5. Построить диаграмму деятельностей, уточняющую вариант использования Выполнение задания системы решения комбинаторно-оптимизационных задач. Учитывая описание предметной области в виде контекстной диаграммы классов, анализируем описание варианта использования. Разбиваем процесс на отдельные операции. Полученные операции показываем на диаграмме деятельностей (рис. 6.14). 187 Контрольные вопросы и задания 1. В чем сущность объектной декомпозиции? 2. Для чего используют язык UML? Почему его называют языком моделирования? Чем обусловлен выбор именно этого языка в качестве стандарта описания объектных разработок? 3. Какие диаграммы используют в качестве спецификаций программного обеспечения при объектном подходе? 4. Что такое «вариант использования»? Как строится диаграмма вариантов использования, и какую информацию она содержит? 5. Для чего нужны концептуальные модели предметной области? Поясните методику их построения. 6. Какие отношения между основными понятиями предметной области отображают концептуальные модели? 7. Какие диаграммы UML применяют для описания поведения разрабатываемо го программного обеспечения? 8. Что понимают под системными событиями и операциями? 9. Разработайте спецификации простейшего графического редактора, использующего векторную графику. Какие диаграммы целесообразно строить в данном случае? 188 7. ПРОЕКТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ ОБЪЕКТНОМ ПОДХОДЕ Основной задачей логического проектирования при объектном подходе является разработка классов для реализации объектов, полученных при объектной декомпозиции, что предполагает полное описание полей и методов каждого класса. Физическое проектирование при объектном подходе включает объединение классов и других программных ресурсов в программные компоненты, а также размещение этих компонентов на конкретных вычислительных устройствах. 7.1. Разработка структуры программного обеспечения при объектном подходе Большинство классов можно отнести к определенному типу, который применительно к данному подходу называют стереотипом, например: • классы-сущности (классы предметной области); • граничные (интерфейсные) классы; • управляющие классы; • исключения и т. д. (рис. 7.1). Классы-сущности используют для представления сущностей реального мира или внутренних элементов системы, например структур данных. Как правило, они не зависят от окружения, и их используют в различных приложениях. Для выявления классов-сущностей изучают описания вариантов ис- 189 пользования, концептуальную модель и диаграммы деятельностей. Полученный таким образом список классов-кандидатов фильтруют, удаляя слова, не относящиеся к предметной области, языковые выражения и т. п. Среди оставшихся отбирают классы-кандидаты, объекты которых обладают как состоянием, так и поведением. Граничные классы обеспечивают взаимодействие между действующими лицами и внутренними элементами системы. К этому типу относят как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными средствами или программными системами. Для обнаружения граничных классов изучают пары «действующее лицо - вариант использования». Управляющие классы служат для моделирования последовательного поведения, заложенного в один или несколько вариантов использования. Если количество классов-кандидатов и других ресурсов велико, то их целесообразно объединить в группы - пакеты. Пакетом при объектном подходе называют совокупность описаний классов и других программных ресурсов, в том числе и самих пакетов. Объединение в пакеты используют только для удобства создания больших проектов, количество классов в которых велико. При этом в один пакет обычно собирают классы и другие ресурсы единого назначения. Диаграмма пакетов показывает, из каких частей состоит проектируемая программная система, и как эти части связаны друг с другом. Связь между пакетами фиксируют, если изменения в одном пакете могут повлечь за собой изменения в другом. Она определяется внешними связями классов и других ресурсов, объединенных в пакет. Возможны различные виды зависимости классов, например: • объекты одного класса посылают сообщения объектам другого класса; • объекты одного класса обращаются к компонентам объектов другого; • объекты одного класса используют объекты другого в списке парамет ров методов и т. п. Самыми хорошими технологическими характеристиками отличается вариант, при котором каждый пакет включает интерфейс, содержащий описание всех ресурсов данного пакета, и взаимодействие пакетов осуществляется только через этот интерфейс. Изменения реализации ресурсов пакета в этом случае не затрагивает других пакетов. И только изменения в интерфейсе могут потребовать изменения пакетов, использующих ресурсы данного пакета. Пакеты, с которыми связаны все пакеты программной системы, называют глобальными. Интерфейсы таких пакетов необходимо проектировать особенно тщательно, так как изменения в них потребуют проверки всех пакетов разрабатываемой системы. 190 На рис. 7.2 приведены обозначения нотации UML, которые допустимо использовать на диаграммах пакетов. Кроме указанных обозначений на диаграммах пакетов допустимо показывать обобщения (рис. 7.3), что, как правило, подразумевает наличие единого интерфейса нескольких пакетов. В этом случае фиксируется связь от пакета-подтипа к пакету- супертипу. Пример 7.1. Разработать диаграмму пакетов системы решения комбинаторно- оптимизационных задач. Анализ концептуальной модели (см. рис. 6.9) и вариантов использования (см. рис. 6.4) позволяют выделить следующие группы классов или пакеты: • Пользовательский интерфейс - классы, реализующие объекты интер фейса с пользователем; • Библиотека интерфейсных компонентов - классы, реализующие ин- терфейсные компоненты: окна, кнопки, метки и т. п.; • Объекты управления - клас сы, реализующие сценарии вари антов использования; • Объекты задачи - классы, реализующие объекты предметной области системы; • Интерфейс базы данных - классы, реализующие интерфейс с базой данных; 191 • База данных; • Базовые структуры данных - классы, реализующие внутренние струк туры данных, такие, как деревья, n-связные списки и т. п.; • Обработка ошибок - классы исключений, реализующие обработку не штатных ситуаций. Последние два пакета объявим глобальными, так как их элементы могут использовать классы всех пакетов. Определим зависимости классов и построим диаграмму пакетов (рис. 7.4). 7.2. Определение отношений между объектами После определения основных пакетов разрабатываемого программного обеспечения переходят к детальному проектированию классов, входящих в каждый пакет. Классы- кандидаты, которые предположительно должны войти и конкретный пакет, показывают на диаграмме классов этапа проектирования и уточняют отношения между объектами указанных классов. Пример 7.2. Определить классы-кандидаты пакета Объекты задачи. Используя рекомендации, приведенные в § 7.1, выполним анализ концептуальной модели предметной области (рис. 6.9), описания основного ва- 192 рианта использования Решение задачи (см. § 6.2) и его диаграммы деятельностей (см. рис. 6.4). Список классов-кандидатов, полученный на основе данного анализа, выглядит следующим образом: • класс Задание - объекты данного класса должны создаваться каждый раз, когда пользователь инициирует новое задание; • семейство классов с базовым классом Алгоритм - объекты данного класса должны создаваться, когда определен алгоритм решения задачи; • класс Данные — объекты данного класса должны создаваться при определении (вводе или выборе из базы) данных; • класс Результаты - объекты данного класса должны создаваться при решении конкретной задачи конкретным алгоритмом с использованием конкретных данных. Исходный вариант диаграммы классов пакета Объекты задачи показан на рис. 7.5. 193 Основой для проектирования классов является уточнение взаимодействия объектов этих классов в процессе реализации вариантов использования. При этом применяют диаграммы последовательностей и диаграммы кооперации. Если же необходимо описать взаимодействие объектов при обработке конкретного сообщения, удобны именно диаграммы последовательностей. |