Википедия

Архитектура системы

15 Июл, 2025 / 05:49

Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию:3.

Понятие архитектуры в значительной мере субъективно и имеет множество противоречивых толкований; в лучшем случае оно отображает общую точку зрения команды разработчиков на результаты проектирования системы.:27 Существует большое количество определений архитектуры. Коллекция определений, относящихся, в основном, к архитектуре программного обеспечения, собрана на сайте Института программной инженерии Университета Карнеги — Меллона.

В настоящее время существует сильная тенденция рассматривать архитектурное и не архитектурное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с обычными проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы:272.

История возникновения понятия

По мере роста сложности решаемых задач возникла необходимость структурирования систем. Однако практики нашли термин «структура» недостаточным для описания всех аспектов системы:272.

Термин «архитектура» в системной инженерии ввёл профессор университета Южной Калифорнии (англ. Eberhardt Rechtin) в начале 1990-х годов. Он считал, что по мере усложнения систем их «высокоуровневого проектирования» (или «концептуального проектирования»), как оно понималось в те годы, было недостаточно, чтобы приводить инженеров и проектировщиков к созданию точных и эффективных проектов. Он изучил архитектурные принципы в строительстве, чтобы понять, как создаются и разрабатываются сложные системы (например, здания):223.

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

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

Термины «архитектура» и «архитектурное проектирование» уже используются в течение приблизительно 30 лет, особенно интенсивно в программной инженерии и таких проблемных областях, как ракетно-космическая отрасль:272.

Сопутствующие понятия

Для более подробного описания принципов построения архитектуры стандарт ISO/IEC/IEEE 42010-2011 вводит следующие понятия:2.

  • Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания.
  • Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры.
  • Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом стейкхолдеров.
  • Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам.
  • Вид модели (англ. model kind) — соглашения по средствам моделирования (например, сети Петри, диаграммы классов, организационные диаграммы и т. д.).

Виды архитектуры

Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую:269.

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

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

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

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

Временная архитектура. Временная архитектура является классификацией функций системы, которая получена в соответствии с уровнем частоты её исполнения. Временная архитектура включает в себя определение синхронных и асинхронных аспектов функций. Мониторинг решений, который происходит внутри системы, следует той же временной классификации :287.

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

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

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

Физическая архитектура является систематизацией физических элементов (элементов системы и физических интерфейсов), которые реализуют спроектированные решения для продукта, услуги или предприятия. Она предназначена для удовлетворения требований к системе и элементам логической архитектуры и реализуется через технологические элементы системы. Системные требования распределяются как на логическую, так и физическую архитектуру. Глобальная архитектура системы оценивается с помощью системного анализа и, после выполнения всех требований, становится основой для реализации системы:296.

Архитектурное описание

image
Концептуальная схема архитектурного описания (ISO/IEC 42010)

Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО) (см. рисунок). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру системы и одно из описаний данной архитектуры, являющееся конкретным продуктом или артефактом.

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

Концептуальный подход

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

На рисунке прямоугольники изображают классы сущностей.

Линии, соединяющие прямоугольники, изображают связи между сущностями. Связь включает две роли (по одной в каждом направлении). Каждая роль может по желанию быть именована меткой. Роль, направленная от A к B, [помечена] ближе к B, и наоборот. Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“». На рисунке роли обладают арностью 1:1, если не указано иное. Роль может обладать множественной арностью, например, роль, обозначенная как «1..*», применяется для обозначения многих, как в связях «один ко многим» или «многие к одному». Ромб (на конце линии связи) обозначает отношение части целого. Например, «группы описаний» являются частью «архитектурного описания». Эта нотация заимствована из UML.

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

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

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

Любая система существует для реализации в своей среде одной или более миссий.

В концептуальном подходе архитектурное описание организовано как одна или более архитектурных групп описаний.

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

Группа описаний может состоять из одного или более архитектурных описаний. Каждое такое архитектурное описание разрабатывается с применением установленных соответствующим ему методов архитектурного описания. Архитектурное описание может входить более чем в одну группу описаний:4-6.

Типы групп описаний архитектуры

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

Функциональная группа описаний

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

Логическая группа описаний

Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков (FFBD), контекстные диаграммы, , IDEF0-диаграммы, данные поточных диаграмм и различных стейкхолдеров — характерные продукты (в том числе бизнес-зависимые продукты):224.

Физическая группа описаний

Данная группа обеспечивает представление с точки зрения проектировщиков. Включает в себя:

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

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

Применение архитектурных описаний

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

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

Примечания

  1. ГОСТ Р ИСО/МЭК 15288, 2008.
  2. Фаулер М., 2006.
  3. Community Software Architecture Definitions Архивная копия от 22 мая 2014 на Wayback Machine // Software Engineering Institute, Carnegie Mellon University
  4. SEBoK, 2012.
  5. Данилин, Слюсаренко, 2005.
  6. Systems Engineering Principles and Practice, 2011.
  7. ISO/IEC 42010, 2011.

Литература

  • ГОСТ Р ИСО/МЭК 15288—2008. Системная инженерия — Процессы жизненного цикла систем. — 2008.
  • Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия. — М.: Интернет-университет информационных технологий, 2005. — 504 с. — ISBN 5-9556-0045-0.
  • Фаулер М. Архитектура корпоративных программных приложений.: Пер. с англ. — М.: Издательский дом «Вильямс», 2006. — 544 с. ISBN 5-8459-0579-6
  • Pyster, A., D. Olwell, N. Hutchison, S. Enck, J. Anthony, D. Henry, and A. Squires (eds). Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0. — The Trustees of the Stevens Institute of Technology, 2012.
  • Kossiakoff A., Sweet W. N., Seymour S. J., Biemer S. M. Systems Engineering Principles and Practice. — 2-е изд. — Hoboken, New Jersey: A John Wiley & Sons, 2011. — 599 с. — ISBN 978-0-470-40548-2.
  • ISO/IEC 42010:2011. System and software engineering — Architecture description. — 2011.

Ссылки

  • Glossary (architecture) // Software Engineering Institute, Carnegie Mellon University

Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры, мобильный, телефон, Android, iOS, apple, мобильный телефон, Samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Сеть, компьютер, Информация о Архитектура системы, Что такое Архитектура системы? Что означает Архитектура системы?

Arhitektura sistemy principialnaya organizaciya sistemy voploshennaya v eyo elementah ih vzaimootnosheniyah drug s drugom i so sredoj a takzhe principy napravlyayushie eyo proektirovanie i evolyuciyu 3 Ponyatie arhitektury v znachitelnoj mere subektivno i imeet mnozhestvo protivorechivyh tolkovanij v luchshem sluchae ono otobrazhaet obshuyu tochku zreniya komandy razrabotchikov na rezultaty proektirovaniya sistemy 27 Sushestvuet bolshoe kolichestvo opredelenij arhitektury Kollekciya opredelenij otnosyashihsya v osnovnom k arhitekture programmnogo obespecheniya sobrana na sajte Instituta programmnoj inzhenerii Universiteta Karnegi Mellona V nastoyashee vremya sushestvuet silnaya tendenciya rassmatrivat arhitekturnoe i ne arhitekturnoe proektirovanie kak razlichnye vidy deyatelnosti delayutsya popytki opredelit ih kak otdelnye praktiki odnako eti vidy proektirovaniya v znachitelnoj mere perepleteny Arhitekturnye resheniya v sravnenii s obychnymi proektnymi resheniyami rassmatrivayutsya kak bolee abstraktnye konceptualnye i globalnye oni naceleny na uspeh vsej missii i na naibolee vysokourovnevye struktury sistemy 272 Drugie opredeleniya arhitektury sistemy Obshij plan ili koncepciya ispolzuemaya dlya sozdaniya sistemy takoj kak zdanie ili informacionnaya sistema ili abstraktnoe opisanie sistemy eyo struktury komponentov i ih vzaimosvyazej Defining Architecture for IT A Framework of Frameworks Gartner 2002 79 80 Konstruktivnye resheniya kotorye posle ih prinyatiya s trudom poddayutsya izmeneniyu soglasie v voprose identifikacii glavnyh komponentov sistemy i sposobov ih vzaimodejstviya a takzhe vybor takih reshenij kotorye interpretiruyutsya kak osnovopolagayushie i ne podlezhashie izmeneniyu v budushem 27Istoriya vozniknoveniya ponyatiyaPo mere rosta slozhnosti reshaemyh zadach voznikla neobhodimost strukturirovaniya sistem Odnako praktiki nashli termin struktura nedostatochnym dlya opisaniya vseh aspektov sistemy 272 Termin arhitektura v sistemnoj inzhenerii vvyol professor universiteta Yuzhnoj Kalifornii angl Eberhardt Rechtin v nachale 1990 h godov On schital chto po mere uslozhneniya sistem ih vysokourovnevogo proektirovaniya ili konceptualnogo proektirovaniya kak ono ponimalos v te gody bylo nedostatochno chtoby privodit inzhenerov i proektirovshikov k sozdaniyu tochnyh i effektivnyh proektov On izuchil arhitekturnye principy v stroitelstve chtoby ponyat kak sozdayutsya i razrabatyvayutsya slozhnye sistemy naprimer zdaniya 223 Rehtin poyasnyaet termin arhitektura sistemy sleduyushim obrazom Sut sozdaniya arhitektury strukturirovanie Strukturirovanie mozhet oznachat prevrashenie formy v funkciyu izvlechenie poryadka iz haosa ili preobrazovanie chastichno sformirovannyh idej klienta v prigodnuyu dlya raboty konceptualnuyu model 223 224 Terminy arhitektura i arhitekturnoe proektirovanie uzhe ispolzuyutsya v techenie priblizitelno 30 let osobenno intensivno v programmnoj inzhenerii i takih problemnyh oblastyah kak raketno kosmicheskaya otrasl 272 Soputstvuyushie ponyatiyaDlya bolee podrobnogo opisaniya principov postroeniya arhitektury standart ISO IEC IEEE 42010 2011 vvodit sleduyushie ponyatiya 2 Arhitekturnaya gruppa opisanij angl architectural view predstavlenie sistemy v celom s tochki zreniya svyazannogo nabora interesov Kazhdaya gruppa opisanij otnositsya k odnomu ili bolee stejkholderu Termin gruppa opisanij upotreblyaetsya dlya vyrazheniya arhitektury sistemy pri nekotorom metode opisaniya Arhitekturnoe opisanie angl architectural description rabochij produkt ispolzuyushijsya dlya vyrazheniya arhitektury Arhitekturnyj podhod angl architectural framework soglasheniya principy i praktiki dlya opisaniya arhitektury ustanovlennye dlya konkretnoj oblasti primeneniya i ili konkretnym soobshestvom stejkholderov Arhitekturnyj metod opisaniya angl architectural viewpoint specifikaciya soglashenij dlya konstruirovaniya i primeneniya gruppy opisanij Shablon ili obrazec po kotoromu razrabatyvayutsya otdelnye gruppy opisanij posredstvom ustanovleniya naznachenij i auditorii dlya gruppy opisanij a takzhe priemy ih sozdaniya i analiza Metod opisaniya ustanavlivaet soglasheniya po kotorym gruppa opisanij sozdaetsya otobrazhaetsya i analiziruetsya Tem samym metod opisaniya opredelyaet yazyki vklyuchaya notacii opisaniya ili tipy produktov primenyaemye dlya opredeleniya gruppy opisanij a takzhe vse svyazannye metody modelirovaniya ili priemy analiza primenyaemye k dannym predstavleniyam gruppy opisanij Dannye yazyki i priemy primenyayutsya dlya polucheniya rezultatov imeyushih otnoshenie k adresuemym interesam Vid modeli angl model kind soglasheniya po sredstvam modelirovaniya naprimer seti Petri diagrammy klassov organizacionnye diagrammy i t d Vidy arhitekturySvod znanij po sistemnoj inzhenerii SEBoK delit arhitekturu na logicheskuyu i fizicheskuyu 269 Logicheskaya arhitektura Logicheskaya arhitektura podderzhivaet funkcionirovanie sistemy na protyazhenii vsego eyo zhiznennogo cikla na logicheskom urovne Ona sostoit iz nabora svyazannyh tehnicheskih koncepcij i principov Logicheskaya arhitektura predstavlyaetsya s pomoshyu metodov sootvetstvuyushih tematicheskim gruppam opisanij i kak minimum vklyuchaet v sebya funkcionalnuyu arhitekturu povedencheskuyu arhitekturu i vremennuyu arhitekturu Funkcionalnaya arhitektura Funkcionalnaya arhitektura predstavlyaet soboj nabor funkcij i ih podfunkcij opredelyayushih preobrazovaniya osushestvlyaemye sistemoj pri vypolnenii svoego naznacheniya Povedencheskaya arhitektura Povedencheskaya arhitektura soglashenie o funkciyah i ih podfunkciyah a takzhe interfejsah vhody i vyhody kotorye opredelyayut posledovatelnost vypolneniya usloviya dlya upravleniya ili potoka dannyh uroven proizvoditelnosti neobhodimyj dlya udovletvoreniya sistemnyh trebovanij Povedencheskaya arhitektura mozhet byt opisana kak sovokupnost vzaimosvyazannyh scenariev funkcij i ili ekspluatacionnyh rezhimov Vremennaya arhitektura Vremennaya arhitektura yavlyaetsya klassifikaciej funkcij sistemy kotoraya poluchena v sootvetstvii s urovnem chastoty eyo ispolneniya Vremennaya arhitektura vklyuchaet v sebya opredelenie sinhronnyh i asinhronnyh aspektov funkcij Monitoring reshenij kotoryj proishodit vnutri sistemy sleduet toj zhe vremennoj klassifikacii 287 Fizicheskaya arhitektura Cel proektirovaniya fizicheskoj arhitektury zaklyuchaetsya v sozdanii fizicheskogo konkretnogo resheniya kotoroe soglasovano s logicheskoj arhitekturoj i udovletvoryaet ustanovlennym sistemnym trebovaniyam Posle togo kak logicheskaya arhitektura opredelena dolzhny byt identificirovany konkretnye fizicheskie elementy kotorye podderzhivayut funkcionalnye povedencheskie i vremennye svojstva a takzhe ozhidaemye svojstva sistemy poluchennye iz nefunkcionalnyh trebovanij k sisteme Fizicheskaya arhitektura yavlyaetsya sistematizaciej fizicheskih elementov elementov sistemy i fizicheskih interfejsov kotorye realizuyut sproektirovannye resheniya dlya produkta uslugi ili predpriyatiya Ona prednaznachena dlya udovletvoreniya trebovanij k sisteme i elementam logicheskoj arhitektury i realizuetsya cherez tehnologicheskie elementy sistemy Sistemnye trebovaniya raspredelyayutsya kak na logicheskuyu tak i fizicheskuyu arhitekturu Globalnaya arhitektura sistemy ocenivaetsya s pomoshyu sistemnogo analiza i posle vypolneniya vseh trebovanij stanovitsya osnovoj dlya realizacii sistemy 296 Arhitekturnoe opisanieKonceptualnaya shema arhitekturnogo opisaniya ISO IEC 42010 Arhitektura mozhet byt zafiksirovana s pomoshyu polnogo arhitekturnogo opisaniya AO sm risunok Standart ISO IEC IEEE 42010 2011 predpisyvaet razlichat konceptualnuyu arhitekturu sistemy i odno iz opisanij dannoj arhitektury yavlyayusheesya konkretnym produktom ili artefaktom V slozhnyh sistemah AO mozhet razrabatyvatsya ne tolko dlya sistemy v celom no i dlya komponentov sistemy Dva raznyh konceptualnyh AO mogut vklyuchat gruppy opisanij kotorye budut sootvetstvovat odnomu i tomu zhe metodu opisaniya Hotya sistemy opisyvaemye dannymi dvumya gruppami opisanij budut sootnositsya kak celoe i chast eto ne primer mnozhestva grupp opisanij sootvetstvuyushih odnomu metodu Eti AO schitayutsya otdelnymi dazhe hotya oni svyazany cherez sistemy kotorye oni opisyvayut 3 Konceptualnyj podhod Konceptualnyj podhod opredelyaet terminy i ponyatiya otnosyashiesya k soderzhaniyu i primeneniyu AO Na risunke izobrazheny osnovnye ponyatiya i ih vzaimosvyazi Vse ponyatiya opredeleny v kontekste arhitektury opredelennoj sistemy i sootvetstvuyushego arhitekturnogo opisaniya Ne nuzhno predpolagat chto u sistemy sushestvuet lish odna arhitektura ili chto eta arhitektura izobrazhaetsya lish odnim arhitekturnym opisaniem Na risunke pryamougolniki izobrazhayut klassy sushnostej Linii soedinyayushie pryamougolniki izobrazhayut svyazi mezhdu sushnostyami Svyaz vklyuchaet dve roli po odnoj v kazhdom napravlenii Kazhdaya rol mozhet po zhelaniyu byt imenovana metkoj Rol napravlennaya ot A k B pomechena blizhe k B i naoborot Naprimer roli mezhdu sistemoj i sredoj mogut chitatsya sistema zhivyot v srede i sreda vliyaet na sistemu Na risunke roli obladayut arnostyu 1 1 esli ne ukazano inoe Rol mozhet obladat mnozhestvennoj arnostyu naprimer rol oboznachennaya kak 1 primenyaetsya dlya oboznacheniya mnogih kak v svyazyah odin ko mnogim ili mnogie k odnomu Romb na konce linii svyazi oboznachaet otnoshenie chasti celogo Naprimer gruppy opisanij yavlyayutsya chastyu arhitekturnogo opisaniya Eta notaciya zaimstvovana iz UML Rassmotrim kazhdoe sostavlyayushee konceptualnoj shemy podrobnee V kontekste rassmatrivaemoj shemy sistema rasprostranyaetsya na otdelnye prikladnye programmnye sredstva sistemy v tradicionnom smysle podsistemy sistemy sistem produkty semejstva produkcii organizacii v celom i drugie interesuyushie sovokupnosti Sistema obitaet v nekotoroj srede Sreda nekotoroj sistemy mozhet vliyat na dannuyu sistemu Eyo sreda ili kontekst opredelyaet obstanovku i obstoyatelstva razrabotki ekspluatacii politicheskih i inyh vliyanij na dannuyu sistemu Takaya sreda mozhet vklyuchat drugie sistemy vzaimodejstvuyushie s celevoj sistemoj kak napryamuyu cherez interfejsy tak i kosvenno inymi putyami Takaya sreda opredelyaet granicy opredelyayushie predmet celevoj sistemy po otnosheniyu k drugim sistemam U kazhdoj sistemy est odin ili bolee stejkholderov Kazhdyj stejkholder obychno prinimaet uchastie v sisteme ili imeet interesy k dannoj sisteme Interesy predpolagayut uchyot takih aspektov sistemy kak proizvoditelnost nadezhnost bezopasnost raspredelyonnost i sposobnost k evolyucii Lyubaya sistema sushestvuet dlya realizacii v svoej srede odnoj ili bolee missij V konceptualnom podhode arhitekturnoe opisanie organizovano kak odna ili bolee arhitekturnyh grupp opisanij Arhitekturnoe opisanie vybiraet dlya primeneniya odin ili bolee podhodyashih metodov opisaniya Vybor metodov opisaniya obychno osnovyvaetsya na soobrazheniyah i interesah zainteresovannyh storon kotorym adresovano eto AO Opredelenie metoda opisaniya mozhet voznikat sovmestno s AO a mozhet byt opredeleno otdelno Metod opisaniya opredelennyj otdelno ot AO nazyvaetsya bibliotechnym metodom opisaniya Gruppa opisanij mozhet sostoyat iz odnogo ili bolee arhitekturnyh opisanij Kazhdoe takoe arhitekturnoe opisanie razrabatyvaetsya s primeneniem ustanovlennyh sootvetstvuyushim emu metodov arhitekturnogo opisaniya Arhitekturnoe opisanie mozhet vhodit bolee chem v odnu gruppu opisanij 4 6 Tipy grupp opisanij arhitektury Sushestvuet tri tipa gruppy opisanij funkcionalnye logicheskie i fizicheskie Kazhdaya iz grupp prednaznachena dlya opisaniya sobstvennyh tochek zreniya i sootvetstvuyushego im urovnya slozhnosti 224 Funkcionalnaya gruppa opisanij Dannaya gruppa obespechivaet predstavlenie s tochki zreniya polzovatelej ili operatorov kotoroe vklyuchaet produkty otnosyashiesya k fazam scenariyam i potokam zadach operacionnoj sistemy Informacionnyj potok mozhet byt rassmotren s polzovatelskogo rakursa takzhe opisyvayutsya i polzovatelskie interfejsy Primerom produktov kotorye mogut byt vklyucheny v eto opisanie budut funkcionalnye dannye ili grafiki scenarnoe opisanie vklyuchaya ispolzovanie kejsov blok shemy zadach organizacionnye diagrammy i shemy informacionnyh potokov 224 Logicheskaya gruppa opisanij Dannaya gruppa obespechivaet predstavlenie s tochki zreniya rukovoditelya ili zakazchika Logicheskoe predstavlenie vklyuchaet produkty kotorye opredelyayut sistemnye granicy s eyo okruzheniem i funkcionalnye interfejsy s vneshnimi sistemami takzhe osnovnye funkcii i povedenie sistemy potoki informacii vnutrennie i vneshnie nabory dannyh vnutrennih i vneshnih polzovatelej i vnutrennie funkcionalnye interfejsy Primerom produktov mogut byt blochnye diagrammy funkcionalnyh potokov FFBD kontekstnye diagrammy IDEF0 diagrammy dannye potochnyh diagramm i razlichnyh stejkholderov harakternye produkty v tom chisle biznes zavisimye produkty 224 Fizicheskaya gruppa opisanij Dannaya gruppa obespechivaet predstavlenie s tochki zreniya proektirovshikov Vklyuchaet v sebya produkty kotorye opredelyayut fizicheskie granicy sistemy fizicheskie komponenty sistemy i to kak oni vzaimodejstvuyut i vliyayut drug na druga vnutrennie bazy dannyh i struktury dannyh infrastrukturu informacionnyh tehnologij IT sistemy vneshnyuyu IT infrastrukturu s kotoroj sistema vzaimodejstvuet trebovaniya neobhodimye dlya razvitiya sistemy Produkt mozhet vklyuchat v sebya fizicheskie blok shemy na dovolno vysokom urovne detalizacii topologii bazy dannyh interfejs upravleniya dokumentami i standarty Vse iz tryoh tipov grupp dolzhny prisutstvovat v kazhdom opisanii arhitektury 224 Primenenie arhitekturnyh opisanijArhitekturnye opisaniya v hode zhiznennogo cikla mogut razlichno primenyatsya vsemi stejkholderami Takie primeneniya vklyuchayut no ne ogranichivayutsya sleduyushim analiz alternativnyh arhitektur delovoe planirovanie perehoda ot unasledovannoj arhitektury k novoj kommunikaciya organizacij uchastvuyushih v razrabotke proizvodstve ustanovke ekspluatacii i obsluzhivanii sistem kommunikaciya mezhdu zakazchikami i razrabotchikami kak chast podgotovki soglasheniya kriterii dlya sertifikacii sootvetstviya realizacii dannoj arhitekture dokumentirovanie razrabotki i obsluzhivaniya vklyuchaya podgotovku materialov dlya hranilish s celyu povtornogo ispolzovaniya i uchebnyh materialov ishodnye dannye dlya posleduyushih meropriyatij po sistemnomu proektirovaniyu i razrabotke ishodnye materialy dlya instrumentov sozdaniya i analiza sistemy ekspluatacionnaya i infrastrukturnaya podderzhka upravlenie konfiguraciej i remont pereproektirovanie i obsluzhivanie sistem podsistem i komponentov podderzhka planirovaniya i finansirovaniya 9 PrimechaniyaGOST R ISO MEK 15288 2008 Fauler M 2006 Community Software Architecture Definitions Arhivnaya kopiya ot 22 maya 2014 na Wayback Machine Software Engineering Institute Carnegie Mellon University SEBoK 2012 Danilin Slyusarenko 2005 Systems Engineering Principles and Practice 2011 ISO IEC 42010 2011 LiteraturaGOST R ISO MEK 15288 2008 Sistemnaya inzheneriya Processy zhiznennogo cikla sistem 2008 Danilin A Slyusarenko A Arhitektura i strategiya In i Yan informacionnyh tehnologij predpriyatiya M Internet universitet informacionnyh tehnologij 2005 504 s ISBN 5 9556 0045 0 Fauler M Arhitektura korporativnyh programmnyh prilozhenij Per s angl M Izdatelskij dom Vilyams 2006 544 s ISBN 5 8459 0579 6 Pyster A D Olwell N Hutchison S Enck J Anthony D Henry and A Squires eds Guide to the Systems Engineering Body of Knowledge SEBoK version 1 0 The Trustees of the Stevens Institute of Technology 2012 Kossiakoff A Sweet W N Seymour S J Biemer S M Systems Engineering Principles and Practice 2 e izd Hoboken New Jersey A John Wiley amp Sons 2011 599 s ISBN 978 0 470 40548 2 ISO IEC 42010 2011 System and software engineering Architecture description 2011 SsylkiGlossary architecture Software Engineering Institute Carnegie Mellon University

15 Июл, 2025 / 05:49
NiNa.Az

NiNa.Az

NiNa.Az - Абсолютно бесплатная система, которая делится для вас информацией и контентом 24 часа в сутки.
Взгляните
Закрыто
© 2019 NiNa.Az - Все права защищены.
Авторские права: Dadash Mammadov