- •Тюменский государственный университет
- •Предисловие 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.2.3. Структурное программирование
Структурное программирование – это программирование в соответствии с заранее определенным набором правил и принципов, облегчающих восприятие и отладку программ, повышающих их надежность, гибкость и эффективность.
Принципы структурного программирования
1. Модульное программирование – процесс разбиения программы на отдельные программные модули (базовые классы, процедуры, функции, ActiveX – элементы, COM/DCOM‑компоненты и др.). Свойства модуля: возникает в результате отдельной компиляции; вызывается по имени; возвращает управление тому, кто его вызывал; может обращаться к другим модулям, непосредственно нижестоящим в схеме иерархии; должен быть небольшого размера; должен иметь один вход и один выход; не должен сохранять историю вызовов для управления своим функционированием; обладает единственной функцией; должен быть независимым от других модулей; должен содержать тесно связанные элементы; должен проверять аргументы; при возникновении в модуле ошибок управление должно возвращаться обратно; должен быть замкнутым.
2. Проектирование и кодирование (программирование) сверху вниз. Если проект большой, то он разбивается на части, представляющие собой древовидную структуру (схема иерархии). Сначала задача описывается на естественном языке, в дальнейшем проект постепенно уточняется, и на каждом шаге выявляются детальные функции. Таким образом, задача разбивается на подзадачи до тех пор, пока они не станут настолько простыми, что каждой из них будет соответствовать один программный модуль.
Достоинства: хорошая комплексная отладка; заказчик участвует в проектировании; промежуточные результаты можно показать заказчику.
Недостатки: слабая автономная отладка модулей; наличие программ-заглушек, которые имитируют работу несуществующих программ нижнего уровня.
Обычно для больших проектов применяется метод «сэндвича». Для одних частей используется метод нисходящего, а для других – метод восходящего проектирования.
3. Защитное программирование. Это такой стиль написания программ, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом. Средства защитного программирования: все входные данные или действия пользователя подлежат обязательной проверке (принцип «всеобщего недоверия»); немедленное обнаружение ошибок; изолирование и минимизация последствий ошибок. Для предотвращения ошибок в программе рекомендуется не применять непроверенные способы программирования. Не используйте принцип умолчания значений (когда при отсутствии параметра программа принимает его определенное значение), так как они могут изменяться в новых версиях. Не допускайте зависимости программ от недостоверности данных. Стремитесь минимизировать число обращений к пользователю.
Тестирование – процесс обнаружения ошибок программы. Тестовые примеры разрабатываются постановщиком на этапе разработки алгоритма. Обычно вместо одного теста готовится целая серия тестов. Рекомендуется тестирование сверху вниз. Первый тест должен быть простым, так как он показывает работу программы вообще. Следующие тесты, предназначенные для проверки общей организации программы, обеспечивают обнаружение грубых ошибок. Повторно тестируйте исправленный код. Ведите журнал обнаруженных ошибок и изменений программы.
Этапы тестирования:
Проверка в нормальных условиях для характерной совокупности допустимых значений.
Проверка в экстремальных условиях в приграничных областях допустимых значений (граничные допустимые значения, нулевые данные, пустые циклы, массивы, файлы).
Проверка в исключительных ситуациях в областях недопустимых значений.
С целью выявления ошибок организуется сквозной структурный контроль (просмотр). В этом случае собираются 4–6 специалистов, которые получают необходимые материалы за 5–7 дней до начала совещания. Время совещания ограничивается двумя часами. Ведущий совещание обеспечивает составление полного списка обнаруженных ошибок. В начале совещания эксперты характеризуют степень завершенности и качество проекта. Разработчик делает обзор проделанной работы, результаты подвергаются групповому анализу. По окончании совещания председатель вручает каждому участнику список ошибок и проблем, требующих решения. Разработчик обязан устранить ошибки и сообщить об этом эксперту.
4. Наглядность исходных текстов программ. Стиль программирования, который позволяет получать удобные для применения и легко читаемые программы. Стиль связан с удобочитаемостью программы.
Р екомендации. Вводный комментарий объясняет назначение и условия применения. Пояснительные комментарии сопровождают те части программы, которые трудно понять. Дополнительные пробелы указываются повсюду, где это приводит к улучшению читабельности программы. Переменные следует явно объявлять и комментировать. Имена должны отображать смысл содержания. Допускается префиксная нотация (перед именем объекта), которая отражает тип объекта (cmdVixod – имя командной кнопки «Выход»). Составные имена следует писать через знак подчеркивания или начинать с прописных букв. Используйте общепринятые имена, которые описывают действия.
В сокращения наименований полей, переменных и других программных объектов всегда должны входить начальные буквы. Согласные важнее гласных. Начало слова важнее его конца. Списки имен в командах объявления упорядочиваются по алфавиту. Используйте общепринятые сокращения.
При записи операторов и для указания связи между ними делаются одинаковые отступы от начала строки в размере трех позиций, т.е. отступами выделяются структуры вложенности отдельных фрагментов программы.
5. Гибкость и эффективность программ. Выносите изменяемые константы, адреса и имена файлов, баз данных в отдельные файлы настройки. Оптимизируйте программу после ее отладки. Используйте именованные константы вместо обычных. Минимизируйте применение глобальных переменных, вложенных структур и команд перехода Goto. Ограничивайте действия над параметрами подпрограмм (например, для Visual Basic – ByVal, ByRef; для Pascal – Optional, Var, Out, Const).
О бщие рекомендации программисту. Помните: программы читаются людьми, и поэтому их тексты должны быть легко читаемыми и понятными. Используйте вводные комментарии. Располагайте комментарии в программе таким образом, чтобы это не делало ее менее наглядной. Одного оператора в строке достаточно. Для выделения структуры используйте отступы (начало и конец структуры сдвинуты на три позиции влево относительно тела структуры). Фиксируйте соответствие букв кириллицы и букв латинского алфавита (например, Щ (H), И (I), B (V)). Стремитесь к простоте и универсальности (например, программа имеет средства настройки на форматы и значения данных). Используйте постоянные приемы программирования. Унифицируйте форматы ввода и вывода информации. Обеспечивайте максимально удобный интерфейс пользователю. Интересуйтесь, как эксплуатируется программа (поработайте со своей программой в качестве пользователя). Устанавливайте более скромные цели (работающие программы гораздо полезнее и важнее незаконченных громадных проектов). Общая схема упрощения – разбиение программы на модули и оформление каждого модуля в виде процедуры, функции, класса, ActiveX‑элемента, компонента. Сложность возрастает квадратично размеру программы. Рекомендуется заменять циклы или вложенные конструкции на функции.