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

Создание скриптов Quick Functions осуществляется в диалоговом окне редактора Quick Functions. Вызов этого диалога на экран в окне WindowMaker производится в командой Special/Scripts с последующим нажатием на строке Quick Functions.

Список Name содержит имена всех определенных к данному моменту скриптов Quick Functions. Щелчок по имени скрипта выводит его текст в рабочее поле диалога.

Команда Scripts/New предназначена для создания нового скрипта и вызывает на экран диалог для ввода его имени. После щелчка по Ok новое имя будет включено в список имен Name.

Следующий этап - определение аргументов нового скрипта в таблице Arguments диалога Quick Function. В левую колонку таблицы вводят имя аргумента (до 31 символа), в правую - его тип (Integer, Real, Discrete, Message). В одном скрипте допускается до 16 аргументов.

После определения типов аргументов можно приступать к написанию текста скрипта Quick Function в рабочем поле (под таблицей Arguments).

Разработка графопостроителя в системе InTouch

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

Рисунок 19. - Окно DDE-сервера на стадии проектирования в Delphi. Примечание: [составлено автором]

Разработка DDE-сервера

Приложение, получающее данные из другого приложения по DDE и/или управляющее другим приложением с помощью команд через DDE является DDE-клиентом. В этом случае второе приложение является DDE-сервером. Рассмотрим проект DDE-сервера, выполненного на языке программирования Borland Delphi 6.

На рисунке представлено окно DDE-сервера во время дизайна в среде Delphi

Для построении DDE-сервера в Delphi имеются два объекта, расположенные на странице System Палитры Компонент - TDdeServerConv и TDdeServerItem. Обычно в проекте используется один объект TDdeServerConv и один или более TDdeServerItem. Для получения доступа к сервису DDE-сервера, клиенту потребуется знать несколько параметров: имя сервиса (Service Name) - это имя приложения (обычно - имя выполняемого файла без расширения EXE, возможно с полным путем); Topic Name - в Delphi это имя компоненты TDdeServerConv; Item Name - в Delphi это имя нужной компоненты TDdeServerItem. Назначение объекта TDdeServerConv - общее управление DDE и обработка запросов от клиентов на выполнение макроса.

Объект TDdeServerItem связывается с TDdeServerConv и определяет, что, собственно, будет пересылаться по DDE. Для этого у него есть свойства Text и Lines. (Text имеет то же значение, что и Lines[0].) При изменении значения этих свойств автоматически происходит пересылка обновленных данных во все приложения-клиенты, установившие связь с сервером.

При запуске приложения происходит выполнение процедуры TDDEServe.FormActivate:

procedure TDDEServe.FormActivate(Sender: TObject);

var nidata: TNotifyIconData;

Application.ShowMainForm:= False;

ShowWindow(Application.Handle, SW_HIDE);

ShowWindow(Application.MainForm.Handle, SW_HIDE);

with nidata do

cbSize:= SizeOf(TNotifyIconData);

Wnd:= Self.Handle;

uID:= 1;

uFlags:= NIF_ICON or NIF_MESSAGE or NIF_TIP;

uCallBackMessage:= WM_MYICONNOTIFY;

hIcon:= Application.Icon.Handle;

Shell_NotifyIcon(NIM_ADD, @nidata);

ru:=10;

end;

В этой процедуре приложение сворачивается в системный Tray, а форма становится невидимой. Окончание работы DDE-сервера вызывается путём нажатия левой или правой кнопкой мыши на иконке приложения в области системного Tray. Обработка этого события выполняется в процедуре TDDEServe.WMICON:

procedure TDDEServe.WMICON(var msg: TMessage);

case msg.LParam of

WM_RBUTTONDOWN,WM_LBUTTONDOWN: close;

При этом, при закрытии окна приложения вызывается процедура TDDEServe.FormDestroy, в которой происходит удаление иконки из системного Tray:

procedure TDDEServe.FormDestroy(Sender: TObject);

var nidata: TNotifyIconData;

with nidata do

cbSize:= SizeOf(TNotifyIconData);

Wnd:= Self.Handle;

uID:= 1;

Shell_NotifyIcon(NIM_DELETE, @nidata);

end;

Работа приложения в целом строится посредством вызова процедуры TDDEServe.Timer1Timer по прерыванию таймера.

implementation

{$R *.DFM}

uses ComObj, activex, ShellApi, shlobj, registry;

var

xsin: integer;

ru:real;

boolka:boolean;

procedure TDDEServe.Timer1Timer(Sender: TObject);

var LPTbyte: byte;

begin

xsin:=xsin+1;

if xsin>1000 then xsin:=xsin-1000;

DDEItem100.Text:=inttostr(5*(xsin-20*trunc(xsin/20))); //пилообразный

mov dx,379h

in al,dx

and al,80h

mov LPTbyte,al

end;

DDEItem200.Text:=inttostr(LPTbyte*100); //состояние линии LPT-порта

if (xsin/5)=trunc(xsin/5) then

if (ru<round(50+50*sin(xsin/20))) then

begin

boolka:=true;

ru:=ru+20

end else

begin

boolka:=false;

ru:=ru-20

end;

if boolka then DDEItem400.Text:='100' else DDEItem400.Text:='0';

end;

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

`DDEServer' - имя сервиса (Service Name);

`DDETopic' - Topic Name;

`DDEItem100' - переменная обмена;

`DDEItem200' - переменная обмена;

`DDEItem300' - переменная обмена;

`DDEItem400' - переменная обмена.

Разработка DDE - клиента

Основа человеко-машинного интерфейса в рамках InTouch - это иерархически взаимосвязанные анимированные сенсорные окна. Для создания нового окна выполним команду File/New Window... (Файл/Новое Окно). На экране появится диалоговое окно Window Properties (Свойства Окна), которое необходимо заполнить.

Здесь следует ввести только имя окна (поле Name) Scope. Остальные поля и опции оставлены без изменений. Окно с указанными атрибутами появится на экране. Там же будет отображена и Панель Инструментов InTouch - Tools, с которой предстоит интенсивно работать далее.

График представляет собой прямоугольную область с нанесенными координатными прямыми, на которой графически представляется изменение значения одной или нескольких переменных в течение времени. В пакете InTouch имеются объекты для динамического отображения значения переменной в реальном времени - графики реального времени (инструмент (Real-time Trend)), и, так называемые, аналитические кривые, которые строятся на основании архивных данных (инструмент (Historical Trend)). Для того, чтобы он появился в созданном нами окне, необходимо на Панели Инструментов InTouch - Tools выбрать пункт Real - Time Trend и затем в окне приложения, удерживая нажатой левую кнопку мышки, придать графику необходимые размеры.

Панель настройки графиков вызывается двойным щелчком левой кнопки мышки по окну графика и состоит из четырех текстовых строк соответствующих графикам (Graph 1, Graph 2, Graph 3, Graph 4). Каждый график имеет независимые настройки масштаба и величины сдвига по вертикали, отображаемые на экране. Для этого используется компонент Analog Tagname Display (Wizard Selection Value Displays Analog Tagname Display). Ввод данных осуществляется не непосредственно в WindowViewer, а посредством компоненты Incr/Decr Buttons Up/Down (Wizard Selection Buttons Incr/Decr Buttons Up/Down). Нажатие на верхнюю или нижнюю стрелку приводит соответственно к увеличению или уменьшению значения переменной. Ограничение максимального и минимального значения указываются при декларации. Каждый компонент связан со своей переменной zoom1 - zoom4 (изменение масштаба графиков 1 - 4 соответственно) и sh1 - sh4 (изменение смещения графиков 1 - 4). Все переменные имеют тип Memory Integer. Для того, чтобы ввести новую переменную, необходимо описать ее в разделе Special/Tagname Dictionary/New. При этом необходимо указать ее имя в поле «Tagname:» и тип - в поле «Type:».

Для организации обмена данными через DDE интерфейс необходимо определить четыре (по числу каналов) переменные типа DDE Integer (Item1, Item2, Item3, Item4). Для этого сначала в разделе Special/DDE Access Names… необходимо нажать кнопку Add и в появившемся диалоговом окне указать имя приложения (DDE Application/Server Name), от которого будет производиться запрос данных, и имя группы/объекта (DDE Topic Name), содержащего требуемую информацию. В нашем случае качестве имени приложения используется имя DDEServer, имя объекта - DDETopic. Далее в разделе Special/Tagname Dictionary/New вводятся поочередно переменные типа DDE Integer. Название элемента (Item) для каждой переменной имеет различные имена: DDEItem100 - для Item1, DDEItem200 - для Item2, DDEItem300 - для Item3 и DDEItem400 - для Item4. Данная информация используется для определения DDE-переменной в Словаре Переменных InTouch.

Для того, чтобы запустить программу графопостроителя и начать DDE - обмен, необходимо включить DDE сервер (т. е. запустить файл Ddeserver.exe) и переключиться в окно InTouch - WindowViewer (нажатием кнопки Runtime! в правом верхнем углу окна InTouch - WindowMaker). В процессе работы InTouch WindowViewer автоматически выполнит все требуемые действия по установлению канала обмена данными и обработке значений элемента.

Ниже представлен внешний вид программы графопостроителя в окне InTouch - WindowViewer отображающей в виде четырех графиков данные, полученные от программы DDE сервера и соответствующие им масштабирующие коэффициенты.

Рисунок 20. - Окно программы графопостроителя. Примечание: [составлено автором]

3. РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ПРОЕКТА

3.1 Экономический расчет

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

- сокращение числа занятых работой, так как вычислительная техника призвана автоматизировать эту работу;

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

- увеличение потребления электроэнергии;

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

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

Все сказанное выше в полной мере относится к рассматриваемой в данном документе программе.

Техническая характеристика проекта выглядит следующим образом. Исходными данными являются сам дипломный проект и нормы времени на программирование задач для ПЭВМ от 20.01.93 г.

Основанием для расчета является разработка программного обеспечения.

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

- индекс подсистемы или задачи;

- степень новизны проекта;

- сложность алгоритма;

- стадии проектирования;

- количество разновидностей форм входной и выходной информации.

Данные показатели имеют следующие значения. Индекс подсистемы или задачи - восемь (управление научно технической информацией). Степень новизны проекта - «В» (разработка проекта с использованием типовых проектных решений или имеющих аналогичное решение). Сложность алгоритма - три (алгоритм реализующие стандартные методы решения или не предусматривающие применение сложных численных и логических методов). Стадии проектирования состоят из технического задания, технорабочего проекта и внедрения [24].

Количество используемой информации:

- количество разновидности форм входной информации - 3;

- количество разновидности форм выходной информации - 3.

Стадии проектирования:

- техническое задание;

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

- рабочий проект;

- внедрение.

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

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

Формы выходной информации включают в себя: формы выведенной информации на дисплей, принтер, в файлы и каналы связи.

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

3.2 Оценка затрат на разработку

Оценка затрат на разработку ПО является одним из наиболее важных видов деятельности в процессе создания ПО, хотя она и не выделена в стандарте ISO 12207 как отдельный процесс. При отсутствии адекватной и достоверной оценки невозможно обеспечить четкое планирование и управление проектом. В целом ситуация в данной области, сложившаяся в индустрии информационных технологий, выглядит далеко не блестящей [37].

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

- оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOG - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Определение функциональной точки приведено;

- оценка трудоемкости в человеко-месяцах или человеко-часах;

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

- оценка стоимости проекта [25].

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

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

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

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

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

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

- по крайней мере, один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

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

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценки (например, модель СОСОМО (Constructive COst MOdel - конструктивная стоимостная модель) Барри Боэма).

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

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

Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)). Глава фирмы SPR Каперс Джонс, «гуру» в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип "что заложишь, то и получишь"). В лучшем случае с помощью таких продуктов можно получить оценку с точностью +10%. Даже если точность будет +50%, это все равно лучше, чем брать данные "с потолка".

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

Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", так же переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.

Различные руководства и отчеты организаций, подобных SoftwareEngineering Institute (SEI), которые могут помочь при выполнении уценки проектов.

Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход позволяет привнести немного здравого смысла в проектную команду и в окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала 1 млн строк кода за 12 мес., то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом. Остановимся более подробно на методе функциональных точек. Определение числа функциональных точек является методом количественной оценки ПО, применяемым для измерения функциональных характеристик процессов его разработки и сопровождения независимо от технологии, использованной для его реализации [26].

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

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной организацией IFPUG (International Function Point User Group). Существуют специальные программные средства, автоматизирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является Knowledge PLAN - продукт фирмы SPR.

Knowledge PLAN создан на основе исследований, проведенных в фирме SPR, в области оценок сложности, трудоемкости и производительности при разработке программного обеспечения. Оценка и планирование в пакете KnowledgePLAN ведутся на основе статистических закономерностей, выведенных путем анализа более чем 8 тыс. успешно завершенных проектов из различных областей применения. Исходные данные для вычислений находятся в специальном репозитории, который обновляется по результатам выполнения реальных проектов. В качестве метрик для оценки размеров программного обеспечения используются методика подсчета функциональных точек и метод оценки сложности программного продукта (собственная разработка фирмы SPR) метрика, позволяющая учесть алгоритмическую сложность разрабатываемых программ.