Пример спецификации требований к программному обеспечению

В данном подразделе рассматривается спецификация требо­ваний к системе регистрации для учебного заведения, бизнес-мо­дель которого описана в подразд. 3.3.2.

Уточненная постановка задачи для системы

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

Из-за недостатка средств университет не в состоянии заме­нить всю существующую систему. Остается функционировать в прежнем виде база данных, содержащая всю информацию о кур­сах (каталог курсов). Эта база данных поддерживается реляцион­ной СУБД. Новая система будет работать с существующей БД в режиме доступа, без обновления.

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

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

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

Глоссарий проекта

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

Описание дополнительных спецификаций

Функциональные возможности:

1. Система должна обеспечивать многопользовательский ре­жим работы.

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

Удобство использования:

1. Пользовательский интерфейс должен быть Windows-сов­местимым.

Надежность.

2. Система должна быть в работоспособном состоянии 24 часа в день 7 дней в неделю, время простоя — не более 10%.

Производительность.

3. Система должна поддерживать до 2000 одновременно рабо­тающих с центральной базой данных пользователей и до 500 пользователей, одновременно работающих с локальными серверами.

Безопасность.

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

5. Только профессора имеют право ставить студентам оценки.

6. Только регистратор может изменять любую информацию о студентах.

Проектные ограничения.

1. Система должна быть интегрирована с существующей сис­- темой каталога курсов, функционирующей на основе реля­- ционной СУБД.

Создание начальной версии модели вариантов использования

Действующие лица:

2. Регистратор — формирует учебный план и каталог курсов, записывает студентов на курсы, ведет все данные о курсах, профессорах, успеваемости и студентах.

3. Расчетная система — получает от данной системы информа­цию по оплате за курсы.

4. Каталог курсов — база данных, содержащая информацию о курсах.

Варианты использования.

Исходя из потребностей действующих лиц, выделяются сле­дующие варианты использования:

1. Войти в систему;

2. Зарегистрировать студента на курсы;

3. Вывести табель успеваемости;

4. Назначить курсы для преподавания;

5. Проставить оценки;

6. Вести информацию о профессорах;

7. Вести информацию о студентах;

8. Закрыть регистрацию.

Начальная версия диаграммы вариантов использования по­казана на рис. 3.19.

Рис. 3.19. Начальная версия диаграммы вариантов использования

Модификация модели вариантов использования

Согласно постановке задачи в состав пользователей системы следует ввести студентов и профессоров. При этом в описание действующих лиц и вариантов использования вносятся измене­ния. Модифицированная версия диаграммы вариантов использования показана на рис. 3.20.

Рис. 3.20. Модифицированная диаграмма вариантов использования для системы регистрации

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

Действующие лица:

1. Студент — записывается на курсы и просматривает табель успеваемости.

2. Профессор - выбирает курсы для преподавания и ставит оценки.

3. Регистратор — формирует учебный план и каталог курсов, ведет все данные о курсах, профессорах и студентах.

4. Расчетная система — получает отданной системы информа­цию об оплате за курсы.

5. Каталог курсов — база данных, содержащая информацию о курсах.

Варианты использования:

1. Войти в систему;

2. Зарегистрироваться на курсы;

3. Просмотреть табель успеваемости; ,

4. Выбрать курсы для преподавания;

5. Проставить оценки;

6. Вести информацию о профессорах;

7. Вести информацию о студентах;

8. Закрыть регистрацию.

Примеры спецификаций вариантов использования

Вариант использования «Войти в систему».

Краткое описание.

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

Основной поток событий.

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

1. Система запрашивает имя пользователя и пароль.

2. Пользователь вводит имя и пароль.

3. Система подтверждает имя и пароль, после чего открывает­ся доступ в систему.

Альтернативные потоки.

Неправильное имя/пароль.

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

Предусловия.

Отсутствуют.

Постусловия.

Если вариант использования выполнен успешно, пользова­тель входит в систему. В противном случае состояние системы не изменяется.

Вариант использования «Зарегистрироваться на курсы»:

Краткое описание.

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

Основной поток событий.

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

1. Система запрашивает требуемое действие (создать график, обновить график, удалить график).

2. Когда студент указывает действие, выполняется один из подчиненных потоков (создать, обновить, удалить или принять график).

Создать график.

1. Система выполняет поиск в каталоге доступных предлагае­мых курсов и выводит их список.

2. Студент выбирает из списка 4 основных курса и 2 альтерна­тивных курса.

3. После выбора система создает график студента.

4. Выполняется подчиненный поток «Принять график».

Обновить график.

1. Система выводит текущий график студента.

2. Система выполняет поиск в каталоге доступных предлагае­мых курсов и выводит их список.

3. Студент может обновить свой выбор курсов, удаляя или до­бавляя предлагаемые курсы.

4. После выбора система обновляет график.

5. Выполняется подчиненный поток «Принять график».

Удалить график.

1. Система выводит текущий график студента.

2. Система запрашивает у студента подтверждения удаления графика.

3. Студент подтверждает удаление.

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

Принять график.

Для каждого выбранного, но еще не «зафиксированного» предлагаемого курса в графике система проверяет выполнение студентом предварительных требований (прохождение опреде­ленных курсов), факт открытия предлагаемого курса и отсутствие конфликтов графика. Затем система добавляет студента в список выбранного предлагаемого курса. Курс фиксируется в графике и график сохраняется в системе.

Альтернативные потоки.

Сохранить график.

В любой момент студент может вместо принятия графика сох­ранить его. В этом случае шаг «Принять график» заменяется на следующий:

1. «Незафиксированные» предлагаемые курсы помечаются в графике как «выбранные».

2. График сохраняется в системе.

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

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

График не найден.

Если во время выполнения подчиненных потоков «Обновить график» или «Удалить график» система не может найти график студента, то выдается сообщение об ошибке. После того, как студент подтвердит это сообщение, основной поток начнется с начала.

Система каталога курсов недоступна.

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

Регистрация на курсы закончена.

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

Удаление отменено.

Если во время выполнения подчиненного потока «Удалить график» студент решит не удалять его, удаление отменяется, и ос­новной поток начнется с начала.

Предусловия.

Перед началом выполнения данного варианта использования студент должен войти в систему.

Постусловия.

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

Вариант использования «Закрыть регистрацию».

Краткое описание.

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

Основной поток событий.

Данный вариант использования начинает выполняться, когда регистратор запрашивает прекращение регистрации.

1. Система проверяет состояние процесса регистрации. Если регистрация еще выполняется, выдается сообщение и вариант использования завершается.

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

3. Для каждого студенческого графика проверяется наличие в нем максимального количества основных курсов; если их недос­таточно, система пытается дополнить альтернативными курсами из списка данного графика. Выбирается первый доступный аль­тернативный курс. Если таких курсов нет, то никакое дополнение не происходит.

4. Система закрывает все предлагаемые курсы. Если в каком-либо предлагаемом курсе оказывается менее трех студентов (с учетом добавлений, сделанных в п.З), система отменяет его и исключает из каждого содержащего его графика.

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

Альтернативные потоки.

Предлагаемый курс никто не ведет.

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

Расчетная система недоступна.

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

Предусловия. ,

Перед началом выполнения данного варианта использования регистратор должен войти в систему.

Постусловия.

Если вариант использования завершится успешно, регистра­ция закрывается. В противном случае состояние системы не из­менится.

! Следует запомнить.

1. Моделирование бизнес-процессов является важной сос­тавной частью проектов по созданию крупномасштабных систем ПО. Отсутствие таких моделей является одной из главных причин неудач многих проектов.

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

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

4. Для выявления требований используются (в различных со­четаниях) следующие методы:

1. собеседование (интервьюирование);

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

3. моделирование и анализ бизнес-процессов;

4. сессии по выявлению требований (мозговой штурм);

5. создание и демонстрация пользователям работающих про­тотипов приложений (для выявления замечаний и дополни­тельных требований).

Основные понятия

Бизнес-процесс, бизнес-модель, бизнес-правила, действую­щее лицо бизнес-процессов, вариант использования с точки зре­ния бизнес-процессов, бизнес-объект.

? Вопросы для самоконтроля

1. Что такое бизнес-процесс и бизнес-модель?

2. Что дает построение бизнес-моделей и какие проблемы с ним связаны?

3. Охарактеризуйте достоинства и область применения мето­дики моделирования Rational Unified Process.

4. Какие проблемы могут возникнуть при спецификации тре­бований в случае отсутствия бизнес-моделей?

ГЛАВА 4.

АНАЛИЗ И ПРОЕКТИРОВАНИЕ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту главу, вы узнаете:

1. Что представляет собой анализ и проектирование ПО.

2. В чем заключается структурный подход к анализу и проектиро­ванию ПО.

3. В чем заключается объектно-ориентированный подход к анализу и проектированию ПО.

4.1.

СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ ПО

В данном подразделе рассматривается вторая часть методики Йордона (см. подразд. 3.2.2), связанная с переходом от бизнес-модели к модели системы. Пример применения данной методи­ки приведен в подразд. 4.2.

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

1. модель системных процессов;

2. архитектура системы;

3. модели данных приложений;

4. модель пользовательского интерфейса.

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

Например, для DFD переход от модели бизнес-процессов к модели системных процессов может происходить следующим об­разом:

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

2. для каждого потока данных определяется, посредством ка­ких технических устройств информация передается или производится;

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

4. определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть);

5. определяются задачи для каждого процессора (приложения, необходимые для работы системы), для них строятся соот­ветствующие диаграммы. Определяется тип связи между за­дачами;

6. устанавливаются ссылки между задачами и процессами ди­аграмм потоков данных следующих уровней.

Иерархия экранных форм Моделируется с помощью диаграмм последовательностей экранных форм. Совокупность таких диаг­рамм представляет собой абстрактную модель пользовательского интерфейса системы, отражающую последовательность появления экранных форм в приложении. Построение диаграмм последова­тельностей экранных форм выполняется следующим образом:

1. на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользова­тельском интерфейсе, поэтому можно определить экранную форму для каждого такого процесса;

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

3. определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же, как в модели процессов, либо другим способом — по функциональным признакам или в зависимости от принадлежности к опреде­ленным объектам);

4. формы с меню изображаются над формами, соответствую­щими интерактивным процессам, и соединяются с ними пе­реходами в виде стрелок, направленных от меню к формам.

5. определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

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

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

Для формирования схемы базы данных из ERM применяется ограниченный набор правил преобразования сущностей и связей между ними.

Правила преобразования сущностей:

Правило 1. Каждая простая сущность, не являющаяся подти­пом и не имеющая подтипов, превращается в таблицу. Имя сущ­ности становится именем таблицы.

Правило 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столб­цы, соответствующие необязательным атрибутам, могут содер­жать неопределенные значения; столбцы, соответствующие обя­зательным атрибутам, — не могут.

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

Правила преобразования связей:

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

Правило 2. Если тип бинарной связи — один-к-одному и класс принадлежности одной сущности является обязательным, а дру­гой — необязательным, то формируются две таблицы (под каж­дую сущность), при этом идентификатор каждой сущности дол­жен служить первичным ключом соответствующей таблицы. Кроме того, идентификатор сущности, для которой класс при­надлежности является необязательным, добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности.

Правило 3. Если тип бинарной связи - один-к-одному и класс принадлежности ни одной сущности не является обязательным, то формируются три таблицы: по одной для каждой сущности (при этом идентификатор каждой сущности должен служить пер­вичным ключом соответствующей таблицы) и одна для связи. Таблица связи включает в качестве атрибутов по одному иденти­фикатору от каждой сущности.

Правило 4. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является обязатель­ным, то формируются две таблицы (под каждую сущность), при этом идентификатор каждой сущности должен служить первич­ным ключом соответствующей таблицы. Кроме того, идентифи­катор сущности с мощностью «1» добавляется в качестве атрибу­та в таблицу, выделенную для сущности с мощностью «n».

Правило 5. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является необяза­тельным, см. правило 3.

Правило 6. Если тип бинарной связи — многие-ко-многим, см. правило 3.

Правило 7. Для представления N-арной связи требуется N+1 таблица. Например, в случае тернарной связи формируются че­тыре таблицы, по одной для каждой сущности и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи от каж­дой сущности.

Правило 8. Для связи «супертип-подтип» возможны два спо­соба преобразования:

а) все подтипы в одной таблице;

б) для каждого подтипа — отдельная таблица.

При применении способа (а) для супертипа создается табли­ца, а для подтипов могут создаваться представления (view). В таб­лицу добавляется по крайней мере один столбец, содержащий код типа; он становится частью первичного ключа.

При использовании способа (б) для каждого подтипа супертип воссоздается с помощью операции объединения (UNION) — из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа.

Преимущества способа (а): все данные хранятся вместе, обес­печивается легкий доступ к супертипу и подтипам, требуется меньше таблиц.

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

Преимущества способа (б): наглядное соответствие схемы БД и ERM, приложения работают только с нужными таблицами.

Недостатки способа (б): формируется слишком много таблиц, возможно снижение производительности при выполнении опе­рации объединения, невозможны модификации супертипа.

4.2.