ТРПО-лекции

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

	Технология разработки программного обеспечения	71
	− как они реализованы (физическая модель).
	При использовании UML временнЫе аспекты отображаются диаграммами по-
	следовательностей.

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

		Скачано с сайта 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

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

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

Рис. 5-1.

цессы жизненного цикла по стандарту ISO 12207

5.1. Основные процессы жизненного цикла

Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает программный продукт.

Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя программным продуктом.

Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного обеспечения и программный продукт.

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

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

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