Всегда ли следует использовать sadt для функционального моделирования.

Дзюба Д.В., Крылов С.С.

 

 

АВТОМАТИЗИРОВАННОЕ МОДЕЛИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ

 

Учебное пособие

 

 

Москва, 2002

 

 

© Д.В. Дзюба, С.С. Крылов

Введение

 

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

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

Наибольший практический интерес представляют индустриально организованные ПС, которые характеризуются:

1. Длительным временем эксплуатации;

2. Сравнительно широким кругом пользователей, результат работы которых зависит от нормального функционирования программных средств;

3. Коммерческой ценностью.

Примерами таких систем могут служить системы контроля за реальными процессами (грузоперевозки, химический синтез), информационно-поисковые системы, системы программирования, офисные пакеты.

Согласно [2] разработка индивидуальных («малых») проектов отличается от индустриально организованных («больших») следующими признаками:

 

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

 

В настоящее время наблюдается тенденция «глобализации» программных проектов, то есть увеличение среди разрабатываемых и эксплуатируемых программ количества сложных интегрированных программных систем, компоненты которых распределены между рабочими местами. Далее рассматриваются, главным образом, индустриально организованные ПС.

Индустриально организованным ПС присуща сложность, определяемая шестью основными причинами [1],[3]

1. Сложностью постановки решаемой задачи (неформальные, неявные, противоречивые требования);

2. Сложностью поведения системы, связанной со случайным характером внешних воздействий, большим числом состояний системы и связей между ними;

3. Сложностью описания поведения отдельных подсистем;

4. Сложностью управления процессом коллективной разработки (ПС не создаются одиночками, следовательно, возникают проблемы связи между разработчиками, синхронизации их действий, обеспечения целостности и непротиворечивости проекта);

5. Сложностью обеспечения открытости ПС (ПС для этого должна соответствовать различным стандартам).

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

 

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

Следуя Г. Бучу [4] выделим два вида декомпозиции:

 

1. Алгоритмическая. Главное - порядок событий, функциональность. Исторически более ранний вид декомпозиции, соответствовал возможностям и задачам ранних ЭВМ, по сути более близок архитектуре фон-Неймановских машин.

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

 

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

 

 

Методология SADT

 

Первоочередной проблемой, возникающей перед разработчиками при проектировании ПС, является анализ предметной области, выявление целей и ключевых закономерностей ее функционирования. Качество выполнения этого этапа во многом определяет успех или неуспех проекта в целом, поскольку ошибки, допускаемые на ранних стадиях разработки системы обходятся особенно дорого. Результаты анализа желательно фиксировать таким образом, чтобы соблюдался баланс между степенью формализации предметной области и наглядностью представления. Для этой цели удобно использовать некоторую стандартизованную графическую нотацию, разумеется, в сочетании с текстовыми комментариями. На практике в качестве средства предварительного описания предметной области более двадцати лет широко и успешно применяется методология SADT - Structured Analysis and Design Technique (Технология структурного анализа и проектирования), включающая наглядные графические средства и подход к описанию систем. Часть этой методологии, связанная с функциональным моделированием, известна под названием IDEF0 – сокращение от ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства) DEFinition. Предварительное описание предметной области часто основывается на функциональном SADT моделировании с помощью SADT- диаграмм. Почему для предварительного описания часто используется функциональное, а не объектное моделирование? Это обусловлено несколькими причинами:

 

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

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

3. При предварительном анализе функции и взаимосвязи между ними часто легче выявить чем классы и их взаимоотношения.

4. Выявленные функции и потоки данных между ними впоследствии удобно использовать как основу объектной декомпозиции.

5. Графический язык SADT содержит всего один примитив для представления действия (блок) и один примитив (дугу) для выражения связи между блоками.

 

Влиятельным фактором распространения SADT являются некоторые корпоративные и государственные стандарты ряда стран, в первую очередь CША, предписывающие использование этой методологии в определенных категориях проектов.

 

Модель

 

SADT-модель должна давать полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, следует из формального определения модели в SADT [3]: М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с требуемой точностью. Множество возможных вопросов определяется выбранной при моделировании точкой зрения на систему. Например, модель завода, построенная с точки зрения главного бухгалтера, ориентированная на финансовые потоки и документооборот, будет существенно отличаться от модели того же завода, созданной с точки зрения начальника производства и совсем не будет похожа на модель функционирования завода с точки зрения ночного сторожа (например, он может представлять завод как огороженное пространство, изобилующее материальными ценностями и их потенциальными расхитителями). Заметим, что во многих случаях SADT-модели реальных предметных областей имеют самостоятельную практическую (в том числе коммерческую) ценность, поскольку они могут быть использованы для реинжиниринга или, скажем, обучения персонала.

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

В SADT-модель входят также текстовые описания и комментарии.

 

 

Диаграмма

 

На SADT-диаграмме располагаются блоки и ориентированные дуги. Диаграмма составляется на стандартном бланке, в котором предусмотрены поля для названия, автора, наименования проекта, даты составления или изменения и другой стандартной информации.

 

 

Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. Методология SADT рекомендует, чтобы на диаграмме находилось не менее трех и не более шести блоков. Исключением является диаграмма самого высокого уровня, которая всегда содержит один блок, выражающий обобщенную функцию системы. Правило «от трех до шести» было получено эмпирическим путем. Считается, что диаграмма из двух блоков слишком тривиальна, а из семи и более – сложна для понимания. Выбор числа семь в качестве границы косвенно подкрепляется некоторыми рекомендациями из области организации управления, согласно которым наличие у начальника более шести заместителей исключает эффективную координацию их действий. Если на диаграмме получается более шести блоков, то следует либо укрупнить некоторые из них, либо пересмотреть структуру дерева диаграмм.

Блоки изображаются прямоугольниками. Название представляемой блоком функции пишется внутри блока обычно в неопределенной глагольной форме («выписать ордер», «проверить и утвердить баланс», «загрузить управляющую программу», «загерметизировать швы» и т.д.). Дуги располагаются и нумеруются на диаграмме вдоль диагонали из левого верхнего угла в правый нижний. Меньший номер соответствует более высокой степени доминирования блока. Доминирование блока может быть обусловлено тем, что его функция выполняется ближе к началу последовательного процесса или важностью его функции. Например, доминирующим может быть блок, содержащий функции управления выполнением работы. Порядковый номер блока пишется в углу прямоугольника и используется для ссылки на декомпозирующие его диаграммы.

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

 

 

 

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

 

 

 

 

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

 

Рисунок.

 

 

При декомпозиции блока 2 диаграммы A1 дуги A,B,C,D,E станут внешними для детализирующей диаграммы A12, например, следующим образом:

 

 

 

Для идентификации внешних дуг в SADT принята система ICOM – обозначений. ICOM – сокращение от Input (вход), Control (управление), Output (выход), Mechanism (механизм). ICOM-нумерация внешних дуг выполняется следующим образом: входы кодируются литерой I и номером соответствующей дуги для родительского блока на декомпозируемой диаграмме. Аналогично для дуг управления (C), выходов(O) и механизмов(M). Нумерация дуг ведется сверху вниз для входов и выходов и слева направо для управляющих дуг и механизмов.

 

 

 

Заметим, что на диаграммах низкого уровня абстракции (и, соответственно, высокой степени детализации) может возникнуть потребность в использование большого числа внешних дуг, механическое перенесение которых на другие диаграммы нежелательно. В этом случае используются так называемые туннельные дуги (со скобочками), реализующие исключение из сформулированного выше правила декомпозиции диаграмм. Аналогично, некоторые дуги на родительских диаграммах иногда нежелательно переносить на дочерние, например, в тех случаях, когда дуга с родительской диаграммы связана со всеми блоками декомпозирующей диаграммы, но изображение всех этих связей нежелательно по соображениям наглядности. Туннельные дуги являются локальными по отношению к диаграмме и по выражению [3] позволяют “спрятать” некоторые подробности и показать необходимые детали.

Пример:

 

 

Дуга А не будет видна на родительской диаграмме; дуга B не будет видна на диаграмме, декомпозирующей блок 2; дуга C не будет видна ни на родительской, ни на декомпозирующей блок 3 диаграмме.

 

Дуги SADT позволяют отображать на диаграммах не только последовательное и параллельное выполнение функций, но и обратную связь между блоками системы. В SADT различается два вида обратной связи – по потоку данных (выход – вход) и по управлению (выход – управление). Обратная связь по управлению свидетельствует о взаимном влиянии функций, тогда как обратная связь по потоку данных указывают на повторное использование и итерацию [3].

 

Последовательное и параллельное выполнение функций.

 

 

Примеры обратной связи. А- обратная связь по управлению, B – по данным.

 

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

 

 

Атрибуты диаграммы

 

В верхней части бланка диаграммы размещаются следующие атрибуты (cм. рис):

· Автор

· Название проекта

· Дата создания

· Информация о рецензировании

· Статус диаграммы (рабочая версия/эскиз/рекомендовано/публикация)

 

В поле «контекст» схематически изображается положение декомпозируемого блока на родительской диаграмме, для корневой диаграммы там пишется слово TOP (верхний). В нижней части диаграммы указывается ее название, совпадающее с названием декомпозируемого блока, а также индекс диаграммы в дереве модели (обозначение узла) и номер диаграммы в модели (С-номер). С-номер формируется из первых трех букв имени автора и последовательного номера, соответствующего хронологическому порядку создания диаграмм. Если в папке модели появляется новая версия диаграммы то рядом с ее С-номером указывается С-номер предыдущей версии. Обозначение узла для контекстной (корневой) диаграммы формируется из полного или сокращенного названия проекта, символа «/», буквы А (сокращение от Activity – деятельность), символ «-» и 0 – индекс корневой диаграммы. Обозначение узла диаграммы, декомпозирующую контекстную такое же, только без знака «-». Все другие номера узлов образуются посредством добавления к номеру узла родительской диаграммы номера декомпозируемого блока. Ведущий ноль в обозначении узла обычно не пишется, поэтому вместо ххх/А01 пишется ххх/А1.

 

 

Создание SADT- модели

 

Создание функциональной модели системы представляет собой с одной стороны алгоритмизированную процедуру, а с другой стороны оставляет простор для творчества автора. Методология SADT содержит рекомендации, обобщающие опыт декомпозиции реальных систем, следование которым позволяет повысить эффективность и качество моделирования. В создании SADT-модели выделяется следующая последовательность этапов:

· Начало моделирования – на этом этапе производится сбор информации о моделируемой системе, выбор цели модели и точки зрения, разграничение системы и внешней среды, оформленные в виде диаграммы A0 и контекстной диаграммы А-0.

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

· Критический анализ построенной модели и, возможно, возврат к предыдущим этапам.

 

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

SADT содержит ценные указания по сбору информации (извлечению знаний) о системе. Они описаны в [3] и частично приводятся здесь в виде таблицы.

 

 

Стратегии сбора информации	Преимущества	Недостатки	Рекомендации по применению
Опрос экспертов (специалистов в данной предметной области).	Эксперты, как правило, наилучшие источники информации о системе. Им известны текущие нюансы и недокументированные аспекты системы.	Эксперты обычно не готовы формально или хотя бы систематически изложить свои знания в нужных пределах.	Необходимо тщательно планировать выбор собеседника и круг обсуждаемых вопросов.
Чтение документов.	Доступность документов, их статичность.	Могут неточно отражать реальную ситуацию (утрата актуальности с течением времени, наличие недокументированных нюансов системы).	Использовать для получения первоначального представления о системе и в ходе подготовки к опросу экспертов. Вести библиотеку документов.
Наблюдение за выполнением операций	Реальная информация “из первых рук”.	Не всегда возможно. При длительном наблюдении развивается привыкание к положению дел в системе, утрачивается объективность восприятия и стремление к поиску альтернативных решений.	При возможности, не только наблюдать но и участвовать.
Анкетирование	Позволяет опросить большие группы экспертов в сжатые сроки.	Практика показывает, что результаты анкетирований часто субъективны и недостаточно достоверны.	Использовать после достаточного знакомства с системой, что позволяет тщательно подготовить вопросы и избежать непонимания и раздражения респондентов. Рекомендуется использовать для выявления наиболее существенных проблем в системе.
Использование собственных знаний	Позволяет увидеть и использовать общие закономерности различных систем.	Применение ограничено. Для выявления специфики системы необходимы другие стратегии.	Необходим значительный личный опыт анализа систем.
Составление описания системы и обсуждение его с экспертами	Стимулирует поиск альтернативных решений.	Эксперты могут не быть готовы к восприятию новых возможностей.	Следует предварительно изучить предметную область и сформировать доброжелательно настроенную группу экспертов

 

Важной частью этапа начала моделирования является построение диаграммы A0, на которой изображаются основные функциональные блоки системы и связывающие их объекты. Для выявления основных объектов и функций при построением диаграммы A0 рекомендуется составить подробные перечни объектов и функций системы. Эти перечни вначале представляют собой просто список терминов, выявленных при сборе информации о системе. Не страшно, если список терминов будет избыточным, поскольку лучше его впоследствии сократить, чем изначально пропустить нечто существенное. Затем из списка терминов выбираются объекты, их перечень подвергается критическому анализу, на предмет исключения ненужных и объединения родственных объектов. Здесь также необходимо разграничить внутренние объекты системы, внешние, и интерфейсные, т.е. связывающие систему с внешним миром. Далее следует сделать предположения о роли выделенных объектов в системе (преобразуемые данные, управление, механизм) и перейти к работе со списком функций. Здесь требуется «увязать» функции с данными и сгруппировать функции в 3-6 блоков (подсистем) по признаку общности данных и назначения. Расположив эти блоки с учетом доминирования и соединив дугами, получим диаграмму A0. Контекстная диаграмма А-0 легко получается обобщением диаграммы А0. Заметим, что процесс построения диаграмм часто бывает итерационным и, возможно, потребуется их неоднократная корректировка.

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

Критический анализ модели должен дать ответ на вопрос – соответствует ли модель формальным требованиям SADT и в какой степени достигнута цель моделирования? Для ответа на этот вопрос следует сначала уточнить цель и точку зрения моделирования, изучить контекстную диаграмму и структуру модели в целом. Критический анализ отдельных диаграмм состоит в их синтаксическом и семантическом контроле. Распространенными синтаксическими ошибками являются:

· Неверная нумерация блоков или диаграмм, отсутствие названия у дуги

· Наличие блоков, не имеющих выхода или входа.

· Несовпадение дуг блока и внешних дуг его декомпозиции

 

Семантический контроль заключается в нахождении ответа, в частности, на следующие вопросы с учетом цели и точки зрения моделирования [3]:

 

· Не перекрываются ли функции различных блоков?

· Нет ли избыточной детализации блоков?

· Нет ли недостаточно детализированных блоков?

· Всегда ли названия блоков и дуг понятны и однозначны?

· Всегда ли одинаковые термины используются в одном и том же смысле?

· Нет ли на одной диаграмме блоков или дуг явно относящихся к далеким друг от друга уровням иерархии абстракций?

· Нет ли ненужных дуг, касающихся блока?

· Не является ли диаграмма слишком запутанной?

· Всегда ли обоснованно используются туннельные дуги?

· Не следует ли некоторые дуги поместить в туннель?

 

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

В приложении С приведен пример функциональной SADT-модели, построенной для решения учебной задачи – выполнения начального этапа проектирования CASE-системы.

 

 

Основы UML

 

UML (Unified Modeling Language) является языком моделирования сложных систем самых различных видов. В этом пособии мы будем рассматривать UML в непосредственной связи с объектно-ориентированной методологией проектирования программных систем.

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

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

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

 

	SADT	«Варианты Использования»
Топология модели	Дерево диаграмм с детализацией процессов.	Детализация процессов производится в рамках одной диаграммы с использованием отношений включения и расширения.
Типизация потоков	Чёткое разделение на вход, выход, управление и механизм.	Отсутствует.
Использование модели при разработке ПС	Моделирование предметной области.	Явное выделение автоматизируемых процессов и внешних по отношению к ПС сущностей.

 

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

Отметим, что UML это только язык, на котором разработчик или аналитик излагает свои знания о системе, и сам по себе не является гарантом успешного моделирования (так же как и SADT). Однако, использование специализированного языка во многом облегчает этот процесс, помогая свести ошибки моделирования к минимуму.

 

 

Диаграммы вариантов использования

 

Как уже отмечалось, для анализа работы системы, выявления основных процессов и связей между ними применяются Диаграммы Вариантов Использования. Эти диаграммы удобно использовать при общении с заказчиком или экспертом. Выявленные процессы служат основой для построения остальных диаграмм UML. Зная, какие процессы происходят в нашей системе, мы сможем определить, какие объекты участвуют в этих процессах, в каких состояниях пребывает система, из каких частей состоит и т.д.

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

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

2. Расширение. Один процесс может являться либо усложнённой версией другого процесса, либо просто содержать некоторые изменения или дополнения к этому процессу. Тогда говорят, что один процесс расширяет другой и соединяют их специальной связью «Расширение».

 

Эти связи очень похожи и не всегда сразу ясно, какую из них применить. Поэтому используют следующие правила:

- Если процесс содержит изменение в нормальной работе другого, то применяют связь «расширение».

- Если же вы просто хотите избежать повторов в диаграмме, то лучше применить связь «включение».

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

 

Действующее лицо

«Действующее лицо» представляет из себя некоторую внешнюю сущность по отношению к моделируемой системе. Эта сущность обязана некоторым образом взаимодействовать с системой. При этом каждому действующему лицу предписывается некоторая роль в данном взаимодействии. Таким образом, одна физическая сущность может быть представлена на диаграмме несколькими действующими лицами соответственно их ролям во взаимодействии с системой. Действующим лицом может являться как пользователь, так и некоторая внешняя система. На диаграмме оно изображается в виде «человечка», под которым подписывается его роль.

Вариант использования

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

Коммуникация

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

Связь Включение

Чтобы изобразить, что Вариант использования №1 включает в себя Вариант использования №2, на диаграмме их соединяют пунктирной стрелкой, идущей от №1 к №2, с ключевым словом <<include>>. Это означает что сервис предоставляемый вариантом использования №2 используется внутри сервиса варианта использования №1.

Связь Расширение

Чтобы изобразить, что Вариант использования №1 расширяет Вариант использования №2, на диаграмме их соединяют пунктирной стрелкой, идущей от №1 к №2, с ключевым словом «extend». Это означает что сервис, предоставляемый вариантом использования №1 является видоизменённым сервисом варианта использования №2, т.е. содержащим некоторые дополнения или изменения.

 

Границы системы

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

 

Диаграммы классов.

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

 

Базовым понятием в объектно-ориентированном программировании является, разумеется, понятие Объекта.

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

- множеством состояний;

- определённым поведением;

- механизмом однозначной идентификации.

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

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