Конструирование программного обеспечение

ИСО

2

3

Минимизация сложности Ожидание изменений Конструирование с возможностью

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

Фундаментальные основы конструирования

4

Следование стандартам Использование ряда специфических

техник Поддержка практик, направленных на

обеспечение качества в конструировании

Минимизация сложности (Minimizing Complexity)

5

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

Ожидание изменений поддерживается рядом техник

Ожидание изменений (Anticipating Changes)

6

обзор, оценка кода (code review) модульное тестирование (unit-testing) структурирование кода для и совместно с

применениям автоматизированных средств тестирования (automated testing)

ограниченное применение сложных или тяжелых для понимания языковых структур

Конструирование с возможностью проверки (Constructing for Verification)

7

коммуникационные методы (например, стандарты форматов документов и <оформления> содержания)

языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java)

платформы (например, стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или .NET Framework SDK, Software Development Kit)

инструменты (не в терминах сред разработки, но возможных средств конструирования – например, UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода)

Стандарты в конструировании (Standards in Constructing)

8

OMG – Object Management Group (CORBA, UML, MDA, …),

международные организации по стандартизации (ISO/IEC, IEEE, TMF),

производители платформ, операционных сред и т.д. (Microsoft, Sun Microsystems, CISCO, NOKIA),

производителями инструментов, систем управления базами данных и т.п. (Borland, IBM, Microsoft, Sun, Oracle). 

Использование внешних стандартов

9

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

Использование внутренних стандартов

10

Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки. В большинстве случаев, модели конструирования определяются используемым стандартом жизненного цикла, применяемыми методологиями и практиками. Некоторые стандарты жизненного цикла, по своей природе, являются ориентированными на конструирование – например, экстремальное программирование (XP- eXtreme Programming). Некоторые рассматривают конструирование в неразрывной связи с проектированием (в части моделирования), например, RUP (Rational Unified Process).

Управление конструированием (Managing Construction)

Модели конструирования (Construction Models)

11

Модульное тестирование в ряде методов является частью работ, после написания соответствующего функционального кода, в то время, как ряд гибких (agile) практик, например, XP (кстати, первыми начавшие использовать такие методы верификации кода), требуют написания Unit-тестов до того, как пишется соответствующий код, требующий тестирования.

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

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

Планирование конструирования (Construction Planning)

12

исходный разработанный код модифицированный объем кода степень повторного использования

Измерения в конструировании (Construction Measurement)

13

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

Практические соображения (Practical Considerations)

14

Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования; другие проекты явно выделяют проектную деятельность в форме фазы дизайна. Вне зависимости от четкости выделения деятельности по проектированию, как таковой, практически всегда на стадии конструирования приходится заниматься и вопросами детального дизайна системы. Такие проектные работы имеют стремление к следованию устойчивым ограничениям, навязываемым конкретными проблемами, решение которых должно быть обеспечено использованием конструируемой программной системы.

Детали деятельности по проектированию на стадии конструирования в основном те же самые, что и описанные в области знаний “Проектирование программного обеспечения” (Software Design). Отличие заключается в большем внимании деталям.

 Проектирование в конструировании (Construction Design)

15

Три основных вида нотаций: лингвистическая формальная визуальная

Языки конструирования (Construction Languages)

16

техники создания легко понимаемого исходного кода на основе использования соглашений об именовании, форматирования и структурирования кода;

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

организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другие структуры)  

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

переполнение буфера или выход за пределы индекса в массиве) использование ресурсов на основе применения механизмов исключения

(из рассмотрения) и порядка доступа к параллельно используемым ресурсам (например, на основе блокировки данных, использования потоков и их синхронизации и т.п.)

документирование кода тонкая “настройка” кода рефакторинг.

Кодирование (Coding)

17

модульное тестирование (unit testing) интеграционное тестирование (integration

testing)

Тестирование в конструировании (Construction Testing)

18

IEEE Std 829-1998: “IEEE Standard for Software Test Documentation”

IEEE Std 1008-1987: “IEEE Standard for Software Unit Testing”

19

EEE Std. 1517-99 “IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes”

выбор единиц (units), баз данных тестовых процедур, данных <полученных в результате> тестов и самих тестов, подлежащих повторному использованию

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

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

Повторное использование (Reuse)

20

модульное (unit) и интеграционное (integration) тестирование разработка с первичностью тестов (test-first development -

тесты пишутся до конструирования кода) пошаговое кодирование (деятельность по конструированию

кода разбивается на мелкие шаги, только после тестирования результатов которых производится переход к следующему шагу кодирования; известен также как итеративное кодирование с тестированием)

использование процедур утверждений (assertion) отладка (в привычном понимании - debugging) технические обзоры и оценки (review) статический анализ

Качество конструирования (Construction Quality)

21

планирование последовательности, в которой интегрируются компоненты;

обеспечение поддержки создания промежуточных версий программного обеспечения;

задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент;

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

Интеграция (Integration)

22

Архитектура базы данных. Физическая и логическая независимость

23

Уровень внешних моделей — самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению.

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

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

24

Процесс прохождения пользовательского запроса

25

Классификация моделей данных

26

Иерархическая модель данных

27

в каждой физической БД существует один корневой сегмент, то есть сегмент, у которого нет логически исходного (родительского) типа сегмента;

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

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

28

Иерархическое дерево

29

30

Внешние модели

31

элемент данных; агрегат данных; запись; набор данных

Сетевая модель данных

32

33

34

Преподаватель Группа День

недели № пары Аудитория

Дисциплина

Иванов 4306 Понедельник

1 22-13 КИД

Иванов 4307 Понедельник

2 22-13 КИД

Карпова 4307 Вторник 2 22-14 БЗ и ЭС

Карпова 4309 Вторник 4 22-14 БЗ и ЭС

35

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

Сингулярный набор

36

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

37

Проектирование реляционных БД на основе принципов нормализации

38

Системный анализ и словесное описание информационных объектов предметной области.

Проектирование инфологической модели предметной области — частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.

Даталогичеcкое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.

Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

39

40

Функциональный подход Предметный подход

Системный анализ предметной области

41

Описание концептуальной схемы БД в терминах выбранной СУБД.

Описание внешних моделей в терминах выбранной СУБД.

Описание декларативных правил поддержки целостности базы данных.

Описание процедур поддержки семантической целостности базы данных.

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

42

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

путь синтеза,то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

Пути проектирования

43

первая нормальная форма (1NF); вторая нормальная форма (2NF); третья нормальная форма (3NF); нормальная форма Бойса—Кодда (BCNF); четвертая нормальная форма (4NF); пятая нормальная форма, или форма

проекции-соединения (5NF или PJNF).

Нормальные формы

44

каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;

при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

Основные свойства нормальных форм

45

Модель "сущность-связь"

46

47

48

49

50

Переход к реляционной модели данных

51

Исходная модель взаимосвязи супертипа и подтипов

52

Результирующая модель с наследованием только идентификатора суперсущности

53

Результирующая модель с наследованием всех атрибутов суперсущности

54

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

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

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

Шаг 4. Проанализировать все сущности на наличие детерминантов, которые не являются возможными ключами. При обнаружении подобных расщепить сущность на две, установив между ними соответствующие связи. Полученная схема соответствует нормальной форме Бойса—Кодда. Перейти к шагу 5.

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

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

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