Состав функциональной модели.
Функциональная модель состоит из диаграмм, фрагментов текста и глоссария, которые имеют ссылки друг на друга.
Диаграммы – это главные компоненты модели. Все функции системы для них представлены в виде блоков и дуг. Управляющая информация входит в блок сверху. Информация, которая подвергается обработке, рисуется слева, результаты операций – справа. Механизм, который осуществляет выполнение операций, рисуется дугой, которая входит в блок снизу.
Каждый элемент модели может быть декомпозирован на другой диаграмме.
Иерархия диаграмм.
Построение моделей системы начинается с представления системы в виде простейшего компонента, т.е. одного блока и дуг, которые символизируют интерфейсы с внешними функциями системы. Затем данный блок декомпозируется на следующей диаграмме с помощью нескольких блоков и дуг, при этом соблюдаются правила:
1. Каждая подфункция может содержать только те же элементы, которые входят в исходную функцию.
2. Модель не может опускать какие-либо элементы для сохранения целостности системы.
Тип связей между функциями
1. Тип случайной связности – возникает, когда конкретная связь между функциями мала или полностью отсутствует
2. Тип логической связности – возникает, когда данные и функции собираются вместе по причине того, что попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не существует.
|
|
|
3. Тип временной связности – элементы данного типа возникают вследствие того, что они представляют функции, связанные по времени, когда данные используются одновременно, или функции включаются параллельно, а не последовательно.
4. Тип процедурной связности – возникает вследствие того, что функции выполняются в течение одной и той же части цикла или процесса.
5. Тип коммуникационной связности – диаграммы демонстрируют такие связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные или производят одни и те же выходные данные.
6. Тип последовательной связности – при данном типе связи выход одной функции служит входными данными для следующей функции.
7. Тип функциональной связности – диаграммы данного типа отражают полную функциональную связность при наличии полной зависимости одной функции от другой.
Моделирование потоков данных (DFD).
В основе DFD лежит построение модели анализируемой системы в виде иерархии диаграмм потоков данных, которые описывают асинхронный процесс преобразования информации с момента её ввода в систему до момента её выдачи.
|
|
|
Диаграммы верхних уровней иерархии определяют основные процессы с внешними системами. Данные диаграммы детализируются при помощи диаграмм нижнего уровня.
Внешние сущности – это материальные объекты, которые представляют собой источники или приемники информации, свойства данных объектов находятся за пределами рассматриваемой системы.
Системы и подсистемы – при построении сложных систем система может быть представлена в самом общем виде, либо декомпозирована на подсистемы.
1 – Номер системы
2 – Имя системы
3 – Имя проектировщика
Процессы – это преобразование входных потоков данных в выходные, в соответствии с определенным алгоритмом. На практике процесс может быть реализован в виде подразделения организации, которая выполняет обработку входных документов и выпускает отчеты. Изображается как подсистема, но в названии присутствует глагол.
Накопители данных – это абстрактные устройства для хранения информации, которую можно в любой момент времени поместить в накопитель и спустя некоторое время извлечь, причем способы помещения и извлечения могут быть различными.
|
|
|
DN – обязательно присутствует, N – порядковый номер накопителя.
Потоки данных – определяют информацию, подаваемую через какое-либо соединение от источника к приемнику.
Первым шагом при построении является построение диаграмм. Если система простая, то строится единственная диаграмма со звездообразной топологией.
Признаки сложной системы:
1. Наличие большого числа внешних сущностей
2. Распределенная природа системы
3. Многофункциональность системы
При детализации диаграмм должны выполняться следующие условия:
1. Правило балансировки – означает, что при детализации системы в качестве внешних сущностей могут использоваться только те объекты, с которыми система имеет информационную связь.
2. Правило нумерации – при детализации должна сохраняться иерархичная нумерация
Детализация завершается при выполнении следующих условий:
1. Наличие у процесса небольшого количества входных и выходных потоков
2. Возможность описания процессов системы в виде одного законченного алгоритма
3. Выполнение процессом логических функций из входной в выходную
Моделирование данных
Метод Чена-Баркера
Суть моделирования по этому методу состоит в обеспечении разработчика концептуальной схемой БД в форме одной или нескольких моделей, которые могут быть легко отображены в систему БД любого типа.
|
|
|
Наиболее распространенным средством моделирования являются диаграммы ERD (диаграммы сущность - связь). С их помощью определяются, важные для предметной области БД, объекты (сущности) их свойства (атрибуты) и отношения друг с другом (связи). С помощью этих диаграмм проектируются реляционные БД.
Пример:
Рассматривается деятельность компании по торговле автомобилями. Выделяются три основных лица персонала: главный менеджер – он должен знать, сколько заплачено за машину и какие расходы. На основе этих данных он устанавливает нижнюю цену продажи. Второе лицо – продавец. Ему необходимо знать, какую цену запрашивать, какая нижняя цена, и основную информацию о машине. Третье лицо – администратор. Его задача – составление контракта. Для этого ему нужна информация о покупателе, машине и продавце.
Первый шаг моделирования – извлечение информации и выделение сущностей.
Сущность – реальный или воображаемый объект, который имеет существенные значения для рассматриваемой области, информация о которой подлежит хранению.
Каждая сущность обладает свойствами:
1. Уникальное имя
2. Наличие атрибутов
3. Наличие связей с другими сущностями
Следующим шагом моделирования является идентификация связей. Связь – это поименованная ассоциация между двумя сущностями, значимых для данной предметной области.
Различают несколько типов связей и обязательностей.
- Связь «много»
- Связь «один»
- Связь «необязательная»
- Связь «обязательная»
Следующим этапом моделирования является описание атрибутов системы. Атрибут – это любая характеристика сущности, значимая для рассматриваемой области и предназначенная для идентификации или классификации сущностей.
«*» - обязательные
«°» - необязательные
Помимо этого выделяют уникальные идентификаторы – атрибут или совокупность атрибутов, предназначенный для уникальной идентификации каждого экземпляра данного типа сущности.
Атрибуты, которые определяют первичный ключ, размещаются вверху списка и выделяются знаком #.
Помимо перечисленных основных конструкций, модель данных может содержать ряд дополнительных характеристик. Существуют понятия подтипов и супертипов, т.е. одна сущность является обобщающей для группы подобных её сущностей.
Рекурсивная связь – сущность может быть связана сама с собой.
Неперемещаемая связь – т.е. экземпляр сущности не может быть перенесен из одного узла связи в другой.
Методологии IDEF1X
Данный метод разработан Рамэем. Основан на подходе Чена и позволяет построить модель, эквивалентную данных реляционной модели в третьей нормальной форме. В настоящее время на основе методологии IDEF1 разработана IDEF1X, к которой были предъявлены следующие требования:
1. Простота изучения
2. Возможность автоматизации
На основе IDEF1X построен ряд CASE – средств, таких, как Erwin, Designer.
Сущностью данной методологии является независимость от идентификаторов, т.е. каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями.
Сущность называется независимой, если однозначная идентификация экземпляра сущности не зависит от его отношения с другой сущностью. Зависимые сущности обозначены круглыми углами.
В методологии выделяют различные типы мощности связи:
1. Каждый экземпляр сущности – родителя может иметь 0, 1 или более связанных с ним сущностей экземпляров – потомков.
2. Каждый экземпляр сущности – родителя должен иметь не менее одного связанного с ним сущности – потомка.
3. Каждый экземпляр сущности – родителя связан с некоторым числом сущностей – потомков.
Пунктирный элемент изображает не идентифицирующую связь. Сущность – потомок в таком типе связи будет не зависимой от идентификатора при условии, что она является сущностью – потомком какой-либо идентифицирующей связи.
Идентифицирующая связь изображается сплошной линией. Сущность – потомок в таком типе связи является зависимой от идентификатора сущности.
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, располагаются вверху и отделяются от других атрибутов горизонтальной чертой.
Сущности могут также иметь внешние ключи (FK), которые могут использоваться в качестве части или целого первичного ключа.
Архитектура ИС
Файл-серверная архитектура
Данная архитектура наиболее распространена по следующим причинам:
- сокращение автономности ПО клиента
- простота организации
- сохранение привычных условий для пользователя
При всей простоте организации необходимо учитывать особенности:
- при работе с БД необходимо учитывать особенности каждой выбранной СУБД;
- необходимо учитывать особенности поддержания целостности и надежности хранимой БД. Для этого должно выполняться:
- Наличие транзакционного управления
- Хранение избыточных данных
- Возможность введения ограничений целостности и их проверку
В целом, в файл-серверной архитектуре мы имеем простое приложение, работающее с небольшими объемами данных и рассчитанное на однопользовательскую работу.
Клиент-серверная архитектура
Под клиент-серверной архитектурой понимается ИС, основанная на применении серверов БД и имеющая следующие характеристики:
- На стороне «клиент» выполняется ввод приложения, в который обязательно входят компоненты, поддерживающие интерфейс с пользователем;
- Клиентская часть приложения взаимодействует с клиентской частью СУБД, которая является представителем СУБД для приложения.
Интерфейс (ИФ) между клиентской частью приложения и клиентской частью сервера БД основан на использовании языка SQL. Функции предварительной обработки, предназначенные для запросов к БД или формирования конечных отчетов, выполняются в коде приложения. Клиентская часть сервера БД, используя средства сетевого доступа, обращается к серверу БД, передавая ему текст на языке SQL. На стороне сервера БД происходит компиляция полученных операторов на языке SQL, далее выполняются операторы, результаты обработки передаются клиентской части приложения и в конечном итоге – пользователю.
В клиент-серверной архитектуре клиенты могут быть достаточно «тонкими», а сервер д.б. настолько «толстым», чтобы удовлетворить запросы всех клиентов.
С другой стороны, пользователи данной архитектуры часто бывают не удовлетворены, в виду постоянно растущих сетевых расходов. Но на практике, как правило, пользователю необходим какой-то кусок БД, что приводит к идее поддержки локального кэша общей БД.
Концепция локального кэширования является частным случаем концепции реплицирования данных. Для поддержки локального кэша необходим компонент СУБД, который должен обеспечивать однопользовательский режим.
Для поддержки локального кэша необходимо выполнять его синхронизацию с основной БД. Это достигается двумя путями:
- автоматическая синхронизация, путем использования триггеров (через определенные промежутки времени)
- в ручном режиме
Архитектура клиент-сервер является более дорогой по сравнению с файл-серверной, требуется более мощная аппаратура для сервера и более развитые СУБД.
Однако наряду с этим недостатком, существует основное достоинство данной архитектуры, заключающееся в масштабируемости системы и способности к развитию.
Internet – приложение
IntraInternet – архитектура базируется на протоколе http. Данная служба получила широкое распространение по ряду причин:
- Достаточно просто разработать ИС, а затем осуществить доступ по данному методу
- Наличие готовых клиентских частей (браузеры)
Наряду с этими достоинствами существует ряд ограничений:
- В данной ИС отсутствует прикладная обработка данных,
- Гипертекстовые структуры сложно модифицируются
- Пользователь имеет право только просматривать данные
- Недостаточно организован поиск информации. Однако все эти причины могут быть разрешены с использованием более развитых механизмов WEB-технологий.
На настоящий момент логика приложения реализуется с помощью двух подходов: CGI, API. Оба подхода основываются на наличии специальных конструкций, информирующих клиента браузера, что ему следует послать веб-серверу специальное сообщение. При получении сообщения сервер должен вызвать внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном виде.
Данный метод доступа используется для обеспечения доступа к БД в Интернет системах. Язык HTML позволяет вставлять в документ необходимые формы. Когда браузер встречает форму, он предлагает пользователю заполнить её, а затем посылает серверу сообщение, которое содержит введенные параметры. Как правило, к сообщению приписывается внешняя процедура сервера. При получении сообщения от клиента сервер вызывает указанную процедуру и передает ей параметры, введенные пользователем. Таким образом, процедура играет роль шлюза между веб-сервером и сервером БД.
Дата добавления: 2018-04-15; просмотров: 526; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!