ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 22.04.2024

Просмотров: 337

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

 

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

 

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

74

2.

Определяются действия, выполняемые при реализации ролей.

 

3.

Обязанности объединяются в контракты, определяющие набор запросов, кото-

 

рые объекты могут поддерживать.

 

4.

Контракты уточняются путѐм создания протоколов, в которых определяются ар-

 

гументы и возвращаемые значения.

 

Для описания классов или подсистем используются CRC-карты (Class – Responsibility – Collaboration). CRC-карты – удобное средство в процессе определения атрибутов и операций, а также для моделирования отношений. Они представляют собой небольшие карточки размером 4х6 см, в верхней части которой записывается имя класса, справа – ответственности, слева – сотрудничество (рис. 4-13).

Рис. 4-13. Пример

CRC-карты для класса Заказ

Ответственность (Responsibility) – высокоуровневое описание выполняемых классом операций.

Сотрудничество (Collaborations) – показывает классы, которые должны кооперироваться с данным классом для реализации операций.

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

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

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

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

4.5.2. Метод Коада/Йордона – OOA/D

Этот метод представляет систему в виде многоуровневой модели. Выделяется пять уровней анализа:

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


 

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

 

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

75

1.

Уровень объектов-классов.

 

2.

Уровень атрибутов.

 

3.

Уровень служб.

 

4.

Структурный уровень.

 

5.

Уровень тематических групп.

 

К пяти уровням анализа добавляется четыре компонента проектирования, каждый из которых включает те же пять уровней анализа:

1.Компонент предметной области (Problem Domain – PD).

2.Компонент взаимодействия с человеком (Human Interaction – HI).

3.Компонент взаимодействия систем (System Interaction – SI).

4.Компонент управления данными (Data Management – DM).

Компоненты модели используются для разбиения классов на осмысленные свободно соединяемые подмножества.

Каждый класс в точности соответствует одному из компонентов модели: HI, PD, DM, SI (§ 3.3). Такая организация классов упрощает моделирование (в рамках каждого компонента), а также повышает вероятность их повторного использования.

Разработка модели состоит из пяти основных этапов:

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

2.Идентификация структур, определяющих два типа отношений между класса-

ми: общее – частное и целое – часть.

3.Выделение субъектов системы – групп классов и объектов, объединѐнных по принципу облегчения понимания модели.

4.Определение атрибутов – для каждого объекта определяются характеризующие его сведения (что знает объект о себе самом).

5.Определение операций (что делает для других объектов и для себя самого).

Основной акцент метода ставится на информационную структуру ПС. Несомненным достоинством метода является простая нотация и лѐгкость освоения для людей, не имеющих большого опыта в объектно-ориентированном подходе. Существуют также стратегии, шаблоны и образцы для построения объектных моделей Питера Коада (Piter Coad), Дэвида Норта (David North) и Марка Мейфилда (Mark Mayfield). Нотация метода отличается от UML-нотации, однако, между ними имеется малосущественная разница.

4.6. Объектная методология – Object Methodology

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

Объектная методология:

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


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

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

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

Базируется на трѐх связанных, но различных точках зрения, каждая из которых фиксирует статику и динамику ПС, а также потоки данных.

Предполагает существование методов и приѐмов, связанных с понятием объ-

екта.

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

Критерии для оценки моделей:

Однозначность. Отсутствие двусмысленности.

Абстрактность. Устранение избыточных деталей.

Согласованность. Отсутствие противоречивости.

4.6.1. Объектная модель

Объектная модель показывает статику ПС и используется для описания его структуры, представляя элементы посредством диаграмм объектов и диаграмм классов.

Общая (независимая от конкретных данных) концепция объектной модели представлена метамоделью (рис. 4-14).

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

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

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

77

 

Рис. 4-14. Метамодель объектной модели

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

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

Пояснения к метамодели:

1.Объект должен принадлежать классу.

2.Значение атрибута существует только для объекта.

3.Связь существует только между объектами.

4.Описание существует только для класса, без него он не может существовать.

5.Ассоциация существует только между классами.

6.Роли ассоциации принадлежат классу, иначе они не могут существовать.

7.Атрибуты ассоциации принадлежат классу, иначе они не могут существовать.

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


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

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

78

При создании объектной модели важно знать и учитывать следующие факторы:

 

1.Объекты имеют идентичность в описании свойств и поведения, которыми они обладают. Объекты различаются конкретными значениями свойств и присущим им конкретным поведением.

2.Объекты класса должны обладать не только общими атрибутами и общими операциями, но и общей семантикой.

3.Атрибуты класса имеют свои значения для каждого объекта.

4.Для описания класса следует использовать самые существенные и характерные для объектов атрибуты и операции.

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

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

7.Каждая ассоциация в диаграмме классов соответствует набору однотипных связей между объектами этих классов.

8.Атрибуты ассоциации – это свойства связей в ассоциации.

9.Роль – это один конец ассоциации. Бинарная ассоциация имеет две роли, каждая из которых может иметь имя роли. Имя роли – это уникальное название, которое опознаѐт один конец ассоциации.

10.Обобщение – это отношение между классами типа is a. Общая сущность, которую называют суперклассом, связана отношением с уточняющей еѐ разновидностью, называемой подклассом. Обобщение характеризуется дискриминатором. Дискриминатор (discriminator) показывает признак, указывающий на свойство объектов, по которому сделано обобщение.

11.Агрегация – отношение между классами типа part of или has (целое-часть). Различают две формы: агрегация и композиция. Агрегация позволяет отличить целое от части и не накладывает никаких ограничений на соотношение времѐн жизни целого и его частей. Композиция – это форма агрегации с чѐтко выраженным отношением владения, причѐм время жизни целого и его частей совпадают. Целое в композиции управляет созданием и уничтожением своих частей.

12.Ассоциация может иметь: мощность (количество объектов-участников), упорядочение (сортировка объектов-участников) и квалификатор. Квалификатор (qualifier) – это значение, выбирающее уникальный объект из группы объектов, которые связаны с ним в ассоциации. Квалификатор позволяет снизить мощность ассоциаций один–ко–многим, многие–ко–многим.

13.В ассоциации между двумя классами сама ассоциация может иметь свойства. В этом случае говорят о классе ассоциации.

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


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

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

79

4.6.2. Процедура моделирования

 

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

При построении объектной модели ПС необходимо выполнить следующие шаги:

1.Выделить классы и объекты на выбранном уровне абстракции.

2.Подготовить словарь данных – выяснить семантику объектов и классов.

3.Идентифицировать связи между объектами и отношения между классами (включая агрегацию).

4.Определить атрибуты и операции классов (спецификации интерфейсов).

5.Упростить классы, используя обобщение.

6.Проверить существование путей доступа для вероятных запросов.

7.Выполнить итерации и совершенствование модели.

8.Сгруппировать классы в пакеты.

Гради Буч называет процедуру моделирования объектно-ориентированной разработки ПС микропроцессом, где традиционные этапы жизненного цикла умышленно перемешаны. Ежедневно разработчиками производится анализ, проектирование, программирование и тестирование на выбранном уровне абстракции. Именно микропроцесс является основой для развития архитектуры ПС. Из множества альтернативных решений, полученных в микропроцессе разработки, складывается окончательное решение, которое и обеспечивает успех или провал всего проекта.

5. ЖИЗНЕННЫЙ ЦИКЛ

Жизненный цикл (software life cycle) – это совокупность процессов (software process), которая связана с последовательным изменением состояния программного обеспечения от формирования исходных требований к нему до полного изъятия его из эксплуатации.

На рис. 5-1 показаны процессы жизненного цикла, рекомендуемые международным стандартом ISO 12207. Этот стандарт определяет действия, которые могут быть выполнены на протяжении жизненного цикла программного обеспечения.

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