Особо должны быть выделены файл-серверные и клиент-серверные части информационного обеспечения, если таковые имеются.
Редактор Нижник Н. С. Верстка Нижник Н. С.
Подписано в печать _________ Формат 60х84 1/16 Печать цифровая. Объем ______ п.л. Тираж ___ экз. Заказ № ______ Отпечатано в Санкт-Петербургском университете МВД России 198206, Санкт-Петербург, ул. Летчика Пилютова, д. 1 [*] Содержание курсовой работы выполняется в автоматическом режиме. [†] Раздел курсовой работы «Источники и использованная литература» должен содержать перечень источников и той литературы, которые реально были использованы автором курсовой работы. Список должен быть грамотно оформлен и содержать не менее 20 различных источников и научных произведений. В приведенном списке-образце приведены примеры оформления различных видов изданий. Нумерация списка источников и использованной литературы должна быть сквозной. [3] Галлиев Ф. Х. Историческая обусловленность правовой культуры // История государства и права. 2010. № 19. С. 16. [4] Хропанюк В. Н. Теория государства и права: Учебник для бакалавров. М., 2013. С.132. [5] Бахта В. М. Проблема аккультурации в современной этнографической литературе США // Современная американская этнография. М., 1963. С. 164–165. [6] См: Redfild R., Linton Я., Herskovits М. Memorandum for the study of acculturation // American Anthropologist. 1936. V. 38. P. 149–152; Herskovits М. J. Acculturation. Tlie study of culture contact. New York, 1938. Р. 34. [7] Популярный юридический энциклопедический словарь / Редкол.: О. Е. Кута-фин, В. А. Туманов, И. В. Шмаров. М., 2000. С. 342. [8] Нижник Н. С. Правовые системы современности // Теория государства и права: Учебное пособие. Ч. 3 / Ред. А. В. Кузьмин. СПб.: Изд-во СПб ун-та МВД России, 2012. С. 64. [9] Карчевская Н. И., Семенова О. В. Теоретико-правовые закономерности гражданского общества. СПб., 2010. С. 26. [10] Матузов Н. И., Малько А. В. Теория государства и права. М., 2014. С. 146. [11] Нижник Н. С. Правовые системы современности. С. 67. [12] Абрамов А. Е. Правовая аккультурация (на примере Испании в период Римской республики): Автореф. дис... канд. юрид. наук. Владимир, 2005. С. 8. [13] См.: Галлиев Ф. Х. Историческая обусловленность правовой культуры. С. 18; Матузов Н. И., Малько А. В. Теория государства и права. С. 149. [14] Абрамов А. Е. Правовая аккультурация (на примере Испании в период Римской республики): Автореф. дис... канд. юрид. наук. С. 12. [15] Закон Российской Федерации от 25 июня 1993 года № 5242-I (ред. 18 июля 2006 года) «О праве граждан Российской Федерации на свободу передвижения, выбор места жительства в пределах Российской Федерации» // Российская газета. 1993. 10 августа; 2004. 5 ноября; 2006. 27 июля. [16] Федеральный закон РФ от 14 июня 1994 года № 5-ФЗ «О порядке опубликования и вступления в силу федеральный конституционных законов, федеральных законов, актов палат Федерального Собрания» (ред. от 25 декабря 2012 года) // СЗ РФ. 1994. № 8. Ст. 801; 2012. № 53. Ч. 1. Ст. 7579; Указ Президента РФ от 23 мая 1996 года № 763 «О порядке опубликования и вступления в силу актов Президента РФ, Правительства РФ и нормативных правовых актов федеральных органов исполнительной власти» (ред. от 2 февраля 2013 года) // СЗ РФ. 1996. № 22. Ст. 2663; 2013. № 6. Ст. 493. Составитель: доц., к. т. н. Зеленко Л.С. УДК 004.4 (075) Принципы разработки учебных программ:Методические указания к лабораторному практикуму по дисциплине «Программная инженерия»/ Л. С. Зеленко. – Самара: Изд-во Самар. гос. аэрокосм. ун-та, 2012. ‑ 64 с. Методические указания предназначены для студентов, обучающихся по направлению 010300.62 ‑ «Фундаментальные информатика и информационные технологии», которые выполняют лабораторный практикум по дисциплине «Программная инженерия». Методические указания включают в себя рекомендации по основным этапам выполнения работ при разработке учебных программных систем, приводятся примеры оформления документации. В них учтены требования действующих государственных стандартов и нормативных материалов министерства образования и науки Российской Федерации, а также рекомендации, изложенные в международных стандартах по разработке программного обеспечения. Указания выполнены на кафедре программных систем. Печатаются по решению редакционно-издательского совета Самарского государственного аэрокосмического университета им. академика С. П. Королева. Рецензент ‑ канд. техн. наук, доцент Симонова Е.В. СОДЕРЖАНИЕ Технология быстрой разработки приложений RAD.. 4 Лабораторная работа №1 Разработка технического задания на программную систему. 7 Лабораторная работа № 2 Описание и анализ предметной области. 13 Лабораторная работа № 3 Постановка задачи. 16 Лабораторная работа № 4 Разработка структуры системы.. 18 Лабораторная работа № 5 Разработка спецификации требований. 21 Лабораторная работа № 6 Разработка прототипа интерфейса пользователя системы.. 26 Лабораторная работа № 7 Разработка информационно-логического проекта системы.. 30 Лабораторная работа № 8 Разработка алгоритмов обработки данных. 42 Оформление отчета. 44 Список использованных источников. 47 Приложение А Пример оформления технического задания на разработку ПС.. 49 Приложение Б Структура содержания отчета. 54 Приложение В Пример оформления титульного листа. 56 Приложение Г Пример оформления реферата. 58
Технология быстрой разработки приложений 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 представлен один из вариантов представления чайнворда).
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) справочную подсистему.
|
