Объектно-ориентированные методы анализа

Важное место в разработках АСУП занимают объектно-ориенти­рованные методологии, основанные на объектной декомпозиции предметной области, представляемой в виде совокупности объек­тов, взаимодействующих между собой посредством передачи сооб­щений. Данный подход не является противопоставлением структур­ному подходу, более того, фрагменты методологий структурного анализа (а именно его базовые модели: DFD, ERD и STD) исполь­зуются при объектно-ориентированном анализе для моделирования структуры и поведения самих объектов.

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

Объекты и классы организуются с использованием следующих принципов:

1. Принцип инкапсуляции (упрятывания информации) деклари­рует запрещение любого доступа к атрибутам объекта, кроме как через его операции. В соответствии с этим внутренняя структура объек­та скрыта от пользователя, а любое его действие инициируется вне­шним сообщением, вызывающим выполнение соответствующей операции.

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

3. Принцип полиморфизма декларирует возможность работы с объектом без информации о конкретном классе, экземпляром ко­торого он является. Каждый объект может выбирать операцию на основании типов данных, принимаемых в сообщении, т. е. реагиро­вать индивидуально на это (одно и то же для различных объектов) сообщение.

Таким образом, объектно-ориентированный подход заключает­ся в представлении моделируемой системы в виде совокупности классов и объектов предметной области. При этом иерархический характер сложной системы отражается с использованием иерархии классов, а ее функционирование рассматривается как взаимодей­ствие объектов. Жизненный цикл такого подхода содержит этапы анализа требований, проектирования, эволюции (объединяющей программирование, тестирование и отладку, а также комплексацию системы) и модификации. При этом в отличие от каскадной модели отсутствует строгая последовательность выполнения пере­численных этапов.

Известные объектно-ориентированные методологии базируются на интегрированных моделях трех типов:

• объектной модели, отражающей иерархию классов, связан­ных общностью структуры и поведения и отражающих специ­фику атрибутов и операций каждого из них (при этом одной из базовых нотаций объектной модели является диалект ERD);

• динамической модели, отражающей временные аспекты и пос­ледовательность операций (при этом достаточно часто исполь­зуется STD);

• функциональной модели, описывающей потоки данных (с ис­пользованием DFD).

В табл. 5 приведены оценки объемов продаж объектно-ориентиро­ванных методологий поданным International Data Corp. на 1995 г.

Главными недостатками перечисленных объектно-ориентирован­ных методологий являются следующие:

• отсутствие стандартизации в рассматриваемой области про­граммотехники (конкретно, для представления объектов и взаимосвязей между ними);

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

Для преодоления этих недостатков авторы известных методоло­гий Буч (Booch), Рамбо (Rumbaugh) и Якобсон (Jacobson) объединились с целью выработки унифицированной методологии, полу­чившей название UML (Unified Modeling Language). При создании UML его авторы руководствовались целями ускорения эволюции наиболее популярных методологий в направлении сближения их друг с другом, обобщения накопленного опыта их использования, обес­печения стабильности проектов на основе единого целостного метода.

В UML используются следующие ключевые диаграммы:

• диаграмма классов, демонстрирующая статическую структуру системы, ее содержимое — классы, объекты и отношения между ними;

• диаграмма прецедентов, моделирующая набор действующих субъектов (акторов) и прецедентов использования, с помо­щью которых они взаимодействуют;

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

• диаграмма состояний, моделирующая изменения (переходы) состояний вследствие взаимодействия конкретного объекта с другими объектами (т. е. в отличие от диаграммы взаимо­действий описывает состояния только одного класса или объекта);

• диаграмма компонентов, описывающая модули системы, в ко­торых определены классы;

• диаграмма применения (развертывания), моделирующая схе­му расположения процессоров и устройств, задействованных в реализации системы, а также маршрутов передачи инфор­мации между ними.

При этом первые четыре диаграммы являются логическими пред­ставлениями разрабатываемой системы, а последние две — отража­ют ее физическое представление.

Разработка технического задания

После построения модели, содержащей требования к будущей системе, на ее основе осуществляется разработка Технического за­дания на создание системы, включающего в себя:

• требования к автоматизированным рабочим местам, их соста­ву и структуре, а также способам и схемам информационного взаимодействия между ними;

• разработку требований к техническим средствам;

• разработку требований к программным средствам;

• разработку топологии, состава и структуры локальной вычис­лительной сети;

•требования к этапам и срокам выполнения работ. Рассмотрим основные виды работ, которые необходимо выпол­нить, прежде чем приступить к проектированию (созданию проекта на разработку или адаптацию).

1) Обозначение границ реализации. Практически любая система может быть разбита на части, отражающие четыре основных типа реализации систем: ручную, пакетную, диалоговую, реального вре­мени. Из этих четырех типов первый реализуется людьми, осталь­ные три являются автоматическими реализациями системы. Рас­смотрим критерии, с помощью которых устанавливаются наибо­лее приемлемые типы реализации требований для частей модели.

Ручная реализация имеет три основных преимущества перед ав­томатической. Во-первых, не требуется заранее точно определять процессы. По крайней мере, они могут определяться не так тща­тельно, как при автоматической реализации: люди хорошо знают как заполнить пробелы в спецификации. Во-вторых, ручная систе­ма может откликаться на неожидаемые запросы, а не только на заранее планируемые. Например, ручная система бронирования авиабилетов может ответить на запрос о возможности парковки автомобиля около аэропорта. В-третьих, система может быть реа­лизована в окружении, где автоматизация невозможна по ряду причин, например психологических: хотя процесс предоставления ссуды и возможно полностью автоматизировать, люди не могут примириться с тем, что их прошения беспристрастно отклонены машиной. Безусловно, ручные системы имеют и массу недостатков. В отличие от машин люди болеют, увольняются, требуют повыше­ния зарплаты. Однако наиболее важно, что размер и сложность ручной системы будут возрастать с увеличением числа запросов, поскольку человек может обрабатывать меньше данных, чем ма­шина.

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

• некоторые запросы требуют длительной работы со срезом базы данных за определенный период (годовой отчет, пересылка накопленной информации и т. п.);

• некоторые отклики (например, отчеты о продажах) содержат большое количество статичных данных, актуальность кото­рых не изменяется в течение дней или даже недель.

Следующий шаг — выделение частей, реализуемых как подсис­темы реального времени. Существует два принципиальных отличия системы реального времени от просто диалоговой системы. Первое из них связано с концептуальным уровнем: в системе реального вре­мени время поступления события в систему само по себе несет оп­ределенную информацию, которая не может быть закодирована. Вто­рое связано с уровнем реализации: время отклика системы реально­го времени является критичным и сопоставимым со скоростью вы­полнения технологических операций. В целом рекомендуется реали­зовать как подсистемы реального времени те части АСУП, из кото­рых должен быть исключен человек, т. е. те части, в которых приори­тетны следующие факторы: скорость (например, противоракетная оборона), опасность (контроль радиоактивности), утомляемость (ра­бота авиадиспетчера).

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

Проектирование

Этап проектирования дает ответ на вопрос: «Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?». Задачей этого этапа является исследование структуры системы и ло­гических взаимосвязей ее элементов, причем здесь не рассматрива­ются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как «(итерационный) процесс получе­ния логической модели системы вместе со строго сформулированны­ми целями, поставленными перед нею, а также написания специфи­каций физической системы, удовлетворяющей этим требованиям». Обычно этот этап разделяют на два подэтапа:

• проектирование архитектуры системы, включающее разработку структуры и интерфейсов компонент, согласование функций и технических требований к компонентам, методам и стан­дартам проектирования;

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

Другими словами, проектирование является этапом ЖЦ, на ко­тором вырабатывается, как реализуются требования к АСУП, по­рожденные и зафиксированные на этапе анализа. В результате этапа должна быть построена модель реализации, демонстрирующая, как система будет удовлетворять предъявленным к ней требованиям (без технических подробностей). Фактически модель реализации являет­ся развитием и уточнением модели требований, а само проектиро­вание является мостом между анализом и реализацией.