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

1
ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
Основы методологии проектирования ПО. Проектирование программ как
сложных систем. Основные положения теории сложных систем_________________3
Жизненный цикл ПО. Модели жизненного цикла ПО. ___________________5
Жизненный цикл ПО ________________________________________________5
Основные процессы ЖЦ ПО __________________________________________6
Вспомогательные процессы ЖЦ ПО ___________________________________8
Организационные процессы ЖЦ ПО ___________________________________9
Модели жизненного цикла ПО ________________________________________9
Методологии и технологии проектирования ПО, общие требования к
методологии и технологии. Методология RAD _______________________________11
Общие требования к методологии и технологии ________________________11
Методология RAD _________________________________________________14
Структурный подход к проектированию ПО. Сущность структурного
подхода. Методология функционального моделирования SADT. Моделирование
потоков данных (процессов). Моделирование данных _________________________16
Сущность структурного подхода _____________________________________17
Методология функционального моделирования SADT ___________________18
Моделирование потоков данных (процессов) ___________________________24
Моделирование данных _____________________________________________28
Пример использования структурного подхода __________________________35
Объектно-ориентированный подход к проектированию ПО. Основные
положения объектной модели. Классы и объекты ____________________________42
Объектно-ориентированная модель ___________________________________42
Классы и объекты __________________________________________________46
Унифицированный язык моделирования UML _________________________50
Диаграммы вариантов использования _________________________________51
Взаимодействие объектов ___________________________________________53
Диаграммы классов ________________________________________________56
Диаграммы состояний ______________________________________________66
Диаграммы компонентов ____________________________________________68
Диаграммы размещения_____________________________________________70
Обзор UML _______________________________________________________72
Программные средства поддержки жизненного цикла ПО. Методологии
проектирования ПО как программные продукты. CASE-средства. Общая
характеристика и классификация __________________________________________73
CASE – средство JAM (методология RAD) _____________________________76
Методология DATARUN и CASE-средство Silverrun ____________________79
Объектно-ориентированные CASE-средства (Rational Rose). Методология
RUP _____________________________________________________________________86
Техническое описание Rational Rose __________________________________86
Структура и функции Rational Rose ___________________________________87
Методология RUP__________________________________________________90
Генерация программного кода с помощью Rational Rose _________________92
Обратное проектирование с помощью Rational Rose _____________________93
Локальные CASE средства (ERwin, BPwin, S-Designor, CASE.Аналитик) __94
Надежность программных средств ____________________________________95
2
Основные понятия надежности систем. ________________________________95
Дестабилизирующие факторы и методы обеспечения надежности
программных средств_____________________________________________________97
Тестирование программного обеспечения _____________________________99
Автоматизация процесса тестирования _______________________________104
Документирование ПО. Обзор отечественных стандартов по составлению
документации на ПО _____________________________________________________105
Коллективные методы разработки программного обеспечения _________108
3
Основы методологии проектирования ПО. Проектирование программ
как сложных систем. Основные положения теории сложных систем
В начале 60-х гг. в США был отмечен кризис программирования. Это выражалось в
том, что большие проекты стали выполняться с отставанием от графика или с
превышением сметы расходов, разработанный продукт не обладал требуемыми
функциональными возможностями, производительность его была низка, качество
получаемого программного обеспечения не устраивало потребителей.
И в настоящее время, как показывают аналитические исследования и обзоры,
выполняемые ведущими зарубежными аналитиками, ситуация не слишком
обнадеживающая. Так, например, в 1995 г. компания Standish Group проанализировала
работу 364 американских корпораций и итоги выполнения более 23 тыс. проектов,
связанных с разработкой ПО, и сделала следующие выводы.
Только 16.2% проектов завершилось в срок, не превысило запланированный
бюджет и реализовало все требуемые функции и возможности; 52.7% проектов
завершились с опозданием, расходы превысили запланированный бюджет, требуемые
функции не были реализованы в полном объеме; 31.1% проектов были аннулированы до
завершения. Для проектов, которые завершились с опозданием или были аннулированы
до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок
выполнения на 122%.
В 1998 г. процентное соотношение проектов лишь немного изменилось в лучшую
сторону (26%, 46% и 28% соответственно).
В числе причин возможных неудач фигурируют: нечеткая и неполная
формулировка требований к ПО, недостаточное вовлечение пользователей в работу над
проектом, отсутствие необходимых ресурсов. Неудовлетворительное планирование,
частое изменение требований и спецификаций, новизна используемой технологии для
организации, отсутствие грамотного управления проектом, недостаточная поддержка со
стороны вышестоящего руководства.
Потребность контролировать процесс разработки ПО, прогнозировать и
гарантировать стоимость разработки, сроки и качество результатов привела в конце 70-х
гг. к необходимости перехода от кустарных к индустриальным способам создания ПО и
появлению «программной инженерии» - совокупности инженерных методов и средств
создания ПО.
Впервые этот термин использовался как тема конференции,
проводившейся под эгидой NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была
проведена первая международная конференция, посвященная программной инженерии.
Тогда же появилось первое издание, посвященное программной инженерии, - IEEE
Transactions on Software Engineering.
В процессе становления и развития программной инженерии можно выделить два
этапа: 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (на
основе структурного подхода) и 90-е гг. – начало перехода к сборочному,
индустриальному способу создания ПО (на основе объектно-ориентированного подхода).
В основе программной инженерии лежит одна фундаментальная идея:
проектирование ПО является формальным процессом, который можно изучать и
совершенствовать. Освоение и правильное применение методов и средств создания ПО
позволяет повысить его качество, обеспечить управляемость процесса проектирования и
увеличить срок жизни ПО.
Причина проблем, возникающих при разработке ПО, в том, что программы
сложны. Причем сложность является самым существенным и неотъемлемым свойством
программных систем.
Известно, что не все программные системы сложны. Существует множество
программ, которые задумываются, разрабатываются, сопровождаются и используются
одним и тем же человеком. Обычно это начинающий программист или профессионал,
работающий изолированно. Нельзя сказать, что все такие системы плохо сделаны или
4
усомниться в квалификации их создателей. Но такие системы имеют, как правило, очень
ограниченную область применения и короткое время жизни. Обычно их лучше заменить
новыми, чем пытаться повторно использовать, переделывать или расширять. Разработка
подобных программ скорее утомительна, чем сложна. так что изучение этого процесса нас
не интересует.
Нас интересует разработка того, что называют промышленными программными
продуктами. Они применяются для решения самых разных задач, имеют большое время
жизни и большое число пользователей. Существенная черта промышленной программы –
уровень сложности. Один разработчик практически не в состоянии охватить все аспекты
такой системы. Грубо говоря, сложность промышленных программных систем превышает
возможности человеческого интеллекта. И сложность подобного рода присуща всем
большим программным системам, т.е. эта сложность неизбежна – с ней можно справиться,
но избавиться от нее нельзя.
Рассмотрим причины, по которым сложность является неотъемлемым свойством
ПО. Это:
- сложность реальной предметной области, из которой исходит заказ на
разработку,
- трудность управления процессом разработки,
- неудовлетворительными способами описания поведения больших дискретных
систем.
Сложность реального мира заключается в том, что проблемы, которые мы
пытаемся решить с помощью ПО, часто содержат сложные элементы, а к
соответствующим
программам
предъявляется
множество
различных,
порой
взаимоисключающих
требований
(удобство,
производительность,
стоимость,
выживаемость и надежность). Дополнительные сложности возникают в результате
изменений требований к ПС уже в процессе разработки.
Трудности управления процессом разработки – сегодня обычными являются ПС,
размер которых исчисляется десятками тысяч или даже миллионами строк на языках
высокого уровня. Ни один человек никогда не сможет полностью понять такую систему.
Поэтому такой объем работ потребует привлечения команды разработчиков, в идеале как
можно меньшей по численности. При этом всегда возникают значительные трудности,
связанные с организацией коллективной разработки. Чем больше разработчиков, тем
сложнее связи между ними и тем сложнее координация. Особенно если участники работ
географически удалены друг от друга.
Проблема описания поведения больших дискретных систем. Большинство систем в
реальном мире – аналоговые. Они являются непрерывными, т.е. небольшие изменения
входных параметров вызовут небольшие изменения выходных. Программные системы
являются дискретными, и каждое событие, внешнее по отношению к программной
системе, может перевести ее в новое состояние, и, более того, переход из одного
состояния в другое не всегда детерминирован.
Предлагается пять общих признаков любой сложной системы:
1.
Сложные системы часто являются иерархическими и состоят из
взаимозависимых подсистем, которые в свою очередь также могут быть
разбиты на подсистемы, и т.д., вплоть до самого низкого уровня;
2.
Выбор, какие компоненты в данной системе считаются элементарными,
относительно произволен и в большой степени оставляется на
усмотрение исследователя;
3.
Внутрикомпонентная связь обычно сильнее, чем связь между
компонентами. Это позволяет определять «высокочастотные»
взаимодействия внутри компонентов от «низкочастотной» динамики
взаимодействия между компонентами;
5
4.
Иерархические системы обычно состоят из немногих типов подсистем,
по-разному скомбинированных и организованных;
5.
Любая работающая система является результатом развития более
простой системы… Сложная система, спроектированная «с нуля»
никогда не заработает. Следует начать с работающей простой системы.
Так как программные системы являются сложными, то им присущи все эти
свойства.
Для преодоления сложности ПС и, тем самым, успешной реализации проекта,
объект проектирования должен быть прежде всего адекватно описан, т.е. должны быть
построены полные и непротиворечивые модели архитектуры ПО, обуславливающей
совокупность структурных элементов системы и связей между ними, поведение элементов
системы в процессе их взаимодействия, а также иерархию подсистем, объединяющих
структурные элементы.
Под моделью понимается полное описание системы ПО с определенной точки
зрения. Модели представляют собой средства для визуализации, описания,
проектирования и документирования архитектуры системы. Модели строятся для того,
чтобы понять и осмыслить структуру и поведение будущей системы, облегчить
управление процессом ее создания и уменьшить возможный риск, а также
документировать принимаемые проектные решения.
То, что построение модели ПС, предшествующее написанию программного кода
необходимо, известно уже давно, но вручную очень трудно разработать и графически
представить строгие формальные спецификации системы, проверить их на полноту и
непротиворечивость и, тем более, изменить. Перечисленные проблемы породили
потребность в программно-технологических средствах специального класса – CASEсредствах, реализующих CASE (Computer Aided Software Engineering) – технологию
создания и сопровождения ПО, которые были созданы и широко используются в
настоящее время.
Жизненный цикл ПО. Модели жизненного цикла ПО.
Жизненный цикл ПО
Одним из базовых понятий методологии проектирования ПС является понятие
жизненного цикла программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный
процесс, который начинается с момента принятия решения о необходимости его
создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является
международный стандарт ISO/IEC 12207:1995 «Information Technology – Software Life
Cycle Processes (ISO - International Organization of Standardization - Международная
организация по стандартизации, IEC - International Electrotechnical Commission Международная комиссия по электротехнике). Он определяет структуру ЖЦ,
содержащую процессы, действия и задачи, которые должны быть выполнены во время
создания ПО. В данном стандарте ПО определяется как набор компьютерных
программ, процедур и, возможно, связанных с ними документации и данных. В
России имеется система стандартов, регламентирующих создание ПО – ГОСТ ЕСПД.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах
процессов:
- Пять основных процессов ЖЦ ПО (приобретение, поставка, разработка, эксплуатация,
сопровождение);
- Восемь вспомогательных процессов, обеспечивающих выполнение основных
процессов (документирование, управление конфигурацией, обеспечение качества,
верификация, аттестация, совместная оценка, аудит, решение проблем);
6
-
Четыре организационных процесса (управление проектами, создание инфраструктуры
проекта, усовершенствование, обучение).
Основные процессы ЖЦ ПО
Процесс приобретения состоит из действий и задач заказчика, приобретающего
ПО. Данный процесс охватывает следующие действия:
- инициирование приобретения;
- подготовку заявочных предложений;
- подготовку и корректировку договора,
- надзор за деятельностью поставщика,
- приемку и завершение работ.
Процесс поставки охватывает действия и задачи, выполняемые поставщиком,
который снабжает заказчика программным продуктом или услугой. Данный процесс
включает следующие действия:
- инициирование поставки;
- подготовку ответа на заявочное предложение;
- подготовку договора;
- планирование;
- выполнение и контроль;
- проверку и оценку;
- поставку и завершение работ.
Процесс разработки включает в себя все работы по созданию ПО и его компонент
в соответствии с заданными требованиями, включая оформление проектной и
эксплуатационной документации, подготовку материалов, необходимых для проверки
работоспособности и соответствующего качества программных продуктов, материалов,
необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя:
- подготовительную работу;
- анализ требований к системе;
- проектирование архитектуры системы;
- анализ требований к ПО;
- проектирование архитектуры ПО;
- детальное проектирование ПО;
- кодирование и тестирование ПО;
- интеграцию ПО;
- квалификационное тестирование ПО;
- интеграцию системы;
- квалификационное тестирование системы;
- установку ПО;
- приемку ПО.
Подготовительная работа начинается с выбора модели ЖЦ ПО. Действия и задачи
процесса разработки должны соответствовать выбранной модели. Разработчик должен
выбрать, адаптировать к условиям проекта и использовать согласованные с заказчиком
стандарты, методы и средства разработки, а также составить план выполнения работ.
Анализ требований к системе подразумевает определение ее функциональных
возможностей, пользовательских требований, требований к надежности и безопасности,
требований к внешним интерфейсам и т.д. Требования к системе оцениваются исходя из
критериев реализуемости и возможности проверки при тестировании.
Проектирование архитектуры системы на высоком уровне заключается в
определении компонентов ее оборудования, ПО и операций, выполняемых
эксплуатирующим систему персоналом. Архитектура системы должна соответствовать
требованиям, предъявляемым к системе, а также принятым проектным стандартам и
методам.
7
Анализ требований к ПО предполагает определение следующих характеристик для
каждого компонента ПО:
- функциональных возможностей, включая характеристики производительности и
среды функционирования компонента;
- внешних интерфейсов;
- спецификаций надежности и безопасности;
- эргономических требований;
- требований к используемым данным;
- требований к установке и приемке;
- требований к пользовательской документации;
- требований к эксплуатации и сопровождению.
Требования к ПО оцениваются исходя из критериев соответствия требованиям к
системе, реализуемости и возможности проверки при тестировании.
Проектирование архитектуры ПО включает следующие задачи:
- трансформацию требований к ПО в архитектуру, определяющую на высоком уровне
структуру ПО и состав его компонентов;
- разработку и документирование программных интерфейсов ПО и баз данных;
- разработку предварительной версии пользовательской документации;
- разработку и документирование предварительных требований к тестам и планам
интеграции ПО.
Архитектура
компонентов
ПО
должна
соответствовать
требованиям,
предъявляемым к ним, а также принятым проектным стандартам и методам.
Детальное проектирование ПО включает следующие задачи:
- описание компонентов ПО и интерфейсов между ними на более низком уровне,
достаточном для их последующего самостоятельного кодирования и тестирования;
- разработку и документирование детального проекта базы данных;
- обновление (при необходимости) пользовательской документации;
- разработку и документирование требований к тестам и планам тестирования
компонентов ПО;
- обновление плана интеграции ПО.
Кодирование и тестирование ПО охватывает следующие задачи:
- разработку (кодирование) и документирование каждого компонента ПО и базы
данных, а также совокупности тестовых процедур и данных для их тестирования;
- тестирование каждого компонента ПО и базы данных на соответствие предъявляемым
к ним требованиям. Результаты тестирования компонентов должны быть
документированы;
- обновление (при необходимости) пользовательской документации);
- обновление плана интеграции
Интеграция ПО предусматривает сборку разобранных компонентов ПО в
соответствии с планом интеграции и тестирование агрегированных компонентов. Для
каждого из агрегированных компонентов разрабатываются наборы тестов и тестовые
процедуры, предназначенные для проверки каждого из квалификационных требований
при последующем квалификационном тестировании. Квалификационное тестирование –
это набор критериев или условий, которые необходимо выполнить, чтобы
квалифицировать программный продукт как соответствующий своим спецификациям и
готовый к использованию в условиях эксплуатации.
Квалификационное тестирование ПО проводится разработчиком в присутствии
заказчика (по возможности) для демонстрации того, что ПО удовлетворяет всем
спецификациям и готово к использованию в условиях эксплуатации. Квалификационное
тестирование выполняется для каждого компонента ПО по всем разделам требований при
широком варьировании тестов. При этом также проверяется полнота технической и
пользовательской документации и ее адекватность самим компонентам ПО.
8
Интеграция системы заключается в сборке всех ее компонентов. Включая ПО и
оборудование. После интеграции система, в свою очередь, подвергается
квалификационному тестированию на соответствие совокупности требований к ней. При
этом также производится оформление и проверка полного комплекта документации на
систему.
Установка ПО осуществляется разработчиком в соответствии с планом в той среде
и на том оборудовании, которые предусмотрены договором. В процессе установки
проверяется работоспособность ПО и баз данных. Если устанавливаемое ПО заменяет
существующую систему. Разработчик должен обеспечить их параллельное
функционирование в соответствии с договором.
Приемка ПО предусматривает оценку результатов квалификационного
тестирования ПО и системы и документирование результатов оценки. Которые
проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную
передачу ПО заказчику в соответствии с договором. Обеспечивая при этом необходимое
обучение и поддержку.
Процесс эксплуатации включает в себя работы по внедрению компонентов ПО в
эксплуатацию, в том числе конфигурирование базы данных и рабочих мест пользователей,
обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и
непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин
их возникновения, модификацию ПО в рамках установленного регламента, подготовку
предложений по совершенствованию, развитию и модернизации системы.
Процесс сопровождения предусматривает действия и задачи, выполняемы
сопровождающей организацией. Под сопровождением понимается внесение изменений в
ПО в целях исправления ошибок, повышения производительности или адаптации к
изменившимся условиям работы или требованиям.
Вспомогательные процессы ЖЦ ПО
Процесс документирования предусматривает формализованное описание
информации, созданной в течение ЖЦ ПО. Данный процесс состоит из набора действий, с
помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют,
распространяют и сопровождают документы, необходимые для заинтересованных лиц,
таких, как руководство, технические специалисты и пользователи системы.
Процесс управления конфигурацией При создании проектов сложных ПС,
состоящих из многих компонентов, каждый из которых может иметь разновидности или
версии, возникает проблема учета их связей и функций, создания унифицированной
структуры и обеспечения развития всей системы. Управление конфигурацией позволяет
организовать, систематически учитывать и контролировать внесение изменений в ПО на
всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета,
планирования и управления конфигурациями ПО отражены в проекте стандарта ISO
12207-2.
Процесс обеспечения качества обеспечивает соответствующие гарантии того, что
ПО и процессы его ЖЦ соответствуют требованиям и утвержденным планам. Может
использовать результаты процессов верификации, аттестации, совместной оценки, аудита
и разрешения проблем.
Процесс верификации состоит в определении того, что программные продукты,
являющиеся результатами некоторого действия, полностью удовлетворяют требованиям
или условиям, обусловленным предшествующими действиями. Может выполняться как
разрабатывающей, так и независимой организацией.
Процесс аттестации предусматривает определение полноты соответствия
заданных требований и созданной системы или программного продукта их конкретному
функциональному назначению. Может выполняться как разрабатывающей, так и
независимой организацией.
9
Процесс совместной оценки предназначен для оценки состояния работ по проекту
и ПО, создаваемого при выполнении работ. Он сосредоточен в основном на контроле
планирования и управления ресурсами, персоналом, аппаратурой и инструментальными
средствами проекта. Может выполняться двумя сторонами, участвующими в договоре,
при этом одна из сторон проверяет другую.
Процесс аудита представляет собой определение соответствия требованиям,
планам и условиям договора. Аудит – это ревизия, проводимая компетентным органомв
целях обеспечения независимой оценки степени соответствия ПО или процессов
установленным требованиям.
Процесс разрешения проблем предусматривает анализ и решение проблем
независимо от их происхождения или источника, которые обнаружены в ходе разработки,
эксплуатации, сопровождения и других процессов.
Организационные процессы ЖЦ ПО
Процесс управления состоит из действий и задач, которые могут выполняться
любой стороной, управляющей своими процессами. Включает следующие действия:
инициирование управления, планирование. Выполнение и контроль, проверку и оценку,
завершение.
Процесс создания инфраструктуры охватывает выбор и поддержку технологии,
стандартов и инструментальных средств, выбор и установку аппаратных и программных
средств, используемых для разработки, эксплуатации и сопровождения ПО.
Процесс усовершенствования предусматривает оценку, измерение, контроль и
усовершенствование процессов ЖЦ ПО. Направлено на повышение производительности
труда всех участвующих в нем специалистов за счет совершенствования технологии,
методов управления, выбора инструментальных средств и обучения персонала.
Процесс обучения охватывает первоначальное обучение и последующее
постоянное повышение квалификации персонала.
Каждый процесс характеризуется определенными задачами и методами их
решения, исходными данными, полученными на предыдущем этапе, и результатами.
Результатами анализа, в частности, являются функциональные модели, информационные
модели и соответствующие им диаграммы. ЖЦ ПО носит итерационный характер:
результаты очередного этапа часто вызывают изменения в проектных решениях,
выработанных на более ранних этапах.
Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы
разработки ПО (под моделью ЖЦ понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ПС и специфики
условий, в которых последняя создается и функционирует). Регламенты стандарта
являются общими для любых моделей ЖЦ, методологий и технологий разработки.
Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в
деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие две
основные модели ЖЦ:
каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).
В изначально существовавших однородных ПС каждое приложение представляло
собой единое целое. Для разработки такого типа приложений применялся каскадный
способ. Его основной характеристикой является разбиение всей разработки на этапы,
10
причем переход с одного этапа на следующий происходит только после того, как будет
полностью завершена работа на текущем (рис. 1.1). Каждый этап завершается выпуском
полного комплекта документации, достаточной для того, чтобы разработка могла быть
продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в
следующем:
на каждом этапе формируется законченный набор проектной документации,
отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать
сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ПС, для которых в
самом начале разработки можно достаточно точно и полно сформулировать все
требования, с тем чтобы предоставить разработчикам свободу реализовать их как можно
лучше с технической точки зрения. В эту категорию попадают сложные расчетные
системы, системы реального времени и другие подобные задачи. Однако, в процессе
использования этого подхода обнаружился ряд его недостатков, вызванных прежде всего
тем, что реальный процесс создания ПО никогда полностью не укладывался в такую
жесткую схему. В процессе создания ПО постоянно возникала потребность в возврате к
предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате
реальный процесс создания ПО принимал следующий вид (рис. 1.2):
Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание с
получением результатов. Согласование результатов с пользователями производится
только в точках, планируемых после завершения каждого этапа работ, требования к ПС
"заморожены" в виде технического задания на все время ее создания. Таким образом,
пользователи могут внести свои замечания только после того, как работа над системой
будет полностью завершена. В случае неточного изложения требований или их изменения
в течение длительного периода создания ПО, пользователи получают систему, не
удовлетворяющую их потребностям. Модели (как функциональные, так и
информационные) автоматизируемого объекта могут устареть одновременно с их
утверждением.
11
Кроме того, не следует забывать последнее свойство сложной системы: любая
работающая система является результатом развития более простой системы… Сложная
система, спроектированная «с нуля» никогда не заработает. Следует начать с работающей
простой системы. Каскадная модель ЖЦ ПО вступает в некоторое противоречие с этим
положением. В то время, когда использовался такой подход предполагалось, что первая
разработанная версия ПС
пойдет в мусорную корзину, и только вторая будет
удовлетворять требованиям.
Для преодоления перечисленных проблем была предложена спиральная модель
ЖЦ (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих
этапах реализуемость технических решений проверяется путем создания прототипов.
Каждый виток спирали соответствует созданию фрагмента или версии ПО, на нем
уточняются цели и характеристики проекта, определяется его качество и планируются
работы следующего витка спирали. Таким образом углубляются и последовательно
конкретизируются детали проекта и в результате выбирается обоснованный вариант,
который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы. Неполное завершение работ на каждом этапе позволяет переходить на
следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном
способе разработки недостающую работу можно будет выполнить на следующей
итерации. Главная же задача - как можно быстрее показать пользователям системы
работоспособный продукт, тем самым активизируя процесс уточнения и дополнения
требований.
Основная проблема спирального цикла - определение момента перехода на
следующий этап. Для ее решения необходимо ввести временные ограничения на каждый
из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если
не вся запланированная работа закончена. План составляется на основе статистических
данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Рис 1.3. Спиральная модель ЖЦ
Методологии и технологии проектирования ПО, общие требования к
методологии и технологии. Методология RAD
Общие требования к методологии и технологии
Вернувшись немного назад, напомню. Мы рассматриваем инженерию
программного обеспечения. Когда говорят об инженерии чего-либо, не только
программного обеспечения, оперируют такими понятиями, как методология и технология.
Рассмотрим методологию и технологию применительно к разработке ПО.
12
Основу проекта любой ПС составляют методологии, технологии и
инструментальные средства проектирования (CASE-средства). Т.е. перед тем, как начать
разработку, мы должны выбрать – какой методологией будем пользоваться. Сделанный
выбор определит весь дальнейший процесс разработки. Именно процесс в целом, а не
такие частности как, скажем, язык программирования. Методология реализуется через
конкретные технологии и поддерживающие их стандарты, методики и инструментальные
средства, которые обеспечивают выполнение процессов ЖЦ. Таким образом, выбрав
технологию мы имеем набор технологий, по которым будем работать, набор стандартов,
которым будем следовать и набор инструментальных средств проектирования, которыми
будем пользоваться.
Процесс
проектирования
рассматривается
как
последовательность
технологических операций. Каких именно – описывается технологией.
Технология проектирования определяется как совокупность технологических
операций (рис. 1.4) проектирования в их последовательности и взаимосвязи, приводящая к
разработке проекта ПО.
Рис. 1.4. Представление технологической операции проектирования
Технологические инструкции, составляющие основное содержание технологии,
должны состоять из описания последовательности технологических операций, условий, в
зависимости от которых выполняется та или иная операция, и описаний самих операций.
Технология проектирования, разработки и сопровождения ПС должна
удовлетворять следующим общим требованиям:
- технология должна поддерживать полный ЖЦ ПО;
- технология должна обеспечивать гарантированное достижение целей разработки ПС с
заданным качеством и в установленное время;
- технология должна обеспечивать возможность выполнения крупных проектов в виде
подсистем (т.е. возможность декомпозиции проекта на составные части,
разрабатываемые группами исполнителей ограниченной численности с последующей
интеграцией составных частей). Опыт разработки крупных ПС показывает, что для
повышения эффективности работ необходимо разбить проект на отдельные слабо
связанные по данным и функциям подсистемы. Реализация подсистем должна
выполняться отдельными группами специалистов. При этом необходимо обеспечить
координацию ведения общего проекта и исключить дублирование результатов работ
каждой проектной группы, которое может возникнуть в силу наличия общих данных и
функций;
- технология должна обеспечивать возможность ведения работ по проектированию
отдельных подсистем небольшими группами (3-7 человек). Это обусловлено
13
принципами управляемости коллектива и повышения производительности за счет
минимизации числа внешних связей;
- технология должна обеспечивать минимальное время получения работоспособной ПС.
Речь идет не о сроках готовности всей ПС, а о сроках реализации отдельных
подсистем. Реализация ПС в целом в короткие сроки может потребовать привлечения
большого числа разработчиков, при этом эффект может оказаться ниже, чем при
реализации в более короткие сроки отдельных подсистем меньшим числом
разработчиков. Практика показывает, что даже при наличии полностью завершенного
проекта, внедрение идет последовательно по отдельным подсистемам;
- технология должна предусматривать возможность управления конфигурацией проекта,
ведения версий проекта и его составляющих, возможность автоматического выпуска
проектной документации и синхронизацию ее версий с версиями проекта;
- технология должна обеспечивать независимость выполняемых проектных решений от
средств реализации ПС, операционных систем, языков и систем программирования);
- технология должна быть поддержана комплексом согласованных CASE-средств,
обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Общий подход к оценке и выбору CASE-средств будет рассмотрен далее.
Реальное применение любой технологии проектирования, разработки и
сопровождения ПС в конкретной организации и конкретном проекте невозможно без
выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми
участниками проекта. К таким стандартам относятся следующие:
- стандарт проектирования;
- стандарт оформления проектной документации;
- стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень
их детализации;
- правила фиксации проектных решений на диаграммах, в том числе: правила
именования объектов (включая соглашения по терминологии), набор атрибутов для
всех объектов и правила их заполнения на каждой стадии, правила оформления
диаграмм, включая требования к форме и размерам объектов, и т. д.;
- требования к конфигурации рабочих мест разработчиков, включая настройки
операционной системы, настройки CASE-средств, общие настройки проекта и т. д.;
- механизм обеспечения совместной работы над проектом, в том числе: правила
интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех
разработчиков состоянии (регламент обмена проектной информацией, механизм
фиксации общих объектов и т.д.), правила проверки проектных решений на
непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
- комплектность, состав и структуру документации на каждой стадии проектирования;
- требования к ее оформлению (включая требования к содержанию разделов,
подразделов, пунктов, таблиц и т.д.),
- правила подготовки, рассмотрения, согласования и утверждения документации с
указанием предельных сроков для каждой стадии;
- требования к настройке издательской системы, используемой в качестве встроенного
средства подготовки документации;
- требования к настройке CASE-средств для обеспечения подготовки документации в
соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
- правила оформления экранов (шрифты и цветовая палитра), состав и расположение
окон и элементов управления;
- правила использования клавиатуры и мыши;
14
-
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя.
Методология RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ
является получившая в последнее время широкое распространение методология быстрой
разработки приложений RAD (Rapid Application Development). Под этим термином
обычно понимается процесс разработки ПО, содержащий 3 элемента:
- небольшую команду программистов (от 2 до 10 человек);
- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
- повторяющийся цикл, при котором разработчики, по мере того, как приложение
начинает обретать форму, запрашивают и реализуют в продукте требования,
полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов,
имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с
использованием
CASE-средств.
Члены
коллектива
должны
также
уметь
трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
- фаза анализа и планирования требований;
- фаза проектирования;
- фаза построения;
- фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют
функции, которые она должна выполнять, выделяют наиболее приоритетные из них,
требующие проработки в первую очередь, описывают информационные потребности.
Определение требований выполняется в основном силами пользователей под
руководством
специалистов-разработчиков.
Ограничивается
масштаб
проекта,
определяются временные рамки для каждой из последующих фаз. Кроме того,
определяется сама возможность реализации данного проекта в установленных рамках
финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы
должны быть список и приоритетность функций будущей ПС, предварительные
функциональные и информационные модели ПС.
На фазе проектирования часть пользователей принимает участие в техническом
проектировании системы под руководством специалистов-разработчиков. CASE-средства
используются для быстрого получения работающих прототипов приложений.
Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют
требования к системе, которые не были выявлены на предыдущей фазе. Более подробно
рассматриваются процессы системы. Анализируется и, при необходимости,
корректируется функциональная модель. Каждый процесс рассматривается детально. При
необходимости для каждого элементарного процесса создается частичный прототип:
экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются
требования разграничения доступа к данным. На этой же фазе происходит определение
набора необходимой документации.
После детального определения состава процессов оценивается количество
функциональных элементов разрабатываемой системы и принимается решение о
разделении ПС на подсистемы, поддающиеся реализации одной командой разработчиков
за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASEсредств проект распределяется между различными командами (делится функциональная
модель). Результатом данной фазы должны быть:
- общая информационная модель системы;
15
-
функциональные модели системы в целом и подсистем, реализуемых отдельными
командами разработчиков;
- точно определенные с помощью CASE-средства интерфейсы между автономно
разрабатываемыми подсистемами;
- построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств,
которые будут использоваться в дальнейшем при построении системы. Данное требование
вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на
этап может произойти фактически неконтролируемое искажение данных. Применение
единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические
средства прототипирования, не предназначенные для построения реальных приложений, а
прототипы выбрасывались после того, как выполняли задачу устранения неясностей в
проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким
образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка
приложения. На данной фазе разработчики производят итеративное построение реальной
системы на основе полученных в предыдущей фазе моделей, а также требований
нефункционального характера. Программный код частично формируется при помощи
автоматических генераторов, получающих информацию непосредственно из репозитория
CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и
вносят коррективы, если в процессе разработки система перестает удовлетворять
определенным
ранее
требованиям.
Тестирование
системы
осуществляется
непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится
постепенная интеграция данной части системы с остальными, формируется полный
программный код, выполняется тестирование совместной работы данной части
приложения с остальными, а затем тестирование системы в целом. Завершается
физическое проектирование системы:
- определяется необходимость распределения данных;
- производится анализ использования данных;
- производится физическое проектирование базы данных;
- определяются требования к аппаратным ресурсам;
- определяются способы увеличения производительности;
- завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным
требованиям.
На фазе внедрения производится обучение пользователей, организационные
изменения и параллельно с внедрением новой системы осуществляется работа с
существующей системой (до полного внедрения новой). Так как фаза построения
достаточно непродолжительна, планирование и подготовка к внедрению должны
начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема
разработки ПС не является абсолютной. Возможны различные варианты, зависящие,
например, от начальных условий, в которых ведется разработка: разрабатывается
совершенно новая система; уже было проведено обследование предприятия и существует
модель его деятельности; на предприятии уже существует некоторая ПС, которая может
быть использована в качестве начального прототипа или должна быть интегрирована с
разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может
претендовать на универсальность, она хороша в первую очередь для относительно
небольших проектов, разрабатываемых для конкретного заказчика. Если же
разрабатывается типовая система, которая не является законченным продуктом, а
16
представляет собой комплекс типовых компонент, централизованно сопровождаемых,
адаптируемых
к
программно-техническим
платформам,
СУБД,
средствам
телекоммуникации, организационно-экономическим особенностям объектов внедрения и
интегрируемых с существующими разработками, на первый план выступают такие
показатели проекта, как управляемость и качество, которые могут войти в противоречие с
простотой и скоростью разработки. Для таких проектов необходимы высокий уровень
планирования и жесткая дисциплина проектирования, строгое следование заранее
разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ,
операционных систем или программ управления космическими кораблями, т.е. программ,
требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых
отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы
системы (например, приложения реального времени) и приложения, от которых зависит
безопасность людей (например, управление самолетом или атомной электростанцией), так
как итеративный подход предполагает, что первые несколько версий наверняка не будут
полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых
функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика
не зависит от языка программирования, на котором ведется разработка. Размер
приложения, которое может быть выполнено по методологии RAD, для хорошо
отлаженной среды разработки ПС с максимальным повторным использованием
программных компонентов, определяется следующим образом:
< 1000 функциональных
один человек
элементов
1000-4000 функциональных
элементов
одна команда разработчиков
> 4000 функциональных
4000 функциональных элементов на одну
элементов
команду разработчиков
В качестве итога перечислим основные принципы методологии RAD:
- разработка приложений итерациями;
- необязательность полного завершения работ на каждом из этапов жизненного цикла;
- обязательное вовлечение пользователей в процесс разработки ПС;
- необходимое применение CASE-средств, обеспечивающих целостность проекта;
- применение средств управления конфигурацией, облегчающих внесение изменений в
проект и сопровождение готовой системы;
- необходимое использование генераторов кода;
- использование прототипирования, позволяющее полнее выяснить и удовлетворить
потребности конечного пользователя;
- тестирование и развитие проекта, осуществляемые одновременно с разработкой;
- ведение
разработки
немногочисленной
хорошо
управляемой
командой
профессионалов;
- грамотное руководство разработкой системы, четкое планирование и контроль
выполнения работ.
Структурный подход к проектированию ПО. Сущность структурного
подхода.
Методология
функционального
моделирования
SADT.
Моделирование потоков данных (процессов). Моделирование данных
Проблема сложности является главной проблемой, которую приходится решать
при создании больших и сложных систем любой природы, в том числе программных
17
систем. Ни один разработчик не в состоянии выйти за пределы человеческих
возможностей и понять всю систему в целом. Единственный эффективный подход к
решению этой проблемы заключается в построении сложной системы из небольшого
числа крупных частей, каждая из которых в свою очередь, строится из частей меньшего
размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из
имеющегося материала. Этот подход известен под разными названиями, среди них такие
как «разделяй и властвуй», иерархическая декомпозиция и др. По отношению к
проектированию сложной программной системы это означает, что ее необходимо
разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно
разрабатывать независимо от других. Это позволят при разработке подсистемы любого
уровня держать в уме информацию только о ней, а не обо всех остальных частях системы.
Правильная декомпозиция является главным способом преодоления сложности
разработки больших систем ПО. Понятие «правильный» по отношению к декомпозиции
означает следующее:
- количество связей между отдельными подсистемами должно быть минимальным;
- связность отдельных частей внутри каждой подсистемы должна быть максимальной.
Структурный подход – один из вариантов декомпозиции. Другой – объектноориентированный, будет рассмотрен позднее.
Сущность структурного подхода
Сущность структурного подхода к разработке ПС заключается в ее декомпозиции
(разбиении) на автоматизируемые функции: система разбивается на функциональные
подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и
так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом
автоматизируемая система сохраняет целостное представление, в котором все
составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от
отдельных задач ко всей системе целостность теряется, возникают проблемы при
информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на
ряде общих принципов. В качестве двух базовых принципов используются следующие:
- принцип "разделяй и властвуй" - принцип решения сложных проблем путем их
разбиения на множество меньших независимых задач, легких для понимания и
решения;
- принцип иерархического упорядочивания - принцип организации составных частей
проблемы в иерархические древовидные структуры с добавлением новых деталей на
каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы
являются второстепенными, поскольку игнорирование любого из них может привести к
непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из
этих принципов являются следующие:
- принцип абстрагирования - заключается в выделении существенных аспектов системы
и отвлечения от несущественных;
- принцип формализации - заключается в необходимости строгого методического
подхода к решению проблемы;
- принцип непротиворечивости - заключается в обоснованности и согласованности
элементов;
- принцип структурирования данных - заключается в том, что данные должны быть
структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств,
иллюстрирующих функции, выполняемые системой и отношения между данными.
Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее
распространенными среди которых являются следующие:
18
-
SADT (Structured Analysis and Design Technique) модели и соответствующие
функциональные диаграммы;
- DFD (Data Flow Diagrams) диаграммы потоков данных;
- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования ПС модели расширяются, уточняются и дополняются
диаграммами, отражающими структуру программного обеспечения: архитектуру ПО,
структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ПС независимо от
того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в
каждом конкретном случае зависит от необходимой полноты описания системы.
Методология функционального моделирования SADT
Методология SADT разработана Дугласом Россом. На ее основе разработана, в
частности, известная методология IDEF0 (Icam DEFinition), которая является основной
частью программы ICAM (Интеграция компьютерных и промышленных технологий),
проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур,
предназначенных для построения функциональной модели объекта какой-либо
предметной области. Функциональная модель SADT отображает функциональную
структуру объекта, т.е. производимые им действия и связи между этими действиями.
Методология SADT может использоваться для моделирования широкого круга
систем и определения требований и функций, а затем для разработки системы, которая
удовлетворяет этим требованиям и реализует эти функции. Для уже существующих
систем SADT может быть использована для анализа функций, выполняемых системой, а
также для указания механизмов, посредством которых они осуществляются.
Состав функциональной модели
Результатом применения методологии SADT является модель, которая состоит из
диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы главные компоненты модели, все функции ПС и интерфейсы на них представлены как
блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая
информация входит в блок сверху, в то время как информация, которая подвергается
обработке, показана с левой стороны блока, а результаты выхода показаны с правой
стороны. Механизм (человек или автоматизированная система), который осуществляет
операцию, представляется дугой, входящей в блок снизу (рисунок 2.1).
Одной из наиболее важных особенностей методологии SADT является постепенное
введение все больших уровней детализации по мере создания диаграмм, отображающих
модель.
Рис. 2.1. Функциональный блок и интерфейсные дуги
На рисунке 2.2, где приведены четыре диаграммы и их взаимосвязи, показана
структура SADT-модели. Каждый компонент модели может быть декомпозирован на
другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на
родительской диаграмме.
Иерархия диаграмм
19
Построение SADT-модели начинается с представления всей системы в виде
простейшей компоненты - одного блока и дуг, изображающих интерфейсы с функциями
вне системы. Поскольку единственный блок представляет всю систему как единое целое,
имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг - они также
представляют полный набор внешних интерфейсов системы в целом.
Затем блок, который представляет систему в качестве единого модуля,
детализируется на другой диаграмме с помощью нескольких блоков, соединенных
интерфейсными дугами. Эти блоки представляют основные подфункции исходной
функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых
представлена как блок, границы которого определены интерфейсными дугами. Каждая из
этих подфункций может быть декомпозирована подобным образом для более детального
представления.
Во всех случаях каждая подфункция может содержать только те элементы, которые
входят в исходную функцию. Кроме того, модель не может опустить какие-либо
элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают
контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной
документацией, разбивающих сложный объект на составные части, которые представлены
в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других
диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей
диаграммы. На каждом шаге декомпозиции более общая диаграмма называется
родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня,
являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и
выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть
системы.
20
Рис. 2.2. Структура SADT-модели. Декомпозиция диаграмм
На рисунках 2.3 - 2.5 представлены различные варианты выполнения функций и
соединения дуг с блоками.
Рис. 2.3. Одновременное выполнение
21
Рис. 2.4. Соответствие должно быть полным и непротиворечивым
Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же
один конец остается неприсоединенным. Неприсоединенные дуги соответствуют входам,
управлениям и выходам родительского блока. Источник или получатель этих
пограничных дуг может быть обнаружен только на родительской диаграмме.
Неприсоединенные концы должны соответствовать дугам на исходной диаграмме. Все
граничные дуги должны продолжаться на родительской диаграмме, чтобы она была
полной и непротиворечивой.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные
связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции
могут быть изображены с помощью дуг. Обратные связи могут выступать в виде
комментариев, замечаний, исправлений и т.д. (рисунок 2.5).
Рис. 2.5. Пример обратной связи
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с
помощью которых осуществляется выполнение функций. Механизм может быть
человеком, компьютером или любым другим устройством, которое помогает выполнять
данную функцию (рисунок 2.6).
22
Рис. 2.6. Пример механизма
Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть
далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее
детализирована с помощью необходимого числа диаграмм. Таким образом, формируется
иерархия диаграмм.
Для того, чтобы указать положение любой диаграммы или блока в иерархии,
используются номера диаграмм. Например, А21 является диаграммой, которая
детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме
А0, которая является самой верхней диаграммой модели. На рисунке 2.7 показано
типичное дерево диаграмм.
Рис. 2.7. Иерархия диаграмм
2.2.3. Типы связей между функциями
Одним из важных моментов при проектировании ПС с помощью методологии
SADT является точная согласованность типов связей между функциями. Различают по
крайней мере семь типов связывания:
Тип связи
Относительная значимость
Случайная
0
Логическая
1
Временная
2
23
Процедурная
3
Коммуникационная
4
Последовательная
5
Функциональная
6
Ниже каждый тип связи кратко определен и проиллюстрирован с помощью
типичного примера из SADT.
(0) Тип случайной связности: наименее желательный.
Случайная связность возникает, когда конкретная связь между функциями мала
или полностью отсутствует. Это относится к ситуации, когда имена данных на SADTдугах в одной диаграмме имеют малую связь друг с другом. Крайний вариант этого случая
показан на рисунке 2.8.
Рис. 2.8. Случайная связность
(1) Тип логической связности. Логическое связывание происходит тогда, когда
данные и функции собираются вместе вследствие того, что они попадают в общий класс
или набор элементов, но необходимых функциональных отношений между ними не
обнаруживается. Функции одного и того же множества или типа (напр. «редактировать
все входы»).
(2) Тип временной связности. Связанные по времени элементы возникают
вследствие того, что они представляют функции, связанные во времени, когда данные
используются одновременно или функции включаются параллельно, а не
последовательно. Функции одного и того же периода времени (например «операции
инициализации»).
(3) Тип процедурной связности. Процедурно-связанные элементы появляются
сгруппированными вместе вследствие того, что они выполняются в течение одной и той
же части цикла или процесса. Пример процедурно-связанной диаграммы приведен на
рисунке 2.9. Функции, работающие в одной и той же фазе или итерации (например
«первый проход компилятора»).
Рис. 2.9. Процедурная связность
(4)
Тип
коммуникационной
связности.
Диаграммы
демонстрируют
коммуникационные связи, когда блоки группируются вследствие того, что они
24
используют одни и те же входные данные и/или производят одни и те же выходные
данные (рисунок 2.10).
(5)
Тип
последовательной
связности.
На
диаграммах,
имеющих
последовательные связи, выход одной функции служит входными данными для
следующей функции. Связь между элементами на диаграмме является более тесной, чем
на рассмотренных выше уровнях связок, поскольку моделируются причинноследственные зависимости (рисунок 2.11).
(6) Тип функциональной связности. Диаграмма отражает полную
функциональную связность, при наличии полной зависимости одной функции от другой.
Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов,
относящихся к последовательному или более слабому типу связности. Одним из способов
определения функционально-связанных диаграмм является рассмотрение двух блоков,
связанных через управляющие дуги, как показано на рисунке 2.12.
Рис. 2.10. Коммуникационная связность
Рис. 2.11. Последовательная связность
В математических терминах необходимое условие для простейшего типа
функциональной связности, показанной на рисунке 2.12, имеет следующий вид:
C = g(B) = g(f(A))
В таблице представлены все типы связей, рассмотренные выше. Важно отметить,
что уровни 4-6 устанавливают типы связностей, которые разработчики считают
важнейшими для получения диаграмм хорошего качества.
Рис. 2.12. Функциональная связность
Моделирование потоков данных (процессов)
В основе данной методологии (методологии Gane/Sarson) лежит построение модели
анализируемой ИС - проектируемой или реально существующей. В соответствии с
методологией модель системы определяется как иерархия диаграмм потоков данных
(ДПД или DFD), описывающих асинхронный процесс преобразования информации от ее
25
ввода в систему до выдачи пользователю. Диаграммы верхних уровней иерархии
(контекстные диаграммы) определяют основные процессы или подсистемы ИС с
внешними входами и выходами. Они детализируются при помощи диаграмм нижнего
уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию
диаграмм, до тех пор, пока не будет достигнут такой уровень декомпозиции, на котором
процесс становятся элементарными и детализировать их далее невозможно.
Источники информации (внешние сущности) порождают информационные потоки
(потоки данных), переносящие информацию к подсистемам или процессам. Те в свою
очередь преобразуют информацию и порождают новые потоки, которые переносят
информацию к другим процессам или подсистемам, накопителям данных или внешним
сущностям - потребителям информации. Таким образом, основными компонентами
диаграмм потоков данных являются:
- внешние сущности;
- системы/подсистемы;
- процессы;
- накопители данных;
- потоки данных.
Внешние сущности
Внешняя сущность представляет собой материальный предмет или физическое
лицо, представляющее собой источник или приемник информации, например, заказчики,
персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в
качестве внешней сущности указывает на то, что она находится за пределами границ
анализируемой ПС. В процессе анализа некоторые внешние сущности могут быть
перенесены внутрь диаграммы анализируемой ПС, если это необходимо, или, наоборот,
часть процессов ПС может быть вынесена за пределы диаграммы и представлена как
внешняя сущность.
Внешняя сущность обозначается квадратом (рисунок 2.13), расположенным как бы
"над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот
символ среди других обозначений:
Рис. 2.13. Внешняя сущность
Системы и подсистемы
При построении модели сложной ПС она может быть представлена в самом общем
виде на так называемой контекстной диаграмме в виде одной системы как единого целого,
либо может быть декомпозирована на ряд подсистем.
Подсистема (или система) на контекстной диаграмме изображается следующим
образом (рисунок 2.14).
Рис. 2.14. Подсистема
Номер подсистемы служит для ее идентификации. В поле имени вводится
наименование подсистемы в виде предложения с подлежащим и соответствующими
определениями и дополнениями.
Процессы
26
Процесс представляет собой преобразование входных потоков данных в выходные
в соответствии с определенным алгоритмом. Физически процесс может быть реализован
различными способами: это может быть подразделение организации (отдел),
выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно
реализованное логическое устройство и т.д.
Процесс на диаграмме потоков данных изображается, как показано на рисунке 2.15.
Рис. 2.15. Процесс
Номер процесса служит для его идентификации. В поле имени вводится
наименование процесса в виде предложения с активным недвусмысленным глаголом в
неопределенной форме (вычислить, рассчитать, проверить, определить, создать,
получить), за которым следуют существительные в винительном падеже, например:
"Ввести сведения о клиентах";
"Выдать информацию о текущих расходах";
"Проверить кредитоспособность клиента".
Использование таких глаголов, как "обработать", "модернизировать" или
"отредактировать" означает, как правило, недостаточно глубокое понимание данного
процесса и требует дальнейшего анализа.
Информация в поле физической реализации показывает, какое подразделение
организации, программа или аппаратное устройство выполняет данный процесс.
Накопители данных
Накопитель данных представляет собой абстрактное устройство для хранения
информации, которую можно в любой момент поместить в накопитель и через некоторое
время извлечь, причем способы помещения и извлечения могут быть любыми.
Накопитель данных может быть реализован физически в виде микрофиши, ящика в
картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д.
Накопитель данных на диаграмме потоков данных изображается, как показано на рисунке
2.16.
Рис. 2.16. Накопитель данных
Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя
накопителя выбирается из соображения наибольшей информативности для
проектировщика.
Накопитель данных в общем случае является прообразом будущей базы данных и
описание хранящихся в нем данных должно быть увязано с информационной моделью.
Потоки данных
Поток данных определяет информацию, передаваемую через некоторое соединение
от источника к приемнику. Реальный поток данных может быть информацией,
передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами,
магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д.
Поток данных на диаграмме изображается линией, оканчивающейся стрелкой,
которая показывает направление потока (рисунок 2.17). Каждый поток данных имеет имя,
отражающее его содержание.
27
Рис. 2.17. Поток данных
Построение иерархии диаграмм потоков данных
Первым шагом при построении иерархии ДПД является построение контекстных
диаграмм. Обычно при проектировании относительно простых ПС строится единственная
контекстная диаграмма со звездообразной топологией, в центре которой находится так
называемый главный процесс, соединенный с приемниками и источниками информации,
посредством которых с системой взаимодействуют пользователи и другие внешние
системы.
Если же для сложной системы ограничиться единственной контекстной
диаграммой, то она будет содержать слишком большое количество источников и
приемников информации, которые трудно расположить на листе бумаги нормального
формата, и кроме того, единственный главный процесс не раскрывает структуры
распределенной системы. Признаками сложности (в смысле контекста) могут быть:
- наличие большого количества внешних сущностей (десять и более);
- распределенная природа системы;
- многофункциональность системы с уже сложившейся или выявленной группировкой
функций в отдельные подсистемы.
Для сложных ПС строится иерархия контекстных диаграмм. При этом контекстная
диаграмма верхнего уровня содержит не единственный главный процесс, а набор
подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня
детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных
функциональных подсистем проектируемой ИС как между собой, так и с внешними
входными и выходными потоками данных и внешними объектами (источниками и
приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения
функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно
важно для сложных многофункциональных систем, в разработке которых участвуют
разные организации и коллективы разработчиков.
После построения контекстных диаграмм полученную модель следует проверить
на полноту исходных данных об объектах системы и изолированность объектов
(отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах,
выполняется ее детализация при помощи ДПД. Каждый процесс на ДПД, в свою очередь,
может быть детализирован при помощи ДПД или миниспецификации. При детализации
должны выполняться следующие правила:
- правило балансировки - означает, что при детализации подсистемы или процесса
детализирующая диаграмма в качестве внешних источников/приемников данных
может иметь только те компоненты (подсистемы, процессы, внешние сущности,
накопители данных), с которыми имеет информационную связь детализируемая
подсистема или процесс на родительской диаграмме;
- правило нумерации - означает, что при детализации процессов должна
поддерживаться их иерархическая нумерация. Например, процессы, детализирующие
процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
28
Миниспецификация (описание логики процесса) должна формулировать его
основные функции таким образом, чтобы в дальнейшем специалист, выполняющий
реализацию проекта, смог выполнить их или разработать соответствующую программу.
Миниспецификация является конечной вершиной иерархии ДПД. Решение о
завершении детализации процесса и использовании миниспецификации принимается
аналитиком исходя из следующих критериев:
- наличия у процесса относительно небольшого количества входных и выходных
потоков данных (2-3 потока);
- возможности описания преобразования данных процессом в виде последовательного
алгоритма;
- выполнения процессом единственной логической функции преобразования входной
информации в выходную;
- возможности описания логики процесса при помощи миниспецификации небольшого
объема (не более 20-30 строк).
При построении иерархии ДПД переходить к детализации процессов следует
только после определения содержания всех потоков и накопителей данных, которое
описывается при помощи структур данных. Структуры данных конструируются из
элементов данных и могут содержать альтернативы, условные вхождения и итерации.
Условное вхождение означает, что данный компонент может отсутствовать в структуре.
Альтернатива означает, что в структуру может входить один из перечисленных элементов.
Итерация означает вхождение любого числа элементов в указанном диапазоне. Для
каждого элемента данных может указываться его тип (непрерывные или дискретные
данные). Для непрерывных данных может указываться единица измерения (кг, см и т.п.),
диапазон значений, точность представления и форма физического кодирования. Для
дискретных данных может указываться таблица допустимых значений.
После построения законченной модели системы ее необходимо верифицировать
(проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы,
процессы, потоки данных) должны быть подробно описаны и детализированы.
Выявленные недетализированные объекты следует детализировать, вернувшись на
предыдущие шаги разработки. В согласованной модели для всех потоков данных и
накопителей данных должно выполняться правило сохранения информации: все
поступающие куда-либо данные должны быть считаны, а все считываемые данные
должны быть записаны.
Моделирование данных
Case-метод Баркера
Цель моделирования данных состоит в обеспечении разработчика ПС
концептуальной схемой базы данных в форме одной модели или нескольких локальных
моделей, которые относительно легко могут быть отображены в любую систему баз
данных.
Наиболее распространенным средством моделирования данных являются
диаграммы "сущность-связь" (ERD). С их помощью определяются важные для
предметной области объекты (сущности), их свойства (атрибуты) и отношения друг с
другом (связи). ERD непосредственно используются для проектирования реляционных баз
данных.
Нотация ERD была впервые введена П. Ченом (Chen) и получила дальнейшее
развитие в работах Баркера. Метод Баркера будет излагаться на примере моделирования
деятельности компании по торговле автомобилями. Ниже приведены выдержки из
интервью, проведенного с персоналом компании.
Сущность (Entity) - реальный либо воображаемый объект, имеющий
существенное значение для рассматриваемой предметной области, информация о котором
подлежит хранению (рисунок 2.18).
29
Рис. 2.18. Графическое изображение сущности
Каждая сущность должна обладать уникальным идентификатором. Каждый
экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других
экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми
свойствами:
- каждая сущность должна иметь уникальное имя, и к одному и тому же имени должна
всегда применяться одна и та же интерпретация. Одна и та же интерпретация не может
применяться к различным именам, если только они не являются псевдонимами;
- сущность обладает одним или несколькими атрибутами, которые либо принадлежат
сущности, либо наследуются через связь;
- сущность обладает одним или несколькими атрибутами, которые однозначно
идентифицируют каждый экземпляр сущности;
- каждая сущность может обладать любым количеством связей с другими сущностями
модели.
Связь (Relationship) - поименованная ассоциация между двумя сущностями,
значимая для рассматриваемой предметной области. Связь - это ассоциация между
сущностями, при которой, как правило, каждый экземпляр одной сущности, называемой
родительской сущностью, ассоциирован с произвольным (в том числе нулевым)
количеством экземпляров второй сущности, называемой сущностью-потомком, а каждый
экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущностиродителя. Таким образом, экземпляр сущности-потомка может существовать только при
существовании сущности родителя.
Связи может даваться имя, выражаемое грамматическим оборотом глагола и
помещаемое возле линии связи. Имя каждой связи между двумя данными сущностями
должно быть уникальным, но имена связей в модели не обязаны быть уникальными. Имя
связи всегда формируется с точки зрения родителя, так что предложение может быть
образовано соединением имени сущности-родителя, имени связи, выражения степени и
имени сущности-потомка.
Степень связи и обязательность графически изображаются следующим образом
(рисунок 2.20).
Рис. 2.20.
Атрибут - любая характеристика сущности, значимая для рассматриваемой
предметной области и предназначенная для квалификации, идентификации,
классификации, количественной характеристики или выражения состояния сущности.
Атрибут представляет тип характеристик или свойств, ассоциированных со множеством
реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар
предметов и т.д.). Экземпляр атрибута - это определенная характеристика отдельного
элемента множества. Экземпляр атрибута определяется типом характеристики и ее
значением, называемым значением атрибута. В ER-модели атрибуты ассоциируются с
конкретными сущностями. Таким образом, экземпляр сущности должен обладать
единственным определенным значением для ассоциированного атрибута.
Атрибут может быть либо обязательным, либо необязательным (рисунок 2.23).
Обязательность означает, что атрибут не может принимать неопределенных значений (null
values). Атрибут может быть либо описательным (т.е. обычным дескриптором сущности),
либо входить в состав уникального идентификатора (первичного ключа).
30
Уникальный идентификатор - это атрибут или совокупность атрибутов и/или
связей, предназначенная для уникальной идентификации каждого экземпляра данного
типа сущности. В случае полной идентификации каждый экземпляр данного типа
сущности полностью идентифицируется своими собственными ключевыми атрибутами, в
противном случае в его идентификации участвуют также атрибуты другой сущностиродителя (рисунок 2.24).
Рис. 2.23.
Рис. 2.24.
Каждый атрибут идентифицируется уникальным именем, выражаемым
грамматическим оборотом существительного, описывающим представляемую атрибутом
характеристику. Атрибуты изображаются в виде списка имен внутри блока
ассоциированной сущности, причем каждый атрибут занимает отдельную строку.
Атрибуты, определяющие первичный ключ, размещаются наверху списка и выделяются
знаком "#".
Каждая сущность должна обладать хотя бы одним возможным ключом.
Возможный ключ сущности - это один или несколько атрибутов, чьи значения однозначно
определяют каждый экземпляр сущности. При существовании нескольких возможных
ключей один из них обозначается в качестве первичного ключа, а остальные - как
альтернативные ключи.
Помимо перечисленных основных конструкций модель данных может содержать
ряд дополнительных.
Подтипы и супертипы: одна сущность является обобщающим понятием для
группы подобных сущностей (рисунок 2.26).
Взаимно исключающие связи: каждый экземпляр сущности участвует только в
одной связи из группы взаимно исключающих связей (рисунок 2.27).
Рис. 2.26. Подтипы и супертипы
31
Рис. 2.27. Взаимно исключающие связи
Рекурсивная связь: сущность может быть связана сама с собой (рисунок 2.28).
Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть
перенесен из одного экземпляра связи в другой (рисунок 2.29).
Рис. 2.28. Рекурсивная связь
Рис. 2.29. Неперемещаемая связь
Методология IDEF1
Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена
и позволяет построить модель данных, эквивалентную реляционной модели в третьей
нормальной форме. В настоящее время на основе совершенствования методологии IDEF1
создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких
требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы
используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов или
просто независимой, если каждый экземпляр сущности может быть однозначно
идентифицирован без определения его отношений с другими сущностями. Сущность
называется зависимой от идентификаторов или просто зависимой, если однозначная
идентификация экземпляра сущности зависит от его отношения к другой сущности
(рисунок 2.30).
Рис. 2.30. Сущности
Каждой сущности присваивается уникальное имя и номер, разделяемые косой
чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или
мощности (количества экземпляров сущности-потомка, которое может существовать для
32
каждого экземпляра сущности-родителя). В IDEF1X могут быть выражены следующие
мощности связей:
- каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с
ним экземпляров сущности-потомка;
- каждый экземпляр сущности-родителя должен иметь не менее одного связанного с
ним экземпляра сущности-потомка;
- каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним
экземпляра сущности-потомка;
- каждый экземпляр сущности-родителя связан с некоторым фиксированным числом
экземпляров сущности-потомка.
Если экземпляр сущности-потомка однозначно определяется своей связью с
сущностью-родителем, то связь называется идентифицирующей, в противном случае неидентифицирующей.
Связь изображается линией, проводимой между сущностью-родителем и
сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи
обозначается как показано на рис. 2.31 (мощность по умолчанию - N).
Рис. 2.31. Мощность связи
Идентифицирующая связь между сущностью-родителем и сущностью-потомком
изображается сплошной линией (рисунок 2.32). Сущность-потомок в идентифицирующей
связи является зависимой от идентификатора сущностью. Сущность-родитель в
идентифицирующей связи может быть как независимой, так и зависимой от
идентификатора сущностью (это определяется ее связями с другими сущностями).
Рис. 2.32. Идентифицирующая связь
Пунктирная линия изображает неидентифицирующую связь (рисунок 2.33).
Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора,
если она не является также сущностью-потомком в какой-либо идентифицирующей связи.
33
Рис. 2.33. Неидентифицирующая связь
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты,
определяющие первичный ключ, размещаются наверху списка и отделяются от других
атрибутов горизонтальной чертой (рисунок 2.34).
Рис. 2.34. Атрибуты и первичные ключи
Сущности могут иметь также внешние ключи (Foreign Key), которые могут
использоваться в качестве части или целого первичного ключа или неключевого атрибута.
Внешний ключ изображается с помощью помещения внутрь блока сущности имен
атрибутов, после которых следуют буквы FK в скобках (рисунок 2.35).
Рис. 2.35. Примеры внешних ключей
Подход, используемый в CASE-средстве Vantage Team Builder
В CASE-средстве Vantage Team Builder (Westmount I-CASE) используется один из
вариантов нотации П. Чена. На ER-диаграммах сущность обозначается прямоугольником,
содержащим имя сущности (рисунок 2.36), а связь - ромбом, связанным линией с каждой
из взаимодействующих сущностей. Числа над линиями означают степень связи.
Рис. 2.36. Обозначение сущностей и связей
Связи являются многонаправленными и могут иметь атрибуты (за исключением
ключевых). Выделяют два вида связей:
необязательная связь (optional);
34
слабая связь (weak).
В необязательной связи (рисунок 2.37) могут участвовать не все экземпляры
сущности.
Рис. 2.37. Необязательная связь
В отличие от необязательной связи в полной (total) связи участвуют все
экземпляры хотя бы одной из сущностей. Это означает, что экземпляры такой связи
существуют только при условии существования экземпляров другой сущности. Полная
связь может иметь один из 4-х видов: обязательная связь, слабая связь, связь "супертипподтип" и ассоциативная связь.
Обязательная (mandatory) связь описывает связь между "независимой" и
"зависимой" сущностями. Все экземпляры зависимой ("обязательной") сущности могут
существовать только при наличии экземпляров независимой ("необязательной")
сущности, т.е. экземпляр "обязательной" сущности может существовать только при
условии существования определенного экземпляра "необязательной" сущности.
В примере (рисунок 2.38) подразумевается, что каждый автомобиль имеет по
крайней мере одного водителя, но не каждый служащий управляет машиной.
Рис. 2.38. Обязательная связь
В слабой связи существование одной из сущностей, принадлежащей некоторому
множеству ("слабой") зависит от существования определенной сущности, принадлежащей
другому множеству ("сильной"), т.е. экземпляр "слабой" сущности может быть
идентифицирован только посредством экземпляра "сильной" сущности. Ключ "сильной"
сущности является частью составного ключа "слабой" сущности.
Слабая связь всегда является бинарной и подразумевает обязательную связь для
"слабой" сущности. Сущность может быть "слабой" в одной связи и "сильной" в другой,
но не может быть "слабой" более, чем в одной связи. Слабая связь может не иметь
атрибутов.
Пример на рисунке 2.39: ключ (номер) строки в документе может не быть
уникальным и должен быть дополнен ключом документа.
Рис. 2.39. Слабая связь
Связь "супертип-подтип" изображена на рисунке 2.40. Общие характеристики
(атрибуты) типа определяются в сущности-супертипе, сущность-подтип наследует все
характеристики супертипа. Экземпляр подтипа существует только при условии
существования определенного экземпляра супертипа. Подтип не может иметь ключа (он
импортирует ключ из супертипа). Сущность, являющаяся супертипом в одной связи,
может быть подтипом в другой связи. Связь супертипа не может иметь атрибутов.
Рис. 2.40. Связь "супертип-подтип"
35
В ассоциативной связи каждый экземпляр связи (ассоциативный объект) может
существовать только при условии существования определенных экземпляров каждой из
взаимосвязанных сущностей. Ассоциативный объект - объект, являющийся одновременно
сущностью и связью. Ассоциативная связь - это связь между несколькими
"независимыми" сущностями и одной "зависимой" сущностью. Связь между
независимыми сущностями имеет атрибуты, которые определяются в зависимой
сущности. Таким образом, зависимая сущность определяется в терминах атрибутов связи
между остальными сущностями.
В примере на рисунке 2.41 самолет выполняет посадку на взлетную полосу в
заданное время при определенной скорости и направлении ветра. Поскольку эти
характеристики применимы только к конкретной посадке, они являются атрибутами
посадки, а не самолета или взлетной полосы. Пилот, выполняющий посадку, связан
гораздо сильнее с конкретной посадкой, чем с самолетом или взлетной полосой.
Рис. 2.41. Ассоциативная связь
Первичный ключ каждого типа сущности помечается звездочкой (*).
ER-диаграмма должна подчиняться следующим правилам:
каждая сущность, каждый атрибут и каждая связь должны иметь имя (связь
супертипа или ассоциативная связь может не иметь имени);
имя сущности должно быть уникально в рамках модели данных;
имя атрибута должно быть уникально в рамках сущности;
имя связи должно быть уникально, если для нее генерируется таблица БД;
каждый атрибут должен иметь определение типа данных;
сущность в необязательной связи должна иметь ключевой атрибут. То же самое
относится к сильной сущности в слабой связи, супертипу в связи "супертип-подтип" и
необязательной сущности в обязательной (полной) связи;
подтип в связи "супертип-подтип" не может иметь ключевой атрибут;
в ассоциативной или слабой связи может быть только одна ассоциативная (слабая)
сущность;
связь не может быть одновременно обязательной, "супертип-подтип" или
ассоциативной.
Пример использования структурного подхода
Описание предметной области
В данном примере используется методология Yourdon, реализованная в CASEсредстве Vantage Team Builder.
В качестве предметной области используется описание работы видеобиблиотеки,
которая получает запросы на фильмы от клиентов и ленты, возвращаемые клиентами.
Запросы рассматриваются администрацией видеобиблиотеки с использованием
информации о клиентах, фильмах и лентах. При этом проверяется и обновляется список
арендованных лент, а также проверяются записи о членстве в библиотеке. Администрация
контролирует также возвраты лент, используя информацию о фильмах, лентах и список
арендованных лент, который обновляется. Обработка запросов на фильмы и возвратов
лент включает следующие действия: если клиент не является членом библиотеки, он не
имеет права на аренду. Если требуемый фильм имеется в наличии, администрация
информирует клиента об арендной плате. Однако, если клиент просрочил срок возврата
имеющихся у него лент, ему не разрешается брать новые фильмы. Когда лента
36
возвращается, администрация рассчитывает арендную плату плюс пени за
несвоевременный возврат.
Видеобиблиотека получает новые ленты от своих поставщиков. Когда новые ленты
поступают в библиотеку, необходимая информация о них фиксируется. Информация о
членстве в библиотеке содержится отдельно от записей об аренде лент.
Администрация библиотеки регулярно готовит отчеты за определенный период
времени о членах библиотеки, поставщиках лент, выдаче определенных лент и лентах,
приобретенных библиотекой.
Организация проекта
Весь проект разделяется на 4 фазы: анализ, глобальное проектирование
(проектирование архитектуры системы), детальное проектирование и реализация
(программирование).
На фазе анализа строится модель среды (Environmental Model). Построение модели
среды включает:
- анализ поведения системы (определение назначения ПС, построение начальной
контекстной диаграммы потоков данных (DFD) и формирование матрицы списка
событий (ELM), построение контекстных диаграмм);
- анализ данных (определение состава потоков данных и построение диаграмм структур
данных (DSD), конструирование глобальной модели данных в виде ER-диаграммы).
Назначение ПС определяет соглашение между проектировщиками и заказчиками
относительно назначения будущей ПС, общее описание ПС для самих проектировщиков и
границы ПС. Назначение фиксируется как текстовый комментарий в "нулевом" процессе
контекстной диаграммы.
Например, в данном случае назначение ПС формулируется следующим образом:
ведение базы данных о членах библиотеки, фильмах, аренде и поставщиках. При этом
руководство библиотеки должно иметь возможность получать различные виды отчетов
для выполнения своих задач.
Перед построением контекстной DFD необходимо проанализировать внешние
события (внешние объекты), оказывающие влияние на функционирование библиотеки.
Эти объекты взаимодействуют с ПС путем информационного обмена с ней.
Из описания предметной области следует, что в процессе работы библиотеки
участвуют следующие группы людей: клиенты, поставщики и руководство. Эти группы
являются внешними объектами. Они не только взаимодействуют с системой, но также
определяют ее границы и изображаются на начальной контекстной DFD как терминаторы
(внешние сущности).
Начальная контекстная диаграмма изображена на рисунке 2.42. В отличие от
нотации Gane/Sarson внешние сущности обозначаются обычными прямоугольниками, а
процессы - окружностями.
37
Рис. 2.42. Начальная контекстная диаграмма
Список событий строится в виде матрицы (ELM) и описывает различные действия
внешних сущностей и реакцию ПС на них. Эти действия представляют собой внешние
события, воздействующие на библиотеку. Различают следующие типы событий:
Аббревиатура
Тип
NC
Нормальное управление
ND
Нормальные данные
NCD
Нормальное управление/данные
TC
Временное управление
TD
Временные данные
TCD
Временное управление/данные
Все действия помечаются как нормальные данные. Эти данные являются
событиями, которые ПС воспринимает непосредственно, например, изменение адреса
клиента, которое должно быть сразу зарегистрировано. Они появляются в DFD в качестве
содержимого потоков данных.
Матрица списка событий имеет следующий вид:
№ Описание
Тип Реакция
1 Клиент желает стать членом библиотеки
ND Регистрация клиента
члена библиотеки
2 Клиент сообщает об изменении адреса
ND Регистрация
клиента
3 Клиент запрашивает аренду фильма
ND Рассмотрение запроса
4 Клиент возвращает фильм
ND Регистрация возврата
5 Руководство предоставляет
новому поставщику
в
измененного
качестве
адреса
полномочия ND Регистрация поставщика
6 Поставщик сообщает об изменении адреса ND Регистрация
поставщика
измененного
адреса
7 Поставщик направляет фильм в библиотеку ND Получение нового фильма
8 Руководство запрашивает новый отчет
ND Формирование требуемого
для руководства
отчета
38
Для завершения анализа функционального аспекта поведения системы строится
полная контекстная диаграмма, включающая диаграмму нулевого уровня. При этом
процесс "библиотека" декомпозируется на 4 процесса, отражающие основные виды
административной деятельности библиотеки. Существующие "абстрактные" потоки
данных между терминаторами и процессами трансформируются в потоки,
представляющие обмен данными на более конкретном уровне. Список событий
показывает, какие потоки существуют на этом уровне: каждое событие из списка должно
формировать некоторый поток (событие формирует входной поток, реакция - выходной
поток). Один "абстрактный" поток может быть разделен на более чем один "конкретный"
поток.
Потоки на диаграмме Потоки на диаграмме нулевого уровня
верхнего уровня
Информация от клиента Данные о клиенте, Запрос об аренде
Информация
клиента
для
Информация
руководства
от
Информация
руководства
Членская карточка, Ответ на запрос об аренде
Запрос отчета о новых членах, Новый поставщик, Запрос отчета
о поставщиках, Запрос отчета об аренде, Запрос отчета о
фильмах
для Отчет о новых членах, Отчет о поставщиках, Отчет об аренде,
Отчет о фильмах
Информация
от
Данные о поставщике, Новые фильмы
поставщика
На приведенной DFD (рисунок 2.43) накопитель данных "библиотека" является
глобальным или абстрактным представлением хранилища данных.
Анализ функционального аспекта поведения системы дает представление об
обмене и преобразовании данных в системе. Взаимосвязь между "абстрактными"
потоками данных и "конкретными" потоками данных на диаграмме нулевого уровня
выражается в диаграммах структур данных (рисунок 2.44).
На фазе анализа строится глобальная модель данных, представляемая в виде
диаграммы "сущность-связь" (рисунок 2.45).
Между различными типами диаграмм существуют следующие взаимосвязи:
ELM-DFD: события - входные потоки, реакции - выходные потоки
DFD-DSD: потоки данных - структуры данных верхнего уровня
DFD-ERD: накопители данных - ER-диаграммы
DSD-ERD: структуры данных нижнего уровня - атрибуты сущностей
На фазе проектирования архитектуры строится предметная модель. Процесс
построения предметной модели включает в себя:
- детальное описание функционирования системы;
- дальнейший анализ используемых данных и построение логической модели данных
для последующего проектирования базы данных;
- определение структуры пользовательского интерфейса, спецификации форм и порядка
их появления;
- уточнение диаграмм потоков данных и списка событий, выделение среди процессов
нижнего уровня интерактивных и неинтерактивных, определение для них
миниспецификаций.
39
Рис. 2.43. Контекстная диаграмма
40
-
Рис. 2.44. Диаграмма структур данных
Результатами проектирования архитектуры являются:
модель процессов (диаграммы архитектуры системы (SAD) и миниспецификации на
структурированном языке);
модель данных (ERD и подсхемы ERD);
модель пользовательского интерфейса (классификация процессов на интерактивные и
неинтерактивные функции, диаграмма последовательности форм (FSD - Form Sequence
Diagram), показывающая, какие формы появляются в приложении и в каком порядке.
На FSD фиксируется набор и структура вызовов экранных форм. Диаграммы FSD
образуют иерархию, на вершине которой находится главная форма приложения,
реализующего подсистему. На втором уровне находятся формы, реализующие
процессы нижнего уровня функциональной структуры, зафиксированной на
диаграммах SAD.
41
Рис. 2.45. Диаграмма "сущность-связь"
На фазе детального проектирования строится модульная модель. Под модульной
моделью понимается реальная модель проектируемой прикладной системы. Процесс ее
построения включает в себя:
- уточнение модели базы данных для последующей генерации SQL-предложений;
- уточнение структуры пользовательского интерфейса;
- построение структурных схем, отражающих логику работы пользовательского
интерфейса и модель бизнес-логики (Structure Charts Diagram - SCD) и привязка их к
формам.
Результатами детального проектирования являются:
- модель процессов (структурные схемы интерактивных и неинтерактивных функций);
- модель данных (определение в ERD всех необходимых параметров для приложений);
- модель пользовательского интерфейса (диаграмма последовательности форм (FSD),
показывающая, какие формы появляются в приложении и в каком порядке,
взаимосвязь между каждой формой и определенной структурной схемой, взаимосвязь
между каждой формой и одной или более сущностями в ERD).
На фазе реализации строится реализационная модель. Процесс ее построения
включает в себя:
- генерацию SQL-предложений, определяющих структуру целевой БД (таблицы,
индексы, ограничения целостности);
- уточнение структурных схем (SCD) и диаграмм последовательности форм (FSD) с
последующей генерацией кода приложений.
На основе анализа потоков данных и взаимодействия процессов с хранилищами
данных осуществляется окончательное выделение подсистем (предварительное должно
было быть сделано и зафиксировано на этапе формулировки требований в техническом
задании). При выделении подсистем необходимо руководствоваться принципом
функциональной связанности и принципом минимизации информационной зависимости.
Необходимо учитывать, что на основании таких элементов подсистемы как процессы и
данные на этапе разработки должно быть создано приложение, способное
функционировать самостоятельно. С другой стороны при группировке процессов и
данных в подсистемы необходимо учитывать требования к конфигурированию продукта,
если они были сформулированы на этапе анализа.
42
Объектно-ориентированный подход к проектированию ПО. Основные
положения объектной модели. Классы и объекты
Сложность программного обеспечения требует применения декомпозиции для его
разработки. Структурный подход основан на алгоритмической декомпозиции. Т.е. мы
выделяем основную функцию системы, а потом последовательно выделяем в каждой
функции подфункции. О такой подход является неестественным. Если провести аналогию
с разговорным языком. Аналог функциональной декомпозиции это предложения, не
имеющие подлежащих, а только сказуемые: «Темнеет.» «Холодает.» и т.д. Выразительная
способность таких предложений невелика. Хотелось бы, чтобы было и подлежащее, т.е.
объект. И это уже объектно-ориентированный подход.
В рамках объекно-ориентированного подхода выделяют ОО программирование,
ОО проектирование и ОО анализ.
ОО программирование – это методология программирования, основанная на
представлении программы в виде совокупности объектов, каждый из которых является
экземпляром определенного класса, а классы образуют иерархию наследования.
В данном определении можно выделить три части:
1. ООП использует в качестве базовых элементов объекты, а не алгоритмы
2. Каждый объект является экземпляром какого-либо класса
3. Классы организованы иерархически.
ОО проектирование – это методология проектирования, соединяющая в себе
процесс объектной декомпозиции и приемы представления логической и физической а
также статической и динамической моделей проектируемой системы.
В данном определении содержатся две важные части ООD:
1. основывается на ОО декомпозиции
2. используется многообразие приемов представления моделей, отражающих
логическую (классы и объекты) и физическую (модули и процессы) структуру системы, а
также ее статические и динамические аспекты.
ОО проектирование отличается от структурного именно использованием ОО
декомпозиции.
ОО анализ – это методология, при которой требования к системе воспринимаются
с точки зрения классов и объектов, выявленных в предметной области.
Объектно-ориентированная модель
Концептуальной основой объектно-ориентированного подхода является объектная
модель. Она имеет четыре главных элемента:
- абстрагирование
- инкапсуляция
- модульность
- иерархия.
Главных в том смысле, что без них модель не будет объектной.
И три дополнительных элемента:
- типизация
- параллелизм
- сохраняемость (устойчивость)
Абстрагирование. Абстрагирование – один из основных методов, применяемых
для решения сложных задач. Абстрагирование проявляется в нахождении сходств между
определенными объектами, ситуациями или процессами реального мира, и в принятии
решений на основе этих сходств, отвлекаясь на время от существующих различий.
Можно определить это понятие так: Упрощенное описание или изложение
системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей
является та абстракция, которая подчеркивает детали, существенные для рассмотрения и
использования, и опускает те, которые на данный момент несущественны.
43
Разделение между существенными и несущественными особенностями называют
барьером абстракции.
Принцип, в соответствии с которым предлагается расположить этот барьер
называют принципом наименьшего удивления. Согласно ему абстракция должна
охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов
и побочных эффектов, лежащих вне сферы ее применимости.
Выбор правильного набора абстракций для заданной предметной области
представляет собой главную задачу объектно-ориентированного проектирования.
Существуют различные варианты абстракций. Они перечислены начиная от
наиболее полезных к наименее:
- абстракция сущности – объект представляет собой полезную модель некой сущности в
предметной области
- абстракция поведения – объект состоит из обобщенного множества операций
- абстракция виртуальной машины – объект группирует операции, которые либо вместе
используются более высоким уровнем управления, либо сами используют некоторый
набор операций более низкого уровня
- произвольная абстракция – объект включает в себя набор операций, не имеющих друг
с другом ничего общего.
Нужно стараться строить абстракции сущности, так как они прямо соответствуют
сущностям предметной области.
Инкапсуляция. Если абстракция позволяет выявить те свойства объекта, которые
интересны для внешнего вида, то инкапсуляция позволяет скрыть особенности их
реализации. Использование инкапсуляции позволяет добиться независимости одной части
сложной системы от внутреннего устройства другой части.
Абстракция и инкапсуляция дополняют друг друга и работать будут только вместе.
Практически это означает наличие двух частей в классе: интерфейса и реализации.
Инкапсуляция – это процесс отделения друг от друга элементов объекта,
определяющих его устройство и поведение.
Модульность. Разложение программы на модули до некоторой степени позволяет
уменьшить ее сложность. Однако важнее тот факт, что внутри модульной программы
создаются множества хорошо определенных и документированных интерфейсов.
Модульность – это разделение программы на фрагменты, которые компилируются
по отдельности, но могут устанавливать связи с другими модулями. Связи между
модулями – это их представления друг о друге. В большинстве языков, поддерживающих
модульность как самостоятельную концепцию, интерфейс модуля отделен от его
реализации. Таким образом модульность и инкапсуляция имеют много общего. В разных
языках программирования модульность поддерживается по разному. Например в С/C++
традиционным является помещение интерфейсной части модулей в отдельные файлы с
расширением .h. Реализация – в файл .c или .cpp. Но это исключительно договоренность и
не является требованием самого языка. В Object Pascal структура модуля оговорена
строго.
Правильное разделение программы на модули является почти такой же сложной
задачей, как выбор правильного набора абстракций. Это вызвано тем, что в начале работы
над проектом решения могут быть неясными и декомпозиция может быть затруднена.
Для небольших задач допустимо описание всех классов и объектов в одном
модуле. Однако для большинства программ лучшим решением будет сгруппировать в
отдельный модуль логически связанные классы и объекты, оставив открытыми те
элементы, которые совершенно необходимо видеть другим модулям. Такой способ
разделения хорош, но его можно довести до абсурда. Деление программ на модули
бессистемным образом иногда еще хуже, чем отсутствие модульности вообще.
В традиционном структурном проектировании модульность – это искусство
раскладывать подпрограммы по кучкам так, что бы в одну кучку попали подпрограммы,
44
использующие друг друга, или используемые вместе. В ООП ситуация несколько иная –
необходимо физически разделить классы и объекты, составляющие логическую структуру
проекта.
Общие рекомендации:
- структура модуля должна быть достаточно простой для восприятия
- реализация каждого модуля не должна зависеть от реализаций других модулей
- должны быть приняты меры для облегчения процесса внесения изменений там, где они
наиболее вероятны.
Перекомпиляция тела модуля не является трудоемкой процедурой, но при
изменении интерфейсной части модуля потребуется перекомпилировать все модули,
связанные с ним. В больших проектах это может быть достаточно трудоемко, кроме этого
имеют место организационные аспекты. Поэтому следует стремиться к тому, чтобы
интерфейсная часть модуля была возможно более узкой (в пределах обеспечения
необходимых связей). Все, что только возможно должно быть скрыто в реализации
модуля. Постепенный перенос описаний из реализации в интерфейсную часть гораздо
менее опасен, чем «вычищение» избыточного интерфейсного кода.
Таким образом, программист должен находиться между двумя противоположными
тенденциями: стремлением скрыть информацию и необходимостью обеспечения
видимости тех или иных абстракций в нескольких модулях. Предлагается следующее
правило: Особенности системы, подверженные изменениям, следует скрывать в
отдельных модулях; в качестве межмодульных следует использовать только те элементы,
вероятность изменения которых мала. Все структуры данных должны быть обособлены в
модуле; доступ к ним будет возможен из всех процедур этого модуля и закрыт для всех
других. Доступ к данным из модуля должен осуществляться только через процедуры
данного модуля.
В процессе разделения системы на модули могут быть полезны следующие
практические правила:
- выделять в отдельные модули код, который будет использоваться повторно;
- разделение на модули проводится в зависимости от того, кто будет их разрабатывать;
- неоправданное увеличение числа модулей приведет к черезмерному увеличению
документации на них.
Иерархия. Иерархия – это упорядочивание абстракций, расположение их по
уровням.
Основными видами иерархических структур, применительно к сложным системам,
являются структура классов (иерархия быть чем-то) и структура объектов (иерархия быть
частью чего-то).
Пример иерархии классов – наследование, которое еще называют иерархией
обобщение-специализация.
Пример иерархии объектов – агрегация – включение одного объекта в другой.
Более подробно будет рассмотрено далее.
Типизация. Понятие типа взято из абстрактных типов данных.
Типизация – это способ защитится от использования объектов одного класса
вместо другого, или по крайней мере управлять таким использованием.
Типизация заставляет нас выражать наши абстракции так, чтобы язык
программирования, используемый в реализации, поддерживал соблюдение принятых
проектных решений.
Типизация бывает сильная и слабая. Язык С++ тяготеет к слабой типизации
примитивных типов. Object Pascal напротив предоставляет для примитивных типов
сильную типизацию. Тогда как для классов оба они ближе к сильной типизации.
Присваивание переменных типа класс допустимо, если они одного типа или в
направлении снизу вверх по типам.
45
Параллелизм. Есть ситуации (обработка большого числа событий одновременно,
недостаточная вычислительная мощность одного процессора или компьютера) при
которых необходимо использовать параллельные процессы.
Возможности проектирования параллельности в ООЯ не сильно отличаются от
любых других.
Объект, который представляет отдельный поток управления называется активным.
Параллелизм – это свойство, которое отличает активные объекты от пассивных.
Сохраняемость. Любой программный объект существует в памяти и живет во
времени. Но здесь есть варианты:
- промежуточные результаты вычисления выражений
- локальные переменные в вызове процедур
- глобальные переменные или динамически создаваемые данные
- данные, сохраняющиеся между сеансами выполнения программы
- данные, сохраняемые при переходе на новую версию программы
- данные, которые переживают программу.
Традиционно, первыми двумя уровнями занимаются языки программирования, а
последними – базы данных. Этот конфликт культур приводит к тому, что программисты
разрабатывают специальные схемы для сохранения объектов в период между запусками
программы, а конструкторы БД переиначивают свою технология под короткоживущие
объекты. Тогда как следовало бы применять унифицированный подход.
Введение сохраняемости, как нормальной составной части объектноориентированного подхода приводит нас к объектно-ориентированным базам данных. На
практике такие базы данных строятся на основе обычных моделей – последовательных,
индексированных, иерархических, сетевых или реляционных, но программист может
ввести абстракцию объектно-ориентированного интерфейса, через который запросы к БД
и другие операции выполняются в терминах объектов, время жизни которых превосходит
время жизни отдельной программы. Кроме того появились ООСУБД.
Сохраняемость – это не только проблема сохранения данных. Иногда в БД следует
сохранять классы.
Сохраняемость – это способность объекта существовать во времени, переживая
породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального
адресного пространства.
Преимущества объектной модели
Наиболее важно то, что объектный подход позволяет создавать системы, которые
удовлетворяют пяти признакам хорошо структурированных сложных систем.
Кроме этого есть следующие преимущества:
1. объектная модель позволяет в полной мере использовать возможности ООЯ
2. использование объектного подхода существенно повышает уровень
унификациии разработки и пригодность для повторного использования не
только программ, но и проектов, что в конце концов ведет к созданию среды
разработки.
3. использование объектной модели приводит к построению систем на основе
стабильных промежуточных описаний, что упрощает процесс внесения
изменений. Это дает возможность системе развиваться постепенно и не
приводит к полной переработке ее даже в случае существенных изменений
исходных требований.
4. объектная модель уменьшает риск разработки сложных систем, прежде всего
потому, что процесс интеграции растягивается на все время разработки, а не
превращается в единовременное событие. Объектный подход состоит из ряда
хорошо продуманных этапов проектирования, что также уменьшает степень
риска и повышает уверенность в правильности принимаемых решений.
5. объектная модель ориентирована на человеческое восприятия мира.
46
Классы и объекты
Природа объекта
Неформально объект может быть определен как осязаемая реальность,
проявляющая четко выделяемое поведение. С точки зрения восприятия человеком
объектом может быть:
- осязаемый или видимый предмет,
- нечто, воспринимаемое мышлением,
- нечто, на что направлена мысль или действие.
Таким образом объект в человеческом восприятии – это модель части окружающей
действительности и именно в таком смысле термин объект был впервые введен в
программировании. Но объекты в программировании – это не только объекты реального
мира. Это могут быть например процессы или виртуальные машины.
Объект – нечто, обладающее состоянием, поведением и идентичностью; структура
и поведение схожих объектов определяет общий для них класс; термины «экземпляр
класса» и «объект» взаимозаменяемы.
Состояние
Во многих ситуациях поведение объекта определяется его историей – важна
последовательность совершаемых над объектом действий. Такая зависимость поведения
от предшествующих событий объясняется тем, что у объекта есть внутреннее состояние.
Состояние объекта характеризуется перечнем (обычно статическим) всех свойств
данного объекта и текущими (обычно динамическими) значениями каждого из этих
свойств.
Перечень свойств объекта составляет неизменяемую основу объекта. Но в ряде
случаев состав свойств объекта может изменяться. Пример – самообучающиеся системы.
Все свойства имеют некоторые значения – простые количественные
характеристики или ссылки на другой объект. Причем другие объекты в свою очередь
имеют свое внутренне состояние и могут его изменять.
Поведение
Объекты не существуют изолированно, а подвергаются воздействию извне, или
сами воздействуют на другие объекты.
Поведение – это то, как объект действует и реагирует; поведение выражается в
терминах состояния объекта и передачи сообщений.
Для описания процесса взаимодействия объектов применительно к разным языкам
программирования используются разные термины: передача сообщений, вызов методов
или функций-членов. Поведение объекта с одной стороны определяется воздействием на
него со стороны других объектов. С другой стороны оно определяется текущим
состоянием самого объекта. В результате поведения объекта его состояние может
меняться.
Поведение объекта может быть выражено через операции.
Операция – это услуга, которую класс может предоставить своим клиентам.
Наиболее распространенные операции:
- модификатор – изменяет состояние объекта,
- селектор – считывает состояние объекта, но не изменяет его,
- итератор – позволяет организовать доступ ко всем частям объекта в строго
определенной последовательности,
- конструктор – создание объекта и/или его инициализация,
- деструктор – освобождает состояние объекта и/или разрушает сам объект.
Чаще всего операции – это методы. Но возможно использование и свободных
подпрограмм, которые также называют утилитами класса.. Рекомендуется использовать
только методы, но возможны ситуации – например если операция выполняется сразу над
несколькими объектами разных классов – когда удержаться от искушения организовать
операцию как свободную подпрограмму сложно.
47
Совокупность всех методов и свободных процедур, относящихся к конкретному
объекту, образует протокол этого объекта. Протокол определяет поведение объекта. В
сложных абстракциях полезно подразделять протокол на частные аспекты поведения,
которые называют ролями. Роль – это маска, которую носит объект, она определяет
контракт абстракции с ее клиентами. Например компьютер можно рассматривать как
машину для обработки информации с соответствующими характеристиками, как товар,
имеющий цену или как груз при перевозке по железной дороге.
Наличие внутреннего состояния, от которого зависит поведение приводит к тому,
что объект может быть формально описан как конечный автомат.
Идентичность
Идентичность – это такое свойство объекта, которое отличает его от всех других
объектов.
Не следует путать адресуемость и идентичность, что происходит при
программировании, когда объекты именуют. Также не следует путать идентичность и
значение данных, что характерно для баз данных, где объекты различают по ключевому
атрибуту.
Рассмотрим пример:
DisplayItem item1;
DisplayItem * item2 = new DisplayItem(Point(75,75));
DisplayItem * item3 = new DisplayItem(Point(100,100));
DisplayItem * item4;
Создали три объекта – объект item1 и два объекта, на которых указывают указатели
item2 и item3. Первый по умолчанию расположен в точке с нулевыми координатами, два
других в различных определенных областях экрана.
item1.move(item2->location());
item4 = item3;
item4->move(Point(38,100);
Объект item1 и объект, на который указывает item2 имеют одинаковое состояние,
но остаются разными объектами. На один из объектов указывают два указателя: item3 и
item4, но это один и тот же объект – такую ситуацию называют структурной
зависимостью.
Структурная зависимость порождает в ООП много проблем: утечку памяти,
неправильный доступ к памяти, непрогнозируемые изменения состояний.
Отношения между объектами
Сами по себе объекты не представляют никакого интереса: система реализуется в
процессе их взаимодействия. Если подход структурный, то мы имеем ряд функций
последовательно, по жестко заданному алгоритму преобразующих входные данные в
результат. Если же подход объектный, то программа представляет собой сообщество
хорошо воспитанных объектов, которые вежливо просят друг друга об услугах. Причем
свойства и поведение системы в целом определяется не столько свойствами и поведением
каждого отдельного компонента, сколько их взаимодействием. Например самолет, по
определению – совокупность элементов, каждый из которых по своей природе стремиться
упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту
тенденцию.
Для ООП интерес представляют два типа отношений между объектами:
- связи,
- агрегация.
48
Связи определяются как физическое или концептуальное соединение между
объектами. Объект сотрудничает с другими объектами через связи, соединяющие его с
ними.
Объект, который запрашивает услугу называют клиентом. Объект, который услугу
предоставляют, называют сервером. В этих терминах связь может быть определена
следующим образом: Связь – это сопоставление, через которое клиент запрашивает
услугу у объекта-сервера или через которое один объект находит путь к другому. Обычно
связь осуществляется через вызов метода.
Связь между объектами и передача сообщений обычно односторонняя, хотя
технически она может быть и взаимной. Но, хотя передаваемое сообщение инициируется
клиентом, данные передаются в обоих направлениях – данные и результат.
Объект может выполнять одну из следующих трех ролей:
- Деятель – может воздействовать на другие объекты, но сам никогда не подвергается
воздействию;
- Сервер – может только подвергаться воздействию;
- Агент – может выступать как в активной, так и в пассивной роли.
С проблемой установки связи между объектами связана проблема видимости.
Пусть есть два объекта А и В. Чтобы послать сообщение из А в В нужно, чтобы В
был в каком-то смысле видим для А. На стадии анализа об этом можно не заботиться, но
на стадии реализации видимость объектов должна быть обеспечена.
Существуют следующие способы обеспечить видимость:
- сервер глобален по отношению к клиенту,
- сервер (или указатель на него) передан клиенту в качестве параметра операции,
- сервер является частью клиента,
- сервер локально порождается клиентом в ходе выполнения какой-либо операции.
Агрегация. В то время как связи описывают равноправные отношения между
объектами типа клиент-сервер, агрегация описывает отношение целого и части,
приводящие к соответствующей иерархии объектов, причем идя от целого (агрегата),
можно придти к его частям (атрибутам).
Агрегация может означать физическое вхождение одного объекта в другой, но не
обязательно. Например: самолет состоит из крыльев, акционер владеет акциями.
Выбирая одно из двух – связь или агрегацию – надо иметь в виду следующее.
Агрегация предпочтительнее, когда следует скрыть части в целом. Иногда связи
предпочтительнее, поскольку они слабее и менее ограничительны.
Объект, являющийся атрибутом другого объекта (агрегата), имеет связь со своим
агрегатом. Через эту связь агрегат может посылать ему сообщения.
Природа класса
Класс – это некое множество объектов, имеющих общую структуру и общее
поведение.
Объект означает конкретную сущность, определенную во времени и пространстве,
класс определяет лишь абстракцию существенного объекте. Любой конкретный объект
является экземпляром класса. Таким образом, для того, чтобы использовать в программе
объект, нужно разработать класс, которому он принадлежит.
Лежащая в основе ООП идея инкапсуляции требует разграничения внешнего
облика, т.е. интерфейса, и внутреннего устройства – т.е. реализации. Реализация класса
никому, кроме него самого не интересна. Главное в интерфейсе – объявление операций,
поддерживаемых экземплярами класса.
Интерфейс класса может быть разделен на три части:
- открытую – видимую всем клиентам;
- защищенную – видимую самому классу, его подклассам и друзьям;
- закрытую – видимую только самому классу и его друзьям.
49
Разные языки программирования предусматривают разные комбинации этих
частей.
Отношения между классами
Имеются следующие виды отношений:
- ассоциация,
- наследование,
- агрегация,
- использование,
- инстацирование,
- метакласс.
Наиболее общим из них является ассоциация. Обычно в процессе проектирования
ассоциация уточняется и превращается в какую-либо иную связь.
Ассоциация означает что есть какая-то связь, не уточняя ее характер. Ассоциация
должна работать в обе стороны. Например торговая точка: две абстракции – товары и
продажи. Они связаны. Задавшись товаром, можно выйти на сделку когда он был продан
и наоборот.
Реализация отношения типа ассоциация, означает, что классы должны содержать
ссылки друг на друга.
Обычно этот тип отношения не реализуется, а заменяется другим в процессе
проектирования.
Ассоциация обладает мощностью:
- один-к-одному,
- один-ко-многим,
- многие-ко-многим.
Наследование – это такое отношение между классами, когда один класс повторяет
структуру и поведение другого класса (одиночное наследование) или других классов
(множественное наследование).
Класс, структура и поведение которого наследуется называется предком или
родительским классом или базовым классом или суперклассом.
Производный класс называется потомком или дочерним классом или производным
классом или подклассом.
Наследование используется, если у объектов есть что-то общее или между ними
есть смысловая ассоциация.
Наследование можно рассматривать как способ управления повторным
использованием программ, то есть как простое решение разработчика о заимствовании
полезного кода.
Наследование обычно предполагает наличие полиморфизма.
Наследование бывает одиночным и множественным.
При множественном наследовании возникают две проблемы: конфликты имен
между различными классами-предками и повторное наследование. Первый случай – это
когда в двух или большем числе предков определено поле или метод с одинаковым
именем. В разных языках программирования этот конфликт решается по-разному. В С++
этот конфликт должен быть явно разрешен вручную. Повторное наследование – это когда
класс наследует двум классам, а они порознь наследуют одному и тому же четвертому.
Получается ромбовидная структура наследования и надо решать, должен ли самый
нижний класс получить одну или две копии самого верхнего? В С++ это остается на
усмотрение программиста.
При множественном наследовании часто используется прием создания классовпримесей. Идея примесей – можно комбинировать (смешивать) небольшие классы, чтобы
строить классы с более сложным поведением. Синтаксически примесь ничем не
отличается от класса, но их использование различно. Примесь не предназначена для
50
порождения самостоятельно используемых экземпляров – она смешивается с другими
классами. Классы, сконструированные целиком из примесей, называют агрегатными.
Агрегация. Отношение агрегации между классами имеет непосредственное
отношение к агрегации между их экземплярами.
Агрегация бывает по значению и по ссылке. При включении по ссылке важно
обеспечить создание и уничтожение включаемых объектов.
Скрытую агрегацию можно применять в языках с одиночным наследованием чтобы
обеспечить подобие множественного наследования.
Для того, чтобы понять наследование или агрегация имеет место следует задаться
вопросом – имеет место отношение «быть чем-то» или «являться частью чего-то». В
первом случае – наследование, во втором – агрегация.
Использование. Отношение использования между классами соответствует
аналогичной связи между их объектами – отношения клиент-сервер.
Инстацирование. При инстацировании разрабатывается обобщенный класс,
который еще называют параметризованным. Он представляет собой что-то вроде шаблона
для построения других классов. Шаблон может быть параметризован другими классами,
объектами или операциями. Т.е. какие-то части описания и реализации класса, которые
могут отличаться, заменены обозначениями. Далее эти обозначения – параметры можно
заменить на конкретные имена типов, процедур и т.д. с помощью например команд
препроцессора. Естественно, что параметризованный класс не является синтаксически
правильным.
Если класс порожден от параметризованного класса, то говорят что между ними
отношение инстацирования.
Наследование вообще более мощный механизм и через наследование можно
получить большинство преимуществ обобщенных классов, но не наоборот.
Метаклассы. Любой объект является экземпляром какого-либо класса. Что будет,
если обращаться с классами как с объектами? Получится класс класса – метакласс.
Назначение метакласса – поддержка переменных класса (аналог статических полей
в С++) и инициализация. Метаклассы можно использовать для порождения экземпляров
класса – аналог в С++ конструкторы и деструкторы.
Унифицированный язык моделирования UML
В определении ОО проектирования можно выделить две основных части: 1 - оно
основывается на ОО декомпозиции; 2 – должны быть представлены логическая и
физическая а также динамическая и статическая модели проектируемой системы.
Логическая модель должна представлять классы и объекты с их полями методами и
свойствами, описывающими состояние и поведение и характеризующимися областями
видимости. Взаимодействие объектов (связи, агрегация). Отношения между классами –
ассоциация, наследование и др. Причем все это должно быть рассмотрено не только в
статике, но и в динамике. Статическая модель это обычно классы и их взаимодействие.
Динамическая – объекты, их поведение, выражающееся в изменении внутреннего
состояния и взаимодействии друг с другом. Кроме этого должна быть разработана
физическая модель, которая показывает как логическая структура будет разложена на
модули, компоненты, динамические библиотеки и тому подобное.
Понятно, что для описания всех этих аспектов необходимо использовать
формальные средства представления информации, желательно графические.
Для объектно-ориентированного проектирования существуют несколько вариантов
нотаций. Наиболее известны – нотация Буча, технология объектного моделирования
(OMT, Object Modeling Technology) и унифицированный язык моделирования (UML,
Unified Modeling Language), который был разработан на основе двух предыдущих. В
51
настоящее время UML наиболее распространен, принят многими производителями и
комитетами по стандартам.
Первая версия UML – UML 1 появилась в январе 1997 г. В настоящее время
происходит процесс развития и усовершенствования UML на пути интеграции с другими
технологиями – CORBA, XML и др.
UML позволяет создавать несколько типов визуальных диаграмм:
- диаграммы вариантов использования (Use Case diagram)
- диаграммы последовательности (Sequence diagram)
- кооперативные диаграммы (Collaboration diagram)
- диаграммы классов (Class diagram)
- диаграммы состояний (State diagram)
- диаграммы компонентов (Component diagram)
- диаграммы размещения (Deployment diagram)
Они служат для представления различных аспектов программной системы. И
используются разными людьми.
Диаграммы вариантов использования
Диаграмма вариантов использования отображают взаимодействие между
вариантами использования, представляющими функции системы, и действующими
лицами (actors), представляющими людей или системы, получающими или передающими
информацию в данную систему.
Вариант использования (use case) – это описание функциональности системы на
«высоком уровне».
Действующее лицо (actor) – это все, что взаимодействует с системой (человек или
другая система).
Диаграмма вариантов использования отражает требования к системе с точки зрения
пользователей. Таким образом, варианты использования – это функции, выполняемые
системой, а действующие лица – это заинтересованные лица по отношению к создаваемой
системе. Диаграмма показывает, какие действующие лица инициируют варианты
использования. Кроме того из них видно, если действующее лицо получает информацию
от вариантов использования. Таким образом, диаграмма вариантов использования может
иллюстрировать требования к системе без подробностей о ее реализации.
Конкретная цель диаграмм вариантов использования – документирование
вариантов использования, действующих лиц и связей между ними.
Ее могут использовать пользователи, менеджеры проектов, аналитики,
разработчики, специалисты по контролю качества.
Варианты использования – эллипсы, действующие лица – фигурки человека.
52
Перевести деньги
Банковский
служащий
использует
Положить деньги на
счет
Изменить идент-онный
номер
Идентифицировать
использует
клиента
Снять деньги со счета
Произвести оплату
Клиент
Кредитная
система
расширяет
Показать баланс
Произвести
ускоренную выплату
Диаграмма вариантов использования для банковского автомата
В дополнение к связям между действующими лицами и вариантами использования
существует два других типа связей: «использование» и «расширение» между вариантами
использования.
Связь типа «использование» (uses) применяется в тех ситуациях, когда имеется
какой-либо фрагмент поведения системы, который повторяется более, чем в одном
варианте использования, и нет необходимости копировать его описание в каждом из этих
вариантов.
Связь типа «расширение» (extends) применяется тогда, когда один вариант
использования подобен другому, но несет большую нагрузку. В примере вариант
использования «Снять деньги» иногда применяет функциональные возможности,
предоставляемые вариантом «Произвести ускоренную выплату». «Снять деньги» нормальный ход событий. «Произвести ускоренную выплату» - ход событий
ненормальный, инициируемый клиентом.
Разница в применении:
Связь «расширение» следует применять при описании изменений в нормальном
поведении системы;
Связь использование – для избежания повторов в двух или более вариантах
использования.
Преимущество вариантов использования заключается в том, что можно отделить
реализацию системы от описания ее принципиальных основ. Они позволяют заострить
внимание на наиболее важных вещах – удовлетворение потребностей и ожиданий
заказчиков – без углубления в детали реализации.
При проектировании системы возникает вопрос – как обнаружить варианты
использования – лучше всего прочитать документацию заказчика или общаться с
заказчиком. Каждому заинтересованному лицу можно задать следующие вопросы:
- что он хочет делать с системой,
- будет ли он с ее помощью работать с информацией,
53
-
нужно ли будет информировать систему о внешних событиях
должна ли система информировать его о каких-либо изменениях.
Чтобы убедится, что обнаружили все варианты использования задают следующие
вопросы:
- присутствует ли каждое функциональное требование хотя бы в одном варианте
использования
- учтено ли как с системой будет работать каждое заинтересованное лицо
- какую информацию будет передавать системе каждое заинтересованное лицо,
- учтены ли проблемы, связанные с эксплуатацией – как система будет запускаться
- учтены ли все внешние системы, с которыми будет взаимодействовать данная
- какой информацией каждая внешняя система будет обмениваться с данной.
Часто для одной системы создается несколько диаграмм вариантов использования.
На диаграмме высокого уровня, указываются только пакеты (группы) вариантов
использования. Другие диаграммы описывают совокупности вариантов использования и
действующих лиц.
Различные разработчики подходят к описанию вариантов использования с разной
детализацией. Например одно из мнений – для проекта с трудоемкостью в 10 человеко-лет
количество вариантов использования может составить около 20. Обычно от 20 до 50
При разработке диаграммы вариантов использования следует придерживаться
следующих правил:
- не моделируйте связи между действующими лицами. Они находятся вне сферы
действия системы. Для изучения коммуникаций между действующими лицами
применяется диаграмма потоков работ.
- Не соединяйте стрелкой непосредственно два варианта использования (кроме случаев
связей типа «использование» и «расширение». Диаграммы вариантов использования
описывают только, какие варианты использования доступны системе, а не порядок их
выполнения. Для отображения порядка выполнения вариантов использования
применяются диаграммы деятельностей.
- Каждый вариант использования должен быть инициирован действующим лицом. Это
означает, что всегда должна быть стрелка, начинающаяся на действующем лице и
заканчивающаяся на варианте использования (за исключением связей расширения и
использования)
- Потоки данных в системе – слой находящийся «под» диаграммой вариантов
использования. С помощью одного варианта использования можно вводить данные в
систему, с помощью другого – получать. Для изображения потоков данных не следует
рисовать стрелки от одного варианта использования к другому.
Взаимодействие объектов
Для каждого варианта использования разрабатывается несколько диаграмм
взаимодействия, отображающих один из процессов обработки информации в
соответствующем варианте использования. Обычно в любом варианте использования
имеется несколько альтернативных потоков. Это приводит к тому что для одного варианта
использования создается несколько диаграмм взаимодействия. На одной диаграмме будет
показано, что происходит, когда все в порядке. На других – альтернативный ход событий
– что происходит, если что-либо не нормально.
Существуют два типа диаграмм взаимодействия: диаграммы последовательности и
кооперативные диаграммы. На диаграммах обоих типов представлена одна и та же
информация, однако их предназначение различно: диаграммы последовательности
заостряют внимание на управлении, кооперативные диаграммы отображают поток
данных.
54
Диаграммы последовательности
Диаграммы последовательности отражают поток событий, происходящих в рамках
варианта использования. В верхней части диаграммы показаны все действующие лица и
объекты, требуемые системе для выполнения соответствующего варианта использования.
Стрелки соответствуют сообщениям, передаваемым между действующими лицами и
объектом или между объектами для выполнения требуемых функций. Причем на
диаграмме последовательности показаны именно объекты, а не классы. У каждого объекта
имеется линия жизни, изображаемая в виде вертикальной штриховой линии под объектом.
Сообщения, соответствующие коммуникациям между объектами рисуют как стрелки
между линиями жизни объектов. Сообщение показывает, что один объект вызывает
функцию другого. Далее при определении операций классов каждое сообщение станет
вызовом операции. Сообщения могут быть рефлексивными, что соответствует обращению
объекта к собственной операции.
Читать эту диаграмму следует сверху вниз.
На диаграммах последовательности можно показать активизацию. Активизация –
это маленькие прямоугольники на линиях жизни, показывающие какой из объектов
активен и получает управление в конкретный промежуток времени.
У каждого варианта использования имеется большое число альтернативных
потоков. Каждая диаграмма последовательности описывает один из потоков варианта
использования.
Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы.
Аналитики видят последовательность действий, разработчики – объекты, которые надо
создать и их операции. Специалисты по контролю качества поймут детали процесса и
смогут разработать тесты для проверки.
Кооперативные диаграммы
Отражают ту же информацию, что и диаграммы последовательности, однако подругому и с другой целью.
Объекты изображаются в виде прямоугольников, действующие лица в виде фигур.
В отличие от диаграммы последовательности связь взаимодействия со временем
отсутствует. Непосредственно взаимодействующие объекты соединены линиями.
Отсутствие линии означает, что непосредственного взаимодействия нет.
Сообщения отображаются как стрелки, параллельные соответствующим линиям
взаимодействия объектов.
Одно из отличий кооперативных диаграмм от диаграмм последовательности в том,
что на кооперативных диаграммах может быть показан поток данных. Потоки данных
применяют для отображения информации, возвращаемой, когда один объект посылает
сообщения другому. В общем случае не стоит добавлять потоки данных к каждому
сообщению – это переполнит диаграмму ненужной информацией. Но если сообщение
возвращает структуру данных (например список сотрудников), то это уже может быть
важным и заслуживает отображения на диаграмме. Изображаются потоки данных
аналогично сообщениям, но используется стрелка с кружком в начале.
Другое отличие – на кооперативных диаграммах нельзя показать активизацию.
55
Нужны кооперативные диаграммы чтобы: специалисты по контролю качества и
архитекторы системы поняли распределение процессов между объектами. Например, если
кооперативная диаграмма представляет собой звезду, то архитектор системы может
сделать вывод, что система слишком зависит от центрального проекта и
перепроектировать ее для более равномерного распределения процессов.
Общие положения
Поиск объектов
Хороший способ первоначального выявления некоторых объектов – изучение имен
существительных в потоке событий, разработанном для варианта использования. Можно
также прочитать документы, описывающие конкретный сценарий. Некоторые
существительные будут соответствовать действующим лицам, некоторые – объектам,
третьи – атрибутам объекта.. Чтобы понять объект это или атрибут, нужно понять, есть ли
у него поведение. Если нет, то это вероятно атрибут, если есть – объект.
Соотнесение объектов с классами
Каждый объект диаграммы последовательности или кооперативной диаграммы
может быть соотнесен с классом. Имя класса указывается через двоеточие после имени
объекта.
В начальный период проектирования системы, когда структура классов еще не
разработана, такого соотнесения обычно не производится. К моменту завершения
проектирования (перед генерацией кода) все объекты должны быть соотнесены с
соответствующими классами.
Соотнесение сообщения с операцией
К моменту завершения проектирования (перед генерацией кода) имена всех
сообщений должны быть соотнесены с именам методов класса объекта, получающего
сообщения.
Типы синхронизации сообщений
Существуют различные типы сообщений в зависимости от способа синхронизации.
Для них на диаграммах последовательности и кооперативных диаграммах используются
следующие виды стрелок:
- Простое (Simple). Означает, что все сообщения выполняются в одном потоке
управления
- Синхронное (Synchronous). Применяется, когда клиент посылает сообщение и ждет
ответа пользователя
- С отказом становиться в очередь (Balking). Клиент посылает сообщение серверу. Если
сервер не может немедленно принять сообщение, то оно отменяется
С лимитированным временем ожидания (Timeout). Клиент посылает сообщение
серверу, а затем ждет указанное время. Если в течение этого времени сервер не
принимает сообщение, оно отменяется
- Асинхронное (Asynchronous) Клиент посылает сообщение серверу и продолжает свою
работу, не ожидая подтверждения о получении
Взаимосвязь диаграмм последовательности и кооперативных диаграмм
Обычно для конкретного сценария строят либо диаграмму последовательности,
либо кооперативную диаграмму. Но иногда полезно иметь их обе. Так как они
представляют информацию по разному. CASE пакеты (Rational Rose) позволяют
автоматически создавать из диаграммы одного типа диаграмму другого.
Двухэтапный подход к созданию диаграмм взаимодействия
При разработке диаграмм взаимодействия часто применяют двухэтапный подход.
Прежде всего отображается информация высокого уровня, которая нужна конечным
пользователям проектируемой системы. Сообщения еще не соотносятся с операциями, и
-
56
объекты могут не быть снесены с классами. Эти диаграммы позволяют аналитикам,
пользователям и всем заинтересованным лицам увидеть, как будут происходить события в
системе.
На втором этапе, после того, как пользователи придут к согласию по поводу
полученной диаграммы, можно углубиться в детали. При этом диаграмма может утратить
свою полезность для пользователей, но стать важной для разработчиков, тестировщиков и
остальных участников команды проекта.
В начале второго этапа на диаграмму помещают некоторые новые объекты. Как
правило это управляющий объект. Все диаграммы взаимодействия для одного варианта
использования имеют, как правило, один и тот же управляющий объект. Управляющий
проект не реализует функции системы, он лишь посылает сообщения другим объектам..
Он отвечает за координацию действий других объектов и за делегирование
ответственности.
Диаграммы классов
На диаграммах классов отображаются некоторые классы и пакеты системы и связи
между ними. Это статические картинки. Обычно для описания системы создают
несколько диаграмм классов. На одних показывают некоторое подмножество классов и
отношения между классами подмножества. На других отображают то же подмножество,
но вместе с атрибутами и операциями классов. Третьи соответствуют только пакетам
классов и соотношениям между ними.
Классы
Выявление классов можно начинать с изучения потока событий сценариев,
разработанных для вариантов использования. Имена существительные в его описания
дадут понять, что может явиться классом.
Лучший способ – анализ диаграмм взаимодействия. На этих диаграммах
представлены объекты. Каждый объект – экземпляр класса. Похожие объекты –
экземпляры одного и того же класса.
Класс выглядит на диаграмме классов как прямоугольник, разделенный на три
области: имя класса, атрибуты класса и операции класса. Части, показывающие атрибуты
и операции можно опустить.
Различают следующие типы классов:
- Стандартный класс (Class);
Class 1
Attribute 1
Attribute 2
Operator 1
Operator 2
-
Параметризированный класс (Parameterized Class) - в верхнем прямоугольнике
находится список аргументов параметризованного класса;
item
Class 1
Attribute 1
Attribute 2
Operator 1
Operator 2
57
-
Инстацированный класс (Instantiated Class) - порожденный от параметризированного –
аналогично стандартному, но его имя заключается в одиночные угловые скобки;
Класс-утилита (Class Utility) - абстракция виртуальной машины - предназначен для
представления совокупности операций, которая будет использоваться другими
классами системы. На диаграмме выглядит как класс с тенью;
Class 1
Attribute 1
Attribute 2
Operator 1
Operator 2
-
Параметризованный класс-утилита (Parameterized Class Utility) – параметризованный
класс, содержащий только набор операций. Выглядит как параметризованный класс с
тенью,
- Инстацированный класс-утилита (Instantiated Class Utility) – класс-утилита,
произведенный от параметризированного класса-утилиты, параметры которой имеют
фактические значения. Выглядит как обычный инстацированный класс, но с тенью;
- Абстрактный класс (Abstract Class) – выглядит как стандартный класс, но имя пишется
курсивом;
- Метакласс (Metaclass) – изображается как обычный класс.
Классы можно вкладывать один в другого, организуя столько уровней
вложенности, сколько необходимо. На диаграмме вложенный класс (Nested Class) либо не
отображается, либо отображается с именем внешнего класса, заключенным в круглые
скобки (from Class).
Классам иногда полезно назначит стереотипы. Стереотип – это механизм,
позволяющий категоризировать классы. В языке UML определены три основных
стереотипа:
- Пограничный класс (Boundary)
- Класс-сущность (Entity)
-
Управляющий класс (Control)
Проектировщик может определить собственные стереотипы.
Пограничными называют классы, которые расположены на границе системы с
окружающим миром – то есть классы, обеспечивающие интерфейс. Для выявления
пограничных классов обследуют диаграммы вариантов использования. Для каждого
взаимодействия между действующим лицом и вариантом использования должен
существовать хотя бы один пограничный класс. Именно он позволяет действующему лицу
взаимодействовать с системой.
Классы-сущности содержат полезную информацию, хранимую постоянно. Часто
для каждого класса-сущности создают таблицу в базе данных, что приводит к
проектированию БД от проекта программы, а не программы от структуры базы данных,
что уменьшает вероятность сбора ненужной информации.
Управляющие классы отвечают за координацию действий других классов. При
двухэтапном подходе к проектированию диаграмм взаимодействия управляющие
объекты, соответствующие управляющим классам вносятся на втором этапе.
Управляющий класс не несет в себе никакой функциональности, поэтому остальные
классы посылают ему мало сообщений, но сам он посылает множество сообщений.
58
В диаграммах класса стереотип указывается в поле имени класса над строкой
имени либо соответствующим значком, либо именем, заключенным в двойные угловые
скобки:
<<entity>>
Class 1
Class 1
Attribute 1
Attribute 2
Attribute 1
Attribute 2
Operator 1
Operator 2
Operator 1
Operator 2
Еще одной характеристикой классов является множественность (Cardinality),
которая позволяет показать, сколько у данного класса должно быть экземпляров. Обычно
разумно предположить, что может существовать любое количество экземпляров, если
класс не абстрактный. В некоторых случаях число экземпляров класса надо ограничивать.
Возможны варианты:
- нет ни одного экземпляра – абстрактный или служебный, содержащий только
атрибуты и операции с областью действия класса - 0;
- ровно один экземпляр – синглетный (Singleton) класс - 1;
- заданное число экземпляров – 1 1..10 1..*;
- произвольное число экземпляров – вариант по умолчанию.
Множественность, отличающаяся от значения по умолчанию, задается
выражением, написанном в верхнем правом углу пиктограммы класса.
Для группировки классов, обладающих некоторой общностью используются
пакеты. На языке UML пакет изображается следующим образом:
Package 1
Пакет может владеть другими элементами, в том числе классами, интерфейсами и
другими пакетами. Элементы, которыми пакет владеет можно указать в теле пакета, тогда
его имя пишется на закладке.
Объединять классы можно как угодно, но существует несколько наиболее
распространенных подходов: по стереотипу, по функциональности и комбинация двух
указанных подходов.
Пакеты классов обычно отображаются на главной диаграмме классов модели. Для
каждого из пакетов имеется уточняющая диаграмма классов. Если и на ней есть пакеты,
то они раскрываются диаграммами классов следующего уровня и т.д. Возможно также
создание общей диаграммы классов, показывающей все классы (а не пакеты).
Диаграммы классов соотносятся с диаграммами взаимодействия через классы: к
моменту завершения проектирования каждый объект на диаграммах взаимодействия
должен быть соотнесен с классом, но не наоборот. Возможно создание вспомогательных
классов, не соотнесенных с объектами на диаграммах использования.
Атрибуты
Атрибуты выявляют путем анализа описаний вариантов использования, требований
к системе и структуры базы данных, если она уже определена. Следует избегать
избыточности атрибутов – каждый атрибут должен быть соотнесен с требованиями к
системе. Каждое требование должно быть отслежено до конкретного потока событий
варианта использования, конкретного требования или существующей таблицы баз
данных.
59
После того, как атрибуты определены, их следует соотнести с соответствующими
классами. Если у класса слишком много атрибутов (10, 15 и более), то возможно его
следует разделить на два меньших (но возможно и нет, если все его атрибуты
действительно нужны и действительно принадлежат этому классу). Подозрение вызывают
также классы, у которых слишком мало атрибутов. Возможно что все нормально –
например, управляющий класс имеет мало атрибутов. Однако это может быть признаком
необходимости в объединении нескольких классов.
Описание атрибута в UML имеет формат:
Видимость имя : тип = начальное значение
Тип может быть как простым, так и сложным – например указатель на простой тип.
Задавать начальное значение необязательно.
Видимость атрибута имеет следующие варианты:
Тип видимости
Обозначение
UML
Public (общий, открытый)
атрибут виден всем остальным классам
+
Private (закрытый, секретный)
атрибут не виден другим классам
Protected (защищенный)
атрибут доступен только самому классу
#
и его потомкам
Package (пакетный)
атрибут является общим в пределах
своего пакета
В общем случае рекомендуется делать атрибуты закрытыми или защищенными.
Логика изменения атрибута должна быть скрыта в том же классе, что и сам атрибут.
Те же значения видимости имеют элементы пакетов.
Возможно определение статичного атрибута – атрибута, который используется
всеми экземплярами класса. В языке UML он обозначается символом «$» перед именем
или подчеркивается
Для атрибутов может быть задана множественность, она указывается в квадратных
скобках после имени атрибута.
Можно задавать свойства атрибутов – в фигурных скобках после описания
атрибута. Используются три варианта свойств:
- changeable (изменяемый) – ограничений на изменение значений атрибута не
установлено;
- addOnly (только добавляемый) – разрешается добавлять новые значения для атрибутов
с множественностью больше 1, но созданное значение не может быть изменено или
удалено;
- frozen (замороженный) – значение атрибута нельзя менять после инициализации
объекта.
Также может быть определен производный атрибут, вычисляемый по заданной
формуле из одного или нескольких других атрибутов. Например класс прямоугольник
может иметь атрибуты ширина и высота а также атрибут площадь, вычисляемый как
произведение высоты и ширины. В UML производные атрибуты помечаются символом
«/» перед именем.
Для атрибутов могут использоваться стереотипы – способ классификации
атрибутов, используемый для облегчения чтения и понимания модели. Имя стереотипа
вводится в двойных угловых скобках перед именем атрибута.
Примеры описания атрибутов:
- at1 : integer = 0
+ at2 : *real
# $at3 : string
- /at4 : real
Описание
60
- <<Type1>> at5 : real = 1
+ at6 : integer = 10 {frozen}
- at7 [1..10] : integer
Операции
Операцией называется связанное с классом поведение. Описание операции состоит
из трех частей – имени, параметров и типа возвращаемого значения.
При выявлении операций следует использовать диаграммы последовательности и
кооперативные диаграммы. Операция выводится из сообщения на диаграмме
взаимодействия, сообщения – из описания вариантов использования, а последние – на
основании требований. Возможность проследить эту цепочку гарантирует, что каждое
требование будет воплощено в коде, а каждый фрагмент кода реализует какое-то
требование.
Различают четыре типа операций:
- операции реализации – реализуют функциональность – каждое сообщение диаграммы
последовательности или кооперативной диаграммы скорее всего можно соотнести с
этим типом операции;
- операции управления – конструкторы и деструкторы;
- операции доступа – доступ к закрытым атрибутам;
- вспомогательные операции – такие операции класса, которые нужны ему самому для
выполнения его ответственностей, о которых другие классы не должны ничего знать.
Обычно это закрытые и защищенные операции класса. Как и операции реализации,
вспомогательные операции можно обнаружить на диаграммах взаимодействия – как
рефлексивные сообщения.
В языке UML операции имеют следующую нотацию:
Видимость Имя (направление аргумент 1: тип данных = значение по умолчанию,
аргумент 2: тип данных, …): тип возвращаемого значения
-
Значения видимости для операций совпадают с видимостью для атрибутов.
Направление может принимать следующие значения:
in – входящий параметр, который не может быть модифицирован;
out – выходящий параметр, который может быть изменен, чтобы передать
информацию вызвавшей подпрограмме;
inout – входящий
Операции класса выделяются подчеркиванием.
Для операции может быть назначен стереотип. Его имя указывается в двойных
угловых скобках перед именем операции. Наиболее распространенные стереотипы
операций:
- Implementer – реализация;
- Manager – управляющая;
- Access – доступ;
- Helper – вспомогательная.
Диаграммы классов соотносятся с диаграммами взаимодействия через операции: к
моменту завершения проектирования каждое сообщение на диаграммах взаимодействия
должно быть соотнесено с операцией класса, получающего сообщение, но не наоборот.
Возможны операции, не соотнесенные с сообщениями.
61
Интерфейсы
Помимо классов в диаграммах классов используются интерфейсы. Интерфейсы
используются
для
визуализации,
специфицирования,
конструирования
и
документирования стыковочных узлов между составными частями системы. Интерфейс
определяет границу между спецификацией того, что делает абстракция, и реализацией
того, как она это делает.
При создании программного обеспечения важно строить системы с четким
разделением задач, так чтобы при развитии системы изменения в одной ее части не
затронули другие. Для этого необходимо специфицировать стыковочные узлы системы, к
которым присоединяются эти независимо изменяемые части. Кроме того, такие части при
правильном проектировании можно использовать многократно. Улучшение или
изменение реализации не повлияет на ПО, использующее данный программный
компонент через интерфейс.
Если рассматривать с практической точки зрения, интерфейсы служат для
обеспечения взаимодействия классов, находящихся в отдельно компилируемых
программных объектах (например в dll). Понятие интерфейса в UML близко к понятию
интерфейса в COM технологии.
Интерфейс – именованный набор операций, используемый для спецификации
услуг.
Существуют два варианта изображения интерфейса на диаграммах классов:
простая – интерфейс изображается в виде кружочка с подписанным под ним именем, и
развернутая – интерфейс изображается как стандартный класс с указанным стереотипом
<<interface>>.
У любого интерфейса должно быть имя, отличающее его от остальных. Имя
интерфейса может быть простым (IUnknown ) или составным (Sensor::ITarget), которое
образуется путем добавления в начало имени пакета, в который входит интерфейс. Имя
интерфейса должно быть уникальным внутри пакета.
Интерфейс – набор операций для специфицирования сервиса. Эти операции могут
быть указаны в описании интерфейса, если использовать развернутую форму его
представления. Атрибутов, в отличие от класса, он не имеет.
Связи
В UML существуют следующие типы связей:
Ассоциация (association)
Это семантическая связь между классами. Ассоциации могут быть
двунаправленными – рисуются в виде сплошной линии без стрелок или со стрелками с
двух сторон и однонаправленной – изображается как линия со стрелкой, показывающей
направление связи. Незакрашенная стрелка для агрегирования, закрашенная – для
композиции.
Направленность
ассоциации
можно
определить,
изучая
диаграммы
последовательности или кооперативные диаграммы. Если классы связаны ассоциацией, то
они могут передавать друг другу сообщения на диаграммах взаимодействия. В случае,
когда во взаимодействующей паре объектов один только принимает сообщения, а другой
только передает, связь однонаправленная (стрелка связи в направлении передачи
сообщений), иначе – двунаправленная.
Однонаправленные ассоциации позволяют выявить классы, являющиеся
кандидатами на повторное использование. Если связь двунаправленная, то каждый класс
62
должен знать о другом и повторно использовать их можно только в паре. Если она
однонаправленная, то класс, который только передает сообщения (вызывает методы)
повторно использовать трудно, а тот, который принимает сообщения (его методы
вызывают), т.е. все его связи входящие – легко.
Наличие связи ассоциации означает, что в одном (однонаправленная ассоциация)
или в обоих связанных классах должны быть соответствующие атрибуты типа класс или
ссылка на класс с которыми данный класс имеет исходящую связь ассоциации.
Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает,
что один экземпляр класса взаимодействует с другими экземплярами этого же класса.
Изображается рефлексивная ассоциация как линия, выходящая и входящая в один и тот
же класс.
Зависимость (dependency)
Связь зависимости показывает, что один класс зависит от другого. Изменения во
втором классе повлияют на первый. Зависимости всегда однонаправленные. Специальный
атрибут в классах связанных зависимостью не создаются. Если классы связаны
зависимостью, то существует диаграмма взаимодействия, на которой один объект
посылает другому сообщение, сообщений в противоположном направлении нет. Если бы
между ними существовала ассоциация, то в классе передающем сообщения был бы
атрибут, соответствующий классу, принимающему сообщения. Для зависимостей такого
атрибута нет. Класс, передающий сообщения, должен узнать о классе, который с ним
связан, каким-то другим способом. Здесь есть три возможности: класс, принимающий
сообщения, может быть глобальным, его можно породить как локальную переменную
внутрь класса (не обязательно поле), передающего сообщения, и его можно передавать в
этот класс в качестве параметра метода.
Зависимость изображается как однонаправленная пунктирная линия со стрелкой в
направлении передачи сообщений (клиент – сервер)
клиент
сервер
Для большинства отношений зависимости достаточно просто указать ее наличие,
но если следует передать какой-либо ее смысловой нюанс, то можно использовать
стереотип. Например:
- friend – указывает, что клиенту даются специальные права видимости свойств сервера;
- instantiate – показывает, что клиент создает экземпляры сервера
Зависимость – фактически единственный тип связи между пакетами. Связь
зависимости между пакетами А и В означает, что некоторый класс пакета А связан
однонаправленной связью (не обязательно зависимостью) с некоторым классом пакета В.
Иначе говоря, класс А должен знать что-либо о классе В.
Зависимость определяет возможность повторного использования пакетов.
Используемый пакет может быть применен повторно, использующий – только совместно
с используемым.
Зависимости между пакетами можно обнаружить, исследуя связи не диаграмме
классов. Если два класса из различных пакетов связаны, то и эти пакеты тоже связаны.
Создавая связи между пакетами следует избегать циклических зависимостей..
Такая зависимость предполагает, что класс из пакета А должен знать о классе из пакета В,
а какой-то класс из пакета В должен знать о классе из пакета А. Следовательно, ни один
пакет нельзя самостоятельно повторно использовать, и изменения в одном из них
неизбежно повлияют на другой. Чтобы разбить циклическую зависимость рекомендуется
разделить один из пакетов на два.
Агрегация (aggregations)
63
Представляет собой более тесную форму ассоциации. Агрегация – это связь между
целым и его частями. Агрегацию изображают в виде линии с ромбиком у класса,
являющегося целым.
целое
часть
Различаю агрегацию по ссылке и по значению. При агрегации по значению один из
атрибутов класса-целого – класс-часть, а при агрегации по ссылке – указатель на классчасть. В первом случае объекты создаются и уничтожаются одновременно, во втором – в
разное время. Агрегация по ссылке и по значению в UML изображаются по-разному. В
первом случае ромбик не закрашенный, во втором – закрашенный.
Один класс может участвовать в нескольких отношениях агрегации с другими.
Как и ассоциации, агрегации могут быть рефлексивными. Рефлексивная
ассоциация предполагает, что один экземпляр класса состоит из одного или нескольких
экземпляров того же класса.
Обобщение (generalization)
Обобщение – это связь наследования между двумя классами. Изображается в виде
сплошной линии с незакрашенной закрытой стрелкой в направлении от подкласса к
суперклассу.
предок
потомок
Подкласс наследует атрибуты и операции суперкласса (повторно они не
описываются) и имеет собственные уникальные атрибуты и методы.
Возможно как одиночное, так и множественное наследование.
Создаваемая структура должна быть управляемой. Иерархия со слишком большим
числом уровней может стать плохо управляемой. Каждое изменение в верхней части
структуры немедленно отразится во всех производных классах.
Наполнение( instantiates), использование (uses)
Описывает связь между параметризованным классом или классом-утилитой и
порожденным от него инстацированным классом или классом-утилитой. В большинстве
случаев также изображается связь использования между инстацированным классом и
конкретным классом, который используется в качестве актуального параметра.
Связь наполнения изображается аналогично связи зависимости – пунктирной
линией с незакрашенной стрелкой в направлении параметризованного класса.
<TClass1>
Реализация (realize)
Отношение реализации – отношение между классом и интерфейсом. Причем
интерфейс определяет ряд обязательств, а класс обеспечивает их выполнение.
Интерфейс специфицирует контракт класса, но не накладывает ограничений на
реализацию. Класс может реализовать несколько интерфейсов и наоборот – класс может
зависеть от нескольких интерфейсов.
Связь интерфейса с реализующим его элементом можно графически представить
двумя способами. Для простой формы, когда интерфейс изображается кружочком, связь
реализации изображается простой сплошной линией. При расширенной форме
64
представления интерфейса отношение реализации изображают в виде пунктирной линии с
большой не закрашенной стрелкой, направленной в сторону интерфейса.
Class 1
Class 2
IUnknown
зависимость
Class 2
реализация
<<interface>>
IUnknown
зависимость
Class 1
реализация
Кроме отношения реализации интерфейсы могут вступать в отношения обобщения,
ассоциации и зависимости как обычный класс.
Метасвязь (meta)
Метасвязь используется, чтобы показать соединение между классом и его
метаклассом. Изображается как сплошная жирная линия со стрелкой в направлении
метакласса.
MetaClass
Class
Спецификации связей
В UML имеется возможность указывать некоторые специфичные особенности для
связей любых типов: множественность, имена, ролевые имена и квалификаторы.
Спецификаторы являются необязательными.
Множественность связи показывает, сколько экземпляров одного класса могут
взаимодействовать с одним экземпляром другого класса в один момент времени. Так как
множественность в общем случае должна быть указана для обоих классов, участвующих в
связи, то ее индикаторы устанавливаются на обоих концах линии связи.
В языке UML приняты следующие нотации для обозначения множественности:
Значение
Множественность
*
Неопределенно много
0
Нуль
1
Один
0..*
Нуль или больше
1..*
Один или больше
0..1
Нуль или один
1..1
Ровно один
<число>
Ровно число
<число 1>..<число 2>
Между числом 1 и числом 2
<число 1>..n
Число или больше
<число 1>, <число 2>
Число 1 или число 2
<число 1>, <число 2>..<число 3>
Ровно число 1 или между числом 2 и
числом 3
65
<число 1>..<число 2>, <число 3>..<число 4> Между числом 1 и числом 2 или между
числом 3 и числом 4
Значение множественности позволяет понять, является ли связь обязательной.
Связи можно уточнять с помощью имен связей, которые позволяют ответить на
вопрос – зачем нужна связь (например классы человек и компания – связь ассоциации
может иметь имя – работает). В качестве имени связи обычно используется глагол. Имя
связи показывают около линии соответствующей связи. Имена связей определять
необязательно и обычно этого не делают.
Как и другим элементам модели, связям можно назначать стереотипы. Они
применяются для классификации связей. Стереотипы пишутся вдоль линии связи в
двойных угловых скобках. Например стереотип может использоваться, чтобы показать
дружественные связи.
Связи можно уточнять с помощью ролей. Ролевые имена применяются в связях
ассоциации и агрегации для описания назначения связи (например человек и компания,
его роль – служащий, роль компании – место работы). Ролевые имена – это обычно
существительные или фразы. Их показывают на диаграмме рядом с классом, играющим
соответствующую роль.
Как правило, используют или ролевые имена или имя связи, но не оба типа сразу.
Также, как и имена связей, ролевые имена необязательны, их указывают, только если чель
связи неочевидна.
Если для организации связи в классах создаются атрибуты (ассоциация и
агрегация), то можно управлять их видимостью. Значения видимости те же, что и для
любых других атрибутов. Соответствующий значок приписывается перед ролевым
именем соответствующего конца связи.
Кроме того, для связей, которым соответствуют атрибуты, также можно сделать
этот атрибут статичным. Для этого перед именем роли (после значка видимости)
приписывается символ $. Если роль статичная, то соответствующий ей атрибут также
будет статичным.
Элементом связи (link element) или классом ассоциаций называется место, где
хранятся относящиеся к ассоциации атрибуты. Иногда возникает вопрос – в какой из двух
участвующих в связи классов добавить атрибут (например классы студент и дисциплина,
допустим студент сам может выбирать на каком году обучения он будет изучать каждую
дисциплину; если добавить атрибут год обучения в класс студент, то придется создавать
по атрибуту для каждой дисциплины, а если в дисциплину – то для каждого студента).
Такие атрибуты характеризуют не каждый из классов, а именно их связь. Для
представления такой ситуации используется класс ассоциаций. Нотация UML для него
имеет следующий вид:
Course
0..4
Student
Grade
10..20
На основе диаграмм классов разработчики создают реальные классы. Такие
инструменты, как Rational Rose генерируют основу кода классов автоматически. Далее
программисты должны ее заполнить деталями. С помощью диаграмм классов аналитики
могут показать детали системы, а архитекторы – понять ее проект. Если, например, какой-
66
либо класс несет слишком большую нагрузку, это будет видно на диаграмме классов, и
архитектор сможет перераспределить ее между другими классами. С помощью диаграммы
классов можно также выявить случаи, когда между сообщающимися классами не
определено никаких связей.
Рекомендуется строить диаграммы классов, показывающие взаимодействующие
классы в каждом варианте использования. Можно также строить более общие диаграммы,
охватывающие всю систему или подсистемы.
Диаграммы состояний
На диаграмме состояний отображается жизненный цикл одного объекта
соответствующего класса, начиная с момента его создания и заканчивая разрушением – то
есть они показывают поведение объекта.
Как правило, диаграммы состояний не требуется создавать для каждого класса.
Многие проекты обходятся вообще без них.
Если динамика поведения объекта данного класса важна, то для него полезно
разработать диаграмму состояний. Такие классы имеют обычно много различных
состояний.
Для того, чтобы выявить, нужна ли для класса диаграмма состояния и какие
состояния она будет включать следует во-первых рассмотреть его атрибуты. Экземпляр
класса может вести себя по-разному в зависимости от их значений. Далее следует
исследовать связи между классами, множественность которых может принимать нулевое
значение. Нули указывают, что данная связь не является обязательной. Возможно, что
экземпляр класса ведет себя по-разному в зависимости от наличия или отсутствия связи.
Если диаграмма классов задает шаблон программного проекта, который далее
должен быть заполнен кодом, то диаграмма состояния нужна, чтобы документировать
динамику поведения класса, которая должна быть запрограммирована.
Состоянием (state) называют одно из возможных условий, в которых может
существовать объект.
В языке UML состояние изображается в виде прямоугольника с закругленными
краями, в котором указывается имя состояния.
Также в прямоугольнике под именем и разделительной чертой может быть
добавлено описание состояния, которое может включать в себя деятельность, входное
действие и выходное действие, иногда включающие в себя события.
Деятельностью (activity) называют поведение, реализуемое объектом, когда он
находится в данном состоянии. Деятельность – прерываемое поведение. Оно может
выполняться до завершения, если объект находится в данном состоянии, или может быть
прервано переходом объекта в другое состояние. Описанию деятельности предшествует
слово do и двоеточие (do:деятельность).
Входным действием (entry action) называют поведение, которое выполняется,
когда объект переходит в данное состояние как часть этого перехода. Входное действие
является непрерываемым поведением. Описанию входного действия предшествует слово
entry и двоеточие. (entry : действие).
Выходное действие (exit action) подобно входному, но осуществляется как
составная часть процесса выхода из данного состояния. Оно также является
непрерываемым. Описанию выходного действия предшествует слово exit и двоеточие
(exit : действие).
Поведение объекта во время деятельности, входных и выходных действий может
включать в себя отправку события другому объекту. В этом случае описанию действия
предшествует знак ^. Например
Do: ^Цель.Событие (аргументы),
67
Где цель – это объект, событие – посылаемое сообщение, аргументы – параметры
посылаемого сообщения.
Переходом (transition) называется перемещение из одного состояния в другое.
Совокупность переходов диаграммы показывает, как объект может переходить из одного
состояния в другое. На диаграмме переходы изображаются в виде стрелки, начинающейся
в первоначальном и заканчивающейся в последующем состоянии.
Переходы могут быть рефлексивными: объект переходит в то же состояние, в
котором он находился. Рефлексивные переходы изображаются в виде стрелки,
начинающейся и заканчивающейся на одном и том же состоянии.
У перехода существует несколько спецификаций: события, возможно имеющие
аргументы, ограждающие условия и действия, возможно представляющие собой
посылаемые события.
Событие (event) – то, что вызвало переход из одного состояния в другое. Событие
размещают на диаграмме вдоль линии перехода.
Для отображения события можно использовать как имя операции, так и обычную
фразу («Клиент требует закрыть» или RequesClosure()). У события могут быть аргументы
– параметры операции (сделать вклад - DepositMoney(Amount)).
Большинство переходов должно иметь события, так как именно они инициируют
переход. Тем не менее бывают и автоматические переходы, не имеющие событий. При
этом объект сам перемещается из одного состояния в другое, например, автоматически
возвращается из состояния после завершения выполнения входных действий,
деятельности и выходных действий.
Ограждающее условие (guard conditions) определяет, когда переход может быть
выполнен, а когда нет. На диаграмме ограждающее условие заключается в квадратные
скобки и размещается вдоль линии перехода после имени события.
Ограждающее условие задавать необязательно. Однако, если существует несколько
автоматических переходов из состояния, необходимо определить для них взаимно
исключающие ограждающие условия, что позволит понять, какой путь перехода будет
выбран автоматически.
Действием (action) называют непрерываемое поведение, выполняющееся как часть
перехода. Входные и выходные действия показываются внутри состояния, поскольку они
определяют, что происходит, когда объект входит и выходит из состояния. Действия,
изображающиеся вдоль линии перехода должны осуществляться не при входе или выходе
из состояния, а при выполнении собственно перехода.
Действие размещают вдоль линии перехода после имени события через косую
черту.
Поведение во время действия может представлять собой отправку события
другому объекту. В этом случае описанию действия предшествует знак ^. Например
Do: ^Цель.Событие (аргументы),
где цель – это объект, событие – посылаемое сообщение, аргументы – параметры
посылаемого сообщения.
Специальные состояния
На диаграмму могут быть добавлены два специальных состояния объекта –
начальное и конечное.
Начальным (start state) называют состояние, в котором объект находится сразу
после своего создания. На диаграмме его изображают в виде закрашенного кружка от
которого проводится переход к последующим состояниям.
Начальное состояние обязательно и единственно, с него начинается существование
объекта.
68
Конечное состояние (end state) – состояние, в котором объект находится
непосредственно перед уничтожением. Его изображают в виде закрашенного кружка с
незакрашенным ободком («бычий глаз»).
Наличие конечного состояния не является обязательным. Конечных состояний
может быть сколько угодно.
Использование вложенных состояний
Для уменьшения беспорядка на диаграмме можно вкладывать состояния одно в
другое. Вложенные состояния называют подсостояниями (substates), а те, в которые они
вложены, - суперсостояниями (superstates).
Если у нескольких состояний имеются идентичные переходы, эти состояния можно
сгруппировать в суперсостояние. Затем, вместо того, чтобы поддерживать одинаковые
переходы для каждого состояния. Их можно объединить, перенеся в суперсостояние.
Бывают случаи, когда система должна помнить, из какого именно подсостояния
одного суперсостояния она вышла, чтобы иметь возможность вернуться в него. Для
описания такой ситуации используется история состояний (state history). При
подключенной истории состояния объект после выхода из суперсостояния вернется точно
в то место откуда вышел. Для подключения истории состояний в углу суперсостояния
располагается буква «H» (history) в кружке.
Диаграммы компонентов
Диаграммы компонентов служат для представления физического облика системы.
Они показывают организацию и зависимости между программными компонентами,
включая компоненты исходного кода, компоненты в бинарном коде и исполняемые
компоненты.
Диаграммой компонентов (Component diagram) называется диаграмма UML, на
которой представлены компоненты системы и зависимости между ними.
Компонент (component) – физический модуль кода с хорошо определенным
интерфейсом. Изображается с помощью значка:
Обобщенный
компонент
Для определения конкретного типа компонента используется стереотип. Имя
стереотипа указывается в двойных угловых скобках над именем компонента. Компоненты
с некоторыми стереотипами отображаются с помощью их собственных значков (уже без
указания имени стереотипа).
Определены следующие стереотипы:
Главная программа (Main Program)
Это файл, содержащий корень программы. Обычно одной программе соответствует
один компонент главная программа.
Main
Имя главной программы – имя соответствующего файла.
Спецификация пакета (Package Specification) – это файл, содержащий описание
классов, на языке С++ спецификация соответствует заголовочному файлу (.h) с
определением классов.
69
Pkg_spez
Имя – имя соответствующего файла.
Тело пакета (Package Body)
Содержит реализацию классов, на языке С++ спецификация соответствует файлу
(.cpp).
Pkg_spez
Имя – имя соответствующего файла.
Спецификация подпрограмм (Subprogram Specification)
Спецификация подпрограмм – это файл, содержащий описание подпрограмм, но не
классов, на языке С++ спецификация соответствует заголовочному файлу (.h) с
прототипами функций.
Sub_spez
Имя – имя соответствующего файла.
Тело подпрограммы (Subprogram Body)
Содержит реализацию подпрограмм, на языке С++ спецификация соответствует
файлам (.cpp или .с).
Sub_body
Имя – имя соответствующего файла.
Спецификация и тело задачи (Task Specification Task Body).
Эти стереотипы соответствуют пакетам, имеющим независимые
управления.
Task_spec
потоки
Task_body
Исполняемый файл (exe) обычно представляют как спецификацию задачи с
расширением .exe. Возможен вариант, когда он представляется как обобщенный
компонент со стереотипом <<EXE>>
Task_spec.exe
Файл динамической библиотеки (dll) обычно представляется тем же значком, что
и спецификация пакета, но файл имеет расширение dll. Возможен вариант, когда он
представляется как обобщенный компонент со стереотипом <<DLL>>
70
Pkg_spez.dll
ActiveX компонент представляется как обобщенный компонент со стереотипом
<<ActiveX>>
Апплет представляется как обобщенный компонент со стереотипом <<Applet>>
К моменту завершения проектирования необходимо соотнести каждый класс с
компонентом. С каждым компонентом можно соотнести один или несколько классов.
Для компонентов может быть указан язык программирования.
На диаграмме компонентов можно использовать пакеты компонентов, которые
представляют собой наиболее общие элементы физического деления системы. Имена
пакетов компонентов это обычно имена каталогов. Пиктограмма для пакетов компонентов
такая же, как и для пакетов классов. Содержание каждого из пакетов должно быть
определено.
На диаграмме компонентов можно использовать интерфейсы, чтобы показать
видимое извне поведение компонентов. Интерфейсы соответствуют интерфейсам на
диаграммах классов. Используется простая форма изображения интерфейса – в виде
кружочка с подписанным под ним именем. Связь реализации между интерфейсом и
компонентом изображается в виде простой линии и означает, что компонент реализует
этот интерфейс.
Единственный тип связей между компонентами или пакетами компонентов на
диаграммах компонентов – зависимости. Также зависимости могут быть установлены
между компонентами и интерфейсами других компонентов. Зависимость изображается
пунктирной линией со стрелкой на конце.
Связь зависимости означает, что класс, содержащийся в компоненте-клиенте каким
либо образом использует класс, экспортируемый из компонента-сервера. Возможные
варианты использования: наследование, вызов методов, инстацирование этим классом.
Направление связей зависимости показывает порядок компиляции компонентов.
Исполняемый файл программы обычно является только зависимым, то есть
находится на клиентской стороне связи. Если какой-либо элемент системы представлен
двумя компонентами – телом и спецификацией, то компонент-спецификация вступает в
связь с другими компонентами-спецификациями, а компонент-реализация только с
соответствующей ему спецификацией, причем реализация находится на клиентской
стороне связи.
Диаграммы компонентов применяются теми участниками проекта, кто отвечает за
компиляцию системы. Диаграмма компонентов дает представление о том, в каком порядке
надо компилировать компоненты, а также какие исполняемые компоненты будут созданы.
То есть она нужна при генерации кода.
Диаграммы размещения
Диаграммы размещения показывают физическое расположение различных
компонентов системы. На ней отображаются все узлы сети, связи между ними и процессы,
выполняющиеся на каждом узле.
Для каждой системы разрабатывается только одна диаграмма размещения.
71
Элементы диаграммы размещения – процессоры с выполняющимися на них
процессами, устройства и связи между ними.
Процессором (processor) называется любое устройство, имеющее вычислительную
мощность, т.е. способное производить обработку данных. В эту категорию попадают
серверы, рабочие станции и другие устройства, содержащие физические процессоры.
На языке UML процессоры изображаются следующим образом:
Процессор
Процессор имеет имя и спецификацию.
В спецификации процессора входят его стереотип, характеристики и планирование.
Стереотипы (stereotype), как и в случаях других элементов модели, могут
применяться для классификации процессоров. Например, стереотипы можно определить
чтобы различать компьютеры под управлением Unix и MS Windows. Указываются в
двойных угловых скобках перед именем процессора.
Характеристики процессора (characteristics) – это его физическое описание. Оно
может включать в себя такие характеристики, как скорость процессора и объем памяти. В
случае необходимости указываются после имени процессора.
Планирование процессора (scheduling) – содержит описание того,
как
осуществляется планирование процессов. Возможны следующие варианты:
- Preemptive (с приоритетом) – высокоприоритетные процессы имеют преимущество
перед низкоприоритетными;
- Non preemptive (без приоритета) – у процессов нет приоритета; текущий процесс
выполняется до своего завершения, после чего начинается следующий.
- Cyclic (циклический) – управление передается межу процессами по кругу; каждому
процессу предоставляется определенное время на выполнение, затем управление
переходит к следующему процессу;
- Executive (исполнительный) – существует некоторый вычислительный алгоритм,
который управляет планированием процессов;
- Manual (вручную) – процессы планируются пользователем.
Способ
планирование
процесса
указывается
внизу
прямоугольника,
представляющего процессор:
Процессор
preemptive
Каждому процессору назначаются процессы, которые будут на нем выполняться.
Процессом (process) называется поток обработки информации (execution),
выполняющийся на процессоре. Процессом, например, считается исполняемый файл.
Процессы на диаграмме размещения отображаются непосредственно под
процессорами, на которых выполняются:
Процессор
preemptive
Process_1
…
Process_n
72
Процессам можно присваивать приоритеты. Если тип планирования
соответствующего процессора позволяет это, то приоритет процесса будет определять,
когда он будет выполняться.
Устройством (device) называется аппаратура, не обладающая вычислительной
мощностью. Например терминалы ввода/вывода, принтеры, сканеры, накопители. На
языке UML устройства обозначают следующим образом:
Device
Процессоры и устройства также называют узлами (nodes) сети.
Устройства имеют имя и спецификации.
Для описания устройства могут быть использованы следующие спецификации:
стереотипы и характеристики.
Стереотип (stereotype) применяют для классификации устройств.
Характеристики (Characteristics) представляют собой физическое описание
устройства.
Связью (connection) называется физическая связь между двумя процессорами,
двумя устройствами или процессором и устройством. Аппаратные устройства могут
соединяться непосредственно (например через кабели, подсоединенные к RS232) или
опосредованно, например через спутник. Связи обычно являются двунаправленными.
Связь изображается как прямая линия между соответствующими узлами системы:
Процессор 1
Процессор 2
Связи можно дать имя, назначить стереотип и задать характеристики связи,
представляющие собой техническое описание физического соединения.
Все это указывается вдоль линии связи – имя непосредственно, стереотип в
двойных угловых скобках.
Диаграммы размещения используются менеджером проекта, пользователями,
архитекторами системы и эксплуатационным персоналом для выяснения физического
размещения системы и расположения ее отдельных подсистем. Менеджер проекта с ее
помощью объяснит пользователям, как будет выглядеть готовый продукт.
Эксплуатационный персонал сможет планировать работу по установке системы.
Обзор UML
UML – язык моделирования. Модель программной системы – это ее проект. На
основе требований к системе строится модель на языке моделирования, то есть
требования преобразуются в понятную и реализуемую форму. Далее эти требования
переводятся в код на конкретном языке программирования. Все системные вопросы
решаются в процессе проектирования (или моделирования). Разработка кода производится
в соответствии с уже разработанными формальными требованиями, и строгое следование
этим требованиям позволит гарантировать соответствие разработанной системы запросам
пользователей.
73
UML – язык визуального моделирования.
Визуальным моделированием называют процесс графического представления
модели с помощью некоторого набора стандартных графических элементов.
Использование не визуальной формы представления информации также возможно, но
человек лучше воспринимает именно визуальную форму. Наличие стандарта жизненно
необходимо для обеспечения понятности модели всем участникам проекта (в том числе и
тем, кто присоединился к проекту на последних стадиях его разработки).
При моделировании системы с помощью языка UML строится ряд диаграмм,
отображающих все аспекты проектируемой системы. Различные типы диаграмм,
используемые для описания системы в UML взаимодействуют следующим образом:
диаграммы вариантов
использования
вариант
использования
Взаимодействие объектов
1..N
диаграммы
последовательности
порождаются
кооперативные
диаграммы
объект соответствует
классу
события соответствуют
методам класса
Диаграммы классов
Диаграммы компонентов
компонент-процесс должен
выполняться на процессоре
Диаграммы размещения
класс
содержится
в
компоненте
Класс
1..N
Диаграммы состояний
Язык UML не ограничивает возможности моделирования системы жестко
заданными правилами. Проектировщик имеет возможность сопровождать любую
диаграмму и любой элемент диаграммы комментариями, как текстовыми, так и
содержащими любые схемы и диаграммы, не входящие в UML. Например при
необходимости проектировщик может сопроводить метод класса схемой алгоритма или
компонент схемой тестирования его функциональных возможностей, если он считает что
это необходимо. Эта информация документирует проект системы и может быть
использована при реализации, тестировании и внедрении системы.
Программные средства поддержки жизненного цикла ПО. Методологии
проектирования ПО как программные продукты. CASE-средства. Общая
характеристика и классификация
Использование языков моделирования при проектировании системы необходимо,
но если делать это вручную, то возникнет ряд проблем:
- неадекватная спецификация требований;
- неспособность обнаружить ошибки в проектных решениях;
- низкое качество документации;
- длительный срок разработки;
- невысокое качество тестирования.
Таким образом, необходимы программно-технологические средства специального
класса - CASE-средства, реализующие CASE-технологию создания и сопровождения ПС.
Термин CASE (Computer Aided Software Engineering) используется в настоящее время в
74
весьма широком смысле. Первоначальное значение термина CASE, ограниченное
вопросами автоматизации разработки только лишь программного обеспечения (ПО), в
настоящее время приобрело новый смысл, охватывающий процесс разработки сложных
ИС в целом. Теперь под термином CASE-средства понимаются программные средства,
поддерживающие процессы создания и сопровождения ИС, включая анализ и
формулировку требований, проектирование прикладного ПО (приложений) и баз данных,
генерацию
кода,
тестирование,
документирование,
обеспечение
качества,
конфигурационное управление и управление проектом, а также другие процессы. CASEсредства вместе с системным ПО и техническими средствами образуют полную среду
разработки ИС.
CASE-технология представляет собой методологию проектирования ИС, а также
набор инструментальных средств, позволяющих в наглядной форме моделировать
предметную область, анализировать эту модель на всех этапах разработки и
сопровождения ИС и разрабатывать приложения в соответствии с информационными
потребностями пользователей. Большинство существующих CASE-средств основано на
методологиях структурного (в основном) или объектно-ориентированного анализа и
проектирования, использующих спецификации в виде диаграмм или текстов для описания
внешних требований, связей между моделями системы, динамики поведения системы и
архитектуры программных средств.
Согласно обзору передовых технологий (Survey of Advanced Technology),
составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования
более 1000 американских фирм, CASE-технология в настоящее время попала в разряд
наиболее стабильных информационных технологий (ее использовала половина всех
опрошенных пользователей более чем в трети своих проектов, из них 85% завершились
успешно). Однако, несмотря на все потенциальные возможности CASE-средств,
существует множество примеров их неудачного внедрения, в результате которых CASEсредства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить
следующее:
- CASE-средства не обязательно дают немедленный эффект; он может быть получен
только спустя какое-то время;
- реальные затраты на внедрение CASE-средств обычно намного превышают затраты на
их приобретение;
- CASE-средства обеспечивают возможности для получения существенной выгоды
только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно делать какиелибо безоговорочные утверждения относительно реального удовлетворения тех или иных
ожиданий от их внедрения. Можно перечислить следующие факторы, усложняющие
определение возможного эффекта от использования CASE-средств:
- широкое разнообразие качества и возможностей CASE-средств;
- относительно небольшое время использования CASE-средств в различных
организациях и недостаток опыта их применения;
- широкое разнообразие в практике внедрения различных организаций;
- отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
- широкий диапазон предметных областей проектов;
- различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях крайне
ограничена и противоречива. Она зависит от типа средств, характеристик проектов,
уровня сопровождения и опыта пользователей. Некоторые аналитики полагают, что
реальная выгода от использования некоторых типов CASE-средств может быть получена
только после одно- или двухлетнего опыта. Другие полагают, что воздействие может
реально проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические
улучшения могут привести к снижению эксплуатационных затрат.
75
Для успешного внедрения CASE-средств организация должна обладать
следующими качествами:
Технология. Понимание ограниченности существующих возможностей и
способность принять новую технологию;
Культура. Готовность к внедрению новых процессов и взаимоотношений между
разработчиками и пользователями;
Управление. Четкое руководство и организованность по отношению к наиболее
важным этапам и процессам внедрения.
Если организация не обладает хотя бы одним из перечисленных качеств, то
внедрение CASE-средств может закончиться неудачей независимо от степени
тщательности следования различным рекомендациям по внедрению.
Для того, чтобы принять взвешенное решение относительно инвестиций в CASEтехнологию, пользователи вынуждены производить оценку отдельных CASE-средств,
опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется
недостаточным знанием всех возможных "подводных камней" использования CASEсредств. Среди наиболее важных проблем выделяются следующие:
- достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду
отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;
- внедрение CASE-средств может представлять собой достаточно длительный процесс и
может не принести немедленной отдачи. Возможно даже краткосрочное снижение
продуктивности в результате усилий, затрачиваемых на внедрение. Вследствие этого
руководство организации-пользователя может утратить интерес к CASE-средствам и
прекратить поддержку их внедрения;
- отсутствие полного соответствия между теми процессами и методами, которые
поддерживаются CASE-средствами, и теми, которые используются в данной
организации, может привести к дополнительным трудностям;
- CASE-средства зачастую трудно использовать в комплексе с другими подобными
средствами. Это объясняется как различными парадигмами, поддерживаемыми
различными средствами, так и проблемами передачи данных и управления от одного
средства к другому;
- некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать
их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду
из той дисциплины, к которой обязывает их применение;
- негативное отношение персонала к внедрению новой CASE-технологии может быть
главной причиной провала проекта.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных
затрат на эксплуатацию, частому появлению новых версий и возможному быстрому
моральному старению средств, а также постоянным затратам на обучение и повышение
квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм,
грамотный и разумный подход к использованию CASE-средств может преодолеть все
перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие
выгоды как:
- высокий уровень технологической поддержки процессов разработки и сопровождения
ПО;
- положительное воздействие на некоторые или все из перечисленных факторов:
производительность, качество продукции, соблюдение стандартов, документирование;
- приемлемый уровень отдачи от инвестиций в CASE-средства.
CASE средства обычно служат для поддержки конкретной методологии и
реализующей ее технологии проектирования ПО. Можно сказать, что методологии и
реализующие их технологии поставляются в электронном виде вместе с CASE-средствами
76
и включают библиотеки процессов, шаблонов, методов, моделей и других компонент,
предназначенных для построения ПО того класса систем, на который ориентирована
методология. Электронные методологии включают также средства, которые должны
обеспечивать их адаптацию для конкретных пользователей и развитие методологии по
результатам выполнения конкретных проектов.
Процесс адаптации заключается в удалении ненужных процессов, действий ЖЦ и
других компонентов методологии, в изменении неподходящих или в добавлении
собственных процессов и действий, а также методов, моделей, стандартов и руководств.
Настройка методологии может осуществляться также по следующим аспектам: этапы и
операции ЖЦ, участники проекта, используемые модели ЖЦ, поддерживаемые концепции
и др.
Электронные методологии и технологии (и поддерживающие их CASE-средства)
составляют ядро комплекса согласованных инструментальных средств среды разработки
программных систем.
CASE – средство JAM (методология RAD)
Средство разработки приложений JAM (JYACC's Application Manager) - продукт
фирмы JYACC (США). В настоящее время поставляется версия JAM 7 и готовится к
выходу JAM 8.
Основной чертой JAM является его соответствие методологии RAD, поскольку он
позволяет достаточно быстро реализовать цикл разработки приложения, заключающийся
в формировании очередной версии прототипа приложения с учетом требований,
выявленных на предыдущем шаге, и предъявить его пользователю.
Структура и функции
JAM имеет модульную структуру и состоит из следующих компонент:
- Ядро системы;
- JAM/DBi - специализированные модули интерфейса к СУБД (JAM/DBi-Oracle,
JAM/DBi-Informix, JAM/DBi-ODBC и т.д.);
- JAM/RW - модуль генератора отчетов;
- JAM/CASEi - специализированные модули интерфейса к CASE-средствам
(JAM/CASE-TeamWork, JAM/CASE-Innovator и т.д.);
- JAM/TPi - специализированные модули интерфейса к менеджерам транзакций
(например, JAM/TPi-Server TUXEDO и т.д.);
- Jterm - специализированный эмулятор X-терминала.
Ядро системы (собственно, сам JAM) является законченным продуктом и может
самостоятельно использоваться для разработки приложений. Все остальные модули
являются дополнительными и самостоятельно использоваться не могут.
Ядро системы включает в себя следующие основные компоненты:
- редактор экранов. В состав редактора экранов входят: среда разработки экранов,
визуальный репозиторий объектов, собственная СУБД JAM - JDB, менеджер
транзакций, отладчик, редактор стилей;
- редактор меню;
- набор вспомогательных утилит;
- средства изготовления промышленной версии приложения.
При использовании JAM разработка внешнего интерфейса приложения
представляет собой визуальное проектирование и сводится к созданию экранных форм
путем размещения на них интерфейсных конструкций и определению экранных полей
ввода/вывода информации. Проектирование интерфейса в JAM осуществляется с
помощью редактора экранов. Приложения, разработанные в JAM, имеют многооконный
интерфейс. Разработка отдельного экрана заключается в размещении на нем
интерфейсных элементов, возможной (но не обязательной) их группировке и
77
конкретизации различных их свойств, включающих визуальные характеристики (позиция,
размер, цвет, шрифт и т.п.), поведенческие характеристики (многообразные фильтры,
форматы, защита от ввода и т.п.) и ряд свойств, ориентированных на работу с БД.
Редактор меню позволяет разрабатывать и отлаживать системы меню. Реализована
возможность построения пиктографических меню (так называемые toolbar). Назначение
каждого конкретного меню тому или иному объекту приложения осуществляется в
редакторе экранов.
В ядро JAM встроена однопользовательская реляционная СУБД JDB. Основным
назначением JDB является прототипирование приложений в тех случаях, когда работа со
штатной СУБД невозможна или нецелесообразна. В JDB реализован необходимый
минимум возможностей реляционных СУБД за исключением индексов, хранимых
процедур, триггеров и представлений (view). С помощью JDB можно построить БД,
идентичную целевой БД (с точностью до отсутствующих в JDB возможностей) и
разработать значительную часть приложения.
Отладчик позволяет проводить комплексную отладку разрабатываемого
приложения. Осуществляется трассировка всех событий, возникающих в процессе
исполнения приложения.
Утилиты JAM включают три группы:
- конверторы файлов экранов JAM в текстовые. JAM сохраняет экраны в виде двоичных
файлов собственного формата. В ряде случаев (например для изготовления
программной документации проекта) необходимо текстовое описание экранов;
- конфигурирование устройств ввода/вывода. JAM и приложения, построенные с его
помощью, не работают непосредственно с устройствами ввода/вывода. Вместо этого
JAM обращается к логическим устройствам ввода/вывода (клавиатура, терминал,
отчет). Отображение логических устройств в физические осуществляется с помощью
средств конфигурирования;
- обслуживание библиотек экранов (традиционные операции с библиотеками).
Одним из дополнительных модулей JAM является генератор отчетов. Компоновка
отчета осуществляется в редакторе экранов JAM. Описание работы отчета осуществляется
с помощью специального языка. Генератор отчетов позволяет определить данные,
выводимые в отчет, группировку выводимой информации, форматирование вывода и др.
Приложения, разработанные с использованием JAM, не требуют так называемых
исполнительных (run-time) систем и могут быть изготовлены в виде исполняемых
модулей. Для этого разработчик должен иметь компилятор C и редактор связей. Для
изготовления промышленной версии в состав JAM входит файл сборки (makefile),
исходные тексты (на языке C) ряда модулей приложения и необходимые библиотеки.
JAM содержит встроенный язык программирования JPL (JAM Procedural
Language), с помощью которого в случае необходимости можно написать модули,
реализующие специфические действия. Данный язык является интерпретируемым, что
упрощает отладку. Существует возможность обмена информацией между средой
визуально построенного приложения и такими модулями. Кроме того, в JAM реализована
возможность подключения внешних модулей, написанных на каком-либо языке,
совместимым по вызовам функций с языком C.
С точки зрения реализации логики приложения JAM является событийноориентированной системой. В JAM определен набор событий, включающий открытие и
закрытие окон, нажатие клавиши клавиатуры, срабатывание системного таймера,
получение и передача управления каждым элементом экрана. Разработчик реализует
логику приложения путем определения обработчика каждого события. Например,
обработчик события "нажатие кнопки на экране" (мышью или с помощью клавиатуры)
может открыть следующее экранное окно. Обработчиками событий в JAM могут быть как
встроенные функции JAM, так и функции, написанные разработчиком на C или JPL.
Набор встроенных функций включает в себя более 200 функций различного назначения.
78
Встроенные функции доступны для вызовов из функций, написанных как на JPL, так и на
C.
Промышленная версия приложения, разработанного с помощью JAM, включает в
себя следующие компоненты:
- исполняемый модуль интерпретатора приложения. В этот модуль могут быть встроены
функции, написанные разработчиками на языках 3-го поколения;
- экраны, составляющие само приложение (могут поставляться в виде отдельных
файлов, в составе библиотек экранов или же быть встроены в тело интерпретатора);
- внешние JPL-модули. Могут поставляться в виде текстовых файлов или в
прекомпилированном виде, причем прекомпилированные внешние JPL-модули могут
быть как в виде отдельных файлов, так и в составе библиотек экранов;
- файлы конфигурации приложения - файлы конфигурации клавиатуры и терминала,
файл системных сообщений, файл общей конфигурации.
Взаимодействие с другими средствами
Непосредственное взаимодействие с СУБД реализуют модули JAM/DBi (Data Base
interface). Способы реализации взаимодействия в JAM разделяются на два класса: ручные
и автоматические. При ручном способе разработчик приложения самостоятельно пишет
запросы на SQL, в которых как источниками, так и адресатами приема результатов
выполнения запроса могут быть как интерфейсные элементы визуально
спроектированного внешнего уровня, так и внутренние, невидимые для конечного
пользователя переменные. Автоматический режим, реализуемый менеджером транзакций
JAM, осуществим для типовых и наиболее распространенных видов операций с БД, так
называемых QBE (Query By Example - запросы по образцу), с учетом достаточно сложных
взаимосвязей между таблицами БД и автоматическим управлением атрибутами экранных
полей ввода/вывода в зависимости от вида транзакции (чтение, запись и т.д.), в которой
участвует сгенерированный запрос.
JAM позволяет строить приложения для работы более чем с 20 СУБД: ORACLE,
Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-совместимые
СУБД и др.
Отличительной чертой JAM является высокий уровень переносимости приложений
между различными платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC),
HP-UX, AIX, VMS/Open VMS и др.). Может потребоваться лишь "перерисовать"
статические текстовые поля на экранах с русским текстом при переносе между средами
DOS-Windows-UNIX. Кроме того, переносимость облегчается тем, что в JAM приложения
разрабатываются для виртуальных устройств ввода/вывода, а не для физических. Таким
образом при переносе приложения с платформы на платформу, как правило, требуется
лишь определить соответствие между физическими устройствами ввода/вывода и их
логическими представлениями для приложения.
Использование SQL в качестве средства взаимодействия с СУБД также создает
предпосылки для обеспечения переносимости между СУБД. При условии переноса
структуры самой БД в ряде случаев приложения могут не требовать никакой
модификации, за исключением инициализации сеанса работы. Такая ситуация может
сложиться в том случае, если в приложении не использовались специфические для той
или иной СУБД расширения SQL.
При росте нагрузки на систему и сложности решаемых задач (распределенность и
гетерогенность используемых ресурсов, количество одновременно подключенных
пользователей, сложность логики приложения) применяется трехзвенная модель
архитектуры "клиент-сервер" с использованием менеджеров транзакций. Компоненты
JAM/TPi-Client и JAM/TPi-Server позволяют достаточно просто перейти на трехзвенную
модель. При этом ключевую роль играет модуль JAM/TPi-Server, так как основная
трудность внедрения трехзвенной модели заключается в реализации логики приложения в
сервисах менеджеров транзакций.
79
Интерфейс JAM/CASE подобен интерфейсу к СУБД и позволяет осуществить
обмен информацией между репозиторием объектов JAM и репозиторием CASE-средства
аналогично тому, как структура БД импортируется в репозиторий JAM непосредственно
из БД. Отличие заключается в том, что в случае интерфейса к CASE этот обмен является
двунаправленным. Кроме модулей JAM/CASEi, существует также модуль JAM/CASEi
Developer's Kit. С помощью этого модуля можно самостоятельно разработать интерфейс
(т.е. специализированный модуль JAM/CASEi) для конкретного CASE-средства, если
готового модуля JAM/CASEi для него не существует.
Мост (интерфейс) Silverrun-RDM <-> JAM реализует взаимодействие между CASEсредством Silverrun и JAM (перенос схемы базы данных и экранных форм приложения
между CASE-средством Silverrun-RDM и JAM версии 7.0). Данный программный продукт
имеет 2 режима работы:
- прямой режим (Silverrun-RDM->JAM) предназначен для создания объектов CASEсловаря и элементов репозитория JAM на основе представления схем в Silverrun-RDM.
В этом режиме мост позволяет, исходя из представления моделей данных интерфейса в
Silverrun-RDM, производить генерацию экранов и элементов репозитория JAM. Мост
преобразует таблицы и отношения реляционных схем RDM в последовательность
объектов JAM соответствующих типов. Методика построения моделей данных
интерфейса в Silverrun-RDM предполагает применение механизма подсхем для
прототипирования экранов приложения. По описанию каждой из подсхем RDM мост
генерирует экранную форму JAM;
- обратный режим (JAM->Silverrun-RDM) предназначен для переноса модификаций
объектов CASE-словаря в реляционную модель Silverrun-RDM.
Режим реинжиниринга позволяет переносить модификации всех свойств экранов
JAM, импортированных ранее из RDM, в схему Silverrun. На этом этапе для контроля
целостности базы данных не допускаются изменения схемы в виде добавления или
удаления таблиц и полей таблиц.
Групповая работа
Ядро JAM имеет встроенный интерфейс к средствам конфигурационного
управления (PVCS на платформе Windows и SCCS на платформе UNIX). Под управлением
этих систем передаются библиотеки экранов и/или репозитории. При отсутствии таких
систем JAM самостоятельно реализует часть функций поддержки групповой разработки.
Использование PVCS (см. подраздел 5.6) является более предпочтительным по
сравнению с SCCS, так как позволяет организовать единый архив модулей проекта для
всех платформ. Так как JAM на платформе UNIX не имеет прямого интерфейса к архивам
PVCS, то выборка модулей из архива и возврат их в архив производятся с использованием
PVCS Version Manager. На платформе MS-Windows JAM имеет встроенный интерфейс к
PVCS и действия по выборке/возврату производятся непосредственно из среды JAM.
Среда функционирования
JAM, как среда разработки, и приложения, построенные с его использованием, не
являются ресурсоемкими системами. Например, на платформе MS-Windows достаточно
иметь 8MB оперативной памяти и 50 MB дискового пространства для среды разработки.
На UNIX-платформах требования к аппаратуре определяются самой операционной
системой.
Методология DATARUN и CASE-средство Silverrun
Одной из наиболее распространенных в мире электронных методологий является
методология DATARUN. В соответствии с методологией DATARUN ЖЦ ПО разбивается
на стадии, которые связываются с результатами выполнения основных процессов,
определяемых стандартом ISO 12207. Каждую стадию кроме ее результатов должен
завершать план работ на следующую стадию.
80
Стадия формирования требований и планирования включает в себя действия по
определению начальных оценок объема и стоимости проекта. Должны быть
сформулированы требования и экономическое обоснование для разработки ИС,
функциональные модели (модели бизнес-процессов организации) и исходная
концептуальная модель данных, которые дают основу для оценки технической
реализуемости проекта. Основными результатами этой стадии должны быть модели
деятельности организации (исходные модели процессов и данных организации),
требования к системе, включая требования по сопряжению с существующими ИС,
исходный бизнес-план.
Стадия концептуального проектирования начинается с детального анализа
первичных данных и уточнения концептуальной модели данных, после чего
проектируется архитектура системы. Архитектура включает в себя разделение
концептуальной модели на обозримые подмодели. Оценивается возможность
использования существующих ИС и выбирается соответствующий метод их
преобразования. После построения проекта уточняется исходный бизнес-план.
Выходными компонентами этой стадии являются концептуальная модель данных, модель
архитектуры системы и уточненный бизнес-план.
На стадии спецификации приложений продолжается процесс создания и
детализации проекта. Концептуальная модель данных преобразуется в реляционную
модель данных. Определяется структура приложения, необходимые интерфейсы
приложения в виде экранов, отчетов и пакетных процессов вместе с логикой их вызова.
Модель данных уточняется бизнес-правилами и методами для каждой таблицы. В конце
этой стадии принимается окончательное решение о способе реализации приложений. По
результатам стадии должен быть построен проект ИС, включающий модели архитектуры
ИС, данных, функций, интерфейсов (с внешними системами и с пользователями),
требований к разрабатываемым приложениям (модели данных, интерфейсов и функций),
требований к доработкам существующих ИС, требований к интеграции приложений, а
также сформирован окончательный план создания ИС.
На стадии разработки, интеграции и тестирования должна быть создана тестовая
база данных, частные и комплексные тесты. Проводится разработка, прототипирование и
тестирование баз данных и приложений в соответствии с проектом. Отлаживаются
интерфейсы с существующими системами. Описывается конфигурация текущей версии
ПО. На основе результатов тестирования проводится оптимизация базы данных и
приложений. Приложения интегрируются в систему, проводится тестирование
приложений в составе системы и испытания системы. Основными результатами стадии
являются готовые приложения, проверенные в составе системы на комплексных тестах,
текущее описание конфигурации ПО, скорректированная по результатам испытаний
версия системы и эксплуатационная документация на систему.
Стадия внедрения включает в себя действия по установке и внедрению баз данных
и приложений. Основными результатами стадии должны быть готовая к эксплуатации и
перенесенная на программно-аппаратную платформу заказчика версия системы,
документация сопровождения и акт приемочных испытаний по результатам опытной
эксплуатации.
Стадии сопровождения и развития включают процессы и операции, связанные с
регистрацией, диагностикой и локализацией ошибок, внесением изменений и
тестированием, проведением доработок, тиражированием и распространением новых
версий ПО в места его эксплуатации, переносом приложений на новую платформу и
масштабированием системы. Стадия развития фактически является повторной итерацией
стадии разработки.
Методология DATARUN опирается на две модели или на два представления:
- модель организации;
- модель ИС.
81
Методология DATARUN базируется на системном подходе к описанию
деятельности организации. Построение моделей начинается с описания процессов, из
которых затем извлекаются первичные данные (стабильное подмножество данных,
которые организация должна использовать для своей деятельности). Первичные данные
описывают продукты или услуги организации, выполняемые операции (транзакции) и
потребляемые ресурсы. К первичным относятся данные, которые описывают внешние и
внутренние сущности, такие как служащие, клиенты или агентства, а также данные,
полученные в результате принятия решений, как например, графики работ, цены на
продукты.
Основной принцип DATARUN заключается в том, что первичные данные, если они
должным образом организованы в модель данных, становятся основой для
проектирования архитектуры ИС. Архитектура ИС будет более стабильной, если она
основана на первичных данных, тесно связанных с основными деловыми операциями,
определяющими природу бизнеса, а не на традиционной функциональной модели.
Любая ИС (рисунок 1) представляет собой набор модулей, исполняемых
процессорами и взаимодействующих с базами данных. Базы данных и процессоры могут
располагаться централизованно или быть распределенными. События в системе могут
инициироваться внешними сущностями, такими как клиенты у банкоматов или временные
события (конец месяца или квартала). Все транзакции осуществляются через объекты или
модули интерфейса , которые взаимодействуют с одной или более базами данных.
Рис. 1. Модель ИС
Подход DATARUN преследует две цели:
- определить стабильную структуру, на основе которой будет строиться ИС.
Такой структурой является модель данных, полученная из первичных данных,
представляющих фундаментальные процессы организации;
- спроектировать ИС на основании модели данных.
Объекты, формируемые на основании модели данных, являются объектами базы
данных, обычно размещаемыми на серверах в среде клиент/сервер. Объекты интерфейса,
определенные в архитектуре компьютерной системы, обычно размещаются на клиентской
части. Модель данных, являющаяся основой для спецификации совместно используемых
объектов базы данных и различных объектов интерфейса, обеспечивает
82
сопровождаемость ИС. На рисунке 3.2 представлена последовательность шагов
проектирования ИС.
На рисунке 3.3 определены модели, создаваемые в процессе разработки ИС. Для их
создания используется CASE-средство Silverrun. Silverrun обеспечивает автоматизацию
проведения проектных работ в соответствии с методологией DATARUN.
Предоставляемая этими средствами среда проектирования дает возможность
руководителю проекта контролировать проведение работ, отслеживать выполнение работ,
вовремя замечать отклонения от графика. Каждый участник проекта, подключившись к
этой среде, может выяснить содержание и сроки выполнения порученной ему работы,
детально изучить технику ее выполнения в гипертексте по технологиям, и вызвать
инструмент (модуль Silverrun) для реального выполнения работы.
Информационная система создается последовательным построением ряда моделей,
начиная с модели бизнес-процессов и заканчивая моделью программы,
автоматизирующей эти процессы.
Рис.2. Последовательность шагов проектирования системы
BPM
(Business
Process
Model)
модель
бизнес-процессов.
PDS
(Primary
Data
Structure)
структура
первичных
данных.
CDM
(Conceptual
Data
Model)
концептуальная
модель
данных.
SPM
(System
Process
Model)
модель
процессов
системы.
ISA (Information System Architecture) - архитектура информационной системы.
ADM
(Application
Data
Model)
модель
данных
приложения.
83
IPM (Interface Presentation Model) - модель представления интерфейса.
ISM (Interface Specification Model) - модель спецификации интерфейса.
Рис 3. Модели, создаваемые с помощью подхода DATARUN
Создаваемая ИС должна основываться на функциях, выполняемых организацией.
Поэтому первая создаваемая модель - это модель бизнес-процессов, построение которой
осуществляется в модуле Silverrun BPM. Для этой модели используется специальная
нотация BPM. В процессе анализа и спецификации бизнес-функций выявляются основные
информационные объекты, которые документируются как структуры данных, связанные с
потоками и хранилищами модели. Источниками для создания структур являются
используемые в организации документы, должностные инструкции, описания
производственных операций. Эти данные вводятся в том виде, как они существуют в
деятельности организации. Нормализация и удаление избыточности производится позже
при построении концептуальной модели данных в модуле Silverrun ERX. После создания
модели бизнес-процессов информация сохраняется в репозитории проекта.
В процессе обследования работы организации выявляются и документируются
структуры первичных данных. Эти структуры заносятся в репозиторий модуля BPM при
описании циркулирующих в организации документов, сообщений, данных. В модели
бизнес-процессов первичные структуры данных связаны с потоками и хранилищами
информации.
На основе структур первичных данных в модуле Silverrun ERX создается
концептуальная модель данных (ER-модель). От структур первичных данных
концептуальная модель отличается удалением избыточности, стандартизацией
наименований понятий и нормализацией. Эти операции в модуле ERX выполняются при
помощи встроенной экспертной системы. Цель концептуальной модели данных - описать
используемую информацию без деталей возможной реализации в базе данных, но в
хорошо структурированном нормализованном виде.
На основе модели бизнес-процессов и концептуальной модели данных
проектируется архитектура ИС. Определяются входящие в систему приложения, для
каждого приложения специфицируются используемые данные и реализуемые функции.
Архитектура ИС создается в модуле Silverrun BPM с использованием специальной
нотации ISA. Основное содержание этой модели - структурные компоненты системы и
навигация между ними. Концептуальная модель данных разбивается на части,
соответствующие входящим в состав системы приложениям.
Перед разработкой приложений должна быть спроектирована структура
корпоративной базы данных. DATARUN предполагает использование базы данных,
основанной на реляционной модели. Концептуальная модель данных после нормализации
переносится в модуль реляционного моделирования Silverrun RDM с помощью
специального моста ERX-RDM. Преобразование модели из формата ERX в формат RDM
происходит автоматически без вмешательства пользователя. После преобразования
форматов получается модель реляционной базы данных. Эта модель детализируется в
модуле Silverrun RDM определением физической реализации (типов данных СУБД,
ключей, индексов, триггеров, ограничений ссылочной целостности). Правила обработки
данных можно задавать как непосредственно на языке программирования СУБД, так и в
декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным
СУБД переводят эти декларативные правила на язык требуемой системы, что снижает
трудоемкость программирования процедур сервера базы данных, а также позволяет из
одной спецификации генерировать приложения для разных СУБД.
С помощью модели системных процессов детально документируется поведение
каждого приложения. В модуле BPM создается модель системных процессов,
определяющая, каким образом реализуются бизнес-процессы. Эта модель создается
отдельно для каждого приложения и тесно связана с моделью данных приложения.
84
Приложение состоит из интерфейсных объектов (экранных форм, отчетов,
процедур обработки данных). Каждый интерфейс системы (экранная форма, отчет,
процедура обработки данных) имеет дело с подмножеством базы данных. В модели
данных приложения (созданной в модуле RDM) создается подсхема базы данных для
каждого интерфейса этого приложения. Уточняются также правила обработки данных,
специфичные для каждого интерфейса. Интерфейс работает с данными в
ненормализованном виде, поэтому спецификация данных, как ее видит интерфейс,
оформляется как отдельная подсхема модели данных интерфейса.
Модель представления интерфейса - это описание внешнего вида интерфейса, как
его видит конечный пользователь системы. Это может быть как документ, показывающий
внешний вид экрана или структуру отчета, так и сам экран (отчет), созданный с помощью
одного из средств визуальной разработки приложений - так называемых языков
четвертого поколения (4GL - Fourth Generation Languages). Так как большинство языков
4GL позволяют быстро создавать работающие прототипы приложений, пользователь
имеет возможность увидеть работающий прототип системы на ранних стадиях
проектирования.
После создания подсхем реляционной модели для приложений проектируется
детальная структура каждого приложения в виде схемы навигации экранов, отчетов,
процедур пакетной обработки. На данном шаге эта структура детализируется до указания
конкретных столбцов и таблиц базы данных, правил их обработки, вида экранных форм и
отчетов. Полученная модель детально документирует приложение и непосредственно
используется для программирования специфицированных интерфейсов.
Далее, с помощью средств разработки приложений происходит физическое
создание системы: приложения программируются и интегрируются в информационную
систему.
CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc.
(CSA) используется для анализа и проектирования ИС бизнес-класса [22] и ориентировано
в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой
методологии, основанной на раздельном построении функциональной и информационной
моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Настройка на конкретную методологию обеспечивается выбором требуемой
графической нотации моделей и набора правил проверки проектных спецификаций. В
системе имеются готовые настройки для наиболее распространенных методологий:
DATARUN (основная методология, поддерживаемая Silverrun), Gane/Sarson,
Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия,
введенного в проекте имеется возможность добавления собственных описателей.
Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.
Структура и функции
Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из
которых является самостоятельным продуктом и может приобретаться и использоваться
без связи с остальными модулями.
Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных
(BPM - Business Process Modeler) позволяет моделировать функционирование
обследуемой организации или создаваемой ИС. В модуле BPM обеспечена возможность
работы с моделями большой сложности: автоматическая перенумерация, работа с деревом
процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение
частей модели для коллективной разработки. Диаграммы могут изображаться в
нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson.
Имеется также возможность создавать собственные нотации, в том числе добавлять в
число изображаемых на схеме дескрипторов определенные пользователем поля.
85
Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert)
обеспечивает построение моделей данных "сущность-связь", не привязанных к
конкретной реализации. Этот модуль имеет встроенную экспертную систему,
позволяющую создать корректную нормализованную модель данных посредством ответов
на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение
модели данных из описаний структур данных. Анализ функциональных зависимостей
атрибутов дает возможность проверить соответствие модели требованиям третьей
нормальной формы и обеспечить их выполнение. Проверенная модель передается в
модуль RDM.
Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет
создавать детализированные модели "сущность-связь", предназначенные для реализации в
реляционной базе данных. В этом модуле документируются все конструкции, связанные с
построением базы данных: индексы, триггеры, хранимые процедуры и т.д. Гибкая
изменяемая нотация и расширяемость репозитория позволяют работать по любой
методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к
представлению схемы базы данных. На языке подсхем моделируются как узлы
распределенной обработки, так и пользовательские представления. Этот модуль
обеспечивает проектирование и полное документирование реляционных баз данных.
Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager)
применяется как словарь данных для хранения общей для всех моделей информации, а
также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.
Платой за высокую гибкость и разнообразие изобразительных средств построения
моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля
между компонентами различных моделей (например, возможности автоматического
распространения изменений между DFD различных уровней декомпозиции). Следует,
однако, отметить, что этот недостаток может иметь существенное значение только в
случае использования каскадной модели ЖЦ ПО.
Взаимодействие с другими средствами
Для автоматической генерации схем баз данных у Silverrun существуют мосты к
наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server,
SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются
мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все
мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих
СУБД или языков 4GL. Это позволяет документировать, перепроектировать или
переносить на новые платформы уже находящиеся в эксплуатации базы данных и
прикладные системы. При использовании моста Silverrun расширяет свой внутренний
репозиторий специфичными для целевой системы атрибутами. После определения
значений этих атрибутов генератор приложений переносит их во внутренний каталог
среды разработки или использует при генерации кода на языке SQL. Таким образом
можно полностью определить ядро базы данных с использованием всех возможностей
конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности.
При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun,
используются либо для автоматической генерации интерфейсных объектов, либо для
быстрого их создания вручную.
Для обмена данными с другими средствами автоматизации проектирования,
создания специализированных процедур анализа и проверки проектных спецификаций,
составления специализированных отчетов в соответствии с различными стандартами в
системе Silverrun имеется три способа выдачи проектной информации во внешние файлы:
Система отчетов. Можно, определив содержимое отчета по репозиторию, выдать
отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редактор или
включить в другой отчет;
86
Система экспорта/импорта. Для более полного контроля над структурой файлов в
системе экспорта/импорта имеется возможность определять не только содержимое
экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца
текстовых полей. Файлы с указанной структурой можно не только формировать, но и
загружать в репозиторий. Это дает возможность обмениваться данными с различными
системами: другими CASE-средствами, СУБД, текстовыми редакторами и электронными
таблицами;
Хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к
данным репозитория из наиболее распространенных систем управления базами данных
обеспечена возможность хранить всю проектную информацию непосредственно в
формате этих СУБД.
Групповая работа
Групповая работа поддерживается в системе Silverrun двумя способами:
В стандартной однопользовательской версии имеется механизм контролируемого
разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким
разработчикам. После детальной доработки модели объединяются в единые
спецификации;
Сетевая версия Silverrun позволяет осуществлять одновременную групповую
работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle, Sybase или
Informix. При этом несколько разработчиков могут работать с одной и той же моделью,
так как блокировка объектов происходит на уровне отдельных элементов модели.
Среда функционирования
Имеются реализации Silverrun трех платформ - MS Windows, Macintosh и OS/2
Presentation Manager - с возможностью обмена проектными данными между ними.
Для функционирования в среде Windows необходимо иметь компьютер с
процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб
(рекомендуется 16 Мб). На диске полная инсталляция Silverrun занимает 20 Мб.
Объектно-ориентированные CASE-средства (Rational Rose). Методология
RUP
Техническое описание Rational Rose
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для
генерации кодов на различных языках и выпуска проектной документации. Rational Rose
использует синтез-методологию объектно-ориентированного анализа и проектирования,
основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и
Джекобсона. Разработанная ими универсальная нотация для моделирования объектов
(UML - Unified Modeling Language) претендует на роль стандарта в области объектноориентированного анализа и проектирования.
Существуют следующие варианты Rational Rose:
- Rose Modeler, позволяющий разрабатывать модели системы, но не
поддерживающий возможности генерации кода и обратного проектирования;
- Rose Enterprise, который позволяет генерировать код на C++, Java, Visual Basic,
схемы Oracle, кроме того, содержит средства реинжиниринга программ,
обеспечивающие повторное использование программных компонент в новых
проектах.
- Rose Professional, позволяющий генерировать код и осуществлять
реинжиниринг для какого-либо одного языка.
Взаимодействие с другими средствами и организация групповой работы
87
Rational Rose интегрируется со средством PVCS для организации групповой
работы и управления проектом и со средством SoDA - для документирования проектов.
Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.
Для организации групповой работы в Rational Rose возможно разбиение модели на
управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается
в модель. В качестве подмодели может выступать категория классов или подсистема.
Для управляемой подмодели предусмотрены операции:
- загрузка подмодели в память;
- выгрузка подмодели из памяти;
- сохранение подмодели на диске в виде отдельного файла;
- установка защиты от модификации;
- замена подмодели в памяти на новую.
Наиболее эффективно групповая работа организуется при интеграции Rational Rose
со специальными средствами управления конфигурацией и контроля версий (PVCS). В
этом случае защита от модификации устанавливается на все управляемые подмодели,
кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты
от записи устанавливается для файлов, которые содержат подмодели, поэтому при
считывании "чужих" подмоделей защита их от модификации сохраняется и случайные
воздействия окажутся невозможными.
Среда функционирования
Rational Rose функционирует на различных платформах: IBM PC (в среде
Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM
RS/6000 (AIX).
Для работы системы необходимо выполнение следующих требований:
Платформа Windows - процессор 80386SX или выше (рекомендуется 80486),
память8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной
модели.
Платформа UNIX - память 32+(16*число пользователей)Mб, пространство на диске
30Mб + 20 при инсталляции + 1-3Mб для одной модели.
Совместимость по версиям обеспечивается на уровне моделей.
Структура и функции Rational Rose
В основе работы Rational Rose лежит построение картины системы, которая
содержит все диаграммы UML, определяющие логическую и физическую структуры
модели, ее статические и динамические аспекты.
В составе Rational Rose можно выделить 6 основных структурных компонент:
- репозиторий,
- графический интерфейс пользователя,
- средства просмотра проекта (browser),
- средства контроля проекта,
- средства сбора статистики,
- генератор документов.
К ним добавляются генератор кодов (индивидуальный для каждого языка) и
анализатор, обеспечивающий реинжиниринг - восстановление модели проекта по
исходным текстам программ.
Репозиторий содержит объекты, из которых формируются диаграммы модели.
Браузер обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям
классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства
контроля и сбора статистики дают возможность находить и устранять ошибки по мере
88
развития проекта, а не после завершения его описания. Генератор отчетов формирует
тексты выходных документов.
Средства автоматической генерации кодов программ, используя информацию,
содержащуюся в логической и физической моделях проекта, формируют файлы
заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет
программы может быть уточнен путем прямого программирования.
Назначение анализатора кодов состоит в том, чтобы создавать модули проектов в
форме Rational Rose на основе информации, содержащейся в определяемых пользователем
исходных текстах программ. В процессе работы анализатор осуществляет контроль
правильности исходных текстов и диагностику ошибок. Модель, полученная в результате
его работы, может целиком или фрагментарно использоваться в различных проектах.
Анализатор обладает широкими возможностями настройки по входу и выходу. Например,
можно определить типы исходных файлов, базовый компилятор, задать, какая
информация должна быть включена в формируемую модель и какие элементы выходной
модели следует выводить на экран. Таким образом, Rational Rose обеспечивает
возможность повторного использования программных компонент.
Основные элементы интерфейса среды Rational Rose
Основными элементами интерфейса являются:
- Браузер (browser) – используется для быстрой навигации по модели;
- Окно документации (documentation window) – применяется для работы с
документацией элементов модели;
- Панели инструментов (toolbars) – обеспечивают быстрый доступ к наиболее
распространенным командам;
- Меню – позволяет выполнять команды;
- Окно диаграмм (diagram window) – используется для просмотра и
редактирования одной или нескольких диаграмм;
- Журнал (log) – применяется для просмотра ошибок и отчетов о результатах
выполнения различных команд.
Представления модели Rational Rose
Модель Rose поддерживает четыре представления
(views): представление
вариантов использования, логическое представление, представление компонентов и
представление размещения.
Представление вариантов использования включает в себя:
- всех действующих лиц;
- все варианты использования;
- документацию по вариантам использования, детализирующую происходящие в
них процессы, включая обработку ошибок;
- диаграммы вариантов использования;
- диаграммы взаимодействия (диаграммы последовательности и кооперативные
диаграммы), отображающие объекты или классы, принимающие участие в
одном потоке событий варианта использования. Для каждого варианта
использования можно создать множество диаграмм взаимодействия. Это
делается либо в представлении вариантов использования, либо в логическом
представлении. Как правило, не зависящие от языка программирования
реализации диаграмм взаимодействия создают в представлении вариантов
использования. Обычно такие диаграммы показывают взаимодействие
89
объектов, а не классов. Диаграммы взаимодействия, зависящие от языка,
обычно находятся в логическом представлении, они, как правило отображают
классы, а не объекты (объекты с указанием классов);
- пакеты, являющиеся группами вариантов использования и/или действующих
лиц (как правило не используются).
Представление вариантов использования – это взгляд на систему, независимый от
ее реализации.
Логическое представление содержит:
- классы;
- диаграммы классов;
- диаграммы взаимодействия (диаграммы последовательности и кооперативные
диаграммы) – с указанием взаимодействующих классов;
- диаграммы состояний, описывающие логику поведения объектов;
- пакеты, являющиеся группами взаимосвязанных классов.
Логическое представление позволяет спроектировать логическую структуру
системы. Одной из ключевых особенностей является возможность повторного
использования классов или пакетов классов. Каждый новый проект пополнит библиотеку
повторно используемых классов или пакетов, в результате выполнение будущих проектов
превратится в процесс сборки целого из имеющихся составных частей.
Представление компонентов содержит:
- компоненты, являющиеся физическими модулями кода;
- диаграммы компонентов, отображающие компоненты и их связи;
- пакеты, являющиеся группами связанных компонентов (часто их группируют в
целях повторного использования).
В представление размещения входят:
- процессы, которые являются потоками, исполняемыми в отведенной для них
области памяти;
- процессоры, т.е. аппаратура, способная обрабатывать данные;
- устройства, т.е. аппаратура, не способная обрабатывать данные.
Работа в Rational Rose
Первым шагом в работе с Rose является создание моделей. Их можно либо строить
с нуля, либо взять за основу существующую каркасную модель. Готовую модель Rose со
всеми диаграммами и другими элементами можно сохранить в одном файле, имеющем
расширение .mdl (model).
Для облегчения повторного использования Rose поддерживает экспорт и импорт
моделей и их элементов.
С помощью Rational Rose можно публиковать модели на Web-страницах – в
корпоративной сети предприятия (интранет) или в Интернет. Это даст возможность всем
желающим изучить проект не использую Rose и не распечатывая большое количество
соответствующей документации.
Среда Rose поддерживает многопользовательскую параллельную разработку
моделей с помощью управляемых элементов (controlled units). Управляемым элементом
может быть любой пакет, входящий в логическое представление, в представление
вариантов использования или компонентов системы. Управляющий элемент сохраняется в
отдельном файле, а не в общем файле модели. Этот файл можно контролировать с
помощью таких инструментов, как Rational ClearCase, Microsoft SourceSafe или в самой
среде Rose. Можно загружать и выгружать управляемые элементы из рассматриваемой
модели, подключать и отключать их проверку
90
Методология RUP
Методология RUP (Rational Unified Process) разработана компанией Rational
Software. Она ориентирована на использование языка объектно-ориентированного
моделирования UML и CASE-средства Rational Rose.
Согласно этой методологии жизненный цикл ПО разбивается на отдельные циклы,
в каждом из которых создается новое поколение продукта (т.е. спиральная модель ЖЦ).
Каждый цикл в свою очередь разбивается на четыре последовательных стадии:
- начальная стадия (inception),
- стадия уточнения (elaboration),
- стадия конструирования (construction),
- стадия ввода в действие (transition).
Начальная фаза – это начало работы над проектом. Во время нее исследуются и
документируются свойства системы на высоком уровне. Определяются действующие лица
и варианты использования, строятся диаграммы вариантов использования.
Начальная фаза завершается, когда исследование закончено и для работы над
проектом выделены необходимые ресурсы.
Начальная фаза проекта в основном последовательна и не итеративна, т.е. основная
работа проводится один раз в ходе выполнения проекта так как проект может быть начат
только один раз. В отличие от нее, другие фазы итеративны. По этой причине в начальной
фазе должна быть решена еще одна задача – разработка плана итераций. Это план,
описывающий, какие варианты использования на каких итерациях должны быть
реализованы. Если, например, в начальной фазе было выделено 10 вариантов
использования, можно создать следующий план.6
Итерация 1 – варианты использования 1, 5, 6
Итерация 2 – варианты использования 7, 9
Итерация 3 – варианты использования 2, 4, 8
Итерация 4 – варианты использования 3, 10
План определяет, какие варианты использования надо реализовать в первую
очередь. Построение плана требует рассмотрения зависимостей между вариантами
использования. Если для того, чтобы мог работать вариант использования 5 необходима
реализация варианта использования 3, то описанный выше план неосуществим, поскольку
вариант использования 3 реализуется на четвертой итерации – значительно позже
варианта использования 5 из первой итерации.
Rational Rose в начальной стадии можно применять для документирования
вариантов использования и действующих лиц, а также для создания диаграмм,
показывающих связи между ними. Полученные диаграммы вариантов использования
могут быть показаны пользователям, чтобы убедиться, что они дают достаточно полное
представление о свойствах системы.
В фазе уточнения проекта выполняются некоторое планирование, анализ и
проектирование архитектуры. Следуя плану итерации уточнение проводится для каждого
варианта использования в текущей итерации.
Основная задача фазы уточнения – детализация вариантов использования,
включающая в себя в том числе разработку диаграмм классов и состояний. Из требований,
определенных в форме детализированных вариантов использования, составляется
документ под названием «Спецификация требований к программному обеспечению»
(Software Requirement Specification, SRS). SRS содержит детальное описание всех
требований к системе.
Фаза уточнения завершается, когда варианты использования полностью
детализированы и одобрены пользователем, разработаны диаграммы классов. Иными
словами, эта фаза пройдена, когда система спроектирована, рассмотрена и готова для
передачи разработчикам.
91
Фаза уточнения предоставляет несколько возможностей для использования Rational
Rose. Так как уточнение – это детализация требований к системе, модель вариантов
использования может потребовать обновления. Диаграммы последовательности и
кооперативные диаграммы помогают проиллюстрировать поток обработки данных при
его детализации. С их помощью можно также спроектировать требуемые для системы
объекты. Уточнение предполагает подготовку проекта системы для передачи
разработчикам, которые начнут ее конструирование. В среде Rose это может быть
выполнено путем создания диаграмм классов и диаграмм состояний.
Конструирование – это процесс разработки и тестирования программного
обеспечения. Как и в случае уточнения та фаза выполняется для каждого набора
вариантов использования на каждой итерации. Задача конструирования включает в себя
определение всех оставшихся требований, разработку и тестирование программного
обеспечения. Так как ПО полностью проектируется в фазе уточнения, конструирование не
предполагает большого количества решений по проекту, что позволяет команде работать
параллельно. Это означает, что разные группы программистов могут одновременно
работать над различными объектами ПО, зная, что по завершении фазы система
«сойдется». В фазе уточнения были спроектированы объекты системы и их
взаимодействие. Конструирование только наполняет разработанные структуры ПО, новых
решений, способных изменить взаимодействие, не принимается.
В начале этапа конструирования возможна автоматическая генерация «скелетного
кода» системы. Для этого следует разработать компоненты и диаграмму компонентов.
Генерацию кода можно начать сразу после создания компонентов и нанесения на
диаграмму зависимостей между ними. В результате будет автоматически построен код,
который можно создать, основываясь на проекте системы. Это не означает, что с
помощью Rose можно получить любой код, реализующий функциональность
приложений. Результат сильно зависит от используемого языка программирования, но в
общем случае предполагает определение классов, атрибутов, прототипов методов,
областей действия и операторов наследования. Это позволяет сэкономить время, так как
написание кода вручную – кропотливая и утомительная работа. Получив такой шаблон
кода, программисты могут сконцентрироваться на специфических аспектах проекта,
связанных с его функциональностью.
Далее еще одна группа разработчиков должна выполнить экспертную оценку кода,
чтобы убедиться в его функциональности и соответствии стандартам и соглашениям по
проекту. Затем объекты должны быть подвергнуты оценке качества. Если в фазе
конструирования были добавлены новые атрибуты или функции или если были изменены
взаимодействия между объектами, код следует преобразовать в модель Rose с помощью
обратного проектирования.
Конструирование можно считать завершенным, когда программное обеспечение
готово и протестировано. Важно убедиться в адекватности модели и программного
обеспечения; модель будет чрезвычайно полезна в процессе сопровождения ПО.
Таким образом, на этапе конструирования Rational Rose используется для
проектирования компонентов и диаграмм компонентов. После выбора языка
программирования можно осуществить генерацию скелетного кода для каждого
компонента. По завершению работы над кодом модель можно привести в соответствие с
ним с помощью обратного проектирования.
Фаза ввода в действие наступает, когда готовый программный продукт передают
пользователям. Задачи в этой фазе предполагают завершение работы над финальной
версией продукта, завершение приемочного тестирования, завершение составления
документации и подготовку к обучению пользователей. Чтобы отразить последние
внесенные изменения необходимо обновить диаграммы модели. Важно, чтобы модели
были синхронизированы с готовым продуктом, поскольку они будут использоваться при
92
его сопровождении. Также они будут неоценимы при внесении усовершенствований в
созданную систему через несколько месяцев после завершения проекта.
В фазе вода в действия Rational Rose не настолько полезна. Как в других фазах. В
этот момент приложение уже создано. Rose предназначена для оказания помощи при
моделировании и разработке программного обеспечения и даже при планировании его
размещения. Однако Rose не является инструментом тестирования и не способна помочь в
планировании тестов или процедур, связанных с размещением ПО. Для этой цели созданы
другие продукты.
Итак, в фазе ввода в действие Rose применяется прежде всего для обновления
моделей после завершения работы над программным продуктом.
Генерация программного кода с помощью Rational Rose
Процесс генерации кода состоит из следующих этапов:
- проверка модели,
- создание компонентов,
- отображение классов на компоненты,
- установка свойств генерации программного кода,
- выбор класса, компонента или пакета,
- генерация программного кода.
В разных языках не все этапы обязательны. Так, программы С++ генерируются и
без предварительного создания компонентов. Создать код программ на любом языке
можно, не выполняя шага проверки модели, хотя во время генерации это приводит порой
к ошибкам. Хотя не все этапы обязательны, рекомендуется выполнять их все.
Проверка модели. В Rose существует независимое от языка средство проверки
моделей, применяемое для обеспечения корректности модели перед генерацией
программного кода.
К наиболее распространенным ошибкам относятся следующие:
- сообщения на диаграмме последовательности или кооперативной диаграмме не
отображены на операцию;
- объекты этих диаграмм не отображены на класс;
- нарушены правила доступа – например, существует связь между классами
пакетов, когда связи между пакетами нет.
Кроме этого возможны проверки, специфичные для выбранного языка
программирования.
Создание компонентов и отображение классов на компоненты, возможно,
выполняется до генерации кода или не выполняется вообще.
Установка параметров генерации программного кода производится для
классов, атрибутов, компонентов и других элементов модели. В Rose предлагаются
общеупотребительные установки по умолчанию и возможность менять свойства как всех
элементов модели, так и каждого отдельного элемента.
Выбор класса, компонента или пакета – при генерации программного кода
можно за один раз создать класс, компонент или целый пакет. При генерации кода пакета
можно выбрать или пакет логического представления или пакет представления
компонентов. Программный код можно генерировать одновременно для нескольких
классов, компонентов или пакетов.
Генерация программного кода – после выбора класса или компонента на
диаграмме следует выбрать в меню соответствующий вариант генерации кода. Сообщения
об ошибках, возникающих в процессе генерации кода, будут появляться в окне журнала.
Результаты генерации. Во время генерации программного кода Rose выбирает
информацию из логического и компонентного представлений модели. Хотя полностью
законченное приложение не может быть создано ни одним инструментом моделирования,
Rose генерирует большой объем «скелетного» программного кода:
93
классы – генерируются все классы модели;
атрибуты – код включает атрибуты каждого класса с указанием видимости,
типа данных и значения по умолчанию;
- сигнатуры операций – код содержит определения всех операций со всеми
параметрами, типами данных параметров и типами возвращаемого значения
операции;
- связи – некоторые из связей модели вызывают создание атрибутов при
генерации кода;
- компоненты – каждый компонент реализуется в виде соответствующего файла с
исходным кодом.
При генерации программного кода Rose использует для создания каталогов
пакетную структуру, определенную в представлении компонентов. Если компоненты не
установлены, то пакетную структуру логического представления.
После генерации файлов остается сделать два шага. Сначала разработчики
обращаются к файлам и кодируют каждую из операций класса. Затем проектируется
графический пользовательский интерфейс.
Rose не является инструментальным средством разработки графического
интерфейса, поэтому для создания экранов и форм следует пользоваться средой своего
языка программирования. Rose предназначен только для того, чтобы спроектировать ту
часть программной системы, которая несет функциональную нагрузку, что, вообще, и
определяет качество программного продукта.
-
Обратное проектирование с помощью Rational Rose
Обратное проектирование – это средство получения информации из исходного
программного кода и создания или обновления модели Rose. Одной из трудностей,
возникающих при работе с программными проектами является согласованность модели с
программами. Порой с изменением требований возникает желание модифицировать
программные конструкции напрямую, не изменяя модели и не генерируя затем из нее
измененные
конструкции.
Обратное
проектирование
позволяет
обеспечить
синхронизацию модели и кода программ.
В процессе обратного проектирования Rose собирает информацию о:
- классах,
- атрибутах,
- операциях,
- связях,
- пакетах,
- компонента.
Используя эти сведения, Rose создает или обновляет объектную модель.
Если существует файл с исходным программным кодом, содержащий класс, то в
процессе обратного проектирования создается соответствующий класс модели Rose.
Каждый атрибут и каждая операция класса становятся атрибутами и операциями нового
класса модели. Вместе с именами атрибутов и операций Rose выбирает информацию об их
видимости, типах данных и значениях по умолчанию.
Если классы первоначально были созданы с помощью Rose и если в их
программный код были внесены некоторые изменения, то они в процессе обратного
проектирования отражаются в модели. Если добавить атрибут или операцию
непосредственно в программный код, то он или она при обратном проектировании
добавятся в модель.
Rose извлекает из программного кода сведения не только о классах, но и о связях.
Если в одном из классов содержится атрибут, типом данных которого является другой
класс, то Rose создает связь между двумя классами (ассоциации).
94
Связи наследования также генерируются в модели Rose. Rose создает для
поддержки наследования связи обобщения.
Компоненты программного кода также отражаются в Rose после обратного
проектирования. Компоненты разных языков проектирования отличаются друг от друга.
Итеративная разработка. В процессе генерации программного кода с помощью
Rose внутри него размещаются идентификационные номера, типа:
@roseuid 36730С530302
Они используются для идентификации классов, операций и других элементов
модели в коде программ для синхронизации программного кода с моделью Rose.
Кроме идентификационных номеров Rose в процессе генерации создает в коде
защищенные области. Любой программный код, записываемый в такие области, защищен
в процессе итеративной разработки.
Пример:
Void SampleClass::DoSomething ()
{
//## begin SampleClass::DoSomething%36EAB3DB03AC.body preserve=yes
// - программный код операции
//## end SampleClass::DoSomething%36EAB3DB03AC.body
}
Когда разработчики пишут программную конструкцию для этого класса, они
помещают операцию DoSomething между операторами //begin и //end, в защищенную
область. Если класс генерируется по-новому (в результате обратного проектирования или
внесения изменений в модель), код операции DoSomething остается защищенным.
Локальные CASE средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
ERwin - средство концептуального моделирования БД, использующее методологию
IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке
целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и
др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных
конфигурациях, ориентированных на наиболее распространенные средства разработки
приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки
приложений PowerBuilder и SQLWindows и позволяет экспортировать описание
спроектированной БД непосредственно в репозитории данных средств.
Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi,
Visual Basic) выполняется генерация форм и прототипов приложений.
Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и
приложений в рамках рабочей группы.
BPwin - средство функционального моделирования, реализующее методологию
IDEF0.
Возможные конфигурации и ориентировочная стоимость средств (без технической
поддержки) приведены в таблице.
Конфигурация
Стоимость, $
ERwin/ERX
3,295
Bpwin
2,495
ERwin/ERX for PowerBuilder, Visual Basic, Progress
3,495
ERwin/ERX for Delphi
4,295
ERwin/Desktop for PowerBuilder, Visual Basic
495
ERwin/ERX for SQLWindows / Designer/2000 / Solaris
3,495 / 5,795 / 6,995
ModelMart 5 / 10 user
11,995 / 19,995
95
3,995
Erwin/OPEN for ModelMart
S-Designor 4.2 представляет собой CASE-средство для проектирования
реляционных баз данных. По своим функциональным возможностям и стоимости он
близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах
нотацией. S-Designor реализует стандартную методологию моделирования данных и
генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2,
Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.
S-Designor совместим с рядом средств разработки приложений (PowerBuilder,
Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории
данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов
приложений.
CASE.Аналитик 1.1 является практически единственным в настоящее время
конкурентоспособным отечественным CASE-средством функционального моделирования
и реализует построение диаграмм потоков данных в соответствии с методологией,
описанной в подразделе 2.3. Его основные функции:
- построение и редактирование DFD;
- анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;
- получение разнообразных отчетов по проекту;
- генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и
34.ХХХ.
Среда функционирования: процессор - 386 и выше, основная память - 4 Мб,
дисковая память - 5 Мб, MS Windows 3.x или Windows 95.
Ориентировочная стоимость:
однопользовательская версия - 605 $;
многопользовательская версия (одно рабочее место) - 535 $.
База данных проекта реализована в формате СУБД Paradox и является открытой
для доступа.
С помощью отдельного программного продукта (Catherine) выполняется обмен
данными с CASE-средством ERwin. При этом из проекта, выполненного в
CASE.Аналитике, экспортируется описание структур данных и накопителей данных,
которое по определенным правилам формирует описание сущностей и их атрибутов.
Надежность программных средств
Основные понятия надежности систем.
По определению, установленному в ГОСТ 13377-75 надежность – свойство
объекта выполнять заданные функции, сохраняя во времени значения установленных
эксплуатационных показателей в заданных пределах, соответствующим заданным
режимам и условиям использования, технического обслуживания, ремонта, хранения и
транспортирования. Таким образом, надежность является внутренним свойством системы,
заложенным при ее создании и проявляющимся во времени при функционировании и
эксплуатации.
Свойства надежности изделий изучаются теорией надежности, которая является
системой определенных идей, математических моделей и методов, направленных на
решение проблемы предсказания, оценки и оптимизации различных показателей
надежности.
Надежность технических систем определяется в основном двумя факторами:
надежностью компонент и дефектами в конструкции, допущенными при
проектировании или изготовлении. Относительно невысокая физическая надежность
компонент, их способность к разрушению, старению или снижению надежности в
процессе эксплуатации привели к тому, что этот фактор является доминирующим для
большинства комплексов аппаратуры. Этому способствует также невысокая сложность
96
многих технических систем, вследствие чего дефекты проектирования проявляются
относительно редко.
Надежность сложных программных средств определена этими же факторами,
однако преобладают дефекты и ошибки проектирования, так как физическое хранение
программы на магнитных носителях характеризуется очень высокой надежностью.
Программа любой сложности и назначения при строго фиксированных исходных данных
и абсолютно надежной аппаратуре исполняется по однозначно определенному маршруту
и дает на выходе строго определенный результат. Однако случайное изменение исходных
данных и накопленной при обработке информации, а также множество условных
переходов в программе создают огромное число маршрутов исполнения каждой сложной
программы. Источникам ненадежности являются непроверенные сочетания исходных
данных, при которых функционирующее ПО дает неверные результаты или отказы.
Отличия ПО от традиционных технических систем приводит к развитию теории
надежности в особом направлении – надежности программных средств.. Предметом ее
изучения является работоспособность сложных программных средств в реальном
времени.
В основе теории надежности лежит понятие о двух возможных состояниях объекта
или системы: работоспособном и неработоспособном. Работоспособным называется
такое состояние объекта, при котором он способен выполнять заданные функции с
параметрами,
установленными
технической
документацией.
В
процессе
функционирования возможен переход объекта из работоспособного состояния в
неработоспособное и обратно. С этим переходом связаны события восстановления и
отказа.
Формализации показателей качества программных средств посвящена группа
нормативных документов. В международном стандарте ISO 9126:1991 рекомендуется 6
основных характеристик качества ПС, каждая из которых детализируется несколькими
(всего 21) подхарактеристиками:
- Функциональная пригодность: пригодность для применения, точность,
защищенность, способность к взаимодействию и согласованность со
стандартами и правилами проектирования;
- Надежность: уровень завершенности (отсутствие ошибок), устойчивость к
ошибкам и перезапускаемость;
- Применимость: понятность, обучаемость и простота использования;
- Эффективность: ресурсная и временная экономичность;
- Сопровождаемость: удобство для анализа, изменяемость, стабильность и
тестируемость;
- Переносимость:
адаптируемость,
структурированность,
замещаемость,
внедряемость.
Характеристики и подхарактеристики в стандарте определены очень кратко без
комментариев и рекомендаций по их применению к конкретным системам и проектам.
Близким к описанному стандарту по иделогии, структуре и содержанию является
стандарт ГОСТ 28195-89. На верхнем уровне в нем выделено 6 показателей – факторов
качества:
надежность,
корректность,
удобство
применения,
эффективность,
универсальность и сопровождаемость. Эти факторы детализируются в совокупности 19
критериями качества на втором уровне. Дальнейшая детализация показателей качества
представлена метриками и оценочными элементами, которых насчитывается около 240.
каждый из них рекомендуется экспертно оценивать в пределах от 0 до 1. Состав
используемых факторов, критериев и метрик предлагается выбирать в зависимости от
назначения, функций и этапов ЖЦ ПС.
В стандарте ГОСТ 28806-90 формализуются общие понятия программы,
программного средства, программного продукта и их качества. Даются определения 18
97
наиболее употребляемых терминов, связанных с оценкой характеристик программ.
Уточняются понятия базовых показателей качества, приведенные в ГОСТ 28195-89.
Функциональная пригодность – это набор атрибутов, определяющий назначение,
номенклатуру, основные необходимые и достаточные функции ПС, заданные
техническим заданием заказчика или потенциального пользователя. В наиболее общем
виде функциональная пригодность проявляется в корректности и надежности ПС.
Понятие корректной (правильной) программы может рассматриваться
статически вне ее исполнения во времени. Корректность программы не определена вне
области изменения исходных данных, заданных требованиями спецификации, и не
зависит от динамики функционирования программы в реальном времени. Степень
некорректности программ определяется вероятностью попадания реальных исходных
данных в область, которая задана требованиями спецификации и технического задания,
однако не была проверена при тестировании и испытаниях.
Надежная программа прежде всего должна обеспечивать низкую вероятность
отказа в процессе функционирования в реальном времени.
Отказ – это нарушение работоспособности программного изделия, являющееся
следствием таких явлений, как нарушение кодов программ в памяти, искажение или
стирание данных в оперативной или долговременной памяти, нарушение нормального
хода вычислительного процесса.
Сбой – это самоустраняющийся отказ, не требующий внешнего вмешательства.
Основное различие между сбоем и отказом – временной показатель длительности
восстановления. Если длительность восстановления больше какого-либо порогового
значения, то аномалию в работе программы относят к отказам, иначе – к сбоям.
Быстрое реагирование на и восстановление работоспособности за время меньшее,
чем порог между сбоем и отказом, обеспечивают высокую надежность программ. При
этом некорректная программа может функционировать абсолютно надежно. В реальных
условиях по различным причинам исходные данные могут попадать в области значений,
вызывающих сбои, но, если при этом происходит достаточно быстрое восстановление,
такое что не фиксируется отказ, то такое событие не влияет на основные показатели
надежности – наработку на отказ и коэффициент готовности. Следовательно, надежность
функционирования программ является понятием динамическим, проявляющимся во
времени и существенно отличается от понятия корректности программ.
Основные показатели надежности ПС – критерий длительности наработки на отказ
и коэффициент готовности.
Для определения критерия длительности наработки на отказ измеряется время
работоспособного состояния системы между последовательными отказами или началами
нормального функционирования системы после них.
Для оценки надежности важную роль также играет поведение системы после отказа
– в процессе восстановления. Основным показателем процесса восстановления является
длительность восстановления. Обобщение характеристик отказов и восстановлений
производится в критерии коэффициент готовности. Этот показатель отражает
вероятность иметь восстанавливаемую систему в работоспособном состоянии в
произвольный момент времени. Значение коэффициента готовности соответствует доле
времени полезной работы системы на достаточно большом интервале, содержащем отказы
и восстановления.
Дестабилизирующие
факторы
надежности программных средств
и
методы
обеспечения
При анализе надежности программных средств следует рассмотреть четыре группы
основных компонент: объекты уязвимости, дестабилизирующие факторы и угрозы
98
надежности, методы предотвращения угроз надежности, последствия нарушения
надежности.
Объектами уязвимости являются:
- динамический вычислительный процесс,
- информация баз данных,
- объектный код программ,
- информация для потребителей, являющаяся результатом обработки исходных
данных.
На эти объекты уязвимости воздействуют различные дестабилизирующие
факторы, которые можно разделить на внутренние, присущие объектам уязвимости, и
внешние, обусловленные средой.
Внутренние дестабилизирующие факторы:
- ошибки проектирования;
- ошибки алгоритмизации,
- ошибки программирования,
- недостаточное качество средств защиты программ и данных от сбоев.
Внешние:
- ошибки персонала при эксплуатации,
- искажения информации в каналах связи,
- сбои и отказы аппаратуры ЭВМ,
- изменения конфигурации системы.
Полное устранение перечисленных негативных воздействий принципиально
невозможно. Но негативное влияние этих факторов может быть снижено. Для этого
применяются две группы методов: методы предотвращения угроз надежности и
оперативные методы повышения надежности.
Методы предотвращения угроз надежности включают в себя:
- предотвращение ошибок проектирования за счет эффективных технологий и
средств автоматизации обеспечения всего жизненного цикла комплекса
программ и баз данных (CASE),
- систематическое тестирование с целью обнаружения и устранение различных
дефектов и ошибок проектирования, разработки и сопровождения ПО,
- обязательная сертификация аттестованными, проблемно-ориентированными
испытательными лабораториями с целью удостоверить достигнутое качество и
надежность функционирования ПС.
Оперативные методы повышения надежности – методы оперативного
обнаружения дефектов и искажений при исполнении программ путем введения в них
временной, информационной и программной избыточности. Например:
- защита от зацикливаний осуществляется подпрограммами обслуживания
аппаратных таймеров,
- защита от останова аналогично предотвращению зацикливания,
- защита от искажений взаимного прерывания программ предусматривает
программный контроль прерываний и периодический контроль взаимодействия
со всеми абонентами,
- защита от пропуска программ или их существенных частей производится
методом ключевых сумм. При этом записывается таблица имен программ,
которые должны быть включены, и количество включений каждой. После
реализации каждой программы в таблице исключается ее код. При завершении
функциональной группы можно установить все ли необходимые программы
выполнились необходимое число раз,
- защита от перегрузки по пропускной способности заключается в прореживании
потоков информации, увеличении периодов включения некоторых
периодических программ, использовании дублирующих упрощенных программ.
99
-
-
Для обнаружения перегрузки контролируют следующие параметры:
длительность запаздывания включения некоторых низкоприоритетных
периодических программ, длительность хранения сообщений, подлежащих
включению диспетчером на обработку по низшим приоритетам, заполнения
буферных накопителей сообщениями низших приоритетов,
защита от искажений и потери накопленной информации предусматривает
контроль результатов перед их переписью в зону долговременного хранения, а
также защиту этих зон от случайной записи информации. При обнаружении
искажений вычисления продолжаются, и искаженная информация постепенно
восстанавливается. При возможности данные восстанавливаются значениями,
полученными с дублирующего компьютера,
защита квазинепрерывных переменных состоит в использовании контроля
гладкости изменения этих переменных. При первичном обнаружении
нарушений гладкости ошибочные данные исключаются из рассмотрения. При
повторных отклонениях должны применяться специальные алгоритмы,
допускающие нарушение условий гладкости (фильтрующие алгоритмы).
Тестирование программного обеспечения
Тестирование – набор процедур и действий, предназначенный для демонстрации
правильности работы программы в заданных режимах. Цель тестирования – убедиться в
отсутствии ошибок в программе. В зависимости от масштабов и требований надежности,
тестирование может занимать от 30% до 50% (и более) времени, затраченного на
разработку ПО.
Выделяют динамическое и статическое тестирование. Динамическое тестирование
– контролируемое выполнение программы на конечном множестве тестовых данных и
анализ результатов этого выполнения с целью обнаружения ошибок. Статическое
тестирование не требует выполнения программы.
Динамическое тестировании заключается в разработке тестов, прогонах тестового
набора и отладке ПО по результатам проведенного прогона. Результативным считается
тест, прогон которого привел к обнаружению ошибки.
Объектами тестирования являются:
- спецификации требований на программные модули, группы программ и
программные комплексы,
- закодированные программные модули,
- группы программ, решающие законченные функциональные задачи,
- комплексы программ, для которых завершены все виды отладки,
- программные средства, подлежащие испытаниям перед сдачей в эксплуатацию,
- сопровождаемый программный продукт до завершения его ЖЦ.
Эти объекты различаются сложностью тестирования, уровнем теоретической
разработки методов и существующей степенью автоматизации процесса тестирования.
Наиболее формализованным является тестирование спецификаций требований,
которое содержит наименьшее количество информации о программах среди всех
рассматриваемых объектов.
Наиболее полные теоретические исследования проведены для методов
тестирования программных модулей и небольших групп программ, написанных с
использованием процедурных языков программирования. Менее исследованными
остаются методы и теория тестирования групп программ, написанных с использованием
ООЯП. Мало исследованными являются методы и теория тестирования в процессе
отладки, испытаний и сопровождения крупных комплексов программ.
100
В ЖЦ ПО обычно выделяется несколько фаз тестирования, основные - модульное
тестирование, интеграционное тестирование, системное тестирование.
На разных этапах ЖЦП для каждой категории объектов тестирования ставятся свои
задачи тестирования и, соответственно, применяются свои виды тестирования и свои
категории тестов.
Для описанных выше объектов тестирования выделяются следующие категории
тестов:
1. на этапе тестирования спецификаций:
- полноты и согласованности функций программных компонент,
- согласованности интерфейса в спецификациях программных компонент,
2. На этапе тестирования программных модулей:
- Структуры программного модуля,
- Вычислений и преобразований данных программным модулем,
- Полноты функций, выполняемых модулем,
3. На этапе тестирования функциональных групп программ:
- Структуры группы программ,
- Межмодульного интерфейса группы программ,
- Выполнения ограничений по использованию памяти и длительности исполнения
группы программ,
- Полноты решения функциональных задач группой программ,
4. На этапе тестирования комплекса программ при отладке:
- полноты решения функциональных задач комплексом программ при типовых
исходных данных,
- функционирования программ в критических ситуациях по условиям и логике
решения задач,
- корректности
использования
ресурсов
памяти
и
производительности
вычислительной системы,
- параллельного исполнения различных программ,
- эффективности защиты от искажения входных данных,
- определения надежности комплекса программ,
- оценки эффективности защиты от сбоев аппаратуры и не выявленных ошибок
программ,
5. На этапе тестирования комплекса программ при испытаниях:
- Испытаний на соответствие комплекса программ техническому заданию,
- Удобства эксплуатации и взаимодействия человека с комплексом программ,
- Удобства установки и подготовки рабочей версии,
- Работы комплекса программ при конфигурациях оборудования,
- Корректности документации,
- Удобства сопровождения и модификации программ.
6. Тестирование при сопровождении комплекса программ осуществляется с
использованием практически всех категорий тестов. С этой позиции сопровождение
является повторением процесса создания программ или его отдельных этапов.
То какие именно тесты будут применяться и каким образом зависит от класса
разрабатываемых программ.
Организация и эффективное применение обширного систематического
тестирования требует больших затрат и высокой квалификации специалистов, которые в
области тестируемых программ должны иметь квалификацию не ниже, чем их
разработчики. Имеются рекомендации по созданию коллективов для выполнения
систематического тестирования, независимых от коллективов, выполняющих разработку
программ.
Рассмотрим далее три основных вида тестирования:
101
модульное: объект – программные модули,
интеграционное: объект – группы программ,
системное: объект – завершенная, интегрированное в единое целое система.
Модульное и интеграционное тестирование основаны на структурных методах,
называемых также методами «белого ящика». При применении этих методов существенно
используются знания о структуре программ. При структурном тестировании всегда
существует модель, отражающая логику работы программы и критерий проведения
тестирования, причем количество необходимых тестов при этом ограничено.
При проведении системного тестирования используется принцип «черного ящика»,
т.е. информация о структуре программы не включается в рассмотрение при построении
тестов. Вместо этого анализируется логика работы функций программы. Другое название
данной методологии – функциональное тестирование.
Деление методов тестирования на функциональные и структурные производится на
основе источника тестовых данных. Как правило, структурное и функциональное
тестирование хорошо сочетаются, так что для каждого структурного теста существует его
точная функциональная интерпретация.
-
Структурное тестирование
Структурное тестирование – это тестирование, принимающее во внимание
внутренние механизмы работы системы или компонентов. Как сказано ранее,
динамическое тестировании заключается в разработке тестов, прогонах тестового набора
и отладке ПО по результатам проведенного прогона. Таким образом, для проведения
тестирования необходимо разработать набор тестов, которые обеспечили бы заданую
степень тестированности при минимальных затратах ресурсов.
Процесс построения набора тестов при структурном тестировании делят на три
фазы:
1. конструирование графа модели программы,
2. выбор тестовых путей,
3. генерация тестов, соответствующих тестовым путям.
Первая фаза сводится к статическому анализу программы. После того, как граф
программы построен, происходит выбор тестовых путей, которые покрывают множество
элементов графа в соответствии с выбранным критерием тестирования.
Критерии тестирования
Используется два типа критериев структурного тестирования: на основе потока
управления и на основе потока данных.
Критерии тестирования на основе потока управления.
Исчерпывающее тестирование по принципу «белого ящика» предполагает
выполнение каждого пути в программе – каждой дуги управляющего графа программы
(УГП). Вершины УГП соответствуют операторам программы. Поскольку в большом
программном проекте, имеющем разветвленный граф с циклами, выполнение каждого
пути нереализуемо, то тестирование всех путей рассматривается как неперспективное
направление. Критерий покрытия всех путей носит название С2.
Два наиболее широко известных критерия выделения маршрутов для структурного
тестирования на основе УГП – критерий покрытия ветвей С1 и критерий покрытия
операторов С0.
Критерий покрытия ветвей УГП, или критерий С1, известный еще как критерий
покрытия решений, заключается в том, что хотя бы по одному разу должны быть
выполнены каждый возможный результат всех решений и передача управления при
вызове программы или подпрограммы каждой точке входа. С точки зрения УГП,
покрытие решений заключается в том, чтобы каждая его дуга и каждая входная вершина
содержались, по крайней мере, в одном из путей тестирования. Сложность тестирования
102
по критерию С1 тесно связана с топологической сложностью по Маккейбу (наиболее
известная метрика логической сложности программы).
Критерий покрытия операторов С0 заключается в выполнении каждого оператора
программы хотя бы один раз и является весьма слабым критерием, так как выполнение
каждого оператора по крайней мере один раз есть необходимое, но не достаточное
условие для приемлемого тестирования по принципу белого ящика.
Выполнение критерия покрытия решений С1 также не может гарантировать
выявление всех ошибок в программе. Например:
if (condition1 && (condition2 || function1()))
Statement1;
else
Statement2;
В этом случае покрытие решений (ветвей) может быть достигнуто без вызова
функции function1(). Если условия condition1 и condition2 принимают значения TRUE, то
они как бы закрывают важный вызов функции function1(), тогда как при условии
condition2 = FALSE эта функция будет вызвана и возможно приведет к ошибкам, так как
не была покрыта тестами.
Исходя из важности проверки всех возможных вариантов значений в булевских
выражениях, вводится критерий покрытия условий, заключающийся в покрытии всех
логических условий в программе.
Критерий покрытия решений (ветвей) и условий не заменяют друг друга, поэтому
предлагается критерий покрытия условий/решений, совмещающий требования по
покрытию и решений и условий.
Также на практике используются критерии покрытия функций программы,
согласно которому каждая функция программы должна быть вызвана хотя бы один раз, и
критерий покрытия вызовов, согласно которому каждый вызов каждой функции в
программе должен быть осуществлен хотя бы один раз.
Есть и другие критерии, хотя большинство из них является спорным.
Критерии тестирования на основе потока данных
Из всех критериев, основанных на потоке данных, наибольший интерес
представляет критерий Cdu или стратегия требуемых пар. Описаны также другие
критерии тестирования на основе потоков данных.
Выбор тестовых путей
Методы построения тестовых путей делятся на:
1. статические метолы,
2. динамические методы,
3. методы реализуемых путей.
В число статических входят эвристические и адаптивные методы.
Эвристические: каждый путь строится посредством постепенного его удлинения за
счет добавления дуг, пока не будет достигнут выход УГП. Выбор дуги производится в
соответствии с некоторой эвристикой.
Адаптивные: каждый раз добавляется только один тестовый путь, используя
предыдущие пути как руководство для выбора последующих путей с некоторой
индуктивной стратегией. Например: если существует возможность построить новый
маршрут путем замены одной из покрытых ранее тестами дуг или ветвей на непокрытую
дугу или ветвь, было бы экономично определить, как данный тест может быть
модифицирован, чтобы выполнить и эту дугу или ветвь.
Статические методы практически не учитывают при построении путей
тестирования их возможной реализуемости.
Другая возможность построения полной системы тестов – построение
покрывающего множества путей и тестовых данных одновременно. При этом можно
автоматически учитывать реализуемость или нереализуемость путей или их частей.
103
Основной идеей динамических методов является подсоединение к начальным
реализуемым отрезкам путей дальнейших их частей таким образом, чтобы:
1. не терять при этом реализуемости вновь полученных путей,
2. покрывать требуемые элементы структуры программы.
Третья группа методов заключается в выделении из множества всех путей
подмножества реализуемых путей. После этого покрывающее множество путей строится
из полученного подмножества реализуемых путей. Эту группу называют методами
реализуемых путей.
Генерация тестов
После того, как построены пути тестирования, необходимо найти соответствующие
им тесты, т.е. набор исходных данных при которых программа будет выполняться по
заданному пути, что может быть связано с определенными трудностями.
Функциональное тестирование
Функциональное тестирование – это тестирование, игнорирующее внутренние
механизмы работы программы, и фокусирующееся только на выходных значениях,
генерируемых в ответ на выбранные входные значения и условия выполнения.
Функциональное тестирование – это тестирование, проводимое для проверки
соответствия системы или компоненты специфицированным функциональным
требованиям.
Структурное тестирование никогда не сможет полностью заменить
функциональное, т.к. некоторые входные условия упускаются в процессе проектирования
программы. Поэтому структурная модель не несет в себе никакой информации о
«забытых» входных условиях. Для их проверки необходимо функциональное
тестирование.
Рассмотрим наиболее широко применяемы методы функционального тестирования.
Разработка тестов по методу эквивалентного разбиения осуществляется в два
этапа:
1. выделение классов эквивалентности,
2. построение тестов.
Классы эквивалентности выделяются путем выбора каждого входного условия
(обычно это фразы в спецификации) и разбиением его на две или более групп. Различают
два типа классов эквивалентности: правильные классы эквивалентности, представляющие
правильные входные данные программы, и неправильные классы эквивалентности,
представляющие ошибочные входные значения. Тесты проектируются таким образом,
чтобы покрыть все классы эквивалентности.
Еще один подобный метод – анализ граничных значений. Граничные условия –
это ситуации, возникающие непосредственно «на», «выше» или «ниже» границ классов
эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения в
двух отношениях:
1.
выбор любого элемента в классе эквивалентности в качестве
представительного при анализе граничных значений осуществляется
таким образом, чтобы проверить тестом каждую границу этого класса,
2.
при разработке тестов рассматриваются не только входные условия, но и
пространство результатов, т.е. «выходные» классы эквивалентности.
Одним из недостатков этих двух методов является то, что они не исследуют
комбинации входных условий. Для решения этой задачи полезен метод функциональных
диаграмм причинно-следственных связей. Построение тестов этим методом
осуществляется в несколько этапов:
1. разбиение спецификаций на «рабочие» участки – факторизация,
104
2. определение причин и следствий. Причина есть отдельное входное условие или
класс эквивалентности входных условий. Следствие есть выходное условие или
преобразование системы,
3. анализируется
семантическое
содержание
спецификации,
которая
преобразуется в булевский граф, связывающий причины и следствия. Этот граф
и является функциональной диаграммой,
4. функциональная
диаграмма
снабжается
примечаниями,
задающими
ограничения и описывающими комбинации причин и/или следствий, которые
являются невозможными или обязательными из-за синтаксических или
внешних ограничений,
5. диаграмма преобразуется в таблицу решений. Каждый столбец таблицы
соответствует тесту,
6. столбцы таблицы решений преобразуются в тесты.
Метод функциональных диаграмм имеет свои недостатки, в частности он
неадекватно исследует граничные условия.
Существуют и другие методы построения тестов для функционального
тестирования. На практике рекомендуется использовать несколько методов.
Автоматизация процесса тестирования
Автоматизация тестирования позволяет сокращать длительность и трудоемкость
тестирования и достигать высокого качества программ при меньших суммарных затратах.
Обычно используют комбинацию ручного и автоматизированного тестирования.
Существует достаточно большое число программных продуктов (CASE-средств)
для автоматизации процесса тестирования.
Автоматизация тестирования затрагивает статическое и динамическое
тестирования. Объектами тестирования являются исходный код и исполняемая
инструментированная версия программы.
При статическом тестировании осуществляется проверка исходного кода
тестируемой программы, которая может включать в себя:
1. проверку соблюдения стандартов для конкретного языка программирования,
2. измерение различных метрик программ,
3. проверку различных таблиц перекрестных ссылок объектов программы,
4. проверку переносимости программы,
5. поиск потенциальных ошибок,
6. анализ потока управления с целью обнаружения «мертвого» и «тупикового»
кода,
7. анализ потоков данных.
Для проведения динамического тестирования создается инструментированная
версия тестируемой программы, которая должна сохранить все свойства тестируемой
программы во время выполнения и при этом позволять проследить результаты прогона
тестов, которые в общем случае могут включать в себя информацию о прохождении
потока управления по управляющему графу программы. Например при вызове каждой
функции регистрируются значения параметров и возвращаемое значение. Разработанный
набор тестов описывается на специализированном языке описания тестов. После этого
осуществляется прогон наборов тестов на инструментированной версии тестируемой
программы под управлением программы, фиксирующей результаты прохождения тестов и
генерирующей отчет о результатах тестирования.
Одно из наиболее развитых средств тестирования QA (новое название - Quality
Works) представляет собой интегрированную, многоплатформенную среду для разработки
автоматизированных тестов любого уровня, включая тесты регрессии для приложений с
графическим интерфейсом пользователя.
105
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять
процессом тестирования, отображать изменения в приложении и повторно использовать
тесты для более чем 25 различных платформ.
Основными компонентами QA являются:
- QA Partner - среда для разработки, компиляции и выполнения тестов;
- QA Planner - модуль для разработки планов тестирования и обработки
результатов. Для создания и выполнения тестов в процессе работы QA Planner
вызывается QA Partner;
- Agent - модуль, поддерживающий работу в сети.
Процесс тестирования состоит из следующих этапов:
- создание плана тестирования;
- связывание плана с тестами;
- пометка и выполнение тестов;
- получение отчетов о тестировании и управление результатами.
Создание тестового плана в QA Planner включает в себя составление схемы
тестовых требований и выделение уровней детализации. Для этого необходимо
определить все, что должно быть протестировано, подготовить функциональную
декомпозицию приложения, оценить, сколько тестов необходимо для каждой функции и
характеристики, определить, сколько из них будет реализовано в зависимости от
доступных ресурсов и времени. Эта информация используется для создания схемы
тестовых требований.
Для связывания плана с тестами необходимо создать управляющие предложения
(скрипты) на специальном языке 4Test и тесты, которые выполняют требования плана, и
связать компоненты любым способом. Для избежания перегруженности тестов
используют управление тестовыми данными.
При выполнении плана результаты записываются в формате, похожем на план. Все
результаты связаны с планом. Есть возможность просмотреть или скрыть общую
информацию о выполнении, слить файлы результатов, разметить неудавшиеся тесты,
сравнить результаты предыдущего выполнения тестов, выполнить или отменить отчет.
Одним из атрибутов теста является имя его разработчика, что позволяет при
необходимости выполнять тесты, созданные конкретным разработчиком.
Комплекс QA занимает на жестком диске не более 21МВ. Поддерживаемые
платформы: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX,
Solaris.
Документирование
ПО.
Обзор
отечественных
стандартов
по
составлению документации на ПО
ГОСТ – государственный стандарт. Несмотря на давность появления,
государственный стандарт был и остается единственным широкодоступным стадартом
документирования и разработки ПО для отечественных программистов. Следование
государственному стандарту дает возможность:
- унифицировать программные изделия для взаимного обмена и применения
ранее разработанных программ в новых разработках,
- снизить трудоемкость и повысить эффективность разработки, сопровождения и
эксплуатации программных продуктов,
- автоматизировать изготовление и хранение программной документации.
Единая система программной документации – ЕСПД – относится к стандартам
класса 19 и подразделяется на 10 групп:
0 – общие положения
1 – основополагающие стандарты
2 – правила выполнения документации разработки
3 – правила выполнения документации изготовления
106
4 – правила изготовления документации сопровождения
5 – правила выполнения эксплуатационной документации
6 – правила обращения программной документации
7,8 – резервные группы
9 – прочие стандарты
Обозначение стандарта включает в себя:
- Класс стандартов (ЕСПД – 19)
- Одна цифра (после точки), обозначающая код классификационной группы
стандартов
- Двузначное число, определяющее порядковый номер стандарта в группе
- Двузначное число (после тире), указывающее год регистрации стандарта.
В ГОСТ 19.102-77 «Стадии разработки» оговорены стадии разработки, каждая из
которых включает в себя некоторые этапы работ:
1.
Техническое задание: обосновывается необходимость разработки программы,
проводятся научно-исследовательские работы, разрабатывается и утверждается
техническое задание.
2.
Эскизный проект: разрабатывается и утверждается эскизный проект.
3.
Технический проект: разрабатывается и утверждается технический проект
4.
Рабочий проект: разрабатывается программа, программная документация,
проводятся испытания программы.
5.
Внедрение – подготовка и передача программы.
ГОСТ 19.101-77 «Виды программ и программных документов»
В данном стандарте оговаривается, что программы подразделяются на два вида:
компонент – программа, рассматривающаяся как единое целое, выполняющая
законченную функцию и применяемая самостоятельно или в составе комплекса, и
комплекс – программа состоящая из двух и более компонентов или комплексов.
Программные документы делятся на две группы документы, содержащие сведения,
необходимые для разработки программного продукта и его изготовления и документы,
используемые при эксплуатации программного продукта. Они приведены в таблицах 1, 2:
Таблица 1.
Вид программного документа
Содержание программного документа
Спецификация
Состав ПО и документации на него
Ведомость держателей подлинников Перечень предприятий, на которых хранятся
подлинники программных документов
Текст программы
Документированная запись программы с
необходимыми комментариями
Описание ПО
Сведения
о
логической
структуре
и
функционировании ПО
Программа и методика испытаний
Требования, подлежащие проверке при
испытании ПО, а также порядок и методы их
контроля
Техническое задание
Назначение и область применения программы,
технические,
технико-экономические
и
специальные требования, предъявляемые к
программе, необходимые стадии и сроки
разработки, виды испытаний
Пояснительная записка
Схема алгоритма, общее описание логики и
функционирования ПО, а также обоснование
принятых
технических
и
техникоэкономических решений
107
Таблица 2.
Вид эксплуатационного документа
Ведомость эксплуатационных документов
Содержание эксплуатационного документа
Перечень эксплуатационных документов
на программу
Формуляр
Основные характеристики программы,
комплектность и сведения об эксплуатации
программы
Описание применения
Сведения о назначении программы,
области
применения,
применяемых
методах,
классе
решаемых
задач,
ограничениях
для
применения,
минимальной конфигурации технических
средств
Руководство системного программиста
Сведения для проверки, обеспечения
функционирования
и
настройки
программы на условия конкретного
применения
Руководство программиста
Сведения для эксплуатации программы
Руководство оператора
Сведения для обеспечения процедуры
общения оператора с вычислительной
системой
в
процессе
выполнения
программы
Описание языка
Описание синтаксиса и семантики языка
Руководство
по
техническому Сведения по установке и обслуживанию
обслуживанию
программных средств
Эти документы разрабатываются на разных стадиях разработки программы. Не все
они являются обязательными для разных видов программ.
Таблица 3.
Стадии разработки
Вид документа
Спецификация
Ведомость держателей
подлинников
Текст программы
Техническое задание
Описание программы
Программа и методика
испытаний
Пояснительная
записка
Ведомость
эксплуатационных
документов
Формуляр
Описание применения
Техническо
е задание
Эскизный
проект
Технический
проект
-
-
-
⊗
-
•
°
•
-
-
-
•
°
°
°
°
°
-
°
°
-
-
-
-
-
°
°
-
-
-
°
°
°
°
Рабочий
проект
комп комп
онент лекс
108
Руководство
°
°
системного
программиста
Руководство
°
°
программиста
Руководство
°
°
оператора
Руководство
по
°
°
техническому
обслуживанию
Прочие документы
°
°
°
°
°
^ - необходимость составления ТЗ на компоненты, не предназначенные для
самостоятельного применения и комплексы, входящие в другие комплексы определяются
по согласованию с заказчиком;
• - документ обязательный;
⊗ - документ, обязательный для компонентов, имеющих самостоятельное
применение;
° - необходимость составления документа определяют на этапе разработки и
утверждения технического задания;
- - документ не составляют.
Стандарты ГОСТ 19.201, 19.202, 19.301-79, 19.401 – 19.404, 19.501-19.508 содержат
требования по содержанию и оформлению программных документов.
Коллективные методы разработки программного обеспечения
Любой промышленный программный продукт разрабатывается не одним
разработчиком, а коллективом, состоящим из десятков и сотен человек. Понятно, что при
этом правильное разделение труда между ними становится одной из самых важных задач.
Поэтому технология разработки программного обеспечения затрагивает способы
коллективной работы над программой.
Коллектив создателей ПО условно можно поделить на несколько категорий:
- разработчики или проектировщики – программисты, которые занимаются
постановкой задачи, принимают общие решения по функционированию
программы, решают глобальные вопросы, разрабатывают спецификации. Они
являются специалистами в предметной области и технологиях проектирования.
- кодировщики – программисты, которые занимаются реализацией отдельных
модулей программы. Хороший кодировщик должен обладать серьезными
знаниями в математике, численных методах, а также хорошо знать платформу,
на которой реализуется программа. На его совести лежит эффективность
функционирования отдельных частей программы, в то время как
проектировщики заботятся только об эффективности программы в целом.
- «тестеры» - люди, которые занимаются разработкой тестов и тестированием
ПО. Эти люди должны быть не только специалистами в программировании, но
и иметь очень хорошее представление о предметной области, для решения задач
которой предназначена программа.
- Инструментальщики – люди, занимающиеся созданием. Поддержкой и
обновлением специальных инструментов.
- Прочие работники – специалисты разных отраслей. Это могут быть художники,
технические писатели, композиторы, специалисты по эффектам, психологи и др.
Они не имеют непосредственного отношения к программированию, но их
работа необходима для создания законченного программного продукта.
Применяются два способа организации этих специалистов: классический, когда
специалисты каждого профиля объединены в отдельное структурное подразделение и
109
каждая разработка на соответствующих стадиях ЖЦ ведется соответствующим
подразделением.
Другой способ известен как метод главного программиста или метод
операционных бригад.
Если задача достаточно проста, то она решается одной операционной бригадой.
Если же она не может быть решена бригадой из 10 человек, то вся работа должна быть
разделена на относительно независимые части. Разработкой архитектуры системы в целом
и обеспечением концептуального единства занимается системный архитектор.
В состав операционной бригады могут входить:
- хирург или главный программист. Он лично проектирует программу, пишет
код, отлаживает его и составляет документацию. Он должен обладать большим
талантом, стажем работы свыше 10 лет и существенными знаниями в системных
и прикладных областях;
- второй пилот – второе «я» хирурга, может выполнять любую работу, но менее
опытен. Его главная задача – участвовать в проектировании, где он должен
думать, обсуждать и оценивать. Главный программист испытывает на нем свои
идеи, но не связан его предложениями. Часто второй пилот представляет
бригаду свою бригаду при обсуждении с другими группами. Он хорошо знает
весь код программы. Он исследует возможности альтернативных стратегий
проектирования. Он может заменить главного программиста в случае
необходимости. Он может заниматься написанием кода, но не несет
ответственности за какую-либо его часть;
- администратор. Главный программист – начальник, ему принадлежит
последнее слов в отношении персонала, прибавок к жалованию, помещений и
т.п., но на эти дела он должен тратить как можно меньше времени. Поэтому ему
необходим профессиональный администратор, заботой которого будут деньги,
люди. Помещения, машины, и который будет контактировать с
административным механизмом организации в целом. Обычно один
администратор может обслуживать две команды;
- редактор. Обязанности разработки документации лежат на главном
программисте. Чтобы она была максимально понятна он должен писать ее сам.
Это относится к описаниям, предназначенным как для внутреннего, так и для
внешнего использования. Задача редактора – взять созданный главным
программистом черновик, критически переработать, снабдить ссылками и
библиографией, проработать несколько версий и обеспечить публикацию;
- два секретаря – администратора и редактора;
- делопроизводитель – отвечает за регистрацию всех технических данных и несет
ответственность за все файлы предназначенные как для машины, так и для
чтения;
- инструментальщик, который занимался бы созданием, поддержкой и
обновлением специальных инструментов именно для этой команды;
- отладчик – готовит данные для ежедневной отладки и контрольные примеры
для системного тестирования;
- языковед – эксперт в области используемого языка программирования. Обычно
один языковед работает более чем с одной операционной бригадой.