Файл: Методические указания по организации практических занятий и самостоятельной работы по мдк. 02. 01 Технология разработки программного обеспечения.docx

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

Связь соединяется с ассоциируемыми сущностями линиями. Возле каждой сущности на линии, соединяющей ее со связью, цифрами указывается класс принадлежности.

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

Связь также может иметь ключевой атрибут. В ряде случаев для удобства организации связей в состав атрибутов сущности вводится искусственный ключ (обычно число). Ключевой атрибут (набор атрибутов) на диаграмме отмечается двумя линиями снизу, внешние ключи отмечаются одной линией. В таблице представлены основные элементы, используемые для формирования ER-диаграммы в нотации Чена.
Таблица 1 – Элементы ER-диаграммы в нотации Чена

Элемент диаграммы	Описание
	Сущность
	Связь
	Атрибут
	Первичный ключ
	Внешний ключ

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

Пример ER-модели в нотации Чена для «Университет».



Понятие информационной модели. Уровни информационной модели

Методология IDEF1X – язык для семантического моделирования данных, основанный на концепции «сущность-связь».

---

Различают два уровня информационной модели: логический и физический.

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

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

• 
  диаграмма сущность-связь (Entity-Relationship Diagram (ERD);
  
• 
  модель данных, основанная на ключах (Key Based Model (KB);
  
• 
  полная атрибутивная модель (Fully Attributed Model (FA).
  

1. 
   Физическая модель отражает физические свойства проектируемой базы данных (типы данных, размер полей, индексы). Параметры физической информационной модели зависят от выбранной системы управления базами данных (СУБД).
   

Основные элементы информационной модели логического уровня

Сущности и атрибуты

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



Любая сущность характеризуется набором атрибутов (свойств).

Атрибут сущности – характеристика сущности, то есть свойство реального объекта. Например, на рисуке атрибутами сущности «Студент» являются «ID студента», «Фамилия», «Имя», «Отчество», «Дата поступления» и «Номер билета».

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

Первичный ключ (Primary Key, PK). Каждая сущность должна обладать атрибутом или комбинацией атрибутов, чьи значения однозначно определяют каждый экземпляр сущности. Эти атрибуты образуют первичный ключ сущности.

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

---

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

Отношения в IDEF1X-модели

При построении информационной модели различают следующие типы отношений между сущностями: идентифицирующее, не идентифицирующее, не специфическое (многие-ко-многим) и отношения категоризации.

Мощность отношения служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Нормализация данных

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

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

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

Третья нормальная форма (3 НФ). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть зависимости между не ключевыми атрибутами).

Пример модели логического уровня



Пример модели физического уровня



Разработка и оформление технического задания

Для обеспечения потребностей по разработке программного обеспечения (ПО) ИС необходимо взаимосвязанное совершенствование технических решений, технологий проектирования и программирования

---

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

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

Использование стандартов при разработке ПО ИС позволит обеспечить:

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

Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем (АС) – обобщенные, но воспринимаемые как весьма жесткие по структуре жизненного цикла (ЖЦ) и проектной документации. Наиболее популярными можно считать ГОСТ 34.601-90 (Автоматизированные системы. Стадии создания) и ГОСТ 34.602-89 (Техническое задание на создание АС). Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. способствует более полной и качественной стыковке разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС.

В последние годы в стране идет интенсивная работа по гармонизации государственных стандартов Российской Федерации с международными стандартами ISO в области создания нормативной базы управления жизненным циклом программных средств и информационных систем. В основе стандартизации - ГОСТ Р ИСО/МЭК 12207-99 "Информационная технология. Процессы жизненного цикла программных средств", который является аутентичным переводом международного стандарта ISO/IEC 12207: 1995-08-01.

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

ТЗ содержит основные технические требования, предъявляемые к изделию и исходные данные для разработки; в ТЗ указываются назначение объекта, область его применения, стадии разработки документации, её состав, сроки исполнения и т. д., а также особые требования, обусловленные спецификой самого объекта либо условиями его эксплуатации. Как правило, ТЗ составляют на основе анализа результатов, полученных в ходе предпроектного обследования.

---

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:

А) Обеим сторонам:

• 
  представить готовый продукт;
  
• 
  выполнить проверку готового продукта по пунктам (приёмочное тестирование – проведение испытаний);
  
• 
  уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний).
  

Б) Заказчику:

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

В) Исполнителю:

• 
  правильно понять суть задачи, показать заказчику «технический облик» будущего программного изделия или АС;
  
• 
  спланировать выполнение проекта и работать по намеченному плану;
  
• 
  отказаться от выполнения работ, не указанных в ТЗ.
  

Структура технического задания

Титульный лист

Содержание

1 ОБЩИЕ СВЕДЕНИЯ

1.1 Полное наименование системы и ее условное обозначение

1.2 Номер договора

1.3 Наименования организации-заказчика и организации-исполнителя

1.4 Перечень документов, на основании которых создается система

1.5 Плановые сроки начала и окончания работы по созданию системы

1.6 Порядок оформления и предъявления заказчику результатов работ по созданию системы

1.7 Перечень нормативно-технических документов, методических материалов, использованных при разработке ТЗ

1.8 Определения, обозначения и сокращения

2 НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

2.1 Назначение системы

2.2 Цели создания системы

3 ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

3.1 Краткие сведения об объекты автоматизации или ссылки на документы, содержащие такую информацию

3.2 Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды

4 ТРЕБОВАНИЯ К СИСТЕМЕ

4.1 Требования к системе в целом

4.2 Требования к функциям, выполняемым системой

4.3 Требования к видам обеспечения

4.3.1 Требования к математическому обеспечению системы

4.3.2 Требования информационному обеспечению системы

4.3.3 Требования к лингвистическому обеспечению системы

4.3.4 Требования к методическому обеспечению системы

4.3.5 Требования организационному обеспечению системы

---