YourLib.net
Твоя библиотека
Главная arrow Информатика (Под общ. ред. А.Н. Данчула) arrow 4.2. Методы разработки программных средств
4.2. Методы разработки программных средств

4.2. Методы разработки программных средств

   Разработка программных средств различного назначения (далее для краткости — программ) состоит из трех фаз: анализа, проектирования и реализации. Основное назначение этих фаз:
   анализа — определить требования к программе: что она должна делать и в каких условиях работать;
   проектирования — определить составные части программы и порядок их взаимодействия: как они должны работать, чтобы удовлетворить разработанным на предыдущей фазе требованиям;
   реализации — согласно результатам проектирования написать программу на выбранном языке (реже — языках) программирования и отладить ее, т. е. добиться ее устойчивой правильной работы при различных вариантах исходных данных и режимах фун кционирован ия.
   В любой программе можно выделить три базисные составные части, каждая из которых является объектом разработки:
   1) данные;
   2) процессы;
   3) интерфейс.
   При разработке программного обеспечения АИС параллельно решаются и вопросы, связанные с созданием их информационного обеспечения.
   Фазы анализа и проектирования завершаются созданием документации, содержащей, в частности, набор моделей, описывающих базисные составные части разрабатываемой программы. Состав этого набора определяется выбранной методологией и методом разработки (см. п. 3.4).
   Например, на первой фазе разработки программы — фазе анализа — могут быть использованы процессно-ориентированные методы, которые относят к классу методов структурного анализа, базирующихся на двух принципах: декомпозиции и иерархического упорядочивания.
   На основе этих методов разрабатываются три группы моделей, описывающих:
   —  функции, которые должна выполнять программа;
   —  объекты предметной области (данные) и связи (отношения) между этими объектами (данными);
   —  поведение системы, зависящее от времени и внешних событий (в частности — от действий пользователей).
   Модели первой группы называются функциональными, третьей группы — событийными, второй — моделями данных.
   Основной упор в процессно-ориентированных методах делается на моделирование процессов обработки данных, что определяет ведущую роль функциональных моделей. Осуществляется последовательное разложение автоматизируемого процесса на отдельные, достаточно простые составляющие, объединенные общей структурой. Для построения функциональных моделей чаще всего используются:
   —  DFD (Data Flow Diagrams) — диаграммы потоков данных, выделяющие внешние источники и внешних потребителей информации, функции (задачи) обработки информации, хранилища данных (базы данных, файлы, массивы);
   —  метод функционального моделирования, входящий в методологию SADT (Structured Analysis and Design Technique), дающий возможность указать в модели исполнителя каждой из имеющихся функций, но не содержащий средств моделирования хранилищ данных.
   Иерархическая система моделей подобного класса позволяет описать с любой степенью подробности функции программы, информационные связи между ними, но не порядок и частоту их выполнения. Декомпозиция должна носить строго функциональный характер, т. е. отдельный элемент модели должен описывать законченную содержательную функцию обработки информации, которая предполагает определенный способ реализации ее на программном уровне. Степень детализации функций может быть различной. Функции ввода-вывода данных рекомендуется отделять от функций их вычислительной или логической обработки.
   Модели данных описывают перечень и структуры входных, выходных и хранимых данных программы. В АИС для построения моделей данных используются диаграммы «сущность-связь» — ERD (Entity Relationship Diagrams), отражающие выделенные объекты (сущности) предметной области, их признаки (атрибуты) и взаимосвязи. Именно этим моделям принадлежит ведущая роль при разработке программного и информационного обеспечения АИС.
   При анализе модели данных надо рассмотреть диапазоны изменения значений всех исходных данных, установить, при всех ли комбинациях их значений применимы имеющиеся методы обработки данных, какой вид могут принять результаты, в каких пределах будут находиться их значения. Такой анализ позволит заранее представить границы возможных значений результатов и обеспечить надежную работу программы.
   Событийные модели, разрабатываемые на основе так называемых диаграмм перехода состояний (см. п. 1.5), являются удобным средством описания взаимодействия (интерфейса) пользователя с программой. Они позволяют выделить множество процессов (подфункций), реализуемых программой, а также отделить их от функций, реализуемых пользователем.
   На этапе анализа требуется также выбрать методы решения задач, описать характер и режимы использования программы, оценить необходимость сетевого варианта ее работы, определить тип операционной системы, требования к комплексу технических средств и т. д.
   Анализ может осуществляться неавтоматизированным и автоматизированным (с использованием CASE-технологий) способами (см. пп. 3.4). Неавтоматизированно ведется разработка лишь небольших по трудоемкости и структурной сложности программ. Автоматизированная разработка необходима при создании больших и средних программных систем, когда необходимо скоординировать работу коллектива разработчиков, уменьшить затраты на проектные работы, сократить сроки их выполнения, гарантированно обеспечить высокое качество системы.
   В фазе проектирования модели, полученные в фазе анализа, получают свое развитие. Из блоков функциональной модели с использованием базовых конструкций структурного программирования и с учетом модели данных строятся блок-схемы алгоритмов, реализующих выполнение всех функций, описываемых этой моделью (см. п. 1.5).
   Графическое оформление алгоритмов регламентируется ГОСТ 19.003-80 ЕСПД (Единая система программной документации), обозначения условные графические — ГОСТ 19.002-80 ЕСПД «Схемы алгоритмов и программ. Правила обозначения».
   Анализ структуры алгоритмов с учетом частоты использования отдельных их фрагментов позволяет распределить эти фрагменты по различным функциональным элементам, которые будут решать различные, в том числе технологические, задачи и нести различную нагрузку в программной среде. Конструктивное оформление и способ взаимодействия этих функциональных элементов определяются принятой методологией проектирования и инструментальными средствами реализации программы.
   При использовании процессно-ориентированных методов функциональными элементами ПО появляются программные модули — относительно автономные конструктивные единицы (функции, процедуры, подпрограммы), логически взаимосвязанный набор которых и образует программу. Модули могут быть взаимосвязаны по управлению и по данным. Связь по управлению реализуется путем вызова одного модуля из другого. Вызванный модуль после завершения своей работы возвращает управление вызвавшему его модулю. Связь по данным может быть реализована двумя способами:
   —  непосредственным указанием при описании модуля его формальных параметров (переменных, массивов). При вызове модуля вместо формальных параметров указывают их фактические имена, используемые в вызывающем модуле. Часть этих параметров используется для передачи исходных данных. Вызванный модуль после завершения своей работы возвращает выходные данные вызвавшему его модулю с помощью другой части параметров. Этот способ обеспечивает интерфейс между вызываемым модулем и всеми непосредственно его вызывающими;
   —  использованием несколькими модулями общей области памяти, в которой размещены данные, необходимые этим модулям. Взаимосвязь модулей по данным будет осуществляться не непосредственно, а через эту область путем использования имен переменных, хранящих эти данные, одних и тех же в различных модулях. Сами модули образуют зону действия (область видимости) этих переменных. Из-за того, что значения переменных могут изменяться в нескольких модулях, контроль корректности их значений перед использованием затруднен. Поэтому рекомендуется размещать в общих областях постоянные данные или редко изменяемые данные, используемые небольшим числом модулей.
   Для модуля характерны:
   —  один вход и один выход — на входе программный модуль получает определенный набор исходных данных, выполняет их содержательную обработку и возвращает один набор выходных данных;
   —  функциональная завершенность — модуль выполняет перечень определенных операций, необходимых для реализации соответствующей функции и достаточных для завершения начатой обработки;
   —  достаточно слабые информационные связи с другими программными модулями;
   —  логическая независимость — результат работы программного модуля зависит только от исходных данных и не зависит от работы других модулей;
   —  ограниченная сложность и размер.
   Таким образом, модули содержат определение доступных для обработки данных, операции обработки данных, описание взаимосвязи с другими модулями. Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело — способ реализации процесса обработки.
   При определении набора модулей, реализующих функции конкретного алгоритма, необходимо учитывать следующее:
   —  принятие основных решений в алгоритме выносится на максимально «высокий» уровень иерархии;
   —  для реализации одной и той же функции в разных местах алгоритма создается один модуль, который при необходимости вызывается на выполнение.
   Среди множества модулей различают:
   —  головной модуль — управляет запуском программного продукта (существует в единственном числе);
   —  управляющий модуль — обеспечивает вызов других модулей на обработку;
   —  рабочие модули — выполняют функции обработки;
   —  сервисные модули и библиотеки, утилиты — реализуют технологические, обслуживающие функции.
   В результате создается функционально-модульная структура программы, являющаяся основой для ее реализации (программирования).
   При проектировании интерфейса необходимо преобразовать полученную ранее диаграмму перехода состояний с учетом диалоговых возможностей, предоставляемых инструментальными средствами реализации программы, предусмотрев возможность контроля ошибочных действий пользователя.
   Наиболее распространены и просты для реализации диалоговые системы с жестким сценарием диалога, использующим стандартизированные интерфейсные средства:
   —  меню — пользователю предлагается выбор альтернативы функций обработки из фиксированного перечня;
   —  действия запрос-ответ — фиксирован перечень возможных значений, выбираемых из списка, например ответы типа Да/Нет;
   —  запрос по формату — с помощью ключевых слов, фраз или путем заполнения экранной формы с регламентированным по составу и структуре набором реквизитов осуществляется подготовка сообщений.
   Ранее составленный перечень данных в фазе проектирования дополняют и уточняют с учетом выбранных решений по интерфейсу и программным модулям.
   К настоящему времени известно порядка десятка объектно- ориентированных методов анализа и проектирования, различающихся составом моделей и последовательностью их составления. Наиболее распространенные из них основаны на использовании унифицированного языка моделирования UML (Unified Modeling Language), появившегося в результате синтеза наиболее удачных сторон трех основных методов. UML содержит стандартный набор диаграмм и нотаций (обозначений).
   Опишем основные диаграммы. Ведущей является диаграмма вариантов использования, описывающая роли пользователей системы и выполняемые ими функции (процессы). Все варианты использования связаны с внешними требованиями к функциональности разрабатываемой программной системы. Диаграммы классов определяют типы объектов предметной области, их атрибуты и методы, а также статические связи между ними. Процесс обмена сообщениями между объектами моделируется диаграммами взаимодействия. Диаграммы состояний описывают переход объектов из состояния в состояние. Логика выполнения процессов описывается с помощью диаграмм деятельности. На диаграммах компонентов изображают компоненты программы (исполняемые модули и библиотеки) и иерархические связи между ними. Диаграммы размещения используют в распределенных АИС для отражения физических взаимосвязей между программными и техническими компонентами.
   Объектно-ориентированная методология проектирования предусматривает реализацию функциональных элементов алгоритмов не только в виде традиционных модулей (процедур), а в основном с помощью методов объектов и событийных процедур. Вызов методов и процедур осуществляется с помощью событий, формирующих сообщения для объектов. Данные (свойства объектов) могут быть доступны лишь с помощью методов этого объекта. Другими словами, никакой другой объект или никакая процедура не могут изменить свойство объекта иначе, как вызвав соответствующий метод этого объекта. Методы объектов и событийные процедуры можно рассматривать как развитие (один из вариантов) программных модулей.
   Объектно-ориентированные инструментальные средства разработки программ предоставляют большие возможности для создания диалоговых процессов и интерфейса конечного пользователя. Отметим среди них многооконность, наличие различных классов управляющих элементов (кнопки, переключатели и т. д.), возможность программного и ручного (визуального) изменения параметров элементов интерфейса.
   Фаза реализации программы осуществляется с помощью выбранных инструментальных средств, основой которых является язык программирования. Основной задачей этой фазы является программирование, т. е. составление программы на этом языке, удовлетворяющей проекту.
   В рассматриваемом в данной главе языке программирования Visual Basic реализована концепция событийно-управляемого программирования. В программе, составленной на этом языке, должны быть описаны объекты и их реакция на различные события. События заключаются либо в использовании какого-ли- бо управляющего элемента (щелчок мышью по кнопке, перемещение указателя линейки прокрутки и т. п.), либо в действиях, заложенных в программных кодах. Большинство событий связывается с экранными формами (окнами) и расположенными на них управляющими элементами, которые являются объектами и описываются на фазе проектирования. Объектами являются как сами формы, так и расположенные на них элементы. Задача программиста состоит в реализации логики вычислений в соответствии с имеющимися алгоритмами и управлении событиями, возникающими при воздействии на объекты.
   Структура программных модулей зависит от выбранного инструментального средства реализации. Приложение, созданное на языке Visual Basic, оформляется в виде совокупности программных модулей следующих уровней:
   —  глобальный модуль;
   —  модули форм;
   —  модули классов объектов;
   —  событийные процедуры управляющих элементов, расположенных на форме;
   —  процедуры пользователя.
   Событийные процедуры и процедуры пользователя не оформляются в виде отдельного файла и поэтому не имеют в своем названии слова «модуль», так как в Visual Basic оно используется лишь для тех программных модулей, для хранения которых создаются отдельные файлы.

 
< Пред.   След. >