"Квазар-Офлайн". Распределенный вычислительный комплекс для решения задач распознавания образов

• Автор: Качалков, Александр Викторович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2007
• Место защиты: Екатеринбург
• Количество страниц: 115 с. : ил.

1 Инструменты разработки и проектирования

1.1 Обзор существующих решений

1.2 Платформа разработки

1.3 Система управления вычислительным порталом

1.4 Сервер базы данных

1.5 Компоненты доступа к данным

1.6 Объектно-ориентированный анализ и унифицированный процесс

2 Анализ требований и построение модели

2.1 Анализ требований

2.2 Сопутствующие цели и требования

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

2.4 Подсистема размещения и мониторинга заданий
2.4.1 Прецеденты системы
2.4.2 Диаграмма прецедентов
2.5 Диаграммы последовательностей
2.6 Модель предметной области
(концептуальная модель)
2.7 Описание системных операций

2.7.1 Системные операции для основных прецедентов
2.8 Пример тестовой модели
3 Архитектура прототипа системы
3.1 Структура базы данных
3.2 Компоненты доступа к базе данных
3.3 Архитектура модуля Quasar
3.4 Установка модуля и настройка Quasar
3.5 Подсистема размещения и мониторинга заданий
3.5.1 Функции по управлению данными пользователя
3.5.2 Функции, связанные с размещением заданий
3.5.3 Функции, связанные с мониторингом заданий
3.6 Вычислительная подсистема
3.6.1 Разработка вычислительного алгоритма
3.6.2 Архитектура вычислительного алгоритма
3.6.3 Создание вычислительного компонента Quasar
3.6.4 Служба обработки заданий
3.6.5 Регистрация нового вычислительного алгоритма в базе данных Quasar
Заключение
3.7 Новые направления развития проекта
«КВАЗАР—Офлайн»
Литература

Гл. 2. Анализ требований и построение модели
• TaskLineltemSpecification описывает TaskLineItem
• ResultLineltemSpecification описывает ResultLineltem.
Далее обратимся к описаниям прецедентов. Также, известно [14], что атрибут — это абстрактное свойство класса. Основное требование при выделении атрибутов — их простота: атрибуты должны быть простого типа данных (строка, число и т.п.). Стандартной ошибкой при добавлении атрибутов является представление сложного понятия предметной области в форме атрибута.
Задачи принадлежат определенному пользователю. Добавим в нашу модель класс User. Реализовать эту информацию в форме атрибута нельзя, т.к. очевидно информация о пользователе может быть описана простым типом данных. Требование того, что атрибуты модели предметной области должны описываться только простыми типами данных не предполагает, что в объектно-ориентированном языке атрибуты должны быть простых типов данных.
Модель предметной области акцентирует внимание на исследовании проблемы предметной области, а не на программных сущностях. В объектно-ориентированных языках ассоциации модели предметной области зачастую реализуются как атрибуты, указывающие на другие сложные объекты, однако это не единственный способ реализации ассоциаций. Например, для объекта Task дата размещения и завершения задания является атрибутом. Аналогично, на этапе проектирования можно выделить несколько простых атрибутов. После объединения концептуальных классов, ассоциаций и атрибутов, модель предметной области, подсистема размещений заданий представлена на (см. рис. 2.6.4).