Разработка приложений

И.В. Гаврилова

Разработка приложений

Учебное пособие

4-е издание, стереотипное

Москва
Издательство «ФЛИНТА» 
2022

УДК 681.142.1.01
ББК З97
         Г12

Р е ц е н з е н т ы: 

Декан факультета автоматики и  вычислительной техники, зав. 
кафедрой вычислительной техники и прикладной математики 
Магнитогорского государственного технического университета, 
доктор технических наук, профессор  
Д.Х. Девятов 

Декан факультета информатики Челябинского государственного 
педагогического университета,  
доктор педагогических наук, профессор 

Г12       

Гаврилова И.В.
    Р    азработка приложений : учебное пособие / И.В. Гаврилова. — 4-е изд., 
стер. — Москва : ФЛИНТА, 2022. — 242 c. — ISBN 978-5-9765-1482-9. — 
Текст : электронный.-86781-430-0

В учебном пособии описан процесс разработки приложений 
информационных систем. Большое внимание уделено архитектуре и 
технологиям 
разработки 
приложений: 
интерфейсам 
прикладного 
программирования, механизмам доступа к данным. Рассматриваются 
методики 
разработки 
пользовательского 
интерфейса. 
Изложение 
материала 
сопровождается 
большим 
количеством 
иллюстраций, 
предлагаются вопросы для самопроверки, а также практикум, в котором 
нашли своё воплощение теоретические вопросы. 
Работа ориентирована на студентов очного и заочного отделения, 
изучающих проблемы разработки приложений информационных систем, 
разработки 
баз 
данных, 
проблемы 
стандартизации 
в 
области 
информационных систем, моделирования бизнес-процессов. 

УДК 681.142.1.01
ББК З97 

© Попова И.В., 2017
© Издательство «ФЛИНТА», 2017

Д.Ш. Матрос

ISBN 978-5-9765-1482-9

 
- 3 - 

СОДЕРЖАНИЕ 

ВВЕДЕНИЕ ............................................................................................... 6 

ГЛАВА 1. СТАНДАРТЫ И МЕТОДОЛОГИИ РАЗРАБОТКИ 
ПРИЛОЖЕНИЙ ......................................................................................... 9 

1.1. Стандарты разработки приложений ........................................................ 10 

Вопросы для самопроверки .............................................................................. 20 

1.2. Методологические подходы к разработке сложных систем ................ 21 
1.2.1. Содержание методологии разработки приложений ............................. 22 
1.2.2. Структурная методология ....................................................................... 29 
1.2.2.1. Методы разработки структуры программы .................................... 31 
1.2.2.2. Порядок разработки модуля ............................................................. 36 
1.2.3. Объектно-ориентированная методология ............................................. 38 
1.2.4. RAD-методология .................................................................................... 48 
1.2.5. Гибкие методологии разработки сложных систем ............................... 50 

Вопросы для самопроверки .............................................................................. 52 

Библиографический список .............................................................................. 55 

ГЛАВА 2. АРХИТЕКТУРА И ТЕХНОЛОГИИ РАЗРАБОТКИ 
ПРИЛОЖЕНИЙ ....................................................................................... 57 

2.1. Архитектура приложения. .......................................................................... 57 
2.1.1. Понятие архитектуры приложения ........................................................ 57 
2.1.2. Подходы к классификации архитектур ................................................. 58 
2.1.3. Архитектура клиент-сервер. ................................................................... 62 
2.1.3.1. Двухзвенная архитектура клиент-сервер ........................................ 63 
2.1.3.2. Трехзвенная архитектура клиент-сервер ........................................ 65 
2.1.3.3. Пятизвенная архитектура клиент-сервер ........................................ 68 

Вопросы для самопроверки .............................................................................. 69 

2.2. Технологии разработки приложений ....................................................... 71 
2.2.1. COM (Component Object Model) ............................................................. 73 
2.2.1.1. Именование потенциальных COM-объектов ................................. 76 
2.2.1.2. Интерфейсы COM ............................................................................. 79 
2.2.1.3. Серверы объектов СОМ ................................................................... 83 
2.2.2. CORBA (Common Object Request Broker Architecture) ........................ 84 

Вопросы для самопроверки .............................................................................. 90 

2.3. Средства разработки приложений ............................................................ 92 
2.3.1. Средства разработки, ориентированные на конкретные СУБД ......... 95 
2.3.2. Средства разработки, универсальные по отношению к СУБД ........... 96 

Вопросы для самопроверки .............................................................................. 98 

 
- 4 - 

Библиографический список .............................................................................. 99 

ГЛАВА 3. РЕАЛИЗАЦИЯ ЛОГИКИ ОБРАБОТКИ И ПРЕДСТАВЛЕНИЯ 
ДАННЫХ ............................................................................................... 101 

3.1. Реализация логики обработки данных на стороне сервера ............... 102 
3.1.1. Реализация бизнес-логики с помощью хранимых процедур ............ 102 
3.1.2. Реализация логики обработки данных с помощью триггеров. ......... 112 

Вопросы для самопроверки ............................................................................. 121 

3.2. Интерфейсы прикладного программирования .................................... 123 
3.2.1. Универсальные API ............................................................................... 125 
3.2.1.1. Open Database Connectivity (ODBC) .............................................. 126 
3.2.1.2. Java Database Connectivity (JDBC) ................................................. 130 
3.2.1.3. OLE DB ............................................................................................. 134 
3.2.2. Механизмы доступа к данным .............................................................. 135 
3.2.2.1. BDE (Borland Database Engine) ...................................................... 136 
3.2.2.2. ADO (Active X Data Objects) .......................................................... 137 

Вопросы для самопроверки ............................................................................. 140 

3.3. Разработка пользовательского интерфейса .......................................... 144 
3.3.1. Принципы разработки пользовательского интерфейса ..................... 144 
3.3.2. Подходы к разработке пользовательского интерфейса ..................... 150 
3.3.3. Стили графического пользовательского интерфейса ........................ 155 
3.3.3.1. Графический пользовательский интерфейс (GUI) ....................... 155 
3.3.3.2. Пользовательский Web-интерфейс (WUI) .................................... 157 
3.3.3.3. Пользовательский интерфейс карманных устройств (НUI) ....... 159 
3.3.3.4. Признаки хорошего пользовательского интерфейса ................... 159 

Вопросы для самопроверки ............................................................................. 161 

Библиографический список ............................................................................ 163 

ГЛАВА 4. ПРАКТИКУМ ........................................................................ 166 

4.1. Практическая работа 1. Эскизный проект ........................................... 166 

4.2. Практическая работа 2. Правила данных: описание ......................... 167 

4.3. Практическая работа 3. Определение размера базы данных ............ 171 

4.4. Практическая работа 4. Правила процессов ........................................ 172 

4.5. Практическая работа 5. Построение матрицы «Функции-сущности»
 ............................................................................................................................... 176 

4.6. Практическая работа 6. Описание сценария работы приложения .. 177 

4.7. Практическая работа 7. Разработка спецификации модулей ........... 180 

4.8. Практическая работа 8. Разработка интерфейса приложения ......... 185 

4.9. Практическая работа 9. Организация доступа к данным ................. 189 

4.10. Практическая работа 10 .Обработка ошибок . ................................... 196 

4.11. Практическая работа 11. Создание отчётов . ..................................... 197 

Библиографический список . .......................................................................... 206 

ОТВЕТЫ . ................................................................................................ 208 

ГЛОССАРИЙ . ......................................................................................... 209 

ПРИЛОЖЕНИЯ . ..................................................................................... 220 

 
- 6 - 

Введение 

Завершающей стадией создания проекта информационной системы является детальное проектирование, к которому относятся разработка приложений, интеграция системы и ее квалификационное тестирование. Существует множество подходов к данному процессу, что обусловлено принятым в 
команде разработчиков стилем, складывающимся из привычек и особенностей работы конкретных специалистов. Тем не менее, есть тип документов, 
регламентирующих данный процесс. Это международные и государственные 
стандарты, направленные на определение требований к процессам разработки, а так же методологии, описывающие что, как и в каком порядке надо делать. 
Детальное проектирование включает в себя разработку спецификаций 
каждой компоненты системы, разработку требований к тестам и плана интеграции компонент, а также построение моделей иерархии программных модулей и межмодульных взаимодействий и проектирование внутренней структуры модулей. К этому моменту должна быть построена модель базы данных 
приложения: полученная в процессе системного проектирования информационная модель сначала преобразуется в логическую, а затем в физическую 
модель данных. После этого для разработчиков информационной системы 
создается пробная база данных, с которой начинают работать кодировщики. 
В идеале к моменту начала разработки приложений модель данных должна 
быть устойчива. 
Проектирование базы данных не может быть оторвано от проектирования модулей и приложений, поскольку бизнес-правила могут создавать объекты в базе данных, например серверные ограничения (constraints), а также 
хранимые процедуры и триггеры, – в этом случае часто говорят, что часть 
бизнес-логики переносится в базу данных. 
Поскольку информационная система редко разрабатывается с нуля, то 
возникает проблема наследования данных из старых систем, которые уже 
выполняют какие-либо задачи автоматизации бизнеса, в новую систему. Другими словами, при интеграции новой системы необходимо перенести ценные 
данные, хранящиеся в старой информационной системе, в новую, то есть 
проектировать механизмы конвертирования данных. Кроме этого, необходимо спроектировать обмен данными с внешними системами.  

 
- 7 - 

Параллельно с проектированием схемы базы данных требуется выполнить проектирование процессов, чтобы получить спецификации всех модулей. Если часть бизнес-логики хранится в базе данных (ограничения, триггеры, хранимые процедуры), то оба эти процесса проектирования тесно связаны. Главная цель проектирования приложений заключается в отображении 
функций, полученных на этапе анализа, в модули информационной системы. 
Определения модулей раскрываются в технической спецификации программ. 
На этапе системного проектирования разработан перечень функций, 
которые будут реализованы, при этом функциональная модель, как правило, 
дополняется диаграммами потока данных и изменения состояний. На этапе 
детального проектирования этот перечень еще раз анализируется и корректируется. Однозначное соответствие между функцией и модулем вряд ли возможно. Дело в том, что на этапе системного анализа функции организованы 
по бизнес-категориям, а на этапе детального проектирования их придется реорганизовывать для упрощения разработки. Как правило, не бывает взаимно 
однозначного отображения функций на модули. Зачастую схожие по выполняемым действиям функции объединяют, даже если у них разный контекст. 
Некоторые сложные функции разбивают на более простые модули. Некоторые функции преобразуют в ограничения базы данных (constraints, или триггеры и хранимые процедуры). Каких-то общих способов отображения функций на модули не существует. Проектировщики часто меняют количество, 
состав модулей в течение процесса проектирования, и это правило, а не исключение. 
Одной из основных частей функционального проектирования является 
определение спецификаций модулей. Спецификации модулей различают по 
степени детализации и содержанию даже в рамках одного проекта. Определяют, сколько времени требуется для того, чтобы сгенерировать тот или иной 
модуль, сколько необходимо на тестирование того или иного модуля, а также 
на тестирование совокупности сгенерированных модулей. Кроме того, следует разработать специальные метрики - шаблоны, которые позволяют оценить, 
сколько времени потребуется на создание исходного кода модуля.  
Одна из важнейших проблем при создании проектировании приложений - размещение логики обработки. В отчетах аналитиков часто смешиваются три группы правил: правила для данных, процессов и интерфейса. На 
этапе проектирования эти правила предстоит выделить. 

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

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

Один из приемов построения расширяемых систем состоит в создании 

независимости двух слоев: обработки запросов и интерфейса, предоставляемого пользователю. Аналогичная независимость реализуется для слоя функций, обеспечивающих вызовы интерфейса, предоставляемого СУБД для выполнения запросов. Очень важен слой функций обработки ошибок. Для 
больших проектов важно наличие функций мониторинга работы приложений. Подобные модули могут быть реализованы в виде локальных агентов, 
каждый из которых работает на одном сервере, а сами они обмениваются 
информацией друг с другом и центральной программой управления. 

В процессе реализации модулей работа проектировщиков не заверше
на. Довольно часто разработчик сталкивается с медленно работающими или 
не реализуемыми в данной схеме запросами. Подобные ситуации инициируют изменение модели данных, а значит, и информационной модели. Однако 
изменение информационной модели производится не только по этой причине. Хорошему проектировщику необходим практический опыт работы с 
аппаратным и программным обеспечением — вот одна из причин участия 
проектировщиков в составе групп разработчиков. 

 
- 9 - 

Глава 1.  Стандарты и методологии разработки 

приложений 

Существует множество подходов к разработке приложений, что обусловлено принятым в команде разработчиков стилем, складывающимся из 
привычек и особенностей работы конкретных специалистов. Тем не менее, 
есть тип документов, регламентирующих данный процесс. Это международные и государственные стандарты, направленные на определение требований 
к процессам разработки, а так же методологии, описывающие что, как и в каком порядке надо делать. 
ГОСТы, как правило, не описывают сами процессы разработки программного обеспечения. Они формулируют определенные требования к ним, 
которым в той или иной степени соответствуют различные методологии. 
Среди стандартов наибольший интерес для отечественного производителя 
представляют, конечно, ГОСТы 19-ой и 34-ой серий и ГОСТ Р ИСО/МЭК 
12207. 
Кроме требований стандарты определяют основные понятия, используемые при разработке информационных систем; при этом существует возможность проследить иерархию конкретного термина. Следует отметить, что 
трактовки терминов разными стандартами отличаются. Например, в 
ИСО/МЭК 2382-1, ИСО/МЭК 2382-20 и  ИСО 8402 Программное средство 
понимается как программа или логически связанная совокупность программ, 
снабженная программной документацией. В ГОСТах 19й серии программные средства – это набор компьютерных программ, процедур и, возможно, 
связанных с ними документации и данных.  
Объем понятия, выражаемого термином «программные средства», 
включает в себя как частный случай объем понятия «программное обеспечение», определяемого по ГОСТ 19781: «Программное обеспечение 
(Software): Интеллектуальный продукт, включающий программы, правила, и 
связанные данные, который при загрузке в область выполнения программы 
компьютера обеспечивает его функционирование». В свою очередь, частным 
случаем этого понятия могут выступать программное обеспечение автоматизированной системы (совокупность программ на носителях данных и 
программных документов, предназначенных для отладки, функционирования 
и проверки работоспособности автоматизированной системы) и прикладное 

 
- 10 - 

программное обеспечение (программное обеспечение, состоящее из отдельных прикладных программ и пакетов прикладных программ, предназначенных для решения различных задач пользователей; и автоматизированных систем, созданных на основе этих (пакетов) прикладных программ.)  
В профиле прикладной среды организации вычислений на супер-ЭВМ 
(PSE10-HIP) приложение понимается как «программное средство, предназначенное для решения прикладной проблемы (прикладное программное средство)». Таким образом, под приложением информационной системы в данном пособии будет пониматься следующее: одна или несколько (комплекс) 
прикладных программ, решающих задачи одного или нескольких конечных 
пользователей, реализующие некоторую функцию информационной системы. 

1.1.Стандарты разработки приложений 

Стандарт - нормативный документ по стандартизации, разработанный, 
как правило, на основе согласия, характеризующегося отсутствием возражений по существенным вопросам у большинства заинтересованных сторон, 
принятый (утвержденный) признанным органом (предприятием). 
Стандарты в РФ являются обязательными в пределах установленной 
сферы их действия и подразделяются на следующие категории: 

 государственные стандарты – ГОСТ; 

 отраслевые стандарты – ОСТ; 

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