Методология проектирования программных продуктов

18.1. МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ

КЛАССИФИКАЦИЯ МЕТОДОВ ПРОЕКТИРОВАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ

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

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

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

• степень автоматизации проектных работ;

• принятая методология процесса разработки.

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

• методы традиционного (неавтоматизированного) проектирования;

Рекомендуемые материалы

• методы автоматизированного проектирования (CASE-технология и ее элементы).
Неавтоматизированное проектирование алгоритмов и программ преимущественно

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

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

Автоматизированное проектирование алгоритмов и программ возникло с необходи­мостью уменьшить затраты на проектные работы, сократить сроки их выполнения, создать типовые "заготовки" алгоритмов и программ, многократно тиражируемых для различных разработок, координации работ большого коллектива разработчиков, стандартизации алго­ритмов и программ.

Автоматизация проектирования может охватывать все или отдельные этапы жизнен­ного цикла программного продукта, при этом работы этапов могут быть изолированы друг

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

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

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

• структурное проектирование программных продуктов;

• информационное моделирование предметной области и связанных с ней приложений;

• объектно-ориентированное проектирование программных продуктов.

В основе структурного проектupования лежит последовательная деком­позиция, целенаправленное структурирование на отдельные составляющие. Начало разви­тия структурного проектирования алгоритмов и программ падает на 60-е гг. Методы структурного проектирования представляют собой комплекс технических и организацион­ных принципов системного проектирования.

Типичными методами структурного проектирования являются:

• нисходящее проектирование, кодирование и тестирование программ;

• модульное программирование;

• структурное проектирование (программирование) и др.
В зависимости от объекта структурирования различают:

• функционально-ориентированные методы — последовательное разложение задачи
или целостной проблемы на отдельные, достаточно простые составляющие, обладаю­щие функциональной определенностью;

• методы структурирования данных.

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

Для методов структурирования данных осуществляется анализ, структурирование и создание моделей данных, применительно к которым устанавливается необходимый состав функций и процедур обработки. Программные продукты тесно связаны со структурой обра­батываемых данных, изменение которой отражается на логике обработки (алгоритмах) и обязательно требует перепроектирования программного продукта.

Структурный подход использует:

• диаграммы потоков данных (информационно-технологические схемы) — показывают
процессы и информационные потоки между ними с учетом "событий", инициирующих
процессы обработки;

• интегрированную структуру данных предметной области (инфологическая модель,
ER-диаграммы);

• диаграммы декомпозиции — структура и декомпозиция целей, функций управления,
приложений;

• структурные схемы — архитектура программного продукта в виде иерархии взаимо­
связанных программных модулей с идентификацией связей между ними, детальная
логика обработки данных программных модулей (блок-схемы).

Для полного представления о программном продукте необходима также текстовая ин­формация описательного характера.

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

Один из основоположников информационной инженерии — Дж.Мартин — выделяет следующие составляющие данного подхода:

• информационный анализ предметных областей (бизнес-областей);

• информационное моделирование — построение комплекса взаимосвязанных моделей
данных;

• системное проектирование функций обработки данных;

• детальное конструирование процедур обработки данных.

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

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

•         датапогические модели, ориентированные на среду хранения и обработки данных.
Даталогические модели имеют логический и физический уровни представления. Физический уровень соответствует организации хранения данных в памяти компьютера. Логичес­кий уровень данных применительно к СУБД реализован в виде:

• концептуальной модели базы данных — интегрированные структуры данных под уп­
равлением СУБД;

• внешних моделей данных — подмножество структур данных для реализации прило­
жений.

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

Выбор средств реализации базы данных определяет вид даталогических моделей и, следовательно, алгоритмы преобразования данных. В большинстве случаев используется реляционное представление данных базы данных и соответствующие реляционные языки для программирования (манипулирования) обработки данных СУБД и реализации алгорит­мов обработки. Данный подход использован во многих CASE-технологиях.

Объектно-ориентированный подход к проектированию программных продуктов осно­ван на:

• выделении классов объектов;

• установлении характерных свойств объектов и методов их обработки;

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

Объектный подход при разработке алгоритмов и программ предполагает:

• объектно-ориентированный анализ предметной области;

• объектно-ориентированное проектирование.

Объектно-ориентированный анализ — анализ предметной области и вы­деление объектов, определение свойств и методов обработки объектов, ус­тановление их взаимосвязей.

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

1

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

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

Объектно-ориентированная технология разработки программных продуктов объеди­няет данные и процессы в логические сущности — объекты, которые имеют способность наследовать характеристики (методы и данные) одного или более объектов, обеспечивая тем самым повторное использование программного кода. Это приводит к значительному уменьшению затрат на создание программных продуктов, повышает эффективность жиз­ненного цикла программных продуктов (сокращается длительность фазы разработки).При выполнении программы объекту посылается сообщение, которое инициирует обработку данных объекта.

ЭТАПЫ СОЗДАНИЯ ПРОГРАММНЫХ ПРОДУКТОВ

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

1. Составление технического задания на программирование

Данная работа соответствует этапу анализа и спецификации программ жизненного цикла программных продуктов.

При составлении технического задания требуется:

• определить платформу разрабатываемой программы — тип операционной системы
(например, для IBM PC-совместимых машин делается выбор операционной среды:
MS DOS, Windows, Windows NT либо Unix, OS/2);

• оценить необходимость сетевого варианта работы программы (определяется про­граммное обеспечение (ПО) вычислительной сети — Windows NT, допустимая номен­клатура программного обеспечения сетевой обработки);

• определить необходимость разработки программы, которую можно переносить на различные платформы;

• обосновать целесообразность работы с базами данных под управлением СУБД.

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

2. Технический проект

На данном этапе выполняется комплекс наиболее важных работ, а именно:

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

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

• разрабатывается внутренняя структура программного продукта, образованная отдель­ными программными модулями;

•         осуществляется выбор инструментальных средств разработки программных модулей.
Работы данного этапа в существенной степени зависят от принятых решений по тех­нической части системы обработки данных и операционной среде, от выбранных инструментальных средств   проектирования алгоритмов и программ, технологии работ.

Пример 18.2. Для создания MS DOS-приложений может быть использован язык про­граммирования Visual Basic for DOS Standard, Fortran 5.1, Visual C++ for Windows. Если необходима переносимость программ на другие ЭВМ или другие операционные платформы, выбирается среда Windows NT.

При разработке программ, работающих в среде Windows, возможно применение тех­нологии OLE 2.0 для создания приложений, включающих объекты других приложе­ний. Определяется способ использования объектов: внедрение (embedding) или связывание (linking).

Приложение может работать с базами данных различных СУБД, для этого служит стандартная технология интерфейса Open Database Connectivity (ODBC). Работа в ре­жиме телекоммуникаций обеспечивается стандартной технологией Messaging Applica­tion Program Interface (MAPI).

3.   Рабочая документация (рабочий проект)

На данном этапе осуществляется адаптация базовых средств программного обеспечения (операционной системы, СУБД, методо-ориентированных ППП, инструментальных сред конечного пользователя — текстовых редакторов, электронных таблиц и т.п.). Выполняется разработка программных модулей или методов обработки объектов — собственно програм­мирование или создание программного кода. Проводятся автономная и комплексная отлад­ка программного продукта, испытание работоспособности программных модулей и базовых программных средств. Для комплексной отладки готовится контрольный пример, который позволяет проверить соответствие возможностей программного продукта задан­ным спецификациям.

Основной результат работ этого этапа — также создание эксплуатационной докумен­тации на программный продукт:

• описание применения — дает общую характеристику программного изделия с указани­ем сферы его применения, требований к базовому программному обеспечению, ком­плексу технических средств;

• руководство пользователя — включает детальное описание функциональных возмож­ностей и технологии работы с программным продуктом. Данный вид документации
ориентирован на конечного пользователя и содержит необходимую информацию для
самостоятельного освоения и нормальной работы пользователя (с учетом требуемой
квалификации пользователя);

•         руководство программиста (оператора) — указывает особенности установки (ин­сталляции) программного продукта и его внутренней структуры — состав и назначе­ние модулей, правила эксплуатации и обеспечения надежной и качественной работы
программного продукта.

В ряде случаев на данном этапе для программных продуктов массового применения создаются обучающие системы, демоверсии, гипертекстовые системы помощи.

4. Ввод в действие

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

СТРУКТУРА ПРОГРАММНЫХ ПРОДУКТОВ

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

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

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

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

Таким образом, структуризация программных продуктов преследует основные цели:

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

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

• контролировать трудозатраты и стоимость проектных работ и др.

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

Некоторые программные продукты используют модули из готовых библиотек стан­дартных подпрограмм, процедур, функций, объектов, методов обработки данных.

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

Рис. 18.1.  Структура программного продукта

Среди множества модулей различают:

• головной модуль — управляет запуском программного продукта (существует в
единственном числе);

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

• рабочие модули — выполняют функции обработки;

• сервисные модули и библиотеки, утилиты — осуществляют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули.

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

Каждый модуль может оформляться как самостоятельно хранимый файл; для функци­онирования программного продукта необходимо наличие программных модулей в полном составе.

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

ППП (application program package) — это система программ, предназна­ченных для решения задач определенного класса.

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

ПРОЕКТИРОВАНИЕ ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ

Диалоговый режим

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

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

Системы, поддерживающие диалоговые процессы, классифицируются на:

• системы с жестким сценарием диалога — стандартизированное представление ин­
формации обмена;

• дескрипторные системы — формат ключевых слов сообщений;

• тезаурусные системы — семантическая сеть дескрипторов, образующих словарь сис­темы (аналог — гипертекстовые системы);

• системы с языком деловой прозы — представление сообщений на языке, естественном
для профессионального пользования.

Наиболее просты для реализации и распространены диалоговые системы с жестким сценарием диалога, которые представлены в виде:

• меню — диалог инициируется программой; пользователю предлагается выбор альтер­нативы функций обработки из фиксированного перечня; предоставляемое меню может
быть иерархическим и содержать вложенные подменю следующего уровня;

• действия запрос-ответ — фиксирован перечень возможных значений, выбираемых из
списка, или ответы типа Да/Нет;

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

Диалоговый процесс управляется согласно созданному сценарию, для которого опре­деляются:

• точки (момент, условие) начала диалога;

• инициатор диалога — человек или программный продукт;

• параметры и содержание диалога — сообщения, состав и структура меню, экранные
формы и т.п.;

• реакция программного продукта на завершение диалога.
Описание сценария диалога выполняют:

• блок-схема, в которой предусмотрены блоки выдачи сообщений и обработки получен­ных ответов;

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

• специализированные объектно-ориентированные языки построения сценариев.

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

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

В ряде СУБД и электронных таблиц, текстовых редакторов существуют различные типы диалоговых окон, содержащих разнообразные объекты управления:

• тексты сообщения;

• поля ввода информации пользователя;

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

• кнопки и т.п.

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

Графический интерфейс пользователя

Графический интерфейс пользователя (Graphics User Interface — GUI) — ГИП является обязательным компонентом большинства современных программных про­дуктов, ориентированных на работу конечного пользователя. К графическому интерфейсу пользователя предъявляются высокие требования как с чисто инженерной, так и с художе­ственной стороны разработки, при его разработке ориентируются на возможности человека. Наиболее часто графический интерфейс реализуется в интерактивном режиме работы пользователя для программных продуктов, функционирующих в среде Windows, и строится в виде системы спускающихся меню с использованием в качестве средства манипуляции мыши и клавиатуры. Работа пользователя осуществляется с экранными формами, содержа­щими объекты управления, панели инструментов с пиктограммами режимов и команд об­работки.

Пример 18.3. Средствами редактора диалогов Microsoft Word Dialog Editor построено диалоговое окно, обеспечивающее графический интерфейс пользователя. К числу типовых объектов управления графического интерфейса относятся:

• метка (label) — постоянный текст, не подлежащий изменению при работе пользо­вателя с экранной формой (например, слова Фамилия Имя Отчество);

• текстовое окно (text box) — используется для ввода информации произвольного вида, отображения хранимой информации в базе данных (например, для ввода фа­милии студента);

• рамка (frame) — объединение объектов управления в группу по функциональному или другому принципу (например, для изменения их параметров);

• командная кнопка (command button) — обеспечивает передачу управляющего воз­действия, например, кнопки <Cancel>, <ОК>, <Отмена>; выбор режима обработки типа<Ввод>, <Удаление>, <Редактирование>, <Выход> и др.;

• кнопка-переключатель <option button> — для альтернативного выбора кнопки из группы однотипных кнопок (например, семейное положение)',

• помечаемая кнопка <check button> — для аддитивного выбора несколько кнопок из группы однотипных кнопок (например, факультатив для посещения)',

• окно-список (list box) — содержит список альтернативных значений для выбора (например, «Спортивная секция»);

• комбинированное окно (combo box) — объединяет возможности окна-списка и текстового окна (например, «Предметы по выбору» — можно указать новый предмет или выбрать один из предлагаемого списка);

• линейка горизонтальной прокрутки — для быстрого перемещения внутри длинно­го списка или текста по горизонтали;

• линейка вертикальной прокрутки — для быстрого перемещения внутри длинного списка или текста по вертикали;

• окно-список каталогов;

• окно-список накопителей;

• окно-список файлов и др.

Стандартный графический интерфейс пользователя должен отвечать ряду требований:

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

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

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

• графические объекты сохраняют свое стандартизованное назначение и по возможнос­ти местоположение на экране.

18.2. СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ И ПРОГРАММИРОВАНИЕ

НИСХОДЯЩЕЕ ПРОЕКТИРОВАНИЕ

Memoд нисходящего проектирования предполагает последовательное разло­жение общей функции обработки данных на простые функциональные элементы ("сверху-вниз").

В результате строится иерархическая схема, отражающая состав и взаимоподчинен­ность отдельных функций, которая носит название функциональная структура алгоритма (ФСА) приложения.

Последовательность действий по разработке функциональной структуры алгоритма приложения:

• определяются цели автоматизации предметной области и их иерархия (цель-подцель);

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

• уточняется характер взаимосвязи приложений и их основные характеристики (инфор­мация для решения задач, время и периодичность решения, условия выполнения и др.);

• определяются необходимые для решения задач функции обработки данных;

• выполняется декомпозиция функций обработки до необходимой структурной слож­ности, реализуемой предполагаемым инструментарием.

Подобная структура приложения (рис. 18.2) отражает наиболее важное — состав и взаимосвязь функций обработки информации для реализации приложений, хотя и не рас­крывает логику выполнения каждой отдельной функции, условия или периодичность их вы­зовов.

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

Функции ввода-вывода информации рекомендуется отделять от функций вычисли­тельной или логической обработки данных.

По частоте использования функции делятся на:

• однократно выполняемые;

• повторяющиеся.

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

Пример 18.4. Некоторые функции, например Ф2, далее неразложимы на составляю­щие: они предполагают непосредственную программную реализацию. Другие функции, например Ф1, Фm, могут быть представлены в виде структурного объединения более простых функций, например Ф11, Ф12 и т.д. Для всех функций-: компонентов осуществляется самостоятельная программная реализация; составные функции (типа Ф1, Фm) реализуются как программные модули, управляющие функ­циями-компонентами, например, в виде программ-меню.

Рис. 18.2. - Функциональная структура приложения: Ц — цель; пЦ — подцель; П — приложение; Ф — функция

МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ

• Свойства модуля

Модульное программupование основано на понятии модуля — логически взаи­мосвязанной совокупности функциональных элементов, оформленных в виде отдельных программных модулей.

Модуль характеризуют:

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

Process — Output) — вход-процесс-выход;

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

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

•     слабые информационные связи с другими программными модулями — обмен инфор­мацией между модулями должен быть по возможности минимизирован;

•         обозримый по размеру и сложности программный элемент.

Таким образом, модули содержат определение доступных для обработки данных, опе­рации обработки данных, схемы взаимосвязи с другими модулями.

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

Модульная структура программных продуктов

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

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

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

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

• принятие основных решений в алгоритме выносится на максимально "высокий" по
иерархии уровень;

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

В результате дальнейшей детализации алгоритма создается функционально-модульная схема (ФМС) алгоритма приложения, которая является основой для программирования (рис. 18.3).

Рис. 18.3.  Функционально-модульная структура приложения

Пример 18.5. Некоторые функции могут выполняться с помощью одного и того же программного модуля (например, функции Ф] и Ф2).

• Функция Ф₃ реализуется в виде последовательности выполнения программных мо­дулей.

• Функция Ф_m реализуется с помощью иерархии связанных модулей.

• Модуль n управляет выбором на выполнение подчиненных модулей.

• Функция Ф_х реализуется одним программным модулем.

Состав и вид программных модулей, их назначение и характер использования в про­грамме в значительной степени определяются инструментальными средствами. Например, применительно к средствам СУБД отдельными модулями могут быть:

экранные формы ввода и/или редактирования информации базы данных;

отчеты генератора отчетов;

макросы;

стандартные процедуры обработки информации;

меню, обеспечивающее выбор функции обработки и др.

Алгоритмы большой сложности обычно представляются с помощью схем двух видов:

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

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

Наиболее часто детально проработанные алгоритмы изображаются в виде блок-схем согласно требованиям структурного программирования; при их разработке используются условные обозначения согласно ГОСТ 19.003-80 ЕСПД (Единая система программной документации). Обозначения условные графические, ГОСТ 19.002-80 ЕСПД. Схемы алго­ритмов и программ. Правила обозначения.

СТРУКТУРНОЕ ПРОГРАММИРОВАНИЕ

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

Рис. 18.4. Блок-схема алгоритма поиска в базе данных

В любой типовой структуре блок, кроме условного, имеет только один вход и выход, безусловный переход на блок с нарушением иерархии запрещен (оператор типа GoTo в структурном программировании не используется). Виды основных управляющих структур алгоритма приведены в табл. 18.1.

Пример 18.6. Алгоритм поиска в базе данных сведений о максимальном окладе со­трудников (рис. 18.4).

Таблица 18.1. Управляющие структуры алгоритмов

Типы управляющей структуры

Применение управляющей структуры

Последовательность

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

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

Альтернатива (условие выбора)

В блоке Условие содержится условие выбора альтернативы обработки. Каждая альтернатива выполняется 1 раз; выпол­нение одной из двух альтернатив — обязательно.

Развитием данного типа структуры является множественная альтернатива, когда последовательно прореряются условия выполнения определенных альтернатив. Если очередное усло­вие истинно, обрабатывается соответствующая ему альтерна­тива, после чего происходит выход. В противном случае — переход к проверке условия следующей альтернативы.

Если ни одно из условий не выполнилось, происходит выход.

Цикл ("пока")

В блоке Условие задается условие тела цикла — определен­ной обработки. Если условие не выполняется, цикл преры­вается и осуществляется выход.

Условие может содержать счетчик повторений тела цикла либо логическое условие.

Тело цикла — произвольная последовательность блоков (операторов) обработки.

18.3. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ

ОСНОВНЫЕ ПОНЯТИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

Метод объектно-ориентированного проектирования основывается на:

модели построения системы как совокупности объектов абстрактного типа данных;

модульной структуре программ;

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

Объектно-ориентированный подход использует следующие базовые понятия:

объект;

свойство объекта;

метод обработки;

событие;

класс объектов.

Объект — совокупность свойств (параметров) определенных сущностей и методов их обработки (программных средств).

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

Свойство — характеристика объекта, его параметр. Все объекты наделены определенными свойствами, которые в совокупности выделяют объект из множества других объектов.

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

Например, объект можно представить перечислением присущих ему свойств:

ОБЪЕКТ_А (свойство-1, свойство-2,...., свойство-k).

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

ОБЪЕКТОВ (...свойство-n, свойство-m,...свойство-r,...)
ОБЪЕКТ_С (...свойство-n,...................... , свойство-r,...).

Одним из свойств объекта являются метод его обработки.

Метод — программа действий над объектом или его свойствами.

Метод рассматривается как программный код, связанный с определенным объектом; осуществляет преобразование свойств, изменяет поведение объекта.

Объект может обладать набором заранее определенных встроенных методов обработ­ки, либо созданных пользователем или заимствованных в стандартных библиотеках, кото­рые выполняются при наступлении заранее определенных событий, например, однократное нажатие левой кнопки мыши, вход в поле ввода, выход из поля ввода, нажатие определен­ной клавиши и т.п.

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

Событие — изменение состояния объекта.

Внешние события генерируются пользователем (например, клавиатурный ввод или нажатие кнопки мыши, выбор пункта меню, запуск макроса); внутренние события генери­руются системой.

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

Класс — совокупность объектов, характеризующихся общностью применя­емых методов обработки или свойств.

Один объект может выступать объединением вложенных в него по иерархии других объектов.

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

В объектно-ориентированном программировании используется следующий формат за­писи работы с объектами:

ОБЪЕКТ.МЕТОД ОБЪЕКТ.СВОЙСТВО.МЕТОД

Программный продукт, созданный с помощью инструментальных средств объектно-ориентированного программирования, содержит объекты с их характерными свойствами, для которых разработан графический интерфейс пользователя. Как правило, работа с про­граммным продуктом осуществляется с помощью экранной формы, с объектами управле­ния, которые содержат методы обработки, вызываемые при наступлении определенных событий. Экранные формы также используются для выполнения заданий и перехода от одного компонента программного продукта к другому. Каждый объект управления облада­ет определенными свойствами, значения которых могут изменяться. Для объектов управле­ния уточняется перечень событий и создаются пользовательские методы обработки — программный код на языке программирования в виде событийных процедур.

МЕТОДИКА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

Существуют различные объектно-ориентированные технологии и методики проектирова­ния программных продуктов, которые должны обеспечить выполнение важнейших принци­пов объектного подхода:

• инкапсуляция (замыкание) свойств данных и программ в объекте;

• наследование;

• полиморфизм.

Инкапсуляция означает сочетание структур данных с методами их обработки в аб­страктных типах данных — классах объектов.

Класс может иметь образованные от него подклассы. При построении подклассов осу­ществляется наследование данных и методов обработки объектов исходного класса. Меха­низм наследования позволяет переопределить или добавить новые данные и методы их обработки, создать иерархию классов.

Полиморфизм — способность объекта реагировать на запрос (вызов метода) сообразно своему типу, при этом одно и то же имя метода может использоваться для различных клас­сов объектов.

Для различных методик объектно-ориентированного проектирования характерны сле­дующие черты:

• объект описывается как модель некоторой сущности реального мира;

• объекты, для которых определены места хранения, рассматриваются во взаимосвязи, и
применительно к ним создаются программные модули системы.

В процессе объектно-ориентированного анализа :

• осуществляется идентификация объектов и их свойств;

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

• определяются связи между объектами для образования классов;

• устанавливаются требования к интерфейсу с объектами.
Выделено четыре этапа объектно-ориентированного проектирования:

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

• разработка структуры классов, описывающей связь между классами и объектами;

• разработка диаграмм объектов, показывающих взаимосвязи с другими объектами;

• разработка внутренней структуры программного продукта.

КЛЮЧЕВЫЕ ПОНЯТИЯ

Ввод в действие

Структура программных продук­тов

Головной модуль

Графический интерфейс пользова­теля

Диалоговый режим

Информационная инженерия

Класс объектов

Метод обработки

Модульное программирование

Нисходящее проектирование

Объект

Объектно-ориентированный ана­лиз

Объектно-ориентированное проек­тирование

Рабочая документация

Свойство

Событие

Структурное программирование

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

Технический проект

Техническое задание на програм­мирование

Управляющий модуль

ВОПРОСЫ ДЛЯ САМОПРОВЕРКИ

1. Как классифицируются методы проектирования алгоритмов и программ?

2. Что характерно для неавтоматизированного проектирования алгоритмов и программ?

3. Что характерно для автоматизированного проектирования алгоритмов и программ?

4. Назовите основные этапы и работы по созданию программных продуктов.

5. Что такое внутренняя структура программного продукта?

6. Какие типы программных модулей существуют?

7. В чем различие головного, управляющего и функционального модулей?

8. Дайте определение пакета прикладных программ.

9. Каковы особенности диалогового режима работы программных продуктов?

10. Укажите основные свойства диалогового режима.

11. Дайте определение графического интерфейса пользователя.

12. Что такое объект управления в графическом интерфейсе пользователя?

13. Каковы основы структурного проектирования алгоритмов и программ?

14. Назовите методы структурного проектирования.

15. Что такое функциональная структура алгоритма?

16. Что такое модульное программирование?

17. Каковы свойства программного модуля?

Вместе с этой лекцией читают "ТЕМА 6. Организация системы управления охраной труда".

18. Назовите управляющие структуры, применяемые в структурном программировании.

19. В чем заключается метод информационного моделирования при разработке программ­
ных продуктов?

20. Что такое объектно-ориентированное проектирование?

21. Дайте определение объекта, свойства, класса объектов.

22. Что такое метод обработки объекта?

23. Что такое событийное программирование?