- •Реферат Расчетно-пояснительная записка содержит 127 страниц, 65 таблиц, 39 рисунков.
- •Содержание
- •Нормативные ссылки
- •Определения, обозначения и сокращения.
- •Введение
- •1. Конструкторская часть
- •Перечень функций, подлежащих автоматизации
- •Уменьшение времени обслуживания пациентов за счёт автоматизации
- •Сущности и отношения между ними
- •Сравнение с аналогами
- •Перечень задач, подлежащих решению в процессе проектирования
- •Разработка структуры
- •Внутреннее проектирование
- •Проектирование баз данных
- •Описание инфологической модели
- •Выбор субд
- •Разработка даталогической модели
- •1.2.6. Разработка архитектуры асоиу
- •1.2.6.1. Выбор архитектуры
- •1.2.6.1.1. Архитектура «Файл-сервер».
- •1.2.6.1.2. Архитектура «Клиент-сервер».
- •1.2.6.1.3.Трёхуровневая архитектура
- •1.2.6.2. Выбор языка сценариев
- •Технологическая часть
- •Задание входных/выходных данных
- •Разработка графа диалога
- •Разработка экранных форм.
- •Руководство пользователю
- •Исследовательская часть
- •3.1. Оптимизация логической схемы бд
- •3.1.1. Понятие «хорошей» схемы бд
- •3.1.2. Алгоритм построения «хорошей» схемы бд
- •Доказательство «хорошей» схемы бд
- •Организационно-экономический раздел
- •4.1. Экономическое обоснование внедрения асдо клиентов поликлиник
- •4.1.1. Обоснование сметы затрат на разработку программного продукта асдо клиентов поликлиник
- •4.1.1.1. Расчет затрат на расходные материалы
- •4.1.1.2. Расчет затрат на оборудование
- •4.1.1.3. Расчет затрат на оплату труда
- •4.1.1.4 Расчет затрат на единый социальный налог
- •4.1.1.5 Расчет затрат на услуги сторонних организаций
- •4.1.1.6 Расчет затрат на накладные расходы
- •4.2 Расчет стоимости оборудования, которое следует закупить для создания асдо клиентов поликлиник
- •4.3. Расчет стоимости программного обеспечения, которое следует закупить для создания асдо клиентов поликлиник
- •4.4. Расчет стоимости установки и монтажа асдо клиентов поликлиник
- •4.5. Расчет экономии стоимости затрат на содержание и эксплуатацию асдо после ее внедрения за месяц
- •4.6. Расчет срока окупаемости асдо после ее внедрения
- •Промышленная экология и безопасность
- •5.1. Характеристика внешних условий и ритма труда, освещенности, неблагоприятных факторов на утомляемость и снижение производительности труда.
- •5.2. Характеристика условий труда
- •5.3. Эргономические требования к рабочему месту.
- •5.4. Расчёт освещённости
- •5.4.1. Комната 1 (два программиста).
- •5.4.2. Комната 2 (руководителя)
- •Заключение
- •Список использованных источников
- •Приложение а. Графические листы
- •Приложение б. Техническое задание
- •«Автоматизированная система дистанционного обслуживания клиентов поликлиник»
- •Оглавление
- •1. Наименование
- •7. Техническая документация, предъявляемая по окончании работы
- •8. Порядок приёма работы
- •9. Дополнительные условия
1.2.6. Разработка архитектуры асоиу
1.2.6.1. Выбор архитектуры
1.2.6.1.1. Архитектура «Файл-сервер».
Здесь функционируют два компонента: это файл-сервер и рабочая станция.
Рисунок 1.12. - Архитектура «Файл-сервер»
Файл-сервер и станция работают на разных компьютерах, которые соединены между собой сетью. Запросы к серверу формируется на уровне доступа к файлам.
Недостатком данной системы является то, что данные обрабатываются на станциях, и хранятся на сервере. Это влечет за собой большую нагрузку на сеть и, следовательно, снижение производительности всей системы. Кроме того, проблемы одновременного доступа к данным, поддержки целостности и согласованности данных решаются копиями приложений на рабочих станциях, т.е. децентрализовано, что чревато конфликтами и трудностями в их решении.
1.2.6.1.2. Архитектура «Клиент-сервер».
Два основных компонента этой архитектуры – это два независимых процесса: клиент и сервер. Сервер работает на том компьютере, где хранятся данные, а клиент - на компьютере пользователя.
Рисунок 1.13. - Архитектура «клиент-сервер»
Клиент формирует пользовательский интерфейс и запросы к серверу на чтение и изменение данных, хранящихся в нем. Можно сказать, что клиент есть приложения, которые выполняются над СУБД. Сервер выполняет эти запросы, обработку данных, отслеживает хранение целостности и согласованности, а также права доступа к данным и возвращает клиенту результаты выполнения ее запроса.
1.2.6.1.3.Трёхуровневая архитектура
Трёхуровневая архитектура — вариант архитектуры клиент - сервер, в котором пользовательский интерфейс, доступ к данным и хранение данных разрабатываются и функционируют как независимые модули, зачастую на различных платформах.
Трёхуровневая архитектура представляет собой:
Терминал - это интерфейсный (обычно графический) компонент, который представляет первый уровень, собственно приложение для конечного пользователя. Первый уровень не должен иметь прямых связей с базой данных (по требованиям безопасности), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надежности). На первый уровень может быть вынесена и обычно выносится простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции (сортировка, группировка, подсчет значений) с данными, уже загруженными на терминал.
Сервер приложений располагается на втором уровне. На втором уровне сосредоточена большая часть бизнес-логики. Вне его остаются фрагменты, экспортируемые на терминалы, а также погруженные в третий уровень хранимые процедуры и триггеры.
Сервер базы данных обеспечивает хранение данных и выносится на третий уровень . Обычно это стандартная реляционная или объектно-ориентированная СУБД. Если третий уровень представляет собой базу данных вместе с хранимыми процедурами, триггерами и схемой, описывающей приложение в терминах реляционной модели, то второй уровень строится как программный интерфейс, связывающий клиентские компоненты с прикладной логикой базы данных.
Достоинствами трёхуровневой архитектуры являются:
Масштабируемость
конфигурируемость - изолированность уровней друг от друга быстро и простыми средствами переконфигурировать систему при возникновении сбоев или при плановом обслуживании на одном из уровней.
высокая безопасность
высокая надежность
низкие требования к скорости канала (сети) между терминалами и сервером приложений.
низкие требования к производительности и техническим характеристикам терминалов, как следствие, снижение их стоимости. Терминалом может выступать не только компьютер, но и мобильный телефон к примеру.
При разработке интернет-магазинов нужны поддержка транзакций, устойчивость к сбоям и способность справляться с массированной загрузкой. Интернет серверу иногда приходится обрабатывать сотни обращений в секунду. К тому же традиционная клиент-сервер схема чувствительна к потере соединения. Выход - оставить прикладной процесс рядом с сервером данных, чтобы иметь устойчивое соединение с последним и удерживать контекст транзакции.
Учитывая вышеизложенное, в качестве архитектуры для разработки интернет-магазина была выбрана трёхуровневая архитектура.