бесплано рефераты

Разделы

рефераты   Главная
рефераты   Искусство и культура
рефераты   Кибернетика
рефераты   Метрология
рефераты   Микроэкономика
рефераты   Мировая экономика МЭО
рефераты   РЦБ ценные бумаги
рефераты   САПР
рефераты   ТГП
рефераты   Теория вероятностей
рефераты   ТММ
рефераты   Автомобиль и дорога
рефераты   Компьютерные сети
рефераты   Конституционное право
      зарубежныйх стран
рефераты   Конституционное право
      России
рефераты   Краткое содержание
      произведений
рефераты   Криминалистика и
      криминология
рефераты   Военное дело и
      гражданская оборона
рефераты   География и экономическая
      география
рефераты   Геология гидрология и
      геодезия
рефераты   Спорт и туризм
рефераты   Рефераты Физика
рефераты   Физкультура и спорт
рефераты   Философия
рефераты   Финансы
рефераты   Фотография
рефераты   Музыка
рефераты   Авиация и космонавтика
рефераты   Наука и техника
рефераты   Кулинария
рефераты   Культурология
рефераты   Краеведение и этнография
рефераты   Религия и мифология
рефераты   Медицина
рефераты   Сексология
рефераты   Информатика
      программирование
 
 
 

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

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

Таблица 2.2. Сравнительный анализ средств проектирования

Критерии выбора Rational Rose Microsoft Office Visio Borland Together Вес
Доступность 3 5 3 3
Требования к ресурсам 5 4 3 1
Удобство интерфейса 4 5 3 2
Итого: 22 29 18

Итак, в соответствии с проведенным анализом, в качестве средства проектирования используется Microsoft Office Visio.

 

2.3 Проектирование системной архитектуры

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

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

Архитектура - это совокупность существенных решений касательно:

ü организации программной системы;

ü выбора структурных элементов, составляющих систему, и их интерфейсов;

ü поведения этих элементов, специфицированного в кооперациях с другими элементами;

ü составления из этих структурных и поведенческих элементов все более и более крупных подсистем;

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

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

Моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме, так называемой диаграммы вариантов использования (Use Case Diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.

2.3.1 Построение диаграммы вариантов использования

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

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

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

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

Рис. 2.3.1. Пользовательская диаграмма вариантов использования

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

Более детально процесс представлен на системной диаграмме вариантов использования, которая приводится в приложении 1.

2.3.2 Спецификация вариантов использования

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

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

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

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

Диаграмма последовательности данного процесса приведена в приложении 3.

Рис. 2.3.2. Диаграмма деятельности «Работа с БД ЭОР»

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

Рис. 2.3.3. Диаграмма деятельности «Назначение задачи»


Диаграмма последовательности приведена в приложении 4.

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

Рис. 2.3.4. Диаграмма деятельности «Получение задания»

Диаграмма последовательности приведена в приложении 5.

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

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

Рис. 2.3.5. Диаграмма деятельности «Формирование отчетной документации»

Диаграмма последовательности приведена в приложении 6.

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

В общем виде весь процесс представлен на общей диаграмме деятельности с дорожками, которая приведена в приложении 2.

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

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

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

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

Диаграмма классов проектируемой системе изображена на рисунке 2.3.6.

Рис. 2.3.6. Диаграмма классов

Структура классов

Класс Сотрудники ЦПК используется для хранения информации о сотрудниках.

Атрибуты класса Сотрудники ЦПК

Имя атрибута Тип атрибута Описание атрибута
ID сотрудника integer Уникальный идентификатор сотрудника
ФИО string Фамилия, имя, отчество сотрудника
Телефон string Телефон
e-mail string Электронная почта
Адрес string Адрес

Данный класс подразделяется на два подкласса: Начальник ЦПК и Сотрудник ЦПК, их атрибуты совпадают.

Методы класса Сотрудники ЦПК

Имя метода Описание метода
Показать Используется для вывода сведений о сотрудниках
Редактировать Используется для редактирования сведений о сотрудниках

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

Атрибуты класса Задачи

Имя атрибута Тип атрибута Описание атрибута
ID задачи integer Уникальный идентификатор задачи
Наименование string Наименование задачи

Методы класса Задачи

Имя метода Описание метода
Добавить Используется для добавления новой задачи
Удалить Используется для удаления задачи
Редактировать Используется для редактирования задачи

Класс Назначенные задачи используется для хранения сведений о назначенных задачах.

Атрибуты класса Назначенные задачи

Имя атрибута Тип атрибута Описание атрибута
ID назначения integer Уникальный идентификатор назначения
ID задачи integer Уникальный идентификатор задачи
ID ресурса integer Уникальный идентификатор ресурса
ID разработчика integer Уникальный идентификатор того, кому назначена задача
ID назначающего integer Уникальный идентификатор того, кто назначил задачу
Дополнительные сведения string Дополнительные сведения о задаче
Дата назначения date Дата назначения задачи
Крайний срок выполнения date Крайний срок, к которому задача должна быть выполнена
Дата начала выполнения date Дата начала работ по выполнению
Дата окончания выполнения date Дата окончания работ по выполнению

Методы класса Назначенные задачи

Имя метода Описание метода
Назначить Используется для назначения задачи по разработке ЭОР одному из сотрудников
Редактировать Используется для редактирования основных сведений о задаче

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

Атрибуты класса Категории ресурсов

Имя атрибута Тип атрибута Описание атрибута
ID категории integer Уникальный идентификатор категории
Наименование string Наименование категории

Методы класса Категории ресурсов

Имя метода Описание метода
Добавить Используется для добавления новой категории
Удалить Используется для удаления категории
Редактировать Используется для редактирования категории

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

Атрибуты класса Электронные образовательные ресурсы

Имя атрибута Тип атрибута Описание атрибута
ID ресурса integer Уникальный идентификатор ресурса
ID категории integer Уникальный идентификатор категории ресурса
ID кафедры integer Уникальный идентификатор кафедры
Наименование string Наименование ресурса
Автор string Автор
Город string Город, в котором проживает автор, написавший курс
Описание string Описание ресурса, краткие сведения
ID разработчика integer Уникальный идентификатор сотрудника, которому поручено разработать данный ресурс
Дата публикации date Дата публикации данного ресурса на образовательном портале

Методы класса Электронные образовательные ресурсы

Имя метода Описание метода
Добавить Используется для добавления нового ресурса
Удалить Используется для удаления ресурса
Редактировать Используется для редактирования сведений о ресурсе

Класс Кафедры служит для хранения информации о кафедрах белгородского филиала МЭСИ.

Атрибуты класса Кафедры

Имя атрибута Тип атрибута Описание атрибута
ID кафедры integer Уникальный идентификатор кафедры
Наименование string Наименование задачи

Методы класса Кафедры

Имя метода Описание метода
Добавить Используется для добавления новой кафедры
Удалить Используется для удаления кафедры
Редактировать Используется для редактирования кафедры

Класс Отчеты служит для хранения сведений о выданных отчетах сотрудников.

Страницы: 1, 2, 3


© 2010 САЙТ РЕФЕРАТОВ