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

Обновлено: 05.07.2024

Презентация на тему: " Лекция 5. ПАТТЕРНЫ И ФРЕЙМВОРКИ В АРХИТЕКТУРЕ ИС Учебные вопросы: 1. Паттерны 2. Антипаттерны 3. Фреймворки 4. Примеры фреймворков." — Транскрипт:

1 Лекция 5. ПАТТЕРНЫ И ФРЕЙМВОРКИ В АРХИТЕКТУРЕ ИС Учебные вопросы: 1. Паттерны 2. Антипаттерны 3. Фреймворки 4. Примеры фреймворков

3 Паттерны (шаблоны) впервые появились в середине 1990-х гг. как составная часть объектно-ориентированного подхода и рассматривались как набор объектов, организованных определенным образом для решения конкретного класса задач. Основное отличие паттернов от компонентов состоит в том, что компонент является модулем, который после настройки можно включить в состав системы, т.е. его можно рассматривать как готовый к употреблению строительный блок, а паттерн это только заготовка, которую еще надо обработать, т. е. добавить код, определяющий функциональность.

4 Концептуальные паттерны это паттерны, функционирование которых описывается в терминах предметной области. Такие паттерны относятся к приложению в целом или крупным подсистемам ИС. Паттерны проектирования это паттерны, для описания которых используются термины, относящиеся к разработке программных систем, такие как объект, класс, модуль. Паттерны проектирования описывают решение общих проблем в конкретном контексте.

5 Программные паттерны это паттерны, для описания которых используются такие относительно низкоуровневые понятия как деревья, списки и т. п.

6 Архитектурный паттерн (architectural patterns) описывает структуру программной системы и определяет состав подсистем, их основные функции и допустимые способы компоновки подсистем. Архитектурные паттерны называют также архитектурными стилями.

7 Системные паттерны (system patterns) представляют собой приложение на верхнем (системном) уровне. Системные паттерны можно рассматривать как паттерны, использование которых позволяет получить улучшенные архитектурные решения.

8 Структурные паттерны с одинаковой эффективностью применяются как для разделения, так и для объединения элементов приложения. Структурные шаблоны могут быть использованы для решения различных задач. Например, шаблон Адаптер может обеспечить возможность двум несовместимым системам обмениваться информацией, тогда как шаблон Фасад позволяет отобразить упрощенный пользовательский интерфейс, не удаляя ненужных конкретному пользователю элементов управления.

10 Производящие паттерны (creational patterns) предназначены для создания объектов в системе. Паттерны параллельного программирования ориентированы на обеспечение корректного взаимодействия асинхронно протекающих процессов и ориентированы на решение двух основных задач: совместное использование ресурсов и управление доступом к ресурса паттерны это классы проверенных практикой проектных решений, использование которых приводит к положительным результатам.

12 Антипаттерны (antipatterns), также известные как ловушки (pitfalls) это классы наиболее часто внедряемых плохих решений проблем. Они изучаются как категория, в случае, когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем Частью хорошей практики программирования является избегание анти паттернов.

17 Методологические антипаттерны Организационные антипатгерны

19 Фреймворк определяют, как набор типовых решений, методик проектирования и классов, которые могут быть использованы при решении множества сходных задач. В самом широком смысле под фреймворком понимают общепринятые архитектурно-структурные решения и (или) подходы к проектированию ИС. Применительно к программным системам фреймворк, или каркас, представляет собой набор классов или структур, которые описывают решение некоторого класса задач.

20 Фреймворк можно рассматривать как реализацию системы паттернов проектирования. Фреймворк представляет собой скелетное решение достаточно крупной задачи и обычно включает в себя большое количество как паттернов, так и компонентов.

23 Использование инфраструктурных фреймворков упрощает разработку инфраструктурных элементов, таких как, например операционные системы. Обычно такие фреймворки используются внутри организации и не поступают в продажу. Фреймворки, используемые по принципу белого ящика, называют также архитектурными фреймворками (architecture- driving framework). Фреймворк, работающий по принципу белого ящика, определяется через интерфейсы объектов, которые разработчик может добавлять в систему.

24 Фреймворки, используемые по принципу черного ящика, называют также фреймворками, управляемыми данными. В качестве основных механизмов формирования приложения выступают композиция компонентов и параметризация. Фреймворки уровня приложения (application frameworks) обеспечивают полный набор функций, которые реализуются типовыми приложениями. Обычно сюда входят GUI, базы данных, документация. Примером таких фреймворков могут быть MFC (Microsoft Foundation Classes), которые служат для создания приложений, ориентированных на работу в среде MS Windows.

25 Фреймворки уровня домена (Domain frameworks) используются для создания приложений, относящихся к определенному предметному домену.

27 Фреймворк Захмана В основе данного фреймворка лежит классификация (таксономия) артефактов. функционирование организации можно описать в терминах ответа на шесть простых вопросов: что, как, где, кто, когда, почему: используемые данные (что?); процессы и функции (как?); места выполнения процессов (где?); организации и персоналии (кто?); управляющие события (когда?); цели и ограничения, определяющие работу системы (почему?).

28 Фреймворк Захмана Ответы на эти вопросы можно давать с использованием различных понятий, т.е. с разной степенью детализации. При этом выделяется шесть уровней: уровень контекста; уровень бизнес-описаний; системный уровень; технологический уровень; технический уровень; уровень реальной системы.

Распределённые приложения — главный элемент современной индустрии разработки ПО. Они имеют решающее значение для облачных сервисов хранения данных и позволяют веб-приложениям с огромной аудиторией оставаться реактивными. Для того чтобы эффективно проектировать эти системы, программисты используют фундаментальные блоки — паттерны распределённых систем.

Мы рассмотрим пять архитектур распределённых систем, их плюсы, минусы и области применения.

Что такое паттерн распределённой системы?

Паттерны проектирования — это проверенные способы создания систем, каждый из которых подходит для определённого случая. Паттерны абстрактны и не опираются на конкретную реализацию. Большинство паттернов разрабатываются и обновляются множеством разработчиков на протяжении многих лет. Поэтому они зачастую очень эффективны на старте разработки.

Паттерны — это строительные блоки, которые позволяют программистам использовать существующие знания вместо того, чтобы начинать с нуля строительство каждой системы. Кроме того они имеют набор стандартных моделей, которые помогают другим разработчикам понять, как их проекты могут взаимодействовать с данной системой.

Паттерны распределённых систем описывают взаимодействие различных узлов системы и то, как они обрабатывают задачи и виды процессов для различных задач.

Эти паттерны широко используются в архитектуре крупномасштабных облачных вычислений и систем масштабируемых микросервисов.

Типы паттернов распределённых систем

Большинство паттернов распределённых систем попадает в одну из трёх категорий, в зависимости от функциональности с которой они работают:

1. Разделение ответственности на команды и запросы (CQRS)

Этот паттерн предполагает разделение операций чтения и записи для увеличения масштабируемости и безопасности системы. Он использует команды для записи данных в постоянное хранилище (они ничего не возвращают) и запросы для обнаружения и получения данных (не могут изменять данные).

Команды и запросы обрабатываются центром управления, который получает запросы от пользователей. Затем центр получает данные и выполняет необходимые изменения, сохраняет их и уведомляет сервис выполняющий чтение. Этот сервис обновляет модель чтения и показывает изменения пользователю.

Уменьшение сложности системы благодаря делегированию.
Обеспечение чёткого разделения между бизнес-логикой и валидацией.
Разделение ответственности.
Уменьшение количества непредсказуемых изменений распределённых данных.
Уменьшение числа сущностей, которые могут изменять данные.

Требует постоянного взаимодействия между командами и запросами.
Может увеличить задержку при отправке большого количества запросов.
Нет средств связи между сервисными процессами.

Область применения

CQRS отлично подходит для приложений, интенсивно использующих данные, например систем управления базами данных SQL или NoSQL. Также паттерн используется для архитектур микросервисов с большим объемом данных. Он прекрасно подходит для приложений, сохраняющих состояние благодаря разделению на писателя и читателя.

2. Двухфазная фиксация (2PC)

Все сервисы в 2PC по умолчанию заблокированы и не могут отправлять данные. После завершения подготовки координатор по одному разблокирует сервисы и запрашивает их данные. Если сервис не готов подтвердить данные, координатор переходит к другому сервису. Когда все подготовленные данные отправлены сервисы остаются разблокированными и ожидают задачи от координатора.

2PC гарантирует, что одновременно может работать только одна служба, что делает процесс более устойчивым и последовательным, чем CQRS.

Консистентность и устойчивость к ошибкам из-за отсутствия параллельных запросов.
Масштабируемость — может обрабатывать большие пулы данных так же эффективно, как и данные с одного компьютера.
Поддерживает одновременную изоляцию и разделение данных.

Не отказоустойчив, подвержен возникновению узких мест и блокировок из-за своей синхронной природы.
Требует больше ресурсов, чем другие паттерны.

Область применения

2PC лучше всего подходит для распределенных систем, имеющих дело с транзакциями, которые отдают предпочтение точности, а не эффективности использования ресурсов. Он устойчив к ошибкам и позволяет легко отследить ошибки даже в больших объёмах информации.

3. Saga

Saga — это асинхронный паттерн не использующий центр управления. Сервисы здесь сами взаимодействуют между собой. Эта особенность позволяет избавиться от недостатков упомянутых выше паттернов.

Для связи между сервисами в Saga используется шина событий. Шина передаёт запросы между службами, и каждая участвующая служба создает локальную транзакцию. Затем участвующие службы выдают событие для получения другими службами. Все другие службы прослушивают события. Первая служба, получившая событие, выполнит необходимое действие. Если этой службе не удается выполнить действие, оно отправляется в другие службы.

Эта структура похожа на 2PC тем, что службы циклически запускаются, если кто-то не может выполнить задачу. Тем не менее, Saga не использует центр управления, чтобы лучше управлять потоком и уменьшить количество требуемой обратной связи.

Отдельные сервисы могут обрабатывать более долгие транзакции.
Децентрализация отлично подходит для распределённых систем.
Меньше узких мест благодаря одноранговой связи между службами.

Асинхронная независимость делает трудным отслеживание сервисов выполняющих индивидуальные задачи.
Сложный механизм управления затрудняет отладку.
Меньшая изоляция сервисов, чем в предыдущих паттернах.

Область применения

Этот паттерн распределённой системы хорошо подходит для задач, которым требуется масштабируемая беcсерверная архитектура, способная обрабатывать много запросов одновременно. AWS использует подобные решения в AWS Step Functions и AWS Lambda, и других продуктах.

4. Реплицированные сервисы с распределением нагрузки (RLBS)

RLBS — это самый простой и часто используемый шаблон проектирования. На базовом уровне он состоит из нескольких идентичных сервисов, которые общаются с центральным распределителем. Каждый сервис способен выполнять задачи и перезапускать их в случае неудачи. Распределитель получает запросы от конечного пользователя и разделяет их между сервисами, используя round-robin или более сложный алгоритм.

Дублирующие службы обеспечивают высокую доступность приложения для запросов пользователей и могут перераспределять работу в случае сбоя одного экземпляра службы.

RLBS часто используется с Azure Kubernetes, которая представляет собой технологию оркестровки контейнеров с открытым исходным кодом, разработанную Microsoft, которая предлагает автоматическое масштабирование служб в зависимости от воркфлоу.

Стабильная производительность с точки зрения конечного пользователя.
Быстрое восстановление после сбоев.
Высокая масштабируемость через увеличение числа сервисов.
Отличная многопоточность.

Нестабильная производительность, зависящая от алгоритма балансировки.
Управление сервисами требует много ресурсов.

Область применения

RLBS отлично подходит для систем, с которыми пользователи взаимодействуют напрямую. Нагрузка на эти системы в течение дня изменяется, поэтому требуется низкая задержка, например Netflix или Amazon Prime.

5. Шардинг

Альтернативой репликации является создание отдельных сервисов, каждый из которых выполняет определённый тип запросов. Это называется шардингом, потому что вы разделяете запрос на несколько неодинаковых частей. Например, у вас может быть отдельный сервис, который принимает кэширующиеся запросы, а другой сервис будет отвечать за запросы с высоким приоритетом. Распределитель нагрузки обрабатывает каждый запрос и передаёт его в подходящий сервис.

Шардинг сервисов обычно используется для создания сервисов с поддержкой состояния, потому что объём состояния часто слишком большой для одного stateless контейнера. Шардинг позволяет масштабировать отдельные элементы под размер состояния.

Шардинг также позволяет быстрее обрабатывать высокоприоритетные запросы. Сегменты, предназначенные для запросов с высоким приоритетом, всегда доступны для обработки таких запросов в момент их поступления и не требуют размещения запроса в очереди.

Возможность масштабировать сегменты для общих запросов.
Легкая приоритизация запросов.
Простая отладка, благодаря естественной сортировке.

Поддержка большого числа сегментов может потребовать много ресурсов.
Непропорциональное использование сегментов может привести к потерям производительности.

Область применения

Шардинг сервисов хорош в тех случаях, когда ваша система работает с предсказуемой несбалансированной нагрузкой для разных запросов, а некоторые запросы имеют приоритет.

Что дальше?

В статье были рассмотрены лишь несколько паттернов распределённых систем. Вот ещё несколько шаблонов проектирования для изучения:

Рассказываем о распространенных шаблонах в архитектуре ПО.

Архитектурный шаблон — это обобщенное часто используемое решение распространенной задачи в архитектуре ПО в заданном контексте.

Шаблон — это решение задачи в определенном контексте.

Часто разработчики не до конца понимают разницу между архитектурными шаблонами, а иногда вообще мало что о них знают.

Что ж, давайте разбираться!

Каналы и фильтры

Модель — представление — контроллер

Управляемая событиями архитектура

Архитектура на основе микросервисов

Многоуровневая архитектура

Популярный пример n-уровневой архитектуры

Контекст

В любых сложных системах необходимо обеспечивать независимую разработку и развитие отдельных частей. Потому разработчикам необходимо понятное и хорошо задокументированное разделение задач, чтобы модули системы можно было разрабатывать и поддерживать независимым образом.

Задача

Программное обеспечение необходимо разделить так, чтобы модули можно было разрабатывать и развивать отдельно — с минимальным взаимодействием между частями, обеспечивая переносимость, модифицируемость и повторное использование.

Решение

Чтобы добиться такого разделения, при использовании многоуровневого шаблона программное обеспечение разделяется на сущности, называемые уровнями. Каждый уровень — группа модулей, предоставляющих взаимосвязанный набор сервисов. Их применение должно быть однонаправленным. Уровни полностью разделяют ПО, причем каждая часть доступна через публичный интерфейс.

Первая идея заключается в том, что у каждого из уровней есть определенные роль и ответственность. Например, уровень представления данных отвечает за обработку всего пользовательского интерфейса. Такое разделение задач в многоуровневой архитектуре упрощает формирование эффективных ролей и ответственности.

Вторая идея состоит в том, что шаблон многоуровневой архитектуры представляет собой техническое разделение — в отличие от разделения по доменам: то есть, это группы компонентов, а не домены.

И, наконец, третья идея: каждый уровень помечается как закрытый или открытый. Запрос, перемещаясь с уровня на уровень и минуя закрытый уровень, должен обязательно пройти через него — пропустить закрытый уровень нельзя.

Недостатки

Наличие уровней снижает производительность. Этот шаблон не подходит для высокопроизводительных приложений: проходить несколько уровней архитектуры для выполнения бизнес-запроса — это неэффективно.

Кроме того, добавление уровней увеличивает полную стоимость и усложняет систему.

Применение

Использовать этот подход следует для небольших, простых приложений и веб-сайтов. Также этот шаблон хорошо подходит, если бюджет и время ограничены.

Многоярусный шаблон

Контекст

При распределенном развертывании часто необходимо разделить инфраструктуру системы на отдельные подмножества.

Задача

Как разделить систему на ряд независимых в вычислительном отношении исполнительных структур — групп программного и аппаратного обеспечения, объединенных каким-нибудь средством связи?

Решение

Исполнительные структуры многих систем организованы как набор логических групп компонентов. Каждая группа называется ярусом.

Недостатки

Значительные полная стоимость и сложность.

Применение

Используется в распределенных системах.

Каналы и фильтры

Один из часто используемых шаблонов в архитектуре ПО — шаблон каналов и фильтров.

Контекст

Часто в системах необходимо преобразовывать потоки дискретных элементов данных от ввода к выводу. На практике многие типы преобразований повторяются неоднократно, поэтому желательно сделать из них независимые, повторно используемые компоненты.

Задача

Такие системы необходимо разделять на повторно используемые слабо связанные компоненты с простыми обобщенными механизмами взаимодействия — таким образом их можно будет удобно сочетать друг с другом. Слабо связанные компоненты с обобщенным взаимодействием легко использовать повторно. А поскольку они независимы, их выполнение можно запускать параллельно.

Решение

В таком подходе выделяют фильтры четырех видов:

генератор (источник) — отправная точка процесса;

преобразователь (сопоставление) — выполняет преобразование некоторых или всех данных;

испытатель (редуцирование) — проверяет один или несколько критериев;

потребитель (приемник) — конечная точка.

Недостатки

Не лучший выбор для интерактивных систем, поскольку такая архитектура ориентирована на преобразование данных.

Чрезмерное использование синтаксического анализа и синтеза снижает производительность и усложняет написание самих фильтров.

Применение

Архитектура каналов и фильтров применяется в самых разных приложениях, особенно при решении задач, обеспечивающих простую одностороннюю обработку — например, инструменты EDI (электронный обмен данными), ETL (извлечение, преобразование и загрузка).

Пример — компиляторы: последовательно расположенные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

Клиент — сервер

Контекст

Есть общие ресурсы и сервисы, к которым нужно обеспечить доступ большого количества распределенных клиентов, и при этом необходимо контролировать доступ или качество обслуживания.

Задача

Управляя набором общих ресурсов и сервисов, можно обеспечить модифицируемость и повторное использование, для чего общие сервисы выносятся отдельно, чтобы их можно было изменять в одном месте или в небольшом количестве мест. Требуется улучшить масштабируемость и доступность к использованию за счет централизованного управления этими ресурсами и сервисами при одновременном распределении самих ресурсов между несколькими физическими серверами.

Решение

Недостатки

Сервер может быть узким местом в отношении производительности, а также единой точкой отказа.

Изменять принятое решение о размещении функциональных возможностей (на клиенте или на сервере) после создания системы — это обычно сложно и дорого.

Применение

Модель — представление — контроллер

Контекст

Обычно в интерактивном приложении чаще других изменяется пользовательский интерфейс. Пользователям нужно видеть данные в различном представлении — например, как линейчатую или круговую диаграмму, — и оба представления должны отражать текущее состояние данных.

Задача

Как можно отделить функциональность пользовательского интерфейса от функциональности приложения и при этом обеспечить быстрый отклик на действия пользователя и изменения в базовых данных приложения?

Как создавать, поддерживать и координировать несколько представлений пользовательского интерфейса при изменении базовых данных приложения?

Решение

Модель — содержит данные приложения.

Представление — отображает некоторую часть базовых данных и взаимодействует с пользователем.

Контроллер — действует в качестве посредника между моделью и представлением и управляет уведомлениями об изменении состояния.

Недостатки

Для простых пользовательских интерфейсов такая сложность может быть чрезмерной.

Применение

Архитектурный шаблон MVC обычно используется в мобильных и веб-приложениях при разработке пользовательских интерфейсов.

Управляемая событиями архитектура

Контекст

Необходимо предоставить вычислительные и информационные ресурсы для обработки независимых асинхронных входящих событий, формируемых приложением, с возможностью масштабирования по мере потребности.

Задача

Решение

Развернуть независимые процессы или обработчики для работы с событиями. Поступающие события ставятся в очередь. Планировщик извлекает события из очереди и передает их в соответствующий обработчик событий согласно политике планирования.

Недостатки

Возможные проблемные области — производительность и восстановление после ошибок.

Применение

Использующее такой подход приложение для электронной коммерции будет работать следующим образом:

Архитектура на основе микросервисов

Контекст

Задача

При необходимости оптимального использования распределенных ресурсов (например, в облачных средах) монолитные приложения могут оказаться слишком большими и сложными для эффективной поддержки и развертывания.

Решение

Недостатки

Системы должны быть спроектированы так, чтобы выдерживать сбои в работе сервисов, а это требует более тщательного мониторинга систем. Дополнительные расходы ресурсов на организацию работы сервисов и взаимодействия событий.

Кроме того, потребуется больше памяти.

Применение

Архитектура микросервисов применима во многих случаях, особенно когда используется большой конвейер данных. Например, микросервисная архитектура — отличный выбор для системы отчетности о продажах в розничных магазинах компании. Каждый шаг в процессе подготовки данных будет обрабатываться микросервисом: сбор, очистка, нормализация, обогащение, агрегирование данных, отчетность и т. д.

Слайды и текст этой презентации

Лекция №5. ПАТТЕРНЫ И ФРЕЙМВОРКИ В АРХИТЕКТУРЕ ИС

Учебные вопросы:
1. Паттерны
2. Антипаттерны
3. Фреймворки
4. Примеры фреймворков

Паттерны (шаблоны) впервые появились в середине 1990-х гг. как составная часть объектно-ориентированного подхода и рассматривались как набор объектов, организованных определенным образом для решения конкретного класса задач.

Основное отличие паттернов от компонентов состоит в том, что компонент является модулем, который после настройки можно включить в состав системы, т.е. его можно рассматривать как готовый к употреблению строительный блок, а паттерн — это только заготовка, которую еще надо обработать, т. е. добавить код, определяющий функциональность.

Концептуальные паттерны — это паттерны, функционирование которых описывается в терминах предметной области. Такие паттерны относятся к приложению в целом или крупным подсистемам ИС.

Паттерны проектирования — это паттерны, для описания которых используются термины, относящиеся к разработке программных систем, такие как объект, класс, модуль. Паттерны проектирования описывают решение общих проблем в конкретном контексте.

Программные паттерны — это паттерны, для описания которых используются такие относительно низкоуровневые понятия как деревья, списки и т. п.

Архитектурный паттерн (architectural patterns) описывает структуру программной системы и определяет состав подсистем, их основные функции и допустимые способы компоновки подсистем. Архитектурные паттерны называют также архитектурными стилями.

Системные паттерны (system patterns) представляют собой приложение на верхнем (системном) уровне. Системные паттерны можно рассматривать как паттерны, использование которых позволяет получить улучшенные архитектурные решения.

Структурные паттерны с одинаковой эффективностью применяются как для разделения, так и для объединения элементов приложения.
Структурные шаблоны могут быть использованы для решения различных задач. Например, шаблон Адаптер может обеспечить возможность двум несовместимым системам обмениваться информацией, тогда как шаблон Фасад позволяет отобразить упрощенный пользовательский интерфейс, не удаляя ненужных конкретному пользователю элементов управления.

Производящие паттерны (creational patterns) предназначены для создания объектов в системе.

Паттерны параллельного программирования ориентированы на обеспечение корректного взаимодействия асинхронно протекающих процессов и ориентированы на решение двух основных задач: совместное использование ресурсов и управление доступом к ресурса

паттерны — это классы проверенных практикой проектных решений, использование которых приводит к положительным результатам.

Антипаттерны (antipatterns), также известные как ловушки (pitfalls) — это классы наиболее часто внедряемых плохих решений проблем.

Они изучаются как категория, в случае, когда их хотят избежать в будущем, и некоторые отдельные случаи их могут быть распознаны при изучении неработающих систем

Частью хорошей практики программирования является избегание антипаттернов.

Антипаттерны в управлении разработкой ПО и их свойства

Антипаттерны в разработке ПО

Антипаттерны в объектно-ориентированном проектировании

Антипаттерны в области программирования

Фреймворк определяют, как набор типовых решений, методик проектирования и классов, которые могут быть использованы при решении множества сходных задач.

В самом широком смысле под фреймворком понимают общепринятые архитектурно-структурные решения и (или) подходы к проектированию ИС.

Применительно к программным системам фреймворк, или каркас, представляет собой набор классов или структур, которые описывают решение некоторого класса задач.

Фреймворк можно рассматривать как реализацию системы паттернов проектирования.

Фреймворк представляет собой скелетное решение достаточно крупной задачи и обычно включает в себя большое количество как паттернов, так и компонентов.

Фреймворки уровня промежуточного ПО используются для интеграции распределенных приложений и компонентов.

Фреймворки, ориентированные на приложения, используются, в первую очередь, для поддержания процесса разработки систем, ориентированных на конечного пользователя и принадлежащих некоторому конкретному предметному домену.

Использование инфраструктурных фреймворков упрощает разработку инфрастуктурных элементов, таких как, например операционные системы. Обычно такие фреймворки используются внутри организации и не поступают в продажу.

Фреймворки, используемые по принципу белого ящика, называют также архитектурными фреймворками (architecture-driving framework). Фреймворк, работающий по принципу белого ящика, определяется через интерфейсы объектов, которые разработчик может добавлять в систему.

Фреймворки, используемые по принципу черного ящика, называют также фреймворками, управляемыми данными. В качестве основных механизмов формирования приложения выступают композиция компонентов и параметризация.

Фреймворки уровня приложения (application frameworks) обеспечивают полный набор функций, которые реализуются типовыми приложениями. Обычно сюда входят GUI, базы данных, документация. Примером таких фреймворков могут быть MFC (Microsoft Foundation Classes), которые служат для создания приложений, ориентированных на работу в среде MS Windows.

Фреймворки уровня домена (Domain frameworks) используются для создания приложений, относящихся к определенному предметному домену.

В основе данного фреймворка лежит классификация (таксономия) артефактов. функционирование организации можно описать в терминах ответа на шесть простых вопросов: что, как, где, кто, когда, почему:
используемые данные (что?);
процессы и функции (как?);
места выполнения процессов (где?);
организации и персоналии (кто?);
управляющие события (когда?);
цели и ограничения, определяющие работу системы (почему?).

Ответы на эти вопросы можно давать с использованием различных понятий, т.е. с разной степенью детализации. При этом выделяется шесть уровней:
уровень контекста;
уровень бизнес-описаний;
системный уровень;
технологический уровень;
технический уровень;
уровень реальной системы.

ГОСТ

Виды архитектуры информационной системы

Любая информационная система (ИС) включает в себя три компонента:

Управление данными;
Бизнес-логику;
Пользовательский интерфейс.

Данные хранятся в базах данных, а управление ими осуществляется с помощью системы управления базами данных (СУБД). Бизнес-логика определяет правила, по которым обрабатываются данные. Она реализуется набором процедур, написанных на различных языках программирования. Пользователь работает с интерфейсом, где логика работы ИС представлена в виде элементов управления – полей, кнопок, списков, таблиц и т.д.

Однако, эти три компонента в разных ИС взаимодействуют друг с другом различными способами.

Архитектурой информационной системы называется концепция, согласно которой взаимодействуют компоненты информационной системы.

Существуют следующие виды архитектур ИС:

Локальная;
Файл-серверная;
Клиент-серверная;
Трехслойная.

Локальные информационные системы

Локальные информационные системы широко использовались до появления компьютерных сетей. В этом случае все компоненты ИС располагаются на одном компьютере. Очевидным недостатком этой архитектуры является возможность работать в ИС только одному пользователю. Другие пользователи не имеют возможности получить доступ к данным даже для чтения.

Файл-серверная архитектура

С появлением компьютерных сетей возникла возможность хранить данные в файлах на выделенном специально для этой цели компьютере. Такой компьютер называется файловым сервером или просто сервером. Компьютеры пользователей соединены с сервером сетью, поэтому доступ к данным, могут получить несколько пользователей одновременно. Однако, кроме функции хранения данных и обеспечения доступа к ним, сервер никаких функций не выполняет. Приложения, обрабатывающие данные, находятся на пользовательских компьютерах.

Готовые работы на аналогичную тему

Предположим, что в базе данных на сервере хранится список сотрудников крупного предприятия. На предприятии 1500 сотрудников и 10 подразделений. Пользователю нужно получить число сотрудников, работающих в каждом подразделении. Для решения этой задачи пользователь должен запросить данные всех 1500 сотрудников с сервера по сети, после чего на пользовательском компьютере выполнится процедура, которая осуществит подсчет сотрудников в каждом подразделении. Результатом процедуры будет 10 строк. Таким образом, чтобы получить 10 строк придется передать по сети 1500 строк.

высокая загруженность сети и, как следствие, низкая скорость работы;
сложность поддержания непротиворечивости данных, из-за их несогласованной обработки разными пользователями.

Клиент-серверная архитектура

До определенного момента на СУБД возлагались лишь задачи хранения данных и организации доступа к ним. С развитием технологий в состав СУБД разработчики стали включать новый компонент – процедурный язык программирования. С его помощью в СУБД стало возможным создавать процедуры для обработки данных, которые можно вызывать повторно. Такие процедуры называются хранимыми процедурами. Наличие хранимых процедур дало возможность осуществлять некоторую часть обработки данных на сервере.

Рассмотрим задачу из примера 1 в условиях клиент-серверной архитектуры. Пользователь отправит на сервер запрос, который запустит процедуру. Процедура выполнится непосредственно на сервере. Она подсчитает количество сотрудников в каждом подразделении и отправит полученные 10 строк по сети на клиентский компьютер. Таким образом, произойдет существенная экономия трафика: вместо 1500 строк будет передано по сети всего 10.

Клиент-серверная архитектура позволяет разгрузить сеть и поддерживать непротиворечивость данных за счет их централизованной обработки. Однако, языки хранимых процедур не приспособлены для полноценной реализации бизнес-логики. Поэтому бизнес-логика в клиент-серверных ИС по-прежнему реализуется на клиентских компьютерах. Такой подход имеет следующие недостатки:

любые изменения в бизнес-логике требуют обновления на клиентском компьютере;
клиентские компьютеры должны быть достаточно производительными;
слабая защита данных от взломов.

Трехуровневая архитектура

Все недостатки клиент-серверной архитектуры связаны с тем, что на клиентском компьютере лежит слишком большая нагрузка, которую можно было бы перенести на сервер. Поэтому дальнейшее развитие технологий двигалось в направлении переноса нагрузки с клиентских компьютеров на сервер. В дополнение к хранимым процедурам разработчики стали использовать серверные языки программирования. Это дало возможность создавать в ИС промежуточный уровень - сервер приложений.

Сервер приложений – это комплекс программ, выполняемых на сервере и реализующих бизнес-логику ИС .

Использование сервера приложений позволяет максимально разгрузить клиентские компьютеры и сделать обработку данных еще более централизованной, что повышает скорость и надежность ИС.

Читайте также: