Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 69

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

Для защиты от несанкционированного доступа клиента объект-поставщик должен сам об этом позаботиться (самостоятельно проявлять инициативу в нужный мо-

мент). Принцип Голливуда гласит: “Не звоните нам, мы сами с Вами свяжемся”.

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

4.3.4. Иерархия – Hierarchy

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

Классификацией является создание иерархий с наследованием.

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

Основными видами иерархии сложных систем являются:

−Иерархия по составу, которая определяет структуру объектов и использует отношение типа part of, has (целое-часть).

−Иерархия по типу, которая определяет структуру классов и использует отношение обобщения is – a (является).

4.3.5. Согласованность – Seamlessness

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

Модели реализации создаются на базе моделей проектирования. Модели проектирования – на базе моделей анализа. Это называется трассируемость (traceability).

Модели анализа могут быть непосредственно подвергнуты сравнению с моделями реализации – свойство обратимости (reversibility).

Трассируемость и обратимость гарантируют согласованное изменение моделей в прямом и обратном направлениях.

4.4. Модели системы

Физическая модель тесно связана с тремя моделями: статической, динамической и функциональной (рис. 4-12). Три перечисленные модели делят ПС на ортогональ-

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 70

ные, но взаимосвязанные, представления, каждое из которых описывает один аспект системы и содержит ссылки на другие модели.

Статическая модель обеспечивает необходимую основу ПС. Эта модель определяет исходную структуру работы динамической и функциональной моделей.

Рис. 4-12. Модели системы

В конце проектирования три модели дают реализацию (физическую модель), которая включает данные (статическая модель), упорядочение (динамическая модель) и методы (функциональная модель).

4.4.1. Статическая модель системы

Статическая модель системы отражает наличие и расположение классов и компонентов системы.

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

Статическая модель тесно связана с динамической и функциональной моделями.

4.4.2. Динамическая модель системы

Динамическая модель представляет аспекты управления системой, временнЫе аспекты и поведение системы.

Как правило, динамика системы проектируется вместе с еѐ статикой. Она может строиться и после того, как построена и согласована статическая модель, в которой уже распределены обязанности между классами.

В динамической модели:

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

−где они работают (статическая модель),

−что эти операции делают (функциональная модель),

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

2.Фиксируются изменения, происходящие с объектами, для чего создаются диаграммы состояний для классов.

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

Главные концепции динамического моделирования – события (внешние стимулы), и состояния (значения и связи с объектом).

4.4.3. Функциональная модель системы

Функциональная модель показывает различные производимые классами операции (вычисления) и функциональную структуру данных.

Функциональная модель содержит четыре компонента:

1.Операции – преобразование данных.

2.Участники операций – производители и потребители значений.

3.Хранилища данных – создатели задержки между созданием и использованием данных.

4.Потоки данных – отношения между операциями, участниками и хранилищами данных.

Для операций могут быть построены UML-диаграммы деятельностей.

Хранилища данных и потоки данных, отношения между значениями при вычислении моделируют в диаграммах потоков данных3 (Data Flow Diagram). Эти диаграммы показывают потоки значений от внешних входов через операции и внутренние хранилища данных к внешним выходам.

4.4.4. Физическая модель системы

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

Элементы реализации специфицируются в UML-диаграммах классов, компонентов и развѐртывания.

4.4.5. Статическая и динамическая модели

Динамическая модель определяет:

3 Диаграммы потоков данных – предмет изучения дисциплины Базы данных

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения

−Допустимую последовательность изменения состояний объекта класса (из72 статической модели). В динамической модели состояния связаны со значениями атрибутов и конкретными связями объекта. Если имеют место существенные различия в состояниях объектов выделенного класса, то объекты следует моделировать как разные классы.

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

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

4.4.6. Статическая и функциональная модели

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

1.Операции в функциональной модели показывают то, что должно быть реализовано в методах.

2.Участники – это объекты из статической модели, которые связаны по операции. Как правило, один входной объект является поставщиком (сервером) и один выходной объект является потребителем (клиентом). Другие входные объекты – это параметры операции.

3.Хранилища данных – это структуры данных для хранения значений атрибутов объектов из статической модели.

4.Потоки данных – это движение значений атрибутов из статической модели:

−Движение к участникам – это операции над объектами (например, модификаторы, запросы).

−Движение от участников – это операции с объектами (например, преобразование объектов, возврат значений).

−Движение к хранилищу – это запросы к хранилищу на получение данных.

−Движение от хранилища данных – это получение данных из хранилища и, как правило, модификация данных.

4.4.7. Динамическая и функциональная модели

Взаимодействие между этими двумя моделями заключается в следующем:

−динамическая модель определяет операции (без рассмотрения того, как они будут выполняться) и рассматривает состояния, когда операции выполнены;

−функциональная модель определяет то, как выполнить операции, и какие параметры для этого необходимы.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 73

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

4.5. Методы проектирования

Почти все методы проектирования имели оригинальные графические нотации, и нашли поддержку в виде CASE-средств. Попытка унификации привела к появлению UML, при создании которого авторы соединили идеи трѐх методов:

1.OMT (Object Modeling Technique) – технология объектного моделирования, разработанная в 1991 году Джеймсом Рамбо (James Rumbaugh) в научноисследовательском центре General Electric.

2.Booch’93 – метод визуального моделирования Гради Буча (Grady Booch).

3.OOSE (Object-Oriented Software Engineering) – метод, известный под названием Objectory, Ивара Якобсона (Ivar Jacobson), 1992 год.

По сложившейся практике, наряду со смысловыми названиями (или вместо них), методы получали имена своих создателей. Среди них:

–CRC (Class – Responsibility – Collaborations) – Класс – Ответственность – Со-

трудничество. Метод создан в 1989 году. Разработчики метода: Уорд Кан-

нингхем (Cunningham) и Кент Бек (Beck).

–RDD (Responsibility-Driven Design) – Проектирование по обязательствам. Ме-

тод в 1989 году разработан Ребеккой Вирс-Брок (Wirfs-Brock).

–OOA/D (Object-Oriented Analysis and Design) – Объектно-ориентированный анализ и проектирование. Авторы Питер Коад (Coad), Эдвард Йордон (Yourdon) создали метод в 1991 году и развили в 1996 году.

–Shlaer/Mellor (Object-Oriented Systems Analysis and Recursive Design) – Рекур-

сивное проектирование. Авторы метода: Салли Шлаер и Стивен Меллор.

Внастоящее время наиболее естественным является применение набора моделей, созданных с помощью UML, так как этот язык стандартизирован, широко используется и постоянно развивается.

4.5.1. Проектирование по обязательствам – CRC-cards

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

Для каждого класса:

1. Определяются обязанности и роли, которые играют объекты этого класса.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011