• Разработчик архитектуры

• Разработчик архитектуры

• Document Service Realization Decisions

• Identify Security Patterns
• Архитектурный анализ

• Оценка жизнеспособность концепции архитектуры

• RUP Service-Oriented Modeling and Architecture  >  Specification  >  Perform Service Specification  >  Document Service Non-Functional Requirements  >  Reference Architecture
• RUP Service-Oriented Modeling and Architecture  >  Realization  >  Realization Decisions  >  Reference Architecture
• Service Realization  >  Realization Decisions  >  Reference Architecture
• Service Realization  >  Reference Architecture
• Service Specification  >  Perform Service Specification  >  Reference Architecture
• Service Specification  >  Reference Architecture
• Анализ и проектирование  >  Определение предполагаемой архитектуры  >  Контрольная архитектура
• Анализ и проектирование  >  Синтез архитектуры  >  Контрольная архитектура

Организация ресурсов

Организации, владеющей ресурсами контрольной архитектуры, потребуется решить, как следует классифицировать и организовать ресурсы, чтобы их легко мог получить архитектор программного обеспечения в соответствии с критериями выбора для создаваемой системы. Хотя создание и хранение контрольных архитектур в настоящее время находится за рамками RUP, можно дать совет организовывать эти архитектуры в соответствии с идеей Определение термина: домен, где домен - это предметная область, определяющая знания и понятия для некоторого аспекта системы или для семейства систем. Здесь термин 'домен' применяется на уровнях ниже уровня приложения. Это использование термина несколько отличается от некоторых других определений - например, представленному в [HOF99] - однако хорошо соответствует определению, представленному в [LMFS96]:

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

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

Горизонтальные и вертикальные домены для армии США

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

Содержимое

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

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

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

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

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

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

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

Организация ресурсов

Организации, владеющей ресурсами контрольной архитектуры, потребуется решить, как следует классифицировать и организовать ресурсы, чтобы их легко мог получить архитектор программного обеспечения в соответствии с критериями выбора для создаваемой системы. Хотя создание и хранение контрольных архитектур в настоящее время находится за рамками RUP, можно дать совет организовывать эти архитектуры в соответствии с идеей домены, где домен - это предметная область, определяющая знания и понятия для некоторого аспекта системы или для семейства систем. Здесь термин 'домен' применяется на уровнях ниже уровня приложения. Это использование термина несколько отличается от некоторых других определений - например, представленному в [HOF99] - однако хорошо соответствует определению, представленному в [LMFS96]:

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

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

Горизонтальные и вертикальные домены для армии США

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

Содержимое

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

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

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

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

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

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

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

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