Завьялов А. В.. Анализ и проектирование информационных систем

УДК 004.415.2

ББК 32.972 З 13

Завьялов А. В. Анализ и проектирование информационных систем [Электронный ресурс]: Методические указания / Завьялов А. В. — М.: МИРЭА — Российский технологический университет, 2020. — 1 электрон. опт. диск (CD-ROM)

Методические указания по выполнению практических, лабораторных и курсовых работ по дисциплине «Анализ и проектирование информационных систем» для обучающихся РТУ МИРЭА по направлению подготовки бакалавров 01.03.02 «Прикладная математика и информатика» с профилем подготовки «Системное программирование и компьютерные технологии».

Методические указания издаются в авторской редакции.

Авторский коллектив: Завьялов Антон Владимирович, к.т.н.

Рецензент:

Крыжановский Юрий Маркович, к.т.н., профессор базовой кафедры РТУ МИРЭА при АО «Концерн «Вега»

Системные требования:

Наличие операционной системы Windows, поддерживаемой производителем. Наличие свободного места в оперативной памяти не менее 128 Мб.

Наличие свободного места в памяти постоянного хранения (на жестком диске) не менее 30 Мб. Наличие интерфейса ввода информации.

Дополнительные программные средства: программа для чтения pdf-файлов (Adobe Reader). Подписано к использованию по решению Редакционно-издательского совета МИРЭА — Российский технологический университет.

Обьем: 0.829 мб Тираж: 10

© Завьялов А. В., 2020 © МИРЭА – Российский технологический университет, 2020

3

Введение

Дисциплина «Анализ и проектирование информационных систем» преподается на 3-м курсе бакалавриата по направлению 01.03.02 «Прикладная математика и информатика» и является частью цикла дисциплин, посвященных разработке программного обеспечения. Перед данной дисциплиной студенты проходят курс «Системного анализа программного обеспечения» и получают необходимые знания, умения и практические навыки сбора и формализации требований к программным продуктам и информационным системам. В данном курсе изучается дальнейшие процессы разработки, связанные с проработкой требований, выявлением среди них архитектурных мотивов, генерации и выбора вариантов архитектуры и детального проектирования программного обеспечения, функционирующего в составе более масштабных информационных систем. Полученные знания в совокупности с полученным ранее опытом программирования и изучением технологии создания программных продуктов формируют основные компетенции, связанные с технической стороной разработки программ. Следующей ступенью в данном цикле является дисциплина «Управление разработкой программного обеспечения», дополняющая знания студентов организационными аспектами разработки программных проектов.

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

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

4

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

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

1. Требования к практическим и лабораторным работам

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

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

Далее приведены описания практических и лабораторных работ, примеры тем и требования к их выполнению.

1.1. Лабораторная/практическая работа №1

Задание – разработка краткого перечня требований к программному средству в соответствии с выбранной темой.

Цель работы – закрепление навыков формализации требований.

В качестве исходных данных могут использоваться:

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

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

–данные экспертов и участников разработки программного средства (например, руководителей производственной практики или сотрудников по

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

5

–личный опыт и идеи студента;

–установки преподавателя;

–научно-техническая литература, техническая или нормативная документация.

Требования формулируются в виде краткого пронумерованного перечня (1-2 страницы текста формата А4) и должны включать (если применимо):

–функциональные требования;

–нефункциональные требования, в том числе требования к готовности, модифицируемости, производительности, безопасности, практичности, контролепригодности и другим параметрам качества программы;

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

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

–понятность;

–корректность;

–недвусмысленность;

–полнота;

–непротиворечивость;

–проверяемость;

–модифицируемость;

–упорядоченность по важности и стабильности;

–трассируемость.

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

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

6

и/или диаграммой прецедентов (с детализацией до уровня прецедентов цели пользователя).

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

Перечень требований может быть выполнен одним из следующих способов:

–простое описание в текстовом редакторе, например: MS Word, Open Office, Libre Office;

–база данных требований в одном из специализированных редакторов

свозможностью экспорта в виде документа с нумерованным перечнем требований. Например, могут использоваться такие средства, как onlineили desktop-версия редактора ReqView, Sparx Enterprise Architect, IBM Rational Requisite Pro, Jira Software SynapseRT.

1.2. Лабораторная/практическая работа №2

Задание – выбор и формулировка архитектурных мотивов для программного средства в соответствии с выбранной темой.

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

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

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

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

7

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

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

–простое описание в текстовом редакторе, например: MS Word, Open Office, Libre Office;

–база данных в одном из специализированных редакторов с возможностью экспорта в виде документа с нумерованным перечнем архитектурных мотивов. Например, могут использоваться такие средства, как onlineили desktop-версия редактора ReqView, Sparx Enterprise Architect, IBM Rational Requisite Pro, Jira Software SynapseRT.

1.3.Лабораторная/практическая работа №3

Задание – выбор, обоснование и применение шаблона программной архитектуры.

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

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

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

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

8

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

Итоговая диаграмма должна быть выполнена одним из следующих способов:

–в произвольном векторном или растровом графическом редакторе с соблюдением нотации UML. Например, можно использовать редакторы: Xara Designer, Inkscape, MS Paint, Adobe Photoshop;

–в специальном редакторе UML-диаграмм с соблюдением ограничений и правил UML, реализованных в данном редакторе. Например,

можно использовать Sparx Enterprise Architect, Visual Paradigm, MS Visio;

–с использованием общедоступных online-сервисов для рисования диаграмм UML, например: creately.com, draw.io.

1.4.Лабораторная/практическая работа №4

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

Цель работы – закрепление навыков применения шаблонов архитектуры и составления диаграмм взаимодействия на языке моделирования UML.

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

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

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

9

взаимодействия в зависимости от количества взаимодействующих объектов, количества и сложности взаимодействий:

–диаграмма последовательности (sequence diagram);

–коммуникационная диаграмма (communication diagram);

–диаграмма деятельности (activity diagram).

В большинстве случаев предпочтительным является выбор диаграммы последовательности.

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

Правила составления диаграмм определяются нотацией UML.

Диаграммы должны быть выполнены одним из следующих способов:

–в произвольном векторном или растровом графическом редакторе с соблюдением нотации UML. Например, можно использовать редакторы: Xara Designer, Inkscape, MS Paint, Adobe Photoshop;

–в специальном редакторе UML-диаграмм с соблюдением ограничений и правил UML, реализованных в данном редакторе. Например,

можно использовать Sparx Enterprise Architect, Visual Paradigm, MS Visio;

–с использованием общедоступных online-сервисов для рисования диаграмм UML, например: creately.com, draw.io.

2.Требования к порядку выполнения курсовой работы

Преподаватель (руководитель курсовой работы):

–устанавливает требования к содержанию и объему курсовой работы на основе методических указаний по курсовому проектированию и доводит их до сведения студентов при выдаче заданий на курсовое проектирование;

–определяет основные направления деятельности студентов по выполнению работы в соответствии с заданием.

Общий объем курсовой работы, как правило, не должен быть менее 15 или более 70 страниц.

10