Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 37
Текст из файла (страница 37)
Именно по этой причине мы сменили во втором издании название книги на"Объектно-ориентированный анализ и проектирование".•МестаЗдания, офисы и другие места, существенныедля работы приложения•Организационныепользователи. единицыГруппы, к которым принадлежатНа более высоком уровне абстракции Коад вводит понятиепредметной области, которая в сущности является логически связаннойгруппой классов, относящейся к высокоуровневым функциям системы.Анализ поведения.
В то время как классические подходыконцентрируют внимание на осязаемых элементах предметной области,другая школа мысли объектно-ориентированного анализа сосредотачиваетсяна динамическом поведении как на первоисточнике объектов и классов.23 Этонапоминает концептуальную кластеризацию, рассмотренную выше: мыформируем классы, основываясь на группах объектов, демонстрирующихсходное поведение.Вирфс-Брок предлагает понятие ответственности объекта, подкоторыми следует понимать "его знания и умения. Ответственность - этоспособ выразить цель объекта и его место в системе. Ответственность объектаесть совокупность всех услуг, которые он может предоставлять по всем егоконтрактам" [36].
То есть, мы объединяем вместе те объекты, которые имеютсходные ответственности и строим иерархию классов, в которой каждыйподкласс, выполняя обязательства суперкласса, привносит своидополнительные услуги.Рубин и Гольдберг предлагают идентифицировать классы и объекты,анализируя функционирование системы: "Наш подход основан на изученииповедения системы. Мы сопоставляем формы поведения с частями системы ипытаемся понять, какая часть инициирует поведение и какие части в немучаствуют...
Инициаторы и участники, играющие существенные роли,опознаются как объекты и делаются ответственными за эти роли" [37].Идеи Рубина тесно связаны с предложенным в 1979 году Альбрехтомподходом с точки зрения функций. По его определению, функция"определяется как отдельное бизнес-действие конечного пользователя" [38], тоесть: ввод/вывод, запрос, файл или интерфейс. Очевидно, что эта концепцияпроисходит из области информационных систем.
Однако, она может бытьприменена к любой автоматизированной системе. По существу, функция - этолюбое достоверно видимое извне и имеющее отношение к делу поведениесистемы.Анализ предметной области. До сих пор мы неявно имели в видуединственное разрабатываемое нами приложение.
Но иногда в поискахполезных и уже доказавших свою работоспособность идей полезно обратитьсясразу ко всем приложениям в рамках данной предметной области, как,например, ведение историй болезни пациентов, торговля ценными бумагами,разработка компиляторов или системы управления ракетами. Если вынаходитесь в середине разработки и застряли, анализ какой-нибудь узкойпредметной области может помочь, указав вам на ключевые абстракции,оказавшиеся полезными в сходных системах. Анализ предметной областиработает очень хорошо, исключая разве что лишь очень специальныеситуации, так как уникальные программные системы встречаются крайнередко.23Шлаер и Меллор дополнили свою более раннюю работу, обратив внимание также ина поведение.
В частности, они изучали жизненный цикл объекта как средствопонимания границ.Идею анализа предметной области впервые предложил Нейборс. Мыопределим такой анализ как "попытку выделить те объекты, операции и связи,которые эксперты данной области считают наиболее важными" [39]. Мур иБайлин определяют следующие этапы в анализе области:•"Построение скелетной модели предметной области при консультациях сэкспертами в этой области.•Изучение существующих в данной области систем и представлениерезультатов в стандартном виде.•Определение сходства и различий между системами при участииэкспертов.•Уточнение общей модели для приспособления к нуждам конкретнойсистемы" [40].Анализ области можно вести относительно аналогичных приложений(вертикально) или относительно аналогичных частей одного и того жеприложения (горизонтально).
Например, начиная проектировать системуучета пациентов, имеет смысл рассмотреть уже имеющиеся подобныесистемы, чтобы понять, какие ключевые абстракции и механизмы,использованные в них, будут вам полезны, а какие нет. Аналогично системабухгалтерского учета должна представлять различные виды отчетов. Еслисчитать отчеты некой предметной областью, ее анализ может привестиразработчика к пониманию ключевых абстракций и механизмов, которыеобслуживают все виды отчетов.
Полученные таким образом классы и объектыпредставляют собой множество ключевых абстракций и механизмов,отобранных с учетом цели исходной задачи: создания системы отчетов.Поэтому окончательный проект будет проще.Определим теперь, кто такой эксперт? В роли эксперта частовыступает просто пользователь системы, например, инженер или диспетчер.Он не обязательно должен быть программистом, но должен быть близкознаком с исследуемой проблемой и разговаривать на языке этой проблемы.Менеджеры проектов заинтересованы в непосредственномсотрудничестве пользователей и разработчиков системы.
Но для оченьсложных систем прикладной анализ является формальным процессом, длякоторого требуется большое число экспертов и разработчиков на длительныйпериод времени. На практике такой формальный анализ требуется редко.Обычно для начального уяснения проблемы достаточно короткой встречиэкспертов и разработчиков. Удивительно, как мало информации требуется дляпродуктивной работы разработчика. Однако мы считаем чрезвычайнополезными такие встречи в течение всей разработки.
Анализ прикладнойобласти лучше всего вести шаг за шагом - немного поанализировать, потомнемного попроектировать и т. д.Анализ вариантов. По отдельности классический подход,поведенческий подход и изучение предметной области, рассмотренные выше,сильно зависят от индивидуальных способностей и опыта аналитика. Длябольшинства реальных проектов одновременное применение всех трехподходов неприемлемо, так как процесс анализа становитсянедетерминированным и непредсказуемым.Анализ вариантов - это подход, который можно успешно сочетать спервыми тремя, делая их применение более упорядоченным.
Впервые егоформализовал Джекобсон, определивший вариант применения, как "частныйпример или образец использования, сценарий, начинающийся с того, чтопользователь системы инициирует операцию или последовательностьвзаимосвязанных событий" [41].Коротко говоря, этот вид анализа можно начинать вместе с анализомтребований. В этот момент пользователи, эксперты и разработчикиперечисляют сценарии, наиболее существенные для работы системы (пока неуглубляясь в детали). Затем они тщательно прорабатывают сценарии,раскладывая их по кадрам, как делают телевизионщики и кинематографисты[42]. При этом они устанавливают, какие объекты участвуют в сценарии,каковы обязанности каждого объекта и как они взаимодействуют в терминахопераций. Тем самым группа разработчиков вынуждена четко распределитьобласти влияния абстракций.
Далее набор сценариев расширяется, чтобыучесть исключительные ситуации и вторичное поведение (Гольд-стейн иАлджер называют это периферийными аспектами [43]). В результатепоявляются новые или уточняются существующие абстракции. Позже, в главе6, мы покажем, как сценарии используются для тестирования.CRC-карточки. CRC обозначает Class-Responsibilities-Collaborators(Класс/Ответственности/Участники). Это простой и замечательноэффективный способ анализа сценариев. Карты CRC впервые предложили Беки Каннингхэм для обучения объектно-ориентированному программированию,но такие карточки оказались отличным инструментом для мозговых атак иобщения разработчиков между собой.Собственно, это обычные библиографические карточки 3х5 дюйма(если позволяет бюджет вашего проекта, купите 5х7; очень хорошо, есликарточки будут линованными, а разноцветные - просто мечта).
На карточкахвы пишите (обязательно карандашом) сверху - название класса, снизу в левойполовине - за что он отвечает, а в правой половине - с кем он сотрудничает.Проходя по сценарию, заводите по карточке на каждый обнаруженный класс идописывайте в нее новые пункты. При этом каждый раз обдумывайте, что изэтого получается, и "выделяйте излишек ответственности" в новый класс или,что случается чаще всего, перенесите ответственности с одного большогокласса на несколько более детальных классов, или, возможно, передайте частьобязанностей другому классу.Карточки можно раскладывать так, чтобы представить формысотрудничества объектов.
С точки зрения динамики сценария, ихрасположение может показать поток сообщений между объектами, с точкизрения статики они представляют иерархии классов.Неформальное описание. Радикальная альтернатива классическомуанализу была предложена в чрезвычайно простом методе Аббота. Согласноэтому методу надо описать задачу или ее часть на простом английском языке,а потом подчеркнуть существительные и глаголы [45]. Существительные кандидаты на роль классов, а глаголы могут стать именами операций.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
