- •А.1. Стратегический анализ бизнес-процессов
- •А.1.1. Моделирование стратегических бизнес-процессов
- •А.1.2.Promet
- •А.1.3. Другие методы стратегического моделирования бизнес-процессов
- •А.2. Моделирование на разных уровнях представленияAris а.2.1. Моделирование на уровне функционального представления
- •А.2.1.1. Определение требований на уровне функциональной модели
- •А.2.1.1.1. Структура функций
- •А.2.1.1.2. Последовательности процедур
- •А.2.1.1.3. Типы обработки
- •А.2.1.1.4. Модели решений
- •A.2.1.1.5. Объединение определения требований на уровне функциональной модели
- •А.2.1.2. Конфигурирование функций
- •А.2.1.3. Определение требований на уровне функциональной модели
- •А.2.1.3.1. Проектирование модулей
- •А.2.1.3.2. Мини-спецификация
- •А.2.1.3.3. Представление выхода
- •А.2.1.4. Реализация на уровне функциональной модели
- •А.2.2. Моделирование представления организации
- •А.2.2.1. Определение требований на уровне организационной модели
- •А.2.2.1.1. Организационные структуры (иерархические организации)
- •А.2.2.1.2. Ролевая концепция
- •А.2.2.2. Конфигурирование организационной структуры
- •А.2.2.3.Спецификация проекта на уровне организационной модели
- •А.2.2.3.1. Топология сети
- •А.2.2.3.2. Типы компонентов
- •А.2.2.4. Реализация на уровне организационной модели
- •А.2.3. Моделирование на уровне представления данных
- •А.2.3.1. Определение требований на уровне модели данных
- •А.2.3.1.1. Макроописание
- •А.2.3.1.2. Микроописания
- •А.2.3.2. Конфигурирование данных
- •А.2.3.3. Спецификация проекта в рамках модели данных
- •А.2.3.3.1. Создание отношений
- •А.2.3.3.2. Нормализация — денормализация
- •А.2.3.3.3. Условия целостности
- •А.2.3.3.4. Логические пути доступа
- •А.2.3.3.5. Схема базы данных
- •А.2.3.4. Реализация на уровне модели данных
- •А.2.4. Моделирование на уровне выходов
- •А.2.4.1. Определение требований на уровне модели выходов
- •А.2.4.2. Конфигурирование выходов
- •А.З. Моделирование отношений между разными типами представлений (модель управления)
- •А. 3.1. Отношения между функциями и организацией
- •А.З.1.1. Моделирование определения требований а.З.1.1.1. Диаграммы связи функция-организация
- •А.3.1.1.2. Диаграмма взаимодействия
- •А.3.1.2. Конфигурирование
- •А.3.1.3. Спецификация проекта
- •А.3.2. Отношения между функциями и данными
- •А.3.2.1. Моделирование определения требований а.3.2.1.1. Установление связей между функциями и данными а.3.2.1.1.1. Объектно-ориентированные диаграммы классов
- •А.3.2.1.1.2. Диаграммы привязки функций
- •А.3.2.1.1.3. Поток данных
- •А.3.2.1.1.4. Ассоциация экранов
- •А.3.2.1.2. Управление посредством событий и сообщений
- •А.3.2.1.2.1. Правило суд
- •A.3.2.1.2.2. Событийные диаграммы процессов (сдп)
- •А.3.2.1.2.3. Диаграммы состояний
- •А.3.2.1.2.4. Управление посредством сообщений
- •А.3.2.1.2.5. Связывание объектно-ориентированного моделирования и сдп
- •А.3.2.2. Конфигурирование
- •А.3.2.3. Спецификация проекта а.3.2.3.1. Связывание модулей с базами данных
- •А.3.2.3.1.1. Привязка схемы
- •А.3.2.3.1.2. Выведение структур управления
- •А.3.2.3.1.3. Транзакции баз данных
- •А.3.2.3.2. Управление посредством триггеров
- •А.3.2.3.3. Объектно-ориентированная спецификация проекта
- •А.3.2.3.3.1. Общая детализация
- •А.3.2.3.3.2. Связи с базами данных
- •А.3.2.4. Описание реализации
- •Void cirle::radius (int newradius)
- •А.3.3. Отношения между функциями и выходом
- •А.3.3.1. Моделирование на уровне определения требований
- •А.3.4. Отношения между организационной структурой и данными
- •А.3.4.1. Моделирование определения требований
- •А.3.4.2. Конфигурирование
- •А.3.4.3. Спецификация проекта а.3.4.3.1. Детализация полномочий
- •А.3.4.3.2. Распределенные базы данных
- •А.3.5. Отношения между организационной структурой и выходом
- •А.3.5.1. Моделирование определения требований
- •А.2.5.2. Конфигурирование
- •А.3.6. Отношения между данными и выходом
- •А.3.6.1. Моделирование определения требований
- •А.3.6.2. Конфигурирование
- •А.3.7. Объединение всех представленийAriSв полную модель
- •А.3.7.1. Моделирование определения требований
- •А.3.7.1.1. Модели процессов
- •А.3.7.1.2. Бизнес-объекты
- •А.3.7.2. Конфигурирование
- •А.3.7.2.1. Конфигурирование на базе моделей бизнес-процессов
- •А.3.7.2.2. Конфигурирование бизнес-объектов
- •А.3.7.3. Спецификация проекта
- •Б. Процедурные модели и приложенияAris
- •Б.1. Реализация стандартного программного обеспечения с помощью моделейAris
- •Б.1.1. Разрешение критических вопросов при управлении стандартным проектом
- •Б.1.2. Aris Quickstep for r/3
- •Б. 1.3.QuickstepforR/3: описание фаз реализацииSap
- •Б.1.4. Резюме
- •Б.2. Реализация системworkflowс помощью моделейAris
- •Б.2.1. Факторы успеха при реализации системworkflow
- •Б.2.2. Процедурная модельAriSдля реализацииworkflow
- •Б.З. Разработка систем на базе модели с использованием инфраструктурыArisFramework
- •Б.3.1. Общая процедурная модель
- •Б.3.2. Процедурная модель для моделирования целевых концепций
- •Б.4. Объектно-ориентированная разработка систем с помощью унифицированного языка моделирования (uml)
- •Б.4.1. Разработка и описание процедурных моделей
- •Б.4.2. Фазы процедурной модели
- •Б.4.3. Перспективы
А.3.4.3. Спецификация проекта а.3.4.3.1. Детализация полномочий
На стадии спецификации проекта выполняется дальнейшая детализация привилегий, присваиваемых пользователям для манипулирования данными. На рис. 141 вкратце представлены различные возможности определения привилегий доступа.
|
Пользователь |
Объекты базы данных | ||||
|
O1 |
O2 |
O3 |
|
On | |
|
U1
|
P1P2 |
|
P3 |
|
Pl |
|
U2 |
|
P1 |
P2P3 |
|
P1 |
|
U3 |
|
P1P2 |
P2 |
|
|
|
Un |
P1P2 |
Pl |
P1 |
|
PlPk |
Условные обозначения:
Ui: Пользователь
Oi: Объекты базы данных
Pi: Привилегии
Рис. 141. Таблица полномочий (Reuter. Sicherheits- und Integritatsbedingungen. 1987, с. 352)
К числу основных привилегий относятся чтение, создание, редактирование и удаление данных. Соответствующие объекты можно разбить на категории. Например, отношение можно рассматривать как объект, а объекты - как отдельные атрибуты, отдельные кортежи или комбинацию кортежей. Логические связи с содержанием данных можно использовать в качестве критериев выбора. Например, руководителям отделов можно разрешить читать личные дела сотрудников только своего отдела. Другой пример в том же прикладном контексте: можно предоставить сотруднику отдела управления персоналом право читать записи, относящиеся только к зарплате ниже определенного уровня.
Метаструктура такого детального представления большей частью согласуется с описанием на рис. 139.
Помимо прямой связи между ШТАТНОЙ ЕДИНИЦЕЙ и АССОЦИАЦИЕЙ ОБЩЕГО АТРИБУТА (см. рис. 139), можно установить косвенную связь, присвоив привилегии определенным паролям, а затем определенным пользователям. Это позволяет сделать описание менее избыточным, так как, например, два пользователя с одинаковым профилем привилегий получают одинаковые привилегии, обусловленные паролем. Эта метамодель показана на рис. 142.

Рис. 142. Метамодель описания полномочий
Механизм защиты можно описывать с помощью таблиц, где проверяется каждый ключевой запрос к базе данных. Реляционные базы данных CA-Ingres отличаются особой реализацией, описывающей правила присвоения привилегий в виде так называемых диапазонных условий. При выполнении запроса диапазоны условий и описание запроса группируются в инструкцию ЯМД (язык манипулирования данными) и, таким образом, обрабатываются в рамках одного и того же синтаксиса. Рис. 143 в пояснениях не нуждается.
|
Устная формулировка |
На ЯМД CA-lnores QUEL |
|
Устная формулировка |
|
|
Руководителю отдела Миллеру разрешается доступ к личным делам всех сотрудников его отдела D43. |
RANGE OF X IS EMPLOYEE RESTRICT ACCESS FOR ‘MILLER’ TO EMPLOYEE |
|
|
WHERE X.DEPT.MEMB='D43' |
|
Описание запроса |
|
|
Найти фамилии всех сотрудников с годовой зарплатой более 30 тыс. долл. |
RANGE OF X IS EMPLOYEE RETRIEVE INTO LIST (X.NAME) WHERE SALARY > 30,000 |
|
Скомпилированный запрос |
|
|
|
RANGE OF X IS EMPLOYEE RETRIEVE INTO LIST (X.NAME) WHERE SALARY > 30,000 AND X.DEPT.MEMB = 'D431 |
Рис. 143. Присвоение полномочий в QUEL (Renter. Sicherheits- und Integritatsbedingungen. 1987, c.361)
