Учебник Технология программирования. Технология программирования
 Скачать 7.85 Mb.
|
|
Выбор среды программирования. Средой программирования называют программный комплекс, который включает специализированный текстовый редактор, встроенные компилятор, компоновщик, отладчик, справочную систему и другие программы, использование которых упрощает процесс написания и отладки программ. Последнее время широкое распространение получили упоминавшиеся выше среды визуального программирования, в которых программист получает возможность визуального подключения к программе некоторых кодов из специальных библиотек компонентов, что стало возможным с развитием объектно-ориентированного программирования. Наиболее часто используемыми являются визуальные среды Delphi, C++ Builder фирмы Borland (Inprise Corporation), Visual C++, Visual Basic фирмы Microsoft, Visual Ada фирмы IBM и др. Между основными визуальными средами этих фирм Delphi, C++ Builder и Visual C++ имеется существенное различие: визуальные среды фирмы Microsoft обеспечивают более низкий уровень программирования «под Windows». Это является их достоинством и недостатком. Достоинством – так как уменьшается вероятность возникновения «нестандартной» ситуации, 101 т.е. ситуации, не предусмотренной разработчиками библиотеки компонентов, а недостатком – так как это существенно загружает программиста «рутинной» работой, от которой избавлен программист, работающий с Delphi или C++ Builder. Много нареканий вызывает также интерфейс Visual C++, также ориентированный на «низкоуровневое» программирование. В общем случае, если речь идет о выборе между этими средами, то он в значительной степени должен определяться характером проекта. Выбор или формирование стандартов разработки. Реальное применение любой технологии проектирования требует формирования или выбора ряда стандартов, которые должны соблюдаться всеми участниками проекта: • стандарт проектирования; • стандарт оформления проектной документации; • стандарт интерфейса пользователя. Стандарт проектирования должен определять: • набор необходимых моделей (схем, диаграмм) на каждой стадии проектирования и степень их детализации; • правила фиксации проектных решений на диаграммах, в том числе правила именования объектов и соглашения по терминологии, набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов; • требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы и используемых CASE-средств; • механизм обеспечения совместной работы над проектом, в том числе и правила интеграции подсистем проекта и анализа проектных решений на непротиворечивость. Стандарт оформления проектной документации должен регламентировать: • комплектность, состав и структуру документации на каждой стадии; • требования к ее содержанию и оформлению; • правила подготовки, рассмотрения, согласования и утверждения документов. Стандарт интерфейса пользователя должен определять: • правила оформления экранов (шрифты и цветовую палитру), состав и расположение окон и элементов управления; • правила пользования клавиатурой и мышью; • правила оформления текстов помощи; • перечень стандартных сообщений; • правила обработки реакции пользователя. Все описанные выше проектные решения существенно влияют на трудоемкость и сложность разработки. Только после их принятия следует переходить к анализу требований и разработке спецификаций проектируемого программного обеспечения. 102 Контрольные вопросы и задания 1. Что понимают под технологичностью программного обеспечения? Почему? 2. Какие типы программных продуктов можно выделить? Чем они различаются? 3. Назовите основные эксплуатационные требования к программным продуктам. Какими средствами и приемами обеспечивается каждый из них? Для каких типов программных систем целесообразно указывать каждый из них? 4. В каких ситуациях необходимы предпроектные исследования? Какие вопросы при этом решают? Что получают в результате таких исследований? 5. Назовите, какой раздел технического задания можно считать основным и почему? Какую информацию должны содержать остальные разделы? В чем основная сложность разработки технического задания? 6. Составьте техническое задание на разработку «калькулятора» по типу, предлагаемого Windows. Проанализируйте, какие программы или программные системы могли бы отвечать указанным вами требованиям. Попробуйте ограничить их количество, уточнив техническое задание. 7. Какие решения ранних этапов проектирования считают основными и почему? 103 4. АНАЛИЗ ТРЕБОВАНИЙ И ОПРЕДЕЛЕНИЕ СПЕЦИФИКАЦИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРИ СТРУКТУРНОМ ПОДХОДЕ Собственно разработка любого программного обеспечения начинается с анализа требований к будущему программному продукту. В результате анализа получают спецификации разрабатываемого программного обеспечения: выполняют декомпозицию и содержательную постановку решаемых задач, уточняют их взаимодействие и эксплуатационные ограничения. В целом в процессе определения спецификаций строят общую модель предметной области, как некоторой части реального мира, с которой будет тем или иным способом взаимодействовать разрабатываемое программное обеспечение, и конкретизируют его основные функции. 4.1. Спецификации программного обеспечения при структурном подходе Как уже упоминалось в § 1.4, спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого программного обеспечения. При этом одна часть спецификаций (функциональные) описывает функции разрабатываемого программного обеспечения, а другая часть (эксплуатационные) определяет требования к техническим средствам, надежности, информационной безопасности и т.д. Определение отражает главные требования к спецификациям. Применительно к функциональным спецификациям подразумевается, что: • требование полноты означает, что спецификации должны содержать всю существенную информацию, где ничего важного не было бы упущено, и отсутствует несущественная информация, например детали реализации, чтобы не препятствовать разработчику в выборе наиболее эффективных решений; • требование точности означает, что спецификации должны однозначно восприниматься как заказчиком, так и разработчиком. Последнее требование выполнить достаточно сложно в силу того, что естественный язык для описания спецификаций не подходит: даже подробные 104 спецификации на естественном языке не обеспечивают необходимой точности. Точные спецификации можно определить, только разработав некоторую формальную модель разрабатываемого программного обеспечения. Формальные модели, используемые на этапе определения спецификаций можно разделить на две группы: модели, зависящие от подхода к разработке (структурного или объектно-ориентированного), и модели, не зависящие от него. Так диаграммы переходов состояний, которые демонстрируют особенности поведения разрабатываемого программного обеспечения при получении тех или иных сигналов извне (см. § 4.2), и математические модели предметной области (см. § 4.6) используют при любом подходе к разработке. В рамках структурного подхода на этапе анализа и определения спецификаций используют три типа моделей: ориентированные на функции, ориентированные на данные и ориентированные на потоки данных. Каждую модель целесообразно использовать для своего специфического класса программных разработок. На рис. 4.1 показана классификация моделей разрабатываемого программного обеспечения, используемых на этапе определения спецификаций. Следует иметь в виду, что все функциональные спецификации описывают одни и те же характеристики разрабатываемого программного обеспечения: перечень функций и состав обрабатываемых данных. Они различаются 105 только системой приоритетов (акцентов), которая используется разработчиком в процессе анализа требований и определения спецификаций. Диаграммы переходов состояний определяют основные аспекты поведения программного обеспечения во времени, диаграммы потоков данных – направление и структуру потоков данных, а концептуальные диаграммы классов – отношение между основными понятиями предметной области. Поскольку разные модели описывают проектируемое программное обеспечение с разных сторон, рекомендуется использовать сразу несколько моделей и сопровождать их текстами: словарями, описаниями и т.п., которые поясняют соответствующие диаграммы. Так методологии структурного анализа и проектирования, основанные на моделировании потоков данных, обычно используют комплексное представление проектируемого программного обеспечения в виде совокупности моделей: • диаграмм потоков данных (DFD – Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе (см. § 4.4); • диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы (см. § 4.5); • диаграмм переходов состояний (STD – State Transition Diagrams), характеризующих поведение системы во времени (см. § 4.2); • спецификаций процессов; • словаря терминов. Взаимосвязь элементов такой обобщенной модели показана на рис. 4.2. Спецификации процессов. Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси-Шнейдермана. Поскольку описание процесса должно быть кратким и понятным как разработчику, так и заказчику, для их спецификации чаще всего используют псевдокоды. Словарь терминов. Словарь терминов представляет собой краткое описание основных понятий, используемых при составлении спецификаций. Он должен включать определение основных понятий предметной области, описание структур элементов данных, их типов и форматов, а также всех сокращений и условных обозначений. Он предназначен для повышения степени понимания предметной области и исключения риска возникновения разногласий при обсуждении моделей между заказчиками и разработчиками. Обычно описание термина в словаре выполняют по следующей схеме: • термин; • категория (понятие предметной области, элемент данных, условное обозначение и т.д.); • краткое описание. 106 В качестве примера приведем описание одного из терминов системы решения комбинаторно-оптимизационных задач: Термин ........ …Алгоритм Категория .... …Понятие предметной области Описание .... …В настоящем проекте используется для обозначения обобщенного понятия «реализация процедуры решения конкретной задачи выбранным методом» Кроме указанных моделей в состав полной спецификации при любом подходе могут входить математические модели описания объектов предметной области, которые позволяют уточнить основные соотношения анализируемых величин и накладываемые на них ограничения. Перейдем к более подробному рассмотрению перечисленных моделей. 107 4.2. Диаграммы переходов состояний Диаграмма переходов состояний является графической формой предоставления конечного автомата – математической абстракции, используемой для моделирования детерминированного поведения технических объектов или объектов реального мира. На этапе анализа требований и определения спецификаций диаграмма переходов состояний демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий. Под управляющими воздействиями или сигналами в данном случае понимают управляющую информацию, получаемую системой извне. Например, управляющими воздействиями считают команды пользователя и сигналы датчиков, подключенных к компьютерной системе. Получив такое управляющее воздействие, разрабатываемая система должна выполнить определенные действия и или остаться в том же состоянии, или перейти в другое состояние взаимодействия с внешней средой. Для построения диаграммы переходов состояний необходимо в соответствии с теорией конечных автоматов определить: основные состояния, управляющие воздействия (или условия перехода), выполняемые действия и возможные варианты переходов из одного состояния в другое. Условные обозначения, используемые при построении диаграмм переходов состояний, показаны на рис. 4.3. Если программная система в процессе функционирования активно не взаимодействует с окружающей средой (пользователем или датчиками), например, использует примитивный интерфейс и выполняет некоторые вычисления по заданным исходным данным, то диаграмма переходов состояний обычно интереса не представляет. В этом случае она демонстрирует только последовательно выполняемые переходы: из исходного состояния в состояние ввода данных, затем после выполнения вычислений – в состояние вывода и, наконец, в состояние завершения работы (рис. 4.4). 108 Для интерактивного программного обеспечения с развитым пользовательским интерфейсом основные управляющие воздействия – команды пользователя, для программного обеспечения реального времени – сигналы от датчиков и/или оператора производственного процесса. Общим для этих типов программного обеспечения является наличие состояния ожидания, когда программное обеспечение приостанавливает работу до получения очередного управляющего воздействия. Для интерактивного программного обеспечения наиболее характерно получение команд различных типов (рис. 4.5), а если это еще и программное обеспечение реального времени – однотипных сигналов (либо от многих датчиков, либо требующих продолжительной обработки). В отличие от интерактивных систем для систем реального времени обычно установлено более жесткое ограничение на время обработки полученного сигнала программного обеспечения. Такое ограничение часто требует выполнения дополнительных исследований поведения системы во времени, например, с использованием сетей Петри или марковских процессов. К программному обеспечению, требующему уточнения особенностей поведения посредством построения диаграммы переходов состояний, относится и программное обеспечение, ориентированное на работу в сети (см. §1.1). При этом отдельно строят модели поведения сервера и клиента, представляя сообщения, передаваемые между ними, в виде управляющих воздействий. 109 Пример 4.1. Рассмотрим диаграмму переходов состояний для программы построения графиков функций одной переменной, техническое задание на которую представлено в § 3.4. Программа относится к классу интерактивных, соответственно на этапе анализа и определения спецификаций целесообразно уточнить поведение программы на уровне интерфейса с пользователем, тем более, что наличие простого интерфейса оговорено в техническом задании. Один из возможных вариантов диаграммы переходов состояний программы представлен на рис. 4.6. Полученную диаграмму переходов состояний следует согласовать с заказчиком программного обеспечения. 4.3. Функциональные диаграммы Функциональными называют диаграммы, в первую очередь отражающие взаимосвязи функций разрабатываемого программного обеспечения. В качестве примера функциональной модели рассмотрим активностную модель, предложенную Д. Россом в составе методологии функционального моделирования SADT (Structured Analysis and Design Technique - технология структурного анализа и проектирования) в 1973 г. [58]. Примечание. Методология SADT предполагает, что модель может основываться либо на функциях системы, либо на ее предметах (данных, оборудовании, информации и т. п.). В обоих случаях используют схожие графические нотации, но в первом случае блок соответствует 110 функции, а во втором - элементу данных. Соответствующие модели принято называть активностными моделями и моделями данных. Полная модель включает построение обеих моделей, обеспечивающих более полное описание программного обеспечения, однако широкое распространение получили только активностные (функциональные) модели. На основе методологии SADT в дальнейшем была построена известная методология описания сложных систем IDEFO (Icam DEFinition - нотация ICAM), которая является основной частью программы ICAM (Integrated Computer-Aided Manufacturing- интегрированная компьютеризация производства), проводимой по инициативе ВВС США. Отображение взаимосвязи функций активностной модели осуществляется посредством построения иерархии функциональных диаграмм, схематически представляющих взаимосвязи нескольких функций. Каждый блок такой диаграммы соответствует некоторой функции, для которой должны быть определены: исходные данные, результаты, управляющая информация и механизмы ее осуществления - человек или технические средства. Все перечисленные выше связи функции представляются дугами, причем тип связи и ее направление строго регламентированы. Дуги, изображающие каждый тип связей, должны подходить к блоку с определенной стороны (рис. 4.7), а направление связи должно указываться стрелкой в конце дуги. Физически дуги исходных данных, результатов и управления представляют собой наборы данных, передаваемые между функциями. Дуги, определяющие механизм выполнения функции, в основном используются при описании спецификаций сложных информационных систем, которые включают как автоматизированные, так и ручные операции. Блоки и дуги маркируются текстами на естественном языке. Блоки на диаграмме размещают по «ступенчатой» схеме в соответствии с последовательностью их работы или доминированием, которое понимается как влияние, оказываемое одним блоком на другие. В функциональных диаграммах SADT различают пять типов влияний блоков друг на друга: • вход - выход блока подается на вход блока с меньшим доминированием, т. е. следующего (рис. 4.8, а); 111 • управление - выход блока используется как управление для блока с меньшим доминированием (следующего) (рис. 4.8, б); • обратная связь по входу - выход блока подается на вход блока с большим доминированием (предыдущего) (рис. 4.8, в); • обратная связь по управлению - выход блока используется как управляющая информация для блока с большим доминированием (предыдущего) (рис. 4.8, г); • выход-исполнитель - выход блока используется как механизм для другого блока (рис. 4.8, д). Дуги могут разветвляться и соединяться вместе различными способами. Разветвление означает, что часть или вся информация может использоваться 112 в каждом ответвлении дуги. Дуга всегда помечается до ветвления, чтобы идентифицировать передаваемый набор данных. Если ветвь дуги после ветвления не помечена, то непомеченная ветвь содержит весь набор данных. Каждая метка ветви уточняет, что именно содержит данная ветвь (рис. 4.9). Построение иерархии функциональных диаграмм ведется поэтапно с увеличением уровня детализации: диаграммы каждого следующего уровня уточняют структуру родительского блока. Построение модели начинают с единственного блока, для которого определяют исходные данные, результаты, управление и механизмы реализации. Затем он последовательно детализируется с использованием метода пошаговой детализации (см. § 1.3). При этом рекомендуется каждую функцию представлять не более чем 3—7-ю блоками. Во всех случаях каждая подфункция может использовать или продуцировать только те элементы данных, которые использованы или продуцируются родительской функцией, причем никакие элементы не могут быть опущены, что обеспечивает непротиворечивость построенной модели. Стрелки, приходящие с родительской диаграммы или уходящие на нее, нумеруют, используя символы и числа. Символ обозначает тип связи: I - входная, С – управляющая, М – механизм, R - результат. Число - номер связи по соответствующей стороне родительского блока, считая сверху вниз и слева направо. Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень - АО, второй - Al, A2 и т. п., третий - А11, А12, А13 и т.п., где первые цифры - номер родительского блока, а последняя - номер конкретного субблока родительского блока. Детализацию завершают после получения функций, назначение которых хорошо понятно как заказчику, так и разработчику. Эти функции описывают, используя естественный язык или псевдокоды. В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и строят словарь данных, в котором определяют структуры и элементы данных, показанных на диаграммах. Таким образом, в результате получают спецификацию, которая состоит из иерархии функциональных диаграмм, спецификаций функций нижнего уровня и словаря, имеющих ссылки друг на друга. |