Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







Проблема учета университетских курсов





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

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

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

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

После окончания регистрации профессорам передаются реестры студентов по каждому курсу.

 

Оценки рисков

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

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

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

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



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

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

Резюме

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

Функции системы

 

Характеристики поведения разрабатываемой системы фиксируются и документиру­ются средствами модели, которая отображает функции (варианты использования— use cases) продукта, представляет окружение системы (множество активных субъектов — ac­tors) и определяет связи между вариантами использования и активными субъектами (диаграммы вариантов использования— use case diagrams). Наиболее важной является ком­муникативная составляющая модели, позволяющая группам разработчиков, заказчиков и конечных пользователей, обсуждающим свойства системы, говорить на одном языке.

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

Активные субъекты

Каждый из внешних активных субъектов (actors) отождествляется с чем-то или с кем-то, взаимодействующим с системой. Активный субъект способен выполнять раз­личные функции:

• Только вводить данные в систему;

• только получать информацию из системы;

• взаимодействовать с системой в обоих направлениях.

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

• Кто именно заинтересован в выполнении определенного требования?

• В каком подразделении организации должна использоваться система?

• Кто получит преимущества от внедрения системы в эксплуатацию?

• Кто будет поставлять системе те или иные данные, обращаться к ним и нести
ответственность за их обновление и удаление?

• Кому предстоит выполнять обязанности администратора
системы?

• Должна ли система использовать внешние ресурсы?

• Способен ли один и тот же активный субъект играть несколько
различных ролей?

• Разрешено ли нескольким субъектам осуществлять в системе оди­наковые функции?

• Будет ли система использоваться совместно с какими-либо существующими унаследованными системами?

 

В языке UML активный субъект представляется символом, показанным на рис 3.1.

 
   


Выбор активных субъектов

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

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

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









Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:


©2015- 2018 zdamsam.ru Размещенные материалы защищены законодательством РФ.