492 lines
50 KiB
TeX
492 lines
50 KiB
TeX
\documentclass{article}
|
||
|
||
\input{../common-preamble}
|
||
\input{../bmstu-preamble}
|
||
\input{../fancy-listings-preamble}
|
||
\author{Девятков Владимир Валентинович}
|
||
\title{Системная инженерия}
|
||
\date{2022-09-05}
|
||
|
||
\begin{document}
|
||
\maketitle
|
||
\tableofcontents
|
||
\newpage
|
||
|
||
\section{Системная инженерия}
|
||
Системная инженерия - Полный набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей и ожиданий клиента и имеющихся ограничений в реализацию и поддержку этой реализации на протяжении ее существования. Целостное и согласованное понимание потребностей заинтересованных сторон. Исследование возможностей реализации. Документирование требований к реализации. Синтез, верификация, валидация и развитие решений при при осуществлении реализации во всей полноте от исследования замысла системы до её ликвидации.
|
||
|
||
Стандартизация
|
||
\begin{itemize}
|
||
\item International Council on Systems Engineering, INCOSE: развивает междисциплинарный подход и средства для обеспечения реализации успешных систем (см. Guide to the Systems Engineering Body of Knowledge, SEBOK).
|
||
\item ISO/IEC/IEEE 24765:2010: междисциплинарный подход - полный набор технических и управленческих усилий, необходимых для преобразования совокупности потребностей и ожиданий клиента и имеющихся ограничений в решение для поддержки этого решения на протяжении его жизни
|
||
\end{itemize}
|
||
|
||
Авторские определения
|
||
\begin{itemize}
|
||
\item Sage A.P. ... проектирование, производство и сопровождение заслуживающих доверия систем с учетом стоимостных и временных ограничений
|
||
\item Д. Хитчинс, бывший президент, INCOSE ... искусство и наука создания эффективных систем на основе целостного подхода к системе и принципам её жизни
|
||
\item А. И. Левенчук , президент российского отделения INCOSE ... это про то, как создать что угодно (от зубочистки до марсохода) в соответствии с требованиями заказчика, и при этом соблюсти бюджет и сроки
|
||
\item Н. П. Бусленко, Большая советская энциклопедия, 1976 . Научно-техническая дисциплина, охватывающая вопросы проектирования, создания, испытания и эксплуатации сложных систем (больших систем, большого масштаба (large scale systems))
|
||
\end{itemize}
|
||
|
||
Что такое успешная система?
|
||
\begin{itemize}
|
||
\item Система успешна тогда и только тогда, когда с ее помощью добиваются успеха все ключевые стейкхолдеры (заинтересованные стороны) (Д. Хитчинс)
|
||
\item Система успешна тогда и только тогда, когда в выигрыше окажутся все критически важные заинтересованные стороны (стейкхолдеры) (Б. Боэм)
|
||
\end{itemize}
|
||
|
||
В США
|
||
\begin{itemize}
|
||
\item 1940-е: Появление очень сложных проектов: морские операции на Тихом океане, ядерный проект.
|
||
\item 1950-1960-е:
|
||
\begin{itemize}
|
||
\item Увеличение числа сложных проектов: например, космический проект.
|
||
\item Появление первых работ, описывающих подходы к созданию сложных систем
|
||
\item СИ впервые появилась как метод ведения работ в МО США по созданию МБР (межконтинетальных баллисьтических ракет) на базе двух уже сверхсложных инженерных проектов:
|
||
\begin{itemize}
|
||
\item атомного проекта,
|
||
\item проекта создания баллистических ракет.
|
||
\end{itemize}
|
||
\end{itemize}
|
||
\item 1965 - А. Д. Холл «Методология системной инженерии» :
|
||
Системная инженерия многоаспектна. Цель процесса СИ является оптимальное проведение границ между человеческими интересами, системой и ее окружением. В окружении выделяются:
|
||
\begin{itemize}
|
||
\item Физическое и техническое окружение.
|
||
\item Деловое и экономическое окружение.
|
||
\item Социальное окружение.
|
||
\item СИ исследует потребности рынка и возможность изменения этих потребностей как в настоящем, так и в будущем.
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
В СССР
|
||
\begin{itemize}
|
||
\item 1920 - План ГОЭЛРО, описывавший развитие электроэнергетики. К плану были привязаны:
|
||
\begin{itemize}
|
||
\item Проекты по индустриализации.
|
||
\item Проекты по развитию инфраструктуры.
|
||
\item Планы развития территорий.
|
||
\end{itemize}
|
||
|
||
Размеры:
|
||
\begin{itemize}
|
||
\item В разработке участвовало более 200 учёных и инженеров.
|
||
\item Период от 10 до 15 лет.
|
||
\end{itemize}
|
||
\item 1962 - появляется термин «Системотехника» в результате перевода книги «System Engineering: An Introduction to the Design of Large-scale Systems».
|
||
\item 1960-1980:
|
||
\begin{itemize}
|
||
\item Создается научная школа системотехники, включая НИИ, кафедры и дисциплины в ВУЗах.
|
||
\item Ведутся работы по выполнению больших и сверхбольших проектов.
|
||
\end{itemize}
|
||
\item Системотехника 80-х
|
||
|
||
Теория:
|
||
\begin{itemize}
|
||
\item Научные школы.
|
||
\item Специализированные издания, публикации.
|
||
\item Подготовка специалистов.
|
||
\end{itemize}
|
||
|
||
Практика:
|
||
\begin{itemize}
|
||
\item Свелась к разработке ПО для АСУ.
|
||
\item Практически не влияла на управление производством, разработку, внедрение.
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
Поколения СИ
|
||
\begin{itemize}
|
||
\item Классическая системная инженерия
|
||
\begin{itemize}
|
||
\item Использование диаграмм
|
||
\item Предназначены для чтения и интерпретации только людьми, описание системы нельзя формально проверить
|
||
\end{itemize}
|
||
\item Системная инженерия на основе моделей (model-based systems engineering)
|
||
\begin{itemize}
|
||
\item Использование формальных моделей
|
||
\item Модели могут быть непосредственно обработаны (проверены, оптимизированы) компьютером
|
||
\item Позволяет достигать принципиально другой сложности систем
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
\subsection{Системная инженерия как процесс}
|
||
\begin{itemize}
|
||
\item Формулировка потребностей (требований заказчика)
|
||
|
||
Формулировка потребностей включает изложение «принципов» (principles) и «концепций» (concepts), как набора компонентов, взаимодействующих между собой для достижения целей. Этими компонентами могут быть :
|
||
\begin{itemize}
|
||
\item «Железо» hardware, ПО, firmware
|
||
\item Люди (не только пользователи)
|
||
\item Информация (например, структуры БД)
|
||
\item «Техники» (techniques)
|
||
\item Здания, помещения и другая инфраструктура (facilities)
|
||
\item Сервисы (services)
|
||
\end{itemize}
|
||
|
||
\item Постановка задачи
|
||
|
||
Системный инженер поддерживает междисциплинарный подход и переводит потребности заказчика в задания исполнителям, помогает оценивать соответствие результатов разработки этим потребностям. Системный инженер учитывает взаимодействие с окружающей средой, которая может представлять собой:
|
||
\begin{itemize}
|
||
\item другие системы,
|
||
\item пользователей,
|
||
\item физический окружающий мир.
|
||
\end{itemize}
|
||
|
||
\item Обеспечение реализации системы
|
||
|
||
Системные инженеры для обеспечения реализации успешных систем анализируют выполнение процессов жизненного цикла, начиная с раннего этапа концептуального принятия решений (conceptual design), на всем жизненном цикле системы, включая производство, развертывание/внедрение (deployment) эксплуатацию и вывод из нее. Системный инженер должен анализировать, составлять ТЗ (specify), разрабатывать архитектуру (design) и проверять на соответствие потребностям следующие характеристики системы:
|
||
\begin{itemize}
|
||
\item Функциональность.
|
||
\item Интерфейсы.
|
||
\item Производительность.
|
||
\item Физичекое состояние.
|
||
\item Баланс между ценой и соответствием потребностям
|
||
\end{itemize}
|
||
|
||
\item Обеспечение взаимодействия компонентов
|
||
|
||
Системный инженер помогает обеспечить взаимодействие компонентов системы (fit together) для достижения общих целей системы, а также удовлетворения потребностей заказчиков и других заинтересованных лиц, которые получают (принимают, acquire) систему и далее ее используют.
|
||
\end{itemize}
|
||
|
||
\subsection{Главные свойства системной инженерии}
|
||
Целостность (holistic) — это ключевое свойство, отличающее СИ от всех остальных инженерных дисциплин. Целостность включает:
|
||
«Междисциплинарность» - полнота охвата всех необходимых дисциплин. Целостность всех действий по созданию системы. Целостность/полнота проблемы. Охват всего жизненного цикла системы «от рождения до смерти».
|
||
|
||
Параллельность выполнения самых разных практик, а не последовательное выполнение их во времени. Разнесение:
|
||
\begin{itemize}
|
||
\item Нужд пользователей и требований к реализации.
|
||
\item Проверки и приёмки.
|
||
\item Синтеза и аналитики.
|
||
\end{itemize}
|
||
|
||
СИ как единое целое это
|
||
\begin{itemize}
|
||
\item Область применения: Большие (сложные) системы, весь их жизненный цикл.
|
||
\item Философия (мировоззрение): Системный взгляд на все.
|
||
\item Средства: Совокупность практик, процессов, методов.
|
||
\end{itemize}
|
||
|
||
\subsection{Будущее системной инженерии}
|
||
Поискориентированная системная инженерия (search-based systems engineering) на основе интеллектуального компьютерного рассуждения при поиске и обосновании требований, архитектуры, методов, практик и т.п.:
|
||
\begin{itemize}
|
||
\item Искусственная интеллектуальная генерация вариантов инженерных решений.
|
||
\item Искусственное интелектуальное умение оценить варианты.
|
||
\item Искусственные интеллектуальные гибридные рассуждения при достижении целей.
|
||
\end{itemize}
|
||
|
||
Цели и контракты
|
||
\begin{itemize}
|
||
\item Формалные синтез и оптимизация архитектуры, соответсвующей контрактам и целям
|
||
\item Искусственное воображение
|
||
\item Использовние методов ИИ (например, вариации «генетических алгоритмов» или «обучаемых нейронных сетей»)
|
||
\item Порождающее проектирование (generative design)
|
||
\item Пока больше используется для визуализации данных, но может быть применено для вычисления оптимальной формы объектов
|
||
\end{itemize}
|
||
|
||
\section{Концептуальные аспекты инженерии знаний}
|
||
Знания – основа интеллектуальности систем. Знания в системах искусственного интеллекта обычно хранятся в базах знаний. Знания содержат информацию как о конкретных (константных) фактах в той или иной предметной области (среде, мире), так и о более общих законах и свойствах, позволяющих получать (рассуждать, выводить) новые знания. Понятие "знание" имеет два аспекта: декларативный и процедурный.
|
||
|
||
\textbf{Декларативные знания} не содержат в явном виде описание процедур, которые необходимо выполнить в процессе вывода.
|
||
Вывод на основе декларативных знаний осуществляется по определенной стратегии вывода специальной машиной вывода (решателем).
|
||
Например, вывод (поиск решения) может быть организован как поиск в пространстве состояний, и сводится к нахождению последовательности состояний ведущих из начального состояния (начальных) в целевое состояние.
|
||
|
||
\textbf{Процедурные знания} - это знания, представляемые в виде процедур, с помощью которых осуществляется вывод. Вывод на основе процедурных знаний также может осуществляться машиной вывода, организующей вызов процедур в соответствии с определенной стратегией.
|
||
|
||
Сочетание преимуществ декларативного и процедурного подхода к представлению знаний по-разному воплощается в различных языках и моделях представления знаний.
|
||
|
||
ИИ функционирует на основе знаний
|
||
ИИ занимается созданием специализированных моделей и языков для представления знаний в ЭВМ,
|
||
ИИ занимается созданием специальных средств, позволяющих пополнять и обобщать знания.
|
||
ИИ занимается созданием программных и аппаратных средств для работы со знаниями;
|
||
ИИ занимается созданием методов формирования планов достижения целей и решения сложных задач, не поддающихся решению другими методами, кроме как на основе использования знаний
|
||
ИИ занимается созданием средств восприятия мультимодальной информации (зрительной, слуховой, тактильной и др),
|
||
ИИ занимается развитием методов мультимодальной обработки и формирования ответных реакций на воздействия внешней среды,
|
||
ИИ занимается развитием методов адаптации искусственных систем к среде путем обучения.
|
||
|
||
Какое представление знаний нам необходимо?
|
||
Насколько представление знаний должно быть понятным и ясным?
|
||
Насколько представление знаний должен быть лаконичным?
|
||
Насколько оно должно быть вычислительно эффективным (способным порождать новые знания)?
|
||
Насколько оно должно быть модульным?
|
||
Насколько оно должно быть доступным из разных мест?
|
||
Какова должна быть охватываемая область представления?
|
||
Какова должна быть неделимая часть?
|
||
Каков должен быть уровень детализации?
|
||
Должен ли быть базовый словарь?
|
||
Насколько легко можно знания модифицировать?
|
||
Могут ли быть изменены отдельные элементы без влияния на другие?
|
||
Как представлять отдельные модули?
|
||
Каков должен быть механизм извлечения знаний?
|
||
Каковы должны быть отношения между старыми и новыми знаниями?
|
||
Какова должна быть форма обобщения и специализации знаний?
|
||
Какова должна быть процедура поиска необходимых знаний?
|
||
Как знания должны быть организованы: иерархически, на базе отношений, ассоциативно?
|
||
Какие отношения возможны между группами знаний?
|
||
Нужны ли оба механизма работы со знаниями: синтаксический и семантический?
|
||
Какой нужен механизм вывода?
|
||
Нужно ли поддерживать дедуктивный, индуктивный и абдуктивный выводы?
|
||
Нужно ли продолжать вывод, если информация стала неопределенной?
|
||
Нужно ли продолжать вывод, если информация отсутствует?
|
||
Должны ли все знания быть явно представленными или решатель может дополнять их?
|
||
Какие знания должны быть представлены обязательно явно?
|
||
Может ли структура представления знаний расширяться и модифицироваться?
|
||
Может ли решатель модифицироваться?
|
||
|
||
\subsection{Дедукция, абдукция, индукция}
|
||
\begin{table}[H]
|
||
\centering
|
||
\begin{tabular}{|r|c|c|c|}
|
||
\hline
|
||
Последовательность логических действий & Дедукция & Абдукции & Индукция \\ [0.5ex]
|
||
\hline\hline
|
||
Логический шаг №1 & Анализ заранее заданной гипотезы & Анализ и точная оценка фактов & Анализ и точная оценка частных фактов \\
|
||
Логический шаг №2 & Вывод следствий из гипотезы и их сопоставление с фактами & Выбор гипотезы для объяснения фактов & Движение мысли от частного к общему\\
|
||
\hline
|
||
\end{tabular}
|
||
\caption{Table to test captions and labels.}
|
||
\label{table:1}
|
||
\end{table}
|
||
|
||
Абдукция – это «обратная» дедукция, так сказать, дедукция, поставленная с ног на голову. Если в дедукции рассуждение развивается от посылки к следствию, то в случае абдукции – в противоположном направлении, то есть от следствия к посылке. Нормальное дедуктивное рассуждение таково «Все люди смертны, Сократ – человек, следовательно, Сократ смертен». Здесь налицо логически необходимый вывод.
|
||
В случае абдукции силлогизм приобретает следующую форму: «Все люди смертны, Сократ смертен, следовательно, Сократ человек». Может показаться, что здесь все нормально, но если вдуматься, то становится ясно, что вывод неправильный: из того, что Сократ смертен, вовсе не следует, что Сократ человек, ведь смертны и кошки, и собаки, и бабочки, и, может быть, деревья.
|
||
|
||
Трудности обмена знаниями
|
||
Представление знаний даже об одних и тех же вещах и на одном и том же языке может быть различным.
|
||
Это приводит к трудностям обмена знаниями между людьми, организациями и программами, и, в частности, к трудностям формирования однозначно понимаемых требований и спецификаций для сложных систем.
|
||
Несмотря на достаточно продвинутый уровень развития сложных систем, возможности повторного использования и распространения знаний ограничены.
|
||
Это приводит к повторным усилиям по извлечению и необходимых знаний.
|
||
|
||
\begin{verbatim}
|
||
Источник -> Структурирование -> Представление
|
||
файлы графы Модели
|
||
Хаос Извлечение Формализация
|
||
\end{verbatim}
|
||
|
||
\subsection{Стандартизация знаний}
|
||
Ответ на многие из поставленных вопросов может быть получен путем стандартизации знаний?
|
||
Стандартизация устранит или сведет к минимуму концептуальную и терминологическую путаницу и установит однозначное понимание языка, используемого для представления знаний
|
||
Такой язык должен служить средством
|
||
стандартизации представления знаний,
|
||
коммуникации между людьми, имеющими различный взгляд на одни и те же вещи,
|
||
взаимодействия между программными системами путем трансляции в него и из него,
|
||
обеспечения возможности повторного использования благодаря формальной спецификации,
|
||
автоматизации проверки корректности знаний,
|
||
адекватного представления других языков представления знаний.
|
||
|
||
Трудности извлечения знаний
|
||
организационные неувязки;
|
||
неудачный метод извлечения, не совпадающий со структурой знаний в данной области;
|
||
неадекватная модель (язык) для представления знаний.
|
||
неумение наладить контакт с источником знаний;
|
||
терминологический разнобой;
|
||
отсутствие целостной системы знаний в результате извлечения только «фрагментов»;
|
||
упрощение «картины мира» и др.
|
||
|
||
Концептуальные графы
|
||
Авторы идеи - Новак и Говин (Novak and Gowin). 1960-ые. Большой вклад внес David Ausubel.
|
||
Этапы
|
||
выделение концептов — базовых понятий данной предметной области(обычно не более 15-20 понятий);
|
||
определение отношений и взаимодействий базовых понятий;
|
||
уточнение, удаление лишних связей, снятие противоречий.
|
||
Типичные ошибки:
|
||
• Целые предложения вместо отдельных концептов
|
||
• Линейность
|
||
• Слишком много пересекающихся отношений
|
||
• Слишком много концептов
|
||
• Неверно определенные типы отношений
|
||
“Хороший” граф обычно получается после 2-3 итераций.
|
||
Software: CmapTools
|
||
|
||
Основные виды отношений
|
||
родо-видовые ("класс-подкласс", "элемент-множество", "часть - целое" и т.п.),
|
||
• функциональные (определяемые обычно глаголами, ’’производит”, “влияет”...),
|
||
• атрибутивные (иметь свойство, иметь значение),
|
||
• причинно-следственные (если-то)
|
||
• количественные (больше, меньше, равно...),
|
||
• пространственные (далеко от , близко от, за, под, над),
|
||
• временные (раньше, позже, в течение...),
|
||
• логические (и, или, не),
|
||
• лингвистические (синонимия, антонимия) и др.
|
||
|
||
\subsection{Формализация}
|
||
Теория
|
||
Это тройка ℜ = {L, S, С}, где
|
||
L – язык формальной модели с присущими ему синтаксисом, т.е. L = {T, G},
|
||
S – совокупность начальных знаний, сформулированных на языке L;
|
||
C – абстрактная машина или машина вывода, которая, используя правила вывода P и определенную стратегию вывода, осуществляет формирование в языке L новых знаний, начиная с начальных.
|
||
Таким образом машина вывода является двойкой С = {P, Ω}, где Ω - стратегия вывода, согласно которой абстрактная машина C, используя правила вывода P осуществляет вывод.
|
||
Правила вывода не обязательно являются правилами логического вывода, поскольку формальные модели могут быть не только логическими.
|
||
|
||
Язык
|
||
Формальный язык L в соответствии с современными представлениями требует рассмотрения двух его неотъемлемых частей: синтаксиса и семантики.
|
||
Синтаксис языка описывает допустимые в языке предложения, состоящие из цепочек терминальных символов, принадлежащих определенному терминальному алфавиту.
|
||
Синтаксис языка позволяет отличать предложения, принадлежащие языку, от предложений, ему не принадлежащих.
|
||
Семантика языка определяет смысл предложений языка.
|
||
Без семантики предложения языка являются ничего незначащими цепочками символов
|
||
|
||
Формализацией задачи будем называть создание для ее решения формальной модели.
|
||
Формальным решением задачи будем называть осуществление решения задачи с помощью формальной модели.
|
||
|
||
Онтологии
|
||
Онтологией называются представленные на некотором формальном знаний о некоторой области интересов (среде, мире).
|
||
Онтологии хранятся в базах знаний. Онтологии непременно сопутствует некоторая концепция этой области интересов.
|
||
Чаще всего эта концепция выражается посредством определения базовых объектов (индивидуумов, атрибутов, процессов) и отношений между ними.
|
||
Определение этих объектов и отношений между ними обычно называется концептуализацией.
|
||
Концептуализация может быть явной или ментальной, т.е. существующей только в чьей-то голове. Однако мы будем полагать, что онтология является явным представлением некоторой концептуализации. Онтология может иметь несколько уровней представления знаний.
|
||
|
||
Уровни онтологий
|
||
неформальная на каком-либо естественном языке,
|
||
полуформальная на каком-либо структурированном подмножестве естественного языка,
|
||
слабоформализованная на каком-либо языке из области искусственного интеллекта с формальным синтаксисом,
|
||
формализованная на каком-либо языке из области искусственного интеллекта с формальным синтаксисом, семантикой, значимым и полным механизмом вывода.
|
||
Следующее определение онтологии, суммирует различные определения онтологий:
|
||
Онтологией является общепринятая и общедоступная концептуализация определенной области знаний (мира, среды), содержащая базис для моделирования этой области знаний, определяющая протоколы для взаимодействия между модулями системы искусственного интеллекта, использующими знания из этой области, и наконец, включающая соглашения о представлении теоретических основ данной области знаний.
|
||
|
||
Этапы формирования Онтологии
|
||
Определение цели и постановка задачи. На этом этапе особенно важно понять зачем нужна онтология, как и кем она будет использоваться.
|
||
Построение. Этот этап разбивается на три подэтапа: формализация понятий, кодирование и интеграция.
|
||
Процесс формализации понятий: 1) выявление основных объектов и отношений предметной области, 2) текстовое описание этих объектов и отношений, 3) сопоставление этим объектам и отношениям термов.
|
||
Процесс кодирования в каком-либо формальном языке результатов предыдущего подэтапа. Обычно кодирование включает 1) описание с использованием введенных термов необходимых утверждений, 2) выбор формального языка для кодирования, 3) кодирование в выбранном языке.
|
||
Процесс интеграции выполняется параллельно двум упомянутым и требует тщательного обдумывания, каким образом вновь создаваемая онтология будет интегрироваться с уже существующими.
|
||
Оценка. На этом этапе осуществляется обдумывание и формирование вопросов, на которые онтология должна давать ответы, выбирается программная среда для реализации онтологии.
|
||
Документирование. На этом этапе осуществляется тщательное составление руководства к онтологии на естественном языке.
|
||
|
||
\section{Методологии разработки мультиагентных систем}
|
||
методологии рмас сравнительно новая область
|
||
терминология не всегда однозначна, первоисточник в английском
|
||
поведение формируется описанием не действий, но целями
|
||
достижение связано с рассуждениями и планированием
|
||
|
||
интеллектуальное поведение
|
||
каждый агент способен на своё собственное ип, вместе достигая цели.
|
||
разработчику не нужно описывать поведение
|
||
|
||
инструментальные средства развиваются с конца 20в.
|
||
|
||
\begin{itemize}
|
||
\item Методология Gaia
|
||
Гайя это некая энергетическая всеобъемлющая сущность. система имеет микро и макро уровни, но минус в том, что она не развивалась. два этапа - выделение роли и налаживание взаимодействия
|
||
|
||
роли - обязательства(не прямое указание, но формулировка возможностей) разрешения активности протоколы.
|
||
м не подходила для систем в открытой среде, известны улучшения, позволяющие системе работать в интернете
|
||
|
||
\item Методология MaSE
|
||
формирование целей
|
||
разработка сценариев
|
||
|
||
\item Методология UML
|
||
используется для моделирования базового уровня агентных систем
|
||
Диаграммы архитектуры, ролей и протоколов, онтологий.
|
||
сложностью считается сложность точного описания модели на языке.
|
||
|
||
\item Методология, основанная на графовых представлениях
|
||
компоненты, сообщения. каналы связи. недостатком является чрезмерная вычислительная затрата на обработку графа.
|
||
\end{itemize}
|
||
|
||
\subsection{Тенденции}
|
||
\begin{enumerate}
|
||
\item концептуализация
|
||
\item структуризация
|
||
\item бихевиоризация
|
||
\item формализация
|
||
\item реализация
|
||
\end{enumerate}
|
||
|
||
Концептуализация - постановка задачи, получение информации о среде. составление словаря терминов где сущностей должно быть столько же или больше, чем категорий в системе, не должно быть неоднозначностей. источником информации являются заказчики системы, эксперт или эксперимент со средой. итог шага - текстовый документ на естественном языке.
|
||
|
||
Структуризация - определение ролей и моделируются компоненты системы
|
||
|
||
бихевиоризация - определение активности ролей, создаются взаимодействия объектов, диаграммы поведений и состояний.
|
||
|
||
на этапах формализации и реализации - создаются или принимается решение об использовании исчислений, переход к программированию.
|
||
|
||
\section{Онтологизация}
|
||
Онтология - часто общепринятое и общедоступное, однозначно понимаемое описание знаний на естественном или частично формализованном языке. Создаются для уменьшения путаницы и неоднозначности. Используют декларативные языки, например OWL. Большинство логик для описания декларативных знаний могут быть переведены в логику предикатов первого порядка. В каждом случае разрабатывают свой метод рассуждений. Помимо самого языка нас всегда интересуют исчисления (язык, знания, правила рассуждения). Для описания используются Т-бокс и А-бокс. Термины, ограничения. Высказывания, утверждения.
|
||
|
||
Используются все механизмы логики - концептуальная конъюнкция, отрицание (множество всех объектов, которые не удовлетворяют требованиям) и другие.
|
||
|
||
\subsection{Доказательства}
|
||
помимо обычных логик (модус поненс, дедукция, абдукция, итд) есть метод табло, в котором в процессе описываются секвенты, объединяющиеся в табло. Годится для доказательства в любых декларативных системах.
|
||
|
||
\section{Извлечение знаний в языке нитей}
|
||
интеллектуальное поведение может быть представлено без явного использования символического представления, предлагаемого ИИ.
|
||
ИП может быть реализовано без явного абстрактного вывода (рассуждения) того типа, которое предлагает символическое представление ИИ.
|
||
|
||
КА - это множеств входов, множество выходов, множество состояний и функции перехода и выхода.
|
||
|
||
ИП - это процесс непрерывного анализа (восприятия) и отображения его в реакцию (выходное действие). Пара вход(анализ) реакция(выход) то есть кортеж действий называются нитями. выполнение нити - это порядок действий. Агент определяется множеством нитей. Процесс выполнения агентом нити - это поведение.
|
||
|
||
Множество пар входных и выходных действий должно удовлетворять:
|
||
\begin{itemize}
|
||
\item для любой нити из множества S начало такой нити также должно принадлежать множеству S.
|
||
\item если нити одинаковые, то реакции на них также должны быть одинаковые
|
||
\item нити находятся в отношении R, если нити удовлетворяют первым двум пунктам.
|
||
\end{itemize}
|
||
|
||
Процессные выражения нитей возможно представить в виде графа переходов (автоматы Мура). Отношение R разбивает множество нитей на классы эквивалентности.
|
||
|
||
Любые две нити восприятия находятся в отношении R если реакции на эти нити одинаковы и обе они принадлежат множеству S.
|
||
|
||
\section{Извлечение знаний в языке процессных графов переходов}
|
||
Стратегии поиска (на графах возможно осуществлять поиск). Оценить стратегию возможно по некоторым критериям (время, сложность, итд.)
|
||
|
||
Слепой и направленный поиск. Самый простой - это слепой поиск в ширину. Возможен также монотонный поиск в ширину.
|
||
|
||
Поиск в глубину, итеративный поиск в глубину. У поисков в глубину нет полноты.
|
||
|
||
Все стратегии слепого поиска экспоненциальны по сложности, поэтому нужно вводить критерий выбора
|
||
|
||
двунаправленный поиск.
|
||
|
||
|
||
\newpage
|
||
\appendix
|
||
\setcounter{secnumdepth}{2}
|
||
\setcounter{tocdepth}{2}
|
||
\section*{Приложения}
|
||
\addcontentsline{toc}{section}{Приложения}
|
||
\renewcommand{\thesubsection}{\Asbuk{subsection}}
|
||
\subsection{Семинар 1 (2022-09-06)}
|
||
что-то тут точно было
|
||
|
||
\subsection{Литература}
|
||
Батоврин В. К. Толковый словарь по системной и программной инженерии. — М.:ДМК Пресс.— 2012 г. — 280 с. ISBN 978 -5-94074 94074-818 -2
|
||
Лоусон , Гарольд «Бад». Путешествие по системному ландшафту / Пер. с англ. В. Батоврин . — М.: ДМК Пресс — 2013. ISBN 978-5-94074-923-3
|
||
Косяков А., Свит У., Сеймур С., Бимер С. Системная инженерия. Принципы и практика / Пер. с англ. В. Батоврин. — М.: ДМК Пресс, 2014. — 636 с.
|
||
Шамие Кетлин. Системная инженерия для «чайников»: ограниченная серия от IBM. — John Wiley \& Sons, Inc., 2014. — 69 с. (NB! Скачивается официально)
|
||
|
||
На английском
|
||
- INCOSE (International Council on Systems Engineering) http://www.incose.org
|
||
- The Guide to the Systems Engineering Body of Knowledge (SEBoK) http://www.sebokwiki.org
|
||
На русском языке
|
||
- Systems Engineering Thinking Wiki http://sewiki.ru
|
||
- Российское отделение INCOSE http://incose-ru.liveiournal.com
|
||
- А. И. Левенчук , президент/директор по исследованиям Российского отделения INCosE http://ailev.liveiournal.com
|
||
- А. И. Левенчук . Системноинженерное мышление http://techinvestlab.ru/files/systems engineering thinking/thin king 2015.pdf
|
||
- В. Мизгулин. Системная инженерия требований http://urse.ru/wp-content/uploads/2017/02/Системная-инженерия-требований.pdf
|
||
|
||
\subsection{Альфа}
|
||
abstract level progress health attribute
|
||
всего Альф 8.
|
||
\begin{frm}
|
||
Альфа - это некоторый элемент, который требуется для отслеживания успешности системы.\end{frm}
|
||
Альф помогает отслеживать
|
||
|
||
\begin{itemize}
|
||
\item альфа стейкхолдеров - это некоторые роли в нашем проекте. лица, чьи действия могут влиять на успешность системы. именно с ними нужно согласовывать требования к системе.
|
||
\begin{itemize}
|
||
\item внешние - заказчик или пользователи
|
||
\item внутренние - разработчики системы
|
||
\end{itemize}
|
||
для анализа стейкхолдеров понадобится их определить, то есть явно в проект не будет входить бухгалетрия и юридический отдел. Будет по большей части влиять на успешность проекта в целом. Выделение механизмов вовлечения стейкхолдеров в проект (4 стратегии - полноценное партнёрство, временная консультация, поддержка, временные работники.) анкета и луковая диаграмма
|
||
\item возможностей зависит от временн\'{о}го интервала и показывает всё, что возможно сделать с системой.
|
||
\item определения системы - воплощение системы, архитектурное и неархитектурное описание, требоваиня ТЗ. финансовая группа может формировать баланс и отчётность
|
||
\item воплощения системы - 4д модели всей системы, изготовление отдельных частей, сборка, верификация и валидация
|
||
\item альфа команды - сотрудничество между людьми с определёнными компетенциями.
|
||
\item альфа работы - системы отслеживания задач
|
||
\item альфа технологий - практика на рабочих продуктах, раскладывается как в жизненных циклах.
|
||
\end{itemize}
|
||
все альфы можно описать на схеме OMG Essence.
|
||
\end{document}
|
||
|