79421

Процессы проектирования. Методики описания системной архитектуры

Доклад

Информатика, кибернетика и программирование

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

Русский

2015-02-13

94.71 KB

15 чел.

  1.  

Процессы проектирования. Методики описания системной архитектуры.

IEEE 1471

IEEE 1471 - «Рекомендуемые методы описания архитектуры программных систем». В нем излагается концепция отношений между архитектурой, описанием архитектуры, заинтересованными сторонами, соображениями, точками зрений (разрезами), представлениями и моделями, а также подход к работе с ними.

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

В рамках стандарта формализуются точки зрения на архитектуру системы. Для каждой точки зрения прописаны:

  1.  Описание;
  2.  Назначения;
  3.  Графические модели;
  4.  Риски, которые нужно учитывать с этой точки зрения.

Пример:

Функциональная точка зрения:

  1.  Необходима для описания функциональности ИС, описывает субъекты и их роль, описывает БП, функции пользователей;
  2.  Использует Use Case UML;
  3.  Риски: сложность автоматизации функциональности, реализуемость и тестируемость функциональности.

Другие точки зрения:

  1.  Сценарная точка зрения (динамическое представление ИС);
  2.  Концептуальная точка зрения (основная структура ИС);
  3.  Поведенческая точка зрения;
  4.  Логическая;
  5.  Информационная;
  6.  Точка зрения размещения (связь компонентов ИС с техническими объектами);
  7.  Технологическая точка зрения (формализованное использование технологий, средств разработки, готовых модулей).

(См подробное описание - ссылка)

Модель Захмана

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

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

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

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

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

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

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

Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

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

Основные характеристики данной модели:

  1.  простота для понимания как техническими, так и нетехническими специалистами;
  2.  целостность в отношении предприятия;
  3.  поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
  4.  возможность применения для планирования, позволяющего лучше принимать решения;
  5.  применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия предприятия как целого;
  6.  независимость от конкретных инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.

(подробнее - ссылка)

TOGAF

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

В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML.

Общая структура:

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

  1.  Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
  2.  Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
  3.  Фаза B: разработка бизнес-архитектуры предприятия.
  4.  Фаза C: разработка архитектуры данных и архитектуры приложений.
  5.  Фаза D: разработка технологической архитектуры.
  6.  Фаза E: проверка возможности реализации предложенных решений.
  7.  Фаза F: планирование перехода к новой системе.
  8.  Фаза G: формирование системы управления преобразованиями.
  9.  Фаза H: управление изменением архитектуры.

Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:

  1.  Описание существующей технологической архитектуры.
  2.  Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
  3.  Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
  4.  Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
  5.  Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
  6.  Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
  7.  Формирование целевой технологической архитектуры.
  8.  Описание существующей системы в терминах TOGAF.
  9.  Определение перспектив (представлений) архитектуры.
  10.  Формирование модели целевой архитектуры.
  11.  Определение ИТ-служб (сервисов).
  12.  Подтверждение учета бизнес-требований.
  13.  Определение архитектуры и используемых блоков (шаблонов).
  14.  Проведение анализа расхождений (gap analysis).

 


 

А также другие работы, которые могут Вас заинтересовать

79823. Разработка программного обеспечения контроллера камер со сверхмалым временем экспозиции 681 KB
  В данной дипломной работе было разработано программное обеспечение отладочной платы контроллера видеокамер НПК «Видеоскан», реализующее функции начальной загрузки и сборки компонентов ядра операционной системы для обработки изображений в режиме реального времени.
79824. Становление отечественной оперы во II половине XVIII века 279.5 KB
  Западноевропейская опера в России в XVIII веке. Общеевропейские тенденции развития музыкальной культуры итальянская опера в России. Французская опера в России. Становление отечественной оперы во II половине XVIII века. Начало русской оперы. Фомин и его вклад в развитие русского музыкального театра. Историческое значение русской комической оперы. Тематический анализ оперных спектаклей II половины XVIII века...
79827. Стратегия инновационного развития 75 KB
  Таким образом инновационная стратегия это план на весь процесс от исследований через производство и сбыт до использования инновационного продукта. Кроме того ИП представляет собой сложный неопределенный по своему исходу насыщенный неожиданностями на промежуточных участках трудно прогнозируемый процесс инновационная стратегия должна учитывать необходимость подготовки альтернативных планов. Следовательно стратегия означает программу постоянно учитывающую перспективную цель выбор путей и средств ведущих к ее достижению.
79828. ИСТОЧНИКИ И ЭФФЕКТИВНОСТЬ ФИНАНСИРОВАНИЯ ИННОВАЦИОННЫХ ПРОЦЕССОВ В УСЛОВИЯХ СМЕШАННОЙ ЭКОНОМИКИ 60.5 KB
  Для реализации инновационного проекта как и любого другого замысла требуются в наличии три основных фактора: люди готовые воплотить замысел в жизнь материальная база средства труда финансовые ресурсы. Поэтому ключевой вопрос реализации инновационного проекта вопрос о финансировании. В рамках такой системы в качестве источников финансирования инновационного проекта можно выделить: собственные средства основателей проекта; государственное бюджетные финансирование; кредитные ресурсы. а Собственные средства авторов проекта...
79829. МИРОВОЙ ОПЫТ И СХЕМЫ ФИНАНСИРОВАНИЯ ИННОВАЦИЙ 45.5 KB
  Однако общепризнанно что кредитным ресурсам принадлежит ведущая роль в мировой практике финансирования инновационной сферы. в Кредитный союз Кредитный союз объединение нескольких нуждающихся в финансировании фирм создающих общий фонд финансирования и пользующихся им в качестве залога или резерва совместно по очереди. чиновников и часто используется для финансирования в небольших масштабах.