Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 45
Текст из файла (страница 45)
Подклассы могут осуществлять повторное использование свойств, унаследованных от суперклассов, или переопределять их. Подклассы также могут добавлять новые свойства. Подкласс наследует диаграммы состояний своих предков, которые должны выполняться параллельно с его собственными диаграммами состояний. Подкласс наследует и состояния предков, и их переходы. Во избежание конфликтов диаграммы состояний подклассов должны быть ортогональными дополнениями к диаграммам состояний суперклассов.
Модель классов поддерживает множественное наследование: класс может быль потомком сразу нескольких суперклассов. Для простоты множественное наследование для сигналов и вариантов использования обычно не разрешается. ° Обобщение сигналов. Сигналы также можно упорядочить в иерархию с наследованием атрибутов. Каждый реальный сигнал может считаться листом этого дерева. Сигнал переключает переходы, рассчитанные на любой из его предков. ° Обобщение вариантов использования. Обобщение применимо и к вариантам использования. Вариант-предок описывает обьцую последовательность поведения. Потомки конкретизируют предка, добавляя новые этапы поведения или детализируя имеющиеся.
В одном отношении обоб1цение вариантов использования оказывается сложнее обобщения классов. Подкласс может добавлять атрибуты к атрибутам, унаследованным от предка, однако их порядок не имеет значения. Вариант-потомок может добавлять этапы поведения, но они должны располагаться в конкретных местах между этапами поведения предка.
При наследовании классификатор-предок може~ быть как абстрактным, так и конкретным. Однако мы рекомендуем вам делать предков только абстрактными. В этом случае будет очевидно, какие классификаторы должны быть абстрактными, а какие конкретными (только листья). Классификаторы, кроме того, обладают свойством полиморфизма: потомок всегда может быть подставлен вместо предка. 200 Глава 9 ° Обзор концепций В первом издании этой книги было описано наследование состояний, поскольку оно было разрешено, однако в УМ).2 оно было запрещено, так как состояние не является классификатором. Можно провести некоторые параллели между обобщением классификаторов и вложением состояний, однако, строго говоря, в ИМЕ2 обобщение к состояниям неприменимо. 9.4.2.
Агрегация Агрегация — это отношение «и», которое разбивае~ агрегат на ортогональные части, взаимодействие которых некоторым образом ограничивается. ° Агрегация объектов. Агрегация — это особая форма ассоциации, которая обладает дополнительными свойствами: транзитивностью и антисимметрией. () МЕ определяет две формы агрегации объектов: общая форма называется собственно агрегацией (составляющая часть может использоваться повторно и может существовать отдельно от агрегата) и композицией (составляющая часть может принадлежать не более чем одному агрегату и имеет одинаковое с ним время жизни).
Диаграмма состояний агрегата является совокупностью диаграмм состояний его частей. Состояние агрегата определяется комбинацией состояний всех его частей. Состояние агрегата — это одно состояние с первой диаграммы, И одно состояние со второй диаграммы, И одно состояние с третьей диаграммы, И так далее. В более сложных случаях состояния частей могут взаимодействовать между собой. ° Агрегация состояний. Некоторые состояния можно разбивать на более мелкие, каждое из которых выполняется независимо и имеет собственную поддиаграмму. Состояние объекта включает в себя одно состояние с каждой из диаграмм.
Эта глава заканчивает рассмотрение концепций и обозначений, применяемых в объектно-ориентированном моделировании. Анализ и проектирование А В первой части нашей книги были описаны концепции и обозначения, относящиеся к моделям классов, состояний и взаимодействия.
Во второй и третьей частях мы сосредоточим свое внимание на процессе формирования моделей. В первой части речь шла о том, из чего модель состоит, а во второй и третьей части о том, каким образом можно сформулировать модель. Наш подход к процессу проектирования не зависит от языка реализации и одинаково хорошо применим к объектноориентированным языкам, не объектно-ориентированным языкам и базам данных. В главе 10 мы приводим обзор процесса построения моделей и подчеркиваем, что разработка обычно представляет собой итерационную деятельность, а не жестку|о последовательность шагов. Глава 11 посвящена первой стадии разработки — концептуализации системы,— на которой автор придумывает приложение и продает его идею организации.
Имея концепцию приложения, вы можете прорабатывать и уточнять ее в процессе формирования моделей. Об этом рассказывают главы 12 и 13. Сначала строится модель области применения, описывающая предметы реального мира, несущие семантику приложения. Затем строится модель приложения, описывающая компьютерные аспекты приложения, видимые пользователям. Аналитические модели дадут вам полное понимание приложения. На следующем этапе придется перейти к решению практических вопросов реализации моделей.
Глава 14 посвящена проектированию системы, то есть выработке высокоуровневой стратегии построения решения. Глава 15 посвящена проектированию классов, в процессе которого определяются особенности классов, ассоциаций и операций. Глава 16 завершает вторую часть книги, подводя итоги этапам анализа и проектирования процесса разработки. Изучив вторую часть, вы узнаете основы построения объектно-ориентированных моделей. Вы не станете экспертом, но заложите неплохой фундамент для приобретения ценного опыта по разработке программного обеспечения. Вы будете готовы к изучению вопросов реализации и технологий разработки программного обеспечения, которые рассматриваются в последних двух частях.
Обзор процесса разработки Процесс разработки программного обеспечения (зо(гааге г!ече!оршепт ргосеез) является основой организованного производства программного обеспечения при помоши совокупности заранее определенных методик и систем обозначений. Описанный в этой книге процесс начинается с формулировки задачи, затем продолжается этапами анализа, проектирования и реализации. Этапы процесса описываются линейно, но на практике процесс редко оказывается последовательным.
10.1. Этапы разработки Разработка программного обеспечения представляет собой последовательность четко определенных этапов, на каждом из которых решается определенная задача. Каждый этап характеризуется входными н выходными данными. ° Концептуализация системы. Придумывается приложение и формулируются пробные требования. ° Анализ. Углубленное понимание требований достигается при помоши построения моделей. Цель анализа состоит в указании того, что должно быть сделано (а не того, как это должно быть достигнуто). Нужно понять задачу перед тем, как вы попытаетесь ее решить. ° Проектирование системы. Предлагается высокоуровневая стратегия решения задачи создания приложения (архитектура системы), определяюшая основы для последую~пего проектирования классов.
° Проектирование классов. Модели реального мира, полученные на этапах анализа, расширяются и корректируются таким образом, чтобы их можно было реализовать на компьютере. Определя1отся алгоритмы для реализации операций. 10.1. Этапы разработки 203 ° Реализация. Проект преобразуется в программный код и структуры баз данных. ° Тестирование. Проверяется, что приложение пригодно для практического использования и действительно удовлетворяет поставленным требованиям. ° Обучение.
Пользователям помогают освоиться с приложением. ° Развертывание. Приложение развертывается там, где планируется его применение. Осушествляется переход с унаследованных приложений. ° Поддержка. Обеспечивается долгосрочная жизнеспособность приложения. На самом деле, процесс разработки непрерывен. Модели постоянно уточняются н оптимизируются, даже когда вы переключаетесь с анализа на проектирование, а затем на реализацию. Одни и те же концепции и обозначения используются на всех этапах. Разница в том, что вначале большее внимание уделяется потребностям заказчика, а в конце — компьютерным ресурсам.
Объектно-ориентированный подход переносит основные усилия по разработке программного обеспечения на этапы анализа и проектирования. Иногда кажется неправильным тратить много времени на анализ и проектирование системы, однако эти дополнительные затраты с лихвой окупаются быстрой и простой реализацией. Поскольку конечная система оказывается более ясной и легче приспосабливаемой, ее проше поддерживать и изменять в соответствии с изменяющейся ситуацией.
Первые три этапа процесса разработки рассматриваются во второй части нашей книги. Третья часть целиком посвящена реализации. Мы подчеркиваем важность разработки и лишь отчасти затрагиваем вопросы тестирования, обучения, развертывания и поддержки. Эти этапы тоже важны, но они не относятся к предмету нашей книги. 10.1.1. Концептуализация системы Концептуалязация системы (зузГет сопсерг1оп) означает рождение приложения.
В самом начале его существования кто-то придумывает идею приложения, составляет бизнес-план и продает свою идею какой-либо организации. Человек, который этим занимается, должен представлять как потребности потенциальных клиентов, так и технологические возможности. 10.1.2. Анализ Анализ (апа!уз1з) — это создание моделей. Аналитики формализуют и исследуют требования, конструируя свои модели. Они описывают то, что должно быть сделано, а не то, как зто следует сделать. Анализ — это непростая задача.
Разработчики должны полностью осознать сложность ставящейся перед ними задачи, перед тем как заняться дополнительными сложностями, которые неизбежно возникнут на этапе реализации. Надежные модели — обязательное условие для создания расширяемого, эффективного, надежного и корректного приложения. Никакие исправления на этапах реализации не смогут исправить внутреннюю несогласованность приложения и скомпенсировать недостаток предусмотрительности. 204 Глава 10 ° Обзор процесса разработки В процессе анализа разработчики используют все доступные источники информации (документы, интервью, аналогичные и связанные приложения) и устраняют возникающие неопределенности.
Часто бизнес-эксперты оказываются не в состоянии сформулировать точные требования, и их уточнением приходится заниматься разработчикам. Моделирование ускоряет сходимость представлений разработчиков и бизнес-экспертов, потому что гораздо быстрее работать с различными вариантами моделей, чем с различными реализациями кода. Модели подчеркивают недостатки и несогласованные моменты, которые можно затем исправить.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
