«Проектирование ИС» 2011

Под ИС обычно понимается прикладная программная подсистема, ориентированная на сбор, хранение, поиск и обработку информации. Подавляющее большинство ИС работает в режиме диалога с пользователем.
В наиболее общем случае типовые функциональные компоненты, входящие в состав ИС, реализуют:
- диалоговый ввод/вывод (PS);
- логику диалога (PL);
- прикладную логику обработки данных (BL);
- логику управления данными (DL);
- операции манипулирования файлами (FS) и (или) базами данных (DS).
Таблица 1. Типовые функциональные компоненты ИС

ИС – это комбинация ручных и компьютерных процессов, которые решают поставленные задачи, четко и логично взаимодействуя между собой для достижения целей функционирования организаций, помогая им занимать лидирующие позиции в бизнесе.
Следует отметить, что любая ИС – это не только программы, данные и коммуникации, но и люди (заказчики, пользователи, аналитики, разработчики), организационные структуры, а также цели, стимулы работы предприятия отдельных людей. И все эти компоненты должны быть понятны как проектировщикам, так и пользователю, а, кроме того, непротиворечивым образом соединены в одну систему.
Главная идея процесса такого согласования состоит в том, что его надо начинать с анализа самых главных характеристик предметной области, рассматривая самые главные содержательные аспекты. И проводить его не «мысленно» и не «на словах», а на явно изложенных описаниях (моделях) объектов предметной области, позволяющих видеть все существенные взаимосвязи.
Под предметной областью неформально можно понимать любую область знаний, достаточно определенную, чтобы о ней могли быть собраны такие данные, о которых можно было бы говорить в аспекте существования или возможности существования базы этих данных.
Однако было бы нереалистично полагать, что по реляционным таблицам одной или даже нескольких баз данных можно разложить все данные, относительно которых принято решение автоматизировать выполнение операций над данными (накопление, хранение, обработку и др.) в комплексной автоматизированной системе информатизации большого предприятия. В ней (в АСИ) могут находиться:
- частично структурированные данные (гипертекстовые и гипермедийные БД) – по объему они составляют основную часть БД;
- полностью формализованные данные, такие как реляционные таблицы, программы и т. п.;
- интеллектуальные БД системы ИИ, созданные с использованием языков логического программирования.

2. Схема развития ИС

Схема предназначена для формирования взгляда на архитектуру ИС с точки зрения участников ее разработки. При моделировании бизнеса рассматривается 3 аспекта:
-объекты, с которыми оперирует бизнес (данные)
-процессы, которые он выполняет (функции)
-события, управляющие изменениями процессов и объектов
Можно определить след.типы моделирования:
-информационное
-функциональное
-событийное
В схеме Захмана каждой строке соответствует точка зрения одного из участников проекта по созданию системы. Точка зрения отображает значения и области ответственности заинтересованных лиц в процессе создания системы.
В основе схемы Захмана рассматривается 3 аспекта, каждому из которых соответствует колонка (или столбец), каждому аспекту соответствуют разные методы формирования представления.
В каждой ячейке представлен вид конечного продукта (архитектурное представление) с точки зрения некоторой группы лиц, участвующих в разработке системы:
1, 2 – заказчик, видит систему общих стратегических и тактических аспектов
3 – проектировщик, его представление является проектирование системы обеспечивающей удовлетворение требований заказчика, к которой должна быть добавлена точность необходимая для тех, кто будет реализовывать систему.
4, 5 – разработчик, его взгляд отражает множество решений ограниченных технологией, временем и стоимостью.
6 – пользователь, в каждой ячейки схемы представлен вид конечного продукта с точки зрения некоторой групп лиц участвующей в разработки системы.

В подходе Захмана не делается акцент на динамике развития ИС. При переходе от одной строки таблицы к другой меняется лишь точка зрения, с которой рассматривается система, причем эта точка зрения не обязана быть связана с уровнем детальности рассмотрения. В схеме Захмана отражены три аспекта системы, приблизительно соответствующие некоторым методикам моделирования (информационное моделирование, диаграмма потоков данных и т.д.).
Представляет интерес составить схему, аналогичную схеме Захмана, в которой в качестве аспектов при формировании архитектурных представлений используется хотя бы часть методик, представленных на диаграмме Баркера. Три основные части диаграммы: функциональное моделирование, информационное моделирование и событийное моделирование. Их пересечения - диаграммы потоков данных, анализ состояний, информационная динамика и функциональная логика.

	ЧТО(данные)	КАК(функции)	ГДЕ(сеть)	ПОЧЕМУ (стимулы)	КТО (участники бизнеса)	КОГДА (операционное время)
1.Потребности/ Внешняя среда	Список важнейших объектов бизнеса	Список процессов, выполняемых бизнесом	Список контактов	Конкурентная среда	Клиенты, партнеры, филиалы	Главные события ведения бизнеса
2.Бизнес модель	Диаграмма сущность- связь (ERD)	Функциональная иерархия (IDEF0) в терминах бизнеса.	Бизнес модель сети	Бизнес-план	Организационная структура предприятия	Календарный график выполнения основных процессов
3.Логическая модель	Концептуальная модель данных	Модель потоков данных DFD, IDEF3	Логическая модель сети	Бизнес правила	Схема взаимодействия участников бизнеса	Время обработки данных
4.Техноло- гическая модель	Структура базы данных	Проектиро -вание пользов-ательского интерфейса	Проектирова-ние сетевой архитектуры	Алгоритм реализации бизнес правил	Техническое оснащение рабочих мест	Схема контроля времени выполнения процессов
5.Детальное представление	Описание структуры данных	Реализация Пользовательс-кого интерфейса	Реализация сетевой архитектуры	Хранение процедур	Авторизация защиты информации	Реализация схемы
6.На взгляд пользователя	Результат	Интерфейс пользователя	Взаимно связь	Качество внедрения	Умение ответствиность	Календарный график, его анализ

3. Этапы проектирования ИС

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Под этапами (стадиями или фазами) будем понимать совокупность ступеней развития проекта от возникновения идеи до полного завершения проекта.
В определении количества этапов и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки ИС почти во всех случаях являются общими. [Избачков с. 40-43]
Обычно выделяют следующие этапы создания проекта ИС [Вендеров]:

На этом этапе конечные пользователи и проектировщики должны работать сообща.

- схема БД (на основании ER-модели, разработанной на этапе анализа);
- набор спецификаций модулей системы (на базе моделей функций).
Также на этапе проектирования определяется:
- выбор платформы и ОС (могут быть не единственными);
- характеристики архитектуры: ф/с или к/с; количество уровней (1, 2 или 3); централизованная или распределенная БД; однородность или неоднородность БД (по количеству используемых серверов). Этап проектирования заканчивается разработкой технического проекта ИС.

А) после завершения разработки отдельного модуля системы выполняют автономный тест, который преследует следующие цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций и отсутствие лишних функций).
Б) После того как автономный тест успешно пройден, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
После тестирования на взаимное влияние модулей необходимо выполнить еще ряд тестов:
В) тесты на проверку надежности работы:
1) тест имитации отказов, демонстрирующий, насколько хорошо система восстанавливается после сбоев ПО и отказов аппаратного обеспечения;
2) тест наработки на отказ (устойчивость системы при штатной работе для оценки времени безотказной работы системы);
3) системный тест (проверка функциональности системы);
4) приемо-сдаточные испытания (такой тест предусматривает показ ИС заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика).
Как правило, тестирование и эксплуатация занимают от 50% до 60% общего времени разработки ИС.
V. Ввод в действие. Эксплуатация и сопровождение. После ввода в действия организуется обучение конечных пользователей.
Практически сразу после ввода системы в строй конечные пользователи начинают просить внести в нее изменения. Внесение изменений и исправлений выполняется службой сопровождения системы, работающей в трех направлениях:
- корректирующее обслуживание – как ответ на возникающие ошибки системы;
- адаптивное обслуживание – как ответ на изменение корпоративной среды;
- усовершенствование – расширение возможностей системы.

4. Понятие жизненного цикла ИС, модели жизненного цикла информационной системы

Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ разработки систем (Systems Development Life Cycle, SDLC) отслеживает историю ЖЦ ИС и представляет «полную картину», в рамках которой могут быть спланированы и качественно оценены и проекты БД и разработка прикладных программ. ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Методология проектирования ИС описывает процесс создания и сопровождения систем в виде ЖЦ ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственности участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Модель ЖЦ отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель ЖЦ – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. [ISO/IEC 12207]
Модели жизненного цикла информационной системы.
- Каскадная модель

предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок (т. е. единое целое). Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем [2]:

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

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

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, делающая упор на начальные этапы ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная же задача - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения необходимо вводить временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
На практике наибольшее распространение получили две основные модели ЖЦ:
- каскадная (период 1970-1985);
-спиральная (после 1985).
Сравнение моделей ЖЦ
Несмотря на настойчивые рекомендации компаний – вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели.

5. Основные принципы создания ИС

6. Требования к методологии и технологии разработки ИС

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

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

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

Стандарт проектирования должен устанавливать:

Стандарт оформления проектной документации должен устанавливать:

Стандарт интерфейса пользователя должен устанавливать:

7. Методология RAD

Rapid Application Development
На фазе построения осущ и тестирован системы. RAD явл пригодн для достаточн небольш проектов, в котор присутств ярко выраж интерфейсн часть. Оценка размера прилож производ на основе функций элементов(экран, сообщ, отчеты, файлы). На этапе проектир испол CASE средства.
В настоящее время широко распространена, реализует подход в рамках разработки ИС.
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Каждый прототиппостепенно развивается в частьбудущей системы.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
< 1000 функциональных элементов          один человек
1000-4000 функциональных элементов    одна команда разработчиков
> 4000 функциональных элементов          4000 функциональных элементов на одну команду разработчиков
В качестве итога перечислим основные принципы методологии RAD:

8. Методы проектирования ИС

Методологии, технологии и инструментальные средства проектирования (CASE (Computer Aided Software Engineering – Автоматизированная разработка ПО)-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Любая технология представляет собой организованную и оформленную в нормативно – технических и организационно – правовых документов систему методов, стандартов, правил и приемов выполнения работ, а также инструментальных средств их автоматизации, обеспечивающую эффективную и управляемую процедуру получения продукции с заданными свойствами для заданных или заранее оговоренных условий.
Методология, опираясь на теорию, вырабатывает и рекомендует обоснованные приемы и рецепты для технологии и также частично пересекается и сливается с технологией.
Технология проектирования определяется как совокупность трех составляющих:

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

По степени аадаптивности проектных решений

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

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

В качестве элементов типизации выступают отдельные подсистемы.

Использование ТПР, включ.в себя полный набор, необходимый для функц-я ИС.

9. Функционально-ориентированные методологии проектирования. Основные принципы функциональной методики IDEF0

Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные).
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Функциональные методики, наиболее известной из которых является методика IDEF, рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
Функциональная методика IDEF0
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
верхняя сторона имеет значение "Управление" (Control);
левая сторона имеет значение "Вход" (Input);
правая сторона имеет значение "Выход" (Output);
нижняя сторона имеет значение "Механизм" (Mechanism).

Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе.
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название "входящей", "исходящей" или "управляющей".
Любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Глоссарий (Glossary) - набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

10. Методология IDEF0. Виды стрелок на диаграммах IDEF0

Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)
В IDEF0 различают пять типов стрелок:
Вход(Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы.
Управление(Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.
Выход(Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться.
Механизм(Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д.
Вызов(Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.
Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Связь по входу(output-input), когда стрелка выхода вышестоящей работы направляется на вход нижестоящей.
Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы.
Обратная связь по входу(output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.
Обратная связь по управлению(output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса.
Связь выход-механизм(output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Правила именования таких стрелок.

Правила именования сливающихся стрелок полностью аналогичны — ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.
Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего.
Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется "не-в-родительской-диаграмме".
Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения.

11. Методология IDEF0. Нумерация работ и диаграмм. Каркас диаграммы

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер.
Каркас диаграммы
Граничные рамки области построения диаграммы называют каркасом диаграммы.
Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.
Поля заголовка каркаса (слева направо)
Used At         Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова
Autor, Date, Rev, Project      Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы
Notes 123456789 10 Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
Status Статус отображает стадию создания диаграммы, отображая все этапы публикации
Working          Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы
Draft   Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
Recommended           Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается
Publication      Диаграмма готова к окончательной печати и публикации
Reader            Имя читателя (эксперта)
Date    Дата прочтения (экспертизы)
Context           Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмм

12. Методология IDEF0. Виды диаграммы IDEF0

Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);
диаграммы декомпозиции;
диаграммы дерева узлов;
диаграммы только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы — эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом и каждом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.

13. Диаграммы потоков данных. Назначение. Нотации DFD. Рекомендации по построению

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.
Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD – процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища).
Рекомендации по построению
1. Размещать на каждой диаграмме от 3 до 6-7 процессов.
2. Не загромождать диаграммы несущественными на данном уровне деталями.
3. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов.
4. Выбирать ясные, отражающие суть дела, имена процессов и потоков для улучшения понимаемости диаграмм, при этом стараться не использовать аббревиатуры.
5. Соблюдать следующие этапы:

1) Идентификация внешних объектов, с которыми система должна быть связана.
2) Идентификация основных видов информации, циркулирующей между системой и внешними объектами.
3) Предварительная разработка контекстной диаграммы.
4) Изучение предварительной контекстной диаграммы и внесение в нее изменений по результатам ответов на возникающие при этом изучении вопросы по всем ее частям.
5) Построение контекстной диаграммы путем объединения всех процессов предварительной диаграммы в один процесс, а также группирования потоков.
6) Формирование DFD первого уровня на базе процессов предварительной контекстной диаграммы.
7) Проверка основных требований по DFD первого уровня.
8) Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.
9) Проверка основных требований по DFD соответствующего уровня.
10) Добавление определений новых потоков в словарь данных при каждом их появлении на диаграммах.
11) Параллельное (с процессом декомпозиции) изучение требований (в том числе и вновь поступающих), разбиение их на элементарные и идентификация процессов или спецификаций процессов, соответствующих этим требованиям.
12) После построения двух-трех уровней проведение ревизии с целью проверки корректности и улучшения понимаемости модели.
13) Построение спецификации процесса (а не простейшей диаграммы) в случае, если некоторую функцию сложно или невозможно выразить комбинацией процессов.

14. Основные элементы диаграмм DFD

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

15. Диаграммы DFD. Элементы для декомпозиции данных

Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов:
1) ГРУППОВОЙ УЗЕЛ. Предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать (т.е. фактически вырождаться в точку слияния/расщепления потоков на диаграмме).
2) УЗЕЛ-ПРЕДОК. Позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD.
3) НЕИСПОЛЬЗУЕМЫЙ УЗЕЛ. Применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока.
4) УЗЕЛ ИЗМЕНЕНИЯ ИМЕНИ. Позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным.
5) Текст в свободном формате в любом месте диаграммы.

16. Диаграммы DFD. Управляющие элементы диаграмм

Управляющий поток. Представляет собой трубопровод, через который проходит управляющая информация. Его имя не должно содержать глаголов, а только существительные и прилагательные. Обычно управляющий поток имеет дискретное, а не непрерывное значение. Это может быть, например, сигнал, представляющий состояние или вид операции.
Управляющий процесс. Представляет собой интерфейс между DFD и спецификациями управления, собственно моделирующими и документирующими аспекты реального времени. Его имя указывает на тип управляющей деятельности, вырабатываемой спецификацией. Фактически управляющий процесс представляет собой преобразователь входных управляющих потоков в выходные управляющие потоки; при этом точное описание этого преобразования должно задаваться в спецификации управления.
Управляющее хранилище. Представляет собой срез управляющего потока во времени. Содержащаяся в нем управляющая информация может использоваться в любое время после ее занесения в хранилище, при этом соответствующие данные могут быть использованы в произвольном порядке. Имя управляющего хранилища должно идентифицировать его содержимое и быть существительным. Управляющее хранилище отличается от традиционного тем, что может содержать только управляющие потоки; все другие их характеристики идентичны.
Логически управляющий процесс есть некий командный пункт, реагирующий на изменения внешних условий, передаваемые ему с помощью управляющих потоков, и продуцирующий в соответствии со своей внутренней логикой выполняемые процессами команды. При этом режим выполнения процесса зависит от типа управляющего потока. Имеются следующие типы управляющих потоков:
Т-поток (trigger flow). Является потоком управления процессом, который может вызывать выполнение процесса. При этом процесс как бы включается одной короткой операцией. Это аналог выключателя света, единственным нажатием которого запускается процесс горения лампы.
А-поток(activator flow). Является потоком управления процессом, который может изменять выполнение отдельного процесса. Используется для обеспечения непрерывности выполнения процесса до тех пор, пока поток включен (т.е. течет непрерывно), с выключением потока выполнение процесса завершается. Это ≈ аналог переключателя лампы, которая может быть как включена, так и выключена.
E/D-поток (enable/disable flow). Является потоком управления процессом, который может переключать выполнение отдельного процесса. Течение по Е-линии вызывает выполнение процесса, которое продолжается до тех пор, пока не возбуждается течение по D-линии. Это аналог выключателя с двумя кнопками: одной ≈ для включения света, другой ≈ для его выключения. Отметим, что можно использовать 3 типа таких потоков: Е-поток, D-поток, E/D-поток.

17. Методология IDEF3. Назначение диаграмм. Основные элементы

Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции.
IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Элементы:
Единицы работы Unit of Work (UOW)- также называемые работами (activity), являются центральными компонентами модели. Изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия").

Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF3 стараются построить так, чтобы связи были направлены слева направо. В IDEF3 различают три типа стрелок, изображающих связи, стиль которых устанавливается через меню Edit/Arrow Style:
Старшая (Precedence)

Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
Отношения (Relational Link)

пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
Потоки объектов (Object Flow)

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

в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

18. Виды перекрестков на диаграммах IDEF3

Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления.

19. SwimLane диаграммы и построение сценариев SwimLaneDiagrams (диаграмма плавательных дорожек).

Это тоже нововведение, которое можно обнаружить только в BPwin 4.0. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей. Таким образом, на этой диаграмме можно показывать принадлежность той или иной работы к определенной роли. В качестве роли могут выступать свойства определенные пользователями или же роли, собранные в группы. Например, в качестве ролей могут выступать отделы организации, а сама диаграмма использоваться для указания работ, выполняемых в рамках каждого отдела.
Для создания Swim Lane диаграммы сначала необходимо определить ролевые группы, затем определить роли внутри каждой ролевой группы, создать собственно диаграмму и разместить ее элементы в области соответствующей роли.
Для определения ролевых групп необходимо выполнить команду меню Dictionary ?Role Group и в открывшемся окне ввести имена и другие определения каждой ролевой группы. После того, как ролевые группы определены, необходимо определить роли внутри каждой ролевой группы. Для этого необходимо выполнить пункт меню Dictionary ?Role и в открывшемся окне ввести имена ролей, их описания, а также указать привязку к ролевой группе. После этого можно приступить к созданию новой диаграммы Swim Lane. Для этого необходимо выбрать пункт меню Diagram - ?Add Swim Lane Diagram. Запустившийся мастер создания диаграмм позволит выбрать необходимые настройки: на чем будет основываться новая диаграмма (ролевые группы или свойства, определенные пользователем), и, если модель уже содержит одну или несколько диаграмм IDEF3, какую из них использовать в качестве основы. На этом шаге необходимо также ввести название диаграммы и нажать Далее. На втором шаге необходимо определить какие из созданных ранее ролей будут использованы для создания дорожек диаграммы. После того, как необходимые роли отмечены галочками, необходимо нажать кнопку Готово.
Описание сценария, области и точки зрения. Перед проведением сеанса экспертизы у экспертов предметной области должны быть задокументированы сценарии и рамки модели для того, чтобы эксперт мог понять цели декомпозиции. Кроме того, если точка зрения моделирования отличается от точки зрения эксперта, она должна быть особенно тщательно задокументирована. Возможно, что эксперт самостоятельно не сможет передать необходимую информацию. В этом случае аналитик должен приготовить список вопросов для проведения интервью
1. Для создания сценария выберите пункт главного меню Diagram/Add IDEF3 Scenario.
2. Создайте диаграмму сценария на основе существующей в модели диаграммы IDEF3 (например, "Сборка настольных компьютеров" с номером А22.1), задав параметры сценария
3. Удалите элементы, не входящие в сценарий.

20. Стоимостной анализ. Принципы связи ABC анализа и IDEF0

Cначала строится функциональная модель существующей организации работы — AS-IS (как есть). После построения модели AS-IS проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и улучшаются, в результате строится модель ТО-ВЕ. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких критериев много и непросто определить важнейший. Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес-процессов, необходима система метрики, т. е. качество следует оценивать количественно.
BPwin предоставляет аналитику два инструмента для оценки модели — стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). Функциональное оценивание – ABC – это технология выявления и исследования стоимости выполнения той или иной функции (действия). Исходными данными для функционального оценивания являются затраты на ресурсы (материалы, персонал и т.д.). В сравнении с традиционными способами оценки затрат, при применении которых часто недооценивается продукция, производимая в незначительном объеме, и переоценивается массовый выпуск, ABC обеспечивает более точный метод расчета стоимости производства продукции, основанный на стоимости выполнения всех технологических операций, выполняемых при ее выпуске. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация наиболее дорогостоящих работ (тех, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений и т.д.
ABC-анализ может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, когда создание модели работы закончено.
На более низком уровне, а именно, уровне функционального блока связь IDEF0- и ABC-моделей базируется на трех принципах:

Оценка информации, полученная по ABC модели позволяет:

21. Количественный и качественный анализ диаграмм модели IDEF

Для проведения количественного анализа диаграмм перечислим показатели модели:

Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.
Необходимо стремиться к тому, чтобы количество блоков на диаграммах нижних уровней было бы ниже количества блоков на родительских диаграммах, т. е. с увеличением уровня декомпозиции убывал бы коэффициент N/L. Таким образом, убывание этого коэффициента говорит о том, что по мере декомпозиции модели функции должны упрощаться, следовательно, количество блоков должно убывать.
Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 10: У работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка- готовое изделие.
Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кb был минимален для диаграммы.
Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.
После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C -произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.

22. Моделирование данных. Архитектура ANSI-SPARC

В общем случае БД обладают свойством независимости от прикладных программ и, как правило, представляются тремя уровнями архитектуры: внешним, концептуальным и физическим; обращение к БД осуществляется с помощью СУБД.

Рассматриваемая нами архитектура почти полностью согласуется с архитектурой, предложенной исследовательской группой ANSI/SPARC (Study Group on Data Management Systems). В задачи группы входило определение того, нуждаются ли какие-либо области технологии БД в стандартизации (и если нуждаются, то какие именно) и выработка набора рекомендуемых действий в каждой из этих областей. В процессе работы над поставленными задачами группа пришла к выводу, что единственный подходящий объект стандартизации – интерфейсы, и в соответствии с этим определила общую архитектуру, или фундамент, СБД, а также указала на важную роль подобных интерфейсов. В окончательном отчете (1978 г.) представлено подробное описание архитектуры и некоторых из 42 указанных интерфейсов.

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

Рис. Три уровня архитектуры ANSI/SPARC

Внешний уровень – представление отдельного пользователя. Отдельного пользователя интересует лишь некоторая часть всей БД. Кроме того, представление пользователя об этой части будет, безусловно, более абстрактным по сравнению с выбранным способом хранения данных. Предоставляемый в распоряжение пользователя подъязык данных определяется в терминах внешних записей (например, выборка множества записей).каждое внешнее представление определяется внешней схемой, которая в основном состоит из определений записей каждого из типов, присутствующих в этом внешнем представлении.(например, тип внешней записи о сотруднике можно определить как 6-символьное поле с номером работника, как поле из пяти десятичных цифр, предназначенных для хранения данных о его зарплате и т.д.).
Концептуальное представление – это представление всей информации БД в несколько более абстрактной форме (как и в случае внешнего представления) по сравнению с описанием физического способа хранения данных. Концептуальное представление определяется с помощью концептуальной схемы. Чтобы добиться независимости от данных, в нее не включаются какие-либо указания о структурах хранения или методах доступа, упорядоченности хранимых данных, индексировании и т.д. Определения концептуального языка должны относится только к содержанию информации. Если концептуальная схема действительно обеспечивает независимость от данных в этом смысле, то внешние схемы, определенные на основе концептуальной, заведомо будут обеспечивать независимость от данных. Концептуальное представление – это представление всего содержимого БД, а концептуальная схема – это определение такого представления. Определения в концептуальной схеме также могут характеризовать большое количество различных дополнительных аспектов обработки информации, например, ограничения защиты или требования поддержания целостности данных.
Внутренний уровень – это низкоуровневое представление всей базы данных. Внутренняя запись - хранимая запись. Внутренне представление также отделено от физического уровня, так как в нем не рассматриваются физические записи (обычно называемые блоками или страницами). Внутреннее представление описывается с помощью внутренней схемы, которая определяет не только типы хранимых записей, но и существующие индексы, способы представления хранимых полей, физическую упорядоченность записей и т.д.

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

24. ER-диаграммы. Определение сущности, атрибута, связи

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD). С помощью ERD осуществляется детализация накопителей данных DFD – диаграммы, а также документируются информационные аспекты бизнес-системы, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).
Базовые понятия ERD
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр
Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:

Каждая сущность может обладать любым количеством связей с другими сущностями модели.
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме "сущность-связь" атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.

25. Методология IDEF1X. Виды и мощности связей. Понятие зависимых и независимых сущностей

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На логическом уровне можно установить идентифицирующую связь "один-ко-многим", связь "многие-ко-многим" и неидентифицирующую связь "один-ко-многим".
Мощность связи представляет собой отношение количества экземпляров одной сущности к соответствующему количеству экземпляров другой сущности. Связи в модели «сущность-связь» могут иметь мощность: «один-к-одному» (1:1), «один-ко-многим» (1:M) и «многие-ко-многим» (M:N).
Связь 1:1 («один-к-одному») – это связь между двумя типами сущностей A и B, при которой каждому экземпляру сущности A соответствует один и только один экземпляр сущности B.
Связь 1:M («один-ко-многим») – это связь между двумя типами сущностей A и B, при которой одному экземпляру сущности A может соответствовать ноль, один или несколько экземпляров сущности B, но каждому экземпляру сущности B соответствует только один экземпляр сущности A.
Связь M:N («многие-ко-многим») – это связь между двумя типами сущностей A и B, при которой каждому экземпляру сущности A может соответствовать ноль, один или несколько экземпляров сущности B и наоборот.

В IDEFIX различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ — FK.
При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной (см. рис. 10.6).
Мощность связей (Cardinality) — служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа сущности:

Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи "один-ко-многим", идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent.

26. Методология IDEF1X. Виды зависимых сущностей

Различают несколько типов зависимых сущностей.
Характеристическая — зависимая дочерняя сущность, которая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности.

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

27. Нормальные формы ER-диаграмм. Получение реляционной схемы из ER-диаграмм

Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем. Мы приведем только очень краткие и неформальные определения трех первых нормальных форм.

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

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

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

Шаг 1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют несколько разных взаимосвязанных классов объектов реального мира (именно это соответствует ненормализованным отношениям). Если такое выявлено, то разделить каждую из этих сущностей на несколько новых сущностей и установить между ними соответствующие связи, полученная схема будет находиться в первой нормальной форме. Перейти к шагу 2.

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

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

Шаг 4. Проанализировать все сущности на наличие детерминантов, которые не являются возможными ключами. При обнаружении подобных расщепить сущность на две, установив между ними соответствующие связи. Полученная схема соответствует нормальной форме Бойса—Кодда. Перейти к шагу 5.

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

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

Получение реляционной схемы из ER-диаграмм.
Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы. Если имеется несколько возможных уникальных идентификатора, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей.

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:
все подтипы в одной таблице (а)
для каждого подтипа - отдельная таблица (б)

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.

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

Шаг 7. Имеется два способа работы при наличии исключающих связей:
общий домен (а)
явные внешние ключи (б)

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

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

28. Реляционная модель данных. Структурная часть. Управляющая связь. Виды ключей

Части реляц. модели:
- струтурная часть,
-управл. Часть
-набор огранич. целостности.
Структурная часть – РМ основ на мат понятии «отношение», физ представ кот явл-ся двумер.таблица отношения исп-мая для хранения информации об объектак БД. Строки таблицы соотв отд, наз-х картажами, столбцы – их атрибутам.
Атрибут (поле) – имен-й столбец отношения. Порядок атрибутов строго не фиксируется.Каждый атрибут опред-ся на некотором домене, кто представляет собой набор допустимых значений для одного или нескольких атрибутов.
Строки отношения(табл.) – кортежи(записи). Степеньотношения определ-ся количеством атрибутов, кардинальность-кол-во кортежей.
Благодаря доменам, пользователь может определить смысл и источник значений.
В РМ пользователь воспринимает БД как набор отношений. Такое восприятие относится к логич стр-ре. (т.е. и внеш), а физ стр-ра реализована с помощью различных структур хранения. Структура отношений определяется с помощью особых методов, наз нормализацией.
Свойства отношений

Домен – это множество допустимых значений одного или несколько атрибутов, заданная на данном типе данных.
Отношения – это таблица (бытовой уровень).
Схема отношений – это именованное {множество} пар, имя атрибута и имя домена.
Для тех СУБД, которые не поддерживают понятие домена, схема отношений это имя атрибута и тип данных.
Сотрудники < Номер сотрудника (табельный номер), ФИО (имена), зарплата (размер выплат)>
Иногда схему отношений называют заголовком отношений.
Степень (арность) отношений – кол-во атрибутов отношений
Кортеж – это множество пар имя атрибутов значения, соответствующие данной схеме отношений (одна строка таблицы).
Отношения – это множество картежей, соответствующих одной схеме отношений.
Тело отношений – это отношение, как набор картежей.
Кардинальное число (кардинальность) – это количество кортежей в отношениях.
Схема базы данных – это набор именованных схем отношений.
Достоинства реляционной модели: теоретическая обоснованность, простота логической структуры, удобство физической реализации, широкие возможности манипулированием данными.
Недостатки реляционной модели: сложность моделирования иерархических и сетевых связей, имеющих место в предметной области, не позволяет адекватно описать такие сложные предметные области как: конструирование, производственные и технологические процессы, ГИС.

Виды ключей:
Суперключ (superkey) – это атрибут или множество атрибутов, которое единственным образом идентифицирует кортеж данного отношения. Суперключ однозначно обозначает каждый кортеж в отношении. Но суперключ может содержать дополнительные атрибуты, которые необязательны для уникальной идентификации кортежа.
Потенциальный ключ – это суперключ, который не содержит подмножества, также являющегося суперключом данного отношения.
Потенциальный ключ К для данного отношения R обладает двумя свойствами.
-уникальность – в каждом кортеже отношения R значение ключа К единственным образом идентифицируют этот кортеж;
-неприводимость – никакое допустимое подмножество ключа К не обладает свойством уникальности.
Отношение может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом.
Первичный ключ – это потенциальный ключ, который выбран для уникальной идентификации кортежей внутри отношения.
Поскольку отношение не содержит кортежей – дубликатов, всегда можно уникальным образом идентифицировать каждую его строку. Это значит, что отношение всегда имеет первичный ключ. В худшем случае все множество атрибутов может использоваться как первичный ключ, но обычно, чтобы различить кортежи, достаточно использовать меньшее подмножество атрибутов.
Альтернативный ключ – это потенциальный ключ, который не выбран в качестве первичного ключа.
Внешний ключ – это атрибут или множество атрибутов внутри отношения, которое соответствует потенциальному ключу некоторого (может быть, того же самого) отношения.

29. Реляционная модель данных. Набор ограничений целостности. Операции, нарушающие целостность

Ограничение целостности – это совокупность утверждений о допустимости значений в базе д-х и связях между ними.
При выполнении операций над базой данных проверяется выполнение ограничения целостности и действия, приводящие к нарушению ограничений целостности, отвергаются.
ОЦ
/ \
Внешнее Внутреннее
Внешнее оц диктуется предметной областью.
Внутренние оц определяются моделью данных.
Ограничения, которые используются только при проверке допустимости корректировки, называются ограничениями перехода.
Ограничение целостности атрибута представляют собой ограничения, накладываемые на допустимые значения атрибута.

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

Ограничения целостности отношения представляют ограничения, накладываемые только на допустимые значения отдельного отношения, и не являющиеся ограничением целостности кортежа. Требование, что ограничение относится к отдельному отношению, означает, что для его проверки не требуется информации о других отношениях (в том числе не требуется ссылок по внешнему ключу на кортежи этого же отношения).
Ограничение целостности.
Совокупность взаимосвязанных таблиц.
Внешний ключ – это атрибут или группа атрибутов отражающих связь между отношениями (объектами)
Ссылающиеся отношения – это отношения, которые содержат внешний ключ.
Ссылочное или целевое отношение – это отношение, которому соответствует потенциальный ключ.
Ограничение целостности связи заключается в том, что для каждого значения внешнего ключа, появляющегося ссылающимся отношением в целевом отношении должен найтись картеж с таким же значением потенциального ключа, любо значение внешнего ключа должно быть неопределенным (значение NULL).
Ограничение по существованию является разновидностью ограничения целостности связей.
Ограничение по существованию заключается в том, что для существования объекта в отношении S1 необходимо, чтобы он был обязательно связан с объектом в отношении S2.
Внешний ключ в отношении S1 не может быть неопределенным (значение NULL).
В предметной области может существовать ситуация обратной связи по существованию, когда не может существовать запись родительской таблицы без связанной с ней дочерних записей.
Прочие ограничения:

Другим признаком классификации по временному признаку является классификация по режиму проверки корректности базы данных.
Возможны два режима проверки целостности:

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

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

Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.
Можно рассмотреть дополнительные стратегии поддержания ссылочной целостности :

В некоторых реализация СУБД рассматривается еще одна стратегия поддержания ссылочной целостности :

//Поскольку каждый атрибут связан с некоторым доменом, для множества допустимых значений каждого атрибута отношения определяются ограничения домена.
Задаются два правила целостности, которые являются ограничениями для всех допустимых состояний базы данных: целостность сущностей и ссылочная целостность.
Целостность сущностей – в базовом отношении ни один атрибут первичного ключа не может содержать отсутствующих значений, обозначаемых как NULL.
По определению, первичный ключ — это минимальный идентификатор, который используется для уникальной идентификации кортежей. Это значит, что никакое подмножество первичного ключа не может быть достаточным для уникальной идентификации кортежей. Если допустить присутствие NULL в любой части первичного ключа, это равносильно утверждению, что не все его атрибуты необходимы для уникальной идентификации кортежей, что противоречит определению первичного ключа.
Второе ограничение целостности касается внешних ключей.
Ссылочная целостность – если в отношении существует внешний ключ, то значение внешнего ключа должно либо соответствовать значению потенциального ключа некоторого кортежа в его базовом отношении либо внешний ключ должен полностью состоять из значений NULL.Корпоративные ограничения целостности – дополнительные правила поддержки целостности данных, определяемые пользователями или администраторами базы данных.//

30. Реляционная алгебра. Теоретико-множественные операции

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

Специальные реляционные операции включают:

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

Объединение – это операция реляционной алгебры, создающая теоретико-множественное объединение двух объединительно совместимых реляционных таблиц (U / UNION)
·При выполнении операции объединения двух отношений производится отношение, включающее все те кортежи, которые входят хотя бы в одно из отношений-операндов:
{<отношение1> UNION < отношение2>}
После преобразования получим следующий запрос SQL:
SELECT <список атрибутов> FROM < отношение1>
UNION
SELECT < список атрибутов > FROM < отношение2>
Отметим, что почти все операции (кроме нескольких специальных) выполняются для атрибутов с одинаковыми именами и определённых на одном и том же домене.
Объединительно совместимые таблицы – это таблицы, у которых совпадают количество столбцов и области значений этих столбцов.

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

Операция пересечения – это операция реляционной алгебры, создающая теоретико-множественное пересечение двух объединительно совместимых реляционных таблиц (? / INTERSECT).
Результат пересечения: это реляционная таблица, содержащая строки, которые совпадают у таблиц.
· Операция пересечения двух отношений производит отношение, включающее все те кортежи, которые являются общими для обоих отношений-операндов:
{<отношение1> INTERSECT <отношение2>}
После преобразования получим:
SELECT DISTINCT <список атрибутов> FROM <отношение1>
WHERE EXISTS
(SELECT * FROM <отношение2> WHERE
<отношение1>.<атрибут1> = <отношение2>.<атрибут1> AND
<отношение1>.<атрибут2> = <отношение2>.<атрибут2> AND… )

Операция разности – это операция реляционной алгебры, создающая теоретико-множественную разность двух объединительно совместимых реляционных таблиц (- / DIFFEFENCE).
Результат разности: реляционная таблица, содержащая все строки входящие в первую таблицу, но не входящие во вторую исходную таблицу.
· Отношение, являющееся разностью двух отношений, включает все кортежи, входящие в отношение, являющееся первым операндом, такие, что ни один из них не входит в отношение, являющееся вторым операндом:
{<отношение1> MINUS <отношение2>}
После преобразования получим:
SELECT DISTINCT <список атрибутов> FROM <отношение1>
WHERE NOT EXISTS
(SELECT * FROM <отношение2> WHERE
<отношение1>.<атрибут1> = <отношение2>.<атрибут1> AND
<отношение1>.<атрибут2> = <отношение2>.<атрибут2> AND … )

Операция произведения – это операция реляционной алгебры, создающая декартово произведение двух объединительно совместимых реляционных таблиц (* / Product).
С:=А*В

Результат произведения: реляционная таблица, полученная при связывании таблиц и при присоединении каждой строке первой таблицы каждой строки второй таблицы.
Если в исходных таблицах существуют атрибуты с одинаковыми именами, то имя атрибута новой таблицы образуется из имени исходной таблицы с указанием через точку имени поля.
· Прямое (декартово) произведение двух отношений есть отношение, кортежи которого являются конкатенацией (сцеплением) кортежей первого и второго операндов:
{<отношение1> TIMES <отношение2>}
Эквивалентный запрос SQL имеет вид:
SELECT DISTINCT <список атрибутов> FROM
<отношение1>, <отношение2>.

31. Реляционная алгебра. Специальные операции

Операция выборка – это операция реляционной алгебры, производящая отбор строк исходной таблицы на основании некоторого условия (SELECT / WHERE).
Результат выбора: реляционная таблица.
Синтаксис операции: Имя новой таблицы:= SELECT (имя исходной таблицы: условие).
Операция создания проекции – это операция реляционной алгебры, создающая новую таблицу путем исключения столбцов из исходной таблицы (Project / либо указывается столбец, который следует оставить в результирующей таблице).
Проекция – это реляционная таблица, полученная в результате применения к исходной таблицы операции проекции.
· При выполнении проекции отношения на заданный набор его атрибутов производится отношение, кортежи которого производятся путем взятия соответствующих значений из кортежей отношения-операнда. Операция переименования производит отношение, тело которого совпадает с телом операнда, но имена атрибутов изменены:

<отношение>[<атрибут1> AS <псевдоним1>, <атрибут2>, …] .
После преобразования получится следующий запрос SQL:
SELECT DISTINCT <атрибут1> AS <псевдоним1>, <атрибут2>, …
FROM <отношение>.
Операция создания проекции автоматически исключает повторы из результирующей таблицы.
Операция деления – это операция реляционной алгебры, создающая новую таблицу, потеем выбора строк одной таблицы соответствующих каждой строке другой таблицы (/ DIVISOIN).

Операция соединения – это операция реляционной алгебры, связывающая таблицы (Join).
Существуют следующие соединения:

· При естественном соединении двух отношений образуется результирующее отношение, кортежи которого являются конкатенацией кортежей первого и второго отношений по атрибутам с одинаковыми именами. То есть соединяться будут кортежи, у которых совпадают значения в полях с одинаковыми именами. В результирующем отношении дубликатные атрибуты отсутствуют. Операция естественного соединения
{<отношение1> JOIN <отношение2>}
преобразуется в следующий запрос:
SELECT DISTINCT <список всех атрибутов без повторений> FROM
<отношение1> INNER JOIN <отношение2> ON
<отношение1>.<атрибут1> = <отношение2>.<атрибут1> AND
<отношение1>.<атрибут2> = <отношение2>.<атрибут2> AND …
Отметим, что внутреннее соединение выполняется здесь только по атрибутам с совпадающими именами.
Естественные соединения – это операция соединения, связывающая таблицы, когда общие столбцы имеет равные значения, при этом из результата исключаются повторяющиеся столбцы.
Операция естественного соединения выполняется в три этапа:

32. Реляционная модель данных. 1НФ, 2НФ, 3НФ, НФБК

Реляционная модель данных — логическая модель данных, прикладная теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных.Реляционная модель данных является приложением к задачам обработки данных таких разделов математики как теория множеств и формальная логика.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation
Для лучшего понимания РМД следует отметить три важных обстоятельства:
• модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
• для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
• наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Целью нормализации является устранение недостатков структуры базы данных, приводящих к вредной избыточности в данных, которая в свою очередь потенциально приводит к различным аномалиям и нарушениям целостности данных.
Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
1 Типы нормальных форм
Первая нормальная форма (1NF)
Отношение находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.
В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается таблиц в существующих реляционных СУБД (SQL-СУБД), то они могут не быть правильными отношениями и, соответственно, не находиться в 1NF.
Вторая нормальная форма (2NF)
Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов(частей). Или другими словами: в 2NF нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1NF).
Третья нормальная форма (3NF)
Согласно определению Кодда, таблица находится в 3НФ тогда и только тогда, когда выполняются следующие условия:
• Отношение R (таблица) находится во второй нормальной форме;
• Каждый непервичный атрибут R находится в нетранзитивной (то есть прямой) зависимости от каждого ключа R.
Таким образом, отношение находится в 3NF тогда и только тогда, когда оно находится во 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых. Транзитивной зависимостью неключевых атрибутов от ключевых называется следующая: A → B и B → C, где A - набор ключевых атрибутов (ключ), B и С - различные множества неключевых атрибутов.
При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3NF.
Нормальная форма Бойса — Кодда (BCNF)
Это модификация третьей нормальной формы (в некоторых источниках именно 3NF называется формой Бойса — Кодда).
Таблица находится в BCNF, если она находится в 3NF, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов. Таблица может находиться в 3NF, но не в BCNF, только в одном случае: если она имеет, помимо первичного ключа, ещё по крайней мере один возможный ключ. Все зависимые от первичного ключа атрибуты должны быть потенциальными ключами отношения. Если это условие не выполняется, для них создаётся отдельное отношение. Чтобы сущность соответствовала BCNF, она должна находиться в третьей нормальной форме. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в BCNF.

33. Реляционная модель данных. Нормальные формы более высоких порядков

Реляционная модель данных — логическая модель данных, прикладная теория, описывающая структурный аспект, аспект целостности и аспект обработки данных в реляционных базах данных.Реляционная модель данных является приложением к задачам обработки данных таких разделов математики как теория множеств и формальная логика.
Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation
Для лучшего понимания РМД следует отметить три важных обстоятельства:
• модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
• для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
• наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.
Целью нормализации является устранение недостатков структуры базы данных, приводящих к вредной избыточности в данных, которая в свою очередь потенциально приводит к различным аномалиям и нарушениям целостности данных.
Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
1 Типы нормальных форм
Четвёртая нормальная форма (4NF)
Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y. То есть, таблица находится в 4NF, если все ее многозначные зависимости являются функциональными.
Пятая нормальная форма (5NF)
Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной. Пятая нормальная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.
Доменно-ключевая нормальная форма (DKNF)
Отношение в ДКНФ не имеет аномалий модификации. Другими словами, что бы ни менялось — ничего не потеряется, если соблюдены все ограничения относительно ключей и доменов. Формулировка слишком общая, но суть ее заключается в том, что если выполнять некоторые правила, то при любых действиях с таблицей ее целостность не пострадает и вся необходимая информация сохранится. Если рассматривать на примере, то правила действуют примерно так: нельзя просто удалить категорию из таблицы категорий, если с этой категорией связаны, например, продукты из таблицы продуктов. Прежде чем удалять категорию, необходимо выполнить предварительные действия в таблице продуктов (например, поле отвечающее за id категории этого товара нужно сделать NULL).
Шестая нормальная форма (6NF)
Таблица находится в 6NF, если она находится в 5NF и удовлетворяет требованию отсутствия нетривиальных зависимостей. Зачастую 6NF отождествляют с DKNF.
Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
В основе RUP лежат следующие основные принципы:

36. Язык моделирования UML. Назначение. Характеристики. Перечень диаграмм

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение, и больше сконцентрироваться на проектировании и архитектуре.
Преимущества UML
UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.
Язык UML (Unified Modeling Language) разработан для специфик-и, визуализ-и, проектир-я и документир-я компонентов ПО и бизнес-процессов. UML - ОО язык моделир-я, облад. хар-ками:
1) обеспеч. разработку репрезентат. моделей для взаимод. заказчика и разработчика, а также разл. групп разработчиков; 2) строить модели на основе ср-в ядра UML; 3) добавлять нов. эл-ты и усл. обозначения, не входящие в ядро 4) вводить нов. систему обозначений и ограничений для конкр. предм. обл-ти
С т.з. объектно-ориент. анализа и проектир-я (ООАП) достаточн. сложн. модель системы предст. собой нек-рое кол-во взаимосвяз-х между собой диаграмм, каждая из к-рых адекватно отражает аспект поведения или стр-ры системы. Т.о. процесс ООАП предст. собой послед-й переход от разработки наиб. общих моделей концепт. уровня к более частным и детальным моделям логич. и физич. уровня, к-рые послед-но дополн-ся деталями для более адекватного отражения аспектов предм. обл-ти.
В нотации UML опред-ны след. виды диаграмм:
Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это обобщенная модель функционирования системы в окружающей среде.
Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.
Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).
Диаграммы состояний (statechart diagrams) – модель динамического поведения системы и ее компонентов при переходе из одного состояния в другое.
Диаграммы классов (class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.
Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.
Диаграммы компонентов (component diagrams) – модель иерархии подсистем, отражает физическое размещение баз данных, приложений и интерфейсов ИС.
Диаграммы развертывания (диаграммы размещения, deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.Общий подход к моделир-ю
- на концепт. уровне разрабат-ся диагр. вар-тов исп-я, к-рая явл-ся исходной для построения остальных диаграмм
- для предст-я на логич. уровне разраб-ся диагр. классов, а также диаграммы

37. Построение диаграммы вариантов использования средствами UML

Визуальное моделир-е ср-вами UML предст собой неα процесс поуровневого спуска от наиб. общей и абстрактной концепт. модели исх. системы к логической, а затем и физической. С этой целью вначале строится диаграмма вар-тов использ-я (ДВИ), α опис-ет функц. назначение системы.
ДВИ разраб-ся с целями:
1)опред-е общих границ и контекста моделир-й предм. обл. на нач. этапах моделир-я
2) формулировка треб-й к функц. поведению проектир-й системы
3) разработка концепт. модели для её послед-й детализации на лог. и физич. уровне
4)подгот. исх. документации для взаимод-я разработчика с заказчиками и польз-ми
Суть диаграммы: Система предст. сосбой мн-во сущностей актёров, взаимод-х с пом. вар-тов исп-я. Актёр – действ. лицо или сущность, взаимод-я с системой извне.
Вариант исп-я (ВИ) служит для описания сервисов, α система предост. актёру, т.е. он опр-ет набор действий, реализ-х системой при взаимод-и с актёром.
Базовые эл-ты: 1

1)ВИ цель: зафиксировать фрагмент поведения проектируемой ИС без раскрытия внут. стр-ры. Сервис, предоставляемый ВИ, иниц-ся по запросу польз-ля. После обработки запроса сист. возвращ-ся к исх. состоянию. ДВИ сод-т конечное мн-во ВИ, α в целом определяют все возм. стороны ожидаемого поведения системы.
2)Актёры Каждый актёр имеет имя, α д.б. информативным. Другие системы или подсистемы. Кажд. актёр опр-ет мн-во ролей, в α могут выступать польз-ли ИС в процессе взаимод-я с ней.
3) Отношения. В отнош-я могут вступать компоненты ДВИ. Отношение – семантич. связь между отд. Эл-ми диаграммы.
а

а) отнош-е ассоциации – для обознач-я роли актёра при его взаимод-и с ВИ. Ассоц-я может иметь имя и кратность(обозн числом, диапазоном, *)
б) отнош-е расширения – опр-ет взаимосвязь отдельн. ВИ с более общим. Напр. от того ВИ, α явл-ся расширением. Один ВИ м. б. расшир-ем для неск. исх. ВИ, а также иметь в кач-ве расш-я несколько ВИ.
в) отнош-е обобщения – исп-ся между ВИ или актёрами и указ., что неα ВИ А (потомок) м.б. обобщён до ВИ В(родитель) Исп-ся, если дочерний объект обладает всеми атрибутами и особ-ми поведения родительского ВИ(актёра), при этом могут быть новые св-ва поведения. Один ВИ может иметь неск. родительских и неск. дочерних.
г) отнош-е включения устан-ся только между ВИ и указ, что заданное поведение одного ВИ включ-ся в посл-ть поведения другого ВИ.
Выбор применяемой связи для 2 последних видов отнош-й опр-ся след. правилом: связь расширения след. применять при описании изменений в нормальном поведении системы, а отнош-е включения для избежания повторов в 2 или более ВИ.
Отдельные эл-ты ДВИ м.б. заключ. в прям-к, α означает проектир. систему вцелом.
Примечания – м.б. исп. на диагр. любых видов.

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

Уточнение предъявл-х к ИС треб-й с целью конкретизации м.б. в 2 направлениях
1.дополнение имеющ-ся ДВИ путём введения обобщ-я и включения
2.уточнение её компонентов с пом. диаграмм других видов.
Рекомендации по построению ДВИ:
Хорошим источником для идент-и ДВИ служат внеш. события, поэтому следует начать с перечисл-я всех событий, происх. во внеш. мире, на α система должна реагировать. Их идент-я позв. выделить ВИю Общ. кол-во актёров <=20, ВИ<=50

38. Построение диаграммы классов средствами UML. Основные элементы

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

На начальных этапах проектир-я классы могут опис-ся только именами и, по мере дальнейш. обработки, дополняться атрибутами и операциями. Класс может иметь или не иметь экземпляров. в завис-ти от этого классы раздел-ся на конкретные и абстрактные.
Атрибут класса служит для отобр. признака, к-рый явл-ся общим для всех экземпляров класса.
Общая запись атрибута:
/ (если атрибут явл-ся производным) <квантор видимости><имя атрибута (обязат)>:[кратность]<тип атрибута>=<исходное значение>{строка-свойство}
Квантор видимости:
+ (public) общедоступный
# (protected) защищённый (только для подклассов данного)
- (private) закрытый (только в текущ. классе)
~ (package) пакетный (только для классов в пределах пакета)
Имя атрибута – уникальное, без пробелов.
Кратность хар-ет общее кол-во конкретных атрибутов данного типа (1..5 0..* или *).
Тип атрибута опр-ся в зав-ти от языка прогр-я и опр-ет мн-во допустимых значений.
Исх. значение опр-ет нач. значение атрибута в момент создания отд. экземпляра класса.
Строка-свойство обознач. фиксир. значение, к-рое принимают все экземпляры класса без исключения.
Операция предст. собой нек-рый сервис, предост-й каждым экземпляром класса по опред. требованию. Сов-ть операций хар-ет ф-циональный аспект поведения класса.
<квантор видимости><имя операции>(список параметров):<выр-е типа возвращ. значения>{строка-свойство}
Формат записи параметра:
<вид парам.><имя>:<выр-е типа>=<знач-е по умолч.>
Вид: in, out, inout; по умолч. – in

39. Построение диаграммы классов средствами UML. Отношения между классами

Отношения между классами:
- ассоциации - обобщения - агрегации - композиции
Отношение ассоциации

М.б. добавлены спец. символы
Для хар-ки её св-в: имя ассоциации (роль), кратность на каждом из концов, направление. Конец ассоциации явл-ся частью ассоциации, но не класса. Роль специфицирует действие, выполняемое классом.
Исключающая ассоциация

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

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

Отношение обобщения
Опред-ся между более общим классом (родителем) и более частным (дочерним, потомком).

Спецификация ограничений отношений обобщения
{complete} - означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может;
{disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов;
{incomplete}- означает случай, противоположный первому, то есть, что на диаграмме указаны не все классы-потомки. В дальнейшем возможно восполнить их перечень не изменяя уже построенную диаграмму;
{overlapping} - означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.
Язык UML содержит 2 спец. расширения (доп. графич. обозначения):
- профиль для процесса разработки ПО
- профиль для процесса моделир-я
Для уточнения семантики отд. классов введены след. типы:
Управляющий класс

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

Класс-сущность

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

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

Сотрудник для связи с окружением

Являясь частью бизнес-системы взаимод-т с актёрами при реализации бизнес-процесса.

Бизнес-сущность
Не инициирует никаких сообщ., служит для сохр. инф-и о рез-тах бизнес-процесса в системе.

40. Расширения языка UML. Виды профилей

Одним из несомненных достоинств языка UML является наличие механизмов расширения, которые позволяют ввести в рассмотрение дополнительные графические обозначения, ориентированные для решения задач из определенной предметной области. Язык UML содержит два специальных расширения: профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и профиль для бизнес-моделирования (The UML Profile for Business Modeling).
В рамках первого из них предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении различных диаграмм:
-Управляющий класс (control class) — класс, отвечающий за координацию действий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими. Управляющий класс отвечает за координацию действий других классов. У каждой диаграммы классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий этого варианта использования. Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом <<control>> (рис. 5.3, а).
-Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность содержит информацию, которая должна храниться постоянно и не уничтожается с уничтожением объектов данного класса или прекращением работы моделируемой системы, связанные с выключением системы или завершением программы. Как правило, этот класс соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>> (рис. 5.3, б).
-Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>> (рис. 5.3, в).

Рис. 5.3. Графическое изображение классов для моделирования программного обеспечения
В рамках второго профиля также предложено три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:
-Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<worker>> или <<internalWorker>> (рис. 5.4, а).
-Сотрудник для связи с окружением (caseworker) – класс, служащий для представления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<caseWorker>> (рис. 5.4, б).
-Бизнес-сущность (business entity) — специальный случай класса-сущности, который также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом <<business entity>> (рис. 5.4, в).
Графическое изображение классов для моделирования бизнес-систем

Графическое изображение классов для моделирования бизнес-систем

41. Построение диаграммы деятельности средствами UML

Диаграммы деят-ти акцентируют внимание на послед-ти вып-я опред. действий, к-рые приводят к опред. рез-ту. Каждое состояние соотв-ет элементарной операции, при завершении к-рой осущ-ся переход в след. состояние.
Графически диаграммы деят-ти предст-ся в форме графа, вершинами к-рого явл-ся т.н. состояния деят-ти, а дугами – переходы из одного сост.в другое.
Элементы:
1) состояние деят-ти (действие)

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

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

2) переходы
На диагр. деят-ти исп-ся переходы, называемые нетриггерными, т.е. такие, к-рые срабатывают сразу после завершения действия или деят-ти.

Состояние деят-ти всегда имеет один переход, или таких переходов м.б. несколько – ветвление, при к-ром на каждом переходе указ-ся сторожевое условие в форме логич. выр-я. При ветвлении срабатывает только один из переходов.

3) Каждая диагр. деят-ти должна иметь единств. начальное и конеч. сост-я.
Саму диаграмму деят-ти следует располагать так, чтобы действия шли сверху вниз.
Часто возникает необх-ть отображения вып-я параллельных процессов. Для этого исп-ся эл-ты диагр. деят-ти разделение и слияние.

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

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

Объекты присоед-ся к состояниям деят-ти отношением завис-ти.

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

42. Построение диаграммы последовательности средствами UML. Основные элементы

Одной из хар-к ИС разл. природы и назначения явл-ся взаимодл-е между собой отд. эл-тов, из α образованы эти системы. В UML сообщение, под α поним-ся инф-я, с помощью α взаимод-ют объекты, приобретает доп. св-во оказывать опред. влияние на своего получателя, т.е. взаимод-е между Эл-мы сводится к отправке и получению сообщений.
В UML сущ-ет 2 вида диаграмм взаимод-я: диагр. послед-ти и кооперации.
Элементы диагр. послед-ти:
1)

1)объекты – изобр-ся с пом. прямоугольника. Изобр-ся только те объекты, α непоср-но участвуют во взаимод-и. Ключевым моментом явл-ся динамика взаимод-я объектов во времени. Поэтому диаграмма имеет 2 условные временные оси: сверзу вниз и слева направо. Сообщ-я изобр-ся с пом. горизонтальных стрелок по времени своего возникн-я.
2)линия жизни объекта – изобр-ся пунктирной вертик. линией и ассоц-ся только с 1 объектом. Исп-ся для обознач-я того периода, в теч. α объект существует и может участвовать во взаимод-и. Отд. объекты, выполнив свою роль в системе, м. б. уничтожены, чтобы освободить занимаемые ими ресурсы. Не обязательно создавать все объекты в нач. момент времени. Они могут созд-ся позже, экономя ресурсы системы. В этом случае объект изобр-ся ниже созданных в нач. момент времени.
3)фокус управления В процессе функц-я системы объекты могут нах-ся в акт. состоянии, выполняя опред. действия или в режиме пассивного ожиданиясообщения от других объектов. Для выделения акт-ти объекта исп. фокус упр-я. Если объект нах-ся в акт. сост. на протяж. всей жизни, линия жизни м.б. заменена на фокус упр-я.
Инициатором взаимод-я в системе чаще всего выст. внешний польз-ль (актёр), и его фокус упр-я будет сущ-ть в системе постоянно.

43. Построение диаграммы последовательности средствами UML. Виды сообщений

Сообщения – предст. собой законченный фрагмент инф-я, α отправл-ся одним объектом другому. При этом приём сообщ-я инициирует вып-е опред-х действий тем объектом, которому оно отправлено.
а)—> наиб.распр. Предполагает перевод объекта, α посылается, в акт. состояние.
б)—> не сопров-ся получением фокуса упр-я
в)----> исп-ся для изобр-я возврата после вып-я необх. действий.
Сообщение может вызывать рекурсию.
Сообщ-е может иметь неα аргументы или параметры, в зав-ти от значений α м.б. получен результат. Знач-я параметров могут сод-ть логич. выр-я, образуя ветвления осн. потока упр-я.
Стереотипы сообщений:
«call» (вызвать) - сообщение, требующее вызова операции или процедуры принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у самого пославшего это сообщение объекта;
«return» (возвратить) - сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;
«create» (создать) - сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может получить фокус управления, а может и не получить его;
«destroy» (уничтожить) - сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;
«send» (послать) - обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.
Пример: моделир-е процесса телефонного разговора. Объекты: абоненты а,b, аппараты c, d, коммутатор, разговор.

44. Построение диаграммы компонентов средствами UML.

Полный проект предст. собой совок-ть моделей не только концепт. и логич. представления, но и физического, причём все они д.б. согласованы между собой. В UML для физич. представления моделей исп-ся диаграммы реализации, к к-рым отн-ся диаграммы кмпонентов и развёртывания.
Диагр. компонентов – диагр., представляющая состав и завис-ти между компонентами прогр. системы.
В наиб. общем случае компонент соотв-ет отдельному модулю (отд. файл).
Компонент предст. физически соотв. часть системы, к-рая обеспечивает реализацию классов и отношений.

Отдельный компонент м.б. представлен на уровне типа (запис-ся только имя компонента) или на уровне отдельного экземпляра (имя:тип).
В кач-ве имён компонентов принято исп-ть имя физич. файла, к-рое соотв-ет dll, веб-странице, файлу справки, БД или файлу с исх. текстом.
Способы спецификации разл. видов компонентов:
1) графич. стереотипы
2) исп-е мпец. слова перед именем компонента
<<file>> <<document>> <<source>> <<table>> <<exe>>
Интерфейсы обесп. совместимость разл. версий, а также возм-ть вносить существ. изменения в одни части программы, не изменяя другие.

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

Компонент-экземпляр

Рекомендации:
1) необх. решить, из каких физич. частей или файлов будет состоять прогр. система.
2) дополнить модель интерфейсами и схемами БД
3) установить и нанести взаимосвязи, отношения
Как правило, для каждого компонента при его создании опр-ся разл. св-ва: стереотипы, язык прогр-я, реализуемые классы.

45. Построение диаграммы развертывания средствами UML.

Диаграммы развёртывания (ДР, deployment diagram) прим-ся для представл-я общ. конфигурации разр. прогр. системы, содержит размещение компонентов по опред. узлам системы. При этом на ней предст-ся только те компоненты, α явл-ся исполнимыми файлами или динамич. библиотеками.
ДР содержит граф. изобр-я процессоров, устр-в и связей между ними.
Узел – физически сущ-й эл-т системы, α может обладать вычислит. ресурсами или явл-ся аппар. устр-вом (1 или неск. процессоров, объём памяти, принтер)
Узел м.б. представлен на Ур. класса или отд. экземпляра. Может добавл-ся доп. инф-я. Иногда бывает необх. явно указать компоненты, α размещ-ся на отд. узле. Они м.б. указаны именами или графически. Дополнительно могут добавляться текстовые стереотипы, α специф-ют назначение (“printer”). Разработчиками м.б. предложены граф. стереотипы, α улучшают наглядность диаграммы (Интернет – облачко, раб. станция – изобр-е компа)
Для узлов различ-ся 2 вида: 1) 2)
1)ресурсоёмкий узел (с процессором и памятью, α необх. для вып-я компонентов)
2)устройство
Отношения

а)соединения
указ. на необх-ть орг-и физич. канала для обмена инф-ей между соотв. узлами. Хар-р соединения м.б. специфицирован с пом. примечания или помеченного значения.
б) зависимости - - - - - -> устан-ся между узлом и размещ-ми на нём компонентами.
ДР исп-ся не только для создания прогр. кода, но и описания прогр. средств.
Рекомендации:
1)разработка ДР начин-ся с опред-я всех аппар. устр-в, α необх. для выполн-я системой всех ф-ций.
2)специфицир-ся все узлы системы, требующие ресурсы и память для вып-я процесса
3)размещ-я все исполняемые компоненты по узлам
ДР строится для след. видов приложений:
1)прил-я, реализ-е технологию клиент-сервер. Для них хар-но чёткое распр-е полномочий между клиентскими раб. станциями и сервером БД.
2)неоднородные распр-е системы (исп-е разл. ОС, аппар. платформы и разл. виды периф. устройств)
3)системы реального времени со встроенными микропроцессорами, α могут функц-ть автономно.
Этот вид диаграмм явл-ся заключит. этапом объектно-ориент. проектирования, но может исп-ся и на более ранних этапах.

46. Операторы определения данных языка SQL

Data Definition Language (DDL) (язык определения данных) - это семейство комп языков, использ-х в комп. прогах для описания структуры БД.
На текущий момент наиб популярным языком DDL является SQL, использ-й для получ и манипул данными в РСУБД.
Ф-ии языков DDL опред-ся первым словом в предложении (часто называемом запросом), кот почти всегда явл глаголом. В случае с SQL эти глаголы - create, alter, drop. Это превращает природу языка в ряд обязат команд к БД.
Существует стандарт SQL, установ. ANSI, но производит. СУБД часто предлаг. свои собств. "расширения" языка.
Соотв. операторы предназн для создания, удаления, изменения основных объектов модели данных реляционных СУБД: таблиц, представлений, индексов.
CREATE TABLE <имя> - создание новой таблицы в БД.
DROP TABLE <имя> - удаление таблицы из БД.
ALTER TABLE <имя> - изменение структуры существующей таблицы или ограничений целостности, задаваемых для данной таблицы.

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

47. Операторы манипулирования данными языка SQL.

Оператор select
Позволяет производить выборки данных, преобразовывать полученные результаты, реализует сложные условия выбора. Формат оператора:
Select [ distinct | all {* | <значение 1> [, <значение 2>… ]}from <таблица1 > [, <таблица2 >… ][ where<условие_поиска>][ groupbyстолбец [collatecollation][, столбец 1 [collatecollation]…][ having<условия_поиска>][ union <оператор_select>][ plan <план_выполнения_запроса>][ order by <список_столбцов>];
Внутреннее соединение таблиц
При сравнении значения столбца одной таблицы со значением столбца другой таблицы условие поиска имеет вид: <имя_столбца_табл1> <оператор> <имя_столбца_табл2>.
Определение сортировки order by
Order by <список_столбцов>.
Устранение повторяющихся записей
Ключевое слово Distinct. Повторяющимися считаются записи, содержащие идентичные значения во всех столбцах результирующего HД.
Расчет вычисляемых столбцов
Для расчета вычисляемых столбцов результирующего HД используются арифметические выражения: Select [distinct | аll ] { * | <столбец 1> [, <выражение 1>… ]} from <таблица 1> [, <таблица 2>… ];
Агрегатные функции
count(<выражение>) – подсчитывает число вхождений значения выражения во все записи результирующего HД; sum(<выражение>) – суммирует значение выражения;
avg(<выражение>) – находит среднее значение; max(<выражение>) – определяет максимальное значение; min(<выражение>) – определяет минимальное значение.
Группировка записей
Для группы записей столбца, характеризующие одинаковые значения можно получить агрегированные значения (min, max, avg). При этом один из столбцов представляется агрегирующей функцией, и предложение group by столбец [, столбец…] перед предложением where.
Внешние соединения
Определяются в предложении from согласно спецификации:
Select { * | <значение 1> [, <значение 2>… ]}from <таблица 1> <вид соединения > join < таблица 2> on <условие поиска>;
Внешнее соединение отличается от внутреннего тем, что в результирующий HД включаются записи ведущей таблицы соединения, которые объединяются с пустым множеством записей другой таблицы. Какая из таблиц будет ведущей, определяет вид соединения (left – левое внешнее соединение, ведущая таблица 1; right – правое внешнее соединение, ведущая таблица 2; full – полное внешнее соединение).
В случае полного внешнего соединения ведущими являются обе таблицы. В результирующий HД вкладываются все записи обеих таблиц согласно алгоритму:
1) если для записи таблицы 1 имеются записи таблицы 2, удовлетворяющие условию соединения, то в результирующий HД включаются все комбинации записей таблиц 1 и 2;
2) иначе, в HД включается запись из таблицы 1, соединенная с пустой записью таблицы 2;
3) пункты 1 и 2 повторяются для таблицы 2 и таблицы 1.

обозначение	наименование	характеристика
PS	Presentation Services (средства представления)	Обслуживает пользовательский ввод и отображает то, что сообщает ему компонент логики представления (PL), с использованием соответствующей программной поддержки
PL	Presentation Logic (логика представления (диалога))	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, щелчке на кнопке или выборе пункта в списке
BL	Business Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которое должно выполнить приложение
DL	Data Logic (логика управления данными)	Операции с БД (реализуемые SQL-операторами), которые нужно выполнить для реализации прикладной логики управления данными
DS	Data Services (операции с БД)	Действия СУБД, реализующие логику управления данными, такие как манипулирование данными, определение данных, фиксация или откат и т. п. СУБД обычно компилирует SQL-предложения
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД и других компонентов. Обычно являются функциями ОС

Типы перекрестковОбозначение	Наименование	Смысл в случае слияния стрелок (Fan-in Junction)	Смысл в случае разветвления стрелок (Fan-out Junction)
	Asynchronous AND	Все предшествующие процессы должны быть завершены	Все следующие процессы должны быть запущены
	Synchronous AND	Все предшествующие процессы завершены одновременно	Все следующие процессы запускаются одновременно
	Asynchronous OR	Один или несколько предшествующих процессов должны быть завершены	Один или несколько следующих процессов должны быть запущены
	Synchronous OR	Один или несколько предшествующих процессов завершены одновременно	Один или несколько следующих процессов запускаются одновременно
	XOR (Exclusive OR)	Только один предшествующий процесс завершен	Только один следующий процесс запускается

А		В
Параметр 1	Параметр 2	Параметр 1	Параметр 2
А1, А4	В1, В2	А1, А5	В1, В3

АU В
Параметр 1	Параметр 2
А1, А4, А5	В1,В2, В3

A.X	A.Y	B.X	B.Y
А1	В1	А1	В1
А1	В1	А5	В3
А1	В1	А6	В6
А1	В1	А3	В3
А2	В2	А1	В1
А2	В2	А5	В5

A.X	A.Y	B.X	B.Y
А1	В1	А1	В1
А1	В1	А5	В3
А1	В1	А6	В6
А1	В1	А3	В3
А2	В2	А1	В1
А2	В2	А5	В5

В		C	C1	C2
S#	P#	P#	P#	P1
S1	P1	P1	P2	P2
S1	P2		P4	P3
S1	P3			P4
S1	P4			P5
S1	P5			P6
S1	P6
S2	Р1
S2	Р2
S3	Р2
S4	P2
S4	P4
S4	P4

A:=B/C	A:=B/C1	A:=B/C2
S#	S#	S#
S1	S1	S1
S2	S4

A.X	A.Y	B.X	B.Y
А1	В1	А1	В1
А1	В1	А5	В3
А1	В1	А6	В6
А1	В1	А3	В3
А2	В2	А1	В1
А2	В2	А5	В5

В		C	C1	C2
S#	P#	P#	P#	P1
S1	P1	P1	P2	P2
S1	P2		P4	P3
S1	P3			P4
S1	P4			P5
S1	P5			P6
S1	P6
S2	Р1
S2	Р2
S3	Р2
S4	P2
S4	P4
S4	P4