- •Тюменский государственный университет
- •Предисловие 7 методические материалы 9
- •Теоретические материалы 27 Глава 1. Методология разработки и стандартизации 27
- •Глава 2. Создание модели процессов в bpWin 95
- •Глава 3. Создание модели данных в erWin 121
- •Предисловие
- •Методические материалы Рабочая программа дисциплины Пояснительная записка
- •Содержание дисциплины
- •Рекомендации по самостоятельной работе Календарно-тематический план самостоятельной работы
- •Методические рекомендации по отдельным видам самостоятельной работы
- •Указания по самостоятельному изучению теоретической части дисциплины
- •Указания по выполнению контрольной работы
- •Указания по выполнению курсовой работы
- •Указания к промежуточной аттестации с применением балльно-рейтинговой системы оценки знаний
- •1.1.2. Классы программ
- •1.1.3. Архитектура программных средств
- •1.2. Стандартизация жизненного цикла программных средств
- •1.2.1. Уровни стандартизации
- •1.2.2. Основные модели жизненного цикла
- •1.2.2.1. Каскадная модель
- •1.2.2.2. Каскадная модель с промежуточным контролем
- •1.2.2.3. Модель разработки программных средств на основе ранее созданных компонентов
- •1.2.2.4. Эволюционная модель
- •1.2.2.5. Модель пошаговой разработки программных средств
- •1.2.2.6. Спиральная модель
- •1.2.2.7. Спиральная модель с ограничением версий
- •1.2.3. Структурное программирование
- •1.2.4. Организация человеко-машинного интерфейса
- •1.2.4.1. Принципы разработки
- •2. Учет возможностей аппаратных и программных средств разработчика и пользователя.
- •1.2.4.2. Рекомендации разработчику
- •1.3. Оценка стоимости и планирование разработки программных средств
- •1.3.1. Оценка стоимости разработки
- •1.3.2. Планирование разработки
- •1.4. Качество программных средств
- •1.4.1. Стандарты качества
- •1.4.2. Основные показатели качества
- •1.4.3. Методы достижения качества
- •1.4.4. Сертификация и аттестация
- •1.4.5. Конфигурационное управление версиями
- •1.4.6. Регламентирование тестирования для обеспечения качества
- •1.4.6.1. Цели и этапы тестирования программ
- •1.4.6.2. Основные тестируемые элементы
- •1.4.6.3. Восходящее и нисходящее тестирование
- •1.5. Методология быстрой разработки приложений (rad)
- •1.6. Структурный подход к проектированию информационных систем
- •1.6.1. Сущность структурного подхода
- •1.6.2. Моделирование потоков данных (бизнес-процессов) dfd
- •Отчет о продажах
- •1.6.3. Функциональное моделирование sadt (idef0)
- •1.6.3.1. Состав функциональной модели
- •1.6.3.2. Иерархия диаграмм
- •1.6.4. Моделирование данных
- •1.6.4.1. Основные понятия
- •1.6.4.2. Методология idef1
- •1.7. Общая характеристика и классификация case-средств
- •1. Компонентный состав:
- •2. Функциональная полнота:
- •3. Степень зависимости от субд:
- •4. Тип используемой модели:
- •1.8. Интеллектуализация вычислительных систем
- •1.9. Рынок программных продуктов
- •Структура рынка программных продуктов и услуг
- •1.10. Классификация систем защиты программных средств
- •1.10.1. Методы установки
- •1.10.2. Методы защиты
- •1.10.3. Принципы функционирования
- •1.10.4. Показатели оценки систем защиты
- •В опросы для контроля
- •Глава 2. Создание модели процессов в bpWin
- •2.1. Среда разработки
- •2.2. Функциональная модель (idef0)
- •2.2.1. Принципы построения модели
- •2.2.2. Работы
- •2.2.3. Стрелки
- •2.2.4. Нумерация работ и диаграмм
- •2.2.5. Диаграммы дерева узлов и экспозиций (feo)
- •2.2.6. Слияние моделей
- •2.2.7. Разделение моделей
- •2.2.8. Отчеты по модели
- •2.2.9. Экспертиза и согласование модели
- •2.3. Оценка модели
- •2.3.1. Стоимостной анализ (abc)
- •2.3.2. Анализ свойств, определенных пользователем (udp)
- •2.4. Дополнительные модели
- •2.4.1. Диаграммы потоков данных (dfd)
- •2.4.2. Диаграммы информационных процессов (idef3)
- •2.4.3. Имитационное моделирование
- •Вопросы для контроля
- •Глава 3. Создание модели данных в erWin
- •3.1. Отображение модели данных
- •3.1.1. Модели представления данных
- •3.1.2. Среда разработки
- •3.1.3. Подмодели и сохраняемые отображения
- •3.2. Создание логической модели данных
- •3.2.1. Уровни логической модели
- •3.2.2. Сущности и атрибуты
- •3.2.3. Связи
- •3.2.4. Типы сущностей и иерархия наследования (супертипы, подтипы)
- •3.2.5. Ключи
- •3.2.6. Методы нормализации и денормализации отношений
- •3.2.7. Домены
- •3.3. Создание физической модели данных
- •3.3.1. Уровни физической модели
- •3.3.2. Выбор субд
- •3.3.3. Таблицы и представления
- •3.3.4. Правила проверки значений и значения по умолчанию
- •3.3.5. Индексы
- •3.3.6. Объекты физической памяти
- •3.3.7. Триггеры и хранимые процедуры
- •3.3.8. Хранилища данных
- •3.3.9. Определение размера базы данных
- •3.3.10. Прямое и обратное проектирование
- •3.4. Создание отчетов в erWin
- •3.5. Связывание моделей процессов и модели данных
- •3.5.1. Экспорт данных из erWin в bpWin
- •3.5.2. Создание сущностей и атрибутов bpWin и их экспорт в erWin
- •В опросы для контроля
- •Глава 4. Генератор отчетов rptWin
- •4.1. Создание нового отчета
- •4.2. Среда конструктора отчетов
- •4.3. Размещение объектов отчета
- •4.4. Группировка и сортировка данных отчета
- •4.5. Изменение файла данных отчета
- •4.6. Изменение свойств отчета
- •4.7. Формирование формул
- •4.8. Пример формирования отчета
- •В опросы для контроля
- •Заключение
- •Практикум
- •Задания для контроля Тесты для самоконтроля
- •Ключи к тестам для самоконтроля
- •Пример выполнения контрольной работы
- •Темы контрольных и курсовых работ
- •1. Учет успеваемости студентов.
- •2. Учет обмена валюты.
- •3. Учет объектов строительства.
- •4. Учет выдачи и возврата книг.
- •5. Учет авиапассажиров.
- •6. Учет производства сельскохозяйственных культур.
- •7. Учет выпуска изделий.
- •8. Учет платежей налогов.
- •9. Учет поставок товаров.
- •10. Учет сбросов отравляющих веществ в окружающую среду.
- •11. Учет уволившихся с предприятия.
- •12. Учет призеров Олимпийских игр.
- •14. Учет участников олимпиады.
- •15. Учет проданных товаров.
- •16. Учет малых предприятий.
- •17. Учет больных в больнице.
- •18. Учет движения общественного транспорта.
- •19. Учет дорожно-транспортных происшествий.
- •20. Учет платежных поручений в банке.
- •21. Учет договоров займа.
- •22. Учет проданных ценных бумаг.
- •23. Учет кадров.
- •24. Учет очередников на получение жилья.
- •25. Учет исполнительской дисциплины.
- •26. Учет книг в библиотеке.
- •27. Учет переселенцев.
- •28. Учет успеваемости школьников.
- •29. Учет нарушителей трудовой дисциплины на предприятии.
- •30. Учет вакцинации населения.
- •Вопросы для подготовки к экзамену
- •Список источников информации
- •Приложения Приложение 1. Стандарты Приложение 1.1. Международный стандарт жизненного цикла
- •1. Процесс приобретения
- •2. Разработка системы и программного средства
- •3. Эксплуатация системы и программного средства
- •4. Сопровождение и развитие системы и программного средства
- •5. Управление проектом и обеспечение качества системы и программного средства
- •6. Интегральные процессы поддержки разработки программных средств
- •Приложение 1.2. Стандарты качества
- •Приложение 1.3. Стандарты по тестированию программ
- •Приложение 1.4. Государственные стандарты рф
- •Приложение 1.5. Единая система программной документации (гост 19)
- •2. Эскизный проект
- •3. Технический проект
- •4. Рабочий проект
- •5. Внедрение
- •Приложение 1.6. Автоматизированные системы управления (гост 24)
- •Приложение 1.7. Автоматизированные системы (гост 34)
- •Приложение 2. Список макрокоманд erWin
- •Приложение 3. Список макрокоманд erWin
Отчет о продажах
Рисунок 1.6.2.5. Поток данных
Построение иерархии диаграмм потоков данных. Первым шагом в построении иерархии диаграмм является построение контекстных диаграмм. Обычно при проектировании относительно простых ИС строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы.
Если же сложная система будет ограничена единственной контекстной диаграммой, то в ней будет содержаться слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги обычного формата, и, кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть: наличие большого количества внешних сущностей (десять и более), распределенная природа системы, многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Для сложных ИС строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем.
Иерархия контекстных диаграмм определяет взаимодействие основных функциональных подсистем проектируемой ИС как между собой, так и с внешними входными и выходными потоками данных и внешними объектами (источниками и приемниками информации), с которыми взаимодействует ИС.
Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем, в разработке которых участвуют разные коллективы.
По окончании построения контекстных диаграмм полученную модель следует проверить на полноту исходных данных об объектах системы и изолированность объектов (отсутствие информационных связей с другими объектами).
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется детализация. Каждый процесс, в свою очередь, может быть детализирован.
При детализации должны выполняться следующие правила:
правило балансировки: при детализации подсистемы или процесса детализирующая диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеют информационную связь детализируемые подсистема на родительской диаграмме;
правило нумерации: при детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Миниспецификация (описание логики) процесса должна формулировать его основные функции таким образом, чтобы специалист смог выполнить их или разработать соответствующую программу. Миниспецификация является вершиной иерархии.
Решение о завершении детализации процесса и использовании мини-спецификации принимается аналитиком исходя из следующих критериев:
наличия у процесса относительно небольшого количества входных и выходных потоков данных (2–3 потока);
возможности описания преобразования данных процессом в виде последовательного алгоритма;
выполнения процессом единственной логической функции преобразования входной информации в выходную;
возможности описания логики процесса при помощи миниспецификации небольшого объема (не более 20–30 строк).
При построении иерархии диаграмм переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Структуры данных конструируются из элементов данных и могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре. Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне. Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения (кг, см и т.п.), диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений.
Законченную модель системы необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные не детализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие данные должны быть считаны, а все считываемые должны быть записаны.