Тема 11 Переход от моделирования к пректированию

advertisement
Переход от анализа к проектированию
(концептуальная разработка, конструирование )
Разработал Дубаков А.А.
ОБЗОР

На данном этапе




Совершается переход от анализа к
проектированию
Обсуждаются проблемы, связанные с
проектированием элементов новой системы
Описываются все виды деятельности этапа
проектирования
Описывается проект сети и архитектуры системы
Если «Анализ» концентрируется на том, что
система должна делать – бизнес требования,
 То «Проектирование» ориентируется в
направлении как система будет построена —
определение структурных компонентов

2
ЭЛЕМЕНТЫ ПРОЕКТА


Фаза концептуальной разработки (проектирование) ИС
предназначается для реализации требований
пользователей и решения других проблем,
выявленных на этапе анализа системы
Проектирование – процесс описания, формирования и
структуризации компонентов ИС на уровне проекта
архитектуры и на уровне подробного проектирования




Модель проекта тесно связана с моделью реализации и в
этой связи можно говорить о проектировании и
конструировании как об одной фазе
Концентрируется на подготовке к конструированию и
формирует подсистемы как независимые компоненты
системы
Аналогично разработке конструкторской документации
Решаются три вопроса



Какие компоненты нуждаются в проектировании?
Что является входом и выходом процесса проектирования?
Как выполняется проект системы?
3
ВХОДЫ ПРОЕКТИРОВАНИЯ
АНАЛИЗ
 Цели - понимание:
 Событий бизнеса и
процессов
 Требования к видам
деятельности и
обработке системы
 Требования к
хранилищу
Модели и
информации документы
этапа
анализа
ПРОЕКТИРОВАНИЕ
 Цели – Определить,
специфицировать и
структурировать
компоненты решения
системы, которое
будет служить в
качестве проектной
документация для
конструирования,
которое, как правило,
выполняется
параллельно
4
КОМПОНЕНТЫ ПРОЕКТА
5
КОНЦЕПТУАЛЬНЫЕ ПРОЕКТНЫЕ
РЕШЕНИЯ












Обработка данных - Централизованная, децентрализованная,
распределенная
Хранение данных – Магнитная лента, жесткие диски, CD,
твердая копия
Структура данных - Файловая или база данных
Доступ к файлам – Прямой, последовательный, индексный
Ввод данных-С клавиатуры, голосом, electronic data interchange
(EDI), Optical Character Recognition (OCR), point-of-sale (POS),
Место обработки - В компании или в сторонней организации
Обработка на – Мэйнфрейм, кластере или персональной ЭВМ
Вывод информации - На монитор, на бумагу, на оборотный
документ, голосом
Коммуникационный канал - Телефонная линия, коаксиальный
кабель, оптоволокно, спутниковый канал, радиоканал
Обработка операций - Ручная, пакетная, онлайновая в
реальном времени, workflow (выбор уровня автоматизации)
Приобретение программ - Готовые, модифицированные,
разработанные
Выбор и приобретение средств интеграции и среды middleware
(средний слой)(.NET, J2EE, CORBA…)
6
ПЕРЕХОД ОТ АНАЛИЗА К ПРОЕКТИРОВАНИЮ


Проектирование

Преобразует функциональные модели из анализа
в модели, которые представляют решение

Концентрируется на технических вопросах

В меньшей степени требует вовлечение
пользователей чем анализ
Проектирование может использовать
структурированный или OO подходы

База данных может быть реляционная, объектноориентированная или гибридная

Разрабатывается пользовательский интерфейс
7
СТРУКТУРНЫЕ
И ОО МОДЕЛИ
8
ВИДЫ ДЕЯТЕЛЬНОСТИ ПРОЕКТИРОВАНИЯ
(СОСТАВ ПРОЕКТА)
Проектирование и интегрирование сети
 Проектирование архитектуры
приложения
 Проектирование пользовательского
интерфейса
 Проектирование и интегрирование базы
данных
 Проектирование и интегрирование
системы управления

9
СОСТАВ ПРОЕКТА И КЛЮЧЕВЫЕ ВОПРОСЫ
Вид
деятельности
Ключевые вопросы
Проектирование и
интегрирование сети
Существует ли подробная спецификация как различные
компоненты системы будут соединяться внутри организации
Проектирование
архитектуры
приложения и ПО
Существует ли подробная спецификация как каждая операция
выполняется людьми и компьютером
Проектирование
пользовательских
интерфейсов
Существует ли подробная спецификация как все пользователи
взаимодействуют с системой
Проектирование
интерфейсов системы
Существует ли подробная спецификация как система будет
работать с другими системами внутри и вне организации
Проектирование и
интегрирование базы
данных
Существует ли подробная спецификация как и где система
будет хранить всю информацию, необходимую организации
Прототипирование
деталей
проектирования
Существуют ли прототипы, обеспечивающие полное понимание
решений проекта
Проектирование и
интегрирование
системы управления
Существует ли подробная спецификация гарантирующая
правильное функционирует системы и что поддерживаемые
системой данные надежны и безопасны
10
КРИТЕРИИ КАЧЕСТВА ПРОЕКТА
Удовлетворяет
требованиям системы
 Устойчив к
изменениям этапа
реализации
 Легко поддерживать
 Понятно как
реализовать
 Легко адаптируется к
изменениям
требований


В начале этапа
проектирования
должна быть
специфицирована
используемая для
реализации технология,
поскольку это решение
будет воздействовать на
архитектуру
приложения и весь
проект.
11
ПРОЕКТИРОВАНИЕ И ИНТЕГРАЦИЯ СЕТИ

Сетевые специалисты развивают сеть на основе
стратегического плана (возможно, на основе
структурированной кабельной системы).

Команда разработчиков обычно интегрирует систему в
существующую инфраструктуру сети.

Описываются протоколы связи и промежуточное ПО,
соединяющее уровни.

Описывается обработка и связность для каждого места
размещения системы.

Технические требования пропускной способности должны
удовлетворяться посредством сети.

Технические вопросы должны решаться сетевыми
специалистами.

Получение сетевых адресов, надежность, безопасность, пропускная
способность, синхронизация (таблиц маршрутизации)
12
ПРОЕКТИРОВАНИЕ АРХИТЕКТУРЫ ПРИЛОЖЕНИЯ

Определяет как прецеденты выполняются в
системе

На этапе анализа система описана как
логическая модель деятельности системы


После выбора варианта проектирования,
подробная компьютерная обработка
разрабатывается как физическая модель,
такая как физическая диаграмма потока
данных и структурная схема (традиционный
подход) или диаграммы классов и
взаимодействия (ОО подход)
Подходы различаются зависимости от среды
разработки и развертывания (.NET, JavaEE)
13
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСОВ




Качество пользовательского языка является
критическим аспектом системы
Проект пользовательского интерфейса определяет
как пользователь взаимодействует с системой

GUI – окна, диалоговые окна, мышь

Звук, видео, голосовые команды
Для пользователя системы пользовательский
интерфейс и есть система
Специалисты пользовательского интерфейса –
проектировщик интерфейса, консультант удобства,
специалист по социальной психологии
14
ПРОЕКТИРОВАНИЕ ИНТЕРФЕЙСОВ
СИСТЕМЫ

Системные интерфейсы позволяют системам
разделять и обмениваться информацией
Внутренние системы организации
 Интерфейсы с системами вне организации
 Новые системные интерфейсы с пакетами
приложений, которые приобретает и
устанавливает организация

Системные интерфейсы могут быть сложными
 Организациям могут потребоваться весьма
специальные технические знания для работы с
этими интерфейсами

15
ПРОЕКТИРОВАНИЕ И
ИНТЕГРИРОВАНИЕ БАЗЫ ДАННЫХ
Модель данных анализа системы используется
для создания физической модели данных
 Набор традиционных компьютерных файлов,
реляционные базы данных и/или объектноориентированные базы данных
 Технические требования,

время ответа,
 производительность базы данных


В процессе разработки выполняются


Настройка производительности (Буферы обмена,
индексирование,…)
Интеграция между новой и существующей базой
данных
16
ПРОТОТИПИРОВАНИЕ
РЕШЕНИЙ
ПРОЕКТА
Продолжается создание и оценка прототипов во
время фазы проектирования
 Прототипы подтверждает выбор этапа
проектирования

Базы данных (My SQL, MS SQL, Oracle,…)
 Архитектуру сети
 Систему управления
 Среда программирования- Платформа: JavaEE,
.NET;Сервер: SAS, Apache, Jboss, WebLogic, IBM, IIS;
IDE: Eclipse, NetBeans, VisualStudio,…..


RAD проектирует прототипы, развивающиеся в
готовую систему
17
ПРОЕКТИРОВАНИЕ И ИНТЕГРИРОВАНИЕ
СИСТЕМЫ УПРАВЛЕНИЯ (БЕЗОПАСНОСТЬ
СИСТЕМЫ)

Заключительная проектная деятельность для
обеспечения системе необходимого уровня
безопасности (управление системой) для
защиты активов организации, часто, как
отдельная подсистема.
Доступность – это возможность за приемлемое
время получить требуемую информационную
услугу.
 Целостность - актуальность и непротиворечивость
информации, ее защищенность от разрушения и
несанкционированного изменения.
 Конфиденциальность – это защита от
несанкционированного доступа к информации

18
ЗАДАЧИ СИСТЕМЫ УПРАВЛЕНИЯ

Система управления требуются для всех
подсистем проекта:





User interface – разграничение доступа
авторизованным пользователям
System interface – защита от других систем
Application architecture – обеспечивает управление
транзакциями
Database – защита от сбоев аппаратного и
программного обеспечения
Network design – защита коммуникаций
19
ПРОБЛЕМЫ СРЕДЫ
 АО
чувствительно к проблемам
электрического питания. (Uninterruptable
power supplies (UPS) – источник
бесперебойного питания) и фильтры
рекомендуются для всех систем.
 Кабельные системы также должны быть
защищены. (Молниязащита)
 Проектировать системы противопожарной
безопасности
 Также критично рассеяние тепла и
предотвращение влажности (системы
кондиционирования).
 (Кластер- UPS 10 Kva, прецессионный
20
кондиционер)
ВОССТАНОВЛЕНИЕ ПОСЛЕ РАЗРУШЕНИЯ
Надежность системы обеспечивается избыточностью
наиболее важных компонент АО.
 Планируются процедуры по сохранению и
восстановлению ключевого ПО и данных, а также
инсталляцию АО. (Сервер резервного копирования
следует размещать в другом здании)

21
ПРОЕКТ ТОПОЛОГИИ
СЕТИ
 Потребности
22
сети для функционирования ИС
интегрируются в сетевую инфраструктуру
 Описываются виды обработки и связность для
каждого места размещения элементов
системы
 Описываются коммуникационные протоколы
и промежуточное ПО для соединения уровней
 Обеспечивается достаточная пропускная
способность сети
Объем данных по типам доступа (по различным
протоколам: http, mms,…) и средняя величина
Пиковое значение производительности в минуту
или час
22
КОМПЬЮТЕРНАЯ СЕТЬ
 Набор
23
линий передачи (UTP,
оптоволокно,…), специального оборудования
(сетевые карты, коммутаторы,…) и
коммуникационных протоколов различных
уровней OSI
 Позволяет взаимодействовать различным
пользователям и компьютерным системам
 Local area network (LAN) протяженностью
менее чем один километр – соединяет
компьютеры внутри одного здания
 Wide area network (WAN) превышает один
километр – предполагает значительно
большие расстояния, глобальные
 Router – направляет информацию внутри и
между сетями, обычно аппаратные
23
ВОЗМОЖНАЯ
КОНФИГУРАЦИЯ СЕТИ
24
24
INTERNET, INTRANET И EXTRANET
Internet – глобальное объединение сетей,
которые используют сетевые протоколы TCP/IP
 Intranets

Частная сеть, использующая те же самые
протоколы TCP/IP что и Internet
 Ограничена для внутренних пользователей, как
правило, использованием использование
приватных адресов


Extranets

Intranet сеть, которая расширяется за пределы
организации, как правило, с использованием VPN
25
ПРИМЕР ДИАГРАММЫ СЕТИ
26
26
СРЕДА РАЗВЕРТЫВАНИЯ ИС

Среда развертывания объединяет анализ и
проектирование на основе
Аппаратного обеспечения – платформа
 Системное программное обеспечения
 Архитектура сети

Среда развертывания – окружение в которой
ИС будет функционировать (MS ACCESS, IISTomcat-Jboss, Java-C#, Spring, Seam,
Hibernate, Ruby on Rails, Python…)
 Используются шаблоны проектирования и
архитектуры промежуточного ПО (Framework)
для создания программного обеспечения
приложения (JSP-Forms, JavaEE, …)

27
АРХИТЕКТУРА СИСТЕМЫ



Вообще говоря, модели архитектур системы
обеспечивает высокий уровень моделей на основе
представления взаимодействующих частей,
образующих систему.
Моделируются подсистемы, интерфейсы, компоненты,
модули и правила взаимодействия между подсистемами
(моделируется множество структурных аспектов системы)
–(Модули (классы), Компоненты и коннекторы,
Размещение элементов системы)
Сложные в аппаратном и сетевом отношении системы
требуют более сложных моделей архитектур
28
РАЗНОВИДНОСТИ АРХИТЕКТУР
ПРИЛОЖЕНИЙ ИС

Существуют следующие широко используемые
подходы (pattern) для архитектуры приложения
Десктоповая архитектура
 Серверная архитектура
 Архитектура Client/server
 Трех-уровневая client/server архитектура
 Архитектура Web services
 Internet и Web-based архитектура
приложений

29
ФУНКЦИИ ПРИЛОЖЕНИЙ ИС
Презентационная логика (т.е.,
пользовательский интерфейс-HCI, )
 Логика приложения (обработка бизнеслогики)
 Логика доступа к базе данных (т.е.
обработка, требующая доступа к данным–
запрос SQL)
 База данных (т.е. файлы данных)
 Существует по крайней мере две альтернативы
для реализации архитектуры обработки:

30
Централизованные системы
Распределенные вычисления
30
ЦЕНТРАЛИЗОВАННЫЕ СИСТЕМЫ
31
• До 1970’s была только одна среда обработки– мэйнфрейм
компьютерная система в центре системы
• Варианты определялись разновидностью устройств вводавывода (например, клавишный перфоратор, система записи на
магнитную ленту или интерактивный ввод с видеотерминала), а
также возможность удаленного взаимодействия с устройствами
ввода-вывода
• Хотя в настоящее время мэйнфреймы не являются
предпочтительным платформами для применения ИС, они всееще широко используются как подсистемы больших, иногда
распределенных ИС или крупномасштабных приложений
пакетной обработки (например, банковские системы, страховые
системы, правительственные системы и т.п.), в которых:
– Нет необходимости обрабатывать транзакции в реальном
масштабе времени
– Персонал ввода данных должен быть централизован
– Системой производится большое количество периодических
31
выводов
Существует три типа централизованных систем : один
компьютер, кластер и мультисистемная архитектура
Архитектура на основе одного компьютера
• Все ресурсы ИС размещаются на одной компьютерной системе и
непосредственно соединенным к системе внешних устройствах
• Пользователи взаимодействуют с системой через терминалы,
подключенные к системе
• Требуется, чтобы все пользователи располагались в непосредственной
близости от компьютера
• Все 4 функциональные приложения реализуются на мэйнфрейме (сервер) –
серверная архитектура
Преимущества:
• Простота поддержки: относительно легко проектировать, строить и
эксплуатировать
Недостатки:
• Ограничения емкости делают непрактичной или неиспользуемой такую
архитектуру для больших ИС: не обеспечивается необходимый уровень
обработки, хранения данных и задач представления данных. Однако, многие
32
системы требуют большую мощность вычислений чем может обеспечить
один компьютер (требуется кластеризация или мультикомпьютерная
архитектура)
СЕРВЕРНАЯ АРХИТЕКТУРА
33
КОМПЬЮТЕР И МНОГОУРОВНЕВАЯ АРХИТЕКТУРА

Компьютерная архитектура из одного
компьютера
На основе мэйнфрейма
 Ограничена ресурсами одного компьютера


Кластерная и мультикомпьютерная архитектура
Группа компьютеров для обеспечения необходимой
мощности обработки и хранения данных
 Кластер действует как единая система (Кластеры:
отказоустойчивые- High-availability clusters -HA ,
сбалансированной нагрузки - Load balancing clusters,
вычислительные - HPC)
 Мультикомпьютерное аппаратное и системное
программное обеспечение отличаются от кластерного

34
КЛАСТЕРНАЯ АРХИТЕКТУРА
35
• Clustered architecture группа (или cluster) компьютеров
одного типа, на которых установлена аналогичная
операционная система и распределяются ресурсы
• Компьютеры одной модели и от одного производителя,
объединенные в сеть (как правило высокоскоростную)
• Программы приложения могут выполняться на любом
компьютере кластера без какой-либо модификации благодаря
аналогичному аппаратному и системному программному
обеспечению
• Кластер действует как одна большая компьютерная система
(перемещение программ и доступ к ресурсам других машин
осуществляется быстро и эффективно благодаря скоростному
и прямому взаимодействию на уровне операционной системы)
• Как правило один компьютер (master-управляющий)
35
действует как точка входа, а другие функционируют как
подчиненные (slave) компьютеры
Мультикомпьютерная архитектура
• Мультикомпьютерная архитектура – группа различных компьютеров,
которые связаны друг с другом, но не требуется, чтобы платформа и
операционная система были аналогичными как в кластерной архитектуре
• Аппаратное и программное обеспечение не позволяет перемещать
программы между компьютерами (вместо этого, ресурсы закрепляются за
каждой компьютерной системой)
• Система функционирует как одна большая компьютерная система
• Может иметь центральный компьютер и подчиненные компьютеры
–Главный компьютер может выполнять программы и поддерживать базу
данных
–Коммуникационный компьютер может управлять всеми
коммуникациями с другими компьютерами и простыми терминалами
Замечания по централизованным системам
• Кластерная система может быть экономически более эффективна и
обеспечивать большие общие возможности если используются аналогичные
операционные системы и аппаратное обеспечение
• Мультикомпьютерные архитектуры хороши, когда централизованная
система может быть декомпозирована на относительно независимые
36
подсистемы (для каждой возможна собственная ОС и аппаратная
платформа)
АРХИТЕКТУРЫ
С ОДНИМ КОМПЬЮТЕРОМ,
КЛАСТЕР И НЕСКОЛЬКО КОМПЬЮТЕРОВ
37
37
РАСПРЕДЕЛЕННАЯ АРХИТЕКТУРА
Система распределяется между
несколькими компьютерами,
установленными в различных местах–
распределенные вычисления
 Основывается на сетевых коммуникациях
для обеспечения связности
 Client/server архитектура является
преобладающей моделью для
распределенных вычислений

38
38
ПРОМЕЖУТОЧНОЕ ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ (MIDDLEWARE)
Аспект распределенного приложения
 Расширяет функциональность систем
программирования, позволяет объединять части
приложения и обеспечивает передачу запросов и
данных между ними
 Отслеживает обработку транзакций, вызовы
программ через сеть (object request brokersORB), каталог Web сервисов и мн. мн. другое
 Проектировщики применяют стандартный набор
компонент и протоколов, объединенных в
промежуточное ПО (J2EE, JavaEE, .NET 2.0, 3.0,
3.5)

39
CLIENT/SERVER АРХИТЕКТУРА

40
Предпочтительная модель архитектуры для распределения
ресурсов
• Двух-уровневая архитектура делит процессы ИС на два
класса:
– Server: управляет ресурсами системы и обеспечивает
доступ к этим ресурсам с других компьютеров сети
– Client computer: использует коммуникационный
интерфейс для запроса сервисов с других компьютерах сети
• Программное обеспечение, которое реализует
коммуникационный протокол в сети называется
промежуточным (middleware)
Преимущества– гибкость развертывания
Размещение, масштабируемость, сопровождение

Недостатки– сложность
Производительность, безопасность и надежность
40
ВЗАИМОДЕЙСТВИЕ НЕСКОЛЬКИХ
КЛИЕНТОВ С ОДНИМ СЕРВЕРОМ
41
41
«ТОЛСТЫЙ КЛИЕНТ»
И
«ТОЛСТЫЙ СЕРВЕР»
42
42
ТРЕХ-УРОВНЕВАЯ АРХИТЕКТУРАCLIENT/SERVER
• Уровень данных (data layer) конфигурации клиент-сервера,
который управляет хранением данных, реализованных как одна
или несколько баз данных
• Уровень бизнес-логики (business logic) содержит программы,
которые реализуют правила и процедуры обработки бизнеса (или
программная логика приложения)
• Уровень презентации (view layer) содержит пользовательский
интерфейс и другие компоненты для доступа к системе
(принимает ввод пользователя, а также формирует и представляет
обработанные результаты)
43
• Этот подход называется Трех-уровневая архитектура (tree-layer
architecture)
 ИС, разделенная на три уровня относительно легко
распределяется и реплицируется в сети (взаимодействие между
уровнями всегда выполняется в форме запрос или ответ)
 Репликация - Механизм синхронизации содержимого нескольких
копий объекта (обычно таблицы). Изменения, сделанные в любой
из копий объекта, могут быть распространены во все копии
43
 Это делает относительно независимыми уровни, и таким образом,
они могут помещаться на различные компьютеры системы с
сетевой связностью и поддержкой промежуточного ПО
Трех-уровневая архитектура
44
ФУНКЦИИ ТРЕХ-УРОВНЕВОГО
ПРИЛОЖЕНИЯ
45
N-уровневая архитектура
Когда сложные требования обработки или ресурсов данных, то
трех-уровневая архитектура может быть расширена на большее
количество уровней (n-layer или n-tiered architecture)
Следующий слайд показывает пример в котором уровень данных
разделен на отдельные уровни: объединенный сервер и сервера,
которые контролируют отдельные базы данных (marketing,
production, accounting).
Уровень бизнес-логики взаимодействует с объединенным
сервером баз данных, который обеспечивает унифицированное
представление, данных, сохраненных в нескольких различных базах
данных.
Ответы от отдельных серверов баз данных объединяются для
создания одного ответа, который посылается на уровень бизнеслогики.
46
N-уровневая архитектура
47
4-Х УРОВНЕВАЯ АРХИТЕКТУРА
48
АРХИТЕКТУРА ПРИЛОЖЕНИЙ НА ОСНОВЕ
WEB
Обычно используются Web-протоколы и браузеры в
качестве клиентских приложений
 Достоинства

Доступность клиентского ПО
 Низкая стоимость связи (используется развитая сеть Internet)
 Широко распространенные стандарты
 Отсутствие необходимости или автоматизация
распространения компонентов системы


Недостатки
Бреши в безопасности
 Изменение параметров надежности сети – зависимость от
связности узлов сети
 Пропускная способность может быть ограничена
 Изменяющиеся стандарты сети передачи данных

49
АРХИТЕКТУРА WEB-СЕРВИСОВ
Клиент/серверная архитектура
 «Упаковывает» программную
функциональность в серверные процессы
(“сервисы”)
 Делает сервисы доступными приложениям
через Web протоколы (http) на основе TCP/IP
 Web-сервисы доступны как внутренним так и
внешним приложениям


Разработчики могут создавать приложения,
используя существующие Web-сервисы
50
АРХИТЕКТУРА WEB СЕРВИСОВ

Universal Description,
Discovery, and Integration
(UDDI)

Web Service Definition
Language (WSDL)

Simple Object Access Protocol
(SOAP
)
51
ПРОЕКТИРОВАНИЕ МОДУЛЬНОЙ СТРУКТУРЫ
Цель проектирования – создать правильный
проект, но правильных может быть много
 Найти наилучший из возможных проектов с
учетом ограничений и требований системы, а
также физической и социальной среды ее
функционирования.
 Один из критериев оценки проекта – модульность
 Система является модульной если существуют
отдельные модули, реализованные отдельно и
изменения одного модуля минимально
воздействуют на другие модули.
 Модифицируемость, понятность,
сопровождаемость – производные параметры.

52
СЦЕПЛЕНИЕ И СВЯЗНОСТЬ
 Один
из фундаментальных принципов
проектирования модулей (классов)
заключается в том, что большая система
должна быть расчленена на обозримые
(управляемые) элементы.
 Разделение системы на модули должно
быть выполнено таким образом, чтобы
модули были как можно более
независимы (критерий связностиcoupling), и чтобы каждый модуль
выполнял единственную (связанную с
общей задачей) функцию (критерий
сцепления- cohesion).
53
СВЯЗНОСТЬ- COUPLING
Уменьшение количества соединений между двумя
модулями приводит к уменьшению вероятности
появления “волнового эффекта” (ошибка в одном
модуле влияет на работу других модулей);
 Минимизация риска появления “эффекта ряби”
(внесение изменений, например, при исправлении
ошибки, приводит к появлению новых ошибок),
т.к. изменение влияет на минимальное количество
модулей;
 Чем меньше связность между модулями тем
меньше в процессе сопровождения системы
необходимости беспокоиться о внутренних деталях
других модулей;
 Упрощение системы для понимания, насколько

это возможно.
54
СВЯЗНОСТЬ
Задача – для уменьшения связности необходимо
уменьшать связи между модулями
 Количество связей увеличивается в зависимости от
сложности и неясности интерфейса между модулями
 Уменьшение связности может быть достигнуто за
счет комбинирования трех следующих способов

действий:
Удаления необязательных связей;
 Сокращение количества необходимых связей;
 Упрощение необходимых связей.

55
ТИПЫ




СВЯЗНОСТИ
На практике существуют три основных типа
сцепления, используемых системными
проектировщиками для связи модулей:
нормальная связность,
связность по общей области и
связность по содержимому.
56
НОРМАЛЬНАЯ




СВЯЗНОСТЬ
Два модуля А и В являются нормально
связанными, если
А вызывает В,
В возвращает управление А,
вся информация, передаваемая между А и В,
представляется значениями параметров при
вызове.
57
НОРМАЛЬНАЯ




СВЯЗНОСТЬ
Существует три типа нормальной связности:
Связность по данным (data coupling) ,
Связность по структуре (stamp coupling) ,
Связность по управлению (control coupling ).
58
СВЯЗНОСТЬ
ПО ДАННЫМ
Два модуля связаны по данным, если они
взаимодействуют посредством передачи
параметров и при этом каждый параметр
является элементарным информационным
объектом.
 В случае небольшого количества передаваемых
параметров связность по данным обладает
наилучшими характеристиками

59
СВЯЗНОСТЬ ПО СТРУКТУРЕ
Если один модуль посылает другому составной
информационный объект, т.е. объект, имеющий
внутреннюю структуру.
 Примером составного объекта может быть объект
Данные о клиенте, включающий в себе поля:
Название организации, Почтовый адрес, Номер
счета
 В случае необходимости передачи одного
значения не рекомендуется передавать всю
структуру

60
СВЯЗНОСТЬ ПО УПРАВЛЕНИЮ
 Если
один модуль посылает другому
информационный объект - флаг,
предназначенный для управления его
внутренней логикой.
Существует два типа флагов - описательный и
управляющий.
 Описательный флаг обычно описывает ситуацию,
которая произошла, и именуются с использованием
существительных и прилагательных: Конец файла,
Введенная кредитная карта.
 Управляющий флаг используется для
декларирования определенных действий в
вызываемом модуле и именуется с использованием
глаголов: Читать следующую запись, Установить в
начало.
 В общем случае управляющие флаги усиливают
связность, следовательно, ухудшают качество 61
системы.

НЕНОРМАЛЬНАЯ СВЯЗНОСТЬ
 Два
модуля являются связанными по
общей области (common coupling), если
они ссылаются к одной и той же области
глобальных данных. Связность по
общей области является плохой.
 Ошибка в любом модуле, использующем
глобальную область, может неожиданно
проявить себя в любом другом модуле.
 Программы с большим количеством
глобальных данных чрезвычайно трудны
для понимания.
62
НЕНОРМАЛЬНАЯ
СВЯЗНОСТЬ
Два модуля являются связанными по содержимому
(content coupling), если один ссылается внутрь
другого любым способом, например, если один
модуль передает управление или выполняет
переход в другой модуль, или если один модуль
ссылается (или изменяет) значения
информационных объектов в другом модуле или
если один модуль изменяет код другого модуля.
 Такая связность делает абсурдной концепцию
модулей как черных ящиков, поскольку оно
вынуждает один модуль знать о точном
содержании и реализации другого модуля. Вообще
говоря, только ассемблер позволяет
проектировщикам применять данный вид
63
связности.

СЦЕПЛЕНИЕ- COHESION

Сцепление- это мера прочности соединения
функциональных и информационных элементов
внутри одного модуля. Размещение сильно
сцепленных объектов в одном и том же
модуле уменьшает межмодульные
взаимосвязи и взаимовлияния. Выделяются
следующие уровни сцепления:
Функциональное,
Последовательное,
Информационное (коммуникационная),
Процедурное,
Временное,
Логическое
и случайное (для полноты).
64
ФУНКЦИОНАЛЬНОЕ
 Функционально
сцепленный модуль содержит
объекты, предназначенные для выполнения
одной и только одной задачи, например:
Расчет заработанной платы, Считывание
данных кредитной карты. Каждый из таких
модулей имеет одну четко определенную цель,
при его вызове выполняется только одна
задача (при этом она выполняется полностью
без выполнения любого другого
дополнительного действия).
65
 Это самый высокий уровень сцепления и
повторного использования.
ПОСЛЕДОВАТЕЛЬНОЕ СЦЕПЛЕНИЕ
Модуль имеет последовательное сцепление, если
его объекты охватывают подзадачи, для которых
выходные данные одной из подзадач служат
входными данными для следующей подзадачи.
 Например, получить заказ, редактировать заказ,
передать заказ на склад для доставки, выставить
счет для оплаты.
 Такой тип модуля не содержит серьезных проблем
связности и сцепления, которые могут ухудшить
сопровождение, однако, поскольку несколько
функций включены в один модуль, то повторное
использование такого модуля невозможно.

66
ИНФОРМАЦИОННОЕ (КОММУНИКАЦИОННОЕ)
 Информационно
сцепленный модуль
содержит объекты, использующие одни и те
же входные или выходные данные.
Предположим, что мы хотим выяснить
некоторые сведения о книге, зная ее ISBN:
название книги, ее автора и цену. Эти три
подзадачи являются связанными потому,
что все они работают с одним и тем же
входным информационным объектом ISBN, который и делает этот модуль
информационно связным.
 Такое сцепление более приемлемо чем
последующие
67
ПРОЦЕДУРНОЕ
 Процедурно
сцепленный модуль является
модулем, объекты которого включены в
различные (и возможно несвязные)
подзадачи, в которых управление
переходит от каждой подзадачи к
последующей (в последовательно
сцепленном модуле данные, а не
управление, переходили от одной
подзадачи к последующей). Примером
процедурно сцепленного модуля может
служить цикл или цепочка принятия
решения, которая является общей для
нескольких процедур.
 Содержит только часть полной функции
или часть нескольких функций
68
ВРЕМЕННОЕ
СЦЕПЛЕНИЕ
Временно сцепленным является модуль,
объекты которого включены в подзадачи,
связанные временем исполнения.
 Модули, которые выполняют действия такие
как “initialization”, “cleanup,” и “termination”
обычно связаны временем.
 Имеют большое сцепление, чем логическое, т.к.
отсутствует необходимость в передачи флага
управления и код такого модуля обычно
проще.

69
ЛОГИЧЕСКОЕ СЦЕПЛЕНИЕ

Модулем с логическим сцеплением является
модуль, объекты которого содействуют решению
одной общей подзадачи, для которой эти объекты
отобраны во внешнем по отношению к модулю
мире. Например, модуль может выполнять
следующие задачи:
1. Ввод
записи
2. Вывод записи
Логически сцепленный модуль содержит
некоторое количество подзадач (действий) одного и
того же общего вида.
 Необходимо передавать флаг управления для
выбора операции, что является «плохим» способом
связности
70
 Надо избегать логическую сцепление, если
возможно

СРАВНИТЕЛЬНАЯ ТАБЛИЦА ВИДОВ
СВЯЗНОСТИ
71
СТРУКТУРНЫЕ

СХЕМЫ
(STRUCTURE CHARTS)
Основной инструментарий, используемый для
структурного проектирования – структурная схема.
 Структурные схемы используются для
графического изображения проекта модулей
программы.
В частности, они показывают как программы
разделены на меньшие модули, иерархию и
организацию этих модулей и интерфейс
взаимодействия между ними.
 Структурные схемы, однако, не показывают
внутренние процедуры, выполняемые модулем
или внутренние данные, используемые модулем.
Для описания процедур на этапе
проектирования создаюся блок-схемы.

72
СТРУКТУРНЫЕ СХЕМЫ
Модули структурной схемы изображаются
поименованными прямоугольниками.
 Предполагается, что модули структурной
схемы выполняются сверху вниз, слева
направо.
 Дуга, окружающая линию (представляющую
вызов модуля) означает, что модуль выполняет
итеративные вызовы.
 Ромб внизу модуля означает, что модуль
вызывает один и только один раз другой
модуль нижнего уровня, который соединен с
ромбом.
 Программные модули взаимодействуют друг с
73
другом, передавая данные.

СТРУКТУРНЫЕ
СХЕМЫ
Программы могут также
взаимодействовать друг с другом
передавая сообщения или
управляющие программы, называемые
флаги(flags).
 Библиотеки модулей изображаются как
прямоугольники, содержащие
вертикальные линии с каждой стороны.

74
ПРИМЕР
СТРУКТУРНОЙ СХЕМЫ
75
ДИАГРАММА ПОТОКА ДАННЫХ
ПРОГРАММ




Структурное проектирование требует, чтобы DFD
сначала была модифицирована для программ.
Процессы, появляющиеся на элементарных
логических диаграммах DFD могут представлять
модули на структурной диаграмме.
Логические DFD следует пересмотреть, чтобы они
показывали больше деталей для использования
программистами
Может быть необходим следующий пересмотр:
 Процессы, появляющиеся в DFD должны
выполнять одну функцию.
 Должны быть добавлены процессы для
управления доступом данных и
сопровождением.
 DFD должны быть пересмотрены для включения
средств обнаружения и обработки ошибок и
процессов реализации внутренних элементов
управления.
76
ПОЛЬЗОВАТЕЛЬСКИЙ
ИНТЕРФЕЙС
Пользовательский интерфейс - средство
взаимодействия пользователя с
информационной системой
 Два основных типа взаимодействия:

Ввод (Inputs)
 Представление (Outputs)

77
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКОГО
ИНТЕРФЕЙСА
 Основные
цели проектирования
Производительность
 Эффективность
 Обеспечение соответствующей обратной связи
 Легкоcть освоения
 Удобство применения

78
ВАРИАНТЫ
Вариант
взаимодействия
Прямое
манипулирование
Выбор из меню
ВЗАИМОДЕЙСТВИЯ
Основные преимущества
Основные недостатки
Примеры
приложений
Быстрое и интуитивно понятное
взаимодействие. Легок в изучении
Сложная реализация.
Подходит только там,
где есть зрительный
образ задач и объектов
Видеоигры,
системы
автоматического
проектирования
Сокращение количества ошибок
пользователя.
Минимальный ввод с клавиатуры.
Медленный вариант для
опытных пользователей.
Главным образом
Может быть сложным,
системы общего
если меню состоит из
назначения
большого количества
вложенных пунктов.
Заполнение форм
Простой ввод данных.
Легок в изучении
Занимает пространство
на экране.
Системы
управления
запасами,
обработка
финансовой
информации.
Командный язык
Мощный и гибкий, удобен
профессионалам
Труден в изучении.
Сложно предотвратить
ошибки ввода.
ОС,
библиотечные
системы.
Естественный язык
Подходит неопытным
пользователям.
Легко настраивается.
Требует большого
ручного набора
Системы
расписания,
системы хранения
данных WWW
79
ПРИНЦИПЫ
ПРОЕКТИРОВАНИЯ ИНТЕРФЕЙСА
Принцип
Описание
Учет знаний
пользователя
В интерфейсе необходимо использовать термины и понятия,
взятые из опыта будущих пользователей системы.
Интерфейс должен быть согласованным в том смысле, что
Согласованность однотипные (но различные) операции должны выполняться
одним и тем, же способом.
Минимум
Поведение системы должно быть прогнозируемым.
неожиданностей
Руководство
пользователя
Интерфейс должен предоставлять необходимую информацию в
случае ошибок пользователя и поддерживать средства
контекстно-зависимой справки
Учёт
разнородности
пользователей
В интерфейсе должны быть средства для удобного
взаимодействия с пользователями, имеющий разный уровень
квалификации и различные возможности
80
ПРОЕКТИРОВАНИЕ
ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Хороший интерфейс обеспечивает
соответствующую обратную связь, улучшает
производительность; он легок в использовании,
поддержке, изучении, а также обеспечивает
оперативную помощь. Кроме того, хороший
интерфейс никогда не «зависает», обеспечивая,
как минимум, понятный выход из любой
операции.
 Для разработки успешного диалога необходимо:

Составить план диалога (STD-диаграмма)
 Выполнить прототипирование диалога и
интерфейса
 Проверить интерфейс «на пользователях»

81
Раскладка
форм для
продажи
видео
82
СТРУКТУРА ИНТЕРФЕЙСА (STD)
83
ТАБЛИЦА
ЭЛЕМЕНТОВ
УПРАВЛЕНИЯ
84
ИНТЕРФЕЙСЫ ВЫВОДА

Варианты вывода


Экраны, принтеры, звук, CD-ROM, DVD, факс, e-mail и
Web страницы, XML, SOAP
Цели проектирования интерфейса вывода






Преследует намеченные цели
 Предлагает пользователям ожидаемую информацию
Приспособлен для пользователя
 Предлагает пользователям необходимые
информацию и взаимодействие (продвинутый,
рядовой, конечный пользователь)
Предоставляет соответствующее количество
 Не слишком много и не слишком мало
Предоставляет в необходимое место
 Соответствующим людям
Предоставляется во время
 Когда это необходимо
Используется соответствующий метод вывода
(таблицы, графики и ..)
85
ИНТЕРФЕЙСЫ ВЫВОДА
 Соответствие
содержания вывода
задачам означает:

Функция определяет форму


От того, что предполагается делать в выходом,
зависит вид формы (Экран-печать-…)
Содержимое для внешнего или внутреннего
использования

Выход для внешнего использования может
требовать совершенно иного представления по
сравнению с внутренним использованием.
86
ИНТЕРФЕЙСЫ ВЫВОДА
 Проектирование отчетов (reports)


Отчет должен обеспечивать пользователя всей
необходимой информацией в удобном формате (по
форме и по содержанию)
В настоящее время доступны различные ПО
«оформители отчетов», которые облегчают
проектирование и управление отчетами,
например, Crystal reports
 Улучшение

качества печати
Расположение страницы
Заголовок, итоги страницы, нумерация страниц,
дата
 Документирование вывода. (Ответственный за отчет)
 Стиль представления – хорошо смотрится и легко
читается
 Точность данных и информации – свободен от

87
ИНТЕРФЕЙСЫ ВЫВОДА

Принципы проектирования экранного вывода

Простота


Выполнять совместимое представление


Делать навигацию максимально простой, используя
кнопки и иконки
Создавать привлекательный экран


Не представлять новый интерфейс для каждой страницы,
это может лишь сбивать с толку и пользователи сбиваются
Помогать пользователям перемещаться по экрану


Не слишком загроможденные, понятные инструкции,
хорошо именованные элементы управления.
Привлекательный экран проще используется, особенно
если он также эффективный и удовлетворяет требованиям
пользователей
Эти принципы применяются ко всем выходным
экранам, включая web страницы, и к входным
экранам.
88
ИНТЕРФЕЙСЫ ВВОДА

Цели проектирования входного интерфейса






Легкость использования
Эффективность
Точность
Привлекательность
Простота
Логичность
Учет человеческого фактора в значительной
степени определяет успех системы.
 Технологии могут изменяться, но основные
человеческие требования не меняются и
аналитики должны помнить об этом все
время.

89
СПЕЦИФИКА ПРОБЛЕМ ПРОЕКТИРОВАНИЯ
ВВОДА ДАННЫХ
Ввод данных в том же порядке, в котором
они появляются на исходном документе;
 Минимизация ввода данных (например,
автоматический вывод названия по номеру
счета или табельного номера по фамилии
работника);
 Заполнение слева направо и сверху вниз;
 Ограниченное количество данных в одном
кадре;
 Автоматическая проверка правильности
ввода (например, сверка почтового индекса и
названия города) и т.д.
 Группирование связанных элементов
управления (рамкой или цветом)

90
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Тон и терминология (стиль)
 Использовать простые грамматически
корректные выражения
 Не стараться быть забавным
 Не быть снисходительным
 Использовать понятную терминологию
Избегать компьютерного жаргона
 Избегать аббревиатур
 Использовать простые термины
 Использовать непротиворечивые термины

91
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Принципы создания стиля
 Ограничиваться 4 гармоничными цветами
 Ограничения шрифтов до 2, 4 размера

Убедиться, что все читаемо
Заключать в рамки группы связанных элементов
 Ограничить аудио, если звук вообще добавляется

92
ВХОДНЫЕ ИНТЕРФЕЙСЫ
Осведомлять пользователей о последующих
действиях
 Использовать логичное расположение
 Ограничиваться одной целью на зону или
страницу
 Показывать сообщения достаточной для
прочтения длины
 Разумно использовать атрибуты дисплея
(разрешение, например, 800Х600->1024Х768)
 Использовать горячие клавиши для общих
функций
 Определять значения по умолчанию, если
возможно
 Предупреждать общие ошибки

93
ПРОЕКТИРОВАНИЕ
ИНТЕРФЕЙСА
Памятка
 Знать своих пользователей
 Знать требования ваших пользователей
 Предлагать пользователям прототип
интерфейса
 Обеспечивайте простоту
 Используйте понятное расположение
 Будьте последовательны
 Обеспечивайте полезные сообщения
 Приспосабливайте интерфейс для основного
типа пользователей
94
ФАЙЛЫ И БАЗЫ ДАННЫХ
Файл набор однотипных записей.
База данных набор взаимосвязанных файлов (в
том смысле, что записи одного файла физически
связаны с записями другого файла).
95
ФАЙЛЫ И БАЗЫ ДАННЫХ
Information
System
File
File
Information
System
File
File
Information
System
Database
(consolidated
& integrated
data from files)
Information
System
Information
System
96
ЗА И ПРОТИВ ФАЙЛОВ
Против
За
 Легко
 Сложнее
адаптируется для
проектировать
распределения
поскольку
между
ориентируются на
приложениями
одно приложение  Сложнее
адаптируется к
 Высокая
производительность новым требованиям
 Требует
благодаря
дублирования
организации для
97
атрибутов
в
одного приложения
нескольких файлах.
ЗА И ПРОТИВ Б.Д
За
Против
Способность разделять
 Сложнее адаптировать к
данные между
разделению данных
приложениями
между приложениями
 Сокращение и управление  Сложнее адаптировать к
избыточности
новым требованиям
 Независимость данных
 Требует дублирования
увеличивает адаптивность атрибутов в нескольких
файлах
 Отличная
масштабируемость и
 Отчасти меньше
разграничение доступа
производительность
 Язык SQL для доступа к
 Выше стоимость
базам
разработки
 Встроенные средства
 Выше уязвимость данных98
резервирования и
репликации данных

АДМИНИСТРАТОРЫ
Администратор
данных отвечает за планирование,
определение, архитектуру и управление данных.
Один или более администраторов баз данных
отвечают за технологию баз данных, проектирование и
построение баз данных, безопасность, сохранение и
восстановление, а также за обеспечение
производительности.
99
АРХИТЕКТУРА БАЗЫ ДАННЫХ
Архитектура базы данных относится к технологиям баз
данных, включая процессор базы данных(database engine),
утилиты баз данных, CASE средства и средства разработки
баз данных.
Система управления базы данных (СУБД - DBMS)
специализированное ПО, используемое для создания,
доступа, контроля и управления , базы данных. Ядро СУБД процессор базы данных (Engine).
 Язык определения данных(data definition language DDL) – часть процессора базы данных,
используемая для физического определения
таблиц, полей и связей.
 Язык манипулирования данных (data manipulation
language - DML) часть процессора базы данных,
используемая для создания, чтения, замены и
100
удаления записей в базе данных и перемещения между
различными файлами (таблицами) в базе данных.
ТИПИЧНАЯ АРХИТЕКТУРА DBMS
Системный аналитик
и
Дизайнер базы данных
Программист
Конечные
Пользователи
Приложения или
Query tools
Монитор
Обработки транзакций(TP)
DBMS
Data Definition
Language (DDL)
Собственный язык
и Tools
Data Manipulation
Language (DML)
DATABASE ENGINE
METADATA
USER
DATA
101

Многие СУБД обеспечивают монитор
обработки транзакций (transaction
processing monitor или TP monitor), который
управляет доступом к базе данных в реальном
времени и обеспечивает, чтобы транзакции,
воздействующие на несколько таблиц
обрабатывались как единое целое.
102
РЕЛЯЦИОННАЯ БАЗА ДАННЫХ
Реляционная база данных реализует сохраненные
данные набором двумерных таблиц, которые
связываются через внешние ключи.
 Физическая модель называется схемой.
 Языки DDL и DML для реляционных баз данных
называются SQL (Structured Query Language).
 Триггеры (Triggers) – программы, встроенные в
таблицы, которые автоматически вызываются
изменениями в других таблицах (изменение,
дополнение, удаление,…).
 Сохраненные процедуры (Stored procedures)
программы, встроенные в таблицы, которые доступны
из приложений (MS SQL – язык Transact-SQL, Oracle
– язык PL/SQL).
103
 Обычно используются для проверки данных или
управление доступом.
ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ
104
ФИЗИЧЕСКАЯ МОДЕЛЬ (РЕЛЯЦИОННАЯ СХЕМА)
105
ЦЕЛИ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ
 База
данных должна обеспечить
эффективное хранение, корректировку и
извлечение данных.
 База данных должна быть надежной—
хранимые данные должны иметь
высокую степень интеграции и
способствовать доверию пользователей
этим данным.
 База данных должна быть адаптивной и
масштабируемой для новых и
непредусмотренных требований и
приложений
106
МЕТОД ПРОЕКТИРОВАНИЯ Б.Д.
1.
2.
3.
4.
5.
6.
7.
8.
Создать таблицу для каждой сущности.
Создать поля для каждого атрибута.
Создать индекс для каждого первичного и
альтернативного ключей.
Создать индекс для каждого группового критерия.
Назначить внешние ключи для связей.
Определить типы, размеры, область допустимых
значений, NULL, значение по умолчанию для
каждого атрибута.
Создайте и объедините таблицы для реализации
структур категоризации.
Оцените и определите ограничения целостности
107
данных (referential integrity constraints).
ЦЕЛОСТНОСТЬ БАЗЫ ДАННЫХ
Целостность ключей - уникальность
 Доменная целостность – значения атрибутов из
ОДЗ.
 Ссылочная целостность-соответствие между
связанными таблицами
Ошибки ссылочной целостности
(referential integrity) возникают, когда
значение внешнего ключа в одной таблице не
совпадает со значением первичного ключа в
связанной таблице.
 Нет ограничений (No restriction)
 Каскадное удаление (Delete: cascade)
 Ограниченное удаление (Delete: restrict)
 Удаление с обнулением (Delete: set null)

108
ПРИМЕР ОПРЕДЕЛЕНИЯ ЦЕЛОСТНОСТИ
create table orders
( ...
,customer_id integer not null
,foreign key (customer_id)
references customers (id)
on update cascade
on delete restrict
, ... )
109
ПРОТОТИПЫ БАЗЫ ДАННЫХ
Прототип не является альтернативой
тщательно продуманной схемы базы данных.
 С другой стороны, как только схема завершена,
прототип базы данных обычно может быть
получен очень быстро.
 Большинство современных СУБД включают
мощные генераторы баз данных, которые
создают скрипт DDL, на основе которого
создается прототип базы данных.


Затем база данных может быть загружена
тестовыми данными, которые будут
способствовать прототипированию и
тестированию входов, выходов, экранов и других
компонентов системы.
110
ПРИМЕР SQL ИЗ DESIGN/IDEF
CREATE TABLE STUDENT
(
soc_sec_no CHAR(18) NOT NULL,
student_name
CHAR(18),
student_address
CHAR(18)
);
CREATE UNIQUE INDEX IXSTUDENT ON STUDENT
(
soc_sec_no ASC
);
CREATE TABLE ENROLLMENT
(
date_enrolled
CHAR(18),
…..
111
ПЛАНИРОВАНИЕ ОБЪЕМА Б.Д.

База данных хранится на диске и
Администратору б.д. необходимо оценить объем
дискового пространства для новой базы данных
для обеспечения достаточного объема.

Простая процедура вычисления объема
состоит в следующем:
1. Для каждой таблицы суммируется размер
полей в байтах.

Это размер записи в таблице.
2. Для каждой таблицы, умножается размер
записи (record size) на количество
экземпляров сущности, содержащихся в
таблице.

Это размер таблицы.
112
ПЛАНИРОВАНИЕ ОБЪЕМА Б.Д.
3. Просуммируйте размеры таблиц.

Это размер базы данных (database size).
4. По возможности, добавьте
дополнительный буфер (например, 1015 %) для учета непредвиденных
факторов или неточностей оценки.

Это ожидаемой емкости д.б.
113
РАСПРЕДЕЛЕНИЕ И РЕПЛИКАЦИЯ
Анализ распределения данных
устанавливает места необходимого доступа
для различных логических элементов
данных.

Анализ определяется решениями типа
распределения:
Централизованное
 Горизонтальное распределение – в различных
местах
 Вертикальное распределение – проблемная
ориентация
 Репликация – дублирование определенных
таблиц, записей и/или полей в несколько
физических баз данных

114
INDV
Customer
R
.Customer Number
RU
.Customer Name
RU
.Customer Address
X
.Customer Credit Rating
R
.Customer Balance Due
INDV
Order
SRD
.Order Number
SRD
.Order Date
SRD
.Order Amount
INDV
Ordered Product
SUD
.Quantity Ordered
.Ordered Item Unit Price SUD
ALL
Product
R
.Product Number
R
.Product Name
R
.Product Description
.Product Unit of Measure R
.Product Current Unit Price R
.Product Quantity on Hand X
R
R
R
ALL
R
R
R
ALL
R
R
ALL
CRUD
CRUD
CRUD
CRUD
CRUD
SS
R
R
CRUD
CRUD
CRUD
CRUD
CRUD
ALL
R
R
RU
R
R
SS
R
ALL
R
R
R
R
RU
INDV= индивидуально ALL= ALL
S = представлять
ALL
CRUD
CRUD
CRUD
R
R
ALL
CRUD
CRUD
CRUD
ALL
CRUD
CRUD
ALL
R
R
R
R
R
R
ALL
R
R
R
RU
RU
SS
CRUD
CRUD
CRUD
R
R
SS
CRUD
CRUD
CRUD
SS
CRUD
CRUD
ALL
R
R
R
R
R
R
R
R
R
R
R
SS = подмножество
C = создавать R = читать
SS
R
R
R
SS
R
R
R
SS
ALL
R
R
R
R
R
RU
X = нет доступа
U = изменять
D = удалять
SS
CRUD
CRUD
CRUD
R
R
SS
CRUD
CRUD
CRUD
SS
CRUD
CRUD
ALL
R
R
R
R
R
R
. Склад
Новокузнецк
. Продажи
Новосибирск
. Склад
. Продажи
Кемерово
.Бухгалтерия
. Продажи
. Склад
.Реклама
. Маркетинг
Томск
Entity . Attribute
Клиенты
Место
МАТРИЦА РАСПРЕДЕЛЕНИЯ ДАННЫХ CRUD
SS
R
R
R
SS
R
R
R
SS
ALL
R
R
R
R
R
RU
115
Download