Операционные системы. Задание. Техническое задание явля ется первым разделом курсовой работы. 1
 Скачать 0.67 Mb.
|
|
5 РУКОВОДСТВО СИСТЕМНОГО ПРОГРАММИСТА Составление руководства системного программиста — цель третьей части второй лабораторной работы. Также руководство системного программиста является пятым разделом курсовой работы. Требования к оформлению руководства системного про- граммиста излагаются в ГОСТ 19.503-79 «Руководство систем- ного программиста. Требования к содержанию и оформлению». 5.1 ГОСТ 19.503-79 Настоящий стандарт устанавливает требования к содержа- нию и оформлению программного документа «Руководство сис- темного программиста», определенного ГОСТ 19.101-77. Стандарт полностью соответствует CТ СЭВ 2094-80. 5.1.1 Общие положения 1.1. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78. 1.2. Руководство системного программиста должно содер- жать следующие разделы: – общие сведения о программе; – структура программы; – настройка программы; – проверка программы; – дополнительные возможности; – сообщения системному программисту. В зависимости от особенностей документа допускается объединять отдельные разделы или вводить новые. В обосно- ванных случаях допускается раздел «Дополнительные возмож- ности» не приводить, а в наименованиях разделов опускать сло- во «программа» или заменять его наименованием программы. 66 5.1.2 Содержание разделов 2.1. В разделе «Общие сведения о программе» должны быть указаны назначение и функции программы и сведения о техни- ческих и программных средствах, обеспечивающих выполнение данной программы. 2.2. В разделе «Структура программы» должны быть при- ведены сведения о структуре программы, ее составных частях, о связях между составными частями и о связях с другими про- граммами. 2.3. В разделе «Настройка программы» должно быть приве- дено описание действий по настройке программы на условиях конкретного применения (настройка на состав технических средств, выбор функций и др.). При необходимости приводят поясняющие примеры. 2.4. В разделе «Проверка программы» должно быть приве- дено описание способов проверки, позволяющих дать общее заключение о работоспособности программы (контрольные примеры, методы прогона, результаты). 2.5. В разделе «Дополнительные возможности» должно быть приведено описание дополнительных разделов функцио- нальных возможностей программы и способов их выбора. 2.6. В разделе «Сообщения системному программисту» должны быть указаны тексты сообщений, выдаваемых в ходе выполнения настройки, проверки программы, а также в ходе выполнения программы, описание их содержания и действий, которые необходимо предпринять по этим сообщениям. 2.7. В приложении к руководству системного программиста могут быть приведены дополнительные материалы (примеры, иллюстрации, таблицы, графики и т.п.). 5.2 Пример 5.2.1 Общие сведения о программе Программа «Автоматизированное рабочее место читателя» предназначена для обеспечения простого и удобного доступа удаленных пользователей к ресурсам различных информацион- ных служб. Удаленными пользователями могут являться любые 67 пользователи HTTP-сервера, на базе которого функционирует программа. Ресурсами информационных служб могут являться различные удаленные базы данных (библиографические, полно- текстовые, базы данных запросов на доставку документов, те- заурусы), доступные по протоколу ISO 23950. Таким образом, программа является промежуточным звеном многозвенной ин- формационной системы, обеспечивающим пользователей сле- дующими возможностями: − поиск библиографической, полнотекстовой информации, информации о заказах, сведений о местонахождении и доступ- ности документа в удаленных базах данных с возможностями устранения дублетности, навигации по поисковым индексам и автоматического расширения запроса с использованием тезау- русов и авторитетных файлов; − заказ документа (копии) по найденному библиографиче- скому описанию; − проверка статуса заказа; − вывод списка документов, полученных во временное пользование. Другими словами, программа является Z39.50-клиентом с Web-интерфейсом пользователя. Поэтому для работы с про- граммой пользователю необходимы лишь Web-агент (Netscape Navigator, MS Internet Explorer, Lynx и т.п.) и надежная связь с HTTP-сервером, на котором выполняется программа. Программа может функционировать на любых технических средствах под управлением любой операционной системы, от- вечающей стандарту ISO/IEC 9945-1 (POSIX) и спецификациям X/Open CAE specifications, Issue 4, July 1992 (XPG4). Обязатель- ными требованиями для выполнения программы являются под- держка стека протоколов TCP/IP и наличие HTTP-сервера, под- держивающего CGI. 5.2.2 Структура программы Программа «Автоматизированное рабочее место читателя» состоит из следующих компонентов: 1) zcon — приложение, реализующее функции Z39.50-кли - ента; 68 2) zgate — CGI-приложение, обеспечивающее передачу дан- ных от HTTP-сервера Z39.50-клиенту и обратно; 3) zgate.cat — каталог сообщений, используемый двумя вы- шеуказанными приложениями для формирования выходных дан- ных. Количество таких каталогов равняется количеству поддержи- ваемых программой языков сообщений (как минимум, два — рус- ский и английский); 4) zgate.xsl — основная XSLT-программа визуального пред- ставления выходных данных. Может редактироваться админи- стратором в целях изменения содержания и формы представле- ния выходных данных; 5) usmarc.xsl — подпрограмма визуального представления записей в формате MARC21 (USMARC). Может редактировать- ся администратором в целях изменения содержания и формы представления выходных данных. 6) … Примечание. Для правильного функционирования про- граммы необходима установка следующих библиотек, поддер- живающих операции над XML-документами и XSLT: − xml2 — библиотека поддержки операций над XML-доку - ментами; − xslt — библиотека поддержки XSLT; − exslt — библиотека поддержки расширений XSLT. В версию программы для операционных систем, не под- держивающих спецификации X/Open CAE specifications, Issue 4, July 1992 для интерфейсов catgets и iconv (например, Microsoft Windows), дополнительно включаются следующие библиотеки: − catgets — интерфейс поддержки каталогов сообщений; − iconv — интерфейс конвертора данных из одного коди- рованного набора символов в другой. 5.2.3 Настройка программы 5.2.3.1 У СТАНОВКА ПРОГРАММЫ В настоящем документе для именования файлов использу- ется синтаксис, определенный ISO/IEC 9945-1. В тех операци- онных системах, которые не поддерживают указанный способ 69 именования файлов в приложениях, используемых при установ- ке и настройке программы, следует использовать способ имено- вания файлов, определяемый используемой операционной сис- темой. Если, например, используется операционная система Mi- crosoft Windows, то указанное в настоящем документе имя фай- ла вида /a/b/c/f следует заменить на X: \ a \ b \ c \ f, где X: — название диска, на котором размещаются приложения zcon и zgate. 1. Разместить исполняемые файлы zcon и zgate в каталоге CGI-приложений HTTP-сервера. 2. Разместить файлы zgate.cat и ru_RU.UTF-8/zgate.cat в од- ном из системных каталогов сообщений, определяемых пере- менной окружения NLSPATH. Если, например, NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/dt/lib/nls/msg/%L/%N.cat, то необходимо поместить файл C/zgate.cat в каталог /usr/lib/nls/msg/С, а файл ru_RU.UTF-8/zgate.cat в каталог /usr/lib/nls/msg/ru_RU.UTF-8. Если определить местонахождение системного каталога сообщений невозможно, то следует размес- тить указанные файлы в каталоге /usr/lib/nls/msg и присвоить переменной окружения NLSPATH значение /usr/lib/nls/msg/%L/%N. 3. … Примечание. Пользователь, устанавливающий программу, должен иметь полномочия, достаточные для записи указанных файлов в требуемые каталоги. В указанных каталогах должно быть достаточно свободного пространства для размещения фай- лов, в т.ч. и временных, размер которых зависит от размеров записей, извлекаемых пользователем. 5.2.3.2 Н АСТРОЙКА ПРОГРАММЫ Обычно в данном подразделе приводятся несколько скриншотов рабочего окна программы с описанием (куда надо нажать и что ввести, чтобы получить результат) и описывается процедура настройки (если присутствует). 5.2.4 Проверка программы Проверка программы осуществляется методом ее выполне- ния. В связи с тем, что конкретные условия применения про- 70 граммы (адреса Z39.50-серверов, названия баз данных, поддер- живаемые точки доступа, форматы записей и т.п.) не могут быть известны заранее, можно ограничиться следующими рекомен- дациями: 1. При проверке программы следует использовать все воз- можные элементы управления — списки с точками доступа, операторами, форматами записей, выключатели и т.п. Напри- мер, можно последовательно осуществлять поиск по каждой из возможных точек доступа, затем получать записи в каждом из возможных форматов и т.д. 2. При получении диагностических и иных сообщений в хо- де проверки программы следует обращаться к разделу «Сооб- щения системному программисту» данного руководства. 5.2.5 Дополнительные возможности Дополнительной возможностью программы является воз- можность динамического управления формой представления записей при просмотре их в полном формате («Детальная ин- формация») при помощи Web-агента, поддерживающего редак- тирование текущего URL. В этом случае URL имеет вид: "http://"<адрес_сервера>":"<порт>"/" <каталог_с_CGI-приложениями>"zgate?present+" <идентификатор_соединения>"+" <наименование_результирующего_множества>"+" <номер_первой_записи_в_выдаваемой_порции>"+" <количество_записей>"+" <наименования_набора_элементов>"+" <формат_записи>"+" <код_языка_интерфейса_пользователя>". 5.2.6 Сообщения системному программисту В таблице 5.1 представлены сообщения, которые могут по- лучить системный программист в ходе выполнения настройки, проверки программы, а также пользователь в ходе выполнения программы. Описано содержание этих сообщений и действия 71 системного программиста, которые необходимо предпринять по этим сообщениям. Таблица 5.1 — Сообщения системному программисту и пользователю Сообщение Описание Действия системного программиста В шлюз не включена форма <имя_файла>. Отсутствует файл <имя_файла> с поис- ковой формой, ука- занный в одном из параметров настройки программы. Проверить наличие файла с именем <имя_файла>. При необходимости создать файл с указанным именем либо изменить параметры на- стройки таким образом, что- бы включалась уже сущест- вующая форма. В форме не указана переменная <название_пере - менной> В форме отсутствует обязательный элемент управления <название_пе - ременной>. Добавить в форму элемент управления <на - звание_переменной>. Недостаточное коли- чество параметров! Точка входа для дос- тупа к Z39.50-серверу не соответствует фор- мату, указанному в п. 5.2.3.2 настоящего документа. Привести точку входа в со- ответствие с требованиями, добавив необходимый пара- метр к значению атрибута href соответствующей ги- перссылки. … … … 72 СПИСОК ЛИТЕРАТУРЫ Основная: 1. Калайда В.Т., Романенко В.В. Технология разработки про- граммного обеспечения: Учебное пособие. — Томск: ТМЦДО, 2007. — 236 с. 2. Зельковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения. — М.: Мир, 1982. — 368 с. 3. Гантер Р. Методы управления проектированием про- граммного обеспечения. — М.: Мир, 1981. — 388 с. 4. Брукс Фредерик. Мифический человеко-месяц или как создаются программные системы. — СПб.: Символ, 2000. — 298 с. 5. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. — М.: Фи- нансы и статистика, 1998. — 176 с. 6. Канер С., Фолк Дж., Нгуен Е.К. Тестирование программ- ного обеспечения. — Киев: Диасофт, 2000. — 544 с. Дополнительная: 1. Вольховер В.Г., Иванов Л.А. Производственные методы разработки программ. — М.: Финансы и статистика, 1983. — 236 с. 2. Боем Б. и др. Характеристики качества программного обеспечения. — М.: Мир, 1981. — 176 с. 3. Буч Г. Объектно-ориентированный анализ и проектиро- вание с примерами приложений на С++. — М.: Бином; СПб.: Невский диалект, 1999. — 560 с. 73 ПРИЛОЖЕНИЕ А Оформление курсового проекта Федеральное агентство по образованию ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР) Кафедра автоматизированных систем управления (АСУ) НАЗВАНИЕ ПРОЕКТА Пояснительная записка к курсовому проекту по дисциплине «Теория разработки программного обеспечения» Выполнил: ст. группы XXX ______________ Иванов И.И. «____» ____________ 2007 Проверил: доц. каф. АСУ ____________ Елизаров А.И. «____» ____________ 2007 Томск – 2007 74 (С новой страницы) Р ЕФЕРАТ Курсовой проект состоит из XX страниц, содержит XX таблиц и XX рисунков. В результате проведенной работы была разработана техническая документация к программному проекту «НАЗВАНИЕ ПРОЕКТА». Пояснительная записка к курсовому проекту выполнена в редак- торе MS Word. (С новой страницы) С ОДЕРЖАНИЕ 1. Техническое задание XX 2. Соглашение о требованиях XX 3. Спецификации XX 4. Тестирование XX 5. Руководство системного программиста XX 6. Заключение XX Примечание. Пункты 5 и 6 являются необязательными. В содер- жание также включаются, как минимум, пункты второго уровня. 75 ПРИЛОЖЕНИЕ Б Пример выполнения курсового проекта № 1 1 Т ЕХНИЧЕСКОЕ ЗАДАНИЕ 1.1 Введение Наименование разрабатываемого программного обеспечения — переносимая программа трансляции данных по различным протоколам (Data Retranslation, DR). Данное программное обеспечение применяется для перенаправ- ления HTTP, FTP, SSL и других запросов и данных с клиентской ма- шины через промежуточную машину на другие вышестоящие proxy- серверы. Выбор вышестоящего proxy-сервера осуществляется в соот- ветствии с ранее определенными приоритетами. Настоящее программное обеспечение может применяться в орга- низациях, располагающих несколькими каналами выхода в Internet. DR должен позволять автоматическое переключение на резервный (менее приоритетный канал) в том случае, если основной канал является не- доступным. 1.2 Основания для разработки Разработка ведется на основании следующих документов: 1. Данное техническое задание 1.3 Назначение разработки Функциональное и эксплуатационное назначение программы: Данная программа призвана осуществлять перенаправления за- просов от клиентов на вышестоящие proxy-серверы в соответствии с определенными для них приоритетами, а также доступностью или не- доступностью того или иного сервера. Программа также позволяет достигать некоторой степени анонимности при работе в сети. 1.4 Технические требования к программе или программному изделию 1.4.1 Требования к функциональным характеристикам − Программа должна полностью поддерживать стандарты пере- дачи гипертекста (HTTP) версий 1.0 и 1.1, утвержденные World Wide 76 Web Consortium (W3C), а так же стандартные протоколы FTP, SSL, SMTP, POP3 и т.д. − Программа должна обеспечивать переносимость в рамках опе- рационных систем семейства Windows. Стандарт, предназначенный для достижения переносимости программного обеспечения на уровне исходных кодов. − Программа должна работать по архитектуре «клиент-сервер», поддерживать несколько одновременных соединений. − Программа должна считывать основные настройки из конфи- гурационного файла, осуществлять это во время работы, без остановки передачи данных. − Конфигурационный файл должен быть легко читаем для чело- века, занимающегося администрированием proxy-сервера. − Программа должна выбирать подходящий вышестоящий proxy-сервер, на который следует перенаправить запрос в соответствии с его приоритетом, определенным в конфигурационном файле, и его текущим статусом (доступен или недоступен). − Программа должна осуществлять проверку вышестоящих proxy-серверов на работоспособность. Это должно осуществляться в фоновом процессе, без прерывания выполнения других операций пе- редачи данных. − Программа должна поддерживать передачу нескольких запро- сов в рамках одного соединения (pipelining). − Программа должна вести журнал своей деятельности, куда бу- дут сохраняться все сообщения об ошибках, нарушениях передачи и прочих проблемах. 1.4.2 Требования к надежности − Программа должна при считывании конфигурационного файла корректно обрабатывать его отсутствие, поврежденность и некоррект- ность введенных в него данных. В случае ошибки соответствующая запись должна быть создана в журнале работы программы и выведено предупреждение на экран. − Программа должна обеспечивать устойчивое функционирова- ние в течение минимум 48 часов. 1.4.3 Требования к эксплуатации Никаких требований к условиям эксплуатации не выдвигается. Для обслуживания требуется один квалифицированный системный администратор. 77 1.4.4 Требования к составу и параметрам технических средств − Для эксплуатации разрабатываемого программного обеспече- ния необходимы Windows-совместимая операционная система (Win- dows 98, WinNT 4.0, WinNT 5.0, WinNT 5.1) и компьютер архитектуры, поддерживаемой этой ОС. − Необходим сетевой адаптер, обеспечивающий связь с Internet. 1.4.5 Требования к информационной и программной совместимости Язык программирования — C или C++. 1.5 Требования к программной документации − В дистрибутиве программного средства должно присутство- вать полное описание процедуры установки программы. − Необходимо также составить синтаксис описания конфигура- ционного файла, а также снабдить дистрибутив примером оформления этого файла. |