Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Выбор технологии клиентского приложения

Читайте также:
  1. D. Отсрочка выборов в Великое Национальное Собрание Турции и дополнительные выборы
  2. I. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ - ОТ ТЕХНОЛОГИЙ К ИНФОРМАЦИИ
  3. IV. ТЕХНОЛОГИИ И КОНЕЧНОЕ ИСПОЛЬЗОВАНИЕ ПОСТОЯННЫ И ЗАДАНЫ
  4. Panacea страница технологии Meyer.
  5. V. Образовательные технологии
  6. VII. Укажите, под какими номерами перечислены общие условия, определяющие выбор методов воспитания
  7. А выбор тона повествования зависит от жанра произведения.

 

Основными преимуществами для выбора JSP послужило следующее:

¾ JSP обеспечивает хорошим набором API, что даёт возможность создавать свои компоненты. Также можно воспользоваться уже готовыми компонентами, такими как: PrimeFaces, RichFaces и др.

¾ С помощью JSP легко указать, с помощью какого Java кода будет обрабатываться форма.

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

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

¾ Централизованная файловая конфигурации JSP, что позволяет вместо жесткого кодирования данных в программе Java выносить ее в конфигурационный файл. Что позволяет без редактирования Java кода и перекомпиляции изменить эти данные [5].

¾ В JSP также можно использовать MVC подход.

 

4 Информационная модель системы и её описание

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

Для разработки структуры базы данных использовались средства Erwin Data Modeler. Ниже представлен логический (рисунок 4.1) и физический (рисунок 4.2) уровни модели системы.

 

 

Рисунок. 4.1 – Логический уровень информационной модели

 

 

Рисунок. 4.2 – Физический уровень информационной модели

База данных agrodb хранит информацию о сельскохозяйственном оборудовании, о странах производителях этого оборудования и его назначении, в соответствующих таблицах – equipment, country и category. Так же представлена таблица buyer c информацией о покупателях и таблица ordersales, в которой храниться вся информациях о продажах.

В модели существуют следующие связи:

1) Сущности category и equipment находятся в отношении «один ко многим», так как у одной категории может быть множество моделей сельскохозяйственного оборудования.

2) Сущность country находится в отношении «один ко многим» с сущностью equipment – в стране производится множество видов оборудования.

3) Сущности buyer и ordersales находятся в отношении «один ко многим». Это связь объясняется тем, что покупатель может сделать множество заказов.

4) Сущность equipment и ordersales находятся в отношении «один ко многим». В заказе может быть множество оборудования.

Теперь следует проверить, не нарушены ли в данном проекте какие-либо принципы нормализации.

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

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

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

Итогом этого этапа проектирования является появление в проекте самой статичной и важной его части – базы данных.

 

 


Дата добавления: 2015-10-16; просмотров: 61 | Нарушение авторских прав


Читайте в этой же книге: Зыходныя даныя да праекта | Требования к поставке. | Описание предметной области и определение требований к системе | Постановка и решение задач | Результаты тестирования разработанной системы | ПРИЛОЖЕНИЕ А | Stop_jboss.bat |
<== предыдущая страница | следующая страница ==>
Модели представления системы| Руководство пользователя

mybiblioteka.su - 2015-2024 год. (0.007 сек.)