Модель представления

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

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

С начала 1990-х годов был предпринят ряд усилий по разработке подходов к описанию и анализу системных архитектур. Эти недавние усилия определяют набор взглядов (или точек зрения). Их иногда называют архитектурными фреймворками или фреймворками корпоративной архитектуры, но обычно их называют «моделями представления».

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

Обзор[править | править код]

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

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

История[править | править код]

В 1970-х годах в программной инженерии начали появляться методы моделирования с несколькими представлениями. Дуглас Т. Росс и К. Э. Шоман в 1977 году представили контекст и точку зрения конструктов для организации процесса моделирования при определении требований к системам[4]. По словам Росса и Шомана, точка зрения «проясняет, какие аспекты считаются важными для достижения общей цели [модели]» и определяет, как мы смотрим на [моделируемый объект]?

В качестве примеров точек зрения в документе предлагаются: Технические, эксплуатационные и экономические точки зрения. В 1992 году Энтони Финкельштейн и другие опубликовали очень важную статью о точках зрения[5]. В этой работе: «Точку зрения можно рассматривать как комбинацию идеи „субъекта“, „источника знаний“, „роли“ или „агента“ в процессе разработки и идеи „точки зрения“ или „перспективы“, которую поддерживает субъект». Важная идея в этой статье состояла в том, чтобы различать «стиль представления, схему и обозначения, с помощью которых точка зрения выражает то, что она может видеть», и «спецификацию, утверждения, выраженные в стиле точки зрения, описывающие конкретные области». Последующие работы, такие как IEEE 1471, сохранили это различие, используя два отдельных термина: точка зрения и представление соответственно.

С начала 1990-х годов был предпринят ряд усилий по кодификации подходов к описанию и анализу системных архитектур. Их часто называют каркасами архитектуры или иногда наборами точек зрения. Многие из них финансировались Министерством обороны Соединенных Штатов, но некоторые возникли в результате международных или национальных усилий в рамках ISO или IEEE. Среди них Рекомендуемая практика IEEE по архитектурному описанию систем с интенсивным использованием программного обеспечения (IEEE Std 1471—2000) содержит полезные определения взглядов, точек зрения, заинтересованных сторон и проблем, а также рекомендации по документированию архитектуры системы путем использования нескольких представлений путем применения точек зрения для решения проблем заинтересованных сторон[6]. Преимущество множественных мнений заключается в том, что скрытые требования и разногласия заинтересованных сторон могут быть обнаружены более легко. Однако исследования показывают, что на практике дополнительная сложность согласования нескольких точек зрения может подорвать это преимущество[7].

IEEE 1471 (в настоящее время ISO/IEC/IEEE 42010:2011, Разработка систем и программного обеспечения — Описание архитектуры) предписывает содержание описаний архитектуры и описывает их создание и использование в ряде сценариев, включая прецедентный и беспрецедентный дизайн, эволюционный дизайн и захват дизайна существующих систем. Во всех этих сценариях общий процесс одинаков: определение заинтересованных сторон, выявление проблем, определение набора точек зрения, которые будут использоваться, а затем применение этих спецификаций точек зрения для разработки набора точек зрения, относящихся к интересующей системе. Вместо того, чтобы определять определенный набор точек зрения, стандарт предоставляет единые механизмы и требования для архитекторов и организаций для определения своих собственных точек зрения. В 1996 году была опубликована Эталонная модель ISO для открытой распределенной обработки (RM-ODP), которая обеспечивает полезную основу для описания архитектуры и проектирования крупномасштабных распределенных систем.

Просмотр разделов модели[править | править код]

Обзор[править | править код]

Представление о системе — это представление системы с точки зрения перспективы. Эта точка зрения на систему включает в себя перспективу, фокусирующуюся на конкретных проблемах, касающихся системы, которая подавляет детали, чтобы обеспечить упрощенную модель, содержащую только те элементы, которые связаны с проблемами точки зрения. Например, точка зрения безопасности фокусируется на проблемах безопасности, а модель точки зрения безопасности содержит те элементы, которые связаны с безопасностью из более общей модели системы[8].

Представление позволяет пользователю изучить часть определенной области интересов. Например, в Информационном представлении могут быть представлены все функции, организации, технологии и т. д., которые используют определенную часть информации, в то время как в Организационном представлении могут быть представлены все функции, технологии и информация, представляющие интерес для конкретной организации. В рамках модели Закмана представления включают группу рабочих продуктов, разработка которых требует особых аналитических и технических знаний, поскольку они сосредоточены либо на «что», «как», «кто», «где», «когда» или «почему» предприятия. Например, рабочие продукты функционального представления отвечают на вопрос «как выполняется миссия?». Они легче всего разрабатываются экспертами в области функциональной декомпозиции с использованием моделирования процессов и деятельности. Они показывают предприятие с точки зрения функций. Они также могут отображать организационные и информационные компоненты, но только в том случае, если они связаны с функциями[9].

Точки зрения[править | править код]

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

Точки зрения предоставляют соглашения, правила и языки для построения, представления и анализа мнений. В ISO/IEC 42010:2007 (IEEE-Std-1471-2000) точка зрения — это спецификация для отдельного представления. Представление может состоять из одной или нескольких архитектурных моделей. Каждая такая архитектурная модель разрабатывается с использованием методов, установленных соответствующей архитектурной системой, а также для системы в целом[10].

Перспективы моделирования[править | править код]

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

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

Модель точки зрения[править | править код]

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

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

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

Описание архитектуры[править | править код]

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

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

Примечания[править | править код]

  1. ISO/IEC/IEEE Systems and software engineering -- Architecture description. — IEEE.
  2. Information technology. Open distributed processing. Reference model. — BSI British Standards.
  3. 1 2 Edward J Barkmeyer, Allison Barnard Feeney, Peter Denno, David W Flater, Donald E Libes. Concepts for automating systems integration. — Gaithersburg, MD: National Institute of Standards and Technology, 2003.
  4. D.T. Ross, K.E. Schoman. Structured Analysis for Requirements Definition // IEEE Transactions on Software Engineering. — 1977-01. — Т. SE-3, вып. 1. — С. 6–15. — ISSN 0098-5589. — doi:10.1109/tse.1977.229899.
  5. A. FINKELSTEIN, J. KRAMER, B. NUSEIBEH, L. FINKELSTEIN, M. GOEDICKE. VIEWPOINTS: A FRAMEWORK FOR INTEGRATING MULTIPLE PERSPECTIVES IN SYSTEM DEVELOPMENT // International Journal of Software Engineering and Knowledge Engineering. — 1992-03. — Т. 02, вып. 01. — С. 31–57. — ISSN 1793-6403 0218-1940, 1793-6403. — doi:10.1142/s0218194092000038.
  6. Peter Shames, Joseph Skipper. Toward a Framework for Modeling Space Systems Architectures // SpaceOps 2006 Conference. — Reston, Virigina: American Institute of Aeronautics and Astronautics, 2006-06-19. — doi:10.2514/6.2006-5581.
  7. S. Easterbrook, E. Yu, J. Aranda, Yuntian Fan, J. Horkoff. Do viewpoints lead to better conceptual models? An exploratory case study // 13th IEEE International Conference on Requirements Engineering (RE'05). — IEEE, 2005. — doi:10.1109/re.2005.23.
  8. Peter Fettke, Peter Loos. Model Driven Architecture (MDA) // Wirtschaftsinformatik. — 2003-10. — Т. 45, вып. 5. — С. 555–559. — ISSN 1861-8936 0937-6429, 1861-8936. — doi:10.1007/bf03250921.
  9. Glicksman, Brian Leslie, (born 14 Dec. 1945), Treasury Officer of Accounts, HM Treasury, 2000–05 // Who's Who. — Oxford University Press, 2007-12-01.
  10. Qiao Wang, Lenan Wu. Translation invariance and sampling theorem of wavelet // IEEE Transactions on Signal Processing. — 2000-05. — Т. 48, вып. 5. — С. 1471–1474. — ISSN 1053-587X. — doi:10.1109/78.839994.
  11. John Krogstie. Quality of Conceptual Models in Model Driven Software Engineering // Conceptual Modeling Perspectives. — Cham: Springer International Publishing, 2017. — С. 185–198.