Опубликован: 16.02.2010 | Доступ: свободный | Студентов: 1469 / 168 | Оценка: 4.21 / 4.00 | Длительность: 06:28:00
Лекция 3:

Действия

< Лекция 2 || Лекция 3: 123 || Лекция 4 >

Разработка архитектуры решения

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

Разделение системы на подсистемы Выберите архитектурные шаблоны
Определение интерфейсов Разработайте интерфейсы
Разработка модели угроз Создайте обзор приложения
Разработка модели производительности Проведите обзор требований к качеству
Создание архитектурной модели Изучите риски
Создание архитектуры инфраструктуры Разработайте архитектуру инфраструктуры

Операция: Разделение системы на подсистемы

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

Для создания гибкой архитектуры в MSF применяется создание временного прототипа ( shadowing ). Приложение-прототип ( shadow ) позволяет применить принцип нисходящего проектирования в любой итерации. В начале итерации, когда существует лишь проект, прототип опережает рабочий программный код. В этот период проектные конструкции не синхронизованы с кодом. В рамках прототипа выполняются все изменения архитектуры или дизайна, которые необходимы для предохранения основного кода от превращения его в "дымоход", "спагетти-код" и прочих проблем, связанных с плохим проектированием. По мере реализации элементов начального предваряющего прототипа ( leading shadow ), архитектура все больше соответствует рабочему коду. Те части системы, которые были спроектированы, но не были реализованы, теперь становятся действительными. Когда архитектура соответствует рабочему коду, прототип называется завершающим ( trailing shadow ). Это сумма конструкций из всех предыдущих итераций.

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

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

Операция: Определение интерфейсов

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

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

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

Операция: Разработка модели угроз

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

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

Операция: Разработка модели производительности

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

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

Операция: Создание архитектурной модели

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

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

Операция: Создание архитектуры инфраструктуры

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

Создание архитектуры инфраструктуры Создайте логическую диаграмму центра обра ботки данных. Работайте с операциями, если они применимы, для лучшего понимания рабочего окружения. В логическом центре обработки данных создайте логические серверы, отражающие физическое окружение. Проверьте получившуюся диаграмму
Сопоставление архитектуры решения Отобразите участки диаграммы приложения на логическую диаграмму центра обработки данных. Проверьте правильность этого отображения. Проверьте диаграмму приложения при помощи логической диаграммы центра обработки данных
Корректировка архитектуры решения По мере определения новых подсистем выявляйте необходимые изменения в архитектуре инфраструктуры
< Лекция 2 || Лекция 3: 123 || Лекция 4 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?