пример зависимости времени расчета t=t(N) для CPU ### МГц и RAM ##К. Зеленая утолщенная линия аппроксимирует данную зависимость и может использоваться для приближенной оценки времени расчета в реальных условиях функционирования ПС. В общем случае полученные таким образом данные дадут возможность выбрать устройства, удовлетворяющие пользователей по эффективности.

Время расчета/вывода_графика t

**

Рис. 1.1.2.1

Дополним документ «Исходные требования к ПС “Поддержка выполнения КР по технологии программирования”» выделенными курсивом группами критериев качества ПС.

1.1.3. Функциональная спецификация реализуемой ПС функции F. При функциональной спецификации опишем внешнюю информационную среду, внешние функции и соответствующие им исключительные ситуации.

Описание внешней информационной среды. Каналы ввода: клавиатурный и файловый (<имя_входного_файла>.wrk). Каналы вывода: основной – дисплейный и/или файловый (<имя_выходного_файла_1>.txt и <имя_выходного_файла_1>.bmp); вспомогательный – принтерный.

Информационные объекты:

– входные Хi, при этом Xi = X, i=1,…,4:

X1 – множество наименований работ ( i, j) и их номеров i=0,…,n-1, j=1,…,n ;

X2 – множество длительностей работ фi,j ;

X3 – множество (k, i)-х работ (k=0,…, n-2), непосредственно предшествующих работам (i, j);

X4 – множество работ (j, r)-х работ (r=2,…, n), непосредственно следующих за работой (i, j);

– выходные pY, при этом pY = Y, p=1, 2:

1Y – табличная форма плана, использующая выходы Y={Yi}|i=1,…,11, а

именно:

1Yi=Xi, i=1,…,4;

1Y5 – множество наиболее ранних моментов наступления j-х событий

tp(xj), j=1,…,n;

1Y6 – множество наиболее поздних моментов наступления j-х событий

– список критических работ, лежащих на критическом пути, 2Y13=

– длина критического пути, - и представление 2Y в виде графа G:

G = (Z; E),

где Z – множество вершин (событий) zi, изображенных пронумерованными кружками (индексами событий), а Е – множество связывающих вершины дуг (работ) (zi, zj), i=0,…, n-1 и j=1,…,n, изображенных тонкими линиями со стрелками в направлении от zi к zj; вершины zi. Лежащие на критическом пути работы (zi, zj), должны быть выделены жирными линиями со стрелками.

Описание внешних функций построим на основе технологии нисходящего проектирования /14, с. 60/, определяющей для рассматриваемого примера

трехэтапную последовательность решения задачи и соответствующие им три функции Fl, Fl = F, l =1, 2, 3):.

F1 – ввод входных информационных объектов Хi ( Xi = X, i=1,…,4) ; F2 – расчет выходных информационных объектов pYj ( pYj = Y, p=1, 2) ;

F3 – вывод табличной (1Y) и/или графической (2Y) формы сетевого плана работ. При этом функция F2 является внутренней. К внешним же относятся функции

F1 и F3.

Описание исключительных ситуаций:

eror1 – ошибка отрицательности или нуля x ≤ 0, x X2;

eror2 – ошибка пустого множества на входе: Xi = , i = 1, 2 , 3, 4; eror3 – ошибка пустого множества на выходе: pYj = , j=5, …, np;

eror4 – ошибка в операциях с файлами: <имя_входного_файла>.wrk, <имя_выходного_файла_1>.txt и <имя_выходного_файла_1>.bmp).

.

Выделенными курсивом группами требований функциональной спецификации завершим документ «Исходные требования к ПС “Поддержка выполнения КР по технологии программирования”» .

1.1.4. Контроль правильности внешнего описания. На данном этапе необходимо провести статический просмотр и смежный пользовательский контроль. После проектирования архитектуры желателен смежный контроль разработчика архитектуры ПС. Результаты контроля должны быть сведены в табл. вида 1.1.

Рекомендуемая к разделу 1 литература:

[3, с. 6-29; 4; 6, с. 136-140; 8, с. 1-8; 11, с. 21-31; 12, с. 15-38; 23; 24].

2. Методические указания к разделу 2 –

"РАЗРАБОТКА АРХИТЕКТУРЫ ПРОГРАММНОГО СРЕДСТВА"

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

В КР должны быть решены следующие задачи разработки архитектуры ПС как системы:

-выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;

-определение способов взаимодействия между выделенными программными подсистемами.

По результатам принятых на этом этапе решений должна производиться дальнейшая конкретизация функциональных спецификаций. Далее должен быть выбран класс архитектуры разрабатываемого ПС Архитектура ПС, функционирующего под управлением Windows, изначально является событийно-управляемой (рис. 2.1). Это означает, что функционирование приложения в целом осуществляется на основе сообщений и касается его объектной составляющей на уровне интерфейсов. В случае, если и для реализации собственно функциональной части ПС выбрана объектная технология, разрабатывают полностью событийно-управляемую архитектуру ПС. При разработке событийно-управляемой архитектуры определяют все возможные события и соответствующие им реакции ПС. В случае же, если функциональная часть ПС реализуется не на основе объектной технологии (а именно это и происходит при разработке большинства ПС) выбирают класс архитектуры для функциональной части разрабатываемого ПС из следующих классических архитектур: цельная программа; комплекс автономно выполняемых программ; слоистая программная система; комплекс параллельно выполняемых программ.

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

функцию, и ее реализация не слишком сложна. Данная архитектура не требует описания. Фиксируют лишь класс архитектуры.

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

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

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

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

Конвейер - это последовательность программных компонентов, в которой стандартный вывод каждой программного компонента, кроме самого последнего, связан со стандартным вводом следующего программного компонента этой последовательности. Конвейер обрабатывает некоторый поток сообщений. Каждое сообщение этого потока поступает на вход первого программного компонента, который переработанное сообщение передает следующему за ним, а сам начинает обработку очередного сообщения потока. Таким же образом действует каждый из компонентов конвейера: получив сообщение от предшествующего программного компонента и, обработав его, он передает переработанное сообщение следующему компоненту и приступает к обработке следующего сообщения. Последний программный компонент конвейера выводит результат работы всего конвейера (результирующее сообщение). Таким образом, в конвейере, состоящим из n программ, может одновременно находиться в обработке до n сообщений. Конечно, в силу того, что разные компоненты конвейера могут затратить на обработку очередных сообщений разные отрезки времени, необходимо обеспечить синхронизацию этих процессов (некоторые процессы могут находиться в стадии ожидания либо возможности передать переработанное сообщение, либо возможности получить очередное сообщение).

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

Для ПС с событийно-управляемой архитектурой, разрабатываемых в Delphi на Object Pascal, достаточно предусмотреть все возможные основные события и реакции на них. Основные события и реакции на них реализованы в свойствах объектов (компонентах), в том числе объекта Exсeption, являющегося предком для всех других объектов - исключительных ситуаций. Обработка исключительных ситуаций легко программируются на Object Pascal посредством блоков try … except и try … finally.

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

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

Контроль архитектуры ПС. Для контроля архитектуры ПС следует использовать смежный контроль и ручную имитацию.

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

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

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

При описании архитектуры ПС необходимо обосновать выбор класса

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

2.1. Пример проектирования архитектуры ПС “Поддержка выполнения КР по технологии программирования” рассмотрен ниже.

2.1.1. Архитектура ПС. Исходной информацией при проектировании архитектуры является определенное в примере 1.1 внешнее описание ПС, общие требования к ПС (см. раздел “Общие организационно-методические указания” настоящих МУ) и согласованная с руководителем КР среда разработки. Анализ полного набора функций ПС, показывает, что любая из основных функций может быть активизирована пользователем, является независимой, а порядок их выполнения не регламентирован. Это, совместно с целесообразностью реализации пользовательского интерфейса в Delphi, предполагает использование событийно управляемой архитектуры ПС на уровне реализации приложения в целом и его пользовательского интерфейса. При выполнении же активизированной функции главного меню (и соответствующего ей программного компонента) пользователю нет необходимости активизировать другие функции (программные компоненты) этого набора до тех пор, пока не закончит выполнение активизированный программный компонент; все программные компоненты набора применяются к одной и той же информационной среде, определенной предметной областью ПС и его окружающей средой. Кроме того, основные функции ПС на уровне главного меню не требуют взаимодействия по управлению. Все сказанное, а также то, что функции объединены общей целью – поддержать выполнение КР – свидетельствует о том, что наиболее подходящей архитектурой для функциональной части разрабатываемого ПС является архитектура автономно выполняемых программ. При этом при функционировании этого комплекса программ будут использоваться все возможности, предоставляемые событийно-управляемой архитектурой.

2.1.2. Архитектурные функции. Специфических функций для реализации предложенной архитектуры не требуется. Для запуска ПС будем использовать стандартные возможности операционной системы Windows 2000/NT. Для этого подготовим исполняемый файл TLP_KRxx.EXE, где хх – номер варианта курсовой работы. Можно подготовить дистрибутив ПС также с помощью стандартных средств.

Другая возможность запуска ПС – открытие груПСы проектов TLP_KRxx.BPG, связывающей отдельные проекты, реализующие описанные в примере 1.1 пункты главного меню. Таким образом, для обеспечения взаимодействия между подсистемами, реализующими пункты главного меню достаточно этих зафиксированных соглашений и стандартных возможностей базового программного обеспечения.

2.1.3. Контроль архитектуры. Для контроля архитектуры ПС следует осуществить, по крайней мере, смежный контроль разработчиком внешнего описания и разработчиком структуры. Результаты контроля должны быть сведены в таблицу, аналогичную табл. 1.1.

Рекомендуемая к разделу 2 литература:

[2, с. 64-67; /8, с. 9-19; 9, с. 207-215; 13, с. 39-79].

3. Методические указания к разделу 3 – "РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММНОГО ПРОДУКТА "

Для дальнейшего уменьшения сложности ПС и повторного использования кодов его разрабатывают по частям - модулям. Выделение модулей может осуществляться на основе технологии нисходящего, структурного, модульного, объектноориентированного, в том числе компонентного, программирования. В данном разделе акцент сделан на технологии нисходящего структурного программирования, позволяющей определить функциональную макро- и микромодульную структуру ПС. Технология объектного структурирования предметной области ПС в соответствии с технологией объектно-ориентированного программирования изложена в /15, с. 100102/ и позволяет в случае целесообразности определить объектную структуру функциональной части ПС. Технология же объектного структурирования пользовательского интерфейса осуществляется на основе VCL и наборов компонент третьих производителей.

Уменьшение сложности ПС в процессе его разработки на основе технологии модульного, в том числе, и компонентного программирования обеспечивается независимостью модулей и увязкой их в иерархическую структуру. Это достигается формулированием определенных требований, которым должен удовлетворять модуль, основных характеристик “хорошего” модуля. Для обеспечения иерархичности используют древовидные модульные структуры программ (включая деревья со сросшимися ветвями /15, с. 67/).

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

Указания по размеру модуля даны в /15, с. 57/. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части ПС и, следовательно, тем больший вклад в упрощение ПС он может внести. Рекомендуются для использования модули двух классов прочности: функционально прочные и информационно прочные.

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

Информационно прочный модуль − это модуль, реализующий несколько функций над одним и тем же информационным объектом, который считается неизвестным вне этого модуля. Для каждой из этих функций в таком модуле имеется свой вход со своей формой обращения к нему. Такой класс следует рассматривать как класс программных модулей с высшей степенью прочности. Информационно прочный модуль может реализовывать, например, абстрактный тип данных /15, с. 9192/.

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

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

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

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

Методы разработки структуры программы. Как уже отмечалось выше, в

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

Функциональная спецификация модуля строится так же, как и функциональная спецификация ПС.

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

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

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

Спецификация ПП (головного модуля)

Текст головного модуля

Спецификация 2-ой подзадачи

Рис. 3.1. Первый шаг формирования модульной структуры ПС при конструктивном подходе

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

этого производится очередное доформирование дерева ПС, например, такое, которое показано на рис. 3.2.

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

Спецификация ПП (головного модуля)

Текст головного модуля

Текст головного модуля 2-ой подзадачи

Рис.. 3.2. Второй шаг формирования модульной структуры ПС при конструктивном подходе

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

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

–приравнивая длину программы без модулей сумме длин модулей в модульной реализации;

–минимизируя потенциальный объём модулей;

–ограничивая длину модуля длиной "программы без ошибок";

–используя соображение о магическом числе "7±2".

Контроль структуры ПС. Для контроля структуры ПС следует использовать статический, смежный и сквозной контроль.

Статический контроль состоит в оценке структуры ПС, насколько хорошо ПС разбит на модули с учетом значений рассмотренных выше основных характеристик модуля.

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

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

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

При описании структуры ПС необходимо проиллюстрировать ее рисунком, специфицировать функции модулей и задокументировать протокол контроля структуры ПС способом, приведенным в п.1. В приложении к КР целесообразно привести “Описание применения” ПС, близкое по содержанию к программному документу с таким же названием [24].

3.1. Пример проектирования структуры подсистемы “Редактор сетевых графиков” при точно определенном пользовательском интерфейсе как самой подсистемы, так и ПС “Поддержка выполнения КР по технологии программирования” в целом. Используем конструктивный подход к проектированию структуры редактора сетевых графиков. Закрепим на первом шаге за головным

модулем подсистемы все функции, составляющие F (см. рис.1.2). Тогда спецификация головного модуля редактора сетевых графиков полностью совпадет со

сетевого плана работ. В соответствии с рекомендациями модульного программирования [14, с. 58] на первом шаге отделим ввод/вывод от остальных операций, т.е. выделим подзадачи, а значит и модули, отвечающие за ввод исходных данных (функция F1) и вывод результатов (функция F3). Таким образом, на первом шаге получаем структуру, изображенную на рис. 3.1.1.

Спецификация редактора СГ (головного модуля)

Текст головного модуля

Спецификация подзадачи “РАСЧЕТ”

(F2)

Рис. 3.1.1. Первый шаг формирования модульной структуры редактора сетевых графиков (СГ)

Содержание подзадач “ВВОД” и “ВЫВОД” рассмотрено в примере 1.1. Подзадача “РАСЧЕТ” является хорошо структурированной. Для ее решения разработан и проверен практикой комплекс алгоритмов [19]. Используя эти алгоритмы на втором шаге целесообразно выделить модули (или подпрограммы), реализующие:

–расчет временных характеристик событий (модуль “МОМЕНТЫ”);

–расчет резервов времени на работы (модуль “РЕЗЕРВЫ”);

–выбор критического пути (модуль “КРИТИЧЕСКИЙ ПУТЬ”).

Врезультате декомпозиции функции F2 подзадачи “РАСЧЕТ” на F2s (s=1, 2, 3) получим структуру, изображенную на рис. 3.1.2.

Специфицируем подзадачи 2.1, 2.2 и 2.3.

F213 – расчет ожидания – резервов времени i-х событий: t0(i)=( tп (i)-tр(i) ).

Исключительные ситуации:

Er1 – ошибка отрицательности: x < 0, x Xi, i= 5, 6.

Подзадача 2.2 – “РЕЗЕРВЫ”. Информационные объекты:

-входные:

tp (j) и tп (j) – множество наиболее ранних и наиболее поздних моментов наступления j-х событий;

фi,j - множество длительностей (i, j)-х работ, фi,j=x X2;

-выходные:

1Y7 – множество резервов времени событий t0(i), i=1,…,n;

1Y8 – 1Y 11 – множества полных фi,jо полн., свободных фi,jо своб., независимых фi,jо незав. и гарантированных фi,jо гаран. резервов времени на работы.

Спецификация функций F22t,(t=1, 2, 3, 4) – расчета резервов времени на (i, j)-е работы:

(F224) расчет гарантированного резерва: фi,jо гаран.= ( tп (j)- tп(i)- фj,i)

Подзадача 2.3 – “КРИТИЧЕСКИЙ ПУТЬ”. Информационные объекты:

-входные:

t0(i) – множество резервов времени i-х событий;

фi,jо полн. – множество полных резервов времени на (i, j)-е работы;

-выходные:

Спецификация функций F23 t:

(F231)– формирование сетевого графика; (F232) – определение критического пути; (F233) – определение длины критического пути.

Дополнительная функция (F07 ) – проверка наличия критического пути и обработка исключительной ситуации Er1.

Исключительные ситуации:

Er1 – ошибка отсутствия критического пути.

Структура модулей ПС “Редактор СГ” представлена на рис. 3.1.2. Связи в данной структуре являются управляющими.

TLP_Curs Password

HelpWnd

About

FuncProc

GlobalData

MainWindow Image

GroupWnd

Рис. 3.1.2

Рекомендуемая к разделу 3 литература:

[2, с. 131-139; 8, с. 20-37; 9, с. 207-215; 14, с. 61-68].

4. Методические указания к разделу 4 –

“РАЗРАБОТКА ПРОГРАММНЫХ МОДУЛЕЙ ”

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

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

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

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

программирования (например, дисциплиной структурного программирования и дисциплиной повторного использования кода).

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

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

Контроль программного модуля. Целесообразны следующие методы контроля правильности программного модуля: статическая проверка текста модуля; сквозное прослеживание; доказательство свойств программного модуля.

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

Сквозное прослеживание представляет собой один из видов динамического контроля модуля. В нем также участвуют несколько

программистов, которые вручную “прокручивают” выполнение модуля на некотором наборе тестов.

Доказательство свойств программных модулей целесообразно проводить на основе прототипов модулей, например логических прототипов [15, с. 68-87; 16]. При этом целесообразно создать двухуровневый логический прототип – функциональный имитатор модуля: вначале осуществить информационную имитацию, а затем – функциональную.

Протокол проверки правильности модуля оформляется способом, приведенным в разделе 1.

Наконец, Необходимо задокументировать модуль, например, одним из способов, приведенных в [15, с. 57].

4.1. Пример разработки модулей редактора сетевых графиков. Для реализации программных модулей, описанных в табл. 3.1, выбрана среда разработчика Delphi и используемый в ней язык Object Pascal. Выбор инструментария обосновывается тем, что в Delphi реализуется технология быстрой разработки приложений (RAD-технология), основывающаяся на CASE-технологии и компонентном программировании, являющимся разновидностью объектно-ориентированного, в том числе визуального программирования. Кроме того, Delphi на сегодняшний день является наилучшим (по показателям простоты, скорости, качества разработки и открытости) инструментальным средством создания интерфейсов взаимодействия с пользователем.

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

Модуль TLP_Curs создается средой Delphi практически полностью автоматически и поэтому не требует тестирования.

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

Модули Image, GroupWnd, MainWindow, About, HelpWnd частично формируются средой Delphi, что также уменьшает затраты времени и труда на их создание, увеличивает надежность их работы, а также существенно уменьшает вероятность ошибок при их конструировании.

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

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

Спецификация функций программных модулей ПС и связанных с ними форм дана в табл.4.1.

До конструирования программных модулей необходимо осуществить объектную спецификацию ПС, которую проводят на основе технологии структурирования объектов реального мира [15, с.100-102]. Для реализуемой функции F и требований к интерфейсу объектами такой спецификации, кроме необходимого класса TForm, используем:

–главное и всплывающее меню − TMainMenu и TPopupMenu (а значит, и пункт меню − TMenuItem);

–таблицу строк − TStringGrid;

–cтатус-строку − TSatusBar для отображения текущей информации;

– инструментальную панель и кнопки для нее − TТoolBar и TToolButton; -отображение картинок и хранилище изображений − TImage; и TImageList;

–набор закладок − TТabSet;

–выбор/отображение цвета − TColorDialog;

–диалоги открытия и сохранения изображений TOpenPictureDialog TSavePictureDialog;

–диалоги открытия и сохранения файлов TOpenDialog и TSaveDialog;

–таймер − TТimer − для отсчета интервалов реального времени;

–индикатор прогресса − TProgressBar − для отображения хода длительного по времени процесса;

–медиаплейер TMediaPlayer − для управления звуковой картой

инекоторые другие.

Используем в качестве необходимых для разработки приложения объектов имеющиеся в Delphi 6.0 компоненты. Аналогично следует специфицировать используемые приложением данные.

В качестве примеров приведем тексты двух из девяти разработанных в среде Delphi программных модулей. Это модуль TLP_Curs.dpr:

program TLP_Curs;

{ФУНКЦИЯ: ГЛАВНЫЙ УПРАВЛЯЮЩИЙ МОДУЛЬ} {РАЗМЕР : 946 / 1709056 байтов }

{%File 'demo.wrk'} {%File 'Canyon.mid'} {%File 'HelpText.txt'}

uses Forms,

Image in 'Image.pas' {LLMImage}, mainwindow in 'mainwindow.pas' {MainWnd}, GlobalData in 'GlobalData.pas',

FuncProc in 'FuncProc.pas', About in 'About.pas' {AboutBox},

GroupWnd in 'GroupWnd.pas' {GroupWindow}, HelpWnd in 'HelpWnd.pas' {HelpWindow}, Password in 'Password.pas' {PasswordWnd};

{$R *.RES}

begin Application.Initialize;

Application.Title := 'ЛЛМ-проект'; Application.HelpFile := '';

Application.CreateForm(TLLMImage, LLMImage);

Application.CreateForm(TGroupWindow, GroupWindow);

Application.CreateForm(TMainWnd, MainWnd);

Application.CreateForm(TAboutBox, AboutBox);

Application.CreateForm(THelpWindow, HelpWindow);

Application.CreateForm(TPasswordWnd, PasswordWnd);

Application.Run;

end.

и модуль About:

unit About;

{ФУНКЦИЯ: ОПИСАНИЕ ОКНА "О ПРОГРАММЕ" И ЕГО ПОВЕДЕНИЯ} {РАЗМЕР : 762 / 3625 байтов }

interface

uses Windows, SysUtils, Classes, Graphics, Forms, Controls, StdCtrls, Buttons, ExtCtrls;

type

TAboutBox = class(TForm) plScale: TPanel; imProgramIcon: TImage; lbProductName: TLabel; lbVersion: TLabel; lbCopyright: TLabel; lbComments: TLabel; bnOK: TButton; lbProjectManager: TLabel;

procedure bnOKClick(Sender: TObject);

private

{Private declarations } public

{Public declarations } end;

var

AboutBox: TAboutBox;

implementation

{$R *.DFM}

procedure TAboutBox. bnOKClick(Sender: TObject); begin

AboutBox.Hide;

end;

end.

Код, написанный вручную в приведенных выше текстах модулей, выделен жирным курсивом.

Количественные характеристики всех программных модулей разработанного ПС приведены в табл. 4.2:

Итак:

–общее количество программных модулей созданного ПС – 9,

–суммарный объем их исходных текстов – 41 074 байтов,

–доля ручного кода при написании отдельных модулей составила от до 2 до

70%.