Информационная система «Запись на университетские курсы»



Лабораторная работа №11

Составление документа описания требований к разрабатываемой информационной системе

 

 

Цель работы:научитьсясоставлять документ описания требований к разрабатываемой ИС согласно шаблону.

 

Теоретические сведения

Спецификация требований

Требования необходимо специфицировать (т. е. задать) графическиили каким-либо иным формальным способом. Всесторонняяспецификация системы может потребовать использования многих типовмоделей. Язык UML изобилует интегрированными методамимоделирования, способными помочь бизнес-аналитику справиться с этойзадачей. Спецификация – подобно процессу разработки ПО в целом – итеративный процесс с пошаговым наращиванием уровня детализациимоделей. Немаловажную роль в успешном моделировании играетиспользование CASE-средств.

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

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

Принципы спецификации требований

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

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

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

Постепенно для целей проектирования и реализации документспецификации требований заменяет документ описания требований (напрактике расширенный документ может по-прежнему называтьсядокументом описания требований).

Модели спецификаций можно разделить на три группы:

1. Модели состояний.

2. Модели поведения.

3. Модели изменения состояний.

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

Модели представляются в виде диаграмм на языке визуальногомоделирования (VisualModelingLanguage) – в данном случае это языкUML. Обычно диаграмма служит целям моделирования одной из сторонсистемы – состояний, поведения или изменения состояний. Заметноеисключение составляет диаграмма классов, которая определяет все триаспекта – состояние и поведение объектов, и, косвенно, изменениясостояний объектов.

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

Аналогично случаю интерпретации завершенных моделейконструирование диаграмм – это не последовательный процесспостроения одной диаграммы за другой.

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

С каждой новой итерацией разработки глубина и степеньдетализации спецификации возрастает. Многие более глубокие свойстваобъектов модели выражаются скорее в текстовом, нежели графическомвиде. Некоторые свойства определяют замысел объекта модели, а нерезультат анализа. Некоторые другие свойства могут отражатьособенности CASE-средств.

Спецификации состояний

Состояние объекта определяется значениями его атрибутов иассоциаций. Например, объект BankAccount (Банковский счет) можетнаходиться в состоянии «превышение кредитного лимита», если значениеатрибута balance (баланс) отрицательно. Поскольку состояния объектаопределяются структурам данных, модели структур данных называютсяспецификациями состояний. Спецификация состояний дает статическийвзгляд на систему (поэтому моделирование состояний часто называютстатическим моделированием). Здесь основной задачей являетсяопределение классов проблемной области, их атрибутов и отношений сдругими классами. Вначале операции классов обычно нерассматриваются. Они выводятся из моделей спецификации поведения.

В типичной ситуации сначала определяются классы-сущности, т.е.классы, которые определяют проблемную область и характеризуютсяпостоянным присутствием в базе данных системы. Подобные классыиногда называются «бизнес-классами». Классы, которые обслуживаютсистемные события (управляющие классы) и классы, которыепредставляют GUI-интерфейс (классы представления или пограничныеклассы), не устанавливаются до тех пор, пока не станут известныповеденческие характеристики системы.

Информационная система «Запись на университетские курсы»

В качестве примера для спецификации требований выбранаинформационная система «Запись на университетские курсы».

Постановка задачи.

Средний по размерам университет проводит набор студентов иаспирантов дневной и вечерней форм обучения для подготовки по рядуспециальностей. Учебная структура университета состоит из факультетов.

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

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

Гибкость выбора учебных курсов оказывает дополнительную нагрузку науниверситетскую систему набора. Индивидуально подобранным программамобучения должны быть противопоставлены правила, регулирующие получениестепени по выбранной специальности. Такие правила можно сформулировать,например, в виде структуры дисциплин, изучение которых являетсяобязательной предпосылкой получения диплома, так, чтобы студент могпрослушать обязательные для данной специальности курсы. Выборстудентами дисциплин может быть ограничен несоответствием расписаний,максимальной вместимостью аудиторий и т.д.Гибкость в получении образования, предлагаемого университетом,стала одной из причин роста количества студентов. Однако для сохранениясвоих традиционно сильных сторон система набора – по-прежнему, частичноручная – должна быть заменена новым программным решением.Предварительно поиск готовых программных пакетов не дал результатов.Университетская система набора достаточно уникальна, чтобы оправдатьразработку ПО собственными силами.

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

Выявление классов

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

1. Подход на основе использования именных групп.

2. Подход на основе использования общих шаблонов для классов.

3. Подход на основе использования прецедентов.

4. Подход CRC (class–responsibility–collaborators – класс –обязанности – «сотрудники»).


Дата добавления: 2018-04-05; просмотров: 323; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!