Доклад и реферат по теме системной инженерии "Управление архитектурой при проектировании систем"

Системная инженерия

Управление архитектурой при проектировании систем

Купин Станислав

Симкин Анатолий

Группа 9111

26.11.2009

Вставьте

картинку

Вставьте

картинку

1

Содержание

1. Архитектура, ее место в ЖЦ и особенности ее

технического процесса

2. Процесс описания и проектирования архитектуры

Что такое архитектура?

2

This is NOT Architecture!

This is the RESULT of Architecture.

Источник: статья Architecture Is Architecture Is Architecture by John A. Zachman

Особенности архитектуры

●Архитектура определяет важнейшие компоненты

●Архитектура определяет как компоненты связаны между собой (структуру) и как они между собой взаимодействуют, используя эти связи

●Архитектура не рассматривает информацию об устройстве компонентов безотносительно к их взаимодействию между собой

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

3

V- образная модель проектирования архитектуры

4

User

Requirements &

Concept of

Operations

System

Requirements &

Architecture

Component

Design

Procure, Fabricate,

& Assemble Parts

Component

Integration & Test

System

Integration & Test

System

Demonstration &

Validation

Component

Engineering

Domain

Systems

Engineering

Domain

Источник: презентация Systems Engineering Overview by Karl Arunski and James Martin

Уровни архитектурных описаний

5Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем ч.2

Концептуальное, логическое и физическое проектирование

●A conceptual design is an abstract or high level design which includes

only the most important components and entities.

● The main goal of a conceptual design is to provide an understandable

picture of the overall purpose of the proposed solution.

●A logical design is a more detailed design which includes all major

components and entities plus their relationships.

● The data flows and connections are detailed in this stage. The target

audience is typically developers or other systems architects.

6

Концептуальное, логическое и физическое проектирование

●A physical design has all major components and entities identified

within specific physical servers and locations or specific software

services, objects, or solutions.

● Include all known details such as operating systems, version numbers,

and even patches that are relevant.

7

ISO 15288: «Что делать?»

Обеспечения проектов• управление описанием

жизненного цикла• управление инфраструктурой

• управление портфелем проектов (программой)

• управление персоналом

• управление качеством

Технические• Cбор требований• Анализ требований

• Архитектурный дизайн • Изготовление

• Интеграция • Проверка (Verification) • Переход к эксплуатации

• Приёмка (Validation) • Эксплуатация

• Обслуживание • Вывод из эксплуатации

Проектные• Управление проектами• Планирование проекта

Управление выполнением и контроль проекта• Поддержка проектов

• Управление решениями • Управление рисками • Управление конфигурацией

• Управление информацией • Измерения

8

25 важнейших процессов СИ

9

Архитектурный подход (ISO/IEC 42010, IEEE 1471)

Стандарт IEEE 1471 Института инженеров-электриков и электронщиков (он же ISO/IEC 42010) предоставляет метамодель для определения архитектуры.

10

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

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

● Каждое описание системы входит в какую-либо тематическую группу описаний (чаще всего в одну такую группу), порождённую одним методом описания.

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

Архитектурный подход

11

● К созданию целостного описания системы можно прийти только в рамках определённого подхода, или совокупности подходов (frameworks).

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

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

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

Архитектурный подход

Вставьте

картинку

12


1. Архитектура, ее место в ЖЦ и особенности ее

технического процесса

2. Процесс описания и проектирования архитектуры

Технические процессы

13

Технические процессы

Определение требований правообладателей

Анализ требований

Проектирование архитектуры

Реализация элементов

Комплексирование

Верификация

Передача

Валидация

Функционирование

Обслуживание

Изъятие и списание

Источник: ISO/IEC 15288

Применение технических процессов

14Источник: ISO/IEC TR 19760

Процесс проектирования архитектуры

15

Действия•Определение логической

архитектуры• Детализация требований к

системе•Оценка потребности в покупных

элементах•Оценка альтернативных

проектных решений•Документирование

интерфейсов

Ресурсы•Инфраструктура предприятия

• Политики, процессы и стандарты предприятия

Выходы•Исходная версия

проекта архитектуры•Описания

элементов системы•Требования к интерфейсам•Стратегия

верификации•План

комплексирования (сборки) системы•Следующая версия

RVTM

Входы•Функциональные

требования и показатели

•Ограничения на архитектуру

• Исходная RVTM•Описание

взаимодействий в системе

Управление•Соглашения и договоры•Проектные процессы и

процедуры

Источник: SYSTEMS ENGINEERING HANDBOOK version 3.1

Логическая и физическая архитектура

16

● The logical architecture is a more detailed structure defines what

has to be done to support the user services. It defines the

processes that perform functions and the information or data

flows that are shared between these processes. Logical

architecture do not include physical server names or addresses.

They do include any business services, application names and

details, and other relevant information for development purposes.

●A physical architecture has all major components and entities

identified within specific physical servers and locations or

specific software services, objects, or solutions. Include all

known details such as operating systems, version numbers, and

even patches that are relevant. Any physical constraints or

limitations should also be identified within the server

components, data flows, or connections. This design usually

precludes or may be included and extended by the final

implementation team into an implementation design.

17

Логическая архитектура системы

●Логическая архитектура представляет

собой функциональную структуру, которая

в течение ЖЦ дает возможность системе

для реализации всех заданных сценариев

функционирования.

●Сценарии функционирования ставят в

соответствие целям системы цепочки

выполняемых задач.

Источник: В.К. Батоврин Лекции по системной инженерии. Процессы ЖЦ систем .

18

Физическая архитектура системы

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

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

●Конкретные характеристики элементов определяются их природой (программа, человек, оборудование, аппаратное средство…), в абстрактном смысле элемент характеризуется своим назначением и своими целями.



19

Источник: ITAG - Information Technology Architecture Group. MIT Architecture

Пример логической архитектуры

20

SAP DB

(Oracle)

Users

SAP ITS

SAP ClientBrowser

Client

(SAP WEB)

System

Component

Key:

Related

System

Other MIT

System

SAP Application Server

Kerberos

Server

Au

the

ntic

atio

nfo

r SA

P C

lien

ts

External

Systems

Other MIT Systems

Incoming:

Data Warehouse

Roles DBSAP - Lincoln Lab

Mainframe

COEUS

MIT ID

Broad Institute

Outgoing:

Data Warehouse

Archive (IX0S)

Server Broad Institute

MIT ID (Real Time)

External Systems

Incoming: Benefit Providers

Financial Institutions

EDI

Outgoing:

ECAT Vendors


Benefits Providers

Financial

Accounting

Materials

Management

ControllingSales and

Distribution

Profit Center

Account

Classification

System

Human

ResourcesPayroll

Labor

Distribution

Cross

Application

X509 Certificates

Drop

Box

SAP Web

Classic

Plant

Maintenance

Training Events

Management

Пример физической архитектуры

21Источник: ITAG - Information Technology Architecture Group. MIT Architecture

Проектирование логической архитектуры

●Данное действие включает идентификацию и определение

производных требований для описания функциональных и

эксплуатационных требований, функциональных

возможностей и свойств, требований к своевременности, к

потокам данных и т.д. в соответствии с логической

архитектурой.

●Перед разделением логической архитектуры на физические

элементы, противоречия внутри и между различными

логическими описаниями должны быть разрешены и каждая

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

завершенном и непротиворечивом виде посредством

проведения проверок совместимости с заданными

системными требованиями.

22

Этапы логического проектирования

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

функций в их подфункции;

b. диаграмма информационного потока, которая раскладывает функции на

составные части, явно демонстрируя данные, необходимые для каждой функции;

c. структура данных с соответствующими им функциями и потоки обработки данных,

относящиеся к данным и связанные с назначенными техническими требованиями;

d. диаграмма режима работы, которая описывает входные воздействия и

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

функционирования, соответствующий критериям входа или выхода;

e. диаграмма управления, которая показывает факторы управления функции и

результирующее поведение;

f. состояния и режимы системы;

g. график времени, который предъявляет требование времени к набору функций;

h. режимы функционального сбоя и таблица эффектов, которая указывает

возможные эффекты режима функционального сбоя, например, невыполнение

того, что предназначено для выполнения, или выполнение функции, выполнения

которой не ожидалось. Следует сформировать возможные решения для каждого

режима сбоя;

i. цели, которые формируют разбиение и отображение технических требований и

характеризуются услугами (режимы работы, функции и операции),

предоставляемыми скрытыми атрибутами (значения, характеристики и данные);

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

Концептуальная модель БЗ IBS

24

Концептуальная модель БЗ IBS

25

Общая схема навигации

26

27

Модель двух пиков


Существующие методологии описания АП

●RUP (4+1)

●DODAF

● Zachman AF

● FEAF

● TEAF

●…

28

Что такое Framework?

●«Architecture frameworks address what it means to define and document an architecture» (http://www.software.org)

●Это различные подходы или рамочные модели, методики

●Методики задают классификацию основных областей

архитектуры и единые принципы для их взаимосвязного

описания

●Описания используются для определения различных

элементов архитектуры на разных уровнях абстракции

29

Зачем нужен Framework?

● «Fundamentally, the problem is communication»

●Они позволяют решить проблему плохого взаимопонимания

между вовлеченными в этот процесс людьми, поскольку

задают некий общий, одинаково понимаемый набор понятий

и моделей для описания элементов архитектуры в интересах

различных категорий заинтересованных сторон.

●Методики не только задают набор документов и планов,

необходимых для описания предприятия, но и определяют,

как все эти элементы описания связаны между собой.

30

Три компонента Frameworks

●Views

Provides the mechanisms for communicating information about the

relationships that are important in your architecture

●Methods

Provides the discipline to gather and organize the data and

construct the views in a way that helps insure integrity, accuracy

and completeness

● Training/Experience

Supports the application of method and use of tools

31

Три компонента Frameworks

32

Complexity

Training&

ExperienceViews

Methods

Zachman EF

33

FEAF

34

DoDAF

35

DoDAF in Zachman

36

-103-

В TOGAF v. 9.0 сохранился: Метод разработки

архитектуры (Architecture Development Method)

Архитектурное

видение

Архитектура

бизнеса

Архитектуры

ИС

Технологическая

архитектура

Возможности и

решения

Планирование

перехода

Управление

внедрением


изменениями

Предварительная

стадия


требованиями

• Предварительная стадия (Preliminary Phase) описывает инициацию процесса и подготовительную деятельность, необходимую для подготовки бизнеса, включая определение специфической для организации архитектурной структуры и основных принципов.

• Стадия A: Архитектурное видение (Architecture Vision)описывает начальную стадию цикла разработки архитектуры и включает определение границ описания, заинтересованных лиц, формирование архитектурного видения и получение одобрения со стороны менеджмента.

• Стадия B: Архитектура бизнеса (Business Architecture)описывает процесс разработки Архитектуры Бизнеса на основе согласованного Архитектурного видения.

• Стадия C: Архитектуры Информационных систем(Information Systems Architectures) описывает процесс разработки архитектур информационных систем, включая архитектуры данных и приложений для архитектурного проекта.

• Стадия D: Технологическая архитектура (Technology Architecture) описывает процесс разработки Технологической архитектуры для архитектурного проекта.

• Стадия E: Возможности и решения (Opportunities & Solutions) определяет план и способы внедрения архитектурных процессов предыдущих стадий.

• Стадия F: Планирование перехода (Migration Planning)занимается формализацией системы последовательности переходных архитектур, включая поддержку внедрения и планы переходов.

• Стадия G: Управление внедрением (Implementation Governance) обеспечивает архитектурный надзор за внедрением.

• Стадия H: Управление изменениями архитектуры (Architecture Change Management) устанавливает процедуры для управления изменениями архитектуры.

• Управление требованиями (Requirements Management) контролирует осуществление управления требованиями сквозь весь процесс ADM.

TOGAF

37

TOGAF and ArchiMate

● Business Architecture Views, which address the concerns of the users of the system, and describe the flows of business information between people and business processes (e.g. People View, Process View, Function View, Business Information View, Usability View, Performance View).

● Information Systems Architecture views, comprising Data Architecture views and Applications Architecture views, address the concerns of the database designers and administrators, and the system and software engineers of the system. They focus on how the system is implemented from the perspective of different types of engineers (security, software, data, computing components, communications), and how that affects its properties. Systems and software engineers are typically concerned with modifiability, re-usability, and availability of other services.

● Technology Architecture views address the concerns of the acquirers, operators, communications engineers, administrators, and managers of the system.

● Composite views, such as the Enterprise Manageability Views, addressing the concerns of systems administrators, operators and managers, and Enterprise security view

38

Примеры: Business Layer Concepts

● The main structural concepts at the business layer are business roles and

business actors, an entity that performs behavior such as business processes

or functions. A business role signifies responsibility for one or more business

processes or business functions. A business function denotes the high-level

capabilities of an organization, and offers functionality that may be used in

business processes to realize the products and services of the organization.

Business functions can be connected through flows that describe the

information or goods exchanged.

39

Примеры: Business Layer Concepts

● A business role is typically assigned to a business actor. Business actors may be individual

persons (e.g. customers or employees), but also groups of people and resources that have a permanent (or at least long-term) status within the organizations. Business processes, which may be triggered by events and manipulate business objects, describe the business behaviour

of a role. The externally visible behaviour of a business process is modelled by the concept of business service, which represents a unit of functionality that is meaningful from the point of

view of the environment. Not shown in the example is that services can be grouped to form (financial or information) products, together with a contract that specifies the associated characteristics, rights and requirements.

40

Примеры: Application Layer Concepts

● The main structural concept for the application layer is the application component. This

concept can be used to model any structural entity in the application layer: not just (reusable) software components that can be part of one or more applications, but also complete software applications or information systems. Behaviour in the application layer can be described in a

way that is very similar to business layer behaviour. Again, we make a distinction between the externally visible behaviour of application components in terms of application services, and

the internal behaviour, application functions, that realise these services1. Services are offered through the application interfaces of an application. Data objects are used in the same way as data objects (or object types) in well-known data modelling approaches, most notably the

‘class’ concept in UML class diagrams.

41

Примеры: Application Layer Concepts

42

Спасибо за внимание!

Купин Станислав

Симкин Анатолий

Группа 9111

26.11.2009

Вставьте

картинку

Системная инженерия. Управление архитектурой при проектировании систем

Учебный процесс Магистратуры IBS. Академия IBS.

Дата вступления в силу: 26.11.2009 Версия: 4 Стр: 1/10

Реферат по курсу «Системная инженерия»

«Управление архитектурой при проектировании

систем»

Подготовил: Анатолий Симкин, Станислав Купин

Проверил: Батоврин Виктор Константинович


Введение в понятие Архитектуры ................................................................................................................................................................1

Что такое архитектура?...............................................................................................................................................................................1

Особенности архитектуры .........................................................................................................................................................................1

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

Процесс проектирования архитектуры .......................................................................................................................................................4

Технические процессы ISO/IEC 15288 ...................................................................................................................................................4

Применение технических процессов ......................................................................................................................................................5

Процесс проектирования архитектуры ..................................................................................................................................................6

Логическая и физическая архитектура ...................................................................................................................................................8

Проектирование логической архитектуры ............................................................................................................................................9

Введение в понятие Архитектуры

Что такое архитектура?

Колизей в Риме – не есть архитектура (см. рисунок Рисунок 1). Это Результат архитектуры. Результат это следствие архитектуры. Этот тезис доказывает следующим примером: если бы архитектор не создал описательную модель (архитектуру) в каком-либо из видов, то римляне не смогли бы построить само здание. Они бы даже не смогли заказать камни для его постройки. Вывод в том, что создание сложных систем без создания их архитектуры занятие практически невозможное. А если и возможное, то это существенным образом повлияет на процесс создания, качество системы и ее стоимость.

Особенности архитектуры

Архитектура обладает некоторыми особенностями:

o Архитектура определяет важнейшие компоненты

o Архитектура определяет, как компоненты связаны между собой (структуру) и как они между собой взаимодействуют, используя эти связи




o Архитектура не рассматривает информацию об устройстве компонентов безотносительно к их взаимодействию между собой

o Каждая система имеет архитектуру (даже в том случае, когда система состоит из одного компонента)

o Архитектура определяет логическое обоснование связи между компонентами и структурой

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

o Архитектура это не только взаиморасположение частей системы – сведения о взаимном расположении частей системы не задают архитектуру

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

Рисунок 1. Колизей

Введение в терминологию и понятийную область

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

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




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

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

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

Информационная модель – датацентрическое описание системы, являющееся в то же время единой учётной системой.

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

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

Подытоживая, можно указать важнейшие связи между понятиями:

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

Понятия стейкхолдер (stakeholder), интерес (concern), метод описания (viewpoint), тематическая группа описаний (view), отдельное описание (model) и их связи соответствуют основным понятиям и связям, введённым международным стандартом ISO/IEC 42010:2007 Systems and software engineering - Recommended practice for architectural description of software-intens ive systems.

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

набор стейкхолдеров и их интересов к системе;

методы рассмотрения и описания систем и правила их применения, включающие:

o предметную (тематическую) онтологию метода;

o нотации для графического или текстового представления соответствующих предметной онтологии метода фактов о системе;

Определение подхода позволяет говорить о наличии подхода при наличии минимального набора элементов (набора интересов и согласованных методов получения описаний для адресации этих интересов), позволяющего создать осмысленный набор описаний системы, пригодный для применения какими-то стейкхолдерами. Подход системной инженерии ISO/IEC 15288:2008 основан более широком системном подходе, содержит ссылки на архитектурный подход, включает элементы процессного подхода и проектного подхода, подробнее о которых будет рассказано ниже. Описание системы может быть выполнено с разной степенью абстракции. Мы будем говорить о разных уровнях абстракции при описании системы.

Уровни описания системы:

• опорный (в основном функциональный);




• принципиальный (в основном конструкционный);

• выполняемый (инструкции);

• исторический (измерения, временные ряды, отчёты):

• актуальные (измеренные)

• прогностические (прогнозные данные)

• нормативные (показатели эффективности)

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

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


Технические процессы ISO/IEC 15288

Рисунок 2. Технические процессы ISO/IEC 15288

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

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




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

Применение технических процессов

Рисунок 3. Модель применения технических процессов

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

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




итеративным, чтобы достичь требуемого решения проекта (см. п. 5.5.3.3 ISO/IEC TR 19760). Процесс реализации, Процесс интеграции, Процесс переноса и Процесс валидации используются для того, чтобы реализовать решение проектирования архитектуры для каждой системы в системной структуре. Применение всех этих процессов может быть очень в высшей степени итеративным. Первые три процесса рекурсивно применяются к интересующей системе, а затем к ее системам сверху вниз до тех пор, пока системный элемент не сможет быть реализован (например, сформирован, приобретен, использован повторно) с использованием Процесса реализации. Это происходит, когда не надо разрабатывать никаких дальнейших систем. После того, как все системные элементы системной структуры реализованы, Процесс интеграции, Процесс верификации, Процесс переноса и Процесс валидации рекурсивно выполняются для каждой системы снизу вверх, включая интересующую систему на верхнем уровне.


Рисунок 4. Контекстная диаграмма процесса проектирования архитектуры

Цель процесса проектирования архитектуры

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

Общая характеристика процесса проектирования архитектуры

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

Описание процесса проектирования архитектуры




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

Входы

Проектирование архитектуры начинается с функциональных и технических требований базовой линии, архитектурных ограничений и Матрицы Отслеживания Требований (Requirements Verification and Traceability Matrix – RVTM). Спецификации обеспечивающих систем используются для управления проектированием интерфейсов. Спецификации для повторно используемых элементов системы используются при проектировании продуктовых линеек.

Выходы

Результатом этого процесса является проект архитектуры, который помещается в управление конфигурацией. Эта исходная конфигурация (baseline) включает:

Детальные описания элементов системы с задокументированным обоснованием выбора концепции

Требования, предъявленные к элементам системы и задокументированные в Матрице Отслеживания Требований

Требования к интерфейсам, план интеграции системы и стратегия верификации

Действия в процессе

Следующие процессы вносят вклад в разработку архитектуры:

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

Разделить системные требования и распределить их по элементам системы и подсистемам с соответствующими требованиями к производительности – оценить существующие коммерческие решения

Оценить альтернативные архитектурные решения, среди следующих критериев выбора:

o Мера способности системы выполнять свои цели в соответствии с требованиями.

o Способность функционировать в пределах ограничений на ресурсы

o Согласованность ее интерфейсов

o Цены, экономические и прочие, внедрения и функционирования системы в течение всего жизненного цикла

o Побочные эффекты, как благоприятные, так и негативные, ассоциирующиеся с вариантами архитектурных решений

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

Определить стратегию и план интеграции системы (включая интеграцию с человеческими элементами системы)

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

Установить и поддерживать отслеживаемость между требованиями и элементами системы

Определить критерии верификации и валидации элементов системы

Результат процесса

В результате успешного осуществления процесса проектирования архитектуры:




устанавливается порядок, в соответствии с которым выполняется проектирование архитектуры;

задается реализуемый набор описаний системных элементов, которые удовлетворяют требованиям, предъявляемым к системе;

требования к интерфейсу включаются в решение по проектированию архитектуры;

устанавливается связь между проектированием архитектуры и системными требованиями;

определяется основа для верификации системных элементов;

устанавливается основа комплексирования системных элементов.

Распространенные подходы и советы:

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

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

Шаблоны архитектуры и проектирования могут оказаться полезными для определения структуры (framework) системы.

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

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


Рисунок 5. Пример взаимосвязи логической и физической архитектуры NATO




Логическая архитектура

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

Сценарии функционирования ставят в соответствие целям системы цепочки выполняемых задач.

Физическая архитектура

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

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

Конкретные характеристики элементов определяются их природой (программа, человек, оборудование, аппаратное средство…), в абстрактном смысле элемент характеризуется своим назначением и своими целями

Проектирование логической архитектуры

Состав

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

Применение

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

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

Этапы логического проектирования

Первым шагом следует преобразовать набор технических требований к более детализированному набору производных (derived) технических требований, которые были получены из набора моделей логического проектирования архитектуры [см. п. 5.5.4.3 a) Международного стандарта ISO/IEC 15288]. Это может быть достигнуто путем выполнения деятельности по логическому проектированию архитектуры Процесса проектирования архитектуры.

Модели логического проектирования архитектуры могут принимать одну или несколько форм, как те, которые описаны ниже:

a) блок-схема функционального потока, отражающая декомпозицию главных функций в их подфункции;




b) диаграмма информационного потока, которая раскладывает функции на составные части, явно демонстрируя данные, необходимые для каждой функции;

c) структура данных с соответствующими им функциями и потоки обработки данных, относящиеся к данным и связанные с назначенными техническими требованиями;

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

e) диаграмма управления, которая показывает факторы управления функции и результирующее поведение;

f) состояния и режимы системы;

g) график времени, который предъявляет требование времени к набору функций;

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

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

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

Рисунок 6. Пример логической архитектуры MIT: Information Technology Architecture Group

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

SAP DB

(Oracle)

Users

SAP ITS

SAP ClientBrowser

Client

(SAP WEB)

System

Component

Key:

Related

System

Other MIT

System

SAP Application Server

Kerberos

Server

Au

the

ntic

atio

nfo

r SA

P C

lien

ts

External

Systems

Other MIT Systems

Incoming:

Data Warehouse

Roles DBSAP - Lincoln Lab

Mainframe

COEUS

MIT ID

Broad Institute

Outgoing:

Data Warehouse

Archive (IX0S)

Server Broad Institute

MIT ID (Real Time)

External Systems

Incoming: Benefit Providers


EDI

Outgoing:

ECAT Vendors


Benefits Providers

Financial

Accounting

Materials

Management

ControllingSales and

Distribution

Profit Center

Account

Classification

System

Human

ResourcesPayroll

Labor

Distribution

Cross

Application

X509 Certificates

Drop

Box

SAP Web

Classic

Plant

Maintenance

Training Events

Management