145071_pr05

Конструирование программного
обеспечение ИСО
2
Фундаментальные основы
конструирования




Минимизация сложности
Ожидание изменений
Конструирование с возможностью проверки
Стандарты в конструировании
3
Минимизация сложности
(Minimizing Complexity)
 Следование стандартам
 Использование ряда специфических техник
 Поддержка практик, направленных на обеспечение
качества в конструировании
4
Ожидание изменений (Anticipating
Changes)
 Большинство программных систем изменяются с
течением времени. Причин этому – множество.
Ожидание изменений является одной из движущих сил
конструирования программного обеспечения.
Программное обеспечение не является изолированным
от внешнего окружения (как системного, так и с точки
зрения области деятельности, для автоматизации задач
и проблем которого оно применяется). Более того,
программные системы являются частью изменяющейся
среды и должны меняться вместе с ней, а, иногда, и
быть источником изменений самой среды.
 Ожидание изменений поддерживается рядом техник
5
Конструирование с возможностью
проверки (Constructing for
Verification)
 обзор, оценка кода (code review)
 модульное тестирование (unit-testing)
 структурирование кода для и совместно с
применениям автоматизированных средств
тестирования (automated testing)
 ограниченное применение сложных или тяжелых
для понимания языковых структур
6
Стандарты в конструировании
(Standards in Constructing)
 коммуникационные методы (например, стандарты форматов
документов и <оформления> содержания)
 языки программирования и соответствующие стили кодирования
(например, Java Language Specification, являющийся частью стандартной
документации JDK – Java Development Kit и Java Style Guide,
предлагающий общий стиль кодирования для языка программирования
Java)
 платформы (например, стандарты программных интерфейсов для
вызовов функций операционной среды, такие как прикладные
программные интерфейсы платформы Windows - Win32 API, Application
Programming Interface или .NET Framework SDK, Software Development
Kit)
 инструменты (не в терминах сред разработки, но возможных средств
конструирования – например, UML как один из стандартов для
определения нотаций для диаграмм, представляющих структура кода и
его элементов или некоторых аспектов поведения кода)
7
Использование внешних
стандартов
 OMG – Object Management Group (CORBA, UML,
MDA, …),
 международные организации по стандартизации
(ISO/IEC, IEEE, TMF),
 производители платформ, операционных сред и
т.д. (Microsoft, Sun Microsystems, CISCO, NOKIA),
 производителями инструментов, систем
управления базами данных и т.п. (Borland, IBM,
Microsoft, Sun, Oracle).
8
Использование внутренних
стандартов
 В сочетании со внешними стандартами, внутренние
стандарты призваны определить общие правила
игры для всех членов проектной команды,
договорившись о терминах, процедурах и других
значимых соглашениях, вне зависимости от
степени формализации процессов
конструирования, в частности, и процессов
жизненного цикла,
9
Управление конструированием
(Managing Construction)
Модели конструирования
(Construction Models)
 Модели конструирования определяют комплекс операций,
включающих последовательность, результаты (например,
исходный код и соответствующие unit-тесты) и другие
аспекты, связанные с общим жизненным циклом разработки.
В большинстве случаев, модели конструирования
определяются используемым стандартом жизненного цикла,
применяемыми методологиями и практиками. Некоторые
стандарты жизненного цикла, по своей природе, являются
ориентированными на конструирование – например,
экстремальное программирование (XP- eXtreme
Programming). Некоторые рассматривают конструирование в
неразрывной связи с проектированием (в части
моделирования), например, RUP (Rational Unified Process).
10
Планирование конструирования
(Construction Planning)
 Модульное тестирование в ряде методов является частью работ, после
написания соответствующего функционального кода, в то время, как
ряд гибких (agile) практик, например, XP (кстати, первыми начавшие
использовать такие методы верификации кода), требуют написания Unitтестов до того, как пишется соответствующий код, требующий
тестирования.
 Используемый подход к конструированию влияет на возможность
уменьшения (в идеале - минимизации) сложности, готовности к
изменениям и конструировании с возможностью проверки.
 Планирование конструкторской деятельности определяет порядок, в
котором создаются компоненты и другие активы данной области знаний
(фазы деятельности), проводятся работы по обеспечению качества
получаемого программного обеспечения, распределяются задачи и
соответствующие ресурсы, в том числе, определяются
назначения/отображения работ конкретным инженерампрограммистам, членам проектной группы.
11
Измерения в конструировании
(Construction Measurement)
 исходный разработанный код
 модифицированный объем кода
 степень повторного использования
12
Практические соображения
(Practical Considerations)
 Конструирование – деятельность, в рамках
которой программное обеспечение приводится к
соглашению с произвольными (иногда хаотическими) ограничениями реального мира,
которые требуют от программного обеспечения
точного следования им. Приближаясь к
ограничениям реального мира, конструирование (в
большей степени, чем любая другая область
знаний) ведется на основе практических
соображений и техник.
13
Проектирование в
конструировании (Construction
Design)
 Некоторые проекты предполагают больший объем работ по
проектированию именно на стадии конструирования; другие проекты
явно выделяют проектную деятельность в форме фазы дизайна. Вне
зависимости от четкости выделения деятельности по проектированию,
как таковой, практически всегда на стадии конструирования приходится
заниматься и вопросами детального дизайна системы. Такие проектные
работы имеют стремление к следованию устойчивым ограничениям,
навязываемым конкретными проблемами, решение которых должно
быть обеспечено использованием конструируемой программной
системы.
 Детали деятельности по проектированию на стадии конструирования в
основном те же самые, что и описанные в области знаний
“Проектирование программного обеспечения” (Software Design).
Отличие заключается в большем внимании деталям.
14
Языки конструирования
(Construction Languages)
Три основных вида нотаций:
 лингвистическая
 формальная
 визуальная
15
Кодирование (Coding)
 техники создания легко понимаемого исходного кода на основе использования
соглашений об именовании, форматирования и структурирования кода;
 использование классов, перечисляемых типов, переменных, именованных
констант и других выразительных сущностей;
 организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и
другие структуры)
 использование структур управления;
 обработка ошибочных условий и исключительных ситуаций
 предотвращение возможных брешей в безопасности (например, переполнение
буфера или выход за пределы индекса в массиве)
 использование ресурсов на основе применения механизмов исключения (из
рассмотрения) и порядка доступа к параллельно используемым ресурсам
(например, на основе блокировки данных, использования потоков и их
синхронизации и т.п.)
 документирование кода
 тонкая “настройка” кода
 рефакторинг.
16
Тестирование в конструировании
(Construction Testing)
 модульное тестирование (unit testing)
 интеграционное тестирование (integration testing)
17
 IEEE Std 829-1998: “IEEE Standard for Software Test
Documentation”
 IEEE Std 1008-1987: “IEEE Standard for Software Unit
Testing”
18
Повторное использование (Reuse)
 EEE Std. 1517-99 “IEEE Standard for Information
Technology – Software Lifecycle Process – Reuse
Processes”
 выбор единиц (units), баз данных тестовых процедур,
данных <полученных в результате> тестов и самих
тестов, подлежащих повторному использованию
 оценка потенциала повторного использования кода и
тестов
 отслеживание информации и создание отчетности по
повторному использованию в новом коде, тестовых
процедурах и данных, полученных в результате тестов.
19
Качество конструирования
(Construction Quality)
 модульное (unit) и интеграционное (integration) тестирование
 разработка с первичностью тестов (test-first development - тесты
пишутся до конструирования кода)
 пошаговое кодирование (деятельность по конструированию
кода разбивается на мелкие шаги, только после тестирования
результатов которых производится переход к следующему шагу
кодирования; известен также как итеративное кодирование с
тестированием)
 использование процедур утверждений (assertion)
 отладка (в привычном понимании - debugging)
 технические обзоры и оценки (review)
 статический анализ
20
Интеграция (Integration)
 планирование последовательности, в которой
интегрируются компоненты;
 обеспечение поддержки создания промежуточных
версий программного обеспечения;
 задание “глубины” тестирования (в частности, на
основе критериев “приемлемого” качества) и других
работ по обеспечению качества интегрируемых в
дальнейшем компонент;
 определение этапных точек проекта, когда будут
тестироваться промежуточные версии конструируемой
программной системы.
21
Архитектура базы данных.
Физическая и логическая
независимость
22
 Уровень внешних моделей — самый верхний уровень, где каждая
модель имеет свое "видение" данных. Этот уровень определяет точку
зрения на БД отдельных приложений. Каждое приложение видит и
обрабатывает только те данные, которые необходимы именно этому
приложению.
 Концептуальный уровень — центральное управляющее звено, здесь
база данных представлена в наиболее общем виде, который
объединяет данные, используемые всеми приложениями, работающими
с данной базой данных. Фактически концептуальный уровень отражает
обобщенную модель предметной области (объектов реального мира),
для которой создавалась база данных. Как любая модель,
концептуальная модель отражает только существенные, с точки зрения
обработки, особенности объектов реального мира.
 Физический уровень — собственно данные, расположенные в файлах
или в страничных структурах, расположенных на внешних носителях
информации.
23
Процесс прохождения
пользовательского запроса
24
Классификация моделей данных
25
Иерархическая модель данных
26
 в каждой физической БД существует один корневой
сегмент, то есть сегмент, у которого нет логически
исходного (родительского) типа сегмента;
 каждый логически исходный сегмент может быть связан
с произвольным числом логически подчиненных
сегментов;
 каждый логически подчиненный сегмент может быть
связан только с одним логически исходным
(родительским ) сегментом.
27
Иерархическое дерево
28
29
Внешние модели
30
Сетевая модель данных




элемент данных;
агрегат данных;
запись;
набор данных
31
32
33
Препода
Группа
ватель
Иванов
4306
Иванов
4307
Карпова
4307
День
недели
Понедель
ник
Понедель
ник
Вторник
Карпова
4309
Вторник
1
Аудитор Дисципл
ия
ина
22-13
КИД
2
22-13
КИД
2
22-14
БЗ и ЭС
4
22-14
БЗ и ЭС
№ пары
34
Сингулярный набор
 Сингулярные наборы позволяют
обеспечить доступ к экземплярам
отдельных типов данных,
поэтому если в задаче алгоритм
обработки информации
предполагает обеспечение
произвольного доступа к
некоторому типу записи, то для
поддержки этой возможности
необходимо ввести
соответствующий сингулярный
набор.
35
Концептуальная модель торговопосреднической организации
36
Проектирование реляционных БД
на основе принципов
нормализации
37
 Системный анализ и словесное описание информационных
объектов предметной области.
 Проектирование инфологической модели предметной
области — частично формализованное описание объектов
предметной области в терминах некоторой семантической
модели, например, в терминах ER-модели.
 Даталогичеcкое или логическое проектирование БД, то есть
описание БД в терминах принятой даталогической модели
данных.
 Физическое проектирование БД, то есть выбор эффективного
размещения БД на внешних носителях для обеспечения
наиболее эффективной работы приложения.
38
39
Системный анализ предметной
области
 Функциональный подход
 Предметный подход
40
Даталогическое проектирование
 Описание концептуальной схемы БД в терминах
выбранной СУБД.
 Описание внешних моделей в терминах выбранной
СУБД.
 Описание декларативных правил поддержки
целостности базы данных.
 Описание процедур поддержки семантической
целостности базы данных.
41
Пути проектирования
 путь декомпозиции (разбиения),когда исходное
множество отношений, входящих в схему БД
заменяется другим множеством отношений (число
их при этом возрастает), являющихся проекциями
исходных отношений;
 путь синтеза,то есть путем компоновки из
заданных исходных элементарных зависимостей
между объектами предметной области схемы БД.
42
Нормальные формы






первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса—Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма, или форма проекциисоединения (5NF или PJNF).
43
Основные свойства нормальных
форм
 каждая следующая нормальная форма в
некотором смысле улучшает свойства
предыдущей;
 при переходе к следующей нормальной форме
свойства предыдущих нормальных форм
сохраняются.
44
Модель "сущность-связь"
45
46
47
48
49
Переход к реляционной модели
данных
50
Исходная модель взаимосвязи
супертипа и подтипов
51
Результирующая модель с
наследованием только
идентификатора суперсущности
52
Результирующая модель с
наследованием всех атрибутов
суперсущности
53






Шаг 1. Проанализировать схему на присутствие сущностей, которые скрыто моделируют
несколько разных взаимосвязанных классов объектов реального мира (именно это
соответствует ненормализованным отношениям). Если такое выявлено, то разделить каждую
из этих сущностей на несколько новых сущностей и установить между ними соответствующие
связи, полученная схема будет находиться в первой нормальной форме. Перейти к шагу 2.
Шаг 2. Проанализировать все сущности, имеющие составные первичные ключи, на наличие
неполных функциональных зависимостей непервичных атрибутов от атрибутов возможного
ключа. Если такие зависимости обнаружены, то разделить данные сущности на 2, определить
для каждой сущности первичные ключи и установить между ними соответствующие связи.
Полученная схема будет находиться во второй нормальной форме. Перейти к шагу 3.
Шаг 3. Проанализировать неключевые атрибуты всех сущностей на наличие транзитивных
функциональных зависимостей. При обнаружении таковых расщепить каждую сущность на
несколько таким образом, чтобы ликвидировать транзитивные зависимости. Схема находится
в третьей нормальной форме. Перейти к шагу 4.
Шаг 4. Проанализировать все сущности на наличие детерминантов, которые не являются
возможными ключами. При обнаружении подобных расщепить сущность на две, установив
между ними соответствующие связи. Полученная схема соответствует нормальной форме
Бойса—Кодда. Перейти к шагу 5.
Шаг 5. Проанализировать все сущности на наличие многозначных зависимостей. Если
обнаружатся сущности, у которых имеется более одной многозначной зависимости, то
расщепить такие сущности на две, установив между ними соответствующие связи. Полученная
схема будет находиться в четвертой нормальной форме. Перейти к шагу 6.
Шаг 6.Проанализировать сущности на наличие в них зависимостей проекции-соединения. При
обнаружении таковых расщепить сущность на требуемое число взаимосвязанных сущностей и
установить между ними требуемые связи. Полученная таким образом схема будет находиться
в пятой нормальной форме и, будучи формально преобразованной к реляционной схеме по
указанным выше принципам, даст реляционную схему также в пятой нормальной форме.
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91