Шаг 56.
Унифицированный язык моделирования UML.
Подходы к анализу объектно-ориентированных систем

    На этом шаге рассмотрим подходы к анализу объектно-ориентированных систем.

    Несмотря на то что границы между анализом и проектированием размыты, они имеют совершенно разные цели. На этапе анализа осуществляется первичное исследование задачи и моделирование реальности с помощью классов и объектов, образующих словарь предметной области. На этапе проектирования изобретаются абстракции и механизмы реализации принятого решения.

    Классические подходы

    Многие исследователи предлагали разнообразные источники классов и объектов, согласованных с требованиями предметной области. Этот подход называется классическим, поскольку в его основе лежат принципы классической категоризации.

    Например, Шлаер (Sclaer) и Меллор (Mellor) предложили следующие источники классов и объектов [Shlaer, S., and Mellor, S. 1988. Object-Oriented Systems Analysis: Modeling the World in Data. Englewood Cliffs, NJ: Yourdon Press, p. 15.]:

    Для моделирования баз данных Росс (Ross) предложил аналогичный список [Ross, R. 1987. Entity Modeling: Techniques and Application. Boston, MA: Database Research Group, p. 9.]:

    Коад (Coad) и Йордон (Yourdon) предложили свой список источников потенциальных объектов [Coad, P., and Yourdon, E. 1990. Object-Oriented Analysis. Englewood Cliffs, NJ: Prentice-Hall, p. 62.]:

    На более высоком уровне абстракции Коад ввел понятие предметной области, состоящей их логически связанных групп классов, относящихся к высокоуровневым функциям системы.

    Анализ характеристик

    В отличие от классических подходов, концентрирующих внимание на материальных элементах предметной области, альтернативные методы объектно-ориентированного анализа сосредоточены на динамических характеристиках как на первоисточнике классов и объектов. Это напоминает концептуальную кластеризацию: классы образуются из групп объектов, демонстрирующих сходное поведение.

    Вирфс-Брок (Wirfs-Brock), Уилкерсон (Wilkerson) и Винер (Wiener), например, делают акцент на обязанностях (responsibilities), под которыми подразумеваются знания объекта и действия, которые он способен выполнять. Обязанности — это средство выражения предназначения объекта и его места в системе. Обязанности объекта представляют собой совокупность всех услуг, которые он может предоставлять согласно договоренностей [Wirfs-Brock, R., Wilkerson, В., and Wiener, L. 1990. Designing Object-Oriented Software. Englewood Cliffs, NJ: Prentice Hall, p. 61.]. Иначе говоря, в группы объединяются объекты, имеющие общие обязанности, а иерархии состоят из классов, связанных с суперклассами, описывающими общие обязанности, и подклассами, уточняющими их поведение.

    Рубин (Rubin) и Голдберг (Goldberg) предлагают идентифицировать классы и объекты, исходя из функций системы. Они предлагают в первую очередь понять, что происходит в системе. Это позволит понять ее функции. Затем эти функции следует сопоставить с частями системы и попытаться понять, кто инициирует функцию и кто участвует в ее реализации. Инициаторы и участники, играющие существенные роли, опознаются как объекты, и на них возлагаются обязанности за выполнение этих ролей [Rubin, К., and Goldberg, A. September 1992. Object Behavior Analysis. Communications of the ACM vol. 35(9), p. 48.].

    Концепция Рубина тесно связана с понятием функциональной точки (functional point), предложенным Албрехом (Albrech) в 1979 году. Согласно его определению, функциональная точка — это отдельное бизнес-действие конечного пользователя [Dreger, B. 1989. Function Point Analysis. Englewood Cliffs, NJ: Prentice Hall, p. 4.], т.е. вывод, запрос, ввод, запись или соединение. Несмотря на то что эта концепция происходит из области информационных систем, она может быть обобщена для любой автоматизированной системы. По существу, функциональная точка — это любое значимое, видимое извне и поддающееся проверке поведение системы.

    Анализ предметной области

    Цель анализа предметной области состоит в идентификации классов и объектов, общих для всех приложений, относящихся к данной сфере знаний, например, ведению историй болезни пациентов, торговле ценными бумагами, разработке компиляторов или систем управления ракетами. С помощью анализа узкой предметной области можно найти основные ключевые абстракции.

    Идею анализа предметной области впервые предложил Нейборс (Neighbors). Он определил анализ предметной области как попытку идентифицировать объекты, операции и отношения, которые эксперты считают наиболее важными [Arango, G. May 1989. Domain Analysis: From Art Form to Engineering Discipline. SIGSOFT Engineering Notes vol. 14(3), p. 153.].

    Мур (Moore) и Байлин (Bailin) выделили следующие этапы анализа предметной области [Moore, J., and Bailin, S. 1988. Position Paper on Domain Analysis. Laurel, MD: СТА, р. 2.]:

  1. Построение модели предметной области в ходе консультаций с экспертами в этой области.
  2. Изучение систем, существующих в данной предметной области, и представление результатов в стандартном виде.
  3. Идентификация сходства и различий между системами при участии экспертов предметной области.
  4. Уточнение обобщенной модели по существующим системам.

    Анализ предметной области можно вести среди аналогичных приложений (вертикальный анализ) или среди аналогичных частей того же самого приложения (горизонтальный анализ). Например, начиная проектирование системы мониторинга состояния пациентов, целесообразно изучить архитектуру существующих аналогов, чтобы понять смысл и оценить полезность основных абстракций и механизмов, использованных в них.

    Аналогично система бухгалтерского учета должна поддерживать разные виды отчетов. Если считать отчеты в рамках конкретного приложения отдельной предметной областью, то их анализ может привести разработчика к идентификации основных абстракций и механизмов, обслуживающих все виды отчетов. Полученные таким образом классы и объекты представляют собой совокупность основных абстракций и механизмов, обобщающих решение исходной задачи. Таким образом, итоговый проект, вероятно, станет проще по сравнению с проектом, построенным на основе анализа отдельных отчетов.

    Часто в роли эксперта выступает обычный пользователь системы, например, инженер или диспетчер железной дороги, а также медсестра или доктор, работающие в больнице. Эксперт не обязан быть программистом. Просто он должен хорошо знать все аспекты исследуемой проблемы и свободно оперировать понятиями из словаря предметной области.

    Для очень сложных систем анализ предметной области является формальным процессом, требующим участия большого количества экспертов и разработчиков в течение длительного периода времени. Такой формальный анализ не обязательно проводить при разработке всех проектов, особенно небольших. Обычно для уточнения задачи достаточно короткой встречи экспертов в предметной области и архитектором или проектировщиком. Анализ прикладной области редко носит целостный характер. Для того чтобы повысить его эффективность, следует осознанно выбрать небольшой фрагмент прикладной области, проанализировать его, принять проектное решение и перейти к исследованию другой части.

    Анализ прецедентов использования

    Метод анализа прецедентов (use case analysis), впервые был формализован Джекобсоном (Jacobson). В работе Джекобсона и его соавторов было сформулировано следующее определение прецедентов использования - последовательность взаимосвязанных операций, выполняемых действующим субъектом в диалоге с системой для достижения некоторой цели, допускающей применение количественного критерия успеха [Jacobson, I., Ericsson, M., and Jacobson, A. 1994. The Object Advantage: Business Process Reengineering with Object Technology. Wokingham, England: Addison-Wesley.].

    Анализ прецедентов использования можно применять на этапе изучения требований, когда конечные пользователи, другие эксперты предметной области и группа разработчиков перечисляют сценарии, наиболее важные для функционирования системы. В совокупности эти сценарии описывают все функции приложения. Затем каждый сценарий тщательно исследуется. Иногда для этого их раскладывают на эпизоды [Zahniseer, R. July/August 1990. Building Software in Groups. American Programmer vol. 3(7-8).]. Изучая сценарий, группа должна идентифицировать объекты, участвующие в сценарии, а также определить их обязанности и способы взаимодействия в терминах выполняемых операций. Таким образом, группа разработчиков вынуждена четко разделить сферы влияния всех абстракций. По мере развития процесса проектирования группа расширяет набор первоначальных сценариев, вводя новые абстракции или добавляя, модифицируя и перераспределяя обязанности между существующими абстракциями. Кроме того, сценарии служат основой для тестирования систем.

    CRC-карточки

    CRC-карточки (аббревиатура CRC означает Class/Responsibilities/Collaborators (Класс/Обязанности/Сотрудники)) — это простой и эффективный метод анализа сценариев. CRC-карточки, которые впервые предложили использовать Бек (Beck) и Каннингхэм (Cminingham) как средство обучения объектно-ориентированному программированию [Beck, K., and Cunningham, W. October 1989. A Laboratory for Teaching Object-Oriented Thinking. SIGPLAN Notices vol. 24(10).], оказались полезным инструментом для проведения мозговых штурмов и улучшения взаимодействия между разработчиками. CRC- карточка представляет собой обычные библиографические карточки, на которых аналитик сверху пишет карандашом имя класса, на одной половине — обязанности класса, а на другой — его сотрудников. На каждый класс, участвующий в сценарии, заводится отдельная карточка. Анализируя сценарий, проектировщики могут поручать новые обязанности существующим классам, группировать новые обязанности в новых классах, а также (чаще всего) разделять обязанности одного класса среди более мелких или делегировать их другому классу.

    CRC-карточки можно упорядочивать так, чтобы представлять шаблоны взаимодействия. С точки зрения динамической семантики сценария, карточки позволяют демонстрировать потоки сообщений между прототипами экземпляров каждого класса, а с точки зрения статической семантики они представляют иерархии классов, связанных отношениями обобщения/специализации или агрегации.

    Неформальное описание

    Радикальная альтернатива классическому объектно-ориентированному анализу была выдвинута Эбботтом (Abbott), предложившим описывать задачу (или ее часть) на английском языке, а затем подчеркивать существительные и глаголы [Abbott, R. November 1983. Program Design by Informal English Descriptions. Communications of the ACM vol. 26(11).]. Существительные являются кандидатами на роль классов, а глаголы — на роль операций.

    Подход Эбботта полезен, так как он прост и стимулирует разработчика работать со словарем предметной области. Однако этот метод не имеет средств для строгого анализа и совершенно непригоден для решения сложных проблем.

    Человеческий язык — весьма неточное средство выражения мыслей, потому качество итогового списка объектов и операций зависит от писательского таланта разработчика. Более того, любое существительное имеет соответствующую глагольную форму и наоборот, следовательно, список кандидатов может быть смещен в сторону объектов или операций.

    Структурный анализ

    Многие организации пытались использовать в качестве основного инструмента объектно-ориентированного проектирования структурный анализ. Этот подход кажется привлекательным уже хотя бы потому, что много аналитиков имеют опыт структурного анализа, и существует большое количество программных CASE-средств, поддерживающих автоматизацию этих методов. Структурный анализ начинается с создания принципиальной схемы системы, описанной диаграммами потоков данных и другими средствами структурного анализа. Эти диаграммы позволяют создать формальную модель проблемы. Основываясь на этой модели, можно идентифицировать классы и объекты, относящиеся к предметной области, используя один из следующих трех методов.

    Макменамин (McMenamin) и Палмер (Palmer) предлагают начинать структурный анализ с изучения словаря данных и анализа контекстных диаграмм модели. Рассматривая список основных элементов данных, следует подумать, о чем они говорят или что описывают. Например, если в предложение входят прилагательные, то к каким существительным они относятся? Ответы на эти вопросы помогут заполнить список кандидатов на роль объектов [McMenamin, S., and Palmer, J. 1984. Essential Systems Analysis. New York, NY: Yourdon Press, p. 267.]. Эти кандидаты на роль объектов происходят из окружающей среды, из основных входных и выходных данных, а также продуктов, услуг и других ресурсов системы.

    Следующие два способа основаны на анализе отдельных диаграмм потоков данных. По отдельной диаграмме потоков данных (в терминологии Уарда (Ward) и Меллора (Mellor) [Ward, P., and Mellor, S. 1985. Structured Development for Real-Time Systems. Englewood Cliffs, NJ: Yourdon Press.]) кандидаты на роль объектов можно найти среди следующих сущностей:

Источники кандидатов в классы перечислены ниже:

    Преобразования данных можно рассматривать либо как операции, либо как существующие объекты, либо как характеристики объектов, создаваемых специально для выполнения этих преобразований.

    Зайдевиц (Seidewitz) и Старк (Stark) предложили другой метод, который они назвали анализом абстракций (abstraction analysis). Этот метод предназначен для идентификации основных сущностей, которые по своей природе аналогичны основным преобразованиям в структурном проектировании. В структурном анализе входные и выходные данные изучаются до тех пор, пока не достигнут высшего уровня абстракции. Основными преобразованиями считаются процессы переработки входных данных в выходные. В анализе абстракций разработчик делает то же самое, но, кроме этого, он изучает основное преобразование для того, чтобы определить, какие процессы и состояния образуют наилучшую абстрактную модель системы [Seidewitz, E., and Stark, M. August 1986. General Object-Oriented Software Development. Report SEL-86-002. Greenbelt, MD: NASA Goddard Space Flight Center, p. 5-2.].

    После идентификации основной сущности в конкретной диаграмме потоков данных аналитик приступает к изучению всех остальных сущностей, прослеживая входящие и исходящие из центра потоки данных, группируя процессы и состояния, встречающиеся по пути. Зайдевиц и Старк пришли к выводу, что анализ абстракций слишком сложен для успешного практического применения и в качестве альтернативы предложили объектно-ориентированный анализ.

    Необходимо подчеркнуть, что принципы структурного проектирования, которое, как правило, сочетается со структурным анализом, полностью ортогональны принципам объектно-ориентированного проектирования. Опыт показывает, что использование структурного анализа в процессе объектно-ориентированного проектирования часто приводит к полному провалу, если разработчик не способен сопротивляться соблазну структурного проектирования. Другая очень серьезная опасность заключается в том, что многие аналитики любят рисовать диаграммы потоков данных, представляющие собой скорее описание проекта, а не сущностную модель задачи. Чрезвычайно трудно построить объектно- ориентированную систему на основе модели, столь сильно ориентированной на алгоритмическую декомпозицию. По этой причине для объектно-ориентированного проектирования более предпочтительным является объектно-ориентированный анализ, позволяющий уменьшить риск испортить проект надуманными элементами алгоритмического анализа.

    Если по каким-либо причинам разработчик вынужден использовать структурный анализ, необходимо немедленно прекратить создание диаграмм, как только они начинают напоминать проект, а не сущностную модель.

    Кроме того, как только проектирование зайдет достаточно далеко, следует отказаться от методов структурного анализа. Средства проектирования, такие как диаграммы потоков данных, — это не конечный продукт, а инструменты, с помощью которых разработчики выражают свое понимание задачи и способы ее решения. Обычно проектировщики рисуют диаграммы, а затем изобретают механизмы реализации требуемого поведения системы.

    Следовательно, следует применять только средства структурного анализа, относящиеся к достаточно высокому уровню абстракции. Именно они позволяют адекватно описать сущностную модель задачи и, благодаря этому, применяются во многих проектах.

    На следующем шаге рассмотрим основные абстракции и их идентификацию.




Предыдущий шаг Содержание Следующий шаг