Программная инженерия.Часть II. Учебное пособие
.pdf
Вывод
Любая система может рассматриваться с разных точек зрения, поэтому в результате формируются различные архитектурные представления, составляющие частные аспекты программной архитектуры, определяющие специфические свойства программной системы. Комплекс архитектурных представлений достаточен для реализации системы и удовлетворения предъявляемых к ней требований. В лекции рассматриваются вопросы представления архитектуры приложений и диаграммы, которые можно использовать при их проектировании.
Вопросы для самопроверки
1.Какие методы обеспечения отказоустойчивости используют наиболее часто? Перечислите достоинства и недостатки каждого из них.
2.Как можно графически отобразить архитектуру ПС? Опишите основные средства отображения архитектуры ПС.
3.Каковы основные атрибуты анализа качества программного дизайна?
Литература
1.Программная инженерия: учебник / В. А. Антипов и др.; под ред.
Б.Г. Трусова. М.: Академия, 2014. 282 с.
2.Соммервилл И. Инженерия программного обеспечения. 6-е изд. / пер. с англ. М.: Изд. дом «Вильямс», 2002. 624 с.
3.Кознов Д. Введение в программную инженерию: учебный курс. М.: Интуит, 2008.
II Часть | пособие Учебное
41
Тема 13. КОНСТРУИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
План 13.1. Основы конструирования реляционных баз данных.
13.2. Разработка баз данных.
13.3. Основы конструирования реляционных баз данных. 13.4. Концептуальное (инфологическое) проектирование. 13.5. Логическое (даталогическое) проектирование.
13.6. Физическое проектирование.
13.7. Конструирование логики работы с данными. 13.8. Вопросы безопасности баз данных.
13.1. Основы конструирования реляционных баз данных
Процесс конструирования – это процесс разработки программного обеспечения, включающий в себя низкоуровневое проектирование и кодирование.
Низкоуровневое проектирование – это более детальная проработка архитектуры программного обеспечения: проектирование классов в ООП (объектно ориентированное программирование), проработка структуры базы данных в СУБД (система управления базами данных), организация Web-приложения и компонентов и т. д.
Кодирование – процедура написания программного кода. Это реализация в виде программы разработанной высокоуровневой и низкоуровневой архитектуры проекта.
В некоторых проектах этап конструирования объединяют с проектированием, если это является целесообразным. Процессы конструирования и разработки различны для разных категорий разрабатываемого ПО, среди самых распространенных можно выделить следующие виды разработок:
|
– разработка баз данных. Базы данных выделяют в отдельную ка- |
|
|
тегорию ПО. Разработка баз данных в большинстве случаев напрямую |
|
ИНЖЕНЕРИЯ |
связана с разработкой одного из видов приложений, которые управляют |
|
информацией, хранящейся в базе данных. Достаточно часто программи- |
||
|
||
|
рованием баз данных занимаются отдельные разработчики; |
|
|
– разработка приложений на базе структурного программирования. |
|
ПРОГРАММНАЯ |
Структурное программирование используется в ряде языков програм- |
|
мирования для определенного класса приложений: драйверы устройств, |
||
|
||
|
операционные системы и пр.; |
|
|
– разработка приложений на базе ООП. Объектно ориентированные |
|
|
языки используются в огромном числе приложений. Одной из основных |
|
|
|
|
|
|
42
задач при разработке данных приложений является проектирование иерархии классов. Ошибки проектирования классов не позволяют оперативно делать доработки или совершенствовать программу, что может привести к затягиванию сроков разработки, увеличению стоимости и прочим негативным последствиям;
– разработка Web-приложений. Web-приложения относятся к еще одной большой категории программных продуктов, которые имеют свою специфику, например, разработка приложений для Web-браузеров (апплетов) является все еще достаточно распространенной среди данной категории приложений.
13.2. Разработка баз данных
База данных (БД) – совокупность взаимосвязанных данных, организованных в соответствии со схемой данных таким образом, чтобы можно было поддержать эффективную работу конечного пользователя. Проектирование и конструирование любой программной системы, которая предполагает работу с БД, начинается с проектирования и конструирования структуры данных. На основании созданной структуры данных проектируется приложение, пишутся процедуры управления этими данными. Такой порядок разработки связан с тем, что проще перейти от структуры данных к логике работы с этими данными, чем наоборот.
Базы данных можно классифицировать следующим образом. Иерархическая база данных – может быть представлена как дерево,
состоящее из объектов различных уровней. Самый верхний уровень (корень) занимает один объект, далее идут объекты второго уровня и т. д. Между объектами существуют определенные связи. Каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект, более близкий к корню, к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно должен быть только один предок. Объекты, имеющие общего предка, называются близнецами.
Сетевая база данных – построена на логической модели данных, которая является расширением иерархического подхода и основана на строгой математической теории, описывающей структурный аспект БД, аспект целостности данных и аспект обработки данных. Разница между иерархической моделью данных и сетевой состоит в том, что в иерархических структурах запись-потомок должна иметь одного предка, а в сетевой структуре данных у потомка может иметься любое число предков.
Реляционная база данных использует логическую (реляционную) модель данных, прикладную теорию построения баз данных, которая
II Часть | пособие Учебное
43
является приложением к задачам обработки данных таких разделов математики, как теория множеств, реляционная алгебра или исчисление предикатов первого порядка.
Объектно ориентированная база данных – база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.
Объектно-реляционная база данных – реляционная база данных, поддерживающая некоторые технологии, реализующие объектно ориентированный подход.
Работа с любой базой данных начинается с проектирования структуры данных. Различают высокоуровневое проектирование, когда выделяются сущности и часть полей, в которых будет сохраняться информация,
идетальное, при котором созданная общая структура может уточняться
имодифицироваться. В процессе детального проектирования либо после его окончания начинается процесс программирования логики работы с данными. В зависимости от типа приложений, логика может разрабатываться средствами самой БД (что является более приемлемым), либо логика закладывается в приложении, которое будет осуществлять доступ и обработку данных. В первом случае разрабатываемое приложение будет с «тонким» клиентом, во втором с «толстым» клиентом. Рассмотрим основные особенности конструирования реляционных баз данных.
13.3. Основы конструирования реляционных баз данных
Реляционная база данных основывается на реляционной модели данных, которая включает следующие аспекты:
– структурный аспект – данные в БД представляют собой набор отношений (таблиц);
– аспект целостности – отношения (таблицы) отвечают определенным условиям целостности (реляционная модель данных поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных;
– аспект обработки (манипулирования) – поддержка операторов манипулирования отношениями (реляционная алгебра, реляционное исчисление.
ИНЖЕНЕРИЯ |
Для описания структуры базы данных необходимо ввести некоторые |
|
основополагающие понятия |
||
|
||
|
Тип данных. Понятие «тип данных» в реляционной модели данных пол- |
|
|
ностью соответствует понятию типа данных в языках программирования. |
|
ПРОГРАММНАЯ |
Домен. Определяется заданием некоторого базового типа данных, |
|
к которому относятся элементы домена, и произвольного логического |
||
|
||
|
выражения, применяемого к элементам этого типа. Если вычисление ло- |
|
|
гического выражения применительно к данному элементу дает результат |
|
|
«истина», то элемент данных является элементом домена. Например, до- |
|
|
|
|
|
|
44
мен «Возраст» определен на базовом типе «Целые числа», но в его число могут входить только значения, например, от 0 до 120 (рис. 13.1). Таким образом, домен позволяет создать пользовательский тип данных с возможностью задания необходимых ограничений допустимых значений.
Рис. 13.1. Базовые понятия реляционных баз данных
Атрибут. Атрибутом называют элемент отношения (свойство), который входит в уникальный набор состава отношения. Атрибут состоит из наименования атрибута и домена / типа данных. В табличном представлении под атрибутами принято понимать столбцы таблиц – поля в структуре БД.
Структура отношения – это множество пар: имя атрибута (уникальные для данного отношения) и имя домена или типа, если концепция домена не поддерживается. Степень, или «арность» отношения – мощность этого множества (число атрибутов). Если все атрибуты одного отношения определены на разных доменах, то имеет смысл использовать для именования атрибутов имена соответствующих доменов (не забывая о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута.
Схема БД (в структурном смысле) – это набор именованных отношений и взаимосвязей между ними. В табличном представлении под структурой отношения понимают структуру таблицы базы данных, а схема базы данных состоит из набора таблиц и отношений между ними.
Кортеж, соответствующий данной структуре отношения, – это множество пар (имя атрибута, значение), где имя атрибута уникально
II Часть | пособие Учебное
45
для данного отношения. «Значение» является допустимым значением домена данного атрибута (или типа данных, если концепция домена не поддерживается). В табличном представлении под кортежем понимается строка таблицы данных – запись.
Первичный ключ – это такой набор атрибутов, который однозначно определяет одну строку или кортеж, другими словами, первичный ключ – это такой набор полей, который позволяет однозначно определить одну запись в таблице данных, т. е. уникальный идентификатор.
В процессе проектирования БД решаются следующие задачи: обеспечение хранения в БД всей необходимой информации; обеспечение возможности получения данных по всем необходимым запросам сокращение избыточности и дублирования данных; обеспечение целостности данных (правильности их содержания), т. е. исключение противоречий в содержании данных, исключение их потери и т. д.
Можно выделить следующие основные этапы процесса проектирования базы данных: концептуальное (инфологическое) проектирование, логическое (даталогическое) проектирование, физическое проектирование. Рассмотрим их подробнее.
13.4. Концептуальное (инфологическое) проектирование
На этом этапе осуществляется построение семантической модели предметной области, т. е. информационной модели наиболее высокого уровня абстракции. Такая модель создается без ориентации на какую-ли- бо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области», например «концептуальная модель базы данных» и «концептуальная модель предметной области», поскольку такая модель является как образом реальности, так и образом проектируемой БД для этой реальности.
Чаще всего концептуальная модель БД включает в себя:
– описание информационных объектов, или понятий предметной об-
ИНЖЕНЕРИЯ |
ласти и связей между ними; |
|
– описание ограничений целостности, т. е. требований к допустимым |
||
|
||
|
значениям данных и к связям между ними. |
|
|
Конкретный вид и содержание концептуальной модели базы данных |
|
ПРОГРАММНАЯ |
определяется выбранным для этого формальным аппаратом. Обычно ис- |
|
пользуются графические нотации, подобные ER-диаграммам. |
||
|
||
|
Модель «сущность – связь» (ER-модель) – модель данных, позволяющая |
|
|
описывать концептуальные схемы предметной области в терминах объек- |
|
|
тов (сущностей) и отношений (связей) между ними. ER-модель представ- |
|
|
|
|
|
|
46
ляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-мо- дель, была предложена диаграмма «сущность – связь» (ER-диаграмма).
13.5. Логическое (даталогическое) проектирование
Это этап создания схемы БД на основе конкретной модели данных, например реляционной. Для реляционной модели данных даталогическая модель – набор отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи. Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Наиболее распространенным видом диаграмм для даталогического (и последующего физического) проектирования является ER-модель. При проектировании желательно использовать специализированные программные продукты, которые позволяют рисовать логические схемы баз данных, а затем переходить от них к физическому проектированию. Одним из таких средств проектирования является «All Fusion ERW in Data Modeler».
13.6. Физическое проектирование
Это этап создания схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на поименование объектов базы данных, на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.
Сама диаграмма в точности повторяет даталогическую, но в ней уже присутствует информация, специфическая для конкретной БД, например, названия типов. Автоматизированные средства проектирования баз данных позволяют по построенной физической схеме БД сформировать скрипты на создание всех необходимых объектов в БД.
13.7. Конструирование логики работы с данными
Под конструированием логики работы с данными понимается разработка процедур и функций, которые позволяют осуществлять как обработку, так и контроль хранимой информации средствами СУБД.
II Часть | пособие Учебное
47
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
Простейшие системы, которые создаются с использованием баз данных, ограничивают разработку баз данных созданием структуры таблиц и связей между ними. Вся обработка данных осуществляется из приложения, которое предоставляет и обрабатывает информацию, а затем сохраняет ее в базе данных. Данный подход является наименее безопасным, так как любой пользователь, получивший логин и пароль к базе данных, используя приложение, получает доступ к таблицам с данными и может не только считывать информацию, но и изменять ее. Такой тип приложений называется «с толстым клиентом».
Более безопасным считается подход, когда доступ к таблицам данных имеют только процедуры СУБД, которые вызываются приложением. Это позволяет в самих процедурах контролировать целостность данных и не выполнять некорректные действия. При этом доступ приложения непосредственно к таблицам полностью запрещается. В данном случае необходимо для каждой таблицы создавать как минимум, четыре процедуры:
1)процедуру на чтение данных (процедуры на чтение данных необязательно должны работать с одной таблицей, они могут использовать сложные запросы, которые получают данные из нескольких таблиц,
атакже принимать дополнительные параметры, которые будут управлять процессом отбора записей / фильтровать;
2)процедуру добавления данных;
3)процедуру изменения данных;
4)процедуру удаления данных.
Подход к работе с данными через процедуры требует программирования на уровне баз данных. Дальнейшим развитием этого подхода является программирование всей логики обработки данных в БД, а приложение должно только отображать информацию, осуществлять первичную проверку корректности вводимых данных и вызывать соответствующие процедуры в СУБД. Такой тип приложений называется «с тонким клиентом».
Существуют решения, которые выносят часть логики обработки информации (так называемая бизнес-логика) на отдельный сервер приложений. Клиентские приложения обращаются к серверу приложений, который обрабатывает запросы и вызывает соответствующие процедуры базы данных. Данный подход является наиболее безопасным, так как становится практически невозможно получить доступ к БД.
13.8. Вопросы безопасности баз данных
Безопасность напрямую связана с хранимой информацией. Любая организация, создающая или заказывающая программный продукт, напрямую заинтересована в том, чтобы информация, с которой она будет работать, не попала к злоумышленникам. Безопасность БД складывается из нескольких составляющих.
48
Безопасность на уровне прав доступа. Все современные СУБД поддерживают выдачу прав доступа практически на любой объект БД. Любое приложение, которое подключается к данным, должно пройти процедуру авторизации (в параметрах подключения необходимо указать логин и пароль). После авторизации объект получает доступ к тем объектам БД, которые прописаны в его правах. Причем права на объекты состоят не только из вариантов: «Есть доступ», «Нет доступа». Для каждого объекта БД существует свой набор прав. Например, для таблицы возможны следующие права: «На чтение данных», «На добавление данных», «На изменение данных», «На удаление данных», «На чтение данных из конкретных полей таблицы».
Совмещенная безопасность на уровне разработанной архитектуры БД и прав доступа. Данный вариант подразумевает запрет любых обращений к таблицам для учетных записей приложений, которые с ней работают. Приложения должны вызывать соответствующие процедуры СУБД, которые имеют права на работу с таблицами данных.
Защищенные соединения. Все подключения к БД необходимо выполнять по защищенному подключению. Наиболее распространенным является SSL-подключение (криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером).
Шифрование данных. Несмотря на то что передача данных по протоколу SSL считается безопасной, если злоумышленник получит доступ к базе данных, он сможет прочитать всю информацию, которая в ней хранится. Чтобы этого не произошло, используют шифрование на уровне хранимой информации. В этом случае, чтобы добраться до данных, злоумышленник должен получить ключ, при помощи которого расшифровываются полученные данные.
Обеспечение безопасности при разработке. Обеспечение безопасности на уровне прав доступа не защищает от ошибок программирования, которые могут дать возможность злоумышленникам получить доступ к данным либо испортить их. Одним из наиболее распространенных вариантов являются SQL-инъекции. В случае, когда запросы к БД формируются динамическим образом (прямо в приложении создается строка запроса), злоумышленник может изменить или даже заменить существующий запрос к БД и получить доступ к недоступной ранее информации.
Например, в программе динамически формируется следующий запрос
SELECTid, nameFROMproductsWHEREmanufacturer = ‘@ price’,
где вместо ключевого слова «@ price» динамически подставляется значение поля с названием производителя, которое заполняет пользователь. Если злоумышленник в качестве наименования производителя введет следующий текст (корректность синтаксиса зависит от используемой СУБД)
II Часть | пособие Учебное
49
ПРОГРАММНАЯ ИНЖЕНЕРИЯ
фыаыва’; deletefromproducts; commit
то запрос выполнится корректно, но также удалятся все данные о продуктах.
Вывод
Нами рассмотрены основные понятия процесса конструирования программного обеспечения. Так как процессы конструирования и разработки различаются для разных категорий разрабатываемого ПО, то среди самых распространенных выделяют следующие: разработка баз данных, разработка приложений на базе структурного программирования, разработка приложений на базе ООП, разработка Web-приложений.
Вопросы для самопроверки
1.Что включает в себя процесс конструирования ПО? Перечислите основные категории ПО и объясните особенности процесса конструирования для каждой из них.
2.Дайте определение БД, а также определение иерархической, сетевой, реляционной, объектно ориентированной, объектно-реляционной БД.
3.В чем отличие «толстого клиента» от «тонкого»?
4.Какие понятия входят в модель реляционной БД? Перечислите компоненты реляционной модели данных.
5.Какие задачи решает проектирование БД?
6.Дайте определение концептуального (инфологического) проектирования.
7.Опишите принцип построения ER-диаграммы для концептуальной модели данных.
8.Дайте определение даталогического проектирования. Опишите принципы построения ER-диаграммы для даталогической модели данных.
9.Дайте определение физического проектирования БД.
10.Каковы особенности конструирования логики работы с данными для СУБД?
11.Расскажите о безопасности БД. Каковы основные варианты обеспечения защиты данных?
12.Что такое SQL-инъекции, как можно защитить от них приложение?
Литература
1.Программная инженерия: учебник / В. А. Антипов и др.; под ред.
Б.Г. Трусова. М.: Академия, 2014. 282 с.
2.Соммервилл И. Инженерия программного обеспечения. 6-е изд. / пер. с англ. М.: Изд. дом «Вильямс», 2002. 624 с.
3.Гецци К., Джазаейри М., Мандриоли Д. Основы инженерии программного обеспечения. 2-е изд. / пер. с англ. СПб.: БХВ-Петербург, 2005.
832 с.
50