Файл: Учебное пособие по курсу Технология разработки программного обеспечения для студентов.doc
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 24.10.2023
Просмотров: 349
Скачиваний: 2
СОДЕРЖАНИЕ
1Цели при разработке программного обеспечения
2Жизненный цикл ПО. Модели жизненного цикла
3.1Принципы структурного анализа
3.3Группы средств моделирования систем
4Построение модели в DFD на примере банковской задачи
7Методология функционального моделирования SADT (IDEF0)
7.1Structured Analysis and Design Technique
8Моделирование данных в нотации IDEF1x
9Комплексная интеграция BPWin, ERWin и Paradigm Plus.
9.1Соответствие объектов моделей процессов и моделей данных
9.2Экспорт между моделью данных и моделью процессов
9.3Paradigm Plus: двусторонняя связь с ERwin
10Создание физической модели данных в ERWin
10.2 Правила валидации и значения по умолчанию
10.4 Триггеры и хранимые процедуры
11Тестирование и сертификация программного обеспечения
11.1 Дестабилизирующие факторы и методы обеспечения высокого качества функционирования ПО
11.2Использование среды автоматизированного тестирования Platinum TESTBytes
11.3 Методы обеспечения качества и надежности программных средств
11.4 Использование CASE для повышения качества ПО
11.5 Влияние стандартов открытых систем на качество ПО
11.6 Повышение качества ПО путем тестирования
11.7 Основные особенности процесса тестирования ПО
11.8 Организационные особенности тестирования
12Организация и планирование тестирования для обеспечения качества ПО
12.1 Важнейшие разделы ISO 9003
12.3 Документирование системы качества
12.5 Внутренние проверки системы качества
13Стандарты, регламентирующие разработку ПО
13.1Стандарт ISO 12207:1995 - Процессы жизненного цикла программных средств
13.3 Серия стандартов ГОСТ 34-ХХХ «Информационная технология»
14Управление проектами разработки информационных систем
14.1 Процессы управления проектами
14.7 Процессы исполнения и контроля
15Определение концепции проекта (область применения, цели и подход)
16.3Диаграмма Гантта по проекту
16.4График движения денежных средств по проекту
8.2Виды сущностей в IDEF1x
В методологии IDEF1x используются следующие виды сущностей:
Независимая от идентификаторов (просто независимая), если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Зависимая от идентификаторов (просто зависимая), если однозначная идентификация экземпляра сущности зависит от его отношения к другой сущности (рис. 18).
-
Виды сущностей в IDEF1x
Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой "/" и помещаемые над блоком.
8.3Виды связей в IDEF1X
Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя).
В IDEF1X могут быть выражены следующие мощности связей:
-
каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка; -
каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка; -
каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка; -
каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.
Кроме того связи подразделяются на:
Идентифицирующие, когда экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем и неидентифицирующие, в противном случае.
Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рис. 19 (мощность по умолчанию - N).
-
Мощности связей
Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией (рис. 20). Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
Неидентифицирующую связь изображают пунктирной линией. Сущность-потомок в неидентифицирующей связи будет независимой от идентификатора.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках.
-
Идентифицирующая связь
Кроме того, в IDEF1X вводится понятие “отношение категоризации”, по смыслу эквивалентное иерархической связи. Отношение полной категоризации (сущности-категории составляют полное множество потомков родительской сущности) обозначается:
-
Связь полной категории в IDEF1x
Также может существовать отношение неполной категоризации (сущности-категории составляют неполное множество потомков общей сущности):
-
Связь неполной категории в IDEF1x
Пример фрагмента схемы данных для банковской задачи приведен на рисунке 24.
-
Фрагмент схемы данных для банковской задачи
8.4Нормализация схемы данных
Нотация IDEF1x позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме.
Процедура нормализации схемы данных до третьей нормальной формы (3НФ) приведена на рис. 25. Расшифровка каждого из этапов приведена на рисунках 26-28
-
Процедура приведения схемы данных к третьей нормальной форме
-
Процедура приведения схемы данных к первой нормальной форме
-
Процедура перевода из 1НФ в 2НФ
-
Процедура перевода из 2НФ в 3НФ
9Комплексная интеграция BPWin, ERWin и Paradigm Plus.
К
онцептуально интеграция программных продуктов в единый технологический цикл показана на рисунке 29.
-
Комплексная интеграция продуктов в технологический цикл
9.1Соответствие объектов моделей процессов и моделей данных
Стрелки в модели процессов означают некоторую информацию, использующуюся в моделируемой системе. ERWin поддерживает два уровня представления модели данных – логический и физический.
Логический уровень не зависит от конкретной реализации БД и позволяет наглядно представить данные для обсуждения с экспертами предметной области. Физический уровень является отображением системного каталога БД и зависит от конкретной реализации БД.
На логическом уровне модели данных информация отображается в виде сущностей (соответствуют таблицам на физическом уровне), состоящих из атрибутов сущностей (соответствуют колонкам таблицы). Сущности состоят из совокупности отдельных записей - экземпляров сущностей (соответствуют записям в таблице). К модели данных предъявляются определенные требования (нормализация данных), которые призваны обеспечить компактность и непротиворечивость хранения данных. Основная идея нормализации данных – каждый факт должен храниться в одном месте. Это приводит к тому, что информация, которая моделируется в виде одной стрелки в модели процессов может содержаться в нескольких сущностях и атрибутах в модели данных.
Кроме того, на диаграмме модели процессов могут присутствовать различные стрелки, изображающие одни и те же данные, но на разных этапах обработки (например, необработанные детали – обработанные детали – собранное изделие).
Информация о таких стрелках находится в одних и тех же сущностях. Следовательно, одной и той же стрелке в модели процессов могут соответствовать несколько сущностей в модели данных и наоборот, одной сущности может соответствовать несколько стрелок.
Стрелке в модели процессов может соответствовать отдельная сущность в модели данных. Информация о стрелке может содержаться только в нескольких атрибутах сущности. Разным атрибутам одной и той же сущности могут соответствовать разные стрелки.
Работы в модели процессов могут создавать или изменять данные, которые соответствуют входящим или выходящим стрелкам. Они могут воздействовать как целиком на сущности (создавая или модифицируя экземпляры сущности), так и на отдельные атрибуты сущности.
BPWin позволяет связывать элементы модели данных, созданной с помощью ERWin, документировать влияние работ на данные и, тем самым, позволяет создать спецификации на права доступа к данным для каждого процесса.
После разработки модели данных ее следует связать с моделью процессов. Такая связь гарантирует завершенность анализа, гарантирует, что есть источник данных «Сущность» для всех потребностей данных «Работа» и позволяет делить данные между единицами и функциями бизнеc – процессов.
Каждая стрелка в модели процессов может быть связана с несколькими атрибутами различных сущностей. Связи объектов способствуют согласованности, корректности и завершенности анализа.
9.2Экспорт между моделью данных и моделью процессов
Для экспорта модели данных из ERwin'а в BPwin необходимо в ERwin'е открыть используется команда меню Bpwin / Export, экспорт ведется при помощи файлов формата *.eax. Прием экспортного файла в BPWin осуществляется при помощи команды меню Import / Erwin (EAX).
После выполнения экспорта необходимо связать сущности и атрибуты со стрелками в диалоге Arrow Data Editor. В нем необходимо указать сущности и атрибут(ы), связанные со стрелкой.
Если в процессе связывания стрелок с объектами модели данных окажется, что каких-либо сущностей или атрибутов не хватает, их можно добавить (меню Edit / Entity/Attribute Dictionary), а затем экспортировать в ERwin (в BPwin'е меню File / Export / ERwin(BPX), в ERwin'е меню BPwin / Import).
Как уже говорилось, работы могут воздействовать на данные. Для документирования такого воздействия в BPWin необходимо использовать Data Usage Editor. Data Usage Editor может быть вызван для каждой функции модели деятельности.
В списке стрелок Data Usage Editor необходимо выбрать стрелку, с которой были связаны сущности и атрибуты.
Для выбранной сущности можно установить параметры доступа по модели CRUD. Устанавливается разрешение на следующие виды операций:
-
Create (создание данных в таблице); -
Retrieve (извлечение данных); -
Update (изменение данных); -
Delete (удаление данных).
Дополнительно для каждого атрибута могут быть установлены параметры доступа по модели IRUN. Устанавливается разрешение на следующие виды операций:
-
Insert (добавление); -
Retrieve (извлечение); -
Update (изменение); -
Nullify (очистка, обнуление значения).
Ассоциации CRUD и IRUN -это правила использования сущностей и атрибутов работами. Данные не могут использоваться работами произвольно, в модели IDEF0 используются следующие правила:
-
Стрелки входа представляют данные, которые работа преобразовывает в выход или потребляет. Такие данные могут быть восстановлены (Retrieve), обновлены (Update), удалены (Delete), но не могут быть созданы (Create). -
Стрелки контроля могут быть только восстановлены (Retrieve) и не могут быть изменены. -
Стрелки выхода могут быть обновлены (если им соответствуют данные стрелок входа) или созданы (Create).
Результат связывания объектов модели процессов можно отобразить в отчете Data Usage Report (меню Report / Data Usage Report).