Тема: Построение диаграммы развертывания (deployment diagram)

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

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

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

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

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

Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними.

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

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

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

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

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

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

Графически на диаграмме развертывания узел изображается в форме трехмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис. 6.8.1, а), так и в качестве экземпляров (рис. 6.8.1, б).

Рисунок 6.8.1. Графическое изображение узла на диаграмме развертывания

В первом случае имя узла записывается без подчеркивания и начинается с заглавной буквы. Во втором имя узла-экземпляра записывается в виде < имя узла ': ' имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов, присутствующих в модели системы.

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

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

Рисунок 6.8.2. Графическое изображение узла-экземпляра с дополнительной информацией в форме помеченного значения

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

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

Рисунок 6.8.3. Варианты графического изображения узлов-экземпляров с размещаемыми на них компонентами

В качестве дополнения к имени узла могут использоваться различные стереотипы, которые явно специфицируют назначение этого узла. Хотя в языке UML стереотипы для узлов не определены, в литературе встречаются следующие их варианты: " процессор", " датчик", " модем", " сеть", " консоль" и др., которые самостоятельно могут быть определены разработчиком. Более того, на диаграммах развертывания допускаются специальные обозначения для различных физических устройств, графическое изображение которых проясняет назначение или выполняемые устройством функции.

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

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

Рисунок 6.8.4. Фрагмент диаграммы развертывания с соединениями меходу узлами

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

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

Рисунок 6.8.5. Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами

Рисунок 6.8.6. Диаграмма развертывания для системы удаленного обслуживания клиентов банка

На этой диаграмме развертывания указана зависимость компонента реализации диалога " dialog.exe" на удаленном терминале от интерфейса lAuthorise, реализованного компонентом " main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре " Сервер банка". Последний зависит от компонента базы данных " Клиенты банка", который развернут на этом же узле.

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

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

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

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

Вариант физического представления этой транспортной системы показан на следующей диаграмме развертывания (рис. 6.8.7).

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

Рисунок 6.8.7. Диаграмма развертывания для модели системы управления транспортной платформой

 

 

Лабораторная работа №7

Тема: Разработка технического проекта (ТП)

Цель работы: Разработать технический проект на разработку программного продукта.

Время выполнения 4 часа.

Краткие теоретические сведения:

В состав технического проекта должны входить следующие разделы:

1 Общие сведения

2 Описание предметной области

3 Описание проектных решений

3.1 Решения по архитектуре

3.2 Информационная модель и структура базы данных

3.3 Структура входных данных

3.4 Функциональные решения

3.5 Структура выходных данных

3.6 Пользовательский интерфейс

3.7 Описание алгоритмов

3.8 Информационное обеспечение

3.9 Интерфейс с другими компонентами и программными

продуктами

3.10 Прочие проектные решения

4 План тестирования

5 Документирование

6 Приложения

 

Примерное содержание разделов технического проекта

 

Общие сведения

Формулировка задания на разработку.

Ссылка на техническое задание, согласно которому разработан технический проект.

Примечание – Если ТЗ не разрабатывалось, общие сведения приводятся в объеме раздела 1 типовой формы «Техническое задание»

 

Описание предметной области

Данный раздел должен содержать информацию, достаточную для понимания сути, специфики и объема работ по техническому проекту. Примерная структура и содержание – аналогично разделу 2 типовой формы «Техническое задание».

Примечание – В случаях, когда имеется документ «Описание предметной области», либо раздел ТЗ, содержащий необходимую информацию, они включаются в состав приложений к ТП со ссылкой в данном разделе. При необходимости здесь могут быть даны пояснения и дополнения. Дублирование информации, содержащейся в указанных документах, не производится.

3 Описание проектных решений

Текстовое описание и схемы решений, влияющих на архитектуру системы.

Решения по архитектуре

 

3.2 Информационная модель и структура базы данных

Текстовое описание и схемы реализуемых проектов, их атрибу-тов, состояний и взаимосвязей.

Описание (схемы) логической и физической структуры базы данных.

 

3.3 Структура входных данных

Описание состава и структуры входных данных, включая:

- данные, вводимые пользователем при работе с функциями, перечисленными в разделе «Функциональные решения»;

- данные, хранящиеся в БД системы;

- значения, используемые по умолчанию.

 

3.4 Функциональные решения

Структура меню модуля

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

Пример:

Документы

| Карточка учета товара

|Накладная на внутреннее перемещение

…

| Накладная на реализацию

| Акт на списание

| Накладная на возврат

|от покупателя

|поставщику

| на оптовый склад

Перечень функций

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

 

Раздел меню, наименование	Назначение, ссылка на описание бизнес-процесса	Использует обьекты (входные данные)	Оперирует с объектами (выходные данные)
Меню «Документы»
Приходные накладные	Ввод и редактирование накладных на приход от поставщика непосредственно в розницу (раздел 2.ХХ, рисунок N, операция М)	Каталог подразделений Каталог МОЛ Каталог контрагентов Каталог КУТ	Создает прихо-ды на заданный разрез хранения
Акт на списание	Ввод и редактирование (раздел 2.ХХ, рисунок N, операция М)	Каталог подразделений Каталог МОЛ Записи по при- ходам (КУТ)	Записи по расходам с выбранных приходов

Примечание – Раздел 3.4 считается обязательным, исключение не допускается. В случаях, когда данная информация полностью отражается в предшествующем ТЗ и не изменена в ТП, допускается ссылка на соответствующий раздел ТЗ. При расхождении между ТЗ и ТП информация в ТП приводится целиком, изменение отмечается фоном и дается примечание («изменено по сравнению с ТЗ»). Если предметом ТП является одиночная функция, допускается вместо структуры меню указывать только путь (способ активизации), приводить текстовое описание.

3.5 Структура выходных данных

Состав и структура выходных данных.

Решения по реализации печатных форм первичных и отчетных документов.

 

3.6 Пользовательский интерфейс

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

 

3.7 Описание алгоритмов

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

 

3.8 Информационное обеспечение

Решения по срокам хранения данных.

Решения по изменению (дополнению) общесистемных справочников и классификаторов.

Решения по изменению (дополнению) параметров настройки (общесистемных, настройки пользователя).

Решения по изменению (дополнению) других таблиц БД, относящихся к другим компонентам системы.

Решения по использованию конкретных СУБД.

Решения по обеспечению конвертации.

 

3.9 Интерфейс с другими компонентами и программными продуктами

Описание интерфейса с другими компонентами системы.

Описание интерфейса с другими программными продуктами (включая экспорт-импорт данных).

 

3.10 Прочие проектные решения

Решения по обеспечению быстродействия.

Решения по обеспечению надежности.

Решения по доработкам инструментария.

Другие решения.

Примечание – При необходимости последовательность перечисленных выше подразделов может быть изменена.

План тестирования

 

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

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

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

Документирование

 

Справочная подсистема

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

Документация пользователя.

Указания:

- по разработке отдельной книги документации;

- по дополнению существующих книг (новые разделы, либо добавления в существующие разделы).

Приводится примерный объем и структура документации.

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

 

Титульный лист ТП должен быть оформлен в соответствии с рисунком 7.1.

 

Наименование министерства

Наименование учреждения

 

 

(Наименование)

Модуль(и)(“Наименование”)

Версия X.XX

 

ТЕХНИЧЕСКИЙ ПРОЕКТ

 

Руководитель /Фамилия И.О/

Разработчик /Фамилия И.О/

 

(Город разработки)200___

 

 

Рисунок 7.1

 

 

Пример оформления технического проекта

Министерство образования Республики Беларусь

Учреждение образования

«Минский государственный высший радиотехнический колледж»

 

 

 

«АВТОМАТИЗАЦИЯ СКЛАДСКОГО УЧЕТА АВТОСЕРВИСА»

Версия 1.01

 

ТЕХНИЧЕСКИЙ ПРОЕКТ

 

Руководитель /Петров Н.Н./

 

Разработчик /Николаев М.М./

 

 

 

Содержание

 

1 Общие сведения
2 Описание предметной области
3 Описание проектных решений
3.1 Решения по архитектуре
3.2 Информационная модель и структура базы данных
3.3 Структура входных данных
3.4 Функциональные решения
3.5 Структура выходных данных
3.6 Пользовательский интерфейс
3.7 Описание алгоритмов
3.8 Информационное обеспечение
3.9 Прочие проектные решения
4 План тестирования
5 Документирование
Приложение А – Накладная на получение товара организа- цией ОАО «Руно-Авто»
Приложение Б – Квитанция, выдаваемая клиенту при по- купке запчастей
Приложение В – Квитанция, выдаваемая заказчику при сда- че машины в ремонт
Приложение Г – Квитанция, выдаваемая заказчику при получении машины из ремонта
Приложение Д – Квитанция, выдаваемая клиенту при по- купке автомобиля
Приложение Е – Пароль Администратора

 

1 Общие сведения

 

1.1 Формулировка задания

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

Основанием для разработки данного ПП является договор №1 между Заказчиком (ОАО «Руно-Авто») и Разработчиком (ООО «ЯВХС») от 10.09.1999 г. и «Техническое Задание» от 12.09.99 г., переданное Заказчиком Разработчику.

 

2 Описание предметной области

Данный раздел подробно описан в разделе 2 ТЗ.

 

3 Описание проектных решений

 

3.1 Решения по архитектуре

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

Архитектура разрабатываемого ПП складывается из следующих БД:

- БД по продаже автомобилей.

Данная БД содержит следующие таблицы:

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

Эта таблица содержит ссылку на подфункцию, формирующую договор поставки на продажу;

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

 

 

Кроме того, таблица содержит ссылку на подфункцию, формирующую договор «купли/ продажи автомобиля» (приложение А);

- БД запасных частей.

Данная БД содержит следующие таблицы:

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

Так же таблица имеет ссылку на подфункцию формирования документов, подтверждающих получение запчастей (приложение Б);

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

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

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

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

 

- БД автомобилей, находящихся в ремонте.

Данная БД содержит следующие таблицы:

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

Так же таблица имеет ссылку на подфункцию формирования документов, подтверждающих заказ (приложение Г);

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

Так же таблица содержи ссылку на подфункцию формирования сопроводительных документов (приложение Д).

3.2 Информационная модель и структура БД

Ниже приведено описание основной БД разрабатываемого ПП:

 

- ведение базы данных по продаже автомобилей.

Данная функция осуществляет создание и корректировку двух видов учета:

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

- ведение учета продажи автомобиля, включающего все реквизиты покупателя, марку автомобиля, технические характеристики, цену, дату продажи, а так же формирование договора «купли/ продажи»;

- ведение базы данных запасных частей.

Данная функция осуществляет создание и корректировку трех видов учета (формирование производится для каждой марки и модели автомобиля):

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

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

- ведение учета внутреннего перемещения запчастей, включающего наименование детали, дату перемещения, назначение перемещения, а так же формирование и учет внутренних ТТН;

- ведение базы данных по автомобилям, находящимся в ремонте.

Данная функция осуществляет создание и корректировку двух видов учета:

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

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

 

3.3 Структура входных данных

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

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

 

3.4 Функциональные решения

Далее приведена подробная структура меню разрабатываемого ПП:

Основное меню:

Список автомобилей в продаже

Вывести список

Изменить запись

Формирование документов

Просмотр созданных

Создать новый

Внесение изменений

Добавить запись

Удалить запись

Список автомобилей в ремонте

Вывести список

Изменить запись

Формирование документов

Просмотр созданных

Создать новый

Внесение изменений

Добавить запись

Удалить запись

Список запасных частей

Вывести список

Изменить запись

Внутреннее движение

Формирование документов

Просмотр созданных

Создать новый

Внесение изменений

Добавить запись Удалить запись

Поисковая система

Поиск автомобиля

Поиск автомобиля в продаже

Поиск по марке автомобиля

Поиск по конкретной модели

Поиск по цене

Поиск запчастей

Поиск по наименованию

Поиск по модели

Поиск автомобиля в ремонте

Поиск по коду заказчика

Поиск по модели автомобиля

Help

 

3.5 Структура выходных данных

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

 

3.6 Пользовательский интерфейс

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

При необходимости интерфейс изменяется только Разработчиком.

 

3.7 Описание алгоритмов

При обработке данных в разрабатываемомПП используются стандартные алгоритмы СУБД FoxPro 2.0. Описание этих алгоритмов можно прочитать в пункте меню «Help» разрабатываемого ПП.

 

3.8 Информационное обеспечение

Изменение и внесение новых данных производится в указанных в п.3.4 пунктах меню, что способствует оперативному пополнению/ изменению БД.

ПП не содержит встроенного модуля сетевого обмена информацией с другими БД.

 

3.9 Прочие проектные решения

Разрабатываемый ПП будет функционировать в ОС Win 9x, NT, 2K. Другие ОС не поддерживают формат создаваемых файлов в процессе работы с ПП.

Хранение данных пользователя производится в файлах с встроенной защитой, не подлежащих удалению без пароля Администратора (приложение Е).

ПП использует нижние регистры памяти, что обеспечивает защиту от сбоев на 95 %.

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

Сетевой обмен информацией с другими БД.

При создании БД происходит резервное сохранение информации, вводимой пользователем в файлы с расширением «pole». Сетевой обмен происходит за счет передачи/ получения файлов с таким же расширением от других систем, для этого необходимо всю нужную информацию другой БД сохранить в файл с расширением «txt» (текстовый), затем переименовать текстовый файл с расширением «pole». После этого полученный файл поместить в директорию:

c: \Program Files\AutoServAutomatisation\main\bd\info\pole.

 

4 План тестирования

 

Тестирование проводится Разработчиком по предложенной схеме Заказчика:

1) создается БД небольшого объема по всем таблицам и пунктам меню;

2) в течение срока, указанного в договоре, Разработчик проводит тестирование ПП и передает Заказчику готовый программный продукт, который будет сопровождаться Разработчиком в течении сроков, предусмотренных договором.

 

5 Документирование

 

Разработанный ПП сопровождается полным пакетом документов, предусмотренным ГОСТ 7685 – 2000, а именно:

1) лицензионное право использования разработанного ПП;

2) документация по эксплуатации;

3) талон на последующее обслуживание ПП;

4) документы, подтверждающие монопольное использование разработанного ПП.

 

ПРИЛОЖЕНИЕ А

(справочное)

 

⇐ Предыдущая123456Следующая ⇒

Поделиться: