Разработка концептуальной модели задачи

В начале раздела даётся определение концептуальной модели как понятие, затем приводится краткое описание идеи-концепции проекта, и сама схема концептуаль-ной модели задачи как стратегии разработки будущего проекта АИС. Модель схе-матично определяет перечень создаваемых объектов АИС.

 

Рассмотрим один из примеров разработки концептуальной модели задачи:

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

 

Пример концептуальной модели представлен на следующей схеме.

- Учебники - Контрольные - Вопросы

- Лекции работы - Ответы

- Пособия - Лабораторные - Список тестируемых

- Файлы работы студентов (БД)

 

 

Рис. 1.1. Схема концептуальной модели задачи

 

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

 

Помимо учебно-практического набора “Обучающая система” в блоке проверки знаний (Тест), расположены материалы, представляющие собой сборник вопросов и ответов по различным главам дисциплины находящийся на бумажных носителях. Имеется список студентов в формате БД, проверяемых на степень усвоения ими теоретических знаний и практических навыков в рамках изучаемой дисциплины.

 

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

 

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

 

Каждый объект “Обучающей системы” должен иметь удобную навигацию.

 

Сервисные функции объектов должны содержать набор средств защиты.

Обоснование выбора технических средств,

Операционной системы

 

В данном разделе для обоснования выбора вышеперечисленных компонентов приводится обзор существующих на сегодня технических средств (ТС), опера-ционных систем, затем даётся их сравнительная характеристика.

 

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

 

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

 

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

 

Критерием качества “Постановки задачи” является самостоятельное программи-рование, отладка и решение задачи сторонней организацией.

 

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

 

Характеристика задачи

 

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

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

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