Downloaded 81 times
Uploaded byEdward Galiaskarov
02 Архитектура информационных систем. Основы
Документ описывает архитектуру информационных систем, включая ее структуру, поведение и влияние на интересы заинтересованных сторон. Он раскрывает важные аспекты проектных элементов, таких как программные и технические компоненты, и примеры систем, таких как система резервирования авиабилетов. Кроме того, рассматриваются архитектурные описания, точки зрения и представления, которые помогают в понимании и разработке архитектуры.
More Related Content
02 Архитектура информационных систем. Основы
- 1.
- 2. Что такое архитектура? •Архитектура определяет структуру • Архитектура определяет поведение • Архитектура фокусирует внимание на существенных элементах • Архитектура является компромиссом потребностей заинтересованных сторон • Архитектура воплощает решение на основе логического обоснования • Архитектура может соответствовать некоторому архитектурному стилю • На архитектуру влияет ее окружение • Архитектура влияет на структуру команды разработчика • Архитектура присутствует в каждой системе • Архитектура принадлежит к определенной сфере (домену) 2
- 3. Что такое архитектура? •Архитектура программно-интенсивной системы – это структура или структуры системы, которые включают • программные элементы, • внешне проявляемые свойства этих элементов и • отношения между ними 3
- 4. Системные структуры • Статическиеструктуры определяют – внутренние проектные элементы и – компоновку (организацию) этих элементов • Динамические структуры определяют – элементы времени выполнения и – взаимодействие этих элементов 4
- 5. Проектные элементы • Программныеэлементы – Модули, классы, хранимые процедуры, любые другие согласованные программные единицы • Элементы данных – Классы, сущности, таблицы, файлы • Технические элементы – Компьютеры и их части, сетевые элементы (кабели, машрутизаторы, хабы) 5
- 6. Компоновка элементов • Ассоциации,отношения, связность – Для программных модулей • Иерархии, зависимости – Для классов или реляционных сущностей • Связи одних элементов с другими – Для оборудования • Физические соединения 6
- 7. Внутренние взаимодействия • Потокиинформации между элементами • Параллельное или последовательное исполнение внутренних задач 7
- 8. Внешне проявляемые системные свойства •Внешне проявляемое поведение – Функциональное взаимодействие между системой и ее окружением • Модель «черный ящик» • Качественные характеристики – Внешне проявляемые нефункциональные свойства • Производительность, безопасность, масштабируемость 8
- 9. Пример. Система резервирования авиабилетов •Назначение – Поддержка различных операций по заказу, бронированию авиабилетов, обновлению заказа или отмены его, оплаты авиабилета и т.п. 9
- 10. Пример. Система резервирования авиабилетов •Внешне проявляемое поведение – Реакции на операции, инициируемые клиентами • Бронирование места • Обновление резервирования • Отмена заказа • Качественные характеристики – Среднее время отклика операции при заданной нагрузке – Максимальная пропускная система – Доступность системы – Время устранение дефектов (проблемы) 10
- 11.
- 12.
- 13. Пример. Система резервирования авиабилетов •Статическая структура – Клиентская программа – Сервер – Соединения • Динамическая структура – Модель «запрос/ответ» • Запрос идет от клиента к серверу через сеть • Ответ возвращается от сервера к клиенту через сеть 13
- 14. Пример. Система резервирования авиабилетов •Особенности – Относительная функциональная простота – Меньшее время реализации – Меньшая стоимость 14
- 15.
- 16. Пример. Система резервирования авиабилетов •Статическая структура – Клиентская программа – Сервер приложения – Сервер баз данных – Соединения • Динамическая структура – Трехуровневая модель «запрос/ответ» • Запрос от клиента идет к серверу приложения, сервер приложения передает запрос серверу баз данных • Ответ от сервера баз данных получает сервер приложения, и если необходимо пересылает его клиенту 16 Альтернативное решение
- 17. Пример. Система резервирования авиабилетов •Особенности – Лучшая масштабируемость при возрастании нагрузки – Меньшие требования к клиентской машине – Лучшая безопасность 17 Альтернативное решение
- 18. Архитектура-кандидат • Архитектура-кандидат – Частныйспособ организации статической и динамической структур, который может потенциально отобразить внешне проявляемое поведение и обеспечить качественные характеристики системы 18
- 19. Важность архитектуры • Каждаякомпьютерная система имеет архитектуру, документирована ли она или нет, понимаема ли она или нет. • Архитектура является неотъемлемым, фундаментальным свойством системы • Каждая система имеет единственную архитектуру, которая может быть представлена разными способами 19
- 20. Архитектурные элементы • Архитектурныйэлемент – Фундаментальная часть системы, из которых она будет построена • Свойства – Ясно определенный набор ответственностей – Ясно определенная граница – Набор ясно определенных интерфейсов • Описывающие услуги, предоставляемые другим элементам 20
- 21. Заинтересованная сторона (в архитектуресистемы) • Заинтересованная сторона – Физическое лицо, группа, организация, • имеющая интерес в реализации этой системы • Озабоченность (интерес) по поводу архитектуры – Требование, цель, намерение, стремление заинтересованной стороны по отношению к архитектуре • Stakeholder 21
- 22. Категории заинтересованных лиц Роль Ответственность ПокупателиКонтроль за приобретением продукта или системы Эксперты Контроль за соответствием стандартам и правовое регулирование Коммуникаторы Объяснение работы системы через документацию и учебные материалы Разработчики Создание и развертывание системы по спецификациям Сопровождение Управление развитием системы во время ее эксплуатации Инженеры Проектирование, развертывание и управление программно- аппаратными средами, в которых система будет построена, испытана и работать Поставщики Создание и/или поставка оборудования, ПО или инфраструктуры, в которых система будет функционировать 22
- 23. Категории заинтересованных лиц Роль Ответственность ПоддержкаОказание поддержки пользователям продукта или системы Системные администраторы Запуск и обслуживание работы системы Тестировщики Проверка системы на годность к использованию Пользователи Определяют функциональность системы и используют ее 23
- 24. Треугольник качества 24 • Архитектурасоздается исключительно для удовлетворения потребностей заинтересованных сторон • Хорошая архитектура та, которая успешно отвечает задачам, целям и потребностям заинтересованных сторон
- 25. Архитектурные описания • Архитектурноеописание (AD) набор артефактов, которые – документируют архитектуры таким образом, чтобы заинтересованные стороны могли понять ее, и – демонстрируют, что архитектура отвечает ожиданиям этих сторон 25
- 26. Архитектурное описание • Архитектурнаямодель • Границы системы • Ограничения • Архитектурные принципы 26
- 27. Архитектурные описания • Хотякаждая система имеет архитектуру, – но не каждая система имеет архитектуру, которая эффективно передается через архитектурное описание • Хорошее архитектурное описание – эффективно и последовательно передает ключевые аспекты архитектуры соответствующих заинтересованных сторон. 27
- 28.
- 29. Точки зрения ипредставления • Невозможно охватить все функциональные свойства и качественные характеристики сложной системы в одной модели, понятной и полезной одновременно всем заинтересованным сторонам • Сложная система гораздо более эффективно описывается с помощью совокупности взаимосвязанных представлений, которые вместе иллюстрируют её функциональные возможности и качественные характеристики и демонстрируют, что она выполняет свои цели 29
- 30. Архитектурное представление • View •Представление – проекция одного или нескольких структурных аспектов архитектуры, которая показывает, как архитектура решает одну или несколько проблем, принадлежащих одной или более заинтересованным сторонам 30
- 31. Точка зрения • Viewpoint •Точка зрения – набор образцов, шаблонов и соглашений для построения одного типа представления. – Она определяет • заинтересованные стороны, проблемы которых нашли свое отражение в этой точке зрения, и • рекомендации, принципы и шаблоны моделей для построения этих представлений. 31
- 32. Что дают точкизрения и представления • Точки зрения дают – Описание подхода к архитектуре – Набор знаний и опыта – Руководство для архитектора • Представления дают – Структура для описания – Разделение задач – Улучшение взаимодействия с заинтересованными сторонами 32
- 33.
- 34. Каталог точек зрения 34 Контекст Функциональность Информация Параллельность Фундаментальная организациясистемы Разработка Размещение Эксплуатация
- 35. Шаблон описания точкизрения 35 Определение Вопросы, требующие решения Модели Заинтересованные стороны Применимость
- 36. Контекст Определение Описывает отношения,зависимости и взаимодействия между системой и ее окружением (людьми, системами и внешними организациями, с которыми она взаимодействует) Вопросы, требующие решения • Границы системы и ее обязанности • Идентичность внешних сущностей и сервисов, используемых данных • Природа и особенности внешних сущностей • Идентичность и ответственности внешних интерфейсов • Природа и характеристики внешних интерфейсов • Другие внешние взаимозависимости • Воздействие системы на окружающую среду • Общая полнота, логичность и согласованность Заинтересованные стороны Все, но в особенности, покупатели, разработчики и пользователи Применимость Все системы 36
- 37. Функциональность Определение Описывает функциональныеэлементы системы и их ответственности, интерфейсы и первичные взаимодействия Вопросы, требующие решения • функциональные возможности • внешние интерфейсы • внутренняя структура • философия функционального проектирования Модели Модель функциональной структуры Заинтересованные стороны Все Применимость Все системы 37
- 38. Информация Определение Описывает способтого, как система хранит, манипулирует, управляет и распространяет информацию Вопросы, требующие решения • информационная структура и содержание • идентификаторы и отображения • модели хранения информации • информационный поток • целостность информации • качество информации • своевременность, задержки и возраст • архивирование и хранение информации Модели • Структурные модели • Модели поток информации • Модели жизненных циклов информации Заинтересованные стороны Пользователи, покупатели, разработчики, тестировщики, сопровождение Применимость Информационные системы 38
- 39. Параллельность Определение Описывает структурупараллельной системы, отображение функциональных элементов на параллельные модули, чтобы четко определить те части системы, которые могут выполняться параллельно, и показать, как это координируется и контролируется Вопросы, требующие решения • структура задач • отображение функциональных элементов на задачи • межпроцессная коммуникация • управление состояниями • синхронизация и целостность • поддержка масштабируемости • запуск и завершение работы • ошибки исполнения задач Модели • Модели параллелизма на системном уровне • Модели состояний Заинтересованные стороны Коммуникаторы, разработчики, тестировщики и системные администраторы Применимость Информационные системы с параллельными потоками исполнения 39
- 40. Разработка Определение Описывает архитектуру,которая поддерживает процесс разработки программного обеспечения Вопросы, требующие решения • организация модулей • общая обработка • стандартизация дизайна • стандартизации тестирования • инструментарий • организация правил кодирования Модели • Модели модульных структур • Общепроектные модели Заинтересованные стороны Инженеры, разработчики и тестировщики Применимость Все программно-интенсивные системы 40
- 41. Размещение Определение Описывает среду,в которой будет развернута система, в том числе зависимости системы от среды выполнения Вопросы, требующие решения • требуемая платформа исполнения • спецификация и количество оборудования • требования к сторонним программным продуктам • технология совместимости • требования к сети • физические ограничения Модели • Модели платформы исполнения • Сетевые модели • Технологические модели Заинтересованные стороны администраторы, разработчики, тестировщики, коммуникаторы, эксперты Применимость Системы со сложной или малознакомой средой развертывания 41
- 42. Эксплуатация Определение Описывает, каксистема будет работать, управляться и сопровождаться во время ее эксплуатации Вопросы, требующие решения • установки и обновления • функциональные миграции • миграция данных • оперативный мониторинг и контроль • предупреждение • управление конфигурацией • мониторинг производительности • поддержка • резервное копирование и восстановление • работы в сторонних сред Модели • модели установки • модели миграции • модели управления конфигурацией • модели управления и поддержки Заинтересованные стороны администраторы, инженеры, разработчики, тестировщики, коммуникаторы, эксперты Применимость Системы со сложной или критичной операционной средой 42
- 43. Архитектурная перспектива • Архитектурнаяперспектива – совокупность мероприятий, тактик и рекомендаций, использование которых гарантирует, что система обладает определенным набором связанных с качеством свойств, которые требуют рассмотрения через ряд архитектурных представлений системы. 43
- 44. Каталог перспектив Доступность Устойчивость Производительность имасштабируемость Безопасность Удобство использования Локализация Эволюция 44
- 45. Доступность Желаемое качество Способностьсистемы быть полезной людям с физическими ограничениями Применимость Любые системы, которые могут использоваться или управляться людьми с физическими ограничениями Вопросы, требующие решения • видами физических ограничений • функциональная готовность • Регулирование ограничений Активности • определение точек системы сенсорного • устройство независимости • содержание эквивалентности Тактики • помогающие технологии • устройства специалист вход • распознавание речи 45
- 46. Устойчивость Желаемое качество Способностьсистемы полностью или частично функционировать при сбоях Применимость Любые системы, требовательные к доступности, имеющие сложные процессы восстановления Вопросы, требующие решения • Классы обслуживания • Плановые и внеплановые простои • Время для ремонта, аварийного восстановления Активности Тактики 46
- 47.
- 48.
- 49.
- 50.
- 51.
- 52. Регулирование Желаемое качество Способностьсистемы быть полезной людям с физическими ограничениями Применимость Любые системы, которые могут использоваться или управляться людьми с физическими ограничениями Вопросы, требующие решения • видами физических ограничений • функциональная готовность • Регулирование ограничений Активности • определение точек системы сенсорного • устройство независимости • содержание эквивалентности Тактики • помогающие технологии • устройства специалист вход • распознавание речи 52
- 53. Безопасность Желаемое качество Способность системы надежноуправлять, контролировать, проверять кто может выполнять какие действия над ресурсами и способность выявлять уязвимости в механизмах безопасности и восстанавливаться после их возникновения Применимость Любые системы с открытыми для свободного доступа интерфейсами, где идентификация пользователя существенна, а доступ к операциям и информации требует контроля Вопросы, требующие решения Политики, угрозы, механизмы, учитываемость, пригодность, обнаружение ошибок, восстановление Активности Определить чувствительные к безопасности ресурсы, политику безопасности, угрозы к системе, оценить риски безопасности, спроектировать систему безопасности Тактики Авторизация доступа, обеспечение информационной тайны, обеспечение целостности информации, защита доступности, интеграция технологий безопасности, применение признанных средств безопасности, использование сторонних средств безопасности 53
- 54. Удобство использования Желаемое качествоПростота, легкость, с которой люди могут использовать систему эффективно Применимость Любые системы, которые могут использоваться или управляться людьми с физическими ограничениями Вопросы, требующие решения Юзабилити пользовательского интерфейса, поток бизнес-процесса, качество информации, Активности Тактики 54
- 55. Процесс определения архитектуры •Определение архитектуры – процесс, посредством которого • анализируются и формализуются проблемы и потребности заинтересованных сторон • проектируется отвечающая им архитектура и • составляется ясное и однозначное описание такой архитектуры 55
- 56. Место архитектуры впроцессе создания решения 56
- 57. Роль архитектора • Архитекторответственен за проектирование, документирование и руководство созданием системы, отвечающей нуждам заинтересованных сторон 57
- 58. Специализации • Архитектор продукта •Архитектор предметной области • Архитектор решения • Архитектор предприятия 58
- 59. Архитектор • Технический лидер •Может исполняться командой • Понимает процесс разработки систем • Понимает предметную область • Имеет опыт и навыки проектирования • Имеет опыт и навыки программирования • Хороший коммуникатор • Принимает решения • Осознает организационную политику • Переговорщик 59
- 60. Ответственности • Гарантировать принятиеи документирование границ, контекста и ограничений проекта (системы). • Идентифицировать заинтересованные стороны и их потребности. • Способствовать принятию решений на уровне системы, гарантируя, что они сделаны на основе наилучшей информации и увязываются с потребностями заинтересованных сторон. • Выявить и обработать входные данных от технических специалистов и специалистов предметной области (и точно их представить для заинтересованных сторон при необходимости). • Определить и задокументировать структуру и форму системы. • Определить и задокументировать стратегии, стандарты и руководства, направляющие сборку и развертывание системы. • Обеспечить чтобы архитектура отвечала атрибутам качества системы. • Разрабатывать и управлять архитектурными описаниями. • Обеспечивать применение архитектурных принципов и стандартов к готовой системе или продукту • Обеспечивать техническое руководство 60
- 61.