
- •Методические указания
- •Технология разработки защищенных автоматизированных систем
- •Справочные данные по моделям нарушителей:
- •Информационный компонент системы
- •6.1.Концептуальная модель данных зас
- •6.2. Логическая модель данных
- •7.2 Описание пользовательского интерфейса
- •7.3. Описание программных модулей и форм:
- •Заключение
- •1. Требования к системе
- •1.1. Требование к системе в целом
- •1.2. Сзи должна оказывать противодействие след угрозам
- •3. Требования к видам обеспечения
- •Теоретические основы проектирования и разработки зас.
- •Алгоритм проектирования индивидуальных систем защиты
- •Потенциально возможные средства
Информационный компонент системы
6.1.Концептуальная модель данных зас
На
основе анализа предметной области и
постановки задачи строим концептуальную
модель
В данной схеме отражены информационные потоки между диспетчером и:
1) клиентом в виде данных о клиенте и заявки на сдачу или продажу;
2)потенциальным арендатором или покупателем в виде запроса;
3)бухгалтером в виде отчёта о заключённых сделках;
В результате отображения концептуальной модели на СУБД будет получена логическая модель.
6.2. Логическая модель данных
Логическая модель данных - это развёрнутая концептуальная модель данных, привязанная к конкретной предметной области. Она отражает объекты и атрибуты этих объектов. Логическая модель должна быть оптимизирована путём перегруппировки элементов данных, согласно поставленным задачам, избавления от избыточности данных, в реляционных системах устанавливаются отношения между сущностями. Так же логическую модель приводят к нормальной форме.
В представленной выше концептуальной модели можно выделить пять сущностей: заявка, клиент, диспетчер, маклер, сделки. На основании концептуальной модели необходимо построить логическую модель.
Для описания всех объектов предметной области необходимо определить атрибуты, свойственные данным сущностям (таблица 12). Таким образом мы привели таблицу ко второй нормальной форме, т.е. исключили повторяющиеся группы- для каждого набора связных атрибутов создали отдельную таблицу и снабдили её первичным ключом(Таблица 12)
Таблица 12.
Нормализованная логическая модель данных подсистемы защиты (рисунок 3):
Рисунок 3.
Физическая модель данных
Относящихся к ЗАС
Заявка (Заявка.dbf)
Таблица 13.
Клиенты (клиенты.dbf)
Т аблица 14.
Диспетчера (диспетчера.dbf)
Таблица 15.
Маклеры (маклеры.dbf)
Таблица 16.
Сделки (сделки.dbf)
Таблица 17.
Относящихся к СЗИ
Особо следует выделить таблицы подсистемы ЗИ:
adm.dbf - ТКП
Имя |
Тип |
Длина |
Uchet_nom |
Numeric |
5 |
Login |
Character |
10 |
Password |
Character |
10 |
Fio |
Character |
55 |
doljnost |
Character |
10 |
jur_reg.dbf – журнал входа \ выхода
Имя |
Тип |
Длина |
Uchet_nom |
Numeric |
5 |
Login |
Character |
10 |
Password |
Character |
10 |
Fio |
Character |
55 |
vxod |
Date |
8 |
exit |
Date |
8 |
nsd |
Character |
14 |
polnomoch.dbf - ТРП
Имя |
Тип |
Длина |
Doljnost |
Character |
10 |
Ank_dis |
Numeric |
2 |
Ank_kl |
Numeric |
2 |
Ank_mak |
Numeric |
2 |
Zaivka |
Numeric |
2 |
Sdelki |
Numeric |
2 |
Jur_reg |
Numeric |
2 |
tkp |
Numeric |
2 |
trp |
Numeric |
2 |
crcs |
Numeric |
2 |
crcs.dbf – Таблица контрольной суммы
Имя |
Тип |
Длина |
Tabl |
Character |
20 |
Summ |
Character |
254 |
etalon |
Character |
254 |
Разработка программного компонента системы
Описать современные методы программирования и создания приложений, проанализировав технологическую цепочку обработки информации и поставленные задачи, разработать алгоритм и представить структуру модулей приложения.
Далее указать методику разработки приложения по каждому модулю. В конце привести перечень всех разработанных модулей и их назначение.
Например,для АС «Недвижимость»
Рисунок 4.
При регистрации в системе пользователь осуществляет ввод Логина и Пароля в соответствующие поля регистрационной формы. Далее система осуществляет проверку КС всех функциональных таблиц и аутентификацию пользователя. Если имя указано неверно, то выдается соответствующее сообщение и заносится запись в журнал НСД. При указании неверного пароля система реагирует аналогично. Но при 3-кратном вводе неверного пароля осуществляется блокировка уч. записи нарушителя с занесением этого факта в журнал НСД.
Если же аутентификация пройдена успешно, заносится запись в журнал регистрации входа/выхода и производится перерасчет КС для журналов и ТКП. Далее осуществляется загрузка главной формы системы и применение политики безопасности. Дальнейшая работа системы сводится к реализации учетно-статистических функций( ввод и модификация данных, участвующих в информационных потоках отдела комплектации). При любой санкционированной модификации выполняются процедуры расшифрования / зашифрования данных, а также перерасчет КС для них.
Возможны 2 варианта завершения работы с системой: смена пользователя (повторная регистрация под другим именем) и выход из системы(при котором осуществляется проверка КС).