Исследование некоторой реальной системы состоит из двух этапов: этапа анализа и этапа синтеза.
Системным анализом называется исследование реальных объектов и явлений с точки зрения системного подхода, состоящее из этапов анализа и синтеза.
Модель «черного ящика»
В простейшем случае бывает достаточно иметь представление о взаимодействии системы с внешней средой, не вдаваясь в подробности ее внутреннего устройства. Например, при использовании сложной бытовой техники вам совсем не обязательно знать ее устройство. Достаточно знать, как ею пользоваться, т. е. какие управляющие действия можно с ней производить (что на входе) и какие результаты вы будете при этом получать (что на выходе). Все эти сведения содержатся в инструкции для пользователя.. Такое описание системы называется моделью «черного ящика» (рис. 1.2).
Модель состава
Как отмечалось выше, результатом анализа системы является определение ее состава. Если описание системы ограничить перечислением ее частей, то мы получим модель состава. Например, модель состава системы «Университет» представлена на рис. 1.3.
Каждая из отмеченных на рис. 1.3 составляющих системы «Университет» является подсистемой со своим составом. Поэтому для этих подсистем также можно построить свои модели состава. Разумеется, такой модели недостаточно для того, чтобы понять, как функционирует университет. И все-таки она дает более подробное представление об университете, чем модель «черного ящика».
Структурная модель системы
Структурную модель системы еще называют структурной схемой. На структурной схеме отражается состав системы и ее внутренние связи. Для отображения структурной схемы системы используются графы.
Еще один пример графа показан на рис. 1.5. Это структурная модель молекулы углеводорода. Вершинами являются атомы водорода и углерода, ребра отображают валентные связи.
Связь между двумя станциями метро, соединенными линией движения, является двунаправленной, поскольку поезда могут двигаться в обе стороны. Валентная связь между атомами молекулы также не имеет выделенного направления. Такие графы называются неориентированными. Если же связь между двумя элементами системы действует только в одну сторону, то на графе она отображается направленной стрелкой. Такой граф называется ориентированным. Направленные линии связи на графе называются дугами.
На практике часто встречаются системы с иерархической структурой, граф которых называется деревом (рис. 1. 7).
Система основных понятий
Вопросы и задания
1. Какие существуют типы моделей систем? Чем они различаются?
2. Что такое граф? Из чего он состоит?
3. Какой граф называется неориентированным? Приведите примеры.
4. Какой граф называется ориентированным? Приведите примеры.
5. Нарисуйте в виде графа систему, состоящую из четырех одноклассников, между которыми существуют следующие связи (взаимоотношения): дружат — Саша и Маша, Саша и Даша, Маша и Гриша, Гриша и Саша. Анализируя полученный граф, ответьте на вопрос: с кем Саша может поделиться секретом, не рискуя, что тот станет известен кому-то другому?
6. Нарисуйте два варианта графа системы «Компьютер», содержащего следующие вершины: процессор, оперативная память, внешняя память, клавиатура, монитор, принтер:
а) линия связи обозначает отношение «передает информацию»;
б) линия связи обозначает отношение: «управляет».
Презентация. Модели систем. Системный анализ смотреть
ГДЗ по информатике 11 класс учебник Семакин параграф 2
1) Какие существуют типы моделей систем? Чем они различаются?
Информационные модели отражают различные типы систем объектов, в которых реализуются различные структуры взаимодействия и взаимосвязи между элементами системы. Для отражения систем с различными структурами используются различные типы информационных моделей: табличные, иерархические и сетевые.
2. Что такое граф? Из чего он состоит?
3. Какой граф называется неориентированным? Приведите примеры.
Неориентированный граф — это упорядоченная пара (V,E), для которой выполнены условия:
V-это множество вершин
E- это множество неупорядоченных пар различных вершин, называемых рёбрами.
4. Какой граф называется ориентированным? Приведите примеры.
Ориентированный граф — это упорядоченная пара (V,A), для которой выполнены условия:
V это множество вершин или узлов,
A это множество упорядоченных пар различных вершин, называемых дугами или ориентированными рёбрами.
Саша может поделиться с секретом только с Дашей.
6. Нарисуйте два варианта графа системы «Компьютер», содержащего следующие вершины: процессор, оперативная память, внешняя память, клавиатура, монитор, принтер:
а) линия связи обозначает отношение «передает информацию»;
б) линия связи обозначает отношение: «управляет ».
Приступим к изучению моделирования систем. Под словом «система» мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними. Мир, в котором мы живем, можно рассматривать как сложную взаимосвязанную совокупность естественных и искусственных систем. Это могут быть достаточно сложные системы (например, планеты в составе Солнечной системы), системы средней сложности (космический корабль) или сверхсложные системы (системы молекулярных взаимодействий в живых организмах). Существует огромное количество научных дисциплин, предназначенных для изучения и объяснения различных аспектов этого бесконечного спектра сложности. Например, механика может объяснить гравитационное притяжение двух планет, а химия может описать молекулярные взаимодействия в стакане кипятка. Искусственные системы по своей сложности, как правило, занимают среднее положение. Например, всемирная телефонная сеть содержит десятки или даже сотни тысяч переключателей, однако количество взаимодействий этих переключателей не идет ни в какое сравнение с количеством взаимодействий молекул даже в небольшом стакане воды. С точки зрения общей теории систем такие системы обычно рассматриваются как системы средней сложности.
Под термином «моделирование» мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями, и в то же время недостаточно велики для применения общих упрощающих предположений (как это принято в физике). Наша неспособность дать простое описание, а следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой.
Эта книга посвящена тому, как строить функциональные модели. Построение с помощью SADT моделей данных, а также множества моделей выходит за рамки этой книги.
В частях I-IV книги обсуждаются те концепции, методы и процессы SADT, которые относятся к построению функциональных моделей. В качестве иллюстрации к описанию технических аспектов приведены примеры построения реальных функциональных моделей. Рассматривается система из области аэрокосмической промышленности, которая представляет собой механический цех, производящий детали для экспериментальных самолетов (его обычно называют экспериментальный механический цех). SADT-модель, которую мы построим и которая будет описывать работу цеха, предназначена для создания учебного руководства для нового персонала цеха. Приложение А содержит полную постановку задачи и краткий обзор работ, выполняемых цехом.
SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Определяя модель таким образом, SADT закладывает основы практического моделирования.
Смысл и трактовка этого определения оказали существенное влияние на практические применения SADT. Обычно вопросы для SADT- модели формулируются на самом раннем этапе проектирования, при этом основная суть этих вопросов должна быть выражена в одной-двух фразах. На рис. 1-1 показана работа автора модели, использующего SADT для определения цели модели экспериментального механического цеха (ЭМЦ). Обратите внимание на то, что, познакомившись с постановкой задачи и кратким описанием процесса, автор составил список вопросов и свел этот список в одно предложение. Это предложение становится целью модели, а список вопросов сохраняется как детализация этого предложения. После завершения работы над моделью информация, содержащаяся в модели, будет отвечать на поставленные вопросы.
Какая степень точности приемлема для модели экспериментального механического цеха? Поскольку модель будет использована для подготовки учебного руководства, разумная степень точности будет достигнута, если каждая описанная в модели функция экспериментального цеха будет изложена в одном абзаце текста. Такая точность достижима и измерима. Другие методы анализа систем (альтернативные пути описания системы) не учитывают этот критический момент определения основной цели модели. Только поняв, насколько хорошо нужно ответить на поставленные вопросы, можно определить,
Рис 1-1. Определение цели и точки зрения модели ЭМЦ
когда процесс моделирования можно считать завершенным (т.е. когда модель будет соответствовать поставленной цели).
Модель является некоторым толкованием системы. Поэтому субъектом моделирования служит сама система. Однако моделируемая система никогда не существует изолированно: она всегда связана с окружающей средой. Причем зачастую трудно сказать, где кончается система и начинается среда. По этой причине в методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект, т.е. модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов. Вот почему мы утверждаем, что SADT-модель должна иметь единственный субъект.
С определением модели тесно связана позиция, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. На рис. 1-1 показано, как автор модели экспериментального механического цеха перечисляет претендентов (механик, контролер), с точки зрения которых можно было бы описывать механический цех.
«Точку зрения» лучше всего представлять себе как место (позицию) человека или объекта, в которое надо встать, чтобы увидеть систему в действии. С этой фиксированной точки зрения можно создать согласованное описание системы так, чтобы модель не дрейфовала вокруг да около, и в ней не смешивались бы несвязанные описания. Например, если в модели экспериментального механического цеха не зафиксировать определенную точку зрения, то легко можно смешать проблему обслуживания станков цеха с тем, как будет обработана деталь. Если это произойдет, то читатель модели столкнется с трудностями при определении конкретных обязанностей персонала.
Иногда только одна из множества возможных точек зрения может дать описание, удовлетворяющее цели модели. Например, для создания согласованной модели механического цеха можно встать на точку зрения как мастера, так и механика или контролера, но ни одна из них сама по себе не даст модели, которая позволила бы написать учебное руководство для всего персонала. Только с позиции начальника цеха можно увидеть все виды работ, выполняемых в цехе. Именно с его точки зрения, как указано в замечании на рис. 1-1, можно проследить взаимосвязи обязанностей различных работников. Точка зрения начальника цеха позволяет создателю модели определить роль каждого работника в изготовлении отдельных деталей и описать координацию обязанностей персонала.
1.5. Модели как взаимосвязанные наборы диаграмм
После того как определены субъект, цель и точка зрения модели, начинается первая интеграция процесса моделирования по методологии SADT. Субъект определяет, что включить в модель, а что исключить из нее. Точка зрения диктует автору модели выбор нужной информации о субъекте и форму ее подачи. Цель становится критерием окончания моделирования. Конечным результатом этого процесса является набор тщательно взаимоувязанных описаний, начиная с описания самого верхнего уровня всей системы и кончая подробным описанием деталей или операций системы.
Каждое из таких тщательно взаимосогласованных описаний называется диаграммой. SADT- модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы наверху модели менее детализированы, чем диаграммы нижних уровней. Другими словами, модель SADT можно представить в виде древовидной структуры диаграмм, где верхняя диаграмма является наиболее общей, а самые нижние наиболее детализированы. На рис. 1-2 представлены две диаграммы из модели экспериментального механического цеха. Верхняя диаграмма (на вершине модели) описывает механический цех как функцию, в основе которой лежит преобразование входящих рабочих комплектов (заготовок, сырья, документации) в детали при определенном контроле качества. Нижняя диаграмма детализирует верхнюю, указывая на три главные функции механического цеха: управление выполнением заданий, выполнение задания и контроль качества выполнения. Таким образом, общая функция, указанная на верхней диаграмме, детализируется с помощью трех функций на нижней диаграмме. Это пример того, как SADT организует описание системы, создавая иерархию добавляющихся на каждом уровне деталей.
На рис. 1-2 показано также взаимное влияние трех функций нижней диаграммы, обозначенное дугами, которые символизируют объекты механического цеха. Если вы внимательно посмотрите на диаграмму, то заметите, что некоторые дуги доходят до ее границы. Посмотрите еще внимательнее и вы увидите, что имена этих дуг совпадают с теми, что указаны на дугах верхней диаграммы. Это пример того, как SADT соединяет диаграммы в модели через объекты системы. Такая схема соединения требует согласованного наименования и учета объектов системы с тем, чтобы две диаграммы можно было рассматривать как связанные между собой. Например, функциональный блок на верхней диаграмме имеет семь дуг, и каждая из них может быть найдена среди дуг, идущих к границе или от границы диаграммы на следующем уровне.
Рис 1-2 Две взаимосвязанных SADT- модели
Brackett, J., and C. McGowan: «Applying SADT to Large System Problems», SofTech Technical Paper TP059,January 1977.
Hori, S.: «Human-Directed Activity Cell Model», CAM-1 Long Range Planning Final Report, CAM-1, Inc., 1972.
Miller, J.: Living Systems, McGraw-Hill, New York, 1978.
Ross, D.: «PLEX1: Sameness and the Need for Rigor», SofTech Deliverable no. 9031-1.1, December 1975.
Ross, D.: «PLEX2: Sameness and Type», SofTech Deliverable no. 9031-2.0, December 1975.
Ross, D.: «Reflections on Requirements», IEEE Transactions on Software Engineering, vol. SE-3, no. 1,January 1977.
Ross, D.: «Doug Ross Talks about Structured Analysis», IEEE Computer, July 1985.
Ross, D. and K. Schoman: «Structured Analysis for Requirements Definitions», IEEE Transactions on Software Engineering, vol. SE-3, no. 1, January 1977.
SofTech, Inc.: «Introduction to IDEFO», SofTech Deliverable no. 7500-14, September 1979.
Weinberg, G.: An Introduction to General Systems Thinking, John Wiley, New York, 1975.
Правильно заданный вопрос быстро приводит к правильному ответу. Недавно меня спросили: «Почему стандарты бизнес-анализа сконцентрированы на выявлении требований, но ничего не говорят о превращении этих требований в решение?» В самом начале своей карьеры аналитика я искал ответ на вопрос: как анализировать предметную область и как превращать результат анализа в структуру модели: откуда брать классы, атрибуты и методы? Тогда я нашел один более-менее вразумительный метод, описанный в книге Крега Лармана Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. Аналитику предлагалось прохождение по тексту с маркерами разных цветов: Красный выделяет существительные и является основанием для создания классов, зеленый — прилагательные, причастия и проч. — основа для создания атрибутов этих классов. И глаголы выделяются синим — основа для создания методов.
Однако, в реальности этот метод не работал. Один и тот же факт я мог смоделировать при помощи класса, значения атрибута или метода в зависимости от своего желания. Об этом написано подробно у Крисса Партриджа в книге Business Objects: Re-Engineering for Re-Use.
Он приводит пример с Колли. Это может быть класс объектов, это может быть значение атрибута «Порода» с типом значения либо строковое, либо – ссылка на объект справочника «Породы», либо – значение «да» булевского атрибута «Колли».
В примере Крисса Партриджа мы выбираем между классом и атрибутом. Но есть альтернатива, при которой можно смоделировать один и тот же факт при помощи класса или метода.
Например, можно вообразить себе ситуацию, что позолоту можно смоделировать при помощи класса объектов, при помощи значения атрибута, а, возможно, и метода. Выбор способа моделирования зависит от контекста и границ информационной модели. Однако, рано или поздно наступает тот момент, когда границы информационной системы вырастают до объема, когда один и тот же факт с одной точки зрения нужно моделировать при помощи. класса, с другой – при помощи функции, операции или значения атрибута. И тогда настоящим вызовом для аналитика становится маппинг между этими разными точками зрения.
Обо всем этом я писал ранее. Но есть еще один важный вопрос, который мы должны себе задать прежде, чем начнем моделирование. Надо выяснить, какого типа модель мы собираемся строить. Недавно я услышал тезис: модель модели – тоже модель (было упомянуто свойство транзитивности моделей). Например, если у вас есть документ «Договор», который есть модель договоренности, то вордовский файл, моделирующий этот договор – тоже модель договоренности. Фокус в том, что этот тезис верен только для одного типа моделей – для моделей объектов. Для другого типа моделей – концептуальных моделей, — этот тезис неверен. Мало, кто делает различие между ними. Поэтому я решил немного отойти от главной линии изложения и рассказать про типы моделей, с которыми работают аналитики.
Классификация моделей
Начнем с того, что обычно мы называем моделью. Под моделью мы понимаем информационный объект. Допустим, что субъект решил передать другому субъекту свое представление о каком-то объекте реального мира. Для этого он при помощи нотации (языка) делает описание своего представления этого объекта в виде информационного объекта. Этот информационный объект попадает в руки другого субъекта и он, зная нотацию, воссоздает у себя в сознании представление первого субъекта. Так происходит передача знаний от одного субъекта другому, и поэтому язык играет столь существенную роль в обучении.
Строго говоря, модель – это то, что есть в сознании у субъекта, а информационный объект – это модель этой модели. Но, благодаря транзитивности моделей, считается, что информационный объект – тоже модель. Этот информационный объект может постоянно уточняться и правиться по мере необходимости, что и происходит, когда один субъект что-то объясняет другому.
Допустим, что субъект в разных задачах сталкивается с похожими объектами. Например, с похожими деталями. Тогда для разных деталей у него могут получаться похожие модели. В какой-то момент в нем включается аналитик, и этот аналитик требует унификации моделей. Унификация нужна для того, чтобы один раз поработав, сэкономить время на моделировании.
Унификация заключается в том, что для всех похожих деталей аналитик создает одну модель. Это – концепт детали. Его отличие от модели детали в том, что модель детали можно уточнять бесконечно, а вот концепт уточнять бесконечно не получится, потому что он относится не к одному, а к множеству деталей. Детали отличаются друг от друга и потому нет возможности уточнять концепт бесконечно.
Можно ли по концепту восстановить модель объекта? Можно, но при помощи домысливания. Мы легко домысливаем концепт до модели объекта. Однако, легкость, с которой мы это делаем, не означает, что модель концепта – это модель объекта. Для восстановления модели объекта на основе его концепта нужен контекст, который дополнит модель концепта до модели объекта.
Теперь усложним задачу и предположим, что субъект моделирует конструкцию. Напомню, что конструкция – это множество объектов и связей между ними. Очевидно, что модель конструкции, как и модель объекта, можно уточнять бесконечно.
Теперь допустим, что, как и в случае с деталями, у субъекта стоит задача моделирования похожих конструкций, например, конструкций тепловозов. Поступая, так же, как и в первом случае, субъект может унифицировать модели и создать одну для множества конструкций — концепт конструкции.
Концепт конструкции состоит из множества концептов – концептов объектов – элементов конструкции и концептов связей между этими элементами. Для концепта конструкции тепловоза будет верным следующее утверждение: для каждого элемента в концепте конструкции существует один и только один элемент в реальном тепловозе. Иначе можно это переформулировать так: «арность» связей в модели концепта конструкции тепловоза всегда «один-к-одному».
Но в общем случае это неверно. Часто можно встретить концептуальные модели, в которых «арность» связей отличается от «один-к-одному».
Концепт конструкции еще называют концептуальной моделью. Правда, в распространенном определении концептуальной модели есть одна очень серьезная ошибка. Обычно говорится, что концептуальная модель – это модель концептов и связей между ними. Это неверно, потому что в концептуальной модели присутствуют не связи и даже не модели связей, а концепты связей. Чтобы как-то замаскировать эту ошибку, говорят, что связи в концептуальной модели имеют арность – например, «один к трем». Обо всем этом я писал ранее и об этом можно прочитать в моей статье Моделирование объектов учета в разделе «стрелки».
Чтобы лучше представить себе такого рода модели, можно посмотреть на любую ER модель. На них мы видим концепты объектов и концепты связей. Можно ли на основе ER модели восстановить модель концепта конструкции? Увы, нельзя. А, следовательно, нельзя восстановить и модель конструкции.
Итак, подводя итог, можно сказать, что существуют два вида моделей – модели объектов и модели концептов. Для моделей объектов верен принцип транзитивности, но для моделей концептов этот принцип не работает.
Примеры
Допустим, что существует договоренность между двумя контрагентами. Эта договоренность имеет модель – письменный договор. Существует несколько таких документов, каждый из которых – модель этой договоренности. Пусть существует вордовский файл с моделью письменных документов. Это удобно – вносить изменения в одном месте, чтобы потом иметь возможность распечатать столько копий, сколько необходимо. Получается, что этот вордовский файл – тоже модель договоренности. Пусть есть множество договоренностей, для каждой из которых приходится создавать письменный документ. Сделаем унификацию, и для всех этих документов создадим одну модель – типовой договор. Типовой договор удобен тем, что позволяет быстро создать модель конкретной договоренности. Но он не является моделью конкретной договоренности. Поэтому вордовский файл с типовым договором не является моделью конкретной договоренности. И транзитивности моделей тут нет.
Вопрос: какого типа модель создается при помощи нотации BPMN? Я не буду отвечать на это вопрос, надеясь, что вы сами способны ответить на него.
Вопрос: какого типа модель создается при помощи нотации IDEF0? Также надеюсь, что вы сами ответите на это вопрос.
