- •Каноническое проектирование и документирование проекта
- •Гост на этапы канонического проектирования
- •Этап системного анализа
- •Техническое задание
- •Планирование разработки
- •Пооперационный перечень работ
- •Типы зависимостей
- •Рабочий график
- •Диаграмма Ганта
- •Сетевые диаграммы
- •Прогнозирование
- •Количественные характеристики
- •Технико-экономическое обоснование (тэо)
- •Этап проектирования (синтез систамы)
- •Статическая (структурная) модель
- •Модель репозитория
- •Модель абстрактной машины
- •Статическая модель распределенной архитектуры.
- •Файл-серверные приложения.
- •Клиент-серверные приложения.
- •Двух- и трехуровневые архитектура клиент-сервер.
- •Архитектура распределенных объектов.
- •Динамическая модель
- •Пользовательский интерфейс
- •Психофизические особенности человека, связанные с восприятием и обработкой информации.
- •Основные критерии оценки интерфейсов
- •Типы интерфейсов пользователя
- •Интерфейс примитивный
- •Интерфейс Меню.
- •Интерфейс со свободной навигацией (графический интерфейс).
- •Классификации и принципы разработки диалогов.
- •Типы диалога.
- •Формы диалога.
- •Фразовая форма
- •Директивная форма
- •Табличная форма
- •Состав и содержание технического проекта.
- •Вопросы и задания для самопроверки
- •Глоссарий
- •Глава III.Каноническое проектирование и документирование проекта 1
Файл-серверные приложения.
Это исторически первая распределенная архитектура (Рис. III -17). Организуется она предельно просто: на сервере находятся только данные, а все остальное относится к клиентской машине. Поскольку локальные сети достаточно дешевы, и в силу того, что при такой архитектуре прикладное ПО автономно, такая архитектура достаточно часто используется и сейчас. Можно сказать, что это вариант клиент-серверной архитектуры, при которой на сервере находятся только файлы данных. Разные персональные компьютеры взаимодействуют только по средствам общего хранилища данных, поэтому программы, написанные в расчете на один компьютер проще всего адаптировать под такую архитектуру.
Плюсы:
Рис. III‑17 Схема файл- серверных приложений
Плюсы файл-серверной архитектуры:
- простота организации;
- не противоречит необходимым требованиям к БД к поддержанию целостности и надежности.
Минусы:
- перегрузка сети;
- непредсказуемость реакции на запрос.
Эти недостатки объясняются тем, что любой запрос к БД приводит к перекачке по сети к значительным объемам информации. Например, для выборки из таблиц одной или нескольких строк перекачивается вся таблица на клиентскую машину и уже там СУБД производит выборку. Значительный сетевой трафик особенно чреват при организации удаленного доступа к БД.
Клиент-серверные приложения.
В данном случае имеет место распределение обязанностей между сервером и клиентом. В зависимости от того, как они разделены различают толстого и тонкого клиента.
Рис. III‑18 Архитектура "Толстый клиент"
К толстому клиенту относят все связанное с приложением, а к серверу относят все связанное с БД (Рис. III -19).
Рис. III‑19 Распределение функций в архитектуре "Толстый клиент"
Рис. III‑20 Архитектура "Тонкий клиент"
В модели «тонкий клиент” вся работа приложения и управление данными выполняются на сервере. Пользовательский интерфейс в этих системах "переселяется" на персональный компьютер, а само программное приложение выполняет функции сервера, т.е. выполняет все процессы приложения и управляет данными. Модель тонкого клиента можно также реализовать там, где клиенты компьютеры или рабочие станции. Сетевые устройства запускают Internet-броузер и пользовательский интерфейс, реализованный внутри системы.
Главный недостаток модели тонкого клиента - большая загруженность сервера и сети. Все вычисления выполняются а сервере, а это может привести к значительному сетевое трафику между клиентом и сервером. В современных компьютерах достаточно вычислительной мощности, но она практически не используется в модель/тонкого клиента банка
Напротив, модель толстого клиента использует вычислительную мощность локальных машин: само приложение помещаются на клиентский компьютер. Примером архитектуры такого типа могут служить системы банкоматов, в которых банкомат является клиентом, а сервер -центральным компьютером, обслуживающим базу данных по расчетам с клиентами
Двух- и трехуровневые архитектура клиент-сервер.
Все рассмотренные выше архитектуры являются двухуровневыми. В них различается уровень клиента и уровень сервера. Строго говоря, ИС состоит из трех логических уровней:
Уровень пользователя;
Уровень приложения:
Уровень данных.
Поэтому в двухуровневой модели, где задействованы только два уровня, возникает проблема с масштабируемостью и производительностью, если выбрана модель тонкий клиент, либо проблемы связанные с управлением системы, если взята модель толстый клиент. Избежать этих проблем можно, если применять модель, состоящую из трех уровней, где два из них сервера(Рис. III -21).
Рис. III‑21 Схема 3-х уровневой архитектуры Сервер -Клиент
Фактически сервер приложения и сервер данных могут располагаться на одной машине, но выполнять функции друг друга они не могут. Трехуровневая модель хороша тем, что в ней логически разделены выполнение приложения и управление данными.
Таблица III‑5 Применение разных типов архитектур
Архитектура |
Приложение |
Двухуровневая тонкий клиент |
1 Наследуемые системы, в которых не целесообразно разделять выполнение приложения и управление данными. 2 Приложения с интенсивными вычислениями, но малыми объемами управления данными. 3 Приложения с большими объемами данных, но малым количеством вычислений. |
Двухуровневый толстый клиент |
1 Приложения, где пользователю требуется интенсивная обработка данных, то есть визуализация данных. 2 Приложения с относительно постоянным набором функций пользователя, применяемых к среде с хорошо отлаженным системным управлением. |
Трехуровневый сервер-клиент |
1 Большие приложения с сотами и тысячами клиентов 2 Приложения, в которых часто меняются и данные и методы их обработки. 3 Приложения, в которых выполняются интеграции данных из многих источников. |
Такая модель подходит многим типам приложений, но ограничивает разработчиков ИС, которые должна решать, где предоставить сервисы, обеспечивать поддержку масштабируемости, разрабатывать средства для подключения новых клиентов.