Главная страница

ГОСТ Архитектура. Национальный стандарт российской федерации системная и программная инженерия описание архитектуры


Скачать 260.27 Kb.
НазваниеНациональный стандарт российской федерации системная и программная инженерия описание архитектуры
Дата28.11.2018
Размер260.27 Kb.
Формат файлаdocx
Имя файлаГОСТ Архитектура.docx
ТипДокументы
#57967
страница5 из 5
1   2   3   4   5


- Репозитарий точек зрения для ИСО/МЭК 42010 [42].

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

- Kruchten. "Модель представления архитектуры "4 + 1" [23].

Определяет точки зрения для логического представления, представления разработки, представления процессов и физического представления. Получающиеся представления объединяются через сценарии;

- Rozansky и Woods, Архитектура программных систем: работа с заинтересованными сторонами с использованием точек зрения и перспективности (Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives) [36].

Определяет каталог точек зрения: функционал, информация, параллелизм, разработка, эксплуатация и перспективы (см. примечание 1 к 5.6): безопасность, функционирование и масштабируемость, пригодность и стойкость, перспективы развития для программных систем.
Приложение C

(справочное)
ВЗАИМОСВЯЗЬ С ДРУГИМИ СТАНДАРТАМИ
C.1 Введение

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

C.2 Использование ИСО/МЭК 12207:2010

C.2.1 Общее

В ИСО/МЭК 12207:2010 определены два процесса, специально имеющие отношение к архитектуре: проектирование архитектуры системы (см. ИСО/МЭК 12207:2010, пункт 6.4.3) и проектирование архитектуры программных средств (см. ИСО/МЭК 12207:2010, пункт 7.1.3). Понятие архитектуры в настоящем стандарте совместимо с процессами проектирования архитектуры в ИСО/МЭК 12207:2010. В ИСО/МЭК 1220:2010 приведены требования к описанию архитектуры в дополнение к таковым из настоящего стандарта. Специфично то, что проектирование архитектуры системы должно включать определение объектов аппаратных средств, программных средств и объектов ручных операций, включенных в систему и распределение системных требований по этим объектам. Проектирование архитектуры системы должно быть оценено на соответствие критериям прослеживаемости и согласованности с требованиями к системе, приемлемости стандартов и методов проектирования и выполнимости программных и ручных операций.

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

Процесс проектирования архитектуры программного средства согласно ИСО/МЭК 1220:2010 иллюстрирует декомпозиционный подход к архитектуре. Его первичная цель состоит в декомпозировании объектов программных средств системы в компоненты и последующем распределении требований по этим компонентам. Описание архитектуры системы и продукты других представлений в описании архитектуры могут способствовать этой деятельности и ее продуктам.

Описание архитектуры может соответствовать настоящему стандарту и ИСО/МЭК 12207:2010. У общего подхода к "совместному соответствию" должна быть точка зрения, которая специально сфокусирована на производстве архитектурной продукции согласно ИСО/МЭК 12207:2010. Пример точки зрения для этой цели определен в C.2.2.

C.2.2 Точка зрения декомпозиции и распределения

Точка зрения декомпозиции и распределения структурирует следующие интересы:

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

- декомпозицию системы на объекты;

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

- верификацию того, что все требования распределены по объектам.

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

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

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

В итоге начальной декомпозиции и распределения производится множество объектов с распределенными требованиями. Это описано в терминах процесса проектирования архитектуры системы (см. ИСО/МЭК 12207:2010, подпункт 6.4.3.3.1).

Программные средства декомпозируются в зависимые компоненты. Требования, распределенные по каждому объекту программных средств, далее распределяются по одному или более компонентам. Описания интерфейса обеспечиваются между программными компонентами, между программными компонентами и аппаратными объектами и объектами ручного оперирования. Это описано в терминах проектирования архитектуры программных средств (см. ИСО/МЭК 12207:2010, подпункт 7.1.3.3.1).

C.3 Использование ИСО/МЭК 15288:2008

C.3.1 Общее

В ИСО/МЭК 15288:2008 определен один процесс, специально имеющий отношение к архитектуре, - это проектирование архитектуры. Понятие архитектуры в настоящем стандарте совместимо с процессом проектирования архитектуры согласно ИСО/МЭК 15288. В ИСО/МЭК 15288 приведены требования к описанию архитектуры в дополнение к требованиям, изложенным в настоящем стандарте. Специфично то, что проектирование архитектуры должно предусматривать определение системных элементов, включенных в систему, и распределение требований системы по этим объектам.

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

Описание архитектуры может соответствовать настоящему стандарту и ИСО/МЭК 15288. У общего подхода к "совместному соответствию" должна быть точка зрения, которая специально сосредотачивается на производстве архитектурной продукции согласно ИСО/МЭК 15288. Пример точки зрения для этой цели определен в C.3.2.

C.3.2 Декомпозиция и точка зрения распределения

Точка зрения декомпозиции и распределения структурирует следующие интересы:

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

- декомпозицию системы на объекты;

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

- верификацию того, что все требования распределены по объектам.

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

Система декомпозируется во множество элементов. Также определяются взаимодействия между объектами.

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

В итоге начальной декомпозиции и распределения производится множество элементов с распределенными требованиями. Это определено в терминах архитектурного описания системы [см. ИСО/МЭК 15288:2008, подпункт 6.4.3.3, перечисление c)].

C.4 Использование со стандартами открытой распределенной обработки

C.4.1 Общее

Эталонная модель открытой распределенной обработки (RM-ODP) определяет структуру архитектуры для систем распределенной обработки; системы, "в которых дискретные компоненты могут быть расположены в различных местах, а связь между компонентами может иметь задержку или оказаться неудачной" (см. ИСО/МЭК 10746-2:2000).

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

Для каждой точки зрения существует соответствующий язык точки зрения, который определяет "понятия и правила для определения системы открытой распределенной обработки с соответствующей точкой зрения".

Описание архитектуры, соответствующее настоящему стандарту и использующее ИСО/МЭК 10746-3, может включать точки зрения, определенные ИСО/МЭК 10746-3, и представления о реализации этих точек зрения. Необязательно ограничиваться пятью точками зрения, определенными в ИСО/МЭК 10746-3 для соответствующего описания архитектуры. При необходимости описание архитектуры может включать дополнительные точки зрения и представления.

Элементы спецификации, определенной для описаний архитектуры (такие как заинтересованные стороны), здесь опущены, так как они являются специально ориентированными на индивидуальные системы. Если это не отмечено, все содержание берется напрямую или цитируется согласно ИСО/МЭК 10746-3:1996 (ИСО/МЭК 10746-3:2001).

Примечание - ИСО/МЭК 19793 определяет профиль UML для спецификации систем открытой распределенной обработки, используя эти точки зрения.
C.4.2 Предпринимательская точка зрения

Предпринимательская точка зрения (точка зрения предприятия) структурирует следующие интересы:

- цель, область применения и политику для системы открытой распределенной обработки;

- роли, выполняемые системой;

- действия, совершаемые системой;

- положения политики о системе.

На предпринимательском языке система открытой распределенной обработки и ее окружающая среда представляются как сообщество объектов. Сообщество определяется в терминах:

- предпринимательских объектов (объектов предприятия), включающих сообщество;

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

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

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

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

- политики, относящейся к контрактам по окружающей среде, управляющим системой.

Примечания

1 Роли ограничивают поведение объектов, их выполняющих.

2 Политики определены в терминах разрешений, обязательств и запрещений.

3 Предпринимательский язык (язык предприятия) определен в ИСО/МЭК 15414.
C.4.3 Информационная точка зрения

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

Информационный язык определен в терминах трех схем:

- инвариантной схемы: предикаты на объектах, которые всегда должны быть в состоянии "верно" ("true");

- статической схемы: состояния одного или более объектов в некоторый момент времени;

- динамической схемы: изменения допустимого состояния одного или более объектов.

C.4.4 Вычислительная точка зрения

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

Вычислительный язык охватывает понятия для определения:

- вычислительных объектов;

- интерфейсов для объектов и определения интерфейсов;

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

- неявных и явных связываний и объектов составного связывания.

C.4.5 Инженерная точка зрения

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

Инженерный язык включает понятия для определения:

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

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

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

C.4.6 Технологическая точка зрения

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

Технологический язык включает понятия:

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

- выражения того, как реализованы спецификации для системы открытой распределенной обработки;

- оказания поддержки при испытаниях.
БИБЛИОГРАФИЯ


[1]

ANSI/IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

[2]

, N., Composition and relations of architectural models supported by an architectural description language. Doctoral dissertation, Katholieke Universiteit Leuven, October, 2009

[3]

Buschmann F., R. Meunier, H. Rohnert, P. Sommerlad and M. Stal, Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996

[4]

Callo-Arias, T.B., P. America, and P. Avgeriou, Defining execution viewpoints for a large and complex software-intensive system, Proceedings of WICSA/ECSA 2009

[5]

Clements P., F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting Software Architectures: Views and Beyond, Boston: Addison-Wesley, 2002

[6]

Darnton, G. and S. Giacoletto, Information in the Enterprise, Burlington, MA: Digital Press, 1992

[7]

Dijkstra, E.W., On the role of scientific thought. 1974.

http://www.cs.utexas. edu/users/EWD/transcriptions/EWD04xx/EWD447.html

[8]

Eeles P. and P. Cripps, The Process of Software Architecting. Addison Wesley, 2010

[9]

Hilliard, R. "Viewpoint modelling", First ICSE Workshop on Describing Software Architecture with UML, May 2001

[10]

Hofmeister, C., R. Nord, and D. Soni, Applied Software Architecture, Reading, MA: Addison-Wesley, 1999

[11]

ISO/IEC 10746-1, Information technology - Open Distributed Processing - Reference model: Overview

[12]

ISO/IEC 10746-2, Information technology - Open distributed processing - Reference model: Foundations

[13]

ISO/IEC 10746-3, Information technology - Open distributed processing - Reference model: Architecture

[14]

ISO/IEC 12207, Systems and software engineering - Software life cycle processes

[15]

ISO/IEC 15288, Systems and software engineering - System life cycle processes

[16]

ISO/IEC 15289, Systems and software engineering - Content of systems and software life cycle process information products (Documentation)

[17]

ISO/IEC 15414:2006, Information technology - Open distributed processing - Reference model - Enterprise language

[18]

ISO/IEC 15504-1:2004, Information technology - Process assessment - Part 1: Concepts and vocabulary

[19]

ISO 15704, Industrial automation systems - Requirements for enterprise-reference architectures and methodologies

[20]

ISO/IEC 19501:2005, Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2

[21]

ISO/IEC 19793:2008, Information technology - Open Distributed Processing - Use of UML for ODP system specifications

[22]

ISO/IEC 25010, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models

[23]

Kruchten, P.B., "The '4 + 1' View Model of Architecture", IEEE Software, 12(6), 45 - 50, 1995

[24]

Kruchten, P.B., "An Ontology of Architectural Design Decisions in Software-Intensive Systems", Proceedings of the 2nd Groningen Workshop on Software Variability, 54 - 61, 2004

[25]

Luckham, D.C., J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan and W. Mann, "Specification and analysis of system architecture using RAPIDE", IEEE Transactions on Software Engineering, 21(4), 336 - 355, April 1995

[26]

Maier, M.W. and E. Rechtin, The art of systems architecting, CRC Press, 2nd edition, 2000

[27]

Ministry of Defence Architecture Framework (MODAF), http://www.modaf.org.uk/

[28]

Muskens, J., R.J. Bril and M.R.V. Chaudron, "Generalizing consistency checking between software views", Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05), 169 - 180, Washington, DC: IEEE Computer Society, 2005

[29]

Nuseibeh, В., J. Kramer and A. Finkelstein, "A framework for expressing the relationships between multiple views in requirements specification", IEEE Transactions on Software Engineering, 20(10), 760 - 773, 1994

[30]

Obbink, H., P.B. Kruchten, W. Kozaczynski, R. Hilliard, A. Ran, H. Postema, D. Lutz, R. Kazman, W. Tracz, and E. Kahane. Report on Software Architecture Review and Assessment (SARA), 2002.

http://philippe.kruchten.com/architecture/SARAv1.pdf

[31]

OMG formal/2008-11-01, Systems Modeling Language, version 1.1, November 2008

[32]

Perry, D.E. and A.L. Wolf, "Foundations for the Study of Software Architecture", ACM SIGSOFT Software Engineering Notes, 17(4), 1992

[33]

Proakis, J.G., Digital Communications. New York: McGraw-Hill, 1995

[34]

Ran, A. "ARES Conceptual Framework for Software Architecture", M. Jazayeri, A. Ran, and F. van der Linden (eds.), Software Architecture for Product Families Principles and Practice. Boston: Addison-Wesley, 1 - 29, 2000

[35]

Ross, D.T., "Structured Analysis (SA): a language for communicating ideas", IEEE Transactions on Software Engineering, SE-3(1), 16 - 34, 1977

[36]

Rozansky, N. and E. Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley, 2005

[37]

Society of Automotive Engineers, Architecture Analysis & Design Language, http://www.ЯОА.info/

[38]

Shaw, M. "Prospects for an engineering discipline of software", IEEE Software, November 1990

[39]

Smolander, K., "Four Metaphors of Architecture in Software Organizations: Finding out The Meaning of Architecture in Practice", Proceedings of the 2002 International Symposium on Empirical Software Engineering (ISESE'02)

[40]

The Open Group, ArchiMate 1.0 Specification, February 2009, http://www.archimate.org/

[41]

The Open Group Architecture Framework (TOGAF), http://www.opengroup. org/togaf/

[42]

Viewpoints Repository for ISO/IEC 42010 http://www.iso-architecture.org/viewpoints/

[43]

Wright ЯОА website, http://www.cs.cmu.edu/able/wright/

[44]

Zachman, J.A., "A Framework for Information Systems Architecture", IBM Systems Journal, 26(3), 1987

[45]

Zimmermann O., Koehler J., Leymann F., Polley R., Schuster N., "Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules", The Journal of Systems and Software and Services, Special Issue on Design Decisions and Rationale in Software Architecture Special Edition on Architectural Decisions, Elsevier, 2009
1   2   3   4   5



написать администратору сайта