Международный стандарт ISO/IEC 12207, назначение, область применения, ограничения

Международный стандарт ISO/IEC 12207, назначение, область применения, ограничения

Назначение

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

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

Область применения.

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

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

· не предназначен для программирования продуктов "на полку", не объединяемых в продукт, предназначенный для поставки.

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

Ограничения

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

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

· ни один из списков задач нельзя рассматривать как исчерпывающий

Международный стандарт ISO/IEC 12207, структура

Процессы жизненного цикла

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

Выделяют 5 основных процессов, 8 вспомогательных процессов и 4 организационных процессов.

Согласно стандарту, структура жизненного цикла основывается на трех группах процессов:

· Основные процессы жизненного цикла (приобретение, поставка, разработка, эксплуатация, сопровождение)

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

· Организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла, обучение)

4. Международный стандарт ISO/IEC 12207, основные участники процесса (пример)

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

· покупатель,

· поставщик,

· разработчик,

· персонал эксплуатации,

· персонал сопровождения программных изделий.

(всмысле пример???)

Действия Процесса Поставки

· Инициирование (начало);

· Подготовка ответа;

· Заключение контракта;

· Планирование;

· Выполнение и контроль;

· Оценка и проверка;

· Поставка и завершение.

 

Процесс Разработки

Процесс Разработки содержит действия и задачи разработчика.

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

Разработчик:

· управляет Процессом Разработки на проектном уровне следующим за Процессом Управления (7.1);

· устанавливает инфраструктуру после Процесса создания Инфраструктуры (7.2);

· приспосабливает процесс для проекта после Процесса Настройки (Приложение А);

· управляет процессом на организационном уровне, после Процесса Усовершенствования (7.3) и Процесса Обучения (7.4),

· Когда разработчик является поставщиком разрабатываемого продукта, разработчик выполняет Процесс Поставки (5.2).

Процесс Разработки состоит из действий:

· Реализация процесса.

· Анализ системных требований.

· Проектирование архитектуры системы.

· Анализ требований программного обеспечения.

· Архитектура программного обеспечения.

· Детальное конструирование программного обеспечения.

· Кодирование и тестирование программного обеспечения.

· Интеграция программного обеспечения.

· Квалификационные испытания программного обеспечения.

· Интеграция системы.

· Квалификационные испытания системы.

· Установка программного обеспечения.

· Поддержка принятия программного обеспечения.

Процесс Функционирования

· Процесс функционирования содержит действия и задачи оператора.

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

· Оператор:

· управляет Процессом Функционирования на проектном уровне следующим за Процессом Управления (п.7.1);

· устанавливает инфраструктуру под процесс следующий за Процессом Создания Инфраструктуры (п.7.2);

· приспосабливает процесс для проекта после Процесса Настройки (Приложение А);

· управляет процессом на организационном уровне после Процесса Усовершенствования (п.7.3) и Процесса Обучения (п.7.4).

· Когда оператор является поставщиком операционного обслуживания, оператор включает Процесс Поставки (п.5.2).

Действия Процесса Функционирования:

· Реализация процесса.

· Операционное тестирование.

· Функционирование системы.

· Поддержка пользователя.

Модель SEI СММ

Модель SEI СММ

Менеджмент качества программных проектов основывается на знаниях из трех источников:

o  программный инжиниринг (ACM, IEEE),

o  менеджмент проекта (PMI)

o  качество (ASQ).

Институт программного инжиниринга (SEI, Software Engineering Institute) в Университете Карнеги Мэллон à Модель зрелости функциональных возможностей (Capability Maturity Model, СММ),

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

Модель СММ

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

Каждый уровень зрелости разбивается на несколько ключевых областей процесса (какие действия еще необходимо предпринять) Каждая ключевая область процесса (Key process area, KPA) определяет набор взаимосвязанных действий (для оптимизации этого процесса)

Уровни СММ

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

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

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

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

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

V-ОБРАЗНАЯ МОДЕЛЬ SLCM

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

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

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

Разновидность каскадной модели

 

↓	Планирование проекта и требований	← →	Производство, эксплуатация и сопровождение
↓	Анализ требований продукта и спецификаций	← →	Системное и приемочное тестирование	↑
↓	Разработка архитектурного проекта на высшем уровне	← →	Интеграция и тестирование	↑
↓	Детализированная разработка проекта	← →	Модульное тестирование	↑
	Кодирование			↑

 

ФАЗЫ V-ОБРАЗНОЙ МОДЕЛИ

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

· анализ требований к продукту и его спецификации — анализ существующей на данный момент проблемы с ПО, завершается полной спецификацией ожидаемой внешней линии поведения создаваемой программной системы;

· архитектура или проектирование на высшем уровне — определяет, каким образом функции ПО должны применяться при реализации проекта;

· детализированная разработка проекта — определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;

· разработка программного кода — выполняется преобразование алгоритмов, определенных на этапе детализованного проектирования, в готовое ПО;

· модульное тестирование — выполняется проверка каждого закодированного модуля на наличие ошибок;

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

· системное и приемочное тестирование — выполняется проверка функционирования программной системы в целом (полностью интегрированная система), после помещения в ее аппаратную среду в соответствии со спецификацией требований к ПО.

· производство, эксплуатация и сопровождение — ПО запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок;

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

Быстрая разработка приложений (RAD) (преимущества, недостатки, область применения)

Rapid Application Development, RAD

В1980г. компания IBM начала использовать метод быстрой разработки приложений (Джеймс Мартин).

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

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

Характерной чертой RAD является: короткое время перехода от определения требований до создания полной системы.

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

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

Факторы:

· использование мощных инструментальных средств разработки,

· высокий уровень фактора повторного использования,

· осмысленные и выделенные ресурсы.

Этапы RAD

планирования требований — сбор требований (метод совместного планирования требований - Joint requirements planning, JRP), который представляет собой структурный анализ и обсуждение имеющихся коммерческих задач;

пользовательское описание — совместное проектирование приложения (Joint application design, JAD);

конструирования ("до полного завершения") — эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генераторов кода, экранных генераторов и других типов производственных инструментальных средств;

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

Преимущества RAD

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

· требуется меньшее количество специалистов, т.к. специалисты хорошо владеют предметной областью;

· благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика;

·  в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

· основное внимание переносится с документации на код, причем при этом справедлив принцип "получаете то, что видите" (What you see is what you get, WYSIWYG);

·  в модели используются современные методы моделирования данных;

· + достоинства структурной эволюционной модели быстрого прототипирования.

Недостатки RAD

·  пользователь должен всегда принимать участие на всех этапах разработке;

· необходимо достаточное количество высококвалифицированных и хорошо обученных разработчиков;

· использование модели может оказаться неудачным в случае, если отсутствуют пригодные для повторного использования компоненты;

· жесткие временные ограничения;

· существует риск, что работа над проектом никогда не будет завершена;

Область применения RAD

· в системах, которые поддаются моделированию (основанных на использовании компонентных объектов), а также в масштабируемых системах;

· в системах, требования для которых в достаточной мере хорошо известны;

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

· при выполнении проектов, разработка которых должна быть выполнена в сокращенные сроки;

· когда пригодные к повторному использованию части можно получить из автоматических хранилищ программных продуктов;

· в системах, которые предназначены для концептуальной проверки, являются некритическими или имеют небольшой размер;

· когда затраты и соблюдение графика не являются самым важным вопросом;

· в системах, в которых не требуются достижение высокой производительности, особенно достигаемая посредством использования настройки интерфейсов;

· когда команде, работающей над проектом, знакома предметная область

Из ТИПСА:

Основные принципы методологии RAD

· Используется итерационная (спиральная) модель разработки.

· Полное завершение работ на каждом этапе ЖЦ не обязательно

· Обеспечивается тесное взаимодействие с заказчиками и будущими пользователями

· Применяются case средства и средства быстрой разработки

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

· Используются прототипы, позволяющие выяснить и реализовать потребности конечного пользователя

· Тестирование и разработка проекта осуществляется одновременно с разработкой

· Разработка ведется многочисленной командой

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

Ограничения методологии RAD

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

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

Неприемлема для разработки систем, от которых зависит безопасность людей (система управления транспортом)

Планирование следующей фазы

· oИнтеграция расширенных операционных возможностей, активация и учебная программа

· oCSCI- интеграция и учебная программа активации узлового тестирования

· oПланирование перехода на фазе проектирования и разработки проекта

· oПланирование проекта и процесса инжиниринга

· разработка плана проекта,

· oразработка плана менеджмента конфигурацией,

· oразработка плана тестирования

· oразработка плана установки программного продукта

 

Доставка

oПервая версия и первоначальная пригодность для эксплуатации (Initial operational capability, IOC)

oВерсия, получаемая в результате проведения пользователям приемочных испытаний, сдается перед наступлением стадии конечной пригодности для эксплуатации (Final operational capability, FOC),

Преимущества спиральной модели

· пользователь "видит" систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;

· обеспечивается определение непреодолимых рисков без особых дополнительных затрат;

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

· она обеспечивает разбиение большого потенциального объема работы по разработке продукта на небольшие части, в которых сначала реализуются решающие функции с высокой степенью риска;

· в модели предусмотрена возможность гибкого проектирования (преимущества каскадной модели и разрешены итерации);

· реализованы преимущества инкрементной модели;

· обратная связь по направлению от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели;

· oпроисходит усовершенствование административного управления, что достигается путем выполнения обзора в конце каждой итерации;

· oповышается продуктивность благодаря использованию пригодных для повторного использования свойств;

· oповышается вероятность предсказуемого поведения системы с помощью уточнения поставленных целей;

· oможно выполнять частую оценку совокупных затрат, а уменьшение рисков связано с затратами

· Недостатки спиральной модели

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

· oмодель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками, менеджерами и заказчиками;

· oсерьезная нужда в высокопрофессиональных знаниях для оценки рисков;

· oспираль может продолжаться до бесконечности;

· oбольшое количество промежуточных стадий может привести к необходимости в обработке внутренней дополнительной и внешней документации;

· при выполнении действий на этапе вне процесса разработки возникает необходимость в переназначении разработчиков;

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

· oотсутствие хорошего средства или метода прототипирования может сделать использование модели неудобным;

· oв производстве использование спиральной модели еще не получило такого широкого масштаба, как применение других моделей

Интегрированная структурная модель (расширенная DFD)

Интегрированная структурная модель (расширенная DFD)

•Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - для этой цели используются собственно диаграммы потоков данных DFD, дополненные словарями данных и спецификациями процессов нижнего уровня;

•Диаграммы, моделирующие данные и их взаимосвязи, - для этой цели используются диаграммы «сущность-связь» ERD (Entity-Relationship Diagrams);

•Диаграммы, моделирующие поведение системы, - для этой цели используются диаграммы переходов состояний STD (State Transition Diagrams).

DFD (Data Flow Diagrams)

• DFD (Data Flow Diagramming) - это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ.

• Сфера применения DFD находится в области моделирования информационных потоков организации. В этой нотации моделируется не последовательность работ, а именно потоки информации (данных) между работами и объектами, которые используют, хранят или "рождают" эти данные.

 

//напоминание из лекции: отчет – это документ, на основ которого формируются управленческие решения

Базовая нотация DFD.

· •Поток данных

· •Процесс

· •Накопитель

· •Внешняя сущность

Поток данных (Data flow)

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

· •Потоки на диаграммах обычно изображаются именованными стрелками (при этом имя потока отражает его содержимое), ориентация которых указывает направление движения информации

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

Процесс (Process)

· •Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.

· •Имя должно содержать глагол в неопределенной форме с последующим дополнением (например, ВЫЧИСЛИТЬ МАКСИМАЛЬНУЮ ВЫСОТУ) или отглагольное существительное (ВЫЧИСЛЕНИЕ МАКСИМАЛЬНОЙ ВЫСОТЫ).

Накопитель данных (Data store)

· •Позволяет на определенных участках определять данные, которые будут сохраняться вне процессов.

· •Информация, которую он содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке.

· •Имя накопителя должно идентифицировать его содержимое и быть существительным во множественном числе.

· •При этом не уточняется способ помещения и извлечения данных в накопитель, нас не интересует, происходит ли извлечение данных для чтения (копирования) или для изъятия и другие подобные вопросы

Внешняя сущность (External Entity)

· •Сущность вне контекста системы, являющаяся источником или приемником системных данных, например ЗАКАЗЧИК, ПОСТАВЩИК, СКЛАД ТОВАРОВ.

· •Определение некоторого объекта в качестве внешней сущности указывает на то, что он находится за пределами анализируемой системы.

· •Предполагается, что такие объекты не должны участвовать ни в какой обработке.

· •Внешняя сущность располагается только на контекстной диаграмме DFD

Информационный канал

· •Слияние, состоящее из нескольких детализированных (структурированных) потоков данных.

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

Преимущества DFD

Преимущества DFD

CASE Consulting Group:

DFD – 90%

SADT (IDEF0) – 10%

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

К преимуществам методики DFD относятся:

· возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

· возможность проектирования сверху вниз, что облегчает построение модели "как должно быть";

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

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

 

Разработка структурной функциональной модели бизнес-системы (DFD).

 

Хм. А не кажется ли вам что это в вопросе выше???!

ERD - модель. Сущности.

Сущности

• СУЩНОСТЬ представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками.

•Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

–обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);

–использование этой информации различными приложениями.

 

Отношения

• ОТНОШЕНИЕ в самом общем виде представляет собой связь между двумя и более сущностями.

•Именование отношения осуществляется с помощью грамматического оборота глагола (ИMEET, ОПРЕДЕЛЯЕТ, МОЖЕТ ВЛАДЕТЬ и т.п.).

 

Сильная сущность

• Сильный тип сущности - тип сущности, существование которого не зависит от какого-то другого типа сущности. Называют также родительскими (parent), сущностями-владельцами (owner) или доминантными (dominant)

• Сильная сущность представляет независимые данные, которые всегда присутствуют в системе. При этом отношения с другими сущностями могут как существовать, так и отсутствовать.

Слабая сущность

• Слабый тип сущности - тип сущности, существование которого зависит от какого-то другого типа сущности. Иногда называют дочерними (child), зависимыми (dependent) или подчиненными (subordinate)

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

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

 

Описание типов отношений

Неограниченное (обязательное) отношение представляет собой безусловное отношение, т.е. отношение, которое всегда существует до тех пор, пока есть относящиеся к делу сущности.

• Ограниченное (необязательное) отношение представляет собой условное отношение между сущностями.

• Существенно-ограниченное отношение используется, когда соответствующие сущности взаимно зависимы в системе.

Атрибуты:

Атрибут - свойство типа сущности или типа связи

Домен атрибута - набор значений, которые могут быть присвоены к атрибуту.

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

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

Однозначный атрибут - атрибут, который содержит одно значение для одной сущности

Многозначный атрибут - атрибут, который содержит несколько значений для одной сущности

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

Ключи

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

• Первичный ключ Потенциальный ключ, который выбран в качестве первичного ключа.

• Составной ключ Потенциальный ключ, который состоит из двух или больше атрибутов.

 

ERD - модель. Связи

 

СВЯЗИ

•Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.

• Значение связи характеризует ее тип и, как правило, выбирается из следующего множества:

 

{"0 или 1", "0 или более", "1", "1 или более", "p:q" (диапазон)}.

Типы связей

Тип связи - осмысленная ассоциация между сущностями разных типов.

•Связь - ассоциация между сущностями, включающая по одной сущности из каждого участвующего в связи типа сущности.

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

1.1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.

2.1*n (один-ко-многим). Отношения данного типа являются наиболее часто используемыми.

3.n*m (многие-ко-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и введением новых отношений).

Представление связей на диаграммах

Ромбик имеет двойной контур, если связь соединяет слабую сущность с сильной сущностью, от которой эта слабая сущность зависит.

Степень (degree) связей

•Степень связи - количество сущностей, которые охвачены данной связью.

• Рекурсивная связь Связь, в которой одни и те же сущности участвуют несколько раз и в разных ролях. Рекурсивные связи иногда называются унарными (unary).

•Связям могут присваиваться ролевые имена — для указания назначения каждой сущности — участницы данной связи.

•Ролевые имена могут также использоваться, когда две сущности связаны несколькими связями.

Атрибуты связей

•Атрибуты, могут также принадлежать связям.

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

EER - модель. Категоризация

Категоризация – моделирование одного подкласса со связью, которая охватывает несколько разных суперклассов.

Категоризация – процесс моделирования единственного подкласса (категории) со связью, которая охватывает несколько суперклассов.

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

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

1. Полное и непересекающееся вхождение - сущность должна быть одной и только одной из следуемых категорий. (ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК).

2. Полное и пересекающееся вхождение - сущность может быть одной и только одной из следуемых категорий. (ПРЕПОДАВАТЕЛЕМ является ФИЗИК, или ХИМИК, или МАТЕМАТИК, или преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

3. Частичное и непересекающееся вхождение - сущность должна быть по крайней мере одной из следуемых категорий. Это предполагает в дополнение к 1) задавать следующую ситуацию: ПРЕПОДАВАТЕЛЕМ является одновременно и ФИЗИК и ХИМИК

4. Частичное и пересекающееся вхождение - сущность может быть по крайней мере одной из следуемых категорий. В дополнение к 2) ПРЕПОДАВАТЕЛЕМ является преподаватель какой-либо другой дисциплины (например, ИСТОРИК).

 

Методология проектирования

Методология проектирования

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

o■ Логическое проектирование — преобразование концептуального представления в логическую структуру базы данных, включая проектирование