BMSTU/02-information-processes-and-sysems-modeling-lecture.tex

\documentclass[a4paper,fontsize=14bp]{article}

\author{Кадырбаева Анастасия Рустемовна}
\title{Методы исследования и моделирования информационных процессов и технологий}
\date{2022-02-08}

\input{../common-preamble}
\input{../fancy-listings-preamble}
\input{../bmstu-preamble}
\numerationTop
\usepackage{subfiles}

\begin{document}
\maketitle
\newpage
\tableofcontents
\newpage
\section{Введение}
Можно послушать курс на курсере. Или курс Systems Engineering Focus Area.

Литература: Системноинженерное мышление Левенчук 2020. 3 РКх10, 4 ЛРх10.

ИСО 15288-2015, 42010-2011

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

Системная инженерия отличается от инженерий по специальности тем, что в ней используются специальные средства мышления о целостности целевой системы: средства системного мышления, когда слово “система” обозначает не просто любой объект, а именно систему — и в явном виде используются практики системной инженерии. В инженериях по специальности есть свои способы удержания целостности целевой системы в сборке различных требуемых для её создания деятельностей — но эти способы основаны не столько на общих принципах, сколько на глубоком опыте разработки тысяч и тысяч более-менее однотипных систем. Этот опыт достигается специализацией инженерной работы, обучением и воспитанием.

\subsection{Термины}
\textbf{Процесс} - это набор взаимосвязанны или взаимодействующих действий, преобразующих входы и выходы. Процессы состоят из действий, а действия из задач, которые могут выполнять некоторые акторы(деятели) над/с системой.

\textbf{Нотация} - множество символов и правил их применения, используемые для представления леусических единиц и их взаимоотношений.

\textbf{Архитектурный метод описания} - спецификация соглашений для конструирования и применения группы описаний.

\textbf{Системная инженерия} - междисциплинарный подход и средства для обеспечения реализации успешных систем, определяющий полный набор технических и управленческих усилий, которые требуются для преобразования совокупности потребностей и ожиданий заказчика, имеющихся ограничений. Помогает создателям систем в выделении точек зрения, которые следует использовать для описания мира или разрабатываемой системы. Включает в себя:
\begin{itemize}
\item Эргономика
\item Программная инженерия
\item Управление проектами
\item Управление качеством
\item Менеджмент
\item Математика
\item Компьютерные науки
\item Компьютерная инженерия
\end{itemize}

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

Суть курса:
\begin{itemize}
\item заложить основы системноинженерного мышления
\item научится работать с нотациями, разрабатывать их по ТЗ и читать
\item освоить методы моделирования информационных процессов.
\end{itemize}

\textbf{Методологический статус системной инженерии}
\begin{itemize}
\item Методы и процедуры, почерпнутые из современной науки и созданные специально для неё
\item Развитие системной инженерии не имеет законченной теории и строгой формализации, это связано с тем, что чрезвычайно высокая сложность и разнообразие крупномасштабных систем существенно затрудняет использование точных формализованных методов при их создании.
\item В настоящее время системная инженерия представляет собой междисциплинарный комплекс исследований, подходов и методологий к построению и эксплуатации сложных систем любого масштаба и назначения в различных областях человеческой деятельности
\end{itemize}

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

Работа с \textbf{онтологией} - попытка понять, как и почему мы выделяем в мире те объекты и отношения, которые обозначаются терминами. Т.о. терминология – про язык и слова, онтология – про мир и его объекты.


\textbf{Сообщество} знаний - совокупность людей, которые одинаково понимают суть окружающих предметов и явлений.

\textbf{Семантика} - наука о связи разных обозначений, символов и общими для разных людей и ситуаций значениями и реального мира.

\textit{На слайде изображение карты с размеченными разным цветом областями}. Пример: карта, это один уровень описания, на неё можно дополнительно нанести описание дорог, создание меток о наличии препятствий, карта высот. Получается, что класс А описан языком В который содержит грамматики С. Карта будет являться описанием некоторого уровня. Такие многоуровневые описания называются метамоделями.
\begin{figure}[H]
  \centering
    \begin{tikzpicture}[
      x=0.75pt, y=0.75pt, yscale=-1, xscale=1,
      outline/.style={draw=#1, thick},
      outline/.default=black,
      antenna/.pic={
        \draw(0,0) -- (0,2);
        \draw(0,1) -- (1,2);
        \draw(0,1) -- (-1,2);
      },
      ]
    \tkzblk{outline}{-100,0}{Concept}
    \tkzblk{outline}{100,0}{Occurence}
    \tkzblk{outline}{0,-75}{Descriptor}
    \tkzblk{outline}{0,-200}{Symbol}
    \draw[thin] (-100, -15) -- (-10, -185);
    \draw[thin] (100, -13) -- (10, -185);
    \draw[thin] (-80, -15) -- (-45, -60);
    \draw[thin] (80, -13) -- (45, -60);
    \draw[thin] (0, -90) -- (0, -185);
    \draw[thin] (-62, 0) -- (53, 0);
    \node [] at (0,10) {classifies};
    \node [rotate=90] at (-10,-130) {describes};
    \node [rotate=62] at (-70,-100) {symbolises};
    \node [rotate=-62] at (70,-100) {symbolises};
    \end{tikzpicture}
  \caption{Метауровни}
  \label{pic:metalevels}
\end{figure}

Метамодели и метауровни позволяют описывать модели мира на разных уровнях. Кто будет составлять? И учёные и инженеры, но у них будут разные уровни описания.

\subsection{Инженерия и исследования}
\begin{figure}[H]
  \centering
    \begin{tikzpicture}[
      x=0.75pt, y=0.75pt, yscale=-1, xscale=1,
      outline/.style={draw=#1, thick},
      outline/.default=black,
      antenna/.pic={
        \draw(0,0) -- (0,2);
        \draw(0,1) -- (1,2);
        \draw(0,1) -- (-1,2);
      },
      ]
    \tkzblk{outline}{0,-200}{Компактное описание}
    \tkzblk{outline}{0,0}{Создание систем}
    \tkzdarr{-30,-185}{-30,-15}
    \tkzdarr{30,-185}{30,-15}

    \node [rotate=90] at (-50,-100) {Инженерия};
    \node [rotate=-90] at (50,-100) {Исследования};
    \end{tikzpicture}
  \caption{Цикл разработки системы}
  \label{pic:metadevel}
\end{figure}

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

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

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

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

Системных инженеров учат на работах предшественников, показывают положительные и отрицательные моменты, учат приёмам работы, которые должны давать хорошие результаты.

\paragraph{Развитие и совершенствование инженерии}
S-образные графики по диагонали внахлёст как по х так и по у. От нуля перечисляются поколения:
\begin{enumerate}
\item Алхинженерия - неформальные тексты и эскизы
\item Современная (классическая) инженерия - диаграммы, чертежи, псевдокод
\item Моделе-ориентированная (model-based) инженерия - формальные языки (вычисляемый код)
\item ИИ, гибридные вычисления
\end{enumerate}

\subsection{Система}
\begin{itemize}
\item Иерархия холонов
\item Классы и классификаторы
\item наборы правил, обычаев, процедур, имеющих какую-то структуру
\end{itemize}

\textbf{Успешная система} - результирующая система проекта, учитывающая ролевые потребности затрагивающих систему и её людей, равно как и потребности, затрагиваемых системой и её проектом людей.

\textbf{Система} - индивидуальный, уникальный объект, имеющий некоторую протяжённость в пространстве и времени. Имеет изменяющиеся состояния. Системы меняются по мере взаимодействия с окружающими системами, которые тоже находятся в физическом мире, а внутри них меняются взаимодействующие подсистемы.

\textbf{Документация} - абстрактное описание, записанное на каком-то физическом носителе информации.

\paragraph{Системность и систематичность.}

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

\paragraph{Многоуровневость системного разбиения.}

На самом верхнем уровне - вселенная, на самом нижнем - суперструны.

Явное указание системного уровня важно для управления вниманием

Системные уровни принципиальны, они отражают саму суть системного подхода

Никакого «истинного» или «объективного» разбиения системы на части нет.

\section{Стандартный язык нотаций UML}
Для разработки ПО нужно понимать, что нужно пользователю. Обсуждать конкретные требования к разрабатываемой системе. Для быстрой и эффективной разработки ПО с имнимальным браком требуется: привлечи рабочую силу, выбрать технологию...

Зачем нужно моделирование?
\begin{itemize}
\item наглядная демонстрация структуры и поведения
\item визуализация и управление архитектуры системы
\item помогает добить ся лучшего понимания создаваемой системы
\item упрощение системы
\item обеспечивает возможность повторного использования
\item минимизация рисков
\end{itemize}

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

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

\textbf{Моделирование} – это устоявшаяся и повсеместно принятая инженерная методика. Мы строим архитектурные модели зданий, чтобы помочь их будущим обитателям во всех деталях представить готовый объект. Иногда применяют даже математическое моделирование зданий, чтобы учесть влияние сильного ветра или землетрясения. Очевидно, моделирование применяется не только в строительстве.

\textbf{Модель} – абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме. С точки зрения общих принципов системного анализа одна и та же физическая система может быть представлена несколькими моделями. При этом назначение отдельной модели системы определяется характером решаемой проблемы. Основные требования к модели программной системы состоит в том, что она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес-аналитиков и программистов. Разработка и использование моделей языка UML осуществляется в рамках общей концепции объектно-ориентированного анализа и проектирования, которая, в свою очередь, является обобщением методологии объектно-ориентированного программирования. 

Модель позволяет:
\begin{itemize}
\item визуализировать систему в её текущем или желательном сосотоянии, 
\item описать структуру или поведение системы, 
\item получить шаблон, позволяющий сконструировать систему, 
\item докуентировать принимаемые решения, используя полученные модели.
\end{itemize}

\subsection{Принципы моделирования}
\begin{enumerate}
\item Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение. Правильно выбранная модель высветит самые опасные проблемы разработки и позволит описать суть задачи. Даёт дополнительную информацию, позволяет проработать больше различных сценариев. Каждая модель может быть представлена с различной степенью точности.

Мы будем использовать диаграммы Феймана, которая позволит описать задачу с разных точек зрения. Если вы смотрите на систему глазами разработчика баз данных, то внимание будете уделять моделям «сущность-связь», где поведение инкапсулировано в триггерах и хранимых процедурах. Аналитик, использующий структурный подход создал бы модель, в центре которой находятся алгоритмы и передача данных от одного процесса к другому. Результатом труда разработчика, пользующегося объектно-ориентированным методом, будет система, архитектура которой основана на множестве классов и образах взаимодействия, определяющих как классы действуют совместно. Любой из этих вариантов может оказаться подходящим для разработки методики или приложения. Хотя более эффектинвой будет объектно-ориентированная точка зрения при создании гибких архитектур.
\item Каждая модель может быть представлена с различной степенью точности.

Лучшей моделью окажется та, которая позволит выбрать уровень детализации в зависимости от того, кто и с какой целью на нее смотрит. Для аналитика или конечного пользователя наибольший интерес представляет вопрос «что», а для разработчика – «как». В обоих случаях необходима возможность рассматривать систему на разных уровнях детализации в разное время.
\item лучшие модели те, что ближе к реальности. Модель всегда упрощает реальность, задача - чтобы упрощение не повлекло за собой существенные потери. Проблема при проектировании ПО - несоответствие принятой в нём модели и модели системного проекта. При объектно ориентированного подхода можео объединить все почти независимые представления системы в единое семантическое целое.

При объектно-ориентированном подходе можно объединить все почти независимые представления системы в единое семантическое целое.
\item нельзя ограничиваться созданием только одной модели.

Наилучший подход при разработку любой нетривиальной системы – использовать совокупность нескольких моделей, почти независимых друг от друга. Если вы конструируете здание, никакой отдельный комплект чертежей не поможет вам прояснить все детали до конца. Понадобятся как минимум поэтажные планы, виды в разрезе, схемы электропроводки, центрального отопления и водопровода.
\end{enumerate}
Для понимания архитектуры подобной системы требуется несколько взаимодополняющих представлений:
\begin{itemize}
\item представление с точки зрения вариантов использования (чтобы выявить требования к системе);
\item с точки зрения проектирования (чтобы построить словарь предметной области и области решения);
\item с точки зрения взаимодействий (чтобы смоделировать взаимодействия между частями системы, системой в целом и средой ее функционирования);
\item с точки зрения реализации (позволяющее рассмотреть физическую реализацию системы);
\item с точки зрения размещения (помогающее сосредоточиться на вопросах системного проектирования).
\end{itemize}
Каждое из перечисленных представлений имеет множество структурных и поведенческих аспектов, которые в своей совокупности составляют детальный чертеж программной системы.

\subsection{Методы моделирования, UML}
Алгоритмический
\begin{itemize}
\item традиционный подход к созданию ПО;
\item основан на процедурах и функциях;
\item вопросы передачи управления и декомпозиции б\'{о}льших алгоритмов на меньшие.
\end{itemize}

Объектно-ориентированный
\begin{itemize}
\item современный подход;
\item основные блоки - объекты и классы;
\item каждый блок обладает идентичностью, состоянием и поведением.
\end{itemize}

ОО подход помогает отвечать на вопросы:
\begin{itemize}
\item какая структура должна быть у хорошей ОО архитектуры
\item какие артефакты должны быть созданы в процессе работы над проектом
\item кто создаёт артефакты
\item как оценить результат работы
\end{itemize}

Унифицированный язык моделирования (Unified Modeling Language – UML) – это стандартный инструмент для разработки «чертежей» программного обеспечения. Его можно использовать для визуализации, спецификации, конструирования и документирования артефактов программных систем. UML – всего лишь язык, и как таковой представляет только одну из составляющих процесса разработки программного обеспечения. Хотя UML не зависит от моделируемых процессов, лучше всего применять его в тех случаях, когда процесс моделирования основан на применении вариантов использования, сконцентрирован на архитектуре системы, является итеративным и пошаговым. 

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

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

UML имеет три вида блоков:
\begin{itemize}
\item Сущности – абстракции, которые являются основными элементами модели
  \begin{itemize}
  \item Структурные – в основном это статические части модели, представляющие либо концептуальные, либо физические элементы. В совокупности структурные сущности называются классификаторами. Структурные сущности это: класс, интерфейс, кооперация (collaboration), компонент, артефакт, сервер.
  \item Поведенческие – динамические части моделей. Так сказать «глаголы», представляющие поведение во времени и пространстве. Это: взаимодействие (interaction, обмен сообщениями между наборами объектов или ролей в определенном контексте достижения целей), автомат (state machine, поведение, характеризуемое последовательностью состояний объекта), деятельность (activity – последовательность шагов вычислений).
  \item Группирующие сущности – организованная часть моделей. Самый распространенный элемент – пакет, т.е. механизм общего назначения для организации проектных решений, который упорядочивает конструкцию реализации.
  \item Аннотирующие сущности – т.е. поясняющие части, комментарии для описания выделения и пояснения любого элемента модели. Примечания.
  \end{itemize}
\item Связи – соединяют между собой сущности
  \begin{itemize}
  \item Зависимость – связь между двумя элементами модели, в которой изменение одного элемента может привести к изменению семантики другого элемента.
  \item Ассоциация – структурная связь между классами, которая описывает набор связей, существующих между объектами – экземплярами классов. Агрегация – особая разновидность ассоциации, представляющая структурную связь целого с его частями.
  \item Обобщение – связь, в которой специализированный элемент (потомок) строится по спецификациям обобщенного элемента (родителя).
  \item Реализация – семантическая связь между классификаторами, когда один из них специфицирует соглашение, которого второй обязан придерживаться.
  \end{itemize}
\item Диаграммы – группируют представляющие интерес наборы сущностей.
\end{itemize}

\subsection{Правила UML}
Хорошо согласованная модель - та, которая семантически самосогласована и находится в гармонии со всеми другими моделями, связанными с ней.

\subsection{Механизмы UML}
\textbf{Спецификация.}  За каждой частью его графической нотации стоит спецификация (specification) содержащая текстовое представление синтаксиса и семантики определенного строительного блока. С помощью графической нотации UML вы визуализируете систему, с помощью спецификаций UML описываете ее детали. Таким образом, допускается последовательное построение модели – шаг за шагом, когда сначала рисуются диаграммы, а затем добавляется семантика к спецификациям модели, – или же напрямую, когда в первую очередь создаются спецификации (возможно, при выполнении обратного проектирования существующей системы), а затем рисуются диаграммы, представляющие их проекции.
Спецификации UML создают семантический задний план, который включает в себя все составные части всех моделей системы, согласованные между собой. Таким образом, диаграммы UML – это простые визуальные проекции на этот задний план, при этом каждая из них раскрывает некоторый существенный аспект системы.

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

\textbf{Архитектура} набор существенных решений относительно организации программной системы, выбора структурных элементов, составляющих систему и их интерфейсов; поведения этих элементов, определенного в их кооперациях; объединения структурных и поведенческих элементов в более крупные подсистемы; архитектурного стиля, определяющего организацию системы? Статические и динамические элементы и их интерфейсы, кооперацию и композицию.

\subsection{Представления}
\section{MDA, MDD, генерация кода}
MDA - model-driven architecture - суть в построении метамодели управления и обмена метаданными с заданием разных способов и технологий программирования. Модель - это основной артефакт разработки, из которой будет генерироваться не только код, но и другие артефакты. Главный стандарт - UML. Достоинство - множество методов описания, множество уровней. Есть недостаток в выразительности, ограниченности архитектуры языком UML.

MOF - meta object facility. Стандарт, целью которого является предоставление системы типов для сущностей и набор интерфейсов с помощью которых можно создавать эти типы. Реализовано как четырёхслойная архитектура. Помимо этих уровней есть средства описания моделей, например стандарт XMI который может и поддерживать МОФ и описывать модели сам по себе, аналогично уровням 1-3 МОФа.

EMF - Eclipse Modeling Framework. Предназначен для понятного метамоделирования и визуализации моделей. Модели просты, но предназначены для смешивания с написанным «от руки» кодом. обеспечивает унифицированное представление структур данных, описанных в приложении. Модели представлены в виде внутренней структуры.

(слайд 13) Применение моделе-управляемого подхода. Получаем второй этап: платформо-независимые модели. Важным аспектом будет визуальное моделирование. Третий этап - это платформо-зависимые модели. Четвёртый этап - это генерация кода. Ecore поддерживает джавские аннотации и поэтому может создавать экземпляры модели. ЕКор поддерживает ряд других концепций, которые не поддерживаются джавой, например, двунаправленные отношения.

Представление вариантов использования системы охватывает варианты использования, описывающие поведение системы с точки зрения конечных пользователей, аналитиков и тестировщиков.
Их взгляд в дейст вительности специфицирует не истинную организацию программной системы, а лишь некие движущие силы, формирующие системную архи тектуру. В языке UML статические аспекты этого представления передаются диаграммами вариантов использования, а динамические его аспекты – диаграммами взаимодействий, состояний и деятельности.
Представление системы с точки зрения дизайна охватывает классы, интерфейсы и кооперации, формирующие словарь проблемы и ее решение. Это представление в основном поддерживает функциональные требования к системе, то есть сервис, который она должна предоставлять конечным пользователям. Статические аспекты этого представления в UML сосредоточены в диаграммах классов и объектов, а динамические передаются диаграммами взаимодействий, состояний и деятельности. Диаграмма внутренней структуры класса, в частности, также полезна.
Представление взаимодействия системы показывает поток управления, проходящий через разные ее части, включая возможные механизмы параллелизма и синхронизации. Это представление касается производительности, масштабируемости и пропускной способности системы. Статические и динамические аспекты этого представления в UML представлены в некоторых видах диаграмм, используемых в представлении дизайна, но сфокусированы на активных классах, управляющих системой, и передаваемых между ними сообщениях.
Представление реализации системы охватывает артефакты, используемые для сборки и физической реализации системы. Это представление в первую очередь относится к управлению конфигурацией версий системы, состоящей из независимых (в определенной степени) файлов и компонентов, которые могут быть собраны различными способами для формирования работающей системы.
Оно также связано с отображением из логических классов и компонентов в физические артефакты. В UML статические аспекты этого представления отражены в диаграммах артефактов, динамические аспекты – в диаграммах взаимодействия, состояний и деятельности.
Представление развертывания системы охватывает узлы, образующие топологию оборудования, на котором работает система. Это представление в основном связано с поставкой, распределением и установкой частей, составляющих физическую систему. Его
статические аспекты в UML описываются диаграммами размещения, а динамические – диаграммами взаимодействий, состояний и деятельности. Каждое из этих пяти представлений может быть достаточным для различных заинтересованных лиц, имеющих отношение к разработке и эксплуатации системы, позволяя им сосредоточиться только на тех аспектах архитектуры, которые непосредственно их касаются. Однако все эти представления также взаимодействуют друг с другом. Узлы из представления размещения содержат компоненты из представления реализации, которые, в свою очередь, представляют собой физическую реализацию классов, интерфейсов, коопераций и активных классов из представлений дизайна, и взаимодействия.

\section{X-Text}
Язык DSL - структура отражает решаемые языком задачи. DSL - это предметно-специфический язык (domain-specific language). Объединяет кроме текста и графики ещё и концептуальную часть. Деление довольно условно, потому что любой описанный протокол на общих языках - это вариация DSL. Это ЯП более высокого уровня абстракции и оперируют правилами.

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

Использует грамматику основного языка, может формировать внутренние DSL.

Правила Х-текста
\begin{itemize}
\item правила лексем
\item правила данных
\item правила разбора
\end{itemize}
Х-текст значительно упрощает формальный язык.

Семантические правила закладываются в два этапа - на этапе написания грамматика и на этапе внедрения. Можно описывать валидацию программ (статический анализ на предмет корректности). Формируем абстрактное синтаксическое дерево.

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

\section{Archmate Framework}
архитектор предприятия - это технический специалист, который получил специальное образование, способный заниматься проектированием, анализом и внедрением информационных систем. Архитектура организации это область знаний об организованности отдельных элементов предприятия. Архитектура - это совокупность некоторых принципов и правил.

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

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

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

Модель Garner фактически не определяет ничего. в методике сформулированы ряд шагов, не детализированных до конкретных процессов. этапов 4 - бизнес, техническая архитектура, инфраструктура, безопасность. в 2007 добавили таймлайн, то есть наложили изменения системы на временную ось. Архитектура предприятия может иметь больше трёх осей (измерений). Элементы очень похожи на UML. Есть механизм типов. Для каждого типа вопросов есть своя диаграмма.

Archmate.
делит модели на внутреннюю и внешнюю структуру. Сервис и интерфейс - это единицы функциональности, которые предоставляют приложения внутри или снаружи

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

\newpage
\section{BPMN}
модель должна давать полное точное и адекватное описание системы.
нотация - это графические элементы для построения модели
аналитическое моделирование заключается в построении модели, основанной на описании поведения объекта или системы объектов в виде аналитических выражений. разработка исполняемых моделей использует более точные методы моделирования.

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

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

Есть три уровня управления:
\begin{enumerate}
\item оперативное - исполнение каждого экземпляра с целью выявить те, которые выполняются с отклонениями. уменьшает число брака
\item тактическое - контроль показателей на краткосрочном интервале. не предполагает изменения процессов
\item стратегическое - контроль параметров на долгосрочном интервале. маркетинговые исследования, корпоративный дизайн.
\end{enumerate}

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

\section{GSN, i*}
Зачем выявлять требования? чтобы сделать точные и достаточные сценарии. Цели помогают понять кто чего хочет, объяснить угрозы, понять корректирующие меры и альтернативы.

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

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

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

Критерии прохождения развилок на основе целей - размерности в котором оцениваются цели.

Предполагается следующий алгоритм:
\begin{itemize}
\item моделируем цели
\item определяем контекст
\item определить интерфейс
\item исследовать варианты
\item ...
\end{itemize}

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

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

GSN - Goal Structuring Notation
Результат должен быть достижим. Цели структурируют чтобы предварительно подготовить аргументы, используется для выделения того, чего не хватает на схеме или в начинании. 

\appendix
\setcounter{secnumdepth}{0}
\section*{Приложения}
\addcontentsline{toc}{section}{Приложения}
\renewcommand{\thesubsection}{\Alph{subsection}}

\subsection{Семинар 1 2022-02-11}
Систему можно рассматривать с разных точек зрения (программист, аналитик, заказчик). Система имеет назначение в своём физическом окружении. Назначение системы - это её функция или поведение, игра по роли. Система прежде всего называется по её роли/назначению/поведению, функции.

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

В роль неправильно указывать
\begin{itemize}
\item человека
\item начальника
\item звание
\item организацию
\end{itemize}

В проекте достаточно указать 5 внешних ролей. Обычно забывают про множественность интересов и собственные интересы. Системные уровни:
люди 5 мин в локации с 16.05 и до 16.10 танцуют:
\begin{itemize}
\item врач смотрит с точки зрения здоровья
\item тренер смотрит на системные органы
\item учитель смотрит на то как выполняются движения
\item хореограф смотрит на общую композицию
\item зрители и родственники смотрят на сочетание картинки и ритма
\end{itemize}

\subsubsection{Задание: диаграмма активности}
Испольуется для описания процессов в зависимости от текущего состояния системы (см диаграмму состояний). Стандартизирует внешний вид описания действий, непосредственной логики.
\begin{itemize}
\item прямоугольник с закруглениями - обычная операция
\item ромб - обычно if, но формально - switch
\item широкие полосы - многопоточность, параллелизм
\item начало
\item конец
\end{itemize}

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

% -а ещё есть расширение SDL которое формализует прямоугольники для описания
% СОСТОЯНИЕ
% ВЫЗОВ ПРОЦЕДУРЫ
% ВВОД
% ВЫВОД
% СОХРАНЕНИЕ
% ЗАДАЧА
% РЕШЕНИЕ

\subsection{Семинар 2 2022-02-25}
Диаграмма классов.
\begin{enumerate}
\item в е ж \item а б \item б е ж \item б в г д е
\item в \item г \item б г \item е \item в г
\item а б в г е з \item б \item а б в г \item в
\end{enumerate}
\end{document}