Процедура выбора архитектуры

1. Разбейте систему на замкнутые модули.

2. Сравните со стандартными типами архитектур. Улучшите декомпозицию. При этом, если:

• есть поток данных в пакетах между обрабатывающими станциями, то выбирается - Архитектура последовательных данных.

• обрабатывающие станции ожидают получения входных данных, чтобы начать свою работу, то выбирается - Архитектура каналов и фильтров.

• процессы выполняются параллельно, то выбирается - Архитектура параллельных взаимодействующих процессов.

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

• приложение состоит из процессов, которые выполняются по сценарию, то выбирается - Образец проектирования Interpreter.

• приложение строится для хранилища данных, то выбирается - репозиторная архитектура.

• существует упорядочение по уровням, то выбирается - Уровневая архитектура.

Можно предложить еще один способ выбора архитектуры, как продолжение первого:

3. Сделайте выбор среди представленных альтернативных архитектур.

4. Добавьте к классам, полученным на основе анализа требований, классы, обеспечивающие согласование с выбранной архитектурой.

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

5. Примените существующий каркас и (или) образец проектирования, если найдете полезный.

6. Распределите классы по пакетам (4-8 пакетов). Каждый пакет должен иметь смысл в контексте приложения.

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

8. Рассмотрите возможность добавления faç ade – класса (объекта) для управления интерфейсами пакетов.

Распределенные системы

В настоящее время практически все большие программные системы являются распределенными (РС).

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

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

Все современные программные системы делятся на три класса.

· Прикладные программные системы, для работы на одном компьютере или рабочей станции (текстовые процессоры, электронные таблицы, графические системы и т.п.).

· Встроенные системы (системы управления бытовыми устройствами, приборами и т.п.) работающие на одном, либо группе процессоров.

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

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

Выделяются несколько родственных типов архитектур распределенных систем:

1. Многопроцессорная архитектура – самая простая РС, состоящая из множества различных процессов, которые могут (но необязательно) выполняться на разных процессорах. Данная модель часто используется в больших системах реального времени.

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

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

Приведем рекомендации, по применению разных типов архитектуры клиент/ сервер.

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

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

3. Архитектура распределенных объектов

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

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

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

Главным недостатком архитектуры распределенных объектов является сложность их проектирования, по сравнению с системами клиент/сервер.

Детальное проектирование

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

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

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

Типичная схема детального проектирования

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

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

· Совершенствуйте модели, обеспечивая их непротиворечивость

· Для каждого класса определите их инварианты.

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

· Набросайте план модульного тестирования.

· Проинспектируйте планы тестирования и проектирования.

· Запускайте в реализацию.

В унифицированном процессе разработки ПО (USDP – Unified Software Development Process) детальное проектирование имеет место в основном во время итераций проектирования и конструирования. USDP поддерживает три стереотипа классов на уровне анализа, не связанных с классами проектирования: классы сущности, граничные классы и классы управления.

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

Следующим приемом детального проектирования является повторно используемые компоненты, развитию которого способствовало широкое распространение объектно – ориентированных, объектно - подобных и других парадигм компонентов. Примером повторного использования программного кода является применение библиотеки Microsoft MFC, элементов управления Visual Basic, объектов COM, Java Beans и других классов Java API. Стандартом для распределенного повторного использования является архитектура CORBA консорциума OMG. Веб – приложения (не компоненты), также часто бывают повторно используемыми, и, наконец, STL – библиотека стандартных шаблонов, применяется к различным структурам данных и к объектам практически любых классов.

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

⇐ Предыдущая22232425262728293031Следующая ⇒

Поделиться: