Проектирование баз данных и информационных систем

Проектирование баз данных и информационных систем

 

Методические указания

к составлению пояснительной записки курсовой работы

 

Санкт-Петербург

 

Составитель: Е.И. Култышев, Т.Ф. Осипова, Е.С. Морева

Рецензент:

 

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

Для студентов высших учебных заведений, обучающихся по специальностям 35…….

 

 

Общие сведения

 

Целью курсовой работы является формирование навыков самостоятельного практического применения современных методов и средств проектирования автоматизированной информационной системы, построенной на основе базы данных. В курсовой работе предполагается выполнить: проект с применением объектно-ориентированного подхода с использованием CASE средства Rational Rose или структурного подхода с использованием CASE средств BPWin и ERWin c последующей реализацией в СУБД MS Access.

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

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

Предпроектное обследование включает:

- постановка задачи,

- описание предметной области,

- определение пользователей,

- установление требований к системе (в виде технического задания на проект согласно ГОСТ 34.601.-90 и Методическим указаниям РД50-43-90).

Модели должны формализовать основные требования системы и описывать

- постановку задачи хранения данных,

- логическую модель данных,

- схему базы данных,

- постановку задачи использования данных пользователями,

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

Реализация системы предполагает создание

- физической модели базы данных системы в СУБД,

- приложения пользователя,

- макета системы в определенной среде,

- испытание и коррекцию макета.

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

К базе данных предъявляются специальные требования:

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

- целостность данных – поддержка правильности данных;

- безопасность и секретность – защита данных от сбоев и несанкционированного доступа;

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

- производительность – время ответа информационной системы, использующей разработанную базу данных, на запросы пользователей;

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

Запросами в СУБД называются программы, по которым осуществляется поиск и выдача информации. Например, в СУБД MS Access используется 3 механизма создания запроса:

- Запрос по образцу QBE – путем заполнения бланка запроса;

- Стандартный язык SQL

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

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

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

 

Рис. 1 Этапы разработки системы

 

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

1. применяемым методологиям: функционально-ориентированные, объектно-ориентированные, комплексно-ориентированные (набор методологий);

2. поддерживаемым графическим нотациям: фиксированной, наиболее распространенными;

3. степени интегрированности: локальные (tools), охватывающие большинство этапов (toolkit), полностью интегрированные (workbench);

4. режиму коллективной разработки проекта; не поддерживающие, объединение подпроектов;

5. доступным платформам;

6. архитектуре вычислительной технике: ориентированные на ПЭВМ, локальную сеть, глобальную, смешанного типа.

 

Разработка информационной системы должна осуществляться с помощью CASE-средства.

 

 

 

Пояснительная записка

 

Разделы, которые должна включать пояснительная записка к эскизному проекту (по РД50.34-90):

· Общие положения.

· Описание процесса деятельности.

· Основные технические решения.

· Мероприятия по подготовке объекта автоматизации к вводу системы в действие.

 

Глоссарий

 

Не забудьте включить в пояснительную записку

- словарь терминов,

- список используемых сокращений.

Источники

 

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

Приложение

 

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

 

Общие положения

 

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

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

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

2.

Признак классификации материалов	Название материала	Тип материала	Использование	Примечание
1.Для всего объекта автоматизации	1.Интервью с руководителями. 2.Структура производства	1.Тексты 2.Схемы 3. Таблицы	Создание подсистем, определение категории пользователей	Основа для создания модели описания системы, определение субъектов
2.Для характеристик задач	1.Интервью с исполнителями 2.Технологические и маршрутные карты 3.Сопровождающие документы	1.Тексты 2.Стандартные шаблоны 3.Диаграммы	Перечень отчетов, выходных форм и запросов	Для диаграмм использования: Субъекты, Аспекты, Ассоциации
3.Для информационных потоков	Используемые документы инвентаризации, хронометраж операций	Бланки документов, записи	Составление таблиц и входных форм	Для разработки логической схемы и определения классов.
4. Другой признак

 

В этой части пояснительной записки обязательно кратко рассказать, как велось предпроектное исследование и документы по нему включить в приложение. Формирование глоссария тоже начинается с этого раздела. Результаты предпроектного оьбследования формулируются в техническом задании согласно РД50-34-90 и ГОСТ 34.602-89.

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

· Полное наименование системы

· Наименование предприятия-разработчика и предприятия заказчика

· Назначение системы:

- Вид автоматизируемой деятельности

- Перечень объектов автоматизации

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

- Технические

- Технологические

- Производственно-экономические

- И другие цели, которые будут достигнуты в результате внедрения системы.

· Характеристика объекта автоматизации

- Сведения об объекте автоматизации

- Характеристика окружающей среды

· Требования к системе:

- В целом

1. к функциям, выполняемых системой

2. к видам обеспечения к системе в целом

- К функциям

3. перечень функций и задач подлежащих автоматизации

4. распределение их по очередям создания

5. временной регламент реализации каждой функции, задачи

6. форма представления выходной информации

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

8. достоверность выдачи информации

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

9. Программному

10. Техническому

11. и т.д.

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

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

 

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

 

Пример 1. Предпроектное обследование.

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

База данных должна хранить и пополняться следующими данными:

- Сведения о компьютерах

- Видах комплектующих

- Сведения о клиентах

- Сведения о заказах

- Сведения об исполнителях

- Сведения о выполнении заказов

Решение задачи должно осуществляться в двух направлениях: прием и выполнения заказов.

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

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

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

Менеджер по продажам сдает заказ клиенту и выписывает накладную и счет.

Коммерческий директор: просматривает отчеты менеджера по продажам и исполнителей, составляет табель выполненных работ по исполнителям и готовит сводные отчеты для принятия решений для ведения дел в Фирме.

Документы компьютерной фирмы: каталог фирмы; заявка; счет; чек; товарная накладная; Гарантийный талон.

 

 

Пример 2: Образец заполнения технического задания

Техническое задание на разработку и проектирование ИС «АЛКОР»

1. Полное наименование системы

ü База данных «Учет исполнителей заказов компьютеров»

2. Наименование предприятия заказчика

ü Заказчик ООО»АЛКОР»

3. Назначение системы:

ü Разрабатываемая база данных предназначена для учета исполнителей заказов компьютеров в компьютерной фирме ООО «АЛКОР». База данных должна обеспечить возможность корректировки информации – пополнение новой информацией и удаление устаревшей информации.

4. Описание предметной области:

Компьютерная фирма предоставляет услуги:

ü Консультации по подбору компьютеров

ü Сбор заказа клиента

ü Заполнение всех необходимых документов

5. Категории пользователей:

ü Пользователи стратегического и тактического уровней:

ü Коммерческий директор.

ü Пользователи оперативного уровня:

ü Менеджер по продажам,

ü Сборщики

6. Сопровождающие систему:

ü Обслуживающий персонал

ü администратор базы данных

ü программист.

7. Требования к системе:

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

ü Удобная форма представления и достоверность расчетной информации.

ü Быстрый ввод и поиск данных, расчет и наглядный анализ результатов.

ü Удобный интерфейс пользователя.

ü Создание общего приложения с распределением задач по пользователям.

8. Требования к функциям системы

ü Автоматизации должны подлежать следующие функции: добавление нового заказа клиента на сборку компьютера и всей необходимой информацией о комплектующих этого заказа.

ü Автоматизированный вывод гарантийного талона на заказ клиента.

ü Автоматизированный вывод информации по списку компьютеров.

ü Формой представления выводной информации должны быть запросы и таблицы с необходимой информацией по данному запросу.

ü Информация, получаемая в результате запросов должна быть достоверной

ü Время на получение необходимой информации – минимальное

9. Формы для ведения базы данных по учету:

ü Клиентов

ü Компьютеров

ü Комплектующих

ü Заказов

ü Исполнителей

ü Выполнения заказов

10. Отчеты, регламентирующие деятельность фирмы

ü Выполнения заказов

ü По оформлению заказов (накладная, чек, гарантийный талон)

ü Итоговые отчеты.

11. Требования к программному обеспечению

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

Должны выполняться требования к операционным системам общего назначения. К таким системам относятся, например, операционная система Windows 2000 и выше.

12. Требования к прикладному программному обеспечению.

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

13. Метод разработки на основе которой создается система Объектно-ориентированный, технология RUP

14. Очередность создания: подсистема1, подсистема2, разработка базы данных, заполнение базы данных данными, создание отчетов, создание форм для ввода данных, создание форм для поиска данных и других, оформление общего приложения, создание клиентских приложений.

Пример 3: Постановка задачи

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

Задача на разработку базы данных:

Подсистема1. Хранить данные, включающие сведения о компьютерах, комплектующих, видах комплектующих, клиенте.

Подсистема 2. Хранить данные об исполнителях, выполнение заказах, осуществлять связь с данными подсистемы1.

Задача на создание приложения.

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

 

Пример 6. Диаграмма Схемы базы данных полученной в CASE средстве Rational Rose. Объектно-ориентированный метод

 

 

Рис.3.3. Схема базы данных Учет компьютеров. Подсистема 1.

 

 

Пример 7. Код на SQL, полученноый в CASE средстве Rational Rose. Объектно-ориентированный метод

 

CREATE TABLE T_Комплектующие (

Артикул INT NOT NULL,

наименование VARCHAR (255) NOT NULL,

производитель VARCHAR (255) NOT NULL,

характеристика VARCHAR (255) NOT NULL,

цена MONEY NOT NULL,

CONSTRAINT PK_T_Комплектующие1 PRIMARY KEY NONCLUSTERED (Артикул)

GO

CREATE TABLE T_1 (

Код_компьютера INT NOT NULL,

Код_клиента INT NOT NULL,

CONSTRAINT PK_T_14 PRIMARY KEY NONCLUSTERED (Код_компьютера, Код_клиента)

GO

CREATE TABLE T_0 (

Код_компьютера INT NOT NULL,

Артикул INT NOT NULL,

CONSTRAINT PK_T_03 PRIMARY KEY NONCLUSTERED (Код_компьютера, Артикул)

GO

CREATE TABLE T_Клиенты (

Код_клиента INT NOT NULL,

Фирма VARCHAR (255) NOT NULL,

Адрес VARCHAR (255) NOT NULL,

Р/счет VARCHAR (255) NOT NULL,

Контактнще_лицо VARCHAR (255) NOT NULL,

Телефон VARCHAR (255) NOT NULL,

CONSTRAINT PK_T_Клиенты2 PRIMARY KEY NONCLUSTERED (Код_клиента)

GO

CREATE TABLE T_Компьютеры (

Код_компьютера INT NOT NULL,

название VARCHAR (255) NOT NULL,

Быстродействие INT NOT NULL,

Опамять VARCHAR (255) NOT NULL,

Впамять INT NOT NULL,

Примечание VARCHAR (255) NOT NULL,

CONSTRAINT PK_T_Компьютеры0 PRIMARY KEY NONCLUSTERED (Код_компьютера)

GO

CREATE INDEX TC_T_12 ON T_1 (Код_компьютера)

GO

CREATE INDEX TC_T_13 ON T_1 (Код_клиента)

GO

CREATE INDEX TC_T_00 ON T_0 (Код_компьютера)

GO

CREATE INDEX TC_T_01 ON T_0 (Артикул)

GO

ALTER TABLE T_1 ADD CONSTRAINT FK_T_12 FOREIGN KEY (Код_компьютера) REFERENCES T_Компьютеры (Код_компьютера)

GO

ALTER TABLE T_1 ADD CONSTRAINT FK_T_13 FOREIGN KEY (Код_клиента) REFERENCES T_Клиенты (Код_клиента)

GO

ALTER TABLE T_0 ADD CONSTRAINT FK_T_00 FOREIGN KEY (Код_компьютера) REFERENCES T_Компьютеры (Код_компьютера)

GO

ALTER TABLE T_0 ADD CONSTRAINT FK_T_01 FOREIGN KEY (Артикул) REFERENCES T_Комплектующие (Артикул)

GO

Пример 7. Использование данных пользователями. Объектно-ориентированный метод.

Рис. 3.4 диаграмма прецедентов для создания приложения ИС «Учет заказов компьютеров»

Пример 8. Изучение взаимодействия объектоа. Объектно-ориентированный метод.

 

 

Рис. 3.5 Диаграмма последовательности действий выполнения заказа

 

 

 

Рис. 3.6 Диаграмма кооперации

 

Структурное проектирование

 

Структурное проектирование основано на алгоритмической декомпозиции,

Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Дуглас Росс разработал язык структурного анализа, используемого для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF. Для структурного подхода используется программный комплекс BP Win и ER Win. Моделирование бизнес-процесса начинается с использования CASE средства BP Win.

Первый шаг на этапе системного анализа жизненного цикла системы как правило, моделирование средствами IDEF0. Методы и средства этого шага определяют IDEF0-технологию разработки информационной системы.

- Контекстная диаграмма формализует общую постановку задачи.

- Декомпозиция – основные задачи (построение базы данных, ведение базы данных, создание приложения и др)

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

Третий шаг определение информационных потоков, DFD –диаграмма (Data Flow Diagrams). В этой диаграмма устанавливаются таблицы сущности, являющиеся основой для построения логической модели и связующим звеном для перехода к CASE средству ER Win.

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

- Таблицы сущности из CASE средства BP Win импортируются в CASE средство ER Win.

- Таблицам задаются атрибуты и устанавливаются отношения (диаграмма сущность-связь)

- Реализуются отношения между сущностями и создается схема базы данных.

- Генерируется код на языке SQL.

 

Пример 8. IDEF0-технология. Постановка задачи

Рис. 3.7 Контекстная диаграмма. Учет продаж табачных изделий

 

Рис. 3.8 Декомпозиция. Учет продаж табачных изделий.

Пример 8. IDEF3-технология. Анализа процессов, происходящих в изучаемой системе

 

Рис. 3.9 Диаграмма описания последовательности этапов процесса действия «Ведение базы данных»

Пример 9. DFD-технология. Анализ потоков данных

 

 

Рис. 3.9 Диаграмма потоков данных действия «Получение информации »

 

 

Пример 10. Построение логической модели и схемы базы данных

 

 

Рис. 3.10. Логическая модель

 

Рис. 3.11. Физическая модель

 

Пример11 Генерация кода в CASE средстве ER-Win

CREATE TABLE Клиенты (

Адрес char(18) NULL,

Номер int IDENTITY,

Отчество char(18) NULL,

Имя char(18) NULL,

Фамилия char(18) NULL

) go

ALTER TABLE Клиенты

ADD PRIMARY KEY NONCLUSTERED (Номер)

go

 

CREATE TABLE Сделки (

Код int NULL,

Количество int NULL,

Артикул int NULL,

Дата datetime NULL,

Номер int NULL

) go

 

ALTER TABLE Сделки

ADD PRIMARY KEY NONCLUSTERED (Код)

go

CREATE TABLE Товары (

Цена money NOT NULL,

Артикул int IDENTITY,

Наименование char(18) NULL

)go

ALTER TABLE Товары

ADD PRIMARY KEY NONCLUSTERED (Артикул)

go

ALTER TABLE Сделки

ADD FOREIGN KEY (Номер)

REFERENCES Клиенты

go

 

ALTER TABLE Сделки

ADD FOREIGN KEY (Артикул)

REFERENCES Товары

go

 

Пример 12. Перенос кода в MS ACCESS и получение схемы базы данных.

 

Рис. 3.13. Запросы создания таблиц и схема базы данных

 

 

Рис.3.14.-База данных в ACCESS

 

Пример 13. Тестовый запрос на SQL

.

SELECT T_Клиенты.Фирма, T_1.[Код заказа], T_Компьютеры.Код_компьютера, T_Компьютеры.Название, T_Виды.[Код_ вида], T_Виды.Вид, T_Комплектующие.Наименование, T_Компьютеры.Быстродействие, T_Компьютеры.Опамять, T_Компьютеры.Впамять

FROM (T_Компьютеры INNER JOIN ((T_Виды INNER JOIN T_Комплектующие ON T_Виды.[Код_ вида]=T_Комплектующие.[Код_ вида]) INNER JOIN T_0 ON T_Комплектующие.Артикул=T_0.Артикул) ON T_Компьютеры.Код_компьютера=T_0.Код_компьютера) INNER JOIN (T_Клиенты INNER JOIN T_1 ON T_Клиенты.Код_клиента=T_1.Код_клиента) ON T_Компьютеры.Код_компьютера=T_1.Код_компьютера

ORDER BY T_Клиенты.Фирма, T_Компьютеры.Код_компьютера, T_Виды.[Код_ вида];.

Результат, который получился показан на рисунке 4.3.

 

Таблица 3.1 Результат решения тестового запроса

 

Пример 14. Пример построения макетов

 

 

Рис. 3.15 Макет Гарантийного талона

Пример 15. Фотография формы для заполнения заказов

Рис. 3.16 Форма Прием заказов

Пример 16. Пример построения макетов

 

Рис. 3.2 Структура приложений.

Подготовка объекта автоматизации к вводу системы в действия.

 

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

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

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

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

- Аварийные ситуации. Рекомендации по созданию копий и архивации.

 

Пример 17. Руководства пользователя

Редактирование записи

Существует возможность редактирования уже имеющихся и создания новых записей. Перемещение от поля к полю удобно осуществлять нажатием клавиши Tab. Для добавления новых записей нажать кнопку Обновить. Для удаления пункта из базы необходимо её выделить в списке и нажать кнопку Удалить. Для выхода нажмите кнопку Выход.

Поиск данных

Для поиска необходимой информации в программе существует ряд средств. Для быстрого поиска параметров (клиентов, материалов, услуг) необходимо ввести набор букв. (кнопка «Поиск Клиента» на форме «Клиент»). В случае их отсутствия появляется пустая строка..

Работа с отчётами

Для печати документов предусмотрена кнопка Вывода отчета «название отчёта». По нажатию кнопки откроется отчёт в режиме просмотра, при решении печатать нажать на пиктограмму принтера на панели меню. Данные кнопки предусмотрены как в формах так и на страницах доступа пользователя.

Логическое представление

 

Логическое представление включает в себя описание:

· статической структуры (классов, объектов и связей между ними, внутренней структуры классов, интерфейсов);

· динамики взаимодействия (обмен сообщениями между объектами).

Диаграмма классов:

Классы – группы объектов с свойствами (атрибутами: Фамилия, год, паспорт), поведением - методы (операциями: добавить клиента, получить товар), отношениями с другими объектами и семантикой. Класс- шаблон для создания объектов.

Объект имеет три характеристики: состояние, поведение, индивидуальность. Состояние – открыт или закрыт для записи. Поведение - как реагирует на запрос – удалить или добавить (аномалии по Миронову). Индивидуальность объекта – уникален или нет).

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

 

 

Рис.4.1 Вид класса.

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

· Класс – описание класса. Поля и методы в определенном формате, их спецификаторы указываются с помощью специальных значков. Синтаксис описания:

<имя_атрибута>: <тип >=<начальное значение >{<свойство>}

< имя_метода> (<список_аргументов >):<тип_ возвращаемого_ значения>{<свойство>}

Между классами существуют отношения. Самый простой вид отношений ассоциация.

1-1 определяют отношения «один- к –одному»;

1-* определяют отношения «один-ко-многим»;

*-* определяют отношения «многие-ко-многим», которое приводится к двум отношениям «один-ко-многим» введением промежуточной сущности (объекта);

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

Стереотипы и классы:

· сущность (есть стереотип)

· граничный элемент (есть стереотип)

· элемент управления (есть стереотип).

Три стереотипа соответствуют концепции модель–подставление – управление.

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

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

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

 

Нотации диаграммы состояния

 

Технология IDEF0

IDEF0 основана на четырех основных понятиях:

1. Функциональный блок.

2. Интерфейсная дуга.

3. Декомпозиция.

4. Глоссарий.

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

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

Ø Верхняя сторона – управление.

Ø Нижняя сторона – механизм.

Ø Левая сторона – вход.

Ø Правая сторона – выход

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

Из нескольких функциональных блоков, соединенных интерфейсными дугами (стрелками) требуемым образом, строится функциональная модель (Рис.4.3).

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

 

 

IDEF3-технология

 

Технология IDEF3 позволяет

Ø документировать технологические процессы,

Ø исследовать сценарии,

Ø моделировать ситуации.

Рассмотрим построение сценария в IDEF3-технологии. В основе построения сценария лежат два типа диаграмм:

1. Диаграмма описания последовательности этапов процесса.

2. Диаграмма состояний объекта.

 

Используются следующие стандартные условные обозначения:

 

- функциональный элемент поведения,

 

-

Данные

данные, обрабатываемые в функциональном элементе поведения,

 

 

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

 

- ссылка в функциональном элементе поведения на обрабатываемые данные

 

- состояние объекта,

 

 

- - перекресток для разветвления процессов

 

Символ J перекрестка может принимать одно из следующих значений:

Ø & - слияние результатов всех работ, если стрелки входят в перекресток;
запуск всех работ, если стрелки выходят из него.

Ø О - слияние результатов работ, если хотя бы одна из входных работ
завершена;
запуск хотя бы одной работы.

Ø Х - слияние только одной работы из ряда входящих в перекресток работ;
запуск только одной работы из выходящих из него работ.

 

Диаграммы потоков данных.

 

Подобно IDEF0 DFD (Data Flow diagramming) представляет модульную систему как сеть связанных между собой процессов, или действий и используются для наглядного отображения текущих операций документооборота. DFD описывает:

· процессы обработки информации

· документы, объекты, сотрудников или отделы, которые участвуют в обработке информации.

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

· Потоки данных – показывают что передает один процесс другому.

· Процесс - осуществляет преобразование входной информации в выходную.

· Хранилище данных – описывает данные, которые необходимо хранить в памяти, прежде чем использовать в работах

· Внешняя сущность – представляет некоторый объект вне системы

В BPWin для построения диаграмм потоков данных используется нотация Гейна- Сарсона

 

- Внешняя сущность

 

- Хранилище данных

 

-

 

- Процесс (действие)