Лабораторная работа №1

Этапы разработки информационной системы

Стадия технического задания
Цель работы: ознакомиться с правилами написания технического задания.
Лабораторная работа рассчитана на 4 часа.
Подготовка к лабораторной работе
1. Ознакомиться с лекционным материалом по теме «Этапы разработки
программного обеспечения. Постановки задачи» учебной дисциплины
«Проект ПО1»
2. Изучить соответствующие разделы в изданиях [1,4].

Теоретическая часть. Разработка технического задания

Техническое задание представляет собой документ, в котором
сформулированы основные цели разработки, требования к программному
продукту, определены сроки и этапы разработки и регламентирован процесс
приемно-сдаточных испытаний. В разработке технического задания
участвуют как представители заказчика, так и представители исполнителя. В
основе этого документа лежат исходные требования заказчика, анализ
передовых достижений техники, результаты выполнения научно-
исследовательских работ, пред проектных исследований, научного
прогнозирования и т.п.
Порядок разработки технического задания
Разработка технического задания выполняется в следующей
последовательности. Прежде всего, устанавливают набор выполняемых
функций, а также перечень результатов, их характеристики исходных данных.
Затем определяют перечень результатов, их характеристики и способы
представления.
Далее уточняют среду функционирования программного обеспечения:
конкретную комплектацию и параметры технических средств, версию
используемой операционной системы и, возможно, версии и параметры
другого установленного программного обеспечения, с которыми предстоит
взаимодействовать будущему программного продукту.
В случаях, когда разрабатываемое программное обеспечение собирает и
хранит некоторую информацию или включаются в управление каким – либо,
техническим процессом, необходимо также четко регламентировать действия
программы в случае сбоев оборудования и электроснабжения.
Техническое задание должно содержать следующие разделы:
 Введение;
 Наименование и область применения;
 Основание для разработки;
 Технические требования к программе или программному
продукту;
 Технико-экономические показатели;
 Стадии и этапы разработки;
  Порядок контроля и приемки;
 Приложение
В зависимости от особенностей программы или программного изделия,
допускается уточнять разделов, вводить новые разделы или объединить
отдельные из них. При необходимости допускается в техническое задание
включить приложения.
 Примеры технического задания на разработку:
Министерство образования и науки Кыргызской Республики
Кыргызский государственный технический университет
Кафедра программное обучение компьютерных систем

УТВЕРЖДАЮ
Зав. Кафедрой ПОКС
Проф. __________Салиев А.Б.
“____”__________________2025 г.

ПРОГРАММА ВИЗУАЛИЗАЦИИ ОДНОМЕРНОГО

И ДВУМЕРНОГО МАССИВОВ

Техническое задание на лабораторную работу

Листов 3

Руководитель, ст.преп._________Каримова Г.Т.

Исполнитель, студент гр. ПИангл-2-24_________

Бишкек, 2025
1. Введение
Настоящее техническое задание распространяется на разработку программы
вода и вывода одномерного и двумерного массивов при изучении курса
школьной информатики студентами ИИТ.
2. Основание для разработки
2.1. Программа разрабатывается на основе учебного плана кафедры
«ПОКС».
2.2. Наименование работы:
«Программа вывода одномерного и двумерного массива».
2.3. Исполнитель: студенты группы ПИангл-2-24
2.4. Соисполнители: нет.
3. Назначение
Программа предназначена для использования студентами ИИТ при изучении
курса информатики и работе с массивами.
4. Требования к программе или программному изделию
4.1. Требования к функциональным характеристикам
4.1.1. Программа должна обеспечивать возможность выполнения
следующих функций:
• ввод массива вручную;
• хранение массива в памяти;
• автоматическую генерацию массива;
• вывод одномерного и двумерного массива.

4.1.2. Исходные данные:

• размер массива, заданный целым числом;
• массив.
4.1.3. Организация входных и выходных данных
Входные данные поступают с клавиатуры.
Выходные данные отображаются на экране и при необходимости выводятся
на печать.
4.2. Требования к надежности
Предусмотреть контроль вводимой информации.
Предусмотреть блокировку некорректных действий пользователя при работе
с системой.
4.3. Требования к составу и параметрам технических средств.
Система должна работать на ПК.
Минимальная конфигурация:
• тип процессора. Pentium и выше;
• объем оперативного запоминающего устройства 32 Мб и более;
• объем свободного места на жестком диске 40 Мб.
Рекомендуемая конфигурация:
• тип процессора. Pentium II 400;
• объем оперативного запоминающего устройства 128 Мб;
• объем свободного места на жестком диске 60 Мб.
4.4. Требования к программной совместимости.
 Программа должна работать под управлением семейства операционных
систем Win 32 (Windows 95/98/2000/МЕ/ХР и т. п.).
5. Требования к программной документации
5.1. Каждая строка кода должна содержать комментарии.
5.2. Разрабатываемая программа должна включать справочную информацию
о работе программы, описания методов сортировки и подсказки учащимся.
5.3. В состав сопровождающей документации должны входить:
5.3.1. Пояснительная записка на пяти листах, содержащая описание
разработки.
5.3.2. Руководство пользователя.

8. Календарный план работ

№
Название этапа Сроки этапа Чем заканчивается этап
этапа

Изучение предметной 20.01.2025— Предложения по работе

1
области. Постановка задачи. системы.

Разработка программного Программа визуализации

2
модуля массивов

Тестирование и отладка Готовая система

3
модуля.
 Лабораторная работа №2
Тема: Построение модели информационной системы
Цель работы: ознакомиться с этапами построения модели информационной
системы. Лабораторная работа рассчитана на 4 часа.
Подготовка к лабораторной работе
1. Ознакомиться с лекционным материалом по теме «Этапы построения
модели информационной системы. Методы задания спецификации»
учебной дисциплины «Проект ПО1»
2. Изучить соответствующие разделы в изданиях [1,4].
Теоретическая часть
Процесс построения модели разбивается на следующие этапы:
Расчленение множества требований и организация их в основные
функциональные группы.
Идентификация внешних объектов, с которыми система должна быть связана.
- Идентификация основных видов информации, циркулирующей между
системой и внешними объектами.
- Предварительная разработка контекстной диаграммы, на которой основные
функциональные группы представляются процессами, внешние объекты —
внешними сущностями, основные виды информации — потоками данных
между процессами и внешними сущностями.
- Изучение предварительной контекстной диаграммы и внесение в нее
изменений по результатам ответов на возникающие вопросы по всем ее
частям.
- Построение контекстной диаграммы путем объединения всех процессов
предварительной диаграммы в один процесс, а также группирования потоков.
- Формирование DFD первого уровня на базе процессов предварительной
контекстной диаграммы.
- Проверка основных требований по DFD первого уровня.
- Декомпозиция каждого процесса текущей DFD с помощью детализирующей
диаграммы или спецификации процесса.
- Проверка основных требований по DFD соответствующего уровня.
- Добавление определений новых потоков в словарь данных при каждом их
появлении на диаграммах.
- Параллельное (с процессом декомпозиции) изучение требований (в том
числе и вновь поступающих), разбиение их на элементарные и идентификация
процессов или спецификаций процессов, соответствующих этим требованиям.
- После построения двух-трех уровней проведение ревизии с целью
проверки корректности и улучшения восприятия модели.
- Построение спецификации процесса (а не простейшей диаграммы) в
случае, если некоторую функцию сложно или невозможно выразить ком-
бинацией процессов.
Пример построения модели ИС:
В качестве примера создания модели рассмотрим фрагмент проекта
системы, организующей работу банкомата по обслуживанию клиента по его
кредитной карте. Этот пример будет строиться поэтапно, на нем будут
продемонстрированы базовые техники структурного анализа и
проектирования по мере их определения.
На рис. 1 приведена контекстная диаграмма системы с единственным
процессом ОБСЛУЖИТЬ, идентифицирующая внешние сущности КЛИЕНТ и
КОМПЬЮТЕР БАНКА, хранящий информацию о счетах всех клиентов.
Опишем потоки данных, которыми обменивается проектируемая система с
внешними объектами.

Рис.2.1. Контекстная диаграмма «Системы обслужить»

Для банковского обслуживания клиенту необходимо предоставить системе

свою КРЕДИТНУЮ КАРТУ для автоматического считывания с нее
информации (ПАРОЛЬ, ЛИМИТ ДЕНЕГ, ДЕТАЛИ КЛИЕНТА), а также сооб-
щить свои КЛЮЧЕВЫЕ ДАННЫЕ, а именно ПАРОЛЬ и ЗАПРОС НА
банковское обслуживание с позиций клиента, в свою очередь, должно
обеспечить следующее:
выдать СООБЩЕНИЕ, приглашающее клиента ввести КЛЮЧЕВЫЕ
ДАННЫЕ;
выдать клиенту ДЕНЬГИ;
выдать клиенту ВЫПИСКУ по проведенному обслуживанию, включающую
ВЫПИСКУ О ДЕНЬГАХ, ВЫПИСКУ ПО БАЛАНСУ и ВЫПИСКУ ПО ОПЕ-
РАЦИИ, проведенной банком.
Контекстный процесс и КОМПЬЮТЕР БАНКА должны обмениваться
следующей информацией:
ДАННЫЕ ПО СЧЕТУ клиента в банке;
ПРОТОКОЛ ОБСЛУЖИВАНИЯ, включающий информацию об
ОБРАБОТАННОЙ ДОКУМЕНТАЦИИ, изымаемой ДЕНЕЖНОЙ СУММЕ и
ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА.
Контекстный процесс может быть детализирован DFD первого уровня как
показано на рис. 2.2. Эта диаграмма содержит 4 процесса и хранилище
ДАННЫЕ КРЕДИТНОЙ КАРТЫ, которое изображено дважды на диаграмме
с целью избежания пересечений линий потоков данных.

Задание спецификации процессов:

Процесс 1.1 (ПОЛУЧИТЬ ПАРОЛЬ) осуществляет прием и проверку пароля
клиента и имеет на входе/выходе следующие потоки:
внешний выходной поток СООБЩЕНИЕ для информирования клиента о
готовности принять пароль;
входной поток ВВЕДЕННЫЙ ПАРОЛЬ как элемент внешнего потока
КЛЮЧЕВЫЕ ДАННЫЕ;
входной поток ПАРОЛЬ из хранилища ДАННЫЕ КРЕДИТНОЙ КАРТЫ для
проверки вводимого клиентом пароля.
Процесс 1.2 (ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) осуществляет
прием и проверку запроса клиента на проведение необходимой ему
банковской операции и имеет на входе/выходе следующие потоки:
внешний выходной поток СООБЩЕНИЕ для информирования клиента о
своей готовности принять запрос на обслуживание;
входной поток ЗАПРОС НА ОБСЛУЖИВАНИЕ как элемент внешнего потока
КЛЮЧЕВЫЕ ДАННЫЕ;
входной поток ЛИМИТ ДЕНЕГ из хранилища ДАННЫЕ КРЕДИТНОЙ
КАРТЫ для контроля наличия денег на счете клиента.
Процесс 1.3 (ОБРАБОТАТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ) имеет
внешний входной поток ДАННЫЕ ПО СЧЕТУ (из внешней сущности
КОМПЬЮТЕР БАНКА), входной поток ДЕТАЛИ КЛИЕНТА (из хранилища),
а также внешние выходные потоки ВЫПИСКА, ДЕНЬГИ и ПРОТОКОЛ
ОБСЛУЖИВАНИЯ.
Процесс 1.4 (ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ) осуществляет
считывание информации с кредитной карты и имеет на входе внешний поток
КРЕДИТНАЯ КАРТА, а на выходе поток ДАННЫЕ КРЕДИТНОЙ КАРТЫ.
Отметим, что нет необходимости в идентификации последнего потока, т.к.
идентифицировано соответствующее хранилище.
Процессы 1.1, 1.2 и 1.4 являются элементарными, поэтому нет необходимости
в их детализации с помощью DFD уровня 2 (они будут раскрыты с помощью
спецификаций процессов в главе 4). Процесс 1.3 может быть детализирован с
помощью DFD второго уровня как показано на рис. 2.3. Эта диаграмма
содержит 4 элементарных процесса, спецификации которых также будут
приведены в следующих лекциях.

Рис.2.2. Декомпозиция контекстной диаграммы «Системы обслужить»

Задание спецификации подпроцессов:

Процесс 1.3.1 (ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА) осуществляет
обработку внутренней банковской документации по клиенту и имеет входной
поток ДЕТАЛИ КЛИЕНТА и выходной поток ОБРАБОТАННАЯ
ДОКУМЕНТАЦИЯ (часть внешнего потока ПРОТОКОЛ СДЕЛКИ).
Процесс 1.3.2 (РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА) выдает справку по
истории счета клиента и по балансу клиента. Входные потоки — ДЕТАЛИ
КЛИЕНТА и ДАННЫЕ ПО БАЛАНСУ (часть внешнего потока ДАННЫЕ ПО
СЧЕТУ), выходные поток ВЫПИСКА ПО БАЛАНСУ (часть внешнего поток
ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА (часть внешнего потока
ПРОТОКОЛ ОБСЛУЖИВАНИЯ).
Процесс 1.3.3 (ПРИГОТОВИТЬ ДЕНЬГИ КЛИЕНТУ) обеспечивает выдачу
наличных денег и информирование компьютера банка об изъятых из банка
деньгах. Он имеет входные потоки ДЕНЕЖНАЯ СУММА и ДЕТАЛИ
КЛИЕНТА, и выходные потоки ДЕНЬГИ и ДЕНЕЖНАЯ СУММА (часть
потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).
Процесс 1.3.4 (РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА) выдает справку по
истории счета и уведомление по проведенной операции. Входные потоки
ДАННЫЕ ПО СЧЕТУ и ДЕТАЛИ КЛИЕНТА, выходные потоки - ВЫПИСКА
ПО ОПЕРАЦИИ (часть потока ВЫПИСКА) и ДАННЫЕ ПО ИСТОРИИ
ЗАПРОСА (часть потока ПРОТОКОЛ ОБСЛУЖИВАНИЯ).

Рис.2.2. Декомпозиция процесса «Обработать запрос на обслуживание»

Контрольные вопросы:
1. Какую модель мы называем контекстной диаграммой?
2. Как происходит декомпозиция модели?
3. От чего зависит количество уровней при декомпозиции?
 Лабораторная работа №3
Тема: Метод задания спецификации ИС
на структурированном естественном языке
Цель работы: ознакомиться со структурированным естественным языком,
правилами и форматами написания спецификации процесса (СП)
Лабораторная работа рассчитана на 4 часа.
Подготовка к лабораторной работе
1. Ознакомиться с лекционным материалом по теме «Спецификация
процессов с помощью структурированного естественного языка»
учебной дисциплины «Проект ПО1»
2. Изучить соответствующие разделы в изданиях [1,4].
Теоретическая часть
Спецификация процесса (СП) используется для описания
функционирования процесса в случае отсутствия необходимости
детализировать его с помощью DFD (если он достаточно невелик, и его
описание может занимать до одной страницы текста).
Фактически СП представляют собой алгоритмы описания задач,
выполняемых процессами: множество всех СП является полной
спецификацией системы. СП содержат номер и/или имя процесса, списки
входных и выходных данных и тело (описание) процесса, являющееся
спецификацией алгоритма или операции, трансформирующей входные потоки
данных в выходные.
Известно большое число разнообразных методов, позволяющих задать
тело процесса, соответствующий язык может варьироваться от
структурированного естественного языка или псевдокода до визуальных
языков проектирования (типа FLOW-форм и диаграмм Насси-Шнейдермана)
и формальных компьютерных языков.
Независимо от используемой нотации спецификация процесса должна
начинаться с ключевого слова (например, @СПЕЦПРОЦ). Требуемые
входные и выходные данные должны быть специфицированы следующим об-
разом:
@ВХОД = <имя символа данных>
@ВЫХОД = <имя символа данных>
@ВХОДВЫХОД = <имя символа данных>,
где имя символа данных — соответствующее имя из словаря данных.
Эти ключевые слова должны использоваться перед определением СП,
например,
@ВХОД = СЛОВА ПАМЯТИ
@ВЫХОД = ХРАНИМЫЕ ЗНАЧЕНИЯ
@СПЕЦПРОЦ
Для всех СЛОВ ПАМЯТИ выполнить:
Распечатать ХРАНИМЫЕ ЗНАЧЕНИЯ
@
Ситуация, когда символ данных является одновременно входным и выходным,
может быть описана двумя способами: либо символ описывается два раза с
помощью @ВХОД и @ВЫХОД, либо один раз с помощью @ВХОД ВЫХОД.
Иногда в СП задаются пред- и пост-условия выполнения данного
процесса. В пред-условии записываются объекты, значения которых должны
быть истинны перед началом выполнения процесса, что обеспечивает опреде-
ленные гарантии безопасности для пользователя. Аналогично, в случае
наличии пост-условия гарантируется, что значения всех входящих в него
объектов будут истинны при завершении процесса.
Ниже рассматриваются некоторые наиболее часто используемые
методы задания спецификаций процессов.
Структурированный естественный язык
Структурированный естественный язык применяется для читабельного,
строгого описания спецификаций процессов. Он является разумной
комбинацией строгости языка программирования и читабельности
естественного языка и состоит из подмножества слов, организованных в опре-
деленные логические структуры, арифметических выражений и диаграмм. В
состав языка входят следующие основные символы:
глаголы, ориентированные на действие и применяемые к объектам;
термины, определенные на любой стадии проекта ПО (например, задачи,
процедуры, символы данных и т.п.);
предлоги и союзы, используемые в логических отношениях;
общеупотребительные математические, физические и технические термины;
арифметические уравнения;
таблицы, диаграммы, графы и т.п.;
комментарии.
Управляющие структуры языка имеют один вход и один выход. К ним
относятся:
последовательная конструкция:
ВЫПОЛНИТЬ функция 1
ВЫПОЛНИТЬ функция2
ВЫПОЛНИТЬ функция3
конструкция выбора:
ЕСЛИ <условие> ТО
ВЫПОЛНИТЬ функция 1
ИНАЧЕ
ВЫПОЛНИТЬ функция2
КОНЕЦЕСЛИ
итерация:
ДЛЯ <условие> ПОКА <условие> ВЫПОЛНИТЬ
ВЫПОЛНИТЬ функция или функция
КОНЕЦДЛЯ КОНЕЦПОКА
При использовании структурированного естественного языка приняты
следующие соглашения:
Логика процесса выражается в виде комбинации последовательных
конструкций, конструкций выбора и итераций.
Ключевые слова ЕСЛИ, ВЫПОЛНИТЬ, ИНАЧЕ и т.д. должны быть написаны
заглавными буквами.
Слова или фразы, определенные в словаре данных, должны быть написаны
заглавными буквами.
Глаголы должны быть активными, недвусмысленными и ориентированными
на целевое действие (заполнить, вычислить, извлечь, а не модернизировать,
обработать).
5 Логика процесса должна быть выражена четко и недвусмысленно.
Пример спецификации процесса:
Приведем спецификации процессов для рассмотренного выше примера
банковской задачи с использованием структурированного естественного
языка.
Спецификации процесса 1 (ПОЛУЧИТЬ ПАРОЛЬ) для диаграммы,
изображенной на рис. 2.2.
@ВХОД = ВВЕДЕННЫЙ ПАРОЛЬ
@ВХОД = ПАРОЛЬ
@ВЫХОД = СООБЩЕНИЕ
@ВЫХОД = КОРРЕКТНЫЙ ПАРОЛЬ
@СПЕЦПРОЦ 1.1 ПОЛУЧИТЬ ПАРОЛЬ
ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту,
запрашивающее ввод пароля
принять ВВЕДЕННЫЙ ПАРОЛЬ
ДОТЕХПОРПОКА ВВЕДЕННЫЙ ПАРОЛЬ = ПАРОЛЬ или были сделаны три
попытки ввода
КОНЕЦВЫПОЛНИТЬ
ВЫПОЛНИТЬ установить флаг КОРРЕКТНЫЙ ПАРОЛЬ
в случае равенства
@КОНЕЦ СПЕЦФИКАЦИИ ПРОЦЕССА 1.1

Спецификации процессов для примера банковской задачи

Спецификация процесса 1.1 приведена выше
Спецификация процесса 1.2.
@ВХОД = ЛИМИТ ДЕНЕГ
@ВХОД = ЗАПРОС НА ОБСЛУЖИВАНИЕ
@ВЫХОД = ДЕНЕЖНАЯ СУММА
@ВЫХОД = СООБЩЕНИЕ
@ВЫХОД = ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ
@СПЕЦПРОЦ 1.2 ПОЛУЧИТЬ ЗАПРОС НА ОБСЛУЖИВАНИЕ
ВЫПОЛНИТЬ выдать СООБЩЕНИЕ клиенту по вводу
запроса на обслуживание
принять ЗАПРОС НА ОБСЛУЖИВАНИЕ
обновить данные ТРЕБУЕМОЕ ОБСЛУЖИВАНИЕ
 (а именно, ЗАПРОС ДОКУМЕНТАЦИИ, ЗАПРОС ДЕНЕГ,
ЗАПРОС БАЛАНСА, ЗАПРОС НА ОПЕРАЦИЮ)
ЕСЛИ был сделан ЗАПРОС ДЕНЕГ
ТО ВЫПОЛНИТЬ запросить ДЕНЕЖНУЮ СУММУ
выдать требуемую ДЕНЕЖНУЮ СУММУ с учетом того, что она не
должна превышать ЛИМИТ ДЕНЕГ
КОНЕЦЕСЛИ
ДОТЕХПОРПОКА запрашивается продолжение обслуживания или не все
обслуживание было выполнено
КОНЕЦВЫПОЛНИТЬ
@ КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.2
3. Спецификация процесса 1.3.
Спецификация процесса 1.3.1.
@ВХОД = ЗАПРОС ДОКУМЕНТАЦИИ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ
@СПЕЦПРОЦ 1.3.1 = ОБРАБОТАТЬ ДОКУМЕНТАЦИЮ БАНКА
По получении ЗАПРОСА ДОКУМЕНТАЦИИ выдать
ОБРАБОТАННУЮ ДОКУМЕНТАЦИЮ, содержащую
ДЕТАЛИ КЛИЕНТА, КОМПЬЮТЕРУ БАНКА
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.1
Спецификация процесса 1.3.2.
@ВХОД = ДАННЫЕ ПО БАЛАНСУ
@ВХОД = ЗАПРОС БАЛАНСА
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА
@ВЫХОД = ВЫПИСКА ПО БАЛАНСУ
@СПЕЦПРОЦ 1.3.2 РАСПЕЧАТАТЬ БАЛАНС КЛИЕНТА
По получении ЗАПРОСА БАЛАНСА выдать ДАННЫЕ
ПО ИСТОРИИ ЗАПРОСА
Затем выдать ВЫПИСКУ ПО БАЛАНСУ, содержащую
ДАННЫЕ ПО БАЛАНСУ
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.2
Спецификация процесса 1.3.3.
@ВХОД = ДЕНЕЖНАЯ СУММА
@ВХОД = ЗАПРОС ДЕНЕГ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ДЕНЬГИ
@ВЫХОД = ВЫПИСКА О ДЕНЬГАХ
@ВЫХОД = ДЕНЕЖНАЯ СУММА
@СПЕЦПРОЦ 1.3.3 ПРИГОТОВИТЬ ДЕНЬГИ ДЛЯ КЛИЕНТА
По получении ЗАПРОСА ДЕНЕГ выдать ДЕНЬГИ
по значению ДЕНЕЖНОЙ СУММЫ
Выдать ВЫПИСКУ О ДЕНЬГАХ, содержащую ДЕНЕЖНУЮ СУММУ
Передать КОМПЬЮТЕРУ БАНКА информацию о ДЕНЕЖНОЙ СУММЕ
 @КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.3
Спецификация процесса 1.3.4.
@ВХОД = ДАННЫЕ ПО СЧЕТУ
@ВХОД = ЗАПРОС НА ОПЕРАЦИЮ
@ВХОД = ДЕТАЛИ КЛИЕНТА
@ВЫХОД = ВЫПИСКА ПО ОПЕРАЦИИ
@СПЕЦПРОЦ 1.3.4 РАСПЕЧАТАТЬ ОПЕРАЦИЮ КЛИЕНТА
По получении ЗАПРОСА НА ОПЕРАЦИЮ выдать
ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА для специфицирования
ДЕТАЛЕЙ КЛИЕНТА, чтобы получить текущие
ДАННЫЕ ПО СЧЕТУ
Выдать ВЫПИСКУ ПО ОПЕРАЦИИ, содержащую ДАННЫЕ ПО СЧЕТУ
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.3.4
4. Спецификация процесса 1.4.
@ВХОД = УДАЛЕННАЯ КРЕДИТНАЯ КАРТА
@ВХОДВЫХОД = КРЕДИТНАЯ КАРТА
@ВЫХОД = ДАННЫЕ КРЕДИТНОЙ КАРТЫ
@ВЫХОД = ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА
@СПЕЦПРОЦ 1.4 ОБРАБОТАТЬ КРЕДИТНУЮ КАРТУ
ВЫПОЛНИТЬ считать КРЕДИТНУЮ КАРТУ
записать в хранилище ДАННЫЕ КРЕДИТНОЙ КАРТЫ
выдать управляющий поток ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА
по получении управляющего потока УДАЛЕННАЯ КРЕДИТНАЯ КАРТА
удалить КРЕДИТНУЮ КАРТУ
@КОНЕЦ СПЕЦИФИКАЦИИ ПРОЦЕССА 1.4.

Контрольные вопросы:
1. Для чего применяется структурированный естественный язык?
2. С какого ключевого слова начинается спецификация процесса?
3. Что является основой визуального проектрования?
 Лабораторная работа №4
Тема: Анализ входных и выходных структур (Форма Бэкуса – Наура)
Нормализация данных
Цель работы: ознакомиться методами проведения анализа входных и
выходных структур
Лабораторная работа рассчитана на 4 часа.
Подготовка к лабораторной работе
1. Ознакомиться с лекционным материалом по теме «Спецификация
процессов с помощью структурированного естественного языка»
учебной дисциплины «Проект ПО1»
2. Изучить соответствующие разделы в изданиях [1,4].
Теоретическая часть
Первоначально осуществляется анализ хранилища, включающий сравнение
содержимого входных и выходных потоков и создание на основе этого
сравнения варианта схемы хранилища. Перечислим структуры данных,
содержащиеся во входных и выходных потоках:
ВХОДНЫЕ СТРУКТУРЫ ВЫХОДНЫЕ СТРУКТУРЫ
ДАННЫХ ДАННЫХ
вновь_ нанятые адрес_слуащего
дата_найма фамилия
фамилия адрес
таб_номер
адрес подробности_з/пл
должность фамилия
начальная_з/пл таб_номер
текущая _з/пл

уволенные
фамилия история_занятости
таб_номер фамилия
таб_номер
изменение_адреса дата_найма
фамилия история_карьера
таб_номер должность
старый_адрес дата_изменения
новый_адрес история_з/пл
з/пл

изменение_з/пл
фамилия
таб_номер
старая_з/пл
новая_з/пл
дата_изменения
Сравнивая входные и выходные структуры, отметим следующие моменты:
Поле АДРЕС хранит текущий адрес сотрудника, а структура
ИЗМЕНЕНИЕ_АДРЕСА хранит и старый адрес, что не является
необходимым, исходя из выходных потоков.
ИСТОРИЯ_3/ПЛ, наоборот, требует перечень всех окладов сотрудника,
поэтому необходимо иметь набор, состоящий из пар (З/ПЛ, ДАТА), а не
просто СТАРАЯ_3/ПЛ и НОВАЯ_3/ПЛ (как во входном потоке).
Аналогичная ситуация и с ИСТОРИЕЙ_КАРЬЕРЫ. Отметим, что на
диаграмме вообще отсутствует поток, определяющий изменения в должности,
то есть обнаружено серьезное упущение в функциональной модели.
Отметим, что изменение в ДОЛЖНОСТИ обычно (но не всегда)
соответствует изменению в 3/ПЛ.
С учетом этих моментов первый вариант схемы может выглядеть следующим
образом: фамилия
таб_номер
адрес
текущая_з/пл
дата_найма
история_карьеры
должность
дата изменения
история_з/пл
з/пл
дата_изменения
На следующем шаге осуществляется упрощение схемы за счет устранения
избыточности. Действительно, ТЕКУ ЩАЯ_3/ПЛ всегда является последней
записью в ИСТОРИИ_3/ПЛ, а ДАТА НАЙМА содержится в разделах
ИСТОРИЯ_3/ПЛ и ИСТОРИЯ_КАРЬЕРЫ. Кроме того, несколько дат в
последних разделах одни и те же, поэтому целесообразно создать на их основе
структуру ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ и вводить в нее данные при изменении
ДОЛЖНОСТИ и/или 3/ПЛ.
фамилия
таб_номер
адрес
история_з/пл_карьеры
з/пл
должность
дата_изменения
Следующий шаг — упрощение схемы при помощи нормализации
(удаления повторяющихся групп). Единственным способом нормализации
является расщепление данной схемы на две, являющиеся более простыми.
Первая схема содержит ФАМИЛИЮ и АДРЕС (которые, как правило, не
меняются), вторая — каждое изменение З/ПЛ и ДОЛЖНОСТИ. Кроме того,
каждая схема должна содержать ТАБ_НОМЕР — единственный элемент
данных, уникально идентифицирующий каждого сотрудника.
Для идентификации сущностей осталось определить ключевые атрибуты. Для
первой схемы ключевым атрибутом является ТАБ_НОМЕР, для второй —
ключом является конкатенация атрибутов ТАБ_НОМЕР и
ДАТА_ИЗМЕНЕНИЯ, т.к. для каждого сотрудника возможно несколько
записей в схеме ИСТОРИЯ_3/ПЛ_КАРЬЕРЫ.

Концепции и методы нормализации были разработаны Коддом (Codd),

установившим существование трех типов нормализованных схем, названных
в порядке уменьшения сложности первой, второй и третьей нормальной
формой (соответственно, 1НФ, 2НФ и ЗНФ).
Рассмотрим, как преобразовывать схемы к наиболее простой ЗНФ.
история_з/пл_карьеры ( тай номер, дата изменения.
должность, з/пп)
сотрудник (тяб номер, фамилия, адрес)

Для примера построения ЗНФ рассмотрим следующую схему, ключ которой

выбран в предположении, что заказчик не заказывает одну и ту же книгу
дважды в один и тот же день:
заказ_на_книгу (имя заказчика ,дата заказа, ISBN, название, автор, количество,
цена, сумма_заказа)
Согласно Кодду, любая нормализованная схема (схема без
повторяющихся групп) автоматически находится в 1НФ независимо от того,
насколько сложен ее ключ и какая взаимосвязь может существовать между ее
элементами.
Отметим, что в последней схеме атрибуты НАЗВАНИЕ, АВТОР, ЦЕНА
могут быть идентифицированы частью ключа (а именно, ISBN), тогда как
атрибут КОЛИЧЕСТВО зависит от всего ключа (соответственно, полная и
частичная функциональная зависимость от ключа). По определению схема
находится в 2НФ если все ее не ключевые атрибуты полностью
функционально зависят от ключа. После избавления от частичной
функциональной зависимости последняя схема будет выглядеть следующим
образом:
Заказ_на_книгу ( имя заказчика, дата_заказа, ISBN,
количество, сумма_заказа)
книга ( ISBN, автор, название, цена)
Заметим, что возможно упростить ситуацию и дальше: атрибуты
КОЛИЧЕСТВО и СУММА_ЗАКАЗА являются взаимно-зависимыми. По
определению схема находится в ЗНФ если она находится в 2НФ и никакой из
не ключевых атрибутов не является зависимым ни от какого другого не
ключевого атрибута. Поскольку в нашем примере атрибут СУММА_ЗАКАЗА
фактически является избыточным, для получения ЗНФ его можно просто
удалить.
Иногда для построения ЗНФ необходимо выразить зависимость между
неключевыми атрибутами в виде отдельной схемы. Так для сотрудников,
работающих по различным проектам, возможна следующая схема:
сотрудник (таб номер, телефон, почасовая_оплата, N_npoeктa,
дата_окончания)
Очевидно, что данная схема находится в 2НФ. Однако N_ПPOEKTA и
ДАТА_ОКОНЧАНИЯ являются зависимыми атрибутами. После расщепления
схемы получим ЗНФ:

участник_проекта ( таб номер, телефон, почасовая_оплата, N_пpoeктa)

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

2. Содержимое словаря данных

Для каждого потока данных в словаре необходимо хранить имя потока, его тип
и атрибуты. Информация по каждому потоку состоит из ряда словарных
статей, каждая из которых начинается с ключевого слова — заголовка
соответствующей статьи, которому предшествует символ
По типу потока в словаре содержится информация, идентифицирующая:
простые (элементарные) или групповые (комплексные) потоки;
внутренние (существующие только внутри системы) или внешние
(связывающие систему с другими системами) потоки;
потоки данных или потоки управления;
непрерывные (принимающие любые значения в пределах определенного
диапазона) или дискретные (принимающие определенные значения) потоки.
Атрибуты потока данных включают:
имена-синонимы потока данных в соответствии с узлами изменения имени;
БНФ-определение в случае группового потока ;
единицы измерения потока;
диапазон значений для непрерывного потока, типичное его значение и
информацию по обработке экстремальных значений;
список значений и их смысл для дискретного потока;
список номеров диаграмм различных типов в которых поток встречается;
список потоков, в которые данный поток входит (как элемент БНФ-
определения);
комментарий, включающий дополнительную информацию (например, о цели
введения данного потока).
БНФ-НОТАЦИЯ
БНФ-нотация позволяет формально описать расщепление/объединение
потоков. Поток может расщепляться на собственные отдельные ветви, на
компоненты потока- предка или на то и другое одновременно. При расщеп-
лении/объединении потока существенно, чтобы каждый компонент потока-
предка являлся именованным. Если поток расщепляется на подпотоки,
необходимо, чтобы все подпотоки являлись компонентами потока-предка. И
наоборот, при объединении потоков каждый компонент потока-предка должен
по крайней мере однажды встречаться среди подпотоков. Отметим, что при
объединении
подпотоков нет необходимости осуществлять исключение общих
компонентов, а при расщеплении подпотоки могут иметь такие общие
(одинаковые) компоненты.
Важно понимать, что точные определения потоков содержатся в словаре
данных, а не на диаграммах. Например, на диаграмме может иметься
групповой узел с входным потоком X и выходными подпотоками Y и Z.
Однако это вовсе не означает, что соответствующее определение в словаре
данных обязательно должно быть X=Y+Z. Это определение может быть
следующим:
Х=А+В+С;
Y=A+B;
Z=B+C
Такие определения хранятся в словаре данных в так называемой БНФ-статье.
БНФ-статья используется для описания компонентов данных в потоках
данных и в хранилищах. Ее синтаксис имеет вид:
@БНФ=<простой оператор> ! <БНФ-выражение >,
где <простой оператор> есть текстовое описание, заключенное в "/"> а <БНФ-
выражение> есть выражение в форме Бэкуса-Наура, допускающее следующие
опера-
ции отношений:
= означает "композиция из",
+ означает "И",
[!] означает "ИЛИ",
() означает, что компонент в
скобках необязателен,
{} означает итерацию
компонента в скобках,
означает литерал.
Итерационные скобки могут иметь нижний и верхний предел, например:
3{болт}7 — от 3 до 7 итераций 1{болт} — 1 и более итераций {шайба} 3 — не
более 3 итераций
БНФ-выражение может содержать произвольные комбинации операций:
@БНФ [ винт ! болт + 2{гайка}2 + (прокладка) ! клей ]
Ниже приведен пример описания потока данных с помощью БНФ:
@ИМЯ=ВОСЬМЕРИЧНАЯ ЦИФРА
@ТИП=дискретный поток
@БНФ= ["0"!"1"!"2"ГЗ"!"4"!"5"!"6"!"7"]
Посмотрим, как некоторые потоки, присутствующие на приведенных
диаграммах потоков данных, представляются в словаре данных.
@ИМЯ=ВВЕДЕННАЯ КРЕДИТНАЯ КАРТА
@ТИП= управляющий поток
@БНФ= указывает, что кредитная карта введена
@ИМЯ=ДАННЫЕ КРЕДИТНОЙ КАРТЫ
@ТИП = дискретный поток
@БНФ=ПАРОЛЬ + ДЕТАЛИ КЛИЕНТА + ЛИМИТ ДЕНЕГ
@ИМЯ = ДАННЫЕ ПО БАЛАНСУ
@ТИП = дискретный поток
@БНФ =/текущий баланс счета клиента/
@ЕДИНИЦА ИЗМЕРЕНИЯ = доллар
@ДИАПАЗОН = +/- 100000
@ТОЧНОСТЬ = .01
@ИМЯ = ДЕНЬГИ
@ТИП = дискретный поток
@БНФ = /деньги, выдаваемые клиенту/
@ЕДИНИЦА ИЗМЕРЕНИЯ = доллар
@НОРМА = 5..1000
@КОММЕНТАРИЙ = Сумма выдаваемых денег должна делиться на 5
@ИМЯ = ПРОТОКОЛ ОБСЛУЖИВАНИЯ
@ТИП = дискретный поток
@БНФ = (ОБРАБОТАННАЯ ДОКУМЕНТАЦИЯ) + (ДЕНЕЖНАЯ СУММА)
+ (ДАННЫЕ ПО ИСТОРИИ ЗАПРОСА)

Контрольные вопросы:
1. Для чего нужна БНФ нотация?
2. Правила
?
3. Что является основой визуального проектрования?
 Лабораторная работа №5
Создание модели данных с помощью ERWin

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

Введение

Программное средство ERWin позволяет проектировать, документировать и

сопровождать базы данных, хранилища данных. Визуальное моделирование
повышает качество создаваемой базы данных, продуктивность и скорость её
разработки.

Основные особенности IDEF1X / ERWin:

1. Поддерживается прямое (создание БД на основе модели) и обратное
(генерация модели по имеющейся базе данных) проектирование для 20 типов
СУБД.
2. Увеличивает производительность труда благодаря удобному интерфейсу и
автоматизации рутинных процедур.
3. Поддерживает методологию структурного моделирования SADT и
следующие нотации: IDEF1Х.
4. Поддерживает 20 различных СУБД: настольные, реляционные и
специализированные СУБД, предназначенные для создания хранилищ
данных.
5. Позволяет повторно использовать компоненты созданных ранее моделей, а
также использовать наработки других разработчиков.
6. Возможна совместная работа группы проектировщиков с одними и теми же
моделями (с помощью AllFusion Model Manager ).
7. Позволяет переносить структуру БД из одной СУБД в другую.
8. Позволяет документировать структуру БД.
9. Продукт можно использовать на всех стадиях жизненного цикла БД:
проектировании, разработке, тестировании и поддержке.

ERWin - это не просто средство проектирования, но и инструмент разработки,

способный автоматически создавать таблицы и генерировать текст хранимых
процедур для всех популярных СУБД. Революционная технология Complete -
Compare (Завершить-Сравнить) позволяет организовать итеративную
разработку, поддерживая постоянную согласованность модели и базы данных.
Благодаря интеграции с популярными средами разработки программ, ERWin
позволяет ускорить создание приложений для обработки данных.
ERWin имеет два уровня представления модели - логический и физический.
Логический уровень - это абстрактный взгляд на данные, на нем данные
представляются так, как выглядят в реальном мире, и могут называться так,
как они называются в реальном мире, например "Деканат", или "Фамилия
студента". Объекты модели, представляемые на логическом уровне,
называются сущностями и атрибутами (подробнее о сущностях и атрибутах
будет рассказано ниже). Логическая модель данных может быть построена на
основе другой логической модели, например на основе модели процессов.
Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД,
фактически являясь отображением системного каталога. В физической модели
содержится информация о всех объектах БД. Поскольку стандартов на
объекты БД не существует (например, нет стандарта на типы данных),
физическая модель зависит от конкретной реализации СУБД. Следовательно,
одной и той же логической модели могут соответствовать несколько разных
физических моделей. Если в логической модели не имеет значения, какой
конкретно тип данных имеет атрибут, то в физической модели важно описать
всю информацию о конкретных физических объектах - таблицах, колонках,
индексах, процедурах и т. д. Разделение модели данных на логические и
физические позволяет решить несколько важных задач.

2.1. Создание логической модели данных

Первым шагом при создании логической модели данных является построение

диаграммы сущность-связь (Entity Relationship Diagram, ERD);
Диаграмма сущность-связь представляет собой модель данных верхнего
уровня. Она включает сущности и взаимосвязи, отражающие основные
бизнес-правила предметной области. Такая диаграмма не слишком
детализирована, в нее включаются основные сущности и связи между ними,
которые удовлетворяют основным требованиям, предъявляемым к ИС.
Диаграмма сущность-связь может включать связи многие-ко-многим и не
включать описание ключей. Как правило, ERD используется для презентаций
и обсуждения структуры данных с экспертами предметной области.
ERD диаграмма позволяет рассмотреть систему целиком и выяснить
требования, необходимые для её разработки, касающиеся хранения
информации.
Как известно основным компонентом реляционных БД является таблица.
Таблица используется для структуризации и хранения информации. ERD-
диаграмма графически представляет структуру данных проектируемой
информационной системы. Сущности отображаются при помощи
прямоугольников, содержащих имя. Имена принято выражать
существительными в единственном числе, взаимосвязи – при помощи линий,
соединяющие отдельные сущности.
Для создания логической модели выполним команду: File/New, и в
появившемя окне выберем тип модели: Логический (как показано на рис.
2.1.1).

Рис. 2.1.1.

Рассмотрим процесс построения логической модели на примере БД студентов

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

2.2. Определение сущностей и атрибутов

Основные компоненты диаграммы ERWin - это сущности, атрибуты и связи.

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

Рассмотрим БД студентов созданной в предыдущих работах системы «Служба

занятости в рамках вуза». В БД будут храниться записи о студентах,
следовательно, сущностью будет студент (Таблица 2.2.1).
Таблица 2.2.1
 Атрибуты сущности «Студент»
Номер
Ф.И.О.
Пароль
Возраст
Пол
Характеристика
E-mail
Телефон
Опыт работы
Специальность
Специализация
Иностранный язык
Тестирование
Экспертная оценка
Оценки по экзаменам

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

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

К ним относятся:
опыт работы,
иностранный язык,
тестирование,
экспертная оценка,
оценки по экзаменам.

Определим их атрибуты (Таблица 2.2.2).

Таблица 2.2.2
Атрибуты сущности «Опыт работы»
Специальность
Опыт
Место работы
Атрибуты сущности «Иностранный язык»
Язык
Уровень владения
Атрибуты сущности «Тестирование»
Название
Описание
 Оценка
Атрибуты сущности «Экспертная оценка»
Дисциплина
Ф.И.О. преподавателя
Оценка
Атрибуты сущности «Оценки по экзаменам»
Предмет
Оценка

2.3. Создание ERD-диаграммы, определяя типы атрибутов

и проставляя связи между сущностями
Построение модели данных предполагает определение сущностей и
атрибутов, т. е. необходимо определить, какая информация будет храниться в
конкретной сущности или атрибуте. Для создания ERD-диаграммы выполняем
следующие действия:
1. Внести сущность в модель: необходимо "кликнуть" по кнопке сущности на
панели инструментов (ERWin Toolbox) , затем "кликнуть" по тому месту на
диаграмме, где необходимо расположить новую сущность (рис. 2.3.1).

Рис. 2.3.1.

2. Вместо Е/1, Е/2, …, Е/6 ввести наименование соответствующих сущностей

(рис. 2.3.2).
Рис. 2.3.2. Ввод наименований сущностей

3. Нажав клавишу Tab ввести атрибуты сущностей (рис. 2.3.3)

Рис. 2.3.3. Ввод атрибутов сущностей

2.4. Определение ключевых атрибутов и типов атрибутов

Каждый экземпляр сущности должен быть уникален и отличаться от других

атрибутов.
Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно
идентифицирующая экземпляр сущности. Атрибуты первичного ключа на
диаграмме не требуют специального обозначения - это те атрибуты, которые
находятся в списке атрибутов выше горизонтальной линии. При внесении
нового атрибута в диалоге Attribute Editor для того, чтобы сделать его
атрибутом первичного ключа, нужно включить флажок Primary Key в нижней
части закладки General. На диаграмме неключевой атрибут можно внести в
состав первичного ключа, воспользовавшись режимом переноса атрибутов
(кнопка в палитре инструментов).
Выбор первичного ключа может оказаться непростой задачей, решение
которой может повлиять на эффективность будущей ИС. В одной сущности
могут оказаться несколько атрибутов или наборов атрибутов, претендующих
на роль первичного ключа. Такие претенденты называются потенциальными
ключами (candidate key).
Ключи могут быть сложными, т. е. содержащими несколько атрибутов.
Сложные первичные ключи не требуют специального обозначения - это
список атрибутов выше горизонтальной линии:"
Первичный ключ должен быть подобран таким образом, чтобы по значениям
атрибутов, в него включенных, можно было точно идентифицировать
экземпляр сущности. Никакой из атрибутов первичного ключа не должен
иметь нулевое значение. Значения атрибутов первичного ключа не должны
меняться. Если значение изменилось, значит, это уже другой экземпляр
сущности.
Внешние ключи (Foreign Key) создаются автоматически, когда связь
соединяет сущности: связь образует ссылку на атрибуты первичного ключа в
дочерней сущности и эти атрибуты образуют внешний ключ в дочерней
сущности (миграция ключа). Атрибуты внешнего ключа обозначаются
символом (FK) после своего имени.
Зависимая сущность может иметь один и тот же внешний ключ из нескольких
родительских сущностей. Сущность может также получить один и тот же
внешний ключ несколько раз от одного и того же родителя через несколько
разных связей. Когда ERWin обнаруживает одно из этих событий, он
распознает, что два атрибута одинаковы, и помещает атрибут внешнего ключа
в зависимой сущности только один раз. Хотя в закладке Key Group диалога
Attribute Editor этот атрибут будет входить в два внешних ключа, на диаграмме
он показывается только один раз. Это комбинирование или объединение
идентичных атрибутов называется унификацией.

Таблица 2.4.1.

Ключевые
Атрибут Тип
атрибуты
Номер Number +
Ф.И.О. String
Пароль String
Возраст Number
Пол String
Характеристика String
E-mail String
Опыт Number +
Место работы String +
 Специальность String +
Специализация String
Язык String +
Уровень владения Number
Название String +
Описание String +
Оценка Number +
Дисциплина String +
Ф.И.О. преподавателя String +
Предмет String +

Каждый атрибут хранит информацию об определенном свойстве сущности, а

каждый экземпляр сущности должен быть уникальным.
Атрибут или группа атрибутов, которые идентифицируют сущность,
называется первичным ключом.
Для описания атрибутов следует, "кликнув" правой кнопкой по сущности,
выбрать в появившемся меню пункт Attribute Editor. Появляется диалог
Attribute Editor (таблица 2.4.1, рис. 2.4.1).

Рис. 2.4.1.

Все сущности будут зависимыми от сущности «Студент». Связи будут типа

«один-ко-многим». На полученной диаграмме рядом со связью отражается её
имя, показывающее соотношение между сущностями. При проведении связи
между сущностями первичный ключ мигрирует в дочернюю сущность.
При установлении связей между сущностями атрибуты первичного ключа
родительской сущности мигрируют в качестве внешних ключей в дочернюю
сущность. Кнопка Migrate диалога Attribute Editor вызывает диалог Migrate
Attribute Property, в котором можно задать свойства, сохраняемые при
миграции (рис. 2.4.2).
Рис. 2.4.2. ERD-диаграмма в нотации IDEF1X
ERD-диаграмма в нотации IE (рис. 2.4.3-2.4.4):

Рис. 2.4.3. Диалоговое окно выбора нотации

Рис. 2.4.4. ERD-диаграмма в нотации IE

Теперь перейдем к построению физической модели. Перед построением

физической модели выбрать сервер (меню Server/Target Server). Выберем в
качестве сервера Microsoft Access 97, получив физическую модель,
сгенерированную ERWin по умолчанию.
В полученной модели необходимо скорректировать типы и размеры полей.
Кроме того, на этапе создания физической модели данных вводятся правила
валидации колонок, определяющие списки допустимых значений и значения
по умолчанию (таблица. 2.4.2).
Таблица 2.4.2. Свойства колонок таблиц физической модели БД студентов

Правило
Тип Размер
валидации
Номер Long Integer
Группа Text 7
Ф.И.О. Text 64
Пароль Text 15
Возраст Number >10 и <100
Пол Text 1 М или Ж
Характеристика Memo
E-mail Text 40
Специальность Text 20
Специализация Text 20
Опыт Number >0
Место работы Text 20
Язык Text 25
Уровень владения Number ≥ 2 и ≤5
Название Text 30
Описание Memo
Оценка Number ≥ 2 и ≤5
Дисциплина String 30
Ф.И.О. преподавателя Text 64
Предмет Text 30

После установки правил валидации в диалоговом окне Column Editor

необходимо присвоить соответствующим колонкам таблиц установленные
для них правила.
Таким образом, проделав все вышеописанные действия, мы получим модель
БД, готовую для помещения в СУБД. Для генерации кода создания БД
необходимо выбрать пункт меню Tasks-> Forward Engineer/SchemaGeneration,
после чего откроется окно установки свойств генерируемой схемы данных.
Для предварительного просмотра SQL-скрипта служит кнопка Preview, для
генерации схемы - Generate. В процессе генерации ERWin связывается с БД,
выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо
ошибки, то она прекращается, открывается окно с сообщениями об ошибках.

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

Контрольные вопросы:
1. Назовите уровни методологии IDEF1X.
 2. Из каких моделей состоит логический уровень?
3. Из каких моделей состоит физический уровень?
4. Что включает в себя модель данных, основанная на ключах?
5. Перечислите преимущества от использования CASE-средства ERWin.

Список тем

1. Организация деятельности автозаправочной станции

2. Организация деятельности супермаркета
3. Организация деятельности автошколы
4. Автоматизация документооборота предприятия
5. Автоматизация библиотечного фонда
6. Организация деятельности налоговой инспекции
7. Организация взаиморасчетов с клиентами в торговом предприятии
8. Организация деятельности предприятий телекоммуникаций
9. Предоставление услуг по ремонту компьютерной техники
10. Автоматизация работы приемной комиссии
11. Автоматизация работы швейного цеха
12. Автоматизация работы фото лаборатории
13. Автоматизация работы склада по учету материальных ценностей
14. Автоматизация работы администратора Интернет клуба
15. Автоматизация работы медицинского центра
16. Автоматизация работы книжного магазина
17. Автоматизация работы центра по продаже компьютерной техники
18. Организация деятельности переговорного пункта
19. Организация деятельности авиакомпании
20. Автоматизация работы склада
21. Автоматизация работы обменного пункта
22. Автоматизация работы отдела кадров
23. Автоматизация работы ГАИ
24. Автоматизация работы библиотеки
25. Автоматизация работы парикмахерской
26. Организация деятельности таможенной инспекции