Чаще всего программные продукты имеют определенную конструкцию (архитектуру) построения – состав и взаимосвязь программных модулей, т.е. обладают внутренней организацией или внутренней структурой, образованной взаимосвязанными программными модулями.
Модуль – это самостоятельная часть программы, имеющая определенное назначение и обеспечивающая заданные функции обработки автономно от других программных модулей. Модуль состоит из логически взаимосвязанной совокупности функциональных элементов.
Структуризация программ выполняется в первую очередь для удобства разработки, программирования, отладки и внесения изменений в программный продукт. Структуризация программных продуктов преследует следующие цели:
· распределить работы по исполнителям, обеспечив приемлемую их загрузку и требуемые сроки разработки программных продуктов;
· построить календарные графики проектных работ и осуществлять их координацию в процессе создания программных изделий;
· контролировать трудозатраты и стоимость проектных работ и др.
Структурное разбиение программ на отдельные составляющие служит основой и для выбора инструментальных средств их создания, хотя имеет место и обратное влияние – выбор инструментальных средств разработчика ПО определяет типы программных модулей.
При создании программных продуктов выделяются многократно используемые модули, проводится их типизация и унификация, за счет чего сокращаются сроки и трудозатраты на разработку программного продукта в целом.
Некоторые программные продукты используют модули из готовых библиотек стандартных подпрограмм, процедур, функций, объектов, методов обработки данных.
 |
Типовая структура программного продукта, состоящего из отдельных программных модулей и библиотек процедур, встроенных функций, объектов и т.п. приведена на рис. П1.1.
Среди множества модулей различают:
· головной модуль – управляет запуском программного продукта (существует в единственном числе);
· управляющий модуль – обеспечивает вызов других модулей на обработку;
· рабочие модули – выполняют функции обработки;
· сервисные модули и библиотеки, утилиты – реализуют обслуживающие функции.
В работе программного продукта активизируются необходимые программные модули. Управляющие модули задают последовательность вызова на выполнение очередного модуля. Информационная связь модулей обеспечивается за счет использования общей базы данных либо межмодульной передачи данных через переменные обмена.
Каждый модуль может оформляться как самостоятельно хранимый файл; для функционирования программного продукта необходимо наличие программных модулей в полном составе.
Структурно-сложные программные продукты разрабатываются как пакеты программ, и чаще всего они имеют прикладной характер – пакеты прикладных программ (ППП).
Большинство программных продуктов, особенно прикладного характера, ориентированных на конечного пользователя, работают в диалоговом режиме взаимодействия с пользователем таким образом, что ведется обмен сообщениями, влияющими на обработку данных.
В диалоговом режиме под воздействием пользователя осуществляются запуск функций (методов) обработки, изменение свойств объектов, производится настройка параметров выдачи информации на печать и т.п.
Многие программы помимо выполнения основных функций, должны обеспечивать поддержку диалоговых процессов. Они классифицируются на:
· программы с жестким сценарием диалога – стандартизированное представление информации обмена;
· дескрипторные программы – формат ключевых слов сообщений;
· тезаурусные программы – семантическая сеть дескрипторов, образующих словарь системы (аналог - гипертекстовые системы);
· программы с языком деловой прозы – представление сообщений на языке, естественном для профессионального пользования.
Наиболее просты для реализации и распространены диалоговые программы с жестким сценарием диалога, которые предоставлены в виде:
· меню – диалог инициируется программой; пользователю предлагается выбор альтернативы функций обработки из фиксированного перечня; предоставляемое меню может быть иерархическим и содержать вложенные подменю следующего уровня;
· действия запрос-ответ – фиксирован перечень возможных значений, выбираемых из списка, или ответы типа Да/Нет;
· запрос по формату – с помощью ключевых слов, фраз или путем заполнения экранной формы с регламентированным по составу и структуре набором реквизитов осуществляется подготовка сообщений.
Диалоговый процесс управляется согласно созданному сценарию, для которого определяются:
· точки (момент, условие) начала диалога;
· инициатор диалога – человек или программный продукт;
· параметры и содержание диалога – сообщения, состав и структура меню, экранные формы и т.п.;
· реакция программного продукта на завершение диалога.
Для создания диалоговых процессов и интерфейса конечного пользователя наиболее подходят объектно-ориентированные инструментальные средства разработки программ.
Графический интерфейс пользователя (Graphics User Interface - GUI) является обязательным компонентом большинства современных программных продуктов, ориентированных на работу конечного пользователя. К графическому интерфейсу пользователя предъявляются высокие требования как с чисто инженерной, так и с художественной стороны разработки, при его разработке ориентируются на возможности человека.
Наиболее часто графический интерфейс реализуется в интерактивном режиме работы пользователя для программных продуктов, функционирующих в среде Windows, и строится в виде системы раскрывающихся меню с использованием в качестве средства манипуляции мыши и клавиатуры. Работа пользователя осуществляется с экранными формами, содержащими объекты управления, панели инструментов с пиктограммами режимов и команд обработки.
Стандартный графический интерфейс пользователя должен отвечать ряду требований:
· поддерживать информационную технологию работы пользователя с программным продуктом – содержать привычные и понятные пользователю пункты меню, соответствующие функциям обработки, расположенные в естественной последовательности использования;
· ориентироваться на конечного пользователя, который общается с программой на внешнем уровне взаимодействия;
· удовлетворять правилу «шести» - в одну линейку меню включать не более 6 понятий, каждое из которых содержит не более 6 опций;
· графические объекты сохраняют свое стандартизованное назначение и по возможности местоположение на экране.
Цели структурного программирования.
Целями структурного программирования являются:
1. Обеспечить дисциплину программирования в процессе создания программных комплексов. Дейкстра дал следующее определение: «Структурное программирование – это дисциплина, которую программист навязывает сам себе».
2. Улучшать читабельность программы. Читабельность улучшается, если придерживаться следующих правил:
· избегать использования языковых конструкций с неочевидной семантикой;
· стремиться к локализации действия управляющих конструкций и использования структур данных;
· разрабатывать программу так, чтобы ее можно было читать от начала до конца без управляющих
переходов на другую страницу.
3. Повышать эффективность программы. Этого можно достигнуть, если выполнять структурирование программы, разбивая ее на модули так, чтобы можно было легко находить и корректировать ошибки, а также чтобы текст любого модуля с целью увеличения эффективности можно было переделать независимо от других.
4. Повышать надежность программы. Этого можно достигнуть, если программа будет легко поддаваться сквозному тестированию и не создаст проблем для организации процесса отладки. Это обеспечивается хорошим структурированием программы при разбивке ее на модули и выполнением правил написания читабельных программ.
5. Уменьшать время и стоимость программной разработки. Это происходит в том случае, если каждый программист команды разработчиков становится способным писать и отлаживать большее количество программного кода, чем раньше, т.е. когда повышается производительность труда программиста. Соблюдение правил структурного программирования позволяет этого достигнуть.
Основные принципы структурной методологии
К основным принципам структурной методологии относятся:
1. Принцип абстракции. Абстракция позволяет программисту вообразить требуемое решение проблемы без сиюминутного учета множества деталей. Используя принцип абстракции, разработчик может рассматривать программу по уровням. Верхний уровень показывает большую абстракцию, упрощает взгляд на проект, в то время как нижний уровень показывает мелкие детали реализации.
2. Принцип формальности. Слово «формальность» предполагает строгий методический подход. Принцип формальности является базой для превращения программирования из импровизации в инженерную дисциплину. Кроме того, этот принцип дает основания для доказательства правильности программ, так как позволяет изучать программы (алгоритмы) как математические объекты.
3. Принцип «разделяй и властвуй». Данный принцип реализует подход к решению трудной проблемы путем ее разделения на множество мелких независимых подпроблем, которые легче понимать и решать.
При разработке ПО этот принцип означает разделение программы на отдельные фрагменты (модули), которые просты по управлению и допускают независимую отладку и тестирование.
4. Принцип иерархического упорядочения. Структура разбиения на части не менее важна, чем сам факт такого разделения. В применении к программированию этот принцип выдвигает требование иерархического структурирования взаимосвязей между модулями программного комплекса, что облегчает достижение рассмотренных выше целей структурного программирования.
