Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 58
Текст из файла (страница 58)
Важно, чтобы для оценкипрототипа были установлены четкие критерии. Работу над прототипом чащепланируют по срокам (имея в виду, что прототип должен быть завершен копределенной дате), чем по требованиям. Это не всегда плохо, так какискусственно ограничивает усилия по созданию прототипа и пресекаетпопытки выпустить концептуально недоношенный продукт.Менеджеры верхнего звена могут оценить здоровье организации по ееотношению к новым идеям. Любая организация, которая сама не генерируетновые идеи, либо уже мертва, либо близка к этому. Наиболее благоразумноедействие в такой ситуации - выделить независимые подразделения либовообще уйти из бизнеса. С другой стороны, любая организация, заваленнаяновыми идеями, но неспособная определить их разумный приоритет,неуправляема.
Такие компании часто тратят впустую существенные ресурсы,перескакивая к разработке изделия слишком рано, без исследования риска.Наиболее благоразумно здесь было бы формализовать процесс производства иналадить переход от концепции к продукту.АнализЦель. Как утверждает Меллор, "цель анализа - дать описание задачи.Описание должно быть полным, непротиворечивым, пригодным для чтения иобозрения всеми заинтересованными сторонами, реально проверяемым" [1б].Говоря нашим языком, цель анализа - представить модель поведения системы.Надо подчеркнуть, что анализ сосредоточен не на форме, а наповедении.
На этой фазе неуместно заниматься проектированием классов,представлением или другими тактическими решениями. Анализ долженобъяснить, что делает система, а не то, как она это делает. Любое, сделанноена стадии анализа (вопреки этому правилу) утверждение о том "как", можетсчитаться полезным только для демонстрации поведения системы, а не какпроверяемое требование к ее проектированию.В этом отношении цели анализа и проектирования весьма различны. Ванализе мы ищем модель мира, выявляя классы и объекты (их роли,обязанности и взаимодействия), которые формируют словарь предметнойобласти.
В проектировании мы изобретаем искусственные персонажи,которые реализуют поведение, требуемое анализом. В этом смысле, анализ это деятельность, которая сводит вместе пользователей и разработчиковсистемы, объединяя их написанием общего словаря предметной области.Сосредоточившись на поведении, мы приступаем к выяснениюфункциональных точек системы. Функциональные точки, впервые описанныеАланом Альбрехтом, обозначают видимые извне и поддающиеся проверкеэлементы поведения системы [17]. С точки зрения конечного пользователя,функциональная точка представляет некоторое простейшее действие системыв ответ на некоторое событие.25 Функциональные точки часто (но не всегда)обозначают отображение входов на выходы и таким образом представляютпреобразования, совершаемые системой.
С точки зрения аналитика,функциональные точки представляют кванты поведения. Действительно,функциональные точки - мера сложности системы: чем их больше, тем онасложнее. На стадии анализа мы передаем семантику функциональных точексценариями.Анализ никогда не происходит независимо. Мы не стремимся кисчерпывающему пониманию поведения системы и даже утверждаем, чтосделать полный анализ до начала проектирования не только невозможно, но инежелательно. Процесс построения системы поднимает вопросы о ееповедении, на которые реально нельзя дать гарантированный ответ, занимаясьтолько анализом. Достаточно выполнить анализ всех первичных элементовповедения системы и некоторого количества вторичных, добавляемых длягарантии того, что никакие существенные шаблоны поведения не пропущены.Достаточно полный и формальный анализ необходим в первуюочередь для того, чтобы ход проекта можно было проследить.
Возможностьпроследить проект нужна для обеспечения возможности его просчитать, дабыгарантировать, что не пропущено ни одной функциональной точки.Возможность проследить проект является также основой управления риском.При разработке любой нетривиальной системы, менеджеры столкнутся снеобходимостью сделать нелегкий выбор либо в распределении ресурсов,либо в решении некоторой тактической проблемы. Имея возможностьпроследить процесс от функциональных точек до реализации, гораздо легчеоценить влияние подобных проблем на архитектуру.Результаты. ДеШампо считает, что результатом анализа должно бытьописание назначения системы, сопровождаемое характеристикамипроизводительности и перечислением требуемых ресурсов [19].
В объектноориентированном проектировании мы получаем такие описания с помощьюсценариев. Каждый сценарий представляет одну функциональную точку. Мыиспользуем первичные сценарии для иллюстрации ключевого поведения ивторичные для описания поведения в исключительных ситуациях.Как говорилось в предыдущих главах, мы используем технику CRCкарточек для раскадровки сценариев, а потом применяем диаграммы объектовдля более точной иллюстрации семантики каждого сценария. Такиедиаграммы должны демонстрировать взаимодействие объектов,обеспечивающее выполнение функций системы, и упорядоченный процессэтого взаимодействия, состоящий в посылке объектами сообщений друг другу.Кроме диаграмм объектов, в рассмотрение можно включить диаграммыклассов (чтобы показать существующие ассоциации между классамиобъектов) и состояний (чтобы показать жизненный цикл важнейшихобъектов).Часто эти результаты анализа объединяют в один формальныйдокумент, который формулирует требования анализа к поведению системы,иллюстрируя их диаграммами, и показывает такие неповеденческие аспектысистемы, как эффективность, надежность, защищенность и переносимость[20].Побочным результатом анализа будет оценка риска: выявлениеопасных мест, которые могут повлиять на процесс проектирования.Обнаружение имеющегося риска в начале процесса проектирования облегчитвозможные архитектурные компромиссы на поздних этапах разработки.25Как отмечает Дрегер, в теории управления информационными системамифункциональная точка представляет отдельную бизнес-функцию конечногопользователя [18].Виды деятельности.
С анализом связаны два основных видадеятельности: анализ предметной области и планирование сценариев.Как мы описали в главе 4, анализ области должен идентифицироватьобитающие в данной проблемной области классы и объекты. Прежде, чемвзяться за разработку новой системы, обычно изучают уже существующие. Вэтом случае мы можем извлечь выгоду из опыта других проектов, в которыхпринимались сходные решения. Лучшим результатом анализа предметнойобласти может явиться вывод, что нам не надо проектировать новый продукт,а следует повторно использовать или адаптировать существующуюпрограмму.Планирование сценариев является центральным действием анализа.Интересно, что по этому вопросу, кажется, имеется совпадение мнений средидругих методологов, особенно у Рубина и Голдберга (Rubin adn Goldberg),Адамса (Adams), Вирфс-Брока (Wirfs-Brock), Коада (Coad) и Джекобсона(Jacobson).
Типичный порядок его выполнения следующий:•Идентифицировать основные функциональные точки системы и, есливозможно, сгруппировать функционально связанные видыповедения. Рассмотреть возможность создания иерархии функций,в которой высшие функции вытекают из низших.•Для каждого представляющего интерес набора функциональныхточек сделать раскадровку сценария, используя технику анализаповедения и примеров использования, описанную в главе 4.26 Вмозговом штурме каждого сценария эффективна техника CRCкарточек. Когда прояснится семантика сценариев, следуетдокументировать их, используя диаграммы объектов, которыеиллюстрируют объекты, инициирующие и обеспечивающиеповедение, и их взаимодействие при выполнении действийсценария.
Приложить описание событий, происходящих привыполнении сценария, и порядок выполняемых в результатедействий. Кроме того, необходимо перечислить всепредположения, ограничения и показатели эффективности длякаждого сценария [21].•Если необходимо, сделать вторичные сценарии, иллюстрирующиеповедение системы в исключительных ситуациях.•Для объектов с особо важным жизненным циклом описать диаграммысостояний (построить конечный автомат).•Найти в сценариях повторяющиеся шаблоны и выразить их втерминах более абстрактных обобщенных сценариев или втерминах диаграмм классов, показывающих связи междуключевыми абстракциями.•Внести изменения в словарь данных; включить в него новые классы иобъекты, выявленные для каждого сценария, вместе с описаниемих ролей и обязанностей.Как описано в следующей главе, планирование сценариев выполняетсяаналитиками в сотрудничестве с экспертами в предметной области иархитекторами.
В планировании сценария дополнительно должен участвоватьконтролер качества, так как сценарии представляют тестируемое поведение.Привлечение контролеров в самом начале процесса помогает сразу установитьвысокие стандарты качества. Эффективно также привлекать и других членовколлектива, чтобы дать им возможность включиться в процесспроектирования и ускорить понимание строения системы.26Всесторонний анализ этого предмета можно найти в работах Джекобсона [22] иРубина и Голдберга[23].Путевые вехи и характеристики.
Мы благополучно завершим этуфазу, когда мы будем иметь уточненные и подписанные сценарии для всехфундаментальных типов поведения системы. Говоря подписанные, мыпредполагаем, что конечные результаты анализа проверялись экспертами,конечными пользователями, аналитиками и архитекторами; говоряфундаментальные, мы имеем в виду типы поведения, основные для данногоприложения. Повторим, мы не ожидаем полного анализа,- достаточнорассмотреть только основные и несколько второстепенных видов поведения.Степень совершенства анализа будет измеряться, в частности, егополнотой и простотой. Хороший анализ выявляет все первичные сценарии и,как правило, важнейшие вторичные. Разумный анализ включает такжепросмотр всех стратегически важных сценариев, так как это помогает привитьединое видение системы всему коллективу разработчиков. Наконец, следуетнайти шаблоны поведения, которые давали бы возможно более простуюструктуру классов и учитывали бы все, что есть общего в различныхсценариях.Другой важной составной частью анализа является оценка риска,которая облегчит будущие стратегические и тактические компромиссы.ПроектированиеЦель.
Цель проектирования - создать архитектуру развивающейсяреализации и выработать единые тактические приемы, которыми должныпользоваться различные элементы системы. Мы начинаем процесспроектирования сразу после появления некоторой приемлемой моделиповедения системы. Важно не начинать проектирование до завершенияанализа. Равным образом важно избегать затягивания проектирования,пытаясь получить идеальную, а следовательно, недостижимую аналитическуюмодель.27Результаты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
