Реализация моделей с помощью case – средства

Моделирование работы информационной системы особенно важно на первых этапах её создания. Так как исправление допущенных на этом этапе ошибок обходится наиболее дорого, то и польза на этапе анализа задачи и разработки логической модели её решения значительна. CASE (Computer-Aided Software/System Engineering): Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. CASE - технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов для автоматизации процесса проектирования и разработки ПО. CASE-средства позволяют получить описание работы создаваемой системы раньше, чем её построили. Потом с их помощью можно анализировать работу системы и оптимизировать подготавливаемые решения. Для этого специально предусмотрен инструментарий проектирования.

28. Современные технологии доступа к базам данных. Двухзвенная и трехзвенная архитектуры ис.

Основные понятия модели клиент-сервер.

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

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

Клиент – это логич. процесс, кот. запраш. обслуживание от сервера, явл-ся инициатором диалога с сервером. Обязанности клиента – запрос на обслуживание, инициирование взаимод-вия с сервером, получение ре-та с сервера, обработка ошибок.

Отличия арх-ры клиент-сервер от файл-сервер

Арх-ра ф-с

Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файлов. сервер принимает запросы, поступающие по сети от комп-в клиентов и передает им требуемые данные. Обработка этих данных вып-ся на комп-х клиентов. Напрмер, база, созданная в субд Аксесс, нах-ся на файлов.сервере, на каждом комп-е-клиенте при обращении к серверу запускается полная копия процессора обработки данных Jet Engine. Люб. копия Jet независимо управляет файлами mdb, содержащимися на комп.-клиенте. Единственная связь м/д этими действиями – файл блокировок, имеющ. расширение ldb.

Недостатки:

1.резкое снижение произв-ти работы с приложениями при увелич. числа пользов-й.

2.Загруженный трафик сети.

Арх-ра к-с

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

Распределение функций в арх. к-с

Функцион-ть разрабатываемого приложения зависит от того, как распределена нагрузка ПО м/д клиентской и серверной частью. Пытаясь реш. эту задачу, разработчики получают однозвенные, двухзвенные, трехзвенные и многозвенные арх-ры.

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

Осн. ф-ции серверной СУБД – это обеспечение надежности, согласов-ти и защищенности данных, управление запросами клиентов, быстр. обработка SQL-запросов. Вся логика работы приложения – прикладной задачи - бизнес-правила распределялись разработчиками м/д 2мя процессами: клиентом и сервером. Сначала бОльшая часть ф-ций решалась с клиентом, сервер занимался только обработкой SQL-запросов. Такая арх-ра получ. название «толстый клиент, тонкий сервер».

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

Понятие однозвенной арх-ры (one-tier)

Это система, в кот. все службы БД, приложения и пользов-кий интерфейс размещены в 1 системе. Система такого типа не производит обработку вне тех компонентов, на кот они исполняются.

Двухзвенная арх-ра (two-tier) в двухзвенных приложениях БД и польз. интерфейс размещаются на разных комп-х. Двухзв. приложения встречаются чаще всего. Польз. интерфейс обычно написан на Microsoft C++(для ОС Виндоус)

Трехзвенная арх-ра (three-tier)

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

Клиент-серверная система SQL-сервер

может менять 2зв. или 3зв. установку. Независимо от варианта установки прогр. обеспечение Бд размещается на сервере БД.

В 2зв. системах клиенты исполняют приложения, осущ-щие доступ к серверу и прилож-я, отображающие для пользователя рез-ты доступа к БД. Такие клиенты называются «толстыми», потому что выполняют 2 вида работ. 2зв. арх-ра имеет смысл при относительно небольш. кол-ве пользов-й (до 100-150). В 3зв. установке имеется 3й комп. – серверное приложение. Серверн.прил. исполняет задачи, кот. явл-ся много потоковыми, благодаря чему с ними м. работать много польз-лей одновременно. Достоинством 3зв. арх-ры явл-ся то, что м. позволять сервер. приложению организовывать все клиентские соединения с сервером, осущ-ть доступ к данным, при этом организуется так называем. пул соединения (-очередь), кот. буд. дожидаться ближайшего доступного соединения.