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

⇐ ПредыдущаяСтр 2 из 6Следующая ⇒

Комментарии к примеру. Для разработки данной системы никаких нормативных документов не требуется (стандартов, инструкций и т.п.), поэтому необходимо только сослаться на информацию, где определена структура и свойства ЛК, а также требования к его построению. Также необходимо определить требования по входным и выходным данным. Большинство параметров ЛК будут задаваться пользователем в режиме диалога: он обязательно должен подключить словарь понятий, из которого будут формироваться задания для кроссворда. В данном случае «словарь понятий» – это текстовый файл определенной структуры (каждая строка файла – это понятие и его расшифровка), который должен загружаться в систему из внешней памяти (с любого логического диска), с которым пользователь должен иметь возможность работать дополнительно. Обязательное условие заказчика – возможность создания коллекции ЛК, поэтому в системе должна быть предусмотрена возможность сохранения наиболее интересных кроссвордов в файл. На данном этапе еще трудно определить структуру этого файла (она должна учитывать и возможность дальнейшего разгадывания кроссворда с помощью данной системы), поэтому можно написать, что «структура файла определяется в процессе проектирования». Обязательным условием составления любого типа кроссвордов является его целостность (для данного случая ‑ это отсутствие пустых клеток в середине ЛК), поэтому это обязательно должно быть записано в требованиях.

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

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

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

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

a) Визуализация процессов работы с кроссвордом;

b) Выдача сведений о системе (справочные данные о системе и о том, как с ней работать).

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

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

Ø по быстродействию (времени реакции на выполнение наиболее важных функций);

Ø по режиму работы (диалоговый/интерактивный, автоматический);

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

Ø по достоверности;

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

а также все другие количественные и качественные показатели, определяющие эффективность функционирования системы. Кроме того, в данном разделе указываются санитарные правила и нормы (СанПин 2.2.2./2.4.2198-07 [6]) и ГОСТы, требования которых необходимо учитывать при разработке такого класса систем, с учетом того, что системы разворачиваются на средствах вычислительной техники [7, 8].

Часть 3 – Календарный план выполнения работ. Технология RAD, как уже говорилось выше, требует жесткого следования плану-графику работ, поэтому в ТЗ оговариваются ключевые задания, по которым преподаватель должен проводить обязательный контроль. Каждый из перечисленных этапов должен завершаться полностью готовой документацией, согласованной с заказчиком (руководителем). Невыполнение в срок какого-либо из этапов может привести либо к сдвигу «контрольных точек» по оставшимся этапам, либо к незавершению проекта в срок.

В заключение хотелось бы отметить, что процесс составления ТЗ на систему:

1. требует от разработчиков коллективных обсуждений и принятия ответственных решений;

2. позволяет выявить наиболее «узкие» места проекта и оценить возможные риски;

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

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

ЛАБОРАТОРНАЯ РАБОТА № 2
описание и анализ предметной области

Как уже говорилось ранее, технология RAD включает в себя элементы методологии объектно-ориентированного проектирования и анализа предметной области. Для быстрой и эффективной разработки программной системы с минимальным браком требуется определить верное направление работы [9]. Для того чтобы правильно построить систему, сначала необходимо построить ее модель (этим вы будете заниматься позднее). Моделирование ‑ это устоявшаяся и повсеместно принятая инженерная методика. Хорошая модель всегда включает элементы, существенно влияющие на результат, и не включает те, которые малозначимы на данном уровне абстракции. Модели строятся для того, чтобы лучше понимать разрабатываемую систему. При этом нужно помнить об основных принципах моделирования, один из которых гласит: «Лучшие модели ‑ те, что ближе к реальности» [9]. Поэтому первое, с чего нужно начать разработку системы – это досконально изучить предметную область, в которой Вы будете работать.

В соответствии с методологией ООАП выделяются следующие шаги работы над проектом (системой).

1. Описание предметной области. Определение гласит: «Под предметной областью (application domain) принято понимать ту часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. Другими словами, предметная область включает в себя только те объекты и взаимосвязи между ними, которые необходимы для описания требований и условий решения некоторой задачи» [4]. Следовательно, разработчикам необходимо выделить основные объекты (компоненты), участвующие в функционировании системы, определить их наиболее существенные характеристики, взаимосвязи в рамках решаемой задачи, а также определить основные информационные потоки в системе. При этом отдельные компоненты выбираются таким образом, чтобы при последующей разработке их было удобно представить в форме классов и объектов. В этом случае немаловажное значение приобретает и сам язык представления информации о концептуальной схеме предметной области.

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

Комментарии к примеру. Для разрабатываемой системы в первую очередь необходимо дать определение кроссворда [10], привести краткую историю его создания, рассказать о разновидностях кроссвордов и особенностях их построения и разгадывания (привести в качестве иллюстраций «сетки» различных кроссвордов)[2], при этом подробно рассказать об особенностях линейного кроссворда, различных формах его построения (привести иллюстрации). Это особенно важно, т.к. в техническом задании было зафиксировано 4 различные формы представления ЛК (на рисунке 1 представлен один из вариантов представления чайнворда).

Рисунок 1 – Чайнворд, как разновидность линейного кроссворда

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

3. Результатом последнего этапа является диаграмма объектов предметной области и краткое описание их свойств и функций. При построении данной диаграммы^{^[3]} нужно помнить о том, что в данном случае объект – это «конкретная материализация абстракции», а не экземпляр класса, т.е. пока это понятие не программистское. Диаграмма объектов представляет статическую составляющую взаимодействующих между собой объектов, она должна включить в себя только те объекты предметной области, которые потом преобразуются в диаграмму классов. Связи между объектами показывают отношения между ними, при необходимости в диаграмме можно привести и атрибуты (свойства) объектов. На рисунке 2 приведен фрагмент диаграммы объектов для рассматриваемой в качестве примера системы.

Диаграммы объектов не позволяют полностью описать объектную структуру системы, поэтому при их использовании нужно сосредоточиться на изображении интересующих вас наборов конкретных объектов [9].

Комментарии к примеру. Как видно из диаграммы, ЛК представляет собой (как и любой кроссворд) совокупность двух составляющих: сетки, на которой будут располагаться слова, и задания, которое по существу представляет собой набор определений, которые разъясняют смысл слов (понятий). Набор понятий и определений хранятся во внешнем файле (чаще всего текстовом), который мы ранее называли словарем понятий (см. лабораторную работу №1).

Коротким пунктиром выделены те сущности, которые могут представлять собой единое целое, длинным – внутренние объекты системы.

ЛАБОРАТОРНАЯ РАБОТА № 3
Постановка задачи

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

Комментарии к примеру. Сначала необходимо сформулировать саму задачу, которая стоит перед разработчиками, обычно она включает в себя название проекта: «Перед авторами поставлена задача ‑ разработать автоматизированную систему составления и разгадывания линейного кроссворда по выбранной теме, которая позволит …». Далее последовательно описывается все процессы (виды автоматизируемой деятельности), в той последовательности, которая позволит получить требуемый результат. Для разрабатываемой системы таких процессов 3, каждый из них может функционировать независимо от других.

Далее по тексту: «Для достижения поставленной цели необходимо решить следующие задачи:

1. Составление кроссворда может проводиться в двух режимах: автоматическом (генерирование) и ручном. В любом случае пользователь должен предварительно задать параметры кроссворда[4]: определить его максимальную длину (не менее 15 и не более 255 символов), выбрать форму его представления (линейная, спиральная, …), определить количество букв в пересечении (от 1 до 3), подключить словарь понятий (он хранится во внешнем текстовом файле определенной структуры[5]). При этом система должна провести проверку правильности этой структуры и, в случае несоответствия, выдать предупредительное сообщение (см. лабораторную работу №5, описание исключительных ситуаций) и обеспечить повторный ввод параметров. В системе должен осуществляться контроль типов и диапазонов значений параметров. В режиме ручного составления кроссворда (или его редактирования) пользователю должны предоставляться следующие возможности: удаление слова (последнего), добавление нового слова (в конец), редактирование (замена) слова, если оно стоит в середине[6]. При этом должна быть обеспечена навигация по словам либо непосредственно на сетке кроссворда, либо с помощью специальных элементов управления[7]. В случае необходимости пользователь должен иметь возможность сохранить полученный кроссворд в файл (с целью дальнейшего его разгадывания или редактирования), структура файла должна быть определена в ходе проектирования⁵. Необходимо также предусмотреть контроль целостности создаваемого кроссворда (отсутствие пустых мест в середине кроссворда).

2. Разгадывание кроссворда…

3. Работа со словарями понятий…

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

Таким образом, система должна выполнять следующие функции[8]:

(здесь перечисляются все функции, которые были определены в разделе 2.5.1 ТЗ)».

ЛАБОРАТОРНАЯ РАБОТА № 4
разработка структуры системы

Построение структурной схемы программной системы. На данном этапе система по функциональному признаку разделяется на основные подсистемы, между ними указываются информационные связи и/или связи по управлению, описывается основное назначение подсистем. При разработке структурной схемы используется методология структурного проектирования, в основе которой лежит алгоритмическая декомпозиция и иерархия вида «часть-целое», учитывающая, что внутренние связи элементов внутри подсистем сильнее, чем связь между подсистемами. Декомпозиция системы может повторяться многократно, вплоть до уровня конкретных процедур, при этом должна быть обеспечена целостность системы, а все составляющие компоненты взаимоувязаны. Для этого используются такие принципы разработки, как «сверху-вниз», «разделяй и властвуй», «иерархическое упорядочивание» и другие [3].

Дадим некоторые определения.

В первом приближении можно придерживаться нормативного понятия системы. Система (греч. ‑ «составленное из частей», «соединение» от «соединяю») ‑ множество элементов, находящихся в отношениях и связях друг с другом, которое образует определённую целостность, единство [11][9].

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

− наличием множества элементов;

− наличием связей между ними;

− целостным характером данного устройства или процесса.

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

К типовым можно отнести следующие подсистемы:

1) подсистему управления;

2) подсистемы ввода-вывода:

a) подсистему настройки параметров;

b) файловую подсистему;

c) подсистему визуализации;

d) подсистему документирования;

e) подсистему взаимодействия с базой данных;

3) справочную подсистему.

⇐ Предыдущая 123 4 5 6 Следующая ⇒