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

Сущность – это абстракция, которая является элементом модели. Отношения связывают сущности. Диаграммы обеспечивают представление взаимосвязей сущностей. UML выделяет 4 типа сущностей:1 – структурные 2 – поведенческие 3 – группирующие 4 – аннотационные

Узагальнений модуль SSADM.

Разработчики SSADM для унификации ЖЦ ИС и процесса проектирования создали унифицированный модуль, определили его содержание, которое может быть адаптировано под каждый модуль.

Входы имеют 3 элемента: организационные полномочия, ссылки, входы.

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

Выходы: проектные решения; стандарты разработки; руководство; планы (проведения работ).

Организационные полномочия:

- договор на проведение исследований;- документы, определяющие объем и содержание работ;- исходные данные для выполнения работ.

Ссылки – это документация, разработанная в рамках SSADM или других системах, необходимая для проектирования модуля, содержащая вспомогательную информацию:

- бизнес-процессы ОУ;- бизнес-цели; - стратегия ОУ (в рамках ИС);- рабочие документы по планированию стратегии;- организационная структура ОУ;- портфель проекта ИС (план).

Цель предусматривает получение конкретного результата проектирования по каждому модулю.

Краткое изложение цели подразумевает разработку структуры и функций ИС.

Участники: разработчик проекта, менеджеры, КП; определение их функций.

Продукты: проектные решения, документы.

Методы проектирования: 13 методов.

Действия участников – описываются действия каждого участника по проектированию.

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

RUP як технологія.

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

Rational Unified Process - это итеративный процесс. Итерационный подход позволяет улучшать понимание проблемы через последовательные усовершенствования и с приращением конкретизировать эффективные решения. Он обеспечивает большую гибкость при учете новых требований и позволяет проекту заранее идентифицировать и разрешать риски.

Rational Unified Process - это управляемый процесс. Итерационный подход предполагает управление требованиями и управление изменениями.

Rational Unified Process поддерживает объектно-ориентированную технологию. Модели базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют Унифицированный язык моделирования (UML) как общую систему обозначений.

Rational Unified Process поддерживает компонентно-ориентированное программирование.

Rational Unified Process поддерживает объектно-ориентированную технологию. Модели базируются на понятиях объектов, классов и зависимостей между ними. Эти модели, подобно многим другим техническим искусственным объектам (артефактам), используют Унифицированный язык моделирования (UML) как общую систему обозначений.

Rational Unified Process поддерживает компонентно-ориентированное программирование.

Модель SSADM.

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

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

В состав структурной модели входят следующие модули:

модуль анализа реализуемости (АР);модуль анализа требований (АТ);модуль спецификации (каталога) требований (СТ);модуль спецификации логической структуры (СЛС);модуль физического проектирования (ФП).

Бізнес-моделювання в UML (діаграма прецедентов).

Для моделирования разрабатываются модель деловых прецедентов (бизнес-прецедентов) и модель деловых объектов. Модель бизнес-прецедентов (business case model) представляет собой модель прецедентов на верхнем уровне абстракции. Бизнес-прецедент определяет возможности системы. Диаграмма бизнес-прецедентов концентрируется на архитектуре бизнес-процессов.

В дополнение к этим моделям разрабатываются следующие артефакты:

• Дополнительная бизнес-спецификация Глоссарий Отображение схемы организации. Разработка приложения.

Модель деловых прецедентов - модель, которая описывает процессы деловой сферы и их взаимодействие с внешней средой.

Цель модели - описать деловую сферу заказчика и партнера.

Модель описывает деловую сферу в терминах бизнес-субъектов и бизнес-прецедентов.

Вибір технологій, методів, моделей проектування ІС (SSADM і ДСТ-34).

Методическое обеспечение технологии SSADM образовано тринадцатью методиками проектирования АС, тесно увязанными между собой и с элементами ТТП. Их краткая характеристика приведена в таблице 1.

Таблица 1. Краткая характеристика методик проектирования

№ п/п	Название методики	Характер основных проектных документов	Номера стадий, на кото­рых при­меняется методика
1	Определение требований к АС	Табличная форма	1,2,3,4
2	Моделирование информационных потоков	Схема, табличная форма	1,2
3	Логическое моделирование данных	Схема, табличная форма	1,3,4
4	Определение функций и за­дач	Схема, табличная форма	1,3
5	Динамическое моделирова­ние данных	Схема, табличная форма	3,4
6	Реляционный анализ данных	Табличная форма	1,3,4
7	Выбор вариантов автоматизации	Поясн. записка, схема	1
8	Разработка демонстрационного прототипа	Видеограмма, схема	3
9	Выбор вариантов технической реализации	Поясн.записка, таблич­ная форма	4
10	Проектирование диалогового взаимодействия	Табличная форма, схема	3,4
11	Логическое проектирование процедур обработки данных	Табличная форма. схема	4
12	Физическое проектирование баз данных	Табличная форма. схема	5
13	Физическое проектирование процедур обработки данных	Табличная форма, схема	5

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

Опис процесів/прецеденти.

Прецедент – это описание происходящих в предметной области. Он позволяет формировать требования к ИС.

Прецедент – это документ, описывающий последовательность действий исполнителя, который приводит к конечному результату (покупка товара).

Прецеденты бывают:

- верхнего уровня или бизнес – прецеденты.- развернутые прецеденты.

Прецеденты высокого уровня описывают наиболее важные глобальные процессы объекта (2-3 предложения).

Развернутые – подробное описание, включает типичный ход событий.

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

На практике прецеденты представляются с различной степенью детализации.

Для формирования прецедентов необходимо иметь описание:

1. название 2 исполнители 3 тип прецедента

Выделяют 3 типа прецедентов:

1 Основные, описывающие общие процессы (покупка товара). 2 Вторичные, описывают уточняющие редкие процессы (запрос на ассортимент товара). 3 Дополнительные, описывающие процессы не реализуемые в системе.

Этапи та стадії SSADM.

SSADM регламентирует и поддерживает все этапы ЖЦ ИС.

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

Структура ЖЦ ИС в SSADM реализуется каскадной моделью.

В SSADM выделяют 5 этапов проектирования и 7 стадий.

К – концепция ТЭО – технико-экономическое обоснование КП – каталог пользователей КТ – каталог требований

КЗ – каталог задач

0 оценивание реализуемости 1 – предпроектное обследование 2 – выбор вариантов автоматизации 3 – ТЗ 4 – выбор вариантов технической реализации 5 – логический проект 6 – физический проект

Ітераційний процес RUP.

Rational Unified Process — это:

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

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

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

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

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

Методическое обеспечение технологии SSADM образовано тринадцатью методиками проектирования АС, тесно увязанными между собой и с элементами ТТП. Их краткая характеристика приведена в таблице 1.

Таблица 1. Краткая характеристика методик проектирования

№ п/п	Название методики	Характер основных проектных документов	Номера стадий, на кото­рых при­меняется методика
1	Определение требований к АС	Табличная форма	1,2,3,4
2	Моделирование информационных потоков	Схема, табличная форма	1,2
3	Логическое моделирование данных	Схема, табличная форма	1,3,4
4	Определение функций и за­дач	Схема, табличная форма	1,3
5	Динамическое моделирова­ние данных	Схема, табличная форма	3,4
6	Реляционный анализ данных	Табличная форма	1,3,4
7	Выбор вариантов автоматизации	Поясн. записка, схема	1
8	Разработка демонстрационного прототипа	Видеограмма, схема	3
9	Выбор вариантов технической реализации	Поясн.записка, таблич­ная форма	4
10	Проектирование диалогового взаимодействия	Табличная форма, схема	3,4
11	Логическое проектирование процедур обработки данных	Табличная форма. схема	4
12	Физическое проектирование баз данных	Табличная форма. схема	5
13	Физическое проектирование процедур обработки данных	Табличная форма, схема	5

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

Моделювання класів UML.

В отличие от концептуальной модели ДК описывает программные сущности.

ДК иллюстрирует спецификацию программных классов и интерфейсов в приложении.

На ДК выносится:1.Классы, ассоциации и атрибуты 2.Интерфейсы с операциями и константами 3.Методы (операции) 4.Информацияя о типах атрибутов 5.Способы навигации 6.Зависимости

Для построения диаграммы необходимо выполнить работы по след. этапам:

1.Проанализировать диагр. взаимодействий и определить все классы, задействованные в конкретном проектном решении

2.Перенесение на д-му классов атрибуты, соответствующие понятиям из концептуальной модели (КМ)

3.Добавить имена методов на основе д-мы взаимодействия

4.Добавить информацию о типах атрибутов и методах.

5. На д-ме классов ассоциации указываются стрелками (навигациями). Информация о навигации связана с видимостью объектов. (рис)

Моделі SSADM.

Моделювання станів в UML (діаграма станів) .

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

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

Изменение состояний счета изменяется при определенной границе вклада.

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

Диаграмма состояний представляет собой модель бизнес-правил. В течение некоторого времени бизнес-правила остаются неизменными. Прецеденты должны соответствовать бизнес-правилам.

Диаграмма состояний определяет способ реагирования объектов класса на события. Диаграмма определяет для каждого состояния объекта определенное действие (action), которое должно быть выполнено после получения сообщения или сигнала.

Изменение состояний объекта осуществляется по схеме событие / условие / действие.

Событие может быть защищено ограждающим условием.

Действие (action) - короткое вычисление, выполняемое при срабатывании перехода. Действие — это отклик объекта на обнаруженное событие.

Методи проектування ІС (SSADM).

Особенностью методологии SSADM является наличие развернутого метода обеспечения и в частности наличие методов проектирования и методик в отличии от других методологий.

Назначение методов проектирования состоит в структурной поддержке ЖЦ ИС, однако не все методы используются на всех стадиях проектирования (макропроектирование и микропроектирование). Использование методов дает возможность перейти от концептуально-логического к физическому проектированию, более детальному выбору применяемых инструментальных средств.

Методы:

1. Варианты бизнес-структуры (БП, бизнес-цели) – позволяет на ранних стадиях проектирования определить вариант бизнес-системы исходя из Ц, Тр (ТЭО). Применяется на стадиях АР и АТ.

2. Моделирование потоков данных – используется для представления существующих и желаемых данных в виде информационного пространства для обеспечения реализации функциональности. Стадии АР, АТ, СТ.

3. Проектирование диалога для реализации функций ИС исходя из класса задач. АР, АТ, СТ, СЛС.

4. Объекто-событийное моделирование предметной области (организационная и функциональная структура) позволяет определить функции каждого структурного подразделения функциональную структуру ИС. Применяется СТ, СЛС.

5. Метод определения функций – позволяет уточнить окончательный вариант функциональной структуры, применяют с объектно-событийными моделями.

6. Метод логического моделирования данных – дает возможность разработать ЛМД, установить взаимосвязи данных при реализации функциональных задач с целью сокращения оперативной памяти, минимизацией времени запросов, снизить нагрузку на каналы связи. Стадии АР, АТ, СТ.

7. Проектирование логических процессов обработки данных и запросов – позволяет оптимизировать структуру КСА за счет оптимизации режимов обработки данных и запросов. СЛС.

8. Спецификация прототипирования – позволяет разрабатывать прототипы системы, оценивать возможность применения ТПР (типовых проектых решений).

9. Реляционный анализ данных – оптимизация документооборота, исключить дублирование данных. АТ, СТ.

10. Определение требований – определение требований к ИС (функциональные, нефункц).

11. Варианты технической системы – дает возможность перейти к детальному проектированию компонентов ИС. АР, СЛС. Позволяет разработать КТ, КП,КЗ.

12. Проектирование физических данных – разработка физической модели данных в соответствии с физической базой данных.

13. Спецификация физических процессов – обеспечивает получение докум. по сопровождению физ.процессов.

Рассмотренные методы взаимосвязаны между собой в рамках реализации ЖЦ ИС.

Побудова концептуальної моделі в UML.

Разраб-ка КМ осущ по неск циклам. Напр, в первонач цикле реализ-ции прец-та «Покупка тов» рассматр только прцедура «Оплата только наличн» на следующ стадиях цикла должна быть получена рассшир КМ

Назначен КМ сост в описан основных, с точки зрен моделирующего, понятий (объектов) ПрО

Идентификация понятий – составная часть исслед-я ПрО

КМ на UML опис статич структурн диаграммами

Важным св-вом КМ явл-ся представление понятий ПрО, а не артефактов прогр компонентов

Процесс создан КМ завис от описаний предметов, док-ов, позволяющий идентифицир объекты

Можно осущ проц разраб-ки КМ параллельно с создан прец-тов

КМ может отображ: 1)понятия; 2)ассоциации меду понятиями (связи); 3)атрибуты объекта

КМ не только позвол осущ декомпозицию ПрОна различн мн-во объектов, но и опред терминологию и словарь терминов ПрО

Описан ПрО в рамках КМ отлич от описаний прогр эл-тов, поэтому в КМ ПрО не использ-ся: 1)артефакты прогр средств (окна, БД), но если КМ не явл-ся прогр сис; 2)описан методов.