Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 38
Текст из файла (страница 38)
Методможно автоматизировать, и такая система была построена в Токийскомтехнологическом институте и в Fujitsu [46].Подход Аббота полезен, так как он прост и заставляет разработчиказаниматься словарем предметной области. Однако он весьма приблизителен инепригоден для сколько-нибудь сложных проблем. Человеческий язык ужасно неточное средство выражения, потому список объектов и операцийзависит от умения разработчика записывать свои мысли.
Тем более, что длямногих существительных можно найти соответствующую глагольную формуи наоборот.Структурный анализ. Вторая альтернатива классической техникеобъектно-ориентированного анализа использует структурный анализ какоснову для объектно-ориентированного проектирования. Такой подходпривлекателен потому, что много аналитиков применяют этот подход иимеется большое число программных CASE-средств, поддерживающихавтоматизацию этих методов. Нам лично не нравится использоватьструктурный анализ как основу для объектно-ориентированногопроектирования, но для некоторых организаций такой прагматический подходне имеет альтернативы.После проведения структурного анализа мы уже имеем модельсистемы, описанную диаграммами потоков данных и другими продуктамиструктурного анализа.
Эти диаграммы дают нам формальную модельпроблемы. Исходя из модели, мы можем приступить к определениюосмысленных классов и объектов тремя различными способами.МакМенамин и Палмер предлагают сначала приступить кформированию словаря данных и затем к анализу контекстных диаграмммодели. Они говорят:"рассматривая список основных структур данных, следует подумать, очем они говорят или что описывают. Например, если они прилагательные, токакие существительные они описывают? Ответы на такие вопросы могутпополнить ваш список объектов" [47]. Эти кандидаты в объекты происходятиз окружающей среды, из существенных входных и выходных данных, атакже продуктов, услуг и других ресурсов, которыми она управляет.Следующие два способа основаны на анализе отдельных диаграммпотоков данных.
Если взять какую-нибудь диаграмму потоков (втерминологии Барда и Меллора [48]), то кандидаты в объекты это:•внешние сущности•хранилища данных•хранилища управляющих сущностей•управляющие преобразования.Кандидаты в классы:•потоки данных•потоки управления.Остается преобразование данных, которое мы можем рассматриватькак операции над существующими объектами или как поведение некоторогообъекта, который мы создали специально для выполнения нужногопреобразования.Зайдевиц и Старк предлагают еще один метод, который они называютанализом абстракций. Метод базируется на идентификации основныхсущностей, которые по своей природе аналогичны основным преобразованиямв структурном проектировании. Как они говорят, "в структурном анализевходные и выходные данные изучаются до тех пор, пока не достигнутвысшего уровня абстракции.
Процесс преобразования входных данных ввыходные есть основное преобразование. В абстрактном анализе разработчикделает то же самое, а также изучает основное преобразование для того, чтобыопределить, какие процессы и состояния представляют наилучшуюабстрактную модель системы" [49]. После определения основной сущности вдиаграмме потоков данных аналитик приступает к изучению всейинфраструктуры, прослеживая входящие и исходящие потоки данных изцентра, группируя процессы и состояния, встречающиеся по пути.
Дляпрактического использования авторы нашли анализ абстракций слишкомсложным и в качестве альтернативы предлагают объектно-ориентированныйанализ [50].Необходимо отметить, что принципы структурного проектирования,которое, естественно, следует за структурным анализом, полностьюортогональны принципам объектно-ориентированного проектирования. Нашопыт показывает, что использование структурного анализа в процессеобъектно-ориентированного проектирования часто приводит к полномупровалу, если разработчик не способен сопротивляться желанию свалиться вструктурную пропасть. Другая очень серьезная опасность заключается в том,что многие аналитики любят рисовать диаграммы потоков данных, которыепредставляют собой скорее описание проекта, чем модель существа системы.Очень трудно построить объектно-ориентированную систему, если модельстоль очевидно ориентирована на алгоритмическую декомпозицию. Поэтомумы предпочитаем объектно-ориентированный анализ и анализ проблемнойобласти как подготовительный этап для объектно-ориентированногопроектирования.
При этом уменьшается риск замусорить проект элементамиалгоритмического анализа.Если же по каким-либо уважительным причинам24 приходится взять заоснову структурный анализ, прекратите строить диаграммы, как только ониначинают смахивать на проект программы, а не на модель предметнойобласти. Помните, что материалы проектирования, такие, как диаграммыпотоков данных, это не конечный продукт, а инструмент разработчиков.Обычно строятся диаграммы, а затем разрабатываются механизмы,обеспечивающие необходимое поведение системы, то есть сам актпроектирования видоизменяет начальную модель. Поддержание соответствиямодели и развивающегося проекта - дело трудное, и, честно говоря,бесполезное. Имеет смысл сохранять только продукт структурного анализавысокого уровня абстракции.
Он отражает существенные черты и достаточнонезависим от проекта системы.4.3. Ключевые абстракции и механизмыКлючевые абстракцииПоиск и выбор ключевых абстракций. Ключевая абстракция - этокласс или объект, который входит в словарь проблемной области. Самаяглавная ценность ключевых абстракций заключена в том, что они определяютграницы нашей проблемы: выделяют то, что входит в нашу систему и поэтомуважно для нас, и устраняют лишнее.
Задача выделения таких абстракцийспецифична для проблемной области. Как утверждает Голдберг, "правильныйвыбор объектов зависит от назначения приложения и степени детальностиобрабатываемой информации" [51].Как мы уже отмечали, определение ключевых абстракций включает всебя два процесса: открытие и изобретение. Мы открываем абстракции,слушая специалистов по предметной области: если эксперт про нее говорит, тоэта абстракция обычно действительно важна [52]. Изобретая, мы создаемновые классы и объекты, не обязательно являющиеся частью предметнойобласти, но полезные при проектировании или реализации системы.Например, пользователь банкомата говорит "счет, снять, положить"; этитермины - часть словаря предметной области. Разработчик системыиспользует их, но добавляет свои, такие, как база данных, диспетчер экрана,список, очередь и так далее. Эти ключевые абстракции созданы уже непредметной областью, а проектированием.Наиболее мощный способ выделения ключевых абстракций - сводитьзадачу к уже известным классам и объектам.
Как будет показано ниже в главе6, при отсутствии таких повторно используемых абстракций мы рекомендуемпользоваться сценариями, чтобы вести процесс идентификации классов иобъектов.Уточнение ключевых абстракций. Определив кандидатов на ролиключевых абстракций, мы должны оценить их по критериям, описанным впредыдущих главах.
По словам Страуструпа "программист должен задаватьсявопросами: Как создаются объекты класса? Как можно копировать и/илиуничтожать объекты данного класса? Какие операции могут быть выполненынад этим объектом? Если ответы на эти вопросы туманны, то, возможно,24Политические и исторические причины в качестве уважительных не принимаются.общая концепция не ясна и лучше сесть и подумать еще раз, чем бросатьсяпрограммировать" [53].Определив новые абстракции, мы должны найти их место в контекстеуже существующих классов и объектов.
Не стоит пытаться делать это строгосверху вниз или снизу вверх. Халберт и О'Брайен утверждают, что "нет особойнеобходимости строить иерархию классов, начиная с самого верхнего класса,и потом дополнять ее подклассами. Чаще вы создаете несколько независимыхиерархий, осознаете их общие черты и выделяете один или несколькосуперклассов. Требуется несколько проходов вверх и вниз по иерархии, чтобысоздать программный проект" [54].
Это не карт-бланш на хакерство, а всеголишь наблюдение, основанное на опыте и подтверждающее тот факт, чтообъектно-ориентированное проектирование - процессКлассы и объекты должны быть на надлежащем уровне абстракции: неслишком высоко и не слишком низкопоследовательных приближений. Сходное наблюдение делаетСтрауструп: "Наиболее частые реорганизации в иерархии классов - этосведение совпадающих частей двух классов в один и разделение класса на двановых" [55].Трудно сразу расположить классы и объекты на правильных уровняхабстракции.
Иногда, найдя важный класс, мы можем передвинуть его вверх виерархии классов, тем самым увеличивая степень повторности использованиякода. Это называется продвижением класса [56]. Аналогично, можем прийти квыводу, что класс слишком обобщен, и это затрудняет наследование:происходит семантический разрыв или конфликт зернистости [57]. В обоихслучаях мы пытаемся выявить зацепление или недостаточную связностьабстракций и смягчить конфликт.Программисты часто легкомысленно относятся к правильномунаименованию классов и объектов, но на самом деле очень важно отразить вобозначении классов и объектов сущность описываемых ими предметов.Программы необходимо писать тщательно, как художественную литературу,дума я и о читателях, и о компьютере [58].
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
