***

   1. Каноническое проектирование информационных систем
В основе процесса проектирования информационных лежит методика канонического проектирования систем. Данная методика описана в стандарте ГОСТ 34.601-90.
Согласно данному стандарту каноническое проектирование предусматривает  выполнение проектных работ по определенному алгоритму.  Допускается выполнять сразу несколько шагов проектирования, объединяя их в одни этап.
В общем виде этапы канонического проектирования можно свести  в таблицу 1.1.
Таблица 1.1. Каноническое проектирование.
Номер этапа Краткое описание
1 Формирование требований к системе
2 Разработка концепции системы
3 Техническое задание на разработку
4 Составление эскизного проекта
5 Разработка технического проекта
6 Составление рабочей документации
7 Ввод системы в эксплуатацию
8 Поддержка системы, послы сдачи ее заказчику

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

2. Модели жизненного цикла информационных систем
Существование любой информационной системы проходит через три основных этапа:
проектирование;
эксплуатацию;
износ – старение;
демонтаж. 
Совокупность этих факторов образует жизненный цикл системы (ЖЦ). ЖЦ  информационных систем в настоящее время определяется стандартом ISO/IEC 12207.
Данный стандарт определяет  определенный набор субъектов участников, каждой стадии ЖЦ. В стандарте модель ЖЦ в общем виде разделяется на следующие этапы – стадии:
стадия разработки;
стадия эксплуатации;
демонтаж системы.
ЖЦ системы включает ряд процессов протекающих во времени. В стандарте ISO 12207  выделены следующие процессы:
заказ системы;
поставка системы потребителю;
разработка системы;   
процесс эксплуатации;
сопровождение системы.
Кроме основных процессов жизненного цикла информационной системы стандарт ISO 12207 определяет так же набор вспомогательных процессов:
процесс документирования;
процесс управления конфигурацией;
процесс обеспечения качества;
процесс верификации;
процесс аттестации;
процесс совместного анализа;
процесс аудита;
процесс решения проблем.

Стандарт ISO 15504
Стандарт ISO 15504  содержит методику оценки аттестации процессов жизненного цикла программных средств. Регламентирует процесс реализации  стадий жизненного цикла систем, определенных в стандарте ISO 12207.
В стандарте ISO 15504 изменен состав организационных процессов, особое внимание уделяется детализации работ в стандартизированных процессах жизненного цикла создаваемого программного обеспечения для информационных систем.
В стандарте ISO 15504 предлагается методика обеспечения качества программного обеспечения разрабатываемого для «сложных» и «больших» информационных систем. Данная методика имеет условное обозначение  – СММ (Capability Maturity Model) — система и модель оценки зрелости комплекса, применяемых технологических процессов.

3. Rational Unified Process. Методология и технология

IBM Rational Unified Process — это:
- новый подход к разработке ПС, основанный на использовании лучших практических методов, успешно зарекомендовавших себя во многих проектах разработки ПС по всему миру;
- четко определенный процесс (технологическая процедура), описывающий структуру жизненного цикла проекта, роли и ответственности отдельных исполнителей, выполняемые ими задачи и используемые в процессе разработки модели, отчеты и т.д.;
- готовый продукт, предоставляемый в виде веб-сайта, содержащего все необходимые модели и документы с описанием процесса.
Подход к разработке

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

IBM Rational Unified Process — это итерационный процесс. Создавать современные сложные программные системы последовательно, т.е. сначала определять все проблемы, затем принимать все проектные решения, формировать ПС и, наконец, проверять изделие, невозможно. Такой подход (называемый каскадным подходом или «водопадом») в современной информационной индустрии не оправдывает себя, поскольку его использование часто приводит к непредсказуемому увеличению проектной стоимости и сроков выпуска ПС. Эффективной альтернативой «водопаду» служит итерационный процесс разработки ПС.

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

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

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

IBM Rational Unified Process — процесс, управляемый на основе прецедентов. Это означает, что в качестве метода описания функциональных требований к системе, а также в качестве естественной единицы для дальнейшего планирования и оценки выполнения работ используются сценарии использования. Сценарии использования позволяют легко выявлять реальные потребности будущих пользователей системы и отслеживать полноту описания этих требований. Они гарантируют выполнения требований заказчика к ПС. Кроме того, использование завершенных сценариев в качестве единицы измерения прогресса помогает избежать неадекватной оценки степени выполнения проекта исполнителем.

IBM Rational Unified Process предполагает разработку, реализацию и тестирование архитектуры на самых ранних стадиях выполнения проекта. Такой подход позволяет устранять самые опасные риски, связанные с архитектурой, на ранних стадиях разработки. Благодаря ему удается избежать существенных переработок в последний момент, если вдруг выяснится, что выбранное решение не обеспечивает, к примеру, выполнение требований к производительности системы.

4. CASE технологии и их особенности
Для автоматизации решения выделенных проблем и учета особенностей информационных систем в процессе из анализа и синтеза используют комплекс программно – технологических средств. Такое комплекс получил название CASE средств (Computer Aided Software Engineering). С учетом выше изложенного можно говорить об определенной технологии создания информационных систем и программного обеспечения для таких систем.
CASE — технология представляет собой методологию проектирования,  а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область системы, анализировать эту модель на всех этапах разработки и сопровождения системы и разрабатывать программное обеспечение в соответствии с информационными потребностями пользователей.
Отмечается, что для успешного внедрения CASE  средств организация – разработчик должна обладать следующими особенностями:
понимание ограниченности существующих возможностей и способность принять новую технологию;
готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;
четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.
Технология CASE проектирования базируется на использовании следующих трех составляющих:
методологии;
нотации;
инструментальных средств проектирования.

5. Технология DATARUN и ее особенности

Методология DATARUN опирается на две модели или на два представления:
модель организации;
модель ИС.
Методология DATARUN базируется на системном подходе к описанию деятельности организации. Построение моделей начинается с описания процессов, из которых затем извлекаются первичные данные (стабильное подмножество данных, которые организация должна использовать для своей деятельности). Первичные данные описывают продукты или услуги организации, выполняемые операции (транзакции) и потребляемые ресурсы. К первичным относятся данные, которые описывают внешние и внутренние сущности, такие как служащие, клиенты или агентства, а также данные, полученные в результате принятия решений, как например, графики работ, цены на продукты.
Основной принцип DATARUN заключается в том, что первичные данные, если они должным образом организованы в модель данных, становятся основой для проектирования архитектуры ИС. Архитектура ИС будет более стабильной, если она основана на первичных данных, тесно связанных с основными деловыми операциями, определяющими природу бизнеса, а не на традиционной функциональной модели.
Подход DATARUN преследует две цели:
определить стабильную структуру, на основе которой будет строиться ИС. Такой структурой является модель данных, полученная из первичных данных, представляющих фундаментальные процессы организации;
спроектировать ИС на основании модели данных.

6. Технология RAD и ее особенности
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
  короткий, но тщательно проработанный производственный график (от    
  до 6 мес.);
повторяющийся цикл, при котором разработчики, по мере того, как
приложение начинает обретать форму, запрашивают и реализуют в    продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE — средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза анализа и планирования требований;
фаза проектирования;
фаза построения;
фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов—разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов—разработчиков. CASE — средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD — проектов время  порядка 60 — 90 дней. С использованием CASE — средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
общая информационная модель системы;
  функциональные модели системы в целом и подсистем, реализуемых   
  отдельными командами разработчиков;
точно определенные с помощью CASE—средства интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE — средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE — средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
определяется необходимость распределения данных;
производится анализ использования данных;
производится физическое проектирование базы данных;
определяются требования к аппаратным ресурсам;
определяются способы увеличения производительности;
завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.

1. Типы современных методологий проектирования.
Методологические проблемы:
размытость критериев выбора подходящей задачи;
слабая проработанность теоретических аспектов процессов извлечения знаний (философские, лингвистические, психологические, педагогические, дидактические и другие аспекты), а также отсутствие обоснованной классификации методов извлечения знаний и разброс терминологии;
отсутствие единого теоретического базиса процедуры структурирования знаний;
жесткость моделей представления знаний, заставляющая разработчиков обеднять и урезать реальные знания экспертов;
несовершенство математического базиса моделей представления знаний (дескриптивный, а не конструктивный характер большинства имеющихся математических моделей);
эмпиричность процедуры выбора программного инструментария и процесса тестирования (отсутствие критериев, разрозненные классификации).
Технологические проблемы:
отсутствие концептуальной целостности и согласованности между отдельными приемами и методами инженерии знаний;
недостаток или отсутствие квалифицированных специалистов в области инженерии знаний;
отсутствие технико-экономических показателей оценки эффективности ЭС;
несмотря на обилие методов извлечения знаний, практическая недоступность методических материалов по практике проведения сеансов извлечения знаний;
явная неполнота и недостаточность имеющихся методов структурирования знаний, отсутствие классификаций и рекомендаций по выбору подходящего метода;
несмотря на обилие программных средств, недостаток систем поддержки разработки в их узкой направленности (зависимость от платформы, языка реализации, ограничений предметной области), разрыв между ЯПЗ и языками, встроенными в "оболочки" ЭС;
жесткость программных средств, их низкая адаптивность, отсутствие индивидуальной настройки на пользователя и предметную область;
слабые графические возможности программных средств, недостаточный учет когнитивных и эргономических факторов;
2. Методология SADT и ее особенности
  Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой—либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
графическое представление блочного моделирования. Графика блоков и дуг SADT — диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
строгость и точность.


3. Методология DFD и  ее особенности
 Методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ.

4. Методология IDEF3 и ее особенности
Методология IDEF3 позволяет проследить структуру определенной деятельности необходимой для преобразования материального или информационного объекта. Такую последовательность действий можно рассматривать как последовательность процессов по преобразованию объектов в процессе технологической деятельности. В результате создается диаграмма потока деятельности WFD (Work Flow Diagramm). 
Основными компонентами такой диаграммы являются действия и логические операторы,  которые показывают точки разветвления последовательности действий.
Действие на диаграмме изображается в виде квадрата  с нумерацией в нижнем левом углу. Действия соединяются стрелками, которые показывают последовательность их выполнения.
Стрелки представляют собой определенный тип связи. Каждая связь имеет свое условное обозначение.
На диаграммах IDEF3 принято выделять следующие типы связей:
связь предшествования. Обозначается сплошной направленной  стрелкой. То действие, на которое указывает стрелка, выполняется только после завершения предыдущего действия;
связь отношения. Изображается пунктирной направленной стрелкой. То
действие, на которое указывает стрелка, может начаться или закончится раньше, чем предыдущее действие;
связь потоков объектов. Изображается сплошной двойной направленной
стрелкой. Означает, что предыдущее действие формирует объект, который используется вторым действием, либо последующими действиями. Условные обозначения элементов приведены в таблице 4.3
Таблица 4.3.  Элементы модели IDEF3
Элемент Нотация
Выполняемое действие

Связь предшествования

Связь отношения

Связь потоков объектов


Для показа точек разветвления в потоке действий используются логические операторы. В методологии IDEF3 определено три типа логических операторов: «И», «ИЛИ», «Исключающее ИЛИ».  Эти операторы имеют условные обозначения,  показанные в таблице 4.4.





\Таблица 4.4. Логические операторы.
Логический оператор. Условное обозначение
«И» &
«ИЛИ» O
«Исключающее ИЛИ» X
Логические операторы на диаграмме образуют перекрестки.  Различают два типа перекрестков:
перекрестки схождения;
перекрестки расхождения.
1. Методология IDEFX1 и ее особенности.
Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия — методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X—диаграммы используются рядом распространенных CASE — средств (в частности, ERwin, Design/IDEF).
Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности.
 
Рис .7.18. Сущности.
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности — потомка, которое может существовать для каждого экземпляра сущности — родителя). В IDEF1X могут быть выражены следующие мощности связей:
каждый экземпляр сущности — родителя может иметь ноль, один или более связанных с ним экземпляров сущности—потомка;
каждый экземпляр сущности — родителя должен иметь не менее одного связанного с ним экземпляра сущности — потомка;
каждый экземпляр сущности — родителя должен иметь не более одного связанного с ним экземпляра сущности — потомка;
каждый экземпляр сущности — родителя связан с некоторым фиксированным числом экземпляров сущности—потомка.
Если экземпляр сущности—потомка однозначно определяется своей связью с сущностью — родителем, то связь называется идентифицирующей, в противном случае — неидентифицирующей.
Связь изображается линией, проводимой между сущностью—родителем и сущностью—потомком с точкой на конце линии у сущности—потомка. Мощность связи обозначается как показано на рис.7.19. (мощность по умолчанию — N).
 
Рис. 7.19. Мощность связи.
Идентифицирующая связь между сущностью — родителем и сущностью—потомком изображается сплошной линией. Сущность—потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность — родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
 Рис. 7.20. Атрибуты и первичные ключи.
Сущности могут иметь также внешние ключи, которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.
 
Рис. 7.21. Идентифицирующая связь.
Пунктирная линия изображает неидентифицирующую связь (рисунок 7.22). Сущность—потомок в неидентифицирующей связи будет независимой от идентификатора, если она не является также сущностью—потомком в какой—либо идентифицирующей связи.
 

2. Классификация моделей UML

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




3. Диаграмма UML классов
   Данная диаграмма представляет собой объектную модель предметной области. Строится с помощью графических элементов расположенных на странице UML Static Structure. Основные элементы

 
Класс предметной области.
  Наследование (генерализация).
  Ассоциация (объединение ).
  Зависимость.
           Настройка графического представления класса выполняется с помощью его контекстного меню.  Необходимо обриться к свойствам класса с помощью команды Properties.  С помощью свойства  Class  задают название классу – параметр   Name . Если класс абстрактный нужно задать параметр —  isAbstract (Название класса становится курсивным). С помощью свойства    Attributes выполняется задание атрибутов. Атрибут имеет параметры:
       Attribute – название
       Type – тип хранимого значения
       Visibility – доступ к атрибуту (public, protected, private)
Для указания статического атрибута следует задать параметр:
         Properties — Owner Scope (classifier— статический, instance— обычный). Статические атрибуты выделяются подчеркиванием.
Свойство  Operations используется для задания операций класса. Параметры операции
         Operation — наименование
         Return Type – тип возвращаемого результата
         Visibility – доступ к операции
          Scope – статическая операция или нет. Для задания параметров операции следует выбрать кнопку   Properties и выбрать ее свойство  Parameters. При вводе параметра следует задать:
           Parameter — название
           Type – тип параметра
           Kind – назначение параметра (in – для ввода данных, out— для
           вывода данных,      
           inout – для ввода и вывода.)
           Dafault Value – значение по умолчанию.

4. Особенности диаграмм классов в UML
Требуемые графические элементы расположены на странице UML Activity. Основными элементами являются:
 
Расходящаяся последовательность деятельности.
 
Сходящаяся последовательность.
 
Блок – условие.
 
Деятельность.
 
Начало последовательности действий.
 
Завершение последовательности действий.

Для изменения названия деятельности нужно использовать команду контекстного меню:
Properties — Name

5. UML диаграмма прецедентов
Построение диаграммы выполняется с помощью  набора элементов расположенных на странице UML Use Case.

 
Прецедент
 
Инициатор действия
 
Группировка прецедентов

5. UML диаграммы поведения
Диаграммы поведения:
Деятельности
Состояний
Вариантов использования
6. UML диаграммы развертывания и компонентов.

Диаграмм строится с помощью вкладки UML Deployment.  Основные графические элементы

  Модуль программного кода.
  Узел вычислительной системы, на котором расположен процессор.
  Интерфейс.
 
Пакет.
 
Зависимость.

Для изменения названия модуля, пакета, интерфейса, узла используется контекстное меню и параметр  Properties – Name.
Любая UML диаграмма может  быть снабжена комментариями
   
 
Рис. 8.1. Пример комментария.

Настройка комментария выполнятся командой контекстного меню Properties. С помощью свойства    Name задают идентификатор, а с помощью Documentation вводят текст комментария.