02 Архитектура информационных систем. Основы
•Download as PPTX, PDF•
3 likes•1,888 views
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to 02 Архитектура информационных систем. Основы
Similar to 02 Архитектура информационных систем. Основы (20)
02 Архитектура информационных систем. Основы
- 2. Что такое архитектура? • Архитектура определяет структуру • Архитектура определяет поведение • Архитектура фокусирует внимание на существенных элементах • Архитектура является компромиссом потребностей заинтересованных сторон • Архитектура воплощает решение на основе логического обоснования • Архитектура может соответствовать некоторому архитектурному стилю • На архитектуру влияет ее окружение • Архитектура влияет на структуру команды разработчика • Архитектура присутствует в каждой системе • Архитектура принадлежит к определенной сфере (домену) 2
- 3. Что такое архитектура? • Архитектура программно-интенсивной системы – это структура или структуры системы, которые включают • программные элементы, • внешне проявляемые свойства этих элементов и • отношения между ними 3
- 4. Системные структуры • Статические структуры определяют – внутренние проектные элементы и – компоновку (организацию) этих элементов • Динамические структуры определяют – элементы времени выполнения и – взаимодействие этих элементов 4
- 5. Проектные элементы • Программные элементы – Модули, классы, хранимые процедуры, любые другие согласованные программные единицы • Элементы данных – Классы, сущности, таблицы, файлы • Технические элементы – Компьютеры и их части, сетевые элементы (кабели, машрутизаторы, хабы) 5
- 6. Компоновка элементов • Ассоциации, отношения, связность – Для программных модулей • Иерархии, зависимости – Для классов или реляционных сущностей • Связи одних элементов с другими – Для оборудования • Физические соединения 6
- 7. Внутренние взаимодействия • Потоки информации между элементами • Параллельное или последовательное исполнение внутренних задач 7
- 8. Внешне проявляемые системные свойства • Внешне проявляемое поведение – Функциональное взаимодействие между системой и ее окружением • Модель «черный ящик» • Качественные характеристики – Внешне проявляемые нефункциональные свойства • Производительность, безопасность, масштабируемость 8
- 9. Пример. Система резервирования авиабилетов • Назначение – Поддержка различных операций по заказу, бронированию авиабилетов, обновлению заказа или отмены его, оплаты авиабилета и т.п. 9
- 10. Пример. Система резервирования авиабилетов • Внешне проявляемое поведение – Реакции на операции, инициируемые клиентами • Бронирование места • Обновление резервирования • Отмена заказа • Качественные характеристики – Среднее время отклика операции при заданной нагрузке – Максимальная пропускная система – Доступность системы – Время устранение дефектов (проблемы) 10
- 13. Пример. Система резервирования авиабилетов • Статическая структура – Клиентская программа – Сервер – Соединения • Динамическая структура – Модель «запрос/ответ» • Запрос идет от клиента к серверу через сеть • Ответ возвращается от сервера к клиенту через сеть 13
- 14. Пример. Система резервирования авиабилетов • Особенности – Относительная функциональная простота – Меньшее время реализации – Меньшая стоимость 14
- 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
- 29. Точки зрения и представления • Невозможно охватить все функциональные свойства и качественные характеристики сложной системы в одной модели, понятной и полезной одновременно всем заинтересованным сторонам • Сложная система гораздо более эффективно описывается с помощью совокупности взаимосвязанных представлений, которые вместе иллюстрируют её функциональные возможности и качественные характеристики и демонстрируют, что она выполняет свои цели 29
- 30. Архитектурное представление • View • Представление – проекция одного или нескольких структурных аспектов архитектуры, которая показывает, как архитектура решает одну или несколько проблем, принадлежащих одной или более заинтересованным сторонам 30
- 31. Точка зрения • Viewpoint • Точка зрения – набор образцов, шаблонов и соглашений для построения одного типа представления. – Она определяет • заинтересованные стороны, проблемы которых нашли свое отражение в этой точке зрения, и • рекомендации, принципы и шаблоны моделей для построения этих представлений. 31
- 32. Что дают точки зрения и представления • Точки зрения дают – Описание подхода к архитектуре – Набор знаний и опыта – Руководство для архитектора • Представления дают – Структура для описания – Разделение задач – Улучшение взаимодействия с заинтересованными сторонами 32
- 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. Развитие ресурса Желаемое качество Применимость Вопросы, требующие решения Активности Тактики 47
- 49. Интернационализация Желаемое качество Применимость Вопросы, требующие решения Активности Тактики 49
- 52. Регулирование Желаемое качество Способность системы быть полезной людям с физическими ограничениями Применимость Любые системы, которые могут использоваться или управляться людьми с физическими ограничениями Вопросы, требующие решения • видами физических ограничений • функциональная готовность • Регулирование ограничений Активности • определение точек системы сенсорного • устройство независимости • содержание эквивалентности Тактики • помогающие технологии • устройства специалист вход • распознавание речи 52
- 53. Безопасность Желаемое качество Способность системы надежно управлять, контролировать, проверять кто может выполнять какие действия над ресурсами и способность выявлять уязвимости в механизмах безопасности и восстанавливаться после их возникновения Применимость Любые системы с открытыми для свободного доступа интерфейсами, где идентификация пользователя существенна, а доступ к операциям и информации требует контроля Вопросы, требующие решения Политики, угрозы, механизмы, учитываемость, пригодность, обнаружение ошибок, восстановление Активности Определить чувствительные к безопасности ресурсы, политику безопасности, угрозы к системе, оценить риски безопасности, спроектировать систему безопасности Тактики Авторизация доступа, обеспечение информационной тайны, обеспечение целостности информации, защита доступности, интеграция технологий безопасности, применение признанных средств безопасности, использование сторонних средств безопасности 53
- 54. Удобство использования Желаемое качество Простота, легкость, с которой люди могут использовать систему эффективно Применимость Любые системы, которые могут использоваться или управляться людьми с физическими ограничениями Вопросы, требующие решения Юзабилити пользовательского интерфейса, поток бизнес-процесса, качество информации, Активности Тактики 54
- 55. Процесс определения архитектуры • Определение архитектуры – процесс, посредством которого • анализируются и формализуются проблемы и потребности заинтересованных сторон • проектируется отвечающая им архитектура и • составляется ясное и однозначное описание такой архитектуры 55
- 56. Место архитектуры в процессе создания решения 56
- 57. Роль архитектора • Архитектор ответственен за проектирование, документирование и руководство созданием системы, отвечающей нуждам заинтересованных сторон 57
- 58. Специализации • Архитектор продукта • Архитектор предметной области • Архитектор решения • Архитектор предприятия 58
- 59. Архитектор • Технический лидер • Может исполняться командой • Понимает процесс разработки систем • Понимает предметную область • Имеет опыт и навыки проектирования • Имеет опыт и навыки программирования • Хороший коммуникатор • Принимает решения • Осознает организационную политику • Переговорщик 59
- 60. Ответственности • Гарантировать принятие и документирование границ, контекста и ограничений проекта (системы). • Идентифицировать заинтересованные стороны и их потребности. • Способствовать принятию решений на уровне системы, гарантируя, что они сделаны на основе наилучшей информации и увязываются с потребностями заинтересованных сторон. • Выявить и обработать входные данных от технических специалистов и специалистов предметной области (и точно их представить для заинтересованных сторон при необходимости). • Определить и задокументировать структуру и форму системы. • Определить и задокументировать стратегии, стандарты и руководства, направляющие сборку и развертывание системы. • Обеспечить чтобы архитектура отвечала атрибутам качества системы. • Разрабатывать и управлять архитектурными описаниями. • Обеспечивать применение архитектурных принципов и стандартов к готовой системе или продукту • Обеспечивать техническое руководство 60