Проектирование информационных систем

Проектирование
информационных
систем
к.т.н., доцент
Набатов Александр Нурович
6‐224
Введение
• Структура курса
• Требования
• Контроль
• Необходимость
• Требования
потребителей
• Что дают ПрИС
Лекция 1. Введение
Лекция 1. Введение
Жизненный цикл информационных
систем
• основные процессы ЖЦ ПО (приобретение,
поставка, разработка, эксплуатация,
сопровождение);
• вспомогательные процессы, обеспечивающие
выполнение основных процессов
(документирование, управление конфигурацией,
обеспечение качества, верификация, аттестация,
оценка, аудит, решение проблем);
• организационные процессы (управление
проектами, создание инфраструктуры проекта,
определение, оценка и улучшение самого ЖЦ,
обучение)
Лекция 1. Введение
Модели жизненного цикла ПО
Каскадная модель
Спиральная модель
Проектирование
Сопровождение
вер. 3 вер. 2
Разработка
вер. 1
Внедрение
Лекция 1. Введение
Понятие методологии
Методология проектирования ИС включает:
1) тесно связанные, предписанные конкретные
последовательности шагов;
2) перечень данных, подлежащих накоплению на
каждой стадии;
3) критерии завершения работ в контрольных
точках;
4) решения, принимаемые при выборе между
альтернативными методами проектирования;
5) конкретные стандарты построения
информационных систем.
Лекция 1. Введение
Роль методологии в
проектировании ИС
Методология обеспечивает:
1) организационную структуру, позволяющую
разработчикам функционировать
скоординированным образом;
2) использование общего терминологического
словаря;
3) использование общих методов разработки;
4) предсказуемость результатов;
5) контроль и согласованность действий.
Лекция 1. Введение
Основа проекта ИС
Методология
реализуется
через конкретные
методики и
технологии,
поддержанные
соответствующими
стандартами.
Инструментальн
ые средства
обеспечивают
выполнение
процессов
проектирования,
описанных в
методиках и
стандартах.
Лекция 1. Введение
Классификация методологий
 По подходу к автоматизации объекта:
–
–
методология восходящего проектирования (подход
«снизу‐вверх»), реализуемая путем поэтапной
разработки ИС собственными силами;
методология нисходящего проектирования (подход
«сверху‐вниз»), реализуемая путем покупки и
внедрения готовой ИС.
 По способу декомпозиции системы управления:
–
–
методология структурного проектирования
(функционально‐ориентированные);
методология объектно‐ориентированного
проектирования.
Лекция 1. Введение
•
•
•
•
•
Преимущества поэтапной разработки
собственными силами
относительно низкая стоимость;
несущественные изменения организационной
структуры;
максимальная ориентация на реализацию
бизнес‐процессов предприятия;
обеспечение значительно более высокого уровня
безопасности и независимости от внешних
факторов;
оперативная реакция на изменения внешней
среды.
Лекция 1. Введение
Условия применения
1. Правильный выбор архитектуры построения
вычислительно‐коммуникационной сети и
ориентация на профессиональные СУБД;
2. Использование современного инструментария;
3. Многозадачная инфраструктура разработки
проекта;
4. Применение эффективных организационно‐
технических средств по управлению проектом и
контролю версий ИС.
Лекция 1. Введение
Внедрение готовой ИС
Преимущества:
– модульный принцип внедрения;
– обеспечение целостности системы.
Условия применения:
– готовность и возможность предприятия
адаптировать свои бизнес‐процессы под
требования приобретаемой информационной
системы;
– готовность к единовременному вложению
больших финансовых средств.
Лекция 1. Введение
Сравнения методологий.
Преимущества и недостатки
Методология восходящего
проектирования
Разработка набора
приложений, наиболее
важных в данный момент для
поддержки деятельности
предприятия.
Методология нисходящего
проектирования
Разработка универсальной
системы, удовлетворяющей
потребности нескольких
предприятий
Достоинства
Хорошо обеспечивается
поддержка отдельных
функций, min затраты
ресурсов
Использование типовых
стандартных программных
средств автоматизации.
Недостатки


Цель

отсутствует стратегия
развития комплексной
системы автоматизации;
проблемы с
объединением
функциональных
подсистем.

сложности адаптации
системы под нужды
конкретного
предприятия;
высокие затраты на
адаптацию.
Лекция 1. Введение
Рекомендации к применению
• Методология восходящего проектирования
рекомендуется для организаций с узко
специфическими потребностями в
автоматизации, не нуждающихся в общем
совершенствовании процессов.
• Методология нисходящего проектирования
рекомендуется для относительно зрелых
организаций с устоявшимися бизнес‐
процессами, которые стремятся вложить все
необходимые ресурсы в полностью
законченную работу.
Лекция 1. Введение
Методологии и технологии
проектирования ИС
•
•
•
•
•
•
•
•
•
•
RUP
RAD
XP
FDD
Lean
Cleanroom SE
OpenUP
MSF
DSDM
TDD
Лекция 1. Введение
Способы декомпозиции системы
управления
• Объектная декомпозиция рассматривает
структуру объектов и связей между ними, а
также поведение системы в терминах
обмена сообщениями между объектами.
• Функциональная декомпозиция
рассматривает структуру системы в
терминах иерархии функций и передачи
информации при выполнении задач и
процедур.
Лекция 1. Введение
Сравнительный анализ методологий
проектирования
Функционально‐
ориентированная
Достоинства



Недостатки


Объектно‐ориентированная

реализация подхода к
проектированию ИС по
принципу «сверху‐вниз»;
процедурная строгость
декомпозиции ИС;

наглядность
представления.
объектно‐
ориентированные
системы более открыты
и легче поддаются
внесению изменений,
высокая степень
унификации разработки
и пригодность для
повторного
использования

независимость
процессов и данных друг 
от друга;

не всегда ясны условия
выполнения функций
сложность методологии;
высокие начальные
затраты;
сложность реализации
ИС
Лекция 1. Введение
Условия применения
• Объектно‐ориентированная методология
позволяет построить более устойчивую к
изменениям систему, лучше соответствует
существующим структурам организации.
• Функционально‐ориентированная
методология применяется в случаях, когда
организационная структура находится в
процессе формирования или изменения.
Лекция 2.
Принципы создания ИС.
Методологии проектирования.
Лекция 2. Принципы/Методологии
Принципы создания ИС
Принципы
создания ИС
Основные
Дополнительные
позволяют
получить
определенный
экономический
эффект
Организационнотехнологические
связаны с
особенностями
компьютерной
обработки
данных
Лекция 2 . Принципы/Методологии
Основные принципы создания ИС
• Принцип системности заключается в рассмотрении
системы как единого целого, позволяет выявить
многообразные типы связей между структурными
элементами, установить направления деятельности
системы и реализуемые функции.
• Принцип развития заключается в том, что ИС создается с
учетом возможности постоянного пополнения и
обновления функций системы.
• Принцип совместимости заключается в обеспечении
способности взаимодействия ИС различных видов,
уровней в процессе их совместного функционирования.
• Принцип стандартизации заключается в необходимости
применения типовых, унифицированных и
стандартизованных элементов.
• Принцип эффективности заключается в достижении
рационального соотношения между затратами на
создание ИС и эффектом, получаемым в результате
автоматизации.
Лекция 2 . Принципы/Методологии
«Открытый» подход к создания ИС
 Открытая система – это система, реализующая
открытые стандарты на интерфейсы, службы и
форматы данных, достаточные для обеспечения:
– мобильности (возможности переноса прикладных
систем с минимальными изменениями на широкий
диапазон программно‐аппаратных платформ);
– интероперабельности (совместной работы с другими
прикладными системами на локальных и удаленных
платформах);
– взаимодействия с пользователями в стиле,
облегчающем им переход от системы к системе
(мобильность пользователей).
 Открытый стандарт не зависит от конкретных
технических и программных средств отдельных
производителей.
Лекция 2 . Принципы/Методологии
Единое информационное пространство
складывается из следующих главных компонентов:
 информационных ресурсов, содержащих данные
и знания, зафиксированные на соответствующих
носителях;
 организационных структур, обеспечивающих
функционирование и развитие единого
информационного пространства – сбор,
обработку, хранение, поиск, распространение
информации;
 средств информационного взаимодействия
граждан и организаций, в том числе программно‐
технических средств и организационно‐
нормативных документов, обеспечивающих
доступ к информационным ресурсам.
Лекция 2 . Принципы/Методологии
Дополнительные принципы создания ИС
• Принцип декомпозиции – основан на разделении системы на
части, выделении отдельных комплексов работ.
• Принцип первого руководителя предполагает закрепление
ответственности при создании системы за заказчиком –
руководителем предприятия, который отвечает за ввод в
действие и функционирование ИС.
• Принцип новых задач – поиск постоянного расширения
возможностей системы, получение дополнительного эффекта
за счет оптимизации управленческих решений.
• Принцип автоматизации документооборота
предусматривает комплексное использование технических
средств на всех стадиях прохождения информации от сбора
до формирования управленческих решений.
• Принцип автоматизации проектирования повышает
эффективность самого процесса проектирования ИС за счет
применения типовых проектных решений, методов и средств
подготовки проектных материалов, стандартизации подходов
при проектировании отдельных элементов и подсистем.
Лекция 2 . Принципы/Методологии
Организационно‐технологические
принципы создания ИС
• Принцип абстрагирования заключается в
выделении существенных аспектов системы и
отвлечения от несущественных для
представления проблемы в более простом общем
виде, удобном для анализа и проектирования.
• Принцип формализации заключается в
применении формализованных методов
описания и моделирования изучаемых и
проектируемых процессов.
• Принцип концептуальной общности
заключается в неукоснительном следовании
единой методологии на всех этапах
проектирования ИС.
Лекция 2 . Принципы/Методологии
Организационно‐технологические
принципы создания ИС
• Принцип непротиворечивости и полноты заключается в
наличии всех необходимых элементов в проектируемой
системе и согласованном их взаимодействии.
• Принцип независимости данных предполагает, что модели
данных должны быть спроектированы независимо от
процессов их обработки, а также от их физической структуры
и распределения в технической среде.
• Принцип структурирования данных предусматривает
необходимость иерархической организации элементов
информационной базы.
• Принцип доступа конечного пользователя заключается в
том, что пользователь должен иметь средства доступа к
данным, которые он может использовать непосредственно
(без программирования).
Лекция 2 . Принципы/Методологии
Методологии проектирования
Проектирование
информационной
системы охватывает три основные области:
• проектирование объектов данных, которые будут
реализованы в базе данных;
• проектирование программ, экранных форм,
отчетов, которые будут обеспечивать выполнение
запросов к данным;
• учет конкретной среды или технологии, а именно:
топологии сети, конфигурации аппаратных
средств, используемой архитектуры (файл‐
сервер
или
клиент‐сервер),
параллельной
обработки, распределенной обработки данных и
т.п.
Лекция 2 . Принципы/Методологии
Методологии проектирования
Проектирование информационных систем всегда
начинается с определения цели проекта. В общем виде
цель проекта можно определить как решение ряда
взаимосвязанных задач, включающих в себя обеспечение
на момент запуска системы и в течение всего времени ее
эксплуатации:
• требуемой функциональности системы и уровня ее
адаптивности
к
изменяющимся
условиям
функционирования;
• требуемой пропускной способности системы;
• требуемого времени реакции системы на запрос;
• безотказной работы системы;
• необходимого уровня безопасности;
• простоты эксплуатации и поддержки системы.
Лекция 2 . Принципы/Методологии
Методологии проектирования
Процесс создания ИС делится на ряд этапов,
ограниченных некоторыми временными рамками и
заканчивающихся выпуском конкретного продукта
(моделей, программных продуктов, документации и
пр.).
Обычно выделяют следующие этапы создания ИС:
• формирование требований к системе,
• проектирование,
• реализация,
• тестирование,
• внедрение
Лекция 2 . Принципы/Методологии
Методологии проектирования
Начальным этапом процесса создания ИС является моделирование бизнес‐
процессов, протекающих в организации и реализующих ее цели и задачи. Модель
организации, описанная в терминах бизнес‐процессов и бизнес‐функций, позволяет
сформулировать основные требования к ИС. Это фундаментальное положение
методологии обеспечивает объективность в выработке требований к проектированию
системы. Множество моделей описания требований к ИС затем преобразуется в
систему моделей, описывающих концептуальный проект ИС. Формируются модели
архитектуры ИС, требований к программному обеспечению (ПО) и информационному
обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются
корпоративные БД и отдельные приложения, формируются модели требований к
приложениям и проводится их разработка, тестирование и интеграция.
Целью начальных этапов создания ИС, выполняемых на стадии анализа
деятельности организации, является формирование требований к ИС, корректно и
точно отражающих цели и задачи организации‐заказчика. Чтобы специфицировать
процесс создания ИС, отвечающей потребностям организации, нужно выяснить и четко
сформулировать, в чем заключаются эти потребности. Для этого необходимо
определить требования заказчиков к ИС и отобразить их на языке моделей в
требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и
задачам организации.
Лекция 2 . Принципы/Методологии
Методологии проектирования
Задача формирования требований к ИС является одной из наиболее
ответственных, трудно формализуемых и наиболее дорогих и тяжелых для
исправления в случае ошибки. Современные инструментальные средства и
программные продукты позволяют достаточно быстро создавать ИС по
готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков,
требуют многочисленных доработок, что приводит к резкому удорожанию
фактической стоимости ИС. Основной причиной такого положения является
неправильное, неточное или неполное определение требований к ИС на этапе
анализа.
На этапе проектирования прежде всего формируются модели данных.
Проектировщики в качестве исходной информации получают результаты
анализа. Построение логической и физической моделей данных является
основной частью проектирования базы данных. Полученная в процессе
анализа информационная модель сначала преобразуется в логическую, а
затем в физическую модель данных.
Лекция 2 . Принципы/Методологии
Методологии проектирования
Параллельно с проектированием схемы базы данных выполняется
проектирование процессов, чтобы получить спецификации (описания) всех
модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть
бизнес‐логики обычно реализуется в базе данных (ограничения, триггеры,
хранимые процедуры). Главная цель проектирования процессов заключается в
отображении функций, полученных на этапе анализа, в модули
информационной системы. При проектировании модулей определяют
интерфейсы программ: разметку меню, вид окон, горячие клавиши и
связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
• схема базы данных (на основании ER‐модели, разработанной на этапе
анализа);
• набор спецификаций модулей системы (они строятся на базе моделей
функций).
Лекция 2 . Принципы/Методологии
Вопросы к методологии проектирования
Кроме того, на этапе проектирования осуществляется также
разработка архитектуры ИС, включающая в себя выбор платформы (платформ)
и операционной системы (операционных систем). В неоднородной ИС могут
работать несколько компьютеров на разных аппаратных платформах и под
управлением различных операционных систем. Кроме выбора платформы, на
этапе проектирования определяются следующие характеристики архитектуры:
• будет ли это архитектура "файл‐сервер" или "клиент‐сервер";
• будет ли это 2/3/4‐уровневая архитектура;
• будет ли база данных централизованной или распределенной;
• будет ли база данных однородной, то есть, будут ли все серверы баз данных
продуктами одного и того же производителя;
• будут ли для достижения должной производительности использоваться
параллельные серверы баз данных (например, Oracle Parallel Server, DB2
UDB и т.п.).
Этап проектирования завершается разработкой технического проекта ИС.
Лекция 2 . Принципы/Методологии
Проблемы проектирования
• Разработчику сложно получить исчерпывающую
информацию для оценки формулируемых заказчиком
требований к ИС.
• Заказчик нередко не имеет достаточных знаний о
проблемах автоматизации обработки данных в новой
технической среде, чтобы судить о возможности тех или
иных новаций.
• Проектировщик сталкивается с чрезмерным количеством
подробных сведений о предметной области, что вызывает
трудности моделирования и формализованного описания
бизнес‐процессов.
• Спецификация проектируемой системы из‐за большого
объема и технических терминов часто непонятна
заказчику, а чрезмерное ее упрощение не может
удовлетворить специалистов‐проектировщиков.
Лекция 3: Каноническое
проектирование.
Типовое проектирование.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Организация канонического проектирования ИС ориентирована на
использование главным образом каскадной модели жизненного цикла ИС.
Стадии и этапы работы описаны в стандарте ГОСТ 34.601‐90.
В зависимости от сложности объекта автоматизации и набора задач,
требующих решения при создании конкретной ИС, стадии и этапы работ могут
иметь различную трудоемкость.
Стадии и этапы создания ИС, выполняемые организациями‐
участниками, прописываются в договорах и технических заданиях на
выполнение работ:
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
• обследование объекта и обоснование необходимости создания ИС;
• формирование требований пользователей к ИС;
• оформление отчета о выполненной работе и тактико‐ технического задания
на разработку.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Стадия 2. Разработка концепции ИС.
• изучение объекта автоматизации;
• проведение необходимых научно‐исследовательских работ;
• разработка вариантов концепции ИС, удовлетворяющих требованиям
пользователей;
• оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
• разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на ИС и ее части.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Стадия 5. Технический проект.
• разработка проектных решений по системе и ее частям;
• разработка документации на ИС и ее части;
• разработка и оформление документации на поставку комплектующих
изделий;
• разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
• разработка рабочей документации на ИС и ее части;
• разработка и адаптация программ.
Стадия 7. Внедрение.
Стадия 8. Сопровождение/эксплуатация ИС.
Стадия 9. Вывод из эксплуатации.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Технико‐экономическое обоснование проекта это документ, где четко
сформулировано, что получит заказчик, если согласится финансировать проект,
когда он получит готовый продукт (график выполнения работ) и сколько это
будет
стоить
(для
крупных
проектов
должен
быть
составлен график финансирования на разных этапах работ).
Ориентировочное содержание этого документа:
•
•
•
•
•
•
•
•
•
ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;
совокупность условий, при которых предполагается эксплуатировать будущую систему:
архитектура системы, аппаратные и программные ресурсы, условия функционирования,
обслуживающий персонал и пользователи системы;
сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы,
меры по защите информации;
описание выполняемых системой функций;
возможности развития системы;
информационные объекты системы;
интерфейсы и распределение функций между человеком и системой;
требования к программным и информационным компонентам ПО, требования к СУБД;
что не будет реализовано в рамках проекта.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:
функции ‐ информация о событиях и процессах, которые происходят в бизнесе;
сущности ‐ информация о вещах, имеющих значение для организации и о которых что‐то
известно.
При изучении каждой функциональной задачи управления определяются:
наименование задачи; сроки и периодичность ее решения;
степень формализуемости задачи;
источники информации, необходимые для решения задачи;
показатели и их количественные характеристики;
порядок корректировки информации;
действующие алгоритмы расчета показателей и возможные методы контроля;
действующие средства сбора, передачи и обработки информации;
действующие средства связи;
принятая точность решения задачи;
трудоемкость решения задачи;
действующие формы представления исходных данных и результатов их обработки в виде
документов;
потребители результатной информации по задаче.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Одной из наиболее трудоемких, хотя и хорошо формализуемых задач
этого этапа является описание документооборота организации. При
обследовании документооборота составляется схема маршрута движения
документов, которая должна отразить:
• количество документов;
• место формирования показателей документа;
• взаимосвязь документов при их формировании;
• маршрут и длительность движения документа;
• место использования и хранения данного документа;
• внутренние и внешние информационные связи;
• объем документа в знаках.
По результатам обследования устанавливается перечень задач
управления, решение которых целесообразно автоматизировать, и
очередность их разработки.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
На этапе обследования следует классифицировать планируемые
функции системы по степени важности. Один из возможных форматов
представления такой классификации ‐ MuSCoW.
Эта аббревиатура расшифровывается так:
• Must have ‐ необходимые функции;
• Should have ‐ желательные функции;
• Could have ‐ возможные функции;
• Won't have ‐ отсутствующие функции.
Функции первой категории обеспечивают критичные для успешной
работы системы возможности.
Реализация функций второй и третьей категорий ограничивается
временными и финансовыми рамками: разрабатывается то, что необходимо, а
также максимально возможное в порядке приоритета число функций второй и
третьей категорий.
Последняя категория функций особенно важна, поскольку необходимо
четко представлять границы проекта и набор функций, которые будут
отсутствовать в системе.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Модели деятельности организации создаются в двух видах:
• модель "как есть" ("as‐is")‐ отражает существующие в организации бизнес‐
процессы;
• модель "как должно быть" ("to‐be") ‐ отражает необходимые изменения
бизнес‐процессов с учетом внедрения ИС.
На этапе анализа необходимо привлекать к работе группы
тестирования для решения следующих задач:
• получения сравнительных характеристик предполагаемых к использованию
аппаратных платформ, операционных систем, СУБД, иного окружения;
• разработки плана работ по обеспечению надежности информационной
системы и ее тестирования.
Привлечение тестировщиков на ранних этапах разработки является
целесообразным. Если проектное решение оказалось неудачным и это
обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе
внедрения в эксплуатацию), то исправление ошибки проектирования
обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в
информационной системе, тем ниже стоимость сопровождения системы.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Техническое задание ‐ это документ, определяющий цели, требования
и
основные
исходные
данные,
необходимые
для
разработки
автоматизированной системы управления.
При разработке технического задания необходимо решить следующие
задачи:
• установить общую цель создания ИС, определить состав подсистем и
функциональных задач;
• разработать и обосновать требования, предъявляемые к подсистемам;
• разработать и обосновать требования, предъявляемые к информационной
базе, математическому и программному обеспечению, комплексу
технических средств (включая средства связи и передачи данных);
• установить общие требования к проектируемой системе;
• определить перечень задач создания системы и исполнителей;
• определить этапы создания системы и сроки их выполнения;
• провести предварительный расчет затрат на создание системы и
определить уровень экономической эффективности ее внедрения.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
Эскизный проект предусматривает разработку предварительных
проектных решений по системе и ее частям.
Выполнение стадии эскизного проектирования не является строго
обязательной. Если основные проектные решения определены ранее или
достаточно очевидны для конкретной ИС и объекта автоматизации, то эта
стадия может быть исключена из общей последовательности работ.
Содержание эскизного проекта задается в ТЗ на систему. Как правило,
на этапе эскизного проектирования определяются:
• функции ИС;
• функции подсистем, их цели и ожидаемый эффект от внедрения;
• состав комплексов задач и отдельных задач;
• концепция информационной базы и ее укрупненная структура;
• функции системы управления базой данных;
• состав вычислительной системы и других технических средств;
• функции и параметры основных программных средств.
Лекция 3: Каноническое проектирование
Каноническое проектирование ИС
На основе технического задания (и эскизного проекта)
разрабатывается технический проект ИС. Технический проект системы ‐ это
техническая документация, содержащая общесистемные проектные решения,
алгоритмы решения задач, а также оценку экономической эффективности
автоматизированной системы управления и перечень мероприятий по
подготовке объекта к внедрению.
На этом этапе осуществляется комплекс научно‐исследовательских и
экспериментальных работ для выбора основных проектных решений и расчет
экономической эффективности системы.
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Типовое проектирование ИС предполагает создание системы из готовых
типовых элементов. Основополагающим требованием для применения методов
типового проектирования является возможность декомпозиции проектируемой ИС на
множество составляющих компонентов (подсистем, комплексов задач, программных
модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на
рынке типовые проектные решения, которые настраиваются на особенности
конкретного предприятия.
Типовое проектное решение (ТПР) ‐ это тиражируемое (пригодное к
многократному использованию) проектное решение.
Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются
следующие классы ТПР:
• элементные ТПР ‐ типовые решения по задаче или по отдельному виду обеспечения
задачи (информационному, программному, техническому, математическому,
организационному);
• подсистемные ТПР ‐ в качестве элементов типизации выступают отдельные
подсистемы, разработанные с учетом функциональной полноты и минимизации
внешних информационных связей;
• объектные ТПР ‐ типовые отраслевые проекты, которые включают полный набор
функциональных и обеспечивающих подсистем ИС.
Лекция 3: Типовое проектирование
Типовое проектирование ИС
В зависимости от уровня декомпозиции системы различают:
Типовое
проектирование
Элементный метод
Подсистемный
метод
Объектный метод
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Класс ТПР
Достоинства
Реализация ТПР
Элементные
•обеспечивается применение модульного подхода к
ТПР
проектированию и документированию ИС
Библиотеки
методо‐
ориентированных
программ
Недостатки
•большие затраты времени на сопряжение разнородных
элементов вследствие информационной, программной и
технической несовместимости
•большие затраты времени на доработку ТПР отдельных
элементов
Подсистемные
ТПР
Пакеты
прикладных
программ
•достигается высокая степень интеграции элементов ИС •адаптивность ТПР недостаточна с позиции непрерывного
•позволяют осуществлять: модульное проектирование; инжиниринга деловых процессов
параметрическую настройку программных компонентов •возникают проблемы в комплексировании разных
функциональных подсистем, особенно в случае
на различные объекты управления
•обеспечивают: сокращение затрат на проектирование и использования решений нескольких производителей
программного обеспечения
программирование взаимосвязанных компонентов;
хорошее документирование отображаемых процессов
обработки информации
Объектные ТПР
Отраслевые
проекты ИС
•комплексирование всех компонентов ИС за счет
методологического единства и информационной,
программной и технической совместимости
•открытость архитектуры — позволяет
устанавливать ТПР на разных программно‐технических
платформах
•масштабируемость — допускает конфигурацию ИС для
переменного числа рабочих мест
•конфигурируемость — позволяет выбирать
необходимое подмножество компонентов
•проблемы привязки типового проекта к конкретному
объекту управления, что вызывает в некоторых случаях
даже необходимость изменения организационно‐
экономической структуры объекта автоматизации
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Для реализации типового проектирования используются
два подхода: параметрически‐ориентированное и модельно‐
ориентированное проектирование.
Параметрически‐ориентированное проектирование включает
следующие этапы:
1. определение критериев оценки пригодности пакетов
прикладных программ (ППП) для решения поставленных задач,
2. анализ и оценка доступных ППП по сформулированным
критериям,
3. выбор и закупка наиболее подходящего пакета,
4. настройка параметров (доработка) закупленного ППП.
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Критерии оценки ППП делятся на следующие группы:
• назначение и возможности пакета;
• отличительные признаки и свойства пакета;
• требования к техническим и программным средствам;
• документация пакета;
• факторы финансового порядка;
• особенности установки пакета;
• особенности эксплуатации пакета;
• помощь поставщика по внедрению и поддержанию пакета;
• оценка качества пакета и опыт его использования;
• перспективы развития пакета.
Числовые значения показателей для конкретных ППП
устанавливаются экспертами по выбранной шкале оценок.
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Модельно‐ориентированное
проектирование
заключается в адаптации состава и характеристик типовой ИС в
соответствии с моделью объекта автоматизации.
Модельно‐ориентированное
проектирование
ИС
предполагает, построение модели объекта автоматизации с
использованием специального программного инструментария
(например: SAP Business Engineering Workbench (BEW), BAAN
Enterprise Modeler).
Внедрение типовой информационной системы начинается
с анализа требований к конкретной ИС, которые выявляются на
основе результатов предпроектного обследования объекта
автоматизации. После выбора программного продукта на базе
имеющихся в нем моделей строится предварительная модель ИС,
в которой отражаются все особенности реализации ИС для
конкретного предприятия.
Лекция 3: Типовое проектирование
Типовое проектирование ИС
Реализация
типового
проекта
предусматривает
выполнение следующих операций:
• установку глобальных параметров системы;
• задание структуры объекта автоматизации;
• определение структуры основных данных;
• задание перечня реализуемых функций и процессов;
• описание интерфейсов;
• описание отчетов;
• настройку авторизации доступа;
• настройку системы архивирования.
Лекция 4: Структурирование
предметной области
Лекция 4: Структурирование предметной области
Концептуальная структура предметной области
Структурирование ‐ это процесс создания полуформализованного
описания предметной области. Такое полуформализованное описание
называется полем знаний. Обычно оно создается в графической форме.
Поле знаний Рz можно описать следующим образом:
Pz=<Sk,Sf>,
Где
Sk ‐ концептуальная структура предметной области;
Sf ‐ функциональная структура предметной области,
Концептуальная структура, или модель предметной области,
служит для описания ее объектов и отношений между ними, т.е. можно
сказать, что концептуальная модель Sk представляет собой следующее:
Sk = <A, R>,
Где
А ‐ множество объектов предметной области;
R ‐ множество отношений, связывающих объекты.
Лекция 4: Структурирование предметной области
Концептуальная структура предметной области
Множество отношений представляет собой связи между объектами. При
помощи этих отношений проектировщик фиксирует концептуальное устройство
предметной области, иерархию понятий, свойства и структуру объектов. Разработка
концептуальной структуры имеет самостоятельное значение, не зависимое от конечной
цели ‐ разработки информационной систем. Эта структура может служить для целей
обучения, повышения квалификации, для прогнозирования, объяснения,
реструктурирования и т.п.
Основными из них являются АКО, A‐part‐of, Has‐attribute, Value и др.
• АКО (A‐Kind‐OF) ‐ "это есть", например, [Cray MP] ‐ > (АКО) ‐ > [Компьютер]. АКО
отражает родовидовые отношения и иерархию понятий предметной области.
Обязательно присутствует в любой концептуальной структуре.
• A‐part‐of ‐ "часть от", например, [процессор] ‐ > (A‐part‐of) ‐ > [компьютер]. Это
отношение служит для отражения физической структуры и декомпозиции сложных
объектов на составляющие.
• Has‐attribute ‐ "имеет свойство", например, [память] ‐ > (Has‐attribute) ‐ > [объем
памяти].
• Value ‐ "значение", например, [объем памяти] ‐ > (Value) ‐ > [16 GB].
Лекция 4: Структурирование предметной области
Концептуальная структура предметной области
Поле знаний может напоминать семантическую сеть (см. подразд. 16.1), но
оно менее формализовано. Если в сети жестко оговорены возможные виды связей, то в
поле знаний они произвольны.
Краткий алгоритм формирования концептуальной структуры.
Шаг 1. Определить все результирующие понятия, или выходы системы. Это может быть
набор диагнозов, рекомендаций, советов системы.
Шаг 2. Определить все входные понятия, или факторы, от которых зависит результат
работы системы.
Шаг 3. Установить промежуточные понятия, участвующие в рассуждениях экспертов,
если они есть.
Шаг 4. Для всех понятий найти обобщающие и уточняющие понятия, т.е. установить
иерархии объектов
Шаг 5. Для объектов, участвующих в рассуждениях, определить свойства и их значения.
Шаг 6. Попытаться определить другие связи, и все в целом отразить графически.
Шаг 7. Убрать лишние связи, объекты, обсудить структуру с экспертом, дополнить, если
надо, с возвратом к шагам 1 ‐ 6.
Лекция 4: Структурирование предметной области
Структурная модель предметной области
В основе проектирования ИС лежит моделирование предметной области. Для
того чтобы получить адекватный предметной области проект ИС в виде системы
правильно работающих программ, необходимо иметь целостное, системное
представление модели, которое отражает все аспекты функционирования будущей
информационной системы. При этом под моделью предметной области понимается
некоторая система, имитирующая структуру или функционирование исследуемой
предметной области и отвечающая основному требованию – быть адекватной этой
области.
К моделям предметных областей предъявляются следующие требования:
• формализация, обеспечивающая однозначное описание структуры предметной
области;
• понятность для заказчиков и разработчиков на основе применения графических
средств отображения модели;
• реализуемость, подразумевающая наличие средств физической реализации модели
предметной области в ИС;
• обеспечение оценки эффективности реализации модели предметной области на
основе определенных методов и вычисляемых показателей.
Лекция 4: Структурирование предметной области
Структурная модель предметной области
Структурный аспект предполагает построение:
• объектной структуры, отражающей состав взаимодействующих в процессах
материальных и информационных объектов предметной области;
• функциональной структуры, отражающей взаимосвязь функций (действий) по
преобразованию объектов в процессах;
• структуры управления, отражающей события и бизнес‐правила, которые
воздействуют на выполнение процессов;
• организационной структуры, отражающей взаимодействие организационных
единиц предприятия и персонала в процессах;
• технической структуры, описывающей топологию расположения и способы
коммуникации комплекса технических средств.
Такая система моделей отражает структурный и оценочный аспекты
функционирования предметной области.
Главный критерий адекватности структурной модели предметной
области заключается в функциональной полноте разрабатываемой ИС.
Лекция 4: Структурирование предметной области
Шаблон потокового процессного описания
Лекция 4: Структурирование предметной области
Построения организационно‐функциональной модели компании
Для построения организационно‐функциональной модели используется всего
два типа элементарных моделей.
Древовидные модели (классификаторы) ‐ точные иерархические списки выделенных
объектов управления (организационных звеньев, функций, ресурсов, в том числе
исполнительных механизмов для бизнес‐процессов, документов и их структуры, и т.п.).
Каждый элемент классификатора может быть дополнительно охарактеризован рядом
атрибутов: тип, шкала, комментарий и т.п. Фактически, классификаторы представляют
собой набор управленческих регистров, содержащих, в основном, неколичественную
информацию, совокупность которых задает систему координат для описания
деятельности компании. Количество таких списков‐классификаторов определяется
целью построения модели.
Матричные модели ‐ это проекции, задающие систему отношений между
классификаторами в любой их комбинации. Связи могут иметь дополнительные
атрибуты (направление, название, индекс, шкала и вес).
Лекция 4: Структурирование предметной области
Построения организационно‐функциональной модели компании
В начальной модели применяется всего несколько
предметной области:
• основные группы продуктов и услуг компании;
• ресурсы, потребляемые компанией в ходе своей деятельности;
• функции (процессы), поддерживаемые в компании;
• организационные звенья компании.
•
•
•
классификаторов
В классификаторе функций обычно выделяют три базовых раздела:
основные функции ‐ непосредственно связанные с процессом преобразования
внешних ресурсов в продукцию и услуги предприятия;
функции менеджмента ‐ или функции управления предприятием;
функции обеспечения ‐ поддерживающие производственную, коммерческую и
управленческую деятельность.
Лекция 4: Структурирование предметной области
Организационно‐функциональной модель компании
Лекция 4: Структурирование предметной области
Двухуровневая модель деятельности предприятия
Лекция 4: Структурирование предметной области
Цикл управления ресурсами
В основе цикла управления ресурсами лежит расчет или имитационное
моделирование и контроль результатов:
• выбор (или получение от системы верхнего уровня) целевого критерия оценки
качества решения;
• сбор информации о ресурсах предприятия или возможностях внешней среды;
• просчет вариантов (с различными предположениями о возможных значениях
параметров);
• выбор оптимального варианта — принятие решения (= ресурсного плана);
• учет результатов (и отчетность);
• сравнение с принятым критерием оценки ( = контроль результатов);
• анализ причин отклонений и регулирование (возврат к 1, 2 или 3).
Лекция 4: Структурирование предметной области
Цикл организационного менеджмента
В основе цикла организационного менеджмента лежит структурное или
процессное моделирование и процедурный контроль:
• определение состава задач (обособленных функций, операций);
• выбор исполнителей (‐ распределение зон и степени ответственности);
• проектирование процедур (последовательности и порядка исполнения);
• согласование и утверждение регламента исполнения (‐ процесса, плана
мероприятий);
• отчетность об исполнении;
• контроль исполнения (‐ процедурный контроль);
• анализ причин отклонений и регулирование (возврат к 1, 2 или 3).
Лекция 4: Структурирование предметной области
Функциональная структура управления
•
Лекция 4: Структурирование предметной области
Функциональная структура управления имеет свои положительные моменты и
недостатки:
•Преимущества
•Недостатки
•Профессиональная
специализация •Отсутствие
единого
технического
руководителей подразделений;
руководства по продуктам, проектам;
•Снижение риска ошибочных явлений; •Снижение
персональной
ответственности за конечный результат;
•Высокий профессиональный авторитет •Сложность контроля за ходом процесса
специалистов
в целом и по отдельным проектам;
•Высокие возможности координации;
•Размытость ответственности и границ
компетенции.
•Простота формирования и реализации
единой инновационной политики.
Лекция 4: Структурирование предметной области
Линейная организационная структура управления
•
Лекция 4: Структурирование предметной области
Линейная организационная структура управления имеет свои положительные
моменты и недостатки:
•Преимущества
•Недостатки
•Четкое разграничение ответственности и •Высокие профессиональные требования
компетенции
к руководителю;
•Простой контроль;
•Сложные коммуникации между
исполнителями;
•Быстрые и экономичные формы
•Низкий уровень специализации
принятия решения;
руководителей;
•Простые иерархические коммуникации; •Ярко выраженный авторитарный стиль
руководства;
•Персонифицированная ответственность. •Большая нагрузка руководителя.
Лекция 4: Структурирование предметной области
Многолинейная организационная структура управления
•
Лекция 4: Структурирование предметной области
Многолинейная организационная структура управления имеет свои
положительные моменты и недостатки:
•
•Преимущества
•Высокий профессиональный уровень
подготовки решений;
•Быстрая коммуникация;
•Разгрузка высшего руководства;
•Профессиональная специализация
руководителя;
•Уменьшение потребности в
специалистах широкого профиля
•Недостатки
•Сложность подготовки и согласования
решений;
•Отсутствие единого руководства;
•Дублирование распоряжений и
коммуникаций;
•Сложность отсутствия контроля;
•Относительно застывшая
организационная форма, с трудом
реагирующая на изменения.
Лекция 5: Функциональное и
информационное
моделирование
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐
ориентированные методологии описания предметной
области
Функциональная методика IDEF0
В основе методологии лежат четыре основных понятия: функциональный
блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую
конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта
название каждого функционального блока должно быть сформулировано в глагольном
наклонении.
Интерфейсная дуга (Arrow) отображает элемент системы, который
обрабатывается функциональным блоком или оказывает иное влияние на функцию.
Интерфейсные дуги часто называют потоками или стрелками.
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐
ориентированные методологии описания предметной
области
Функциональная методика IDEF0
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0.
Принцип декомпозиции применяется при разбиении сложного процесса на
составляющие его функции. При этом уровень детализации процесса определяется
непосредственно разработчиком модели.
Модель IDEF0 всегда начинается с представления системы как единого целого
– одного функционального блока с интерфейсными дугами, простирающимися за
пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком
называется контекстной диаграммой.
Точка зрения определяет основное направление развития модели и уровень
необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить
модель, отказавшись от детализации и исследования отдельных элементов, не
являющихся необходимыми, исходя из выбранной точки зрения на систему.
Правильный выбор точки зрения существенно сокращает временные затраты на
построение конечной модели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее
создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть
организованы новые проекты, нацеленные на производство изменений в модели.
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐
ориентированные методологии описания предметной
области
Функциональная методика потоков данных (DFD)
При создании диаграммы потоков данных используются четыре основных
понятия: потоки данных, процессы (работы) преобразования входных потоков
данных в выходные, внешние сущности, накопители данных (хранилища).
Потоки данных
являются абстракциями, использующимися для
моделирования передачи информации (или физических компонент) из одной части
системы в другую. Потоки на диаграммах изображаются именованными стрелками,
ориентация которых указывает направление движения информации.
Назначение процесса (работы) состоит в продуцировании выходных потоков
из входных в соответствии с действием, задаваемым именем процесса. Имя процесса
должно содержать глагол в неопределенной форме с последующим дополнением.
Хранилище (накопитель) данных позволяет на указанных участках
определять данные, которые будут сохраняться в памяти между процессами.
Фактически хранилище представляет "срезы" потоков данных во времени.
Внешняя сущность представляет собой материальный объект вне контекста
системы, являющейся источником или приемником системных данных.
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐ориентированные
методологии описания предметной области
Объектно‐ориентированная методика
Принципиальное отличие между функциональным и объектным подходом
заключается в способе декомпозиции системы. Объектно‐ориентированный подход
использует объектную декомпозицию, при этом статическая структура описывается в
терминах объектов и связей между ними, а поведение системы описывается в
терминах обмена сообщениями между объектами. Целью методики является
построение бизнес‐модели организации, позволяющей перейти от модели сценариев
использования к модели, определяющей отдельные объекты, участвующие в
реализации бизнес‐функций.
Объект — предмет или явление, имеющее четко определенное поведение и
обладающие состоянием, поведением и индивидуальностью. Структура и поведение
схожих объектов определяют общий для них класс. Класс – это множество объектов,
связанных общностью структуры и поведения. Следующую группу важных понятий
объектного
подхода
составляют
наследование
и
полиморфизм.
Понятие полиморфизм может быть интерпретировано как способность класса
принадлежать более чем одному типу. Наследование означает построение новых
классов на основе существующих с возможностью добавления или переопределения
данных и методов.
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐ориентированные
методологии описания предметной области
Объектно‐ориентированный
подход
обладает
следующими
преимуществами:
• Объектная декомпозиция дает возможность создавать модели меньшего размера
путем использования общих механизмов, обеспечивающих необходимую экономию
выразительных средств. Использование объектного подхода существенно повышает
уровень унификации разработки и пригодность для повторного использования, что
ведет к созданию среды разработки и переходу к сборочному созданию моделей.
• Объектная декомпозиция позволяет избежать создания сложных моделей, так как
она предполагает эволюционный путь развития модели на базе относительно
небольших подсистем.
• Объектная модель естественна, поскольку ориентирована на человеческое
восприятие мира.
К недостаткам объектно‐ориентированного подхода относятся высокие
начальные затраты. Этот подход не дает немедленной отдачи. Эффект от его
применения сказывается после разработки двух–трех проектов и накопления повторно
используемых компонентов. Диаграммы, отражающие специфику объектного подхода,
менее наглядны.
Лекция 5: Функциональное и информационное моделирование
Функционально‐ориентированные и объектно‐ориентированные
методологии описания предметной области
Синтетическая методика
Идея синтетической методики заключается в последовательном применении
функционального и объектного подхода с учетом возможности реинжиниринга
существующей ситуации.
Рассмотрим применение синтетической методики на примере разработки
административного регламента.
При построении административных регламентов выделяются следующие стадии:
1. Определение границ системы. На этой стадии при помощи анализа потоков данных выделяют
внешние сущности и собственно моделируемую систему.
2. Выделение сценариев использования системы. На этой стадии при помощи критерия
полезности строят для каждой внешней сущности набор сценариев использования системы.
3. Добавление системных сценариев использования. На этой стадии определяют сценарии,
необходимые для реализации целей системы, отличных от целей пользователей.
4. Построение диаграммы активностей по сценариям использования. На этой стадии строят
набор действий системы, приводящих к реализации сценариев использования;
5. Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики
IDEF0.
6. Формальное описание отдельных функциональных активностей в виде административного
регламента (с применением различных нотаций ).
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Одной
из
основных
частей
информационной
системы является информационная база. Информационная база (ИБ) представляет
собой совокупность данных, организованную определенным способом и хранимую в
памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются
информационные потребности управленческих процессов и решаемых задач.
Разработка БД выполняется с помощью моделирования данных. Цель моделирования
данных состоит в обеспечении разработчика ИС концептуальной схемой базы данных
в форме одной модели или нескольких локальных моделей, которые относительно
легко могут быть отображены в любую систему баз данных. Наиболее
распространенным средством моделирования данных являются диаграммы
"сущность‐связь" (ERD). С помощью ERD осуществляется детализация накопителей
данных DFD – диаграммы, а также документируются информационные аспекты бизнес‐
системы, включая идентификацию объектов, важных для предметной
области ( сущностей), свойств этих объектов ( атрибутов ) и их связей с другими
объектами (отношений).
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
Сущность (Entity) — множество экземпляров реальных или абстрактных объектов
(людей, событий, состояний, идей, предметов и др.), обладающих общими атрибутами
или характеристиками. Любой объект системы может быть представлен только одной
сущностью, которая должна быть уникально идентифицирована. При этом имя
сущности должно отражать тип или класс объекта, а не его конкретный экземпляр
(например, АЭРОПОРТ, а не ВНУКОВО).
Каждая сущность должна обладать уникальным идентификатором. Каждый
экземпляр сущности должен однозначно идентифицироваться и отличаться от всех
других экземпляров данного типа сущности. Каждая сущность должна обладать
некоторыми свойствами:
• иметь уникальное имя; к одному и тому же имени должна всегда применяться одна
и та же интерпретация; одна и та же интерпретация не может применяться к
различным именам, если только они не являются псевдонимами;
• иметь один или несколько атрибутов, которые либо принадлежат сущности, либо
наследуются через связь ;
• иметь один или несколько атрибутов, которые однозначно идентифицируют
каждый экземпляр сущности.
Каждая сущность может обладать любым количеством связей с другими
сущностями модели.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая
для рассматриваемой предметной области. Связь — это ассоциация между
сущностями, при которой каждый экземпляр одной сущности ассоциирован с
произвольным (в том числе нулевым) количеством экземпляров второй сущности, и
наоборот.
Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой
предметной области и предназначенная для квалификации, идентификации,
классификации, количественной характеристики или выражения состояния сущности .
Атрибут представляет тип характеристик или свойств, ассоциированных с множеством
реальных или абстрактных объектов (людей, мест, событий, состояний, идей,
предметов и т.д.).
Экземпляр атрибута — это определенная характеристика отдельного элемента
множества. Экземпляр атрибута определяется типом характеристики и ее значением,
называемым значением атрибута. На диаграмме "сущность‐связь" атрибуты
ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности
должен обладать единственным определенным значением для ассоциированного
атрибута.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
Связь изображается линией, проводимой между сущностью‐родителем и сущностью‐
потомком, с точкой на конце линии у сущности‐потомка. Мощность связей может
принимать следующие значения: N — ноль, один или более, Z — ноль или один, Р —
один или более. По умолчанию мощность связей принимается равной N.
Идентифицирующая связь между сущностью‐родителем и сущностью‐потомком
изображается сплошной линией. Сущность‐потомок в идентифицирующей связи
является зависимой от идентификатора сущностью. Сущность‐родитель в
идентифицирующей связи может быть как независимой, так и зависимой от
идентификатора сущностью (это определяется ее связями с другими сущностями ).
Пунктирная линия изображает неидентифицирующую связь.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты,
определяющие первичный ключ, размещаются наверху списка и отделяются от других
атрибутов горизонтальной чертой.
Сущности могут иметь также внешние ключи (Foreign Key), которые могут
использоваться в качестве части или целого первичного ключа или неключевого
атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена
атрибутов, после которых следуют буквы FK в скобках.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
•
•
Логический уровень — это абстрактный взгляд на данные, когда данные
представляются так, как выглядят в реальном мире, и могут называться так, как
они называются в реальном мире, например "Постоянный клиент", "Отдел" или
"Фамилия сотрудника". Объекты модели, представляемые на логическом уровне,
называются сущностями и атрибутами. Логическая модель данных может быть
построена на основе другой логической модели, например на основе модели
процессов. Логическая модель данных является универсальной и никак не связана с
конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически
являясь отображением системного каталога. В физической
модели содержится информация обо всех объектах БД. Поскольку стандартов на
объекты БД не существует (например, нет стандарта на типы данных), физическая
модель зависит от конкретной реализации СУБД. Следовательно, одной и той
же логической модели могут соответствовать несколько разных физических
моделей. Если в логической модели не имеет значения, какой конкретно тип
данных имеет атрибут, то в физической модели важно описать всю информацию о
конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Базовые понятия IDEF1X
Иерархия наследования (или иерархия категорий) представляет собой особый тип
объединения сущностей, которые разделяют общие характеристики.
Обычно иерархию наследования создают, когда несколько сущностей имеют общие по
смыслу атрибуты, либо когда сущности имеют общие по смыслу связи.
Для каждой категории можно указать дискриминатор — атрибут родового предка,
который показывает, как отличить одну категориальную сущность от другой.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Ключи
Как было сказано выше, каждый экземпляр сущности должен быть уникален и должен
отличаться от других атрибутов.
Первичный ключ (primary key) — это атрибут или группа атрибутов, однозначно
идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не
требуют специального обозначения — это те атрибуты, которые находятся в списке
атрибутов выше горизонтальной линии.
В одной сущности могут оказаться несколько атрибутов или наборов атрибутов,
претендующих на роль первичного ключа. Такие претенденты называются
потенциальными ключами (candidate key).
Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные
первичные ключи не требуют специального обозначения — это список атрибутов,
расположенных выше горизонтальной линии.
Для того чтобы стать первичным, потенциальный ключ должен удовлетворять ряду
требований:
Уникальность. Два экземпляра не должны иметь одинаковых значений возможного
ключа.
Компактность. Сложный возможный ключ не должен содержать ни одного атрибута,
удаление которого не приводило бы к утрате уникальности.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Диаграммы Чена
Данная нотация была введена
Ченом (Chen) и получила
дальнейшее
развитие
в
работах
Баркера
(Barker).
Нотация Чена предоставляет
богатый
набор
средств
моделирования
данных,
включая собственно ERD, а
также диаграммы атрибутов и
диаграммы
декомпозиции.
Эти диаграммные техники
используются прежде всего
для
проектирования
реляционных баз данных (хотя
также
могут
с
успехом
применяться
и
для
моделирования
как
иерархических, так и сетевых
баз данных).
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Диаграммы Гейн‐Сарсон
DFD – это нотация, предназначенная для моделирования информационный систем с
точки зрения хранения, обработки и передачи данных.
Исторически синтаксис этой нотации применяется в двух вариантах — Гейна‐Сарсона
(Gane‐Sarson) и Йордана (Yourdon).
Гейн‐Сарсон
Йордан
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Диаграммы Йордана (Yourdon) VS Гейн‐Сарсон
Основное различие между этими системами заключается в том, что методы Йордона‐
Коуда и Йордона‐Де Марко для обозначения процессов применяют круги, а метод
Гейна‐Сарсона — прямоугольные блоки со скругленными углами (которые иногда
называют «конфетками»). Безусловно, у этих методов имеются и другие различия.
Главное — четко придерживаться выбранной системы нотации при работе с другими
участниками проекта.
Лекция 5: Функциональное и информационное моделирование
Моделирование информационного обеспечения
Кардинальность и ординальность
Под кардинальностью подразумевается максимальное число связей, которое может
быть установлено между экземплярами разных сущностей. Ординальность, в свою
очередь, указывает минимальное количество связей между экземплярами двух
сущностей. Кардинальность и ординальность отображаются на соединительных линиях
согласно выбранному формату нотации.
Лекция 6: Объектно‐
ориентированный подход UML
Лекция 6: Объектно‐ориентированный подход UML
Унифицированный язык визуального моделирования
Unified Modeling Language (UML)
Унифицированный язык объектно‐ориентированного моделирования
Unified Modeling Language (UML) явился средством достижения компромисса между
этими подходами. Существует достаточное количество инструментальных средств,
поддерживающих с помощью UML жизненный цикл информационных систем, и,
одновременно, UML является достаточно гибким для настройки и поддержки
специфики деятельности различных команд разработчиков.
UML представляет собой объектно‐ориентированный язык моделирования,
обладающий следующими основными характеристиками:
• является языком визуального моделирования, который обеспечивает разработку
репрезентативных моделей для организации взаимодействия заказчика и
разработчика ИС, различных групп разработчиков ИС;
• содержит механизмы расширения и специализации базовых концепций языка.
Лекция 6: Объектно‐ориентированный подход UML
Синтаксис и семантика основных объектов UML
Классы
Классы — это базовые элементы любой объектно‐ориентированной системы. Классы
представляют собой описание совокупностей однородных объектов с присущими им
свойствами — атрибутами, операциями, отношениями и семантикой.
В рамках модели каждому классу присваивается уникальное имя, отличающее его от
других классов. Если используется составное имя (в начале имени добавляется имя
пакета, куда входит класс ), то имя класса должно быть уникальным в пакете.
Атрибут — это свойство класса, которое может принимать множество значений. Атрибут
имеет имя и отражает некоторое свойство моделируемой сущности, общее для всех
объектов данного класса. Класс может иметь произвольное количество атрибутов.
Операция — реализация функции, которую можно запросить у любого объекта класса.
Операция показывает, что можно сделать с объектом. Исполнение операции часто
связано с обработкой и изменением значений атрибутов объекта, а также изменением
состояния объекта.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов
Классы в UML изображаются на
диаграммах классов, которые позволяют
описать систему в статическом состоянии —
определить типы объектов системы и
различного рода статические связи между
ними.
Классы отображают типы объектов системы.
Между классами возможны различные
отношения, представленные на рисунке
• зависимости,
которые
описывают
существующие между классами отношения
использования;
• обобщения, связывающие обобщенные
классы со специализированными;
• ассоциации, отражающие структурные
отношения между объектами классов.
• реализация – это семантическая связь
между классами
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов. Связи.
Зависимость – семантически представляет собой связь между
двумя элементами модели, в которой изменение одного элемента
(независимого) может привести к изменению семантики другого
элемента (зависимого). Графически представлена пунктирной линией,
иногда со стрелкой, направленной к той сущности, от которой зависит
еще одна; может быть снабжена меткой.
Зависимость – это связь использования, указывающая, что
изменение спецификаций одной сущности может повлиять на другие
сущности, которые используют ее.
Зависимости на диаграммах классов используются сравнительно
редко, потому что имеют более расплывчатую семантику по сравнению
с ассоциациями и обобщением.
Стрелка может помечаться необязательным, но стандартным
ключевым словом в кавычках и необязательным индивидуальным
именем. Для отношения зависимости предопределены ключевые слова,
которые обозначают некоторые специальные виды зависимостей. Эти
ключевые слова (стереотипы) записываются в кавычках рядом со
стрелкой, которая соответствует данной зависимости.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов. Связи.
Примеры стереотипов для отношения зависимости представлены
ниже:
• «access» – служит для обозначения доступности открытых атрибутов и
операций класса‐источника для классов‐клиентов;
• «bind» – класс‐клиент может использовать некоторый шаблон для своей
последующей параметризации;
• «derive» – атрибуты класса‐клиента могут быть вычислены по атрибутам
класса‐источника;
• «import» – открытые атрибуты и операции класса‐источника становятся
частью класса‐клиента, как если бы они были объявлены непосредственно в
нем;
• «refine» – указывает, что класс‐клиент служит уточнением класса‐источника
в силу причин исторического характера, когда появляется дополнительная
информация в ходе работы над проектом.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов. Связи.
Обобщение – выражает специализацию или наследование, в
котором
специализированный
элемент
(потомок)
строится
по
спецификациям обобщенного элемента (родителя). Потомок разделяет
структуру и поведение родителя. Графически обобщение представлено
в виде сплошной линии с пустой стрелкой, указывающей на родителя.
При наследовании дочерний элемент любого родителя может
получать доступ, обновлять или наследовать функциональность,
указанную внутри родительского объекта. Дочерний объект может
добавлять свои функциональные возможности самому себе, а также
наследовать структуру и поведение родительского объекта.
Этот тип отношений все вместе известен как обобщающие
отношения.
Обобщение также известно как наследование или «is a»
взаимосвязь (или отношение «является»).
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов. Связи.
Ассоциация – это структурная связь между элементами
модели, которая описывает набор связей, существующих между
объектами.
Ассоциация показывает, что объекты одной сущности (класса)
связаны с объектами другой сущности таким образом, что можно
перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию,
так как человек может учиться в школе. Ассоциации можно присвоить
имя «учится в». В представлении однонаправленной ассоциации
добавляется стрелка, указывающая на направление ассоциации.
учится в
Человек
1..*
1..*
Школа
Ассоциация может быть именованной, и тогда на концах
представляющей её линии будут подписаны роли, принадлежности,
индикаторы, мультипликаторы, видимости или другие свойства.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы классов. Связи.
Реализация – это семантическая связь между классами, когда один из
них (поставщик) определяет соглашение, которого второй (клиент) обязан
придерживаться. Это связи между интерфейсами и классами, которые реализуют
эти интерфейсы. Это, своего рода, отношение «целое-часть». Поставщик, как
правило, представлен абстрактным классом. В графическом исполнении связь
реализации – это гибрид связей обобщения и зависимости: треугольник
указывает на поставщика, а второй конец пунктирной линии – на клиента.
Типы реализации:
Каноническая форма
В отношениях реализации UML каноническая форма используется для
реализации интерфейсов в системе. Он использует стереотип интерфейса для
создания интерфейса, а отношения реализации используются для реализации
конкретного интерфейса.
В канонической форме отношение реализации обозначается с помощью
пунктирной направленной линии с большой открытой стрелкой.
Избранная форма
В форме исключения интерфейс обозначается с помощью круга, который также
называется обозначением леденца на палочке.
Этот интерфейс, когда реализован с использованием чего-либо,
присутствующего внутри системы, создает элитную структуру.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы использования
Диаграммы использования описывают функциональность ИС, которая будет
видна пользователям системы. "Каждая функциональность" изображается в виде
"прецедентов использования" (use case) или просто прецедентов. Прецедент — это
типичное взаимодействие пользователя с системой, которое при этом:
• описывает видимую пользователем функцию,
• может представлять различные уровни детализации,
• обеспечивает достижение конкретной цели, важной для пользователя.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы использования
На диаграмме использования изображаются:
• акторы — группы лиц или систем, взаимодействующих с нашей системой;
• варианты использования (прецеденты) — сервисы, которые наша система
предоставляет акторам;
• комментарии;
• отношения между элементами диаграммы.
Порядок построения диаграммы следующий:
1. выделить группы действующих лиц (работающих с системой по‐разному, часто из‐за
различных прав доступа);
2. идентифицировать как можно больше вариантов использования (процессов,
которые могут выполнять пользователи). При этом не следует делить процессы
слишком мелко, нужно выбирать лишь те, которые дадут пользователю значимый
результат. Например, кассир может «продать товар» (это будет являться
прецедентом), однако «ввод штрих‐кода товара для получения цены»
самостоятельным прецедентом не является;
3. дополнить прецеденты словесным описанием (сценарием):
– для каждого прецедента создать разделы: «главная последовательность» и
«альтернативные последовательности»;
– при составлении сценария нужно упорно задавать заказчику вопросы «что
происходит?», «что дальше?», «что еще может происходить?» и записывать
ответы на них.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы последовательностей
Этот вид диаграмм используется для точного определения логики сценария
выполнения прецедента. Диаграммы последовательностейотображают типы
объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они
посылают друг другу, и любые возвращаемые значения, ассоциированные с этими
сообщениями. Прямоугольники на вертикальных линиях показывают "время жизни"
объекта. Линии со стрелками и надписями названий методов означают вызов метода у
объекта.
•
•
•
•
вводятся строки заказа;
по каждой строке проверяется наличие товара;
если запас достаточен — инициируется поставка;
если запас недостаточен — инициируется дозаказ (повторный заказ).
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы последовательностей
Существуют различные взгляды на применение этого вида диаграмм:
• Фаулер предлагает строить диаграммы последовательности для визуализации
наиболее сложных отношений на диаграмме классов;
• Буч рассматривает их в качестве альтернативы диаграмм объектов и использует для
анализа семантики сценариев на ранних стадиях проектирования (до создания
протоколов отдельных классов);
• Розенберг строит диаграммы последовательности в рамках процесса ICONIX,
поэтому они строятся для каждого прецедента (а не только для наиболее
интересных отношений, как у Фаулера). В процессе ICONIX разработке этого вида
диаграмм предшествует построение диаграмм робастности (пригодности), поэтому
уже выделены объекты, участвующие в прецеденте.
UML‐диаграммы допускают аннотацию комментариев во всех типах UML‐
диаграммы. Объект‐комментарий представляет собой прямоугольник со сложенным
углом, как показано ниже. Комментарий можно связать со связанным объектом с
помощью пунктирной линии.
Объект 3
Комментарий
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы состояний
Диаграммы состояний используются для описания поведения сложных
систем. Они определяют все возможные состояния, в которых может находиться
объект, а также процесс смены состояний объекта в результате некоторых событий. Эти
диаграммы обычно используются для описания поведения одного объекта в
нескольких прецедентах.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы состояний
Основные элементы диаграммы состояний
На диаграмме состояний можно отобразить следующие элементы нотации UML,
доступные в панели элементов:
Элемент/
Предназначение
Нотация
Элемент/
Предназначение
Нотация
Класс (Class)
Конечное состояние (Final state)
Состояние (State)
Синхронизатор/разветвитель (Complex
transition)
Состояние (StateEx)
Переход (Transition)
Составное состояние (Composite state)
Сообщение (Event message)
Разделитель (Concurrent state)
Точка изгиба связей (Point)
История (History)
Комментарий (Note)
Глубокая история (Deep history)
Коннектор комментария (Note connector)
Начальное состояние (Start state)
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы деятельности
Диаграмма деятельности — это частный случай диаграммы состояний. На
диаграмме деятельности представлены переходы потока управления от одной
деятельности к другой внутри системы. Этот вид диаграмм обычно используется для
описания поведения, включающего в себя множество параллельных процессов.
•
•
•
•
овалы, изображающие действия объекта;
линейки синхронизации, указывающие на необходимость завершить или начать
несколько действий (модель логического условия "И");
ромбы, отражающие принятие решений по выбору одного из маршрутов
выполнения процесса (модель логического условия "ИЛИ");
стрелки — отражают последовательность действий, могут иметь метки условий.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы деятельности
Диаграмма деятельности – это технология, позволяющая описывать логику
процедур, бизнес‐процессы и потоки работ. Во многих случаях они напоминают блок‐
схемы, но принципиальная разница между диаграммами деятельности и нотацией
блок‐схем заключается в том, что первые поддерживают параллельное процессы.
Диаграмма деятельности подвергалась самым большим изменениям при
смене версий языка UML, поэтому неудивительно, что она были снова изменена и
существенно расширена в UML 2. В UML 1 диаграмма деятельности рассматривалась
как особый случай диаграмм состояний. Это вызвало немало трудностей у
специалистов, моделирующих потоки работ, для которых хорошо подходят диаграммы
деятельности. В UML 2 это ограничение было ликвидировано.
Диаграмма деятельности позволяет любому, кто выполняет данный процесс,
выбирать порядок действий. Другими словами, диаграмма только устанавливает
правила обязательной последовательности действий, которым я должен следовать. Это
важно для моделирования бизнес‐процессов, поскольку эти процессы часто
выполняются параллельно. Такие диаграммы также полезны при разработке
параллельных алгоритмов, в которых независимые потоки могут выполнять работу
параллельно.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы компонентов
Диаграммы компонентов позволяют изобразить модель системы на
физическом уровне.
Элементами диаграммы являются компоненты — физические замещаемые
модули системы. Каждый компонент является полностью независимым элементом
системы. Разновидностью компонентов являются узлы. Узел — это элемент реальной
(физической) системы, который существует во время функционирования
программного комплекса и представляет собой вычислительный ресурс, обычно
обладающий как минимум некоторым объемом памяти, а часто еще и способностью
обработки. Узлы делятся на два типа:
• устройства — узлы системы, в которых данные не обрабатываются.
• процессоры — узлы системы, осуществляющие обработку данных.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы компонентов
Диаграмма компонентов разрабатывается для следующих целей:
• визуализация общей структуры исходного кода программной системы;
• спецификация исполнимого варианта программной системы;
• обеспечение многократного использования отдельных фрагментов программного
кода; представление концептуальной и физической схем баз данных.
Компонент (component) — элемент модели, представляющий некоторую
модульную часть системы с инкапсулированным содержимым, спецификация которого
является взаимозаменяемой в его окружении.
Для компонентов UML определяет следующие стереотипы:
•
•
•
•
•
•
file {файл} — самая распространенная разновидность компонента, принимающая вид какого‐
либо файла;
executable {исполнимый} — разновидность файла, являющегося исполнимым; может
исполняться на какой‐либо компьютерной платформе;
document {документ} — разновидность файла в формате документа, который не является
исполнимым и нс содержит исходный код программы;
library {библиотека} — разновидность файла в формате библиотеки (динамической или
статической);
source {источник} — разновидность файла, который содержит в себе исходный код
программы;
table {таблица} — разновидность компонента в формате таблицы БД.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы развертывания
Польза диаграмм развертывания
• Графическое представление ИТ‐инфраструктуры может помочь более рационально
распределить компоненты системы по узлам сети, от чего зависит в том числе и
производительность системы.
• Такая диаграмма может помочь решить множество вспомогательных задач,
связанных, например, с обеспечением безопасности.
Диаграмма развертывания показывает
топологию системы и распределение
компонентов системы по ее узлам, а
также соединения ‐ маршруты передачи
информации между аппаратными узлами.
Это единственная диаграмма, на которой
применяются “трехмерные” обозначения:
узлы системы обозначаются кубиками.
Все остальные обозначения в UML ‐
плоские фигуры.
Лекция 6: Объектно‐ориентированный подход UML
Диаграммы развертывания
Как нарисовать диаграмму развертывания
Следуйте простым указанным ниже шагам, чтобы нарисовать диаграмму
развертывания.
Шаг 1: Определите цель вашей схемы развертывания. Для этого необходимо
определить узлы и устройства в системе, которые вы будете визуализировать с
помощью диаграммы.
Шаг 2: Выясните отношения между узлами и устройствами. Как только вы
узнаете, как они связаны, перейдите к добавлению коммуникационных
ассоциаций на схеме.
Шаг 3: Определите, какие другие элементы, такие как компоненты, активные
объекты необходимо добавить для завершения диаграммы.
Шаг 4: При необходимости добавляйте зависимости между компонентами и
объектами.
Лекция 7: Методология ARIS
Лекция 7: Методология ARIS
Особенности методологии ARIS
Методология ARIS является наиболее объемной и содержит около
100 различных моделей, используемых для описания, анализа
и оптимизации различных аспектов деятельности организации.
Эта концепция имеет два основных преимущества:
• позволяет выбрать методы и интегрировать их, опираясь на
основные особенности моделируемого объекта;
• служит базой для управления сложными проектами, поскольку
благодаря структурным элементам содержит встроенные
модели процедур для разработки интегрированных
информационных систем.
Кроме того большим преимуществом методологии ARIS является
эргономичность и высокая степень визуализации моделей, что
делает данную методологию удобной и доступной в
использовании всеми сотрудниками компании
Лекция 7: Методология ARIS
В виду большого количества моделей методология
ARIS делит их на 4 группы:
1. Информация (информационные модели). Состоит из моделей
с помощью которых описывается информация, используемая в
деятельности организации.
2. Функции (функциональные модели).Состоит из моделей,
используемых для описания стратегических целей компании,
функций и прочих элементов функциональной деятельности
организации.
3. Оргструктура (организационные модели). Состоит из моделей
с помощью которых описывается организационная структура
компании, а также другие элементы внутренней
инфраструктуры организации.
4. Процессы (модели управления). Состоит из моделей,
используемых для описания бизнес‐процессов, а также
различных взаимосвязей между структурой, функциями и
информацией.
Лекция 7: Методология ARIS
Группы моделей методологии ARIS.
Лекция 7: Методология ARIS
Архитектура ARIS
Лекция 7: Методология ARIS
Каждая из этих групп разделяется ещё на три
уровня:
• Уровень определения требований. На данном уровне
разрабатываются модели, описывающие то, что должна делать
система ‐ как она организована, какие деловые процессы в ней
присутствуют, какие данные при этом используются.
• Уровень проектной спецификации. Этот уровень
соответствует концепции информационной системы,
определяющей основные пути реализации предъявленных на
втором этапе требований.
• Уровень описания реализации. На данном этапе жизненного
цикла создания информационных систем происходит
преобразование спецификации в физическое описание
конкретных программных и технических средств. Это
заключительный этап проектирования систем, за которым
следует этап физической реализации (программирования).
Лекция 7: Методология ARIS
ARIS Toolset – инструментальная среда,
разработанная компанией IDS Scheer AG.
Методология ARIS позиционирует себя как конструктор, из
которого под конкретный проект в зависимости от его целей и
задач разрабатывается локальная методология, состоящая из
небольшого количества требуемых бизнес‐моделей и
объектов.
ARIS Express ‐ бесплатная версия программы поддерживает
только базовые типы диаграмм, не имеет
многопользовательской поддержки, не использует базу
данных, не содержит инструментов для формирования отчётов
и средств анализа модели. ARIS Express не поддерживает связи
между создаваемыми объектами в отличие от полноценной
платной версии, то есть отсутствует контроль целостности и
непротиворечивости модели.
Лекция 7: Методология ARIS
ARIS Express
Архитектура программы базируется на Java Runtime Environment
(JRE)
ARIS Express поддерживает следующие типы моделей:
• Организационная диаграмма (Organizational chart)
• Бизнес‐процесс (Business process)
• ИТ‐инфраструктура (IT infrastructure)
• Карта процессов (Process landscape)
• Модель данных (Data model)
• Карта систем (System landscape)
• Доска (Whiteboard)
• BPMN диаграмма версии 2.0 (BPMN diagram)
• Общие диаграммы (General diagram)
Лекция 7: Методология ARIS
Организационная модель
Моделирование и анализ организационной структуры должен
проводиться с целью выявления:
• обоснованного количества уровней иерархии;
• наличия более чем 5‐6 подчиненных подразделений у одного
руководителя;
• наличие малого количества подчиненных у одного
руководителя;
• подчинения одних и тех же сотрудников различным
руководителям.
В модели организационной структуры целесообразно показывать:
 подразделения предприятия;
 наименование должностей и фамилии руководителей
подразделений;
 физическое местоположение отделов на предприятии.
Лекция 7: Методология ARIS
Лекция 7: Методология ARIS
Предметная область «Предприятие по сборке и
продаже компьютеров».
Организационная модель.
• В модель верхнего уровня включаются самостоятельные
подразделения, входящие в структуру организации: Отдел
управления, Отдел по продажам и маркетингу, Отдел по сборке
и тестированию, Отдел по отгрузке и снабжению.
• Уровни структурных подразделений:
для Отдела по сборке и тестированию это ‐ Управление сборкой
и тестированием, Сборка, Тестирование
для Отдела по отгрузке и снабжению это ‐ Снабжение
необходимыми комплектующими, Хранилище комплектующих
и собранных компьютеров, Отгрузка готовой продукции.
• Низшим уровнем является описание подразделений на уровне
должностей – штатных единиц, занимаемых конкретными
сотрудниками.
Лекция 7: Методология ARIS
Лекция 7: Методология ARIS
Функциональная модель
Функция – описание элемента работы, образующего один
логический этап в рамках процесса. В методологии ARIS
используется диаграмма «Дерево функций», посредством
которой функции могут быть описаны с различными уровнями
детализации. При этом функции представляются
необязательно в хронологическом порядке.
На самом верхнем уровне описываются наиболее сложные
функции, представляющие собой отдельный бизнес‐процесс
или процедуру. Детализация функций образует иерархическую
структуру их описаний
Лекция 7: Методология ARIS
Предметная область «Предприятие по сборке и
продаже компьютеров».
Бизнес процесс предприятия делится на функции:
• «Управление», «Заключение договора»,
• «Сборка и тестирование»,
• «Отгрузка и снабжение».
Они в свою очередь деляться еще на ряд функций.
Функция «Получить запрос клиента» подразумевает, что клиент
делает заказ на сборку компьютера.
Функция «Сформировать заказ» подразумевает оформление
договора с заказчиком.
Функция «Согласовать заказ» подразумевает проверку договора и
его подписание.
Функция «Принять заказ к выполнению» подразумевает отправку
копии договора в отдел сборки и тестирования.
Функция «Получить договор на сборку» означает, что с отдела по
продажам поступил договор.
Лекция 7: Методология ARIS
Предметная область «Предприятие по сборке и
продаже компьютеров».
Функция «Получить необходимые комплектующие»
подразумевает под собой оформление заказа на снабжение и
его отправка в отдел отгрузки и снабжения.
Функции «Сборка» и «Тестирование» означают сборку
компьютера и его тестирование соответственно.
Функция «Получить заказ на снабжение» означает, что с отдела
«Сборка и тестирование» пришел список необходимых
комплектующих.
Функция «Заказать комплектующие» означает, что
комплектующие, которые указаны в заказе на снабжение и не
хранящиеся на складе, заказываются.
Функция «Отправить комплектующие на сборку» подразумевает,
что необходимые комплектующие есть на складе и их
отправляем в отдел «Сборки и тестирования». Функция
«Отправить готовую продукцию» подразумевает, что готовая
подукция отправляется заказчику.
Лекция 7: Методология ARIS
Лекция 7: Методология ARIS
Информационная модель (модель данных).
•
•
Базовая модель ERM Формулировка требований в рамках модели данных включает
описание семантической модели данных в рассматриваемой предметной области.
Модель сущность‐отношение (ERM) Чена является наиболее широко
распространненым методом создания семантических моделей. Сущность – это
реальный или абстрактный объект, представляющий интерес для задач в
конкретной области деятельности. Атрибуты – это свойства, описывающие типы
сущностей.
Процессная модель. Диаграмма цепочек добавления качества.
Диаграмма цепочек добавленного качества описывает функции организации,
которые непосредственно влияют на реальный выход ее продукции. Эти функции
создают последовательность действий, формируя добавленные значения:
стоимость, количество, качество и т.д. Построение диаграммы цепочки
добавленного качества целесообразно начать с обзорного представления
взаимосвязанных частей процесса путем расположения элементов процесса
согласно временной последовательности их выполнения. На следующем этапе
рекомендуется отразить взаимозависимость различных элементов процесса путем
нанесения соответствующих связей. После отображения в модели структуры
процесса каждый из элементов процесса рассматривается с точки зрения
необходимости его детализации. Если это необходимо, то элемент детализируется
на соответствующие блоки. На завершающем этапе в модель процесса добавляют
элементы организационной структуры, отвечающие за выполнения процесса или
участвующие в процессе, а также документы, используемые в процессе.
Лекция 7: Методология ARIS
Элементы управления информационной модели
Лекция 7: Методология ARIS
Пример модели ERM
Лекция 7: Методология ARIS
Пример диаграммы цепочек добавления качества
Лекция 7: Методология ARIS
Диаграмма eEPC (событийная цепочка процесса)
Модель предназначена для детального описания процессов,
выполняемых в рамках одного подразделения, несколькими
подразделениями или конкретными сотрудниками.
Она позволяет выявлять взаимосвязи между организационной и
функциональной моделями.
Модель eEpc отражает последовательность действий в рамках
одного бизнес‐процесса, которые выполняются
организационными единицами, а также ограничения по
времени, налагаемые на отдельные функции. Для каждой
функции могут быть определены начальное и конечное
события, ответственные исполнители, материальные и
документарные потоки (входы, выходы, ресурсы),
сопровождающие модель, а также проведена декомпозиция
на более низкие функции (подфункции и т.д.).
Модель eEPC является наиболее информативной и удобной при
описании деятельности подразделений организации.
Лекция 7: Методология ARIS
Лекция 7: Методология ARIS
Лекция 8: Облачные
технологии
Лекция 8: Облачные технологии
Облачные технологии:
Облачные вычисления (cloud computing) ‐ это технология
распределённой обработки данных в которой компьютерные ресурсы и
мощности предоставляются пользователю как интернет‐сервис.
Облачные технологии ‐ это различные аппаратные,
программные средства, методологии и инструменты, которые
предоставляются пользователю, как интернет‐сервисы, для реализации
своих целей, задач, проектов.
Лекция 8: Облачные технологии
Модели развёртывания облачных технологий:
•
•
•
•
Частное облако (private cloud) — инфраструктура, предназначенная для использования одной
организацией, включающей несколько потребителей (например, подразделений одной
организации), возможно также клиентами и подрядчиками данной организации. Частное
облако может находиться в собственности, управлении и эксплуатации как самой
организации, так и третьей стороны (или какой‐либо их комбинации), и оно может физически
существовать как внутри, так и вне юрисдикции владельца.
Публичное облако (public cloud) — инфраструктура, предназначенная для свободного
использования широкой публикой. Публичное облако может находиться в собственности,
управлении и эксплуатации коммерческих, научных и правительственных организаций (или
какой‐либо их комбинации). Публичное облако физически существует в юрисдикции
владельца — поставщика услуг.
Общественное облако (community cloud) — вид инфраструктуры, предназначенный для
использования конкретным сообществом потребителей из организаций, имеющих общие
задачи (например, миссии, требований безопасности, политики, и соответствия различным
требованиям). Общественное облако может находиться в кооперативной (совместной)
собственности, управлении и эксплуатации одной или более из организаций сообщества или
третьей стороны (или какой‐либо их комбинации), и оно может физически существовать как
внутри, так и вне юрисдикции владельца.
Гибридное облако (hybrid cloud) — это комбинация из двух или более различных облачных
инфраструктур (частных, публичных или общественных), остающихся уникальными
объектами, но связанных между собой стандартизованными или частными технологиями
передачи данных и приложений (например, кратковременное использование ресурсов
публичных облаков для балансировки нагрузки между облаками).
Лекция 8: Облачные технологии
Модели обслуживания облачных технологий:
•
•
•
Программное обеспечение как услуга (SaaS, Software‐as‐a‐Service) — модель, в которой
потребителю предоставляется возможность использования прикладного программного
обеспечения провайдера, работающего в облачной инфраструктуре и доступного из
различных клиентских устройств или посредством тонкого клиента, например,
из браузера (например, веб‐почта) или посредством интерфейса программы. Контроль и
управление основной физической и виртуальной инфраструктурой облака, в том числе сети,
серверов, операционных систем, хранения, или даже индивидуальных возможностей
приложения (за исключением ограниченного набора пользовательских настроек
конфигурации приложения) осуществляется облачным провайдером.
Платформа как услуга (PaaS, Platform‐as‐a‐Service) — модель, когда потребителю
предоставляется возможность использования облачной инфраструктуры для размещения
базового программного обеспечения для последующего размещения на нём новых или
существующих приложений (собственных, разработанных на заказ или приобретённых
тиражируемых приложений). В состав таких платформ входят инструментальные средства
создания, тестирования и выполнения прикладного программного обеспечения — системы
управления базами данных, связующее программное обеспечение, среды исполнения
языков программирования — предоставляемые облачным провайдером.
Инфраструктура как услуга (IaaS, Infrastructure‐as‐a‐Service) предоставляется как
возможность использования облачной инфраструктуры для самостоятельного управления
ресурсами обработки, хранения, сетями и другими фундаментальными вычислительными
ресурсами, например, потребитель может устанавливать и запускать произвольное
программное обеспечение, которое может включать в себя операционные системы,
платформенное и прикладное программное обеспечение. Потребитель может
контролировать операционные системы, виртуальные системы хранения данных и
установленные приложения, а также обладать ограниченным контролем за набором
доступных сетевых сервисов (например, межсетевым экраном, DNS). Контроль и управление
основной физической и виртуальной инфраструктурой облака, в том числе сети, серверов,
типов используемых операционных систем, систем хранения осуществляется облачным
провайдером.
Лекция 8: Облачные технологии
Модели обслуживания облачных технологий:
•
•
Бизнес‐процесс как сервис (BPaaS, Business‐Process‐as‐a‐Service): Эти
предложения представляют следующий после SaaS уровень
абстракции. Они предоставляют часть или целый бизнес‐процесс, как
противоположность отдельному приложению, и могут даже
объединять вместе сервисы разных поставщиков. Компании, такие
как ADP (бухгалтерские услуги, прим. переводчика), предлагают
подобные услуги уже десятилетия. Преимущества облачной
масштабируемости и адаптации делают дальнейший рост BPaaS
интересным объектом для наблюдений. И еще, представьте себе
возможность простой смены поставщика одной из частей бизнес‐
процесса на другого. Это тот тип маневренности, который BPaaS
может предоставлять в будущем.
Данные как сервис (DaaS, Data‐as‐a‐Service): Через веб‐сервисы и
стандарты, такие как Open Data Protocol (OData), DaaS предоставляет
доступ к необработанным данным (например, к данным переписи
населения), которые приложения могут извлекать, анализировать,
визуализировать и т.д. Провайдер отвечает за качество данных, тогда
как клиент имеет доступ по требованию за приемлемую цену.
Организации могут монетизировать данные, размещая их на
облачных платформах, таких как Windows Azure Marketplace
DataMarket.
Лекция 8: Облачные технологии
Традиционные и облачные технологии:
Лекция 8: Облачные технологии
Возможности облачных вычислений
•
•
•
•
•
•
•
•
•
•
Доступ к личной информации с любого компьютера, подключённого к
Интернету
Можно работать с информацией с разных устройств (ПК, планшеты,
телефоны и т.п.)
Не важно в какой операционной системе Вы предпочитаете работать,
‐ веб‐сервисы работают в браузере любых ОС
Одну и туже информацию, как Вы, так и окружающие, могут
просматривать и редактировать одновременно с разных устройств
Многие платные программы стали бесплатными (или более
дешёвыми) веб‐приложениями
Если что‐то случится с вашим устройством (ПК, планшетом,
телефоном), то Вы не потеряете важную информацию, так как она
теперь не хранится в памяти устройств
Всегда под рукой свежая и обновлённая информация
Вы всегда пользуетесь самой последней версией программ и при этом
не надо следить за выходом обновлений
Можно свою информацию объединять с другими пользователями
Легко можно делиться информацией с близкими людьми или с
людьми из любой точки земного шара.
Лекция 8: Облачные технологии
Основные преимущества облачных технологий
• Позволяют получить нужные ресурсы по запросу,
без покупки оборудования.
– Спрос компании на ресурсы или программы
неоднороден
– Облаке ресурсы предоставляются по требованию
• Позволяют снять часть нагрузки с IT‐отдела
• Позволяют быстро запускать новые проекты или
MVP для стартапов и исследовательских отделов
• Позволяют снизить риски при сбоях и авариях
Лекция 8: Облачные технологии
Переход на облачные технологии
Организации прибегают к помощи облачных технологий
для разработки искусственного интеллекта,
оптимизации эксплуатации и рабочих процессов, а
также для динамического масштабирования
инфраструктуры с учетом меняющихся требований
бизнеса. При разработке облачного сервиса полезно
помнить, что вы создаете как инфраструктуру, так и
бизнес‐модель для дальнейшего масштабирования,
обеспечения устойчивости и гибкости. Для достижения
этих целей в ходе разработки облачной архитектуры
необходимо учитывать уникальные особенности,
определяемые рабочими нагрузками, пользователями и
эксплуатационными затратами.
Лекция 8: Облачные технологии
Переход на облачные технологии
Вопросы, которые необходимо рассмотреть перед переходом:
• Каковы существующие рабочие нагрузки и приложения? Где
они выполняются в настоящее время и кто их использует?
• Какова у вас в целом загруженность облачных средств?
Является ли она пониженной из‐за того, что облачные средства
разрабатывались с расчетом на пиковые нагрузки? Требуется ли
вам нарастить мощности для поддержки новых рабочих
нагрузок?
• Сталкиваетесь ли вы с узкими местами вычислительных
мощностей, памяти или сетевого взаимодействия?
• Какова ситуация с вашей средой виртуализации? Используете
ли вы контейнеры?
• Как вы обеспечиваете отказоустойчивость? Нужно ли при этом
задействовать нескольких поставщиков облачных услуг?
Лекция 8: Облачные технологии
Облачная трансформация
Подход 6М:
1. Моделирование и дорожная карта (Model&Map)
2. Имитация (Mimic)
3. Измерение (Measure)
4. Управление (Manage)
5. Переход (Move)
6. Модернизация (Modernize)
Лекция 8: Облачные технологии
Переход на облачные технологии:
Лекция 8: Облачные технологии
Расходы на облака в России будут расти на 5,3%
ежегодно до 2024 года
Компания Accenture 16 сентября 2021 года поделилась результатами
исследования рынка облачных технологий, впервые проведенного в России.
Согласно полученным данным, облака получили широкое распространение
среди отечественных компаний. Более 50% респондентов отмечают
проникновение cloud‐технологий в классические бизнес‐ и ИТ‐приложения:
более 40% используют облака для работы CRM, ERP, платежных шлюзов, BI и ПО
для закупок.
В рамках исследования «Потенциал облачных технологий в России»
было опрошено 130 компаний из промышленного сектора, ритейла, FMCG,
телекоммуникаций, финансового сектора и других отраслей.
Лишь 32% компаний используют облака более 5 лет, 47% начали
работать с ними только в последние 3‐5 лет. Скорость перехода к облакам
снижается из‐за ряда опасений: сложности бизнес‐изменений, требований к
информационной безопасности, необходимости соответствовать
законодательству и вопросов защиты данных.
Более 42% компаний ожидают сложности изменений в бизнесе при
облачной трансформации. Более 41% видят риски с точки зрения
информационной безопасности. При этом 97% респондентов ожидают, что
требования к суверенитету данных станут строже, 67% обеспокоены
сохранностью данных при выборе публичного провайдера.
Лекция 8: Облачные технологии
Информационная безопасность и облачных технологий:
• Преимущества:
– Защиту обеспечивают профессионалы
– Надежность КТС выше
– Доступность информации гарантируется облаком и
провайдером
• Недостатки:
– Необходимость постоянного соединения.
Программное обеспечение и его «кастомизация».
Есть ограничения по ПО, которое можно разворачивать на
«облаках» и предоставлять его пользователю.
– Конфиденциальность.
– Безопасность.
– Дороговизна оборудования.
– Дальнейшая монетизация ресурса.
Вполне возможно, что компании в дальнейшем решат брать
плату с пользователей за предоставляемые услуги.
Лекция 9: Информационная
безопасность
Лекция 9: Информационная безопасность
Основные термины и понятия:
Источник угрозы ‐ это потенциальные антропогенные, техногенные или
стихийные носители угрозы безопасности.
Угроза (действие) [Threat]‐ это возможная опасность (потенциальная или
реально существующая) совершения какого‐либо деяния (действия или
бездействия), направленного против объекта защиты (информационных
ресурсов), наносящего ущерб собственнику, владельцу или
пользователю, проявляющегося в опасности искажения и потери
информации.
Фактор (уязвимость) [Vulnerability]‐ это присущие объекту
информатизации причины, приводящие к нарушению безопасности
информации на конкретном объекте и обусловленные недостатками
процесса функционирования объекта информатизации, свойствами
архитектуры автоматизированной системы, протоколами обмена и
интерфейсами, применяемыми программным обеспечением и
аппаратной платформой, условиями эксплуатации.
Последствия (атака) ‐ это возможные последствия реализации угрозы
(возможные действия) при взаимодействии источника угрозы через
имеющиеся факторы (уязвимости).
Лекция 9: Информационная безопасность
Классификация угроз информационной безопасности:
•
По аспекту информационной безопасности, на который направлены угрозы:
– Угрозы конфиденциальности (неправомерный доступ к информации).
– Угрозы целостности (неправомерное изменение данных).
– Угрозы доступности (осуществление действий, делающих невозможным или
затрудняющих доступ к ресурсам информационной системы).
•
По степени преднамеренности действий:
– Случайные (неумышленные действия, например, сбои в работе систем, стихийные
бедствия).
– Преднамеренные (умышленные действия, например, шпионаж и диверсии).
•
По расположению источника угроз:
– Внутренние (источники угроз располагаются внутри системы).
– Внешние (источники угроз находятся вне системы).
•
По размерам наносимого ущерба:
– Общие (нанесение ущерба объекту безопасности в целом, причинение значительного
ущерба).
– Локальные (причинение вреда отдельным частям объекта безопасности).
– Частные (причинение вреда отдельным свойствам элементов объекта безопасности).
•
По степени воздействия на информационную систему:
– Пассивные (структура и содержание системы не изменяются).
– Активные (структура и содержание системы подвергается изменениям).
Лекция 9: Информационная безопасность
Проявления возможного ущерба ИБ:
• моральный и материальный ущерб деловой репутации
организации;
• моральный, физический или материальный ущерб, связанный с
разглашением персональных данных отдельных лиц;
• материальный (финансовый) ущерб от разглашения
защищаемой (конфиденциальной) информации;
• материальный (финансовый) ущерб от необходимости
восстановления нарушенных защищаемых информационных
ресурсов;
• материальный ущерб (потери) от невозможности выполнения
взятых на себя обязательств перед третьей стороной;
• моральный и материальный ущерб от дезорганизации
деятельности организации;
• материальный и моральный ущерб от нарушения
международных отношений.
Лекция 9: Информационная безопасность
Преступления, определяемых УК РФ относящиеся к ИБ:
•
•
•
•
•
•
•
•
•
Хищение ‐ совершенные с корыстной целью противоправные безвозмездное изъятие и (или)
обращение чужого имущества в пользу виновного или других лиц, причинившее ущерб
собственнику или владельцу имущества.
Копирование компьютерной информации ‐ повторение и устойчивое запечатление
информации на машинном или ином носителе.
Уничтожение ‐ внешнее воздействие на имущество, в результате которого оно прекращает
свое физическое существование либо приводятся в полную непригодность для использования
по целевому назначению. Уничтоженное имущество не может быть восстановлено путем
ремонта или реставрации и полностью выводится из хозяйственного оборота
Уничтожение компьютерной информации ‐ стирание ее в памяти ЭВМ.
Повреждение ‐ изменение свойств имущества при котором существенно ухудшается его
состояние, утрачивается значительная часть его полезных свойств и оно становится полностью
или частично непригодным для целевого использования.
Модификация компьютерной информации ‐ внесение любых изменений, кроме связанных
с адаптацией программы для ЭВМ или баз данных.
Блокирование компьютерной информации ‐ искусственное затруднение доступа
пользователей к информации, не связанное с ее уничтожением.
Несанкционированное уничтожение, блокирование модификация, копирование
информации ‐ любые не разрешенные законом, собственником или компетентным
пользователем указанные действия с информацией.
Обман (отрицание подлинности, навязывание ложной информации) ‐ умышленное
искажение или сокрытие истины с целью ввести в заблуждение лицо, в ведении которого
находится имущество и таким образом добиться от него добровольной передачи имущества,
а также сообщение с этой целью заведомо ложных сведений.
Лекция 9: Информационная безопасность
Виды мер противодействия угрозам безопасности:
• Правовые (законодательные)
К правовым мерам защиты относятся действующие в стране законы, указы и другие нормативно‐
правовые акты, регламентирующие правила обращения с информацией, закрепляющие права и
обязанности участников информационных отношений в процессе ее получения, обработки и
использования, а также устанавливающие ответственность за нарушения этих правил, препятствуя
тем самым неправомерному использованию информации и являющиеся сдерживающим
фактором для потенциальных нарушителей. Правовые меры защиты носят в основном
упреждающий, профилактический характер и требуют постоянной разъяснительной работы с
пользователями и обслуживающим персоналом системы.
• Морально‐этические
К морально‐этическим мерам защиты относятся нормы поведения, которые традиционно
сложились или складываются по мере распространения информационных технологий в обществе.
Эти нормы большей частью не являются обязательными, как требования нормативных актов,
однако, их несоблюдение ведет обычно к падению авторитета или престижа человека, группы
лиц или организации. Морально‐этические нормы бывают как неписаные (например,
общепризнанные нормы честности, патриотизма и т.п.), так и писаные, то есть оформленные в
некоторый свод (устав, кодекс чести и т.п.) правил или предписаний. Морально‐этические меры
защиты являются профилактическими и требуют постоянной работы по созданию здорового
морального климата в коллективах пользователей и обслуживающего персонала АС.
• Технологические
К данному виду мер защиты относятся разного рода технологические решения и приемы,
основанные обычно на использовании некоторых видов избыточности (структурной,
функциональной, информационной, временной и т.п.) и направленные на уменьшение
возможности совершения сотрудниками ошибок и нарушений в рамках предоставленных им прав
и полномочий. Примером таких мер является использование процедур двойного ввода
ответственной информации, инициализации ответственных операций только при наличии
разрешений от нескольких должностных лиц, процедур проверки соответствия реквизитов
исходящих и входящих сообщении в системах коммутации сообщений, периодическое
подведение общего баланса всех банковских счетов и т.п.
Лекция 9: Информационная безопасность
Виды мер противодействия угрозам безопасности:
• Организационные
Организационные меры зашиты ‐ это меры административного и процедурного
характера, регламентирующие процессы функционирования системы обработки
данных, использование ее ресурсов, деятельность обслуживающего персонала, а
также порядок взаимодействия пользователей и обслуживающего персонала с
системой таким образом, чтобы в наибольшей степени затруднить или
исключить возможность реализации угроз безопасности или снизить размер
потерь в случае их реализации.
• Меры физической защиты
Физические меры защиты основаны на применении разного рода механических,
электро‐или электронно‐механических устройств и сооружений, специально
предназначенных для создания физических препятствий на возможных путях
проникновения и доступа потенциальных нарушителей к компонентам системы и
защищаемой информации, а также средств визуального наблюдения, связи и
охранной сигнализации. К данному типу относятся также меры и средства
контроля физической целостности компонентов АС (пломбы, наклейки и т.п.).
• Технические
Технические меры защиты основаны на использовании различных электронных
устройств и специальных программ, входящих в состав АС и выполняющих
(самостоятельно или в комплексе с другими средствами) функции защиты.
Лекция 9: Информационная безопасность
Основные механизмы защиты компьютерных систем:
•
•
•
•
•
•
•
•
•
•
•
•
Идентификация (именование и опознавание), аутентификация
(подтверждение подлинности) пользователей системы;
Разграничение доступа пользователей к ресурсам системы и авторизация
(присвоение полномочий) пользователям;
Регистрация и оперативное оповещение о событиях, происходящих в системе;
(аудит)
Криптографическое закрытие хранимых и передаваемых по каналам связи
данных;
Контроль целостности и аутентичности (подлинности и авторства) данных;
выявление и нейтрализация действий компьютерных вирусов;
Затирание остаточной информации на носителях;
Выявление уязвимостей (слабых мест) системы;
Изоляция (защита периметра) компьютерных сетей (фильтрация трафика,
скрытие внутренней структуры и адресации, противодействие атакам на
внутренние ресурсы и т.д.);
Обнаружение атак и оперативное реагирование.
Резервное копирование
Маскировка.
Лекция 9: Безопасность сетей
Защита данных от внутренних угроз
Для защиты циркулирующей в локальной сети информации можно применить следующие
криптографические методы:
• шифрование информации;
• электронную цифровую подпись (ЭЦП).
Шифрование
Шифрование информации помогает защитить ее конфиденциальность, т.е.
обеспечивает невозможность несанкционированного ознакомления с ней. Шифрование — это
процесс преобразования открытой информации в закрытую, зашифрованную (что называется
«зашифрование») и наоборот («расшифрование»). Это преобразование выполняется по строгим
математическим алгоритмам; помимо собственно данных в преобразовании также участвует
дополнительный элемент — «ключ».
По виду соответствия ключей k1 и k2 алгоритмы шифрования разделяются на две категории:
• Симметричное шифрование: k1= k2. Для зашифрования и расшифрования информации
используется один и тот же ключ. Это означает, что пользователи, обменивающиеся
зашифрованной информацией, должны иметь один и тот же ключ. Более безопасный вариант
– существует уникальный ключ шифрования для каждой пары пользователей, который
неизвестен остальным. Ключ симметричного шифрования должен храниться в секрете: его
компрометация (утеря или хищение) повлечет за собой раскрытие всей зашифрованной
данным ключом информации.
• Асимметричное шифрование. Ключ k1‐ в данном случае называется «открытым», а ключ k2 –
«секретным». Открытый ключ вычисляется из секретного различными способами (зависит от
конкретного алгоритма шифрования). Обратное же вычисление k2 из k1 является практически
невозможным. Смысл асимметричного шифрования состоит в том, что ключ k2 хранится в
секрете у его владельца и не должен быть известен никому; ключ k1, наоборот,
распространяется всем пользователям, желающим отправлять зашифрованные сообщения
владельцу ключа k2; любой из них может зашифровать информацию на ключе k1,
расшифровать же ее может только обладатель секретного ключа k2.
Лекция 9: Безопасность сетей
Защита данных от внутренних угроз
ЭЦП
ЭЦП позволяет гарантировать целостность и авторство информации (схема 2).
Как видно из схемы, ЭЦП также использует криптографические ключи: секретный и
открытый. Открытый ключ вычисляется из секретного по достаточно легкой формуле,
например: у=ах*mod p (где х – секретный ключ, у – открытый ключ, а и р – параметры
алгоритма ЭЦП), обратное же вычисление весьма трудоемко и считается неосуществимым
за приемлемое время при современных вычислительных мощностях.
Лекция 9: Безопасность сетей
Защита от внешних угроз
Виртуальные частные сети
Технология VPN является весьма эффективной защитой, ее повсеместное внедрение —
только вопрос времени.
Суть VPN состоит в следующем:
1. На все компьютеры, имеющие выход в Internet (вместо Internet может быть и любая
другая сеть общего пользования), ставится средство, реализующее VPN. Такое средство
обычно называют VPN‐агентом. VPN‐агенты обязательно должны быть установлены на
все выходы в глобальную сеть.
2. VPN‐агенты автоматически зашифровывают всю информацию, передаваемую через них
в Internet, а также контролируют целостность информации с помощью имитоприставок.
Лекция 9: Безопасность сетей
Политика безопасности
Политика обеспечения безопасности включает несколько элементов, в том числе
следующие.
• Оценка риска. Что именно мы защищаем и от кого? Нужно идентифицировать
ценности, находящиеся в сети, и возможные источники проблем.
• Ответственность. Необходимо указать ответственных за принятие тех или иных мер по
обеспечению безопасности, начиная от утверждения новых учетных записей и
заканчивая расследованием нарушений.
• Правила использования сетевых ресурсов. В политике должно быть прямо сказано, что
пользователи не имеют права употреблять информацию не по назначению,
использовать сеть в личных целях, а также намеренно причинять ущерб сети или
размещенной в ней информации.
• Юридические аспекты. Необходимо проконсультироваться с юристом и выяснить все
вопросы, которые могут иметь отношение к хранящейся или генерируемой в сети
информации, и включить эти сведения в документы по обеспечению безопасности.
• Процедуры по восстановлению системы защиты. Следует указать, что должно быть
сделано в случае нарушения системы защиты и какие действия будут предприняты
против тех, кто стал причиной такого нарушения..
Лекция 9: Информационная безопасность
Формальные модели безопасности (модель Диона):
•
Метки безопасности субъекта:
– абсолютная метка конфиденциальности (ACL) присваивается субъекту
во время создания и остается постоянной во все время его
существования. Обычно в качестве ACL используется метка пользователя‐
инициатора процесса;
– метка конфиденциальности чтения (RCL) ‐ максимальный (в смысле
отношения доминирования меток) уровень конфиденциальности, с
которого субъекту разрешено читать информацию;
– метка конфиденциальности записи (WCL) ‐ минимальный уровень
конфиденциальности, на который субъекту разрешено записывать
информацию;
– абсолютная метка целостности (AIL);
– метка целостности чтения (RIL) ‐ минимальный уровень целостности, с
которого субъекту разрешено читать информацию;
– метка целостности записи (WIL) ‐ максимальный уровень целостности, на
который субъекту разрешено записывать информацию.
•
Для каждого субъекта s должны выполняться следующие
соотношения:
WCL(s) <= ACL(s) <= RCL(s)
RIL(s) <= AIL(s) <= WIL(s)
Лекция 9: Безопасность сетей
Формальные модели безопасности (модель Диона):
•
Метки безопасности объекта:
– абсолютная метка конфиденциальности (ACL) присваивается объекту во
время создания и остается постоянной на все время его существования.
Характеризует конфиденциальность данных, хранящихся в объекте;
– метка конфиденциальности чтения из объекта (RCL) ‐ максимальный
уровень конфиденциальности, на который могут мигрировать данные,
хранящиеся в объекте;
– метка конфиденциальности записи в объект (WCL) ‐ минимальный
уровень конфиденциальности, с которого данные могут записываться в
объект;
– абсолютная метка целостности (AIL);
– метка целостности чтения из объекта (RIL) ‐ минимальный уровень
целостности, на который могут мигрировать данные, хранящиеся в
объекте;
– метка целостности записи в объект (WIL) ‐ максимальный уровень
целостности, с которого данные могут записываться в объект.
•
Для каждого объекта o должны выполняться следующие
соотношения:
WCL(o) <= ACL(o) <= RCL(o)
RIL(o) <= AIL(o) <= WIL(o)
Лекция 9: Безопасность сетей
Система информационной безопасности
Обеспечение
информационной
безопасности
Внешняя система
(СОИБ)
Встроенная система
Система на основе
сторонних
элементов
Лекция 9: Безопасность сетей
Система обеспечения информационной безопасности (СОИБ):
Цели проектирования СОИБ:
• Реализация мер защиты соответствующих реальным
угрозам ИБ Компании.
• Соответствие разрабатываемой СОИБ и нормативной
базы определенным критериям (законодательство,
стандарты, внутренние требования).
• Централизация процессов управления и мониторинга
ИБ в Компании.
• Контроль над службами и системами ИБ, гибкое
распределение уровней доступа и управления.
• Стандартизация, унификация и оптимизация
информационно‐управляющих ресурсов обеспечения
безопасности всех связанных служб и подразделений.
Лекция 9: Безопасность сетей
Система обеспечения информационной безопасности (СОИБ):
В состав СОИБ как правило входят следующие компоненты и
подсистемы:
• Подсистема защиты периметра сети
• Подсистема безопасного межсетевого взаимодействия
• Подсистема регистрации и учета событий
• Подсистема обеспечения целостности
• Подсистема управления доступом
• Подсистема обнаружения и предотвращения атак
• Подсистема анализа защищенности
• Подсистема криптографической защиты данных
• Подсистема инфраструктуры открытых ключей
• Подсистема антивирусной защиты
• Подсистема управления информационной безопасностью
• Подсистема предотвращения утечек информации
• Подсистема резервного копирования и восстановления данных
Лекция 9: Безопасность сетей
Этапы проектирования СОИБ
В рамках проведения работ по проектированию
и внедрению СОИБ разработчик выполняет
полный комплекс работ:
1. Обследование объекта информатизации
2. Создание концепции информационной
безопасности
3. Техно‐рабочее (техническое проектирование)
СОИБ
Лекция 9: Безопасность сетей
Встроенная система безопасности
Принципы и подходы
• Минимизация ИБ, причины
– не профильные затраты разработчиков ИС
– затраты вычислительных ресурсов
– усложнение ИС
• Простые защитные механизмы
– авторизация и аутентификация на входе
– простейшие алгоритмы шифрования
– простейшие методы защиты коммуникаций или их
отсутствие
• Иллюзия защиты у пользователя
• Перенос ответственности на других
производителей/разработчиков
Лекция 9: Безопасность сетей
Разработка встроенных систем безопасности
Необходимо сформулировать ответы на следующие вопросы:
• Какие данные и информацию будет обслуживать данная ИС?
• Каковы возможные последствия нарушения конфиденциальности,
целостности и доступности этой информации?
• Каковы угрозы, по отношению к которым данные, информация, ИС
и пользователь будут наиболее уязвимы?
• Существуют ли какие‐либо особенности ИС, требующие принятия
специальных мер — например, территориальная распределённость
компонентов ИС?
• Каковы должны быть характеристики персонала, имеющие
отношение к безопасности: компьютерная квалификация,
дисциплинированность, благонадежность?
• Каковы законодательные положения и корпоративные правила,
которым должен удовлетворять ИС?
Лекция 9: Безопасность сетей
Формирование требований к встроенной систем безопасности
Лекция 9: Безопасность сетей
Разработка систем на основе сторонних элементов
Пошаговый подход
1. Выявление «узких» мест и угроз ИБ
2. Согласование нормативной базы
3. Подбор компонентов/элементов
4. Модернизация проекта с учетом подобранных
элементов
– Выбор пути
1.
2.
3.
2 проекта,
выбор пользователя
отказ от не безопасной версии
– Взаимодействие с поставщиком/разработчиком компонент
• Условия взаимодействия
• Разграничение ответственности
5. Реализация, тестирование, внедрение
Лекция 9: Информационная безопасность
Экономика ИБ:
• Соотношение средства на защиту ‐ ущерб.
• Оптимизация затрат на безопасность.
• «Паранойя» безопасности – путь к возможным
убыткам.
• Разделение информации по ИБ признаку:
– Защищаемая государством и законом.
– Коммерческая тайна.
– ДСП и другие уровни.
• Профиль затрат на ИБ
– приобретение (разовые)
– периодические (ЗП, платежи, страховки)
– экстренный фонд
Лекция 10: Проектирование
открытых систем
Лекция 10: Проектирование открытых систем
Понятие открытой системы
В любом более или менее серьезном проекте по созданию
программного обеспечения на одном из первых этапов
производится выбор архитектуры будущего решения.
Трудно переоценить важность этого этапа, особенно если
речь идет о большой системе, рассчитанной на длительную
эксплуатацию: на разработку подобной системы будут затрачены
значительные ресурсы, и вложения окажутся эффективными лишь в
случае, если система не станет «унаследованной» уже с момента
ввода в эксплуатацию, а будет допускать модернизацию не только с
минимально возможными затратами, но и без потери
архитектурной целостности и, соответственно, надежности.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Одна из важнейших проблем, возникающих при создании ИС,
типа КИС, ИС для решения отдельных задач и в других областях
автоматизации, заключается в резком увеличении стоимости системы с
ростом ее сложности. Объективная причина этого явления состоит в том,
что сложные системы часто изготавливаются в единичных экземплярах, а
это не позволяет сделать их дешевыми. Даже небольшие серии типовых
ИС не приводят к заметному снижению цены, что также сужает рынок
потенциальных потребителей.
Распространенный метод решения указанной проблемы состоит
в делении системы на модули таким образом, чтобы каждый из них
становился коммерчески эффективным изделием и мог изготавливаться
несколькими конкурирующими производителями в больших количествах.
Однако при этом возникает проблема аппаратной и программной
совместимости модулей. Для достижения совместимости интерфейс,
конструктив и выполняемые функции таких модулей должны быть
стандартизованы.
Открытой называется модульная система, которая допускает
замену любого модуля на аналогичный модуль другого производителя,
имеющийся в свободной продаже по конкурентоспособным ценам, а
интеграция системы с другими системами (в том числе с пользователем)
выполняется без преодоления чрезмерных проблем.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Открытость можно рассматривать на разных уровнях
иерархии программного и аппаратного обеспечения системы
или ее составных частей. Открытыми, например, могут быть:
• физические интерфейсы, протоколы обмена, методы
контроля ошибок, системы адресации, форматы данных, типы
организации сети, интерфейсы между программами и т.п.;
• конструкционные элементы (шкафы, стойки, корпуса,
разъемы, крепежные элементы);
• пользовательские интерфейсы, языки программирования,
управляющие команды модулей ввода‐вывода, языки
управления базами данных, операционные системы и т.п.;
• системы, включающие в себя перечисленные выше элементы;
• и т.д.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Понятие открытости нужно трактовать шире: оно должно
подразумевать, что система не только удовлетворяет стандартам, но
стандарт является общепризнанным, а в свободной продаже
имеются аналогичные системы других производителей по
конкурентоспособным ценам.
Как следует из определения, необходимыми условиями открытости
являются:
• модульность;
• соответствие стандартам (необязательно официальным, но
обязательно общепринятым и легко доступным по цене,
компенсирующей только затраты на его разработку, поддержку и
распространение);
• наличие в свободной продаже аналогичных систем других
производителей (подсистем, модулей) по конкурентоспособным
ценам.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
С точки зрения программной организации большинство
современных информационных систем спроектированы под
влиянием сервисной архитектуры.
Компонент Business Logic реализует основной функционал
системы (рисунок). Компонент UI — интерфейс к основному
функционалу для пользователей системы, а компонент API
предназначен для интеграции с другими системами.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Именно компонент API обеспечивает сервисность, предоставляя внешним
потребителям интерфейсы к готовым бизнес‐сервисам, реализованным на базе основного
функционала системы из компонента Business Logic. Причем реализация сервисов может
быть инкапсулирована как в компоненте API (c использованием функций основного
функционала), так и в компоненте Business Logic.
Процессы разработки пользовательского интерфейса и сервисов зачастую не
синхронизированы, кроме того, разработчики часто с большим вниманием относятся к
требованиям своих непосредственных пользователей, чем к требованиям партнеров по
интеграции. В результате функционал, предоставляемый непосредственным
пользователям системы, может сильно отличаться от того, что доступно внешним
системам в виде сервисов, а это, в свою очередь, не позволяет использовать хорошо
зарекомендовавшую себя при работе в автономном режиме систему столь же эффективно
и в едином информационном пространстве предприятия.
«Открытая архитектура информационных систем» позволяет устранить этот
функциональный дисбаланс, однако следует отметить, что сегодня под «Открытой
архитектурой» часто подразумевают более узкое понятие — наличие мощного и хорошо
документированного API для интеграции и расширения функциональности системы
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Основная идея состоит в том, чтобы при разработке пользовательского
интерфейса применялся тот же набор функций, который предоставлен в виде сервисов
внешним системам. Основные достоинства данного подхода.
• Синхронность функционала, предоставляемого непосредственным пользователям и
внешним системам.
• Использование единого кода, реализующего сервис, как для пользовательского
интерфейса, так и для внешних систем, что позволяет сократить время разработки,
модификации и тестирования.
• Единый подход к обеспечению информационной защиты. Часто сервисы,
предназначенные для интеграции с внешними системами, обладают слабой защитой
из‐за того, что внешняя система не транслирует индивидуальные полномочия
конечных пользователей, а использует общий для всех операций механизм
аутентификации и авторизации с максимальными полномочиями, достаточными для
выполнения всех запланированных операций.
• Высокий уровень прозрачности использования сервисов системы. «Родной» интерфейс
является по сути руководством по правильному использованию сервисов,
предоставляемых внешними системами, и при должном уровне диагностики
стороннему разработчику для реализации той или иной функции системы достаточно
посмотреть, как этот функционал реализован в «родном» интерфейсе.
Лекция 10: Проектирование открытых систем
Понятие открытой системы
Истинный смысл «Открытой архитектуры» состоит в равных
возможностях производителя и сторонних разработчиков — все
функции, доступные непосредственным пользователям системы,
должны быть доступны и внешним системам, при этом они должны
демонстрировать идентичное поведение и поддерживать один и
тот же уровень информационной защиты.
Лекция 10: Проектирование открытых систем
Стандартизация и открытые системы
Интенсивность усилий в области научной постановки и разработки проблем стандартизации ИТ в
мировом масштабе обеспечила развитие соответствующей системы знаний и стандартов до такого уровня, когда она
становится главным носителем научно‐методических основ в области ИТ. Эта система знаний получила название
итологии. В основе развития итологии лежат следующие методы:
•
создание основ научного знания в виде методологического ядра (метазнаний), представляющего собой
целостную систему эталонных моделей важнейших разделов ИТ, осуществляющего структуризацию научного
знания в целом ‐ данный метод получил название архитектурной спецификации;
•
разработка спецификаций поведения реализаций ИТ, т.е. такого поведения ИТ‐систем, которое может
наблюдаться на интерфейсах (границах) этих систем ‐ данный метод называют также функциональной
спецификацией;
•
стандартизация спецификаций ИТ и управление их жизненным циклом, осуществляемая системой
специализированных международных организаций на основе строго регламентированной деятельности ‐ этот
процесс обеспечивает накопление базовых сертифицированных научных знаний, служит основой создания
открытых технологий;
•
разработка аппарата (концепция и методология) проверки соответствия (аттестации) реализаций ИТ‐систем ИТ‐
спецификациям, на основе которых данные ИТ‐системы были разработаны;
•
профилирование ИТ или разработка функциональных профилей ИТ ‐ метод построения спецификаций
комплексных технологий посредством комбинирования базовых и производных от них (представленных в
стандартизованном виде) спецификаций с соответствующей параметрической настройкой этих спецификаций
(иными словами, профилирование является композиционным оператором в пространстве ИТ с базисом, в
качестве которого выступают базовые, т.е. стандартные спецификации);
•
таксономия (классификационная система) профилей ИТ, обеспечивающая уникальность идентификации в
пространстве ИТ, явное отражение взаимосвязей ИТ между собой;
•
разнообразные методы формализации и алгоритмизации знаний, методы конструирования прикладных
информационных технологий (парадигмы, языки программирования, базовые открытые технологии,
функциональное профилирование ИТ).
Лекция 10: Проектирование открытых систем
Стандартизация и открытые системы
Получены фундаментальные нормативно‐методические решения, в
частности созданы стандарты, определяющие:
• глобальные концепции развития области ИТ;
• концептуальный базис и эталонные модели построения основных разделов
ИТ;
• функции, протоколы взаимодействия, интерфейсы и другие аспекты ИТ;
• языки программирования, языки спецификации информационных ресурсов,
языки управления базами данных;
• модели технологических процессов создания и использования систем ИТ, а
также языки описания таких моделей;
• методы тестирования соответствия (конформности) систем ИТ исходным
стандартам и профилям;
• методы и процедуры функционирования собственно системы стандартов ИТ;
• метаязыки и нотации для описания стандартов ИТ;
• общесистемные функции ИТ ‐ например: безопасность, администрирование,
интернационализация, качество сервисов.
Лекция 10: Проектирование открытых систем
Стандартизация и открытые системы
Состояние и развитие стандартизации в области информационных технологий характеризуются в
настоящее время рядом проблемных областей, которые определяют поле деятельности в области международной
стандартизации:
•
международные и национальные стандарты в области ИТ и разработки программного обеспечения не
полностью и неравномерно удовлетворяют потребности в стандартизации объектов и процессов создания и
применения сложных ИС;
•
длительные сроки разработки, согласования и утверждения международных и национальных стандартов (3‐5
лет) приводят к их консерватизму и хроническому отставанию от современных технологий создания сложных
ИС;
•
совокупности стандартов на разработку современных ИС (профили ИС) должны учитывать необходимость
построения ИС как открытых систем, обеспечивать их расширяемость при наращивании или изменении
выполняемых функций (переносимость программного обеспечения и возможность взаимодействия с другими
ИС);
•
в области ИС функциональными стандартами поддержаны и регламентированы только самые простые объекты
и рутинные, массовые процессы (передача данных по сетям, программирование, документирование программ
и данных);
•
наиболее сложные процессы создания и развития крупных распределенных ИС (системный анализ и
проектирование, интеграция компонентов и систем, испытания и сертификация ИС и т.п.) почти не поддержаны
требованиями и рекомендациями стандартов из‐за разнообразия содержания, творческого характера труда,
трудности их формализации и унификации;
•
имеющиеся лакуны и задержки в подготовке и издании стандартов высокого ранга, а также текущая
потребность в унификации и регламентировании современных объектов и процессов в области ИС приводят к
созданию многочисленных нормативных и методических документов отраслевого, ведомственного или
фирменного уровней
Лекция 10: Проектирование открытых систем
Организации по стандартизации
ISO и IEC объединили свою деятельность в области стандартизации ИТ, создав единый орган JTC1 ‐
Объединенный технический комитет № 1 (Joint Technical Committee 1), предназначенный для формирования
всеобъемлющей системы базовых стандартов в области ИТ и их расширений для конкретных сфер деятельности.
Лекция 10: Проектирование открытых систем
Организации по стандартизации
К основным целям Комитета JTC1 относятся разработка, поддержание, продвижение
стандартов ИТ, являющихся необходимыми для глобального рынка, удовлетворяющих требованиям
бизнеса и пользователей и имеющих отношение:
• к проектированию и разработке систем и средств ИТ;
• производительности и качеству продуктов и систем ИТ;
• безопасности систем ИТ и информации;
• переносимости прикладных программ;
• интероперабельности продуктов и систем ИТ;
• унифицированным средствам и окружениям;
• гармонизированному словарю понятий области ИТ;
• "дружеским" и эргономичным пользовательским интерфейсам.
Работа над стандартами ИТ в JTC1 тематически распределена по подкомитетам (SC),
связанных с разработкой стандартов ИТ, относящихся к окружению открытых систем OSE (Open
Systems Environment). Некоторых таких комитетов и подкомитетов:
• SC6 ‐ телекоммуникация и информационный обмен между системами;
• SC7 ‐ разработка программного обеспечения и системная документация;
• SC18 ‐ текстовые и офисные системы";
• SC21 ‐ открытая распределенная обработка (Open Distributed Processing ‐ ODP), управление
данными (Data Management ‐ DM) и взаимосвязь открытых систем (Open System Interconnection ‐
OSI);
• и т.д.
Этапы проведения функциональной стандартизации
Базовые стандарты в
проблемных областях
Лекция 10: Проектирование открытых систем
Схема функциональной стандартизации ИТ
Лекция 10: Проектирование открытых систем
Методологический базис открытых систем
Процесс стандартизации информационных технологий должен иметь
методологическое основание, которое позволило бы обоснованно определять объекты,
методы и инструменты стандартизации. При этом понятие информационные технологии
трактуется следующим образом: "Информационные технологии включают в себя
спецификацию, проектирование и разработку программно‐аппаратных и
телекоммуникационных систем и средств, имеющих дело с поиском и сбором
информации, представлением, организацией, обработкой, безопасностью, хранением,
передачей, а также обменом и управлением информацией". Такое толкование и единая
методологическая база реализована в виде методологического базиса открытых систем.
Методологически базис открытых систем состоит из совокупности концепций и
основанных на них эталонных моделей:
• концептуальная основа и принципы построения открытых систем;
• эталонная модель окружений открытых систем (Open System Environment Reference
Model ‐ OSE RM);
• эталонная модель взаимосвязи открытых систем (Open Systems Interconnection
Reference Model ‐ OSI RM);
• аппарат разработки и использования профилей ИТ/ИС, предназначенный для создания
открытых систем в пространстве стандартизованных решений;
• таксономия профилей;
• концепция тестирования конформности систем ИТ исходным стандартам и профилям.
Лекция 10: Проектирование открытых систем
Эталонная модель среды взаимодействия открытых систем
Лекция 10: Проектирование открытых систем
Обобщенная среда прикладных программ
Лекция 10: Проектирование открытых систем
Базовая эталонная модель взаимосвязи открытых систем
Обобщенная структура любой программной или информационной системы
может быть представлена, как было отмечено выше, двумя взаимодействующими
частями:
• функциональной части, включающей в себя прикладные программы, которые
реализуют функции прикладной области;
• среды или системной части, обеспечивающей исполнение прикладных программ.
С таким разделением и обеспечением взаимосвязи тесно связаны две группы вопросов
стандартизации:
• стандарты интерфейсов взаимодействия прикладных программ со средой ИС,
прикладной программный интерфейс (Application Program Interface ‐ API);
• стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External
Environment Interface ‐ EEI).
Эти две группы интерфейсов определяют спецификации внешнего описания
среды ИС ‐ архитектуру, с точки зрения конечного пользователя, проектировщика ИС,
прикладного программиста, разрабатывающего функциональные части ИС.
Спецификации внешних интерфейсов среды ИС и интерфейсов взаимодействия
между компонентами самой среды ‐ это точные описания всех необходимых функций,
служб и форматов определенного интерфейса.
Совокупность таких описаний составляет эталонную модель взаимосвязи
открытых систем.