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

Составитель: доц., к. т. н. Зеленко Л.С.

УДК 004.4 (075)

Принципы разработки учебных программ:Методические указания к лабораторному практикуму по дисциплине «Программная инженерия»/ Л. С. Зеленко. – Самара: Изд-во Самар. гос. аэрокосм. ун-та, 2014. ‑ 64 с.

Методические указания предназначены для студентов, обучающихся по направлению 010300.62 ‑ «Фундаментальные информатика и информационные технологии», которые выполняют лабораторный практикум по дисциплине «Программная инженерия». Методические указания включают в себя рекомендации по основным этапам выполнения работ при разработке учебных программных систем, приводятся примеры оформления документации. В них учтены требования действующих государственных стандартов и нормативных материалов министерства образования и науки Российской Федерации, а также рекомендации, изложенные в международных стандартах по разработке программного обеспечения.

Указания выполнены на кафедре программных систем.

Печатаются по решению редакционно-издательского совета Самарского государственного аэрокосмического университета им. академика С. П. Королева.

Рецензент ‑ канд. техн. наук, доцент Симонова Е.В.


СОДЕРЖАНИЕ

Технология быстрой разработки приложений RAD.. 4

Лабораторная работа №1 разработка технического задания на программную систему. 7

Лабораторная работа № 2 описание и анализ предметной области. 14

Лабораторная работа № 3 Постановка задачи. 17

Лабораторная работа № 4 Разработка структуры системы.. 19

Лабораторная работа № 5 Разработка спецификации требований. 22

Лабораторная работа № 6 Разработка прототипа интерфейса пользователя системы.. 27

Лабораторная работа № 7 Разработка информационно-логического проекта системы.. 31

Лабораторная работа № 8 Разработка алгоритмов обработки данных. 44

Оформление отчета. 46

Список использованных источников. 49

Приложение А Пример оформления технического задания на разработку ПС.. 51

Приложение Б Пример оформления приложения к техническому заданию.. 55

Приложение В Структура содержания отчета. 59

Приложение Г Пример оформления титульного листа. 61

Приложение Д Пример оформления реферата. 63

 

 


Технология быстрой разработки приложений RAD

Один из подходов к разработке программного обеспечения (ПО) в рамках спиральной модели жизненного цикла (ЖЦ) – получившая широкое распространение методология (технология) быстрой разработки приложений RAD (Rapid Application Development – быстрая разработка приложений) [1, 2]. Данная модель очень хорошо подходит к разработке учебных программ, т.к. включает в себя три составляющие:

− небольшую команду программистов (от 2 до 4 человек);

− короткий, но тщательно проработанный производственный график (от 2 до 4 мес.);

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

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

ЖЦ ПО [1] по технологии RAD состоит из четырёх фаз(рисунок 1):

1. Анализа и планирования требований;

2. Проектирования;

3. Построения;

4. Внедрения.

 
 

 


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

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

Результатом фазы должны быть: список расставленных по приоритету функций будущей ПС; предварительная функциональная модель ПС; предварительная информационная модель ПС.

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

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

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

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

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.

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

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

В заключение перечислим основные принципы технологии RAD:

− разработка приложений итерациями;

− необязательность полного завершения работ на каждом этапе ЖЦ;

− обязательное вовлечение пользователей на этапе разработки;

− тестирование и развитие проекта одновременно с разработкой;

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

ЛАБОРАТОРНАЯ РАБОТА №1
разработка технического задания на программную систему

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

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

Техническое задание разрабатывается в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» [2] и в дальнейшем должно стать основным документом, по которому студенты ведут разработку проекта. Любые изменения ТЗ на систему должны быть согласованы с преподавателем и заверены его подписью.

Техническое задание состоит из трех частей:

1) содержание задания;

2) исходные данные;

3) календарный план выполнения работ.

Часть 1 – «Содержание задания». Данная часть ТЗ фиксирована, в ней перечислены основные составные этапы выполнения проекта. При разработке ПС в рамках лабораторного практикума и в дальнейшем при выполнении курсового проекта будут использоваться две основные методологии: объектно-ориентированного анализа и проектирования (ООАП) и методология структурного проектирования [3].

ООАП (Object-Oriented Analysis/Design) ‑ технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов [4]. Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE) и языком моделирования UML (Unified Modeling Language).

Методология объектно-ориентированного анализа и проектирования используется при выполнении лабораторной работы №2 – описании и анализе предметной области, где студенты должны выявить взаимосвязи между основными информационными объектами ПС, определить их характеристики и порядок взаимодействия.

Методология структурного проектирования применяется на первой фазе проектирования (лабораторная работа №3) при разделении системы на подсистемы, здесь используется принцип проектирования «сверху вниз». За каждым студентом закрепляется определенный перечень работ (обычно это разработка отдельной подсистемы), выполнение которых в дальнейшем контролирует преподаватель.

Часть 2 – «Исходные данные к проекту» включает в себя следующие подразделы:

1. Характеристики объекта автоматизации (или управления);

2. Требования к информационному обеспечению.

3. Требования к техническому обеспечению.

4. Требования к программному обеспечению.

5. Общие требования к проектируемой системе.

6. Перечень дополнительных работ (если необходимо).

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

a) полное название объекта (ов);

b) условия его функционирования;

c) количественные и качественные показатели объекта, которые являются ограничениями процесса функционирования.

В качестве примера рассмотрим проект «Автоматизированная система составления и разгадывания линейного кроссворда по выбранной теме», ТЗ на который приведено в приложении Б.

Понятие «объект автоматизации» в явном виде в ГОСТ 34.602-89 [2] нигде не определено, но если внимательно прочитать п. 2.4.1. «В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать»[1], то из него следует, что под «объектами автоматизации» авторы понимали вовсе не процессы. Будем считать, что объектом автоматизации может быть только материальный (интеллектуальный) объект ‑ организация, магазин, цех, отдел, и так далее.

Комментарии к примеру. Из названия темы следует, что в данном случае объект автоматизации – это линейный кроссворд, а виды автоматизируемой деятельности – это процессы:

1) составления/ генерирования кроссворда;

2) разгадывания кроссворда;

3) работы со словарем понятий.

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

Для каждого процесса в ТЗ должны быть указаны количественные показатели-ограничения, для того, чтобы их правильно выбрать, необходимо знать начальные сведения о структуре самого объекта, каким образом будет проходить его построение и разгадывание. Отправной точкой является определение линейного кроссворда (ЛК). Итак, ЛК – это «цепочка слов, которая строится методом стыкования, где последняя буква первого слова является первой буквой второго и т. д. В чайнворде, как и в кроссворде, используются только имена существительные в именительном падеже и единственном числе» [5]. Так как ЛК строится из слов, то необходимо указать ограничение на длину слова: минимальную длину слова можно определить равную 3, а максимальную – 15, потому что чаще всего кроссворды будут составляться на бытовые темы и сам ЛК не должен быть очень простым. Чтобы ЛК было интересно разгадывать, он не должен быть очень коротким, поэтому минимальное количество слов, например, 5, а максимальное – 15. Идем дальше: «слова в чайнворде не пересекаются, а только стыкуются друг с другом. Иногда цепочку слов изгибают для придания сетке причудливой формы. Длинная изогнутая цепочка может неоднократно пересекать саму себя, как слова в кроссворде, такая головоломка обычно называется кроссчайнвордом». Исходя из этого, можно задать следующее ограничение – на форму отображения ЛК: обычная (линейная), спираль, змейка, W-образная. «В линейных кроссвордах слова могут перекрываться не только одной, но и двумя или тремя буквами, поэтому их длина указывается в скобках при определении к слову» [5], эта часть описания ЛК дает еще одно ограничение: количество букв в пересечении ‑ от 1 до 3. В качестве пожелания, заказчик отметил, что ЛК необходимо строить в двух режимах: ручном и автоматическом (генерация кроссворда), из этого следует еще одно ограничение – составление кроссворда осуществляется с привязкой к словарю понятий. Для того чтобы системы была более универсальной (необходимо обеспечить создание тематических кроссвордов или на общие области знаний), заказчик предложил загружать в систему внешние словари понятий и обеспечить ему возможность редактировать их содержимое. При разгадывании кроссворда могут возникнуть затруднения, поэтому (в соответствии с пожеланиями заказчика) в системе должна быть организована система подсказок, количество которых можно связать с количеством слов – не менее 1 и не более 10% от количества слов.

Требования к информационному обеспечению. Разработка информационного обеспечения (ИО) – наиболее важная часть проекта, она может оказать существенное влияние на весь процесс разработки, поэтому уже на стадии разработки ТЗ необходимо определить:

1) на основании каких документов разрабатывается методическое и информационное обеспечение системы (нормативные и другие документы);

2) перечень исходных данных:

a) какие массивы данных используются и в каких форматах;

b) на каких носителях эти данные будут поставляться в систему;

3) перечень выходных данных:

a) какие массивы данных будут являться результатом работы ПС;

b) какие документы будут представлены пользователю и в каком виде (указывается вид носителя) и с какой периодичностью;

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

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

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

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

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

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

Комментарии к примеру. Функции, которые должна выполнять данная система, определяются в первую очередь видами автоматизируемой деятельности, которые были определены в п.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]. В случае необходимости пользователь должен иметь возможность сохранить полученный кроссворд в файл (с целью дальнейшего его разгадывания или редактирования), структура файла должна быть определена в ходе проектирования5. Необходимо также предусмотреть контроль целостности создаваемого кроссворда (отсутствие пустых мест в середине кроссворда).

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

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

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

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

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

 


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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