Методы анализа

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

Метод Coad-Yourdon первоначально был направлен на воплощение идей структурного анализа. Он включает в себя пять этапов: поиск классов и объектов, исходя из предметной области и на основе анализа функций системы, идентификация структур путем поиска отношений " обобщение -специализация" и "общее-частное", определение "субъектов" (групп класс - объект), определение атрибутов; определение сервисов.

Метод OMT (Object Modeling Technique) объединяет концепции объектной технологии и моделирования, основываясь на понятии "сущность- отношение " (entity-relation). Метод включает статическую и динамическую модели. Статическая модель базируется на концепциях класса, атрибута, операции, отношения и агрегирования, динамическая - на основе диаграмм "событие-состояние" позволяет дать абстрактное описание предполагаемого поведения системы.

Метод Shlaer-Mellor изначально ориентирован на создание моделей, допускающих проверку поведения системы, независимо от конкретного проектирования и реализации. Для этого в исходной проблеме выделяются области, задающие различные аспекты: предметная, сервиса (интерфейс пользователя), архитектурная, реализации. Отдельные решения затем связываются воедино для создания завершенной системы.

Наличие в Shlaer-Mellor и ряде методов моделирования элементов архитектуры, проектирования и реализации иллюстрирует высказанную ранее мысль о том, что амбиции методов часто выходят за рамки анализа.

Метод Martin-Odell, известный также как OOIE (Object-Oriented Information Engineering), разделяется на две части. В первой части анализируется объектная структура, идентифицируются типы объектов, их состав, отношения наследования. Вторая часть анализирует поведение объектов, определяемое динамической моделью, учитывающей состояния объектов и события, которые могут изменить эти состояния.

Метод Booch использует логическую модель (класс и объектная структура) и физическую модель (модуль и архитектура процесса), включая как статические, так и динамические компоненты, в ней применяются многочисленные графические символы. Планируется его включение в язык анализа UML (Unified Modeling Language) (см. ниже).

Метод OOSE (Object-Oriented Software Engineering), также известный как метод Jacobson или как Objectory (название оригинального средства поддержки), основан на использовании сценариев для выявления классов. Рассматривается пять моделей сценариев: доменная модель исходной области приложения и четыре модели этапов разработки - анализа, проектирования, реализации, тестирования.

Метод OSA (for Object-oriented Systems Analysis) предназначен скорее для создания общей модели процесса анализа, а не пошаговой процедуры. Он состоит из трех частей: модели объектных отношений, описывающей объекты, классы и их отношения друг с другом и с "реальным миром", модели объектного поведения, обеспечивающей динамическое представление через состояния, переходы, события, действия и исключения и модели объектного взаимодействия, определяющей возможные взаимодействия между объектами. Метод также поддерживает понятия представления, обобщения и специализации, которые используются для описания взаимодействия и моделей поведения.

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

Метод Syntropy определяет три модели. Наиболее важная модель - "модель реальной или воображаемой ситуации", описывающая элементы ситуации, их структуру и поведение. Модель спецификации - абстрактная модель, рассматривающая систему как механизм реакции на воздействия, располагающий неограниченными аппаратными ресурсами. Модель реализации принимает во внимание реальную вычислительную среду. Предусмотрены различные способы представления каждой модели: описание типов объекта и их статических свойств, диаграммы состояний, подобные диаграммам переходов в OMT для описания динамики поведения, диаграммы механизмов для реализации. Метод поддерживает описание одних и тех же объектов с помощью различных интерфейсов, не ограничиваясь простым разделением интерфейса и реализации.

Метод MOSES включает пять моделей: объект - класс, событие для описания сообщений, инициируемых в результате вызова сервисов объекта, "объектные диаграммы" для моделирования динамики изменения состояния, наследование, сервисную структуру для отображения потока данных. Подобно рассматриваемому ниже методу BON, в методе MOSES подчеркивается важность контрактов в определении класса и используются предусловия, постусловия и инварианты в стиле данной книги. Его модель "фонтанирующего процесса" определяет стандартные документы, создаваемые на каждой стадии.

Метод SOMA (Semantic Object Modeling Approach) использует "Объектную Модель Задачи ", чтобы сформулировать требования и преобразовать их в "Деловую Объектную Модель". Это одна из немногих попыток извлечения выгоды из формальных подходов, использующая понятие контракта для описания деловых правил, применимых к объектам.

Во время написания книги, разрабатывались два самостоятельных проекта объединения существующих методов. Первый (Brian Henderson-Sellers, Don Firesmith, Ian Graham и Jim Odell) направлен на создание объединенного метода OPEN. Целью второго проекта Rational Corporation является разработка UML (унифицированного языка моделирования), используя в качестве отправной точки методы OMT, Booch и Jacobson.

Нотация BON (Business Object Notation)

Каждый из рассмотренных подходов имеет свои сильные стороны. Метод Business Object Notation (BON), предложенный Nerson и Walden, при минимальной сложности обеспечивает максимальные преимущества и может служить примером комплексного подхода к OO-анализу. Данный краткий обзор основных особенностей метода огранивается обсуждением его вклада в анализ. Для более подробного знакомства можно рекомендовать указанную в библиографии монографию.

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

Метод BON основан на трех принципах: бесшовность, обратимость и контрактность. Бесшовность - непрерывность процесса на протяжении всего жизненного цикла ПО. Обратимость - поддержка прямого и обратного процессов разработки: от анализа к проектированию и реализации и наоборот. Контрактность (вспомните о Проектировании по Контракту) - точное определение семантических свойств каждого программного элемента. BON - практически единственный популярный метод анализа, использующий развитый механизм утверждений, что позволяет аналитикам определить не только структуру системы, но и ее семантику (ограничения, инварианты, свойства ожидаемых результатов).

Ряд других свойств выделяют BON среди OO-методов:

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

· Метод BON был создан в 1990-е годы. В нем изначально предполагается, что в распоряжении его пользователей будут вычислительные ресурсы, а не только бумага и карандаш или доска. Это позволяет использовать мощные инструментальные средства для отображения комплексной информации. Такие средства описаны в последней лекции этой книги. Для небольших задач вполне достаточно карандаша и бумаги.

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

Поддержка больших систем в BON основана в частности на понятии кластера - группы логически связанных классов. Кластеры могут содержать субкластеры, тем самым формируется вложенная структура и аналитики получают возможность работы на различных уровнях. Некоторые кластеры могут быть библиотеками - серьезное внимание уделяется повторному использованию.

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

BON поддерживает несколько вариантов формальных описаний: текстовую нотацию, табличную форму и графические диаграммы.

Текстовая нотация аналогична принятой в этой книге. Поскольку не подразумевается непосредственная компиляция, можно использовать ряд расширений в области утверждений. Например, delta a означает, что компонент может изменить атрибут a, forall и exists применяются для логических формул исчисления предикатов первого порядка, а member_of - для операций с множествами.

Таблица удобна для сжатого описания свойства класса. Общая форма табличного представления класса приведена ниже.

Таблица 9.1. Таблица описания класса в методе BON
CLASS	Class_name	Part:
Short description (Краткое описание)	Indexing information (Индексирующая информация)
Inherits from (Наследует от)
Queries (Запросы)
Commands (Команды)
Constraints (Ограничения)

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

Рис. 9.4. Основные графические обозначения BON ([Walden 1995], приведено с разрешения автора)

Процесс анализа и разработки состоит из семи задач. Порядок их решения соответствует идеальному процессу. В реальной практике его можно изменить и использовать итерации в соответствии с концепцией обратимости. Стандартными являются задачи:

· B1 Определение границ системы: что будет включено и не включено в систему, главные подсистемы, пользовательские метафоры, функциональность, библиотеки повторного использования.

· B2 Составление списка классов-кандидатов, в который вначале включают классы, имеющие отношение к данной области.

· B3 Выбор классов и формирование кластеров: объединение классов в логические группы, выделение абстрактных, перманентных классов и т. д.

· B4 Определение классов: развернутое описание классов в терминах запросов, команд и ограничений.

· B5 Составление эскиза поведения системы: определение схем создания объектов, событий и сценариев.

· B6 Определение общедоступных компонентов: завершение интерфейсов классов.

· B7 Совершенствование системы.

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

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

Дата добавления: 2014-12-07