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

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

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

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

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.Стандарты разработки приложений 

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

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

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

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

 
- 11 - 

стандарты организационно-методического характера обязательны только для 
предприятий и организаций министерства, их утвердившего. 
Стандарты предприятия обязательны только для предприятия (объединения), 
утвердившего данный стандарт. Стандарты предприятия могут распространяться 
на составные части разрабатываемых или изготавливаемых на 
предприятии изделий, внутренние нормы и правила в области управления и 
организации производства, управления качеством продукции; оснастку и инструмент, 
типовые технологические процессы, методики измерений и контроля. 

Организационным и технологическим основанием для автоматизации 
являются корпоративные стандарты – единые правила организации, технологии 
и управления – в качестве которых могут использоваться отраслевые, 
национальные, международные стандарты. 
Создание программных продуктов – трудоемкий процесс, основанный 
на определенной технологии и инструментарии его разработки. При этом 
важно отличать хороший проект разработки программного обеспечения от 
посредственного. Существует много способов такого отличия. Можно оценить 
вид экрана, поведение приложения, информационно-логическую модель 
предметной области, структуру внутренних таблиц, код программы. Каждый 
из этих пунктов несет определенную информацию о приложении и его разработчиках. 
Несомненный успех проекту принесет соблюдение стандартов, 
применяемых при создании приложения. Стандарты не стесняют творчество 
разработчика, а вносят в проект определенность, понимание используемых 
методов, облегчают общение между программистами. Важно иметь общий 
язык и методы разработки системного проекта и написания кодов. Это облегчает 
подключение к проекту новых разработчиков, так как позволяет заранее 
знакомить их с используемыми терминами и методами.  
Государственных стандартов, регламентирующих написание кода, не 
существует, поскольку невозможно описать всё разнообразие условий и требований 
к приложениям информационных систем всех предметных областей. 
Однако есть ГОСТы, определяющие жизненный цикл программных средств, 
и стандарты языков программирования, оформления программной документации, 
есть стандарты пользовательского интерфейса. Стандарты жизненного 
цикла разбивают процесс разработки системы на этапы и приводят в соответствие 
каждому набор документов. Стандарты языков программирования со-

 
- 12 - 

держат правила представления программ, синтаксис и ограничения языка, 
семантические правила, для интерпретации программ, ограничения и препятствия, 
налагаемые согласованной реализацией. Любой из государственных 
стандартов затем уточняется и адаптируется к конкретным условиям компании-
разработчика, тем самым, формируя корпоративный стандарт, который  
включает в себя соглашения по оформлению кода программы. Они включают 
четыре основные области: соглашения об именовании переменных, об именовании 
объектов, о форматировании кода, комментарии. 
Соглашения об именовании переменных. В первую очередь нужно 
ввести способ выбора имен переменных. Это важно, потому что в большинстве 
языков программирования требуется объявлять переменные и типы их 
данных перед использованием. В других языках программирования переменная 
может быть инициализирована как числовая в одной точке программы, а 
затем изменена в другой. Использование соглашений об именовании переменных 
важно для раскрытия намерений программиста. Разработчик может 
передать в своем программном коде дополнительные сведения (например, о 
типе данных и области видимости переменной). Такая информация пригодиться 
в дальнейшей работе с этим кодом.  
Одно из наиболее популярных соглашений такого рода – «венгерская 
нотация» или «венгерский стандарт». Он назван так по национальности самого 
известного (после Билла Гейтса) программиста Microsoft - Чарльза Си-
мони. Согласно «венгерскому стандарту», имя переменной должно состоять 
из двух частей : префикса, обозначающего тип данных, и собственно имени, 
которое назначает программист. Чтобы стандарт содержал как можно больше 
сведений, надо добавить и другой аспект: область видимости переменной. 
Переменная может быть локальной (Local) - добавляемый префикс L, частной (
Private) - префикс Р и т.п. Область видимости показывает время создания 
и существования переменной, а также определяет, кто или что может ее 
изменить. Обычно для области видимости и типа данных используется нижний 
регистр, а значимые слова в имени переменной начинаются с большой 
буквы. Назначение такого приема - сделать код удобочитаемым.  
Соглашения об именовании объектов. Так как в последнее время 
большую популярность получили объектно-ориентированные языки, то появилась 
потребность в новом наборе соглашений - об именовании объектов. 
Соглашения об именовании объектов служат той же цели, что и соглашения 

 
- 13 - 

об именовании переменных: они позволяют выявить тип объекта, который 
встречается в коде. Разработчики используют эти соглашения, чтобы давать 
имена объектам, с помощью которых создаются определения классов и форм. 
Имя объекта строится так же, как и имя переменной: сначала префикс, обозначающий 
тип объекта, а затем имя. Например, cmdEdit – объект, принадлежащий 
классу CommandButton (командная кнопка); txtLastName – объект, 
принадлежащий классу TextBox (область ввода текста) и т.п.  
Соглашения о форматировании кодов. Форматирование кода делает 
код программы более удобным для чтения и понимания другими разработчиками. 
Текст должен быть набран с отступами и содержать много свободного 
пространства. Человеческому глазу нужны промежутки между объектами, 
тогда он их сможет различать. В соответствии с соглашениями об использовании 
требуемых регистров в названиях всех команд, функций, методов и 
свойств названия констант пишут в верхнем регистре, для переменных и объектов 
первая буква заглавная, остальные строчные. Соглашения об именовании 
должны быть гибкими: если для программы больше подходят другие соглашения, 
нужно использовать их. Главное – иметь стандарт. 
Соглашения о кодировании должно также определять, как происходит 
обращение к методам. Например, Visual FoxPro позволяет в этом случае не 
применять скобки, однако нужно стараться использовать синтаксис языка 
полностью. Также Visual FoxPro позволяет при желании употреблять только 
первые четыре буквы команды, но установленный стандарт должен требовать 
применения полных ключевых слов и скобок при вызове методов. Не 
исключено, что в будущих версиях Visual FoxPro понадобятся полные ключевые 
слова или скобки.  
О необходимости написания комментариев в программе говорят и 
пишут давно. Комментарии помогут разобраться в программе другим разработчикам, 
помогут легко вносить изменения при расширении функциональных 
возможностей, при отладке программы. Каждый комментарий должен 
находиться там же, где и описываемая строка. Часто блока на псевдокоде в 
начале программы бывает недостаточно, требуются комментарии особенно 
для сложных объектов.  

Разработка стандартов графического интерфейса пользователя. 
Графический интерфейс пользователя (Graphics User Interface - GUI) - является 
обязательным компонентом большинства современных программных