Диссертация. Диссертация Беляшов А.Н. Факультет итс
 Скачать 1.84 Mb.
|
|
Метод IDEF3 (Process Description Capture - документирование технологических процессов) (рис. 2.6) предназначен для описания бизнес-процессов нижнего уровня и содержит объекты – логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты – стрелки, с помощью которых показывают временную последовательность работ в бизнес-процессе [43]. В отличие от классического метода WFD в IDEF3 связи между работами делятся на три типа, обозначения, названия и смысл которых, приведены в таблице 2.3. Помимо наличия нескольких типов связей между работами в стандарте IDEF3 логические операторы, которые в данном случае называются перекрестками, также делятся на несколько типов: "Исключающий ИЛИ", "И" и "ИЛИ" (рис. 2.7).  Рис. 2.6. Модель IDEF3 Таблица 2.3. Типы связей между работами в стандарте IDEF3
 Рис. 2.7. Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы расхождения В таблице 2.4 приведены обозначения, названия и смысл всех типов перекрестков как в схемах схождения, так и в схемах расхождения. Таблица 2.4. Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения
Метод STD (State Transition Diagram - диаграмма переходов состояний) (рис. 2.8). Моделирует поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчётного периода) [43]. Такие диаграммы позволяют осуществлять декомпозицию управляющих процессов, происходящих в системе, и описать отношения между управляющими потоками.  Рис. 2.8. Модель STD С помощью STD можно моделировать последующее функционирование системы исходя из предыдущих состояний. Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течении времени она может изменять своё состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в новое состояние необходимо условие перехода. Оно может быть информационным (условие появления информации) или временным. Определим основные объекты STD. Состояние – рассматривается как устойчивое значение некоторого свойства в течении определённого момента времени. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в последующее состояние. Начальное состояние – это узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет только одно начальное состояние, но может иметь множество конечных. Переход – определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода – это событие, которое вызвало этот переход. Переход может быть вызван каким-либо действием (нажатием клавиши) Триггер – логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние. Условие перехода – событие, вызывающее переход и определяемое именем перехода. текущее состояние системы определяется ожиданием выбора того или иного пункта меню. выбранный пункт меню – это информационное событие, а сам выбор – действие перехода в следующее состояние системы. Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных на DFD), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий. Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события привязываются к переходам и забываются под соответствующим условием. Метод ERD (Entity-Relationship diagram – диаграмма «Сущность-связь») (рис. 2.9). ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных [7]. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.). ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. Основные понятия диаграмм «Сущность-связь». Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Экземпляр сущности – это конкретный представитель данной сущности. Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности. Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Ключ сущности – это набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Сущность может иметь несколько различных ключей. Связь – это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Каждая связь имеет два конца и одно или два наименования.  Рис. 2.9. Модель ER Метод IDEF1X (Data Modeling – метод моделирования баз данных) (рис. 2.10) используется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы [43]. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа, тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.  Рис. 2.10. Модель IDEF1X Модель ESM (Enterprise Structure Model – Модель метаструктуры предприятия) (рис. 2.11) применяется для описания географически распределенной организационной структуры предприятия, описывает географические подразделения компании (офисы, филиалы, пр.), а также материальные и информационные потоки между ними [46]. Данная бизнес-модель по своей сути напоминает классический DFD-стандарт, в котором на разрабатываемой схеме вместо работ, показываются структурные подразделения и взаимодействия между ними. Модель BCM (Business Control Model – модель управления) (рис. 2.12) – декомпозиция структурных подразделений компании, изображенных на модели метаструктуры предприятия, на которой показываются бизнес-процессы данного структурного подразделения, а также материальные и информационные потоки протекающие между ними [46]. Модель управления BCМ полностью соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов верхнего уровня.  Рис. 2.11. Модель метаструктуры предприятия – ESM Модель BPM (Business Process Model – процессная модель) (рис. 2.13) – модель, которая применяется для описания бизнес-процессов нижнего уровня и практически соответствуют классической WFD-схеме, за исключением двух особенностей [46]. Первая – блоки принятия решений на модели бизнес-процессов BPM называются управляющими работами и вторая особенность связана с наличием на модели элементов, называемых состоянием, с помощью которых описываются состояния, характеризующие начало и окончания каждой работы. Данный подход, связанный с описанием состояний заимствован из подхода к описанию бизнес-процессов, который называется "Сети Петри".  Рис. 2.12. Модель управления – BCM Модель BFM (Business Function Model – функциональная модель) (рис. 2.14) – модель, используемая при описании деятельности компании. С помощью этой модели строится дерево функций компании [46]. Модель ERM (Entity-Relationship Model – информационная модель) (рис. 2.15) имеет тип "Сущность-Связь" и предназначена для описания структуры информации, используемой при реализации бизнес-процессов [46]. С помощью данной модели проектируется базы данных. Модель BOM (Business Organization Model – организационная модель) (рис. 2.16) используется для описания подразделений и должностей организации, а также связей линейного и функционального подчинения [46]. На данной модели также показываются роли, которые играет должность в тех или иных бизнес-процессах. Например, сотрудник, занимающий должность менеджер отдела маркетинга, может играть роль менеджера проекта в проекте по выводу нового проекта на рынок, при этом данный сотрудник может играть и другие роли в других проектах.  Рис. 2.13. Модель бизнес-процессов – BPM  Рис. 2.14. Модель функций – BFM  Рис. 2.15. Информационная модель ERM  Рис. 2.16. Модель организационной структуры – BOM Модель OD (Objective diagram – диаграмма целей) (рис. 2.17) применяется для описания стратегических целей компании, их иерархической упорядоченности, а также связей целей с продуктами и услугами, производимыми компанией, и бизнес-процессами, поддерживающими их производство [46]. Модель PST (Product/Service tree – дерево продуктов и услуг) (рис. 2.18) применяется для описания продуктов и услуг, производимых в компании, а также их связи со стратегическими целями компании и бизнес-процессами, поддерживающими их производство [46]. Модель FT (Function tree – дерево функций) (рис. 2.19) описывает функции, выполняемые в компании и их иерархию [46]. Данная модель часто применяется для построения дерева бизнес-процессов компании. Модель FAD (Function allocation diagram – диаграмма окружения процесса) (рис. 2.20) позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов [46].  Рис. 2.17. Модель "Диаграмма целей" – OD  Рис. 2.18. Модель "Дерево продуктов и услуг" – PST Модель VACD (Value added chain diagram – диаграмма цепочки добавленной стоимости) (рис. 2.21) является аналогом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня [46]. Дополнительным отличием данной модели от других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VACD, в отличие от классического подхода, также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD.  Рис. 2.19. Модель "Дерево функций" – FT  Рис. 2.20. Модель "Диаграмма окружения процесса" – FAD Модель PSM (Process selection matrix – матрица выбора процесса) (рис. 2.22) является аналогом классического DFD-стандарта и используется как альтернатива для модели VACD [46]. Матрица выбора процессов по отношению к диаграмме цепочки добавленной стоимости с одной стороны является более упрощенным вариантом описания процесса, с другой стороны содержит дополнительные объекты, позволяющие показать другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов связана с тем, что на данной модели не показываются информационные и материальные потоки. Что касается других аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения бизнес-процесса, который описывается. Соответственно матрицу выбора процессов целесообразно применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет несколько вариантов исполнения, каждый из которых ложится базовую схему.  Рис. 2.21. Модель "Диаграмма цепочки добавленной стоимости" – VACD Модель eEPC (Extended event driven Process Chain – расширенная цепочка процессов, управляемая событиями) (рис. 2.23) является аналогом классического WFD-стандарта и используется для описания бизнес-процессов нижнего уровня [46]. Дополнительным отличием eEPC-модели от классической WFD-схемы является наличие на модели объекта, который называется событием. С помощью объектов событий изображается факт, время или событие инициирующие начало выполнения работ бизнес-процесса, а также факт или время их завершения.  Рис. 2.22. Модель "Матрица выбора процессов"– PSM  Рис. 2.23. Модель "Расширенная цепочка процессов, управляемая событиями"– eEPC Модель ORG (Organizational chart – модель организационной структуры) (рис. 2.24) используется для описания организационной структуры компании [46]. На данной модели изображаются структурные подразделения, группы, должности, роли и прочие элементы организационной структуры и связи между ними. Модель ASTD (Application system type diagram – диаграмма типов информационных систем) (рис. 2.25) используется для описания структуры информационных систем, используемых в компании [46]. На данной модели показываются типы и модули информационных систем, программные продукты, взаимосвязь между ними и бизнес-процессами организации, которые они автоматизируют.  Рис. 2.24. Модель "Организационная структура" – ORG  Рис. 2.25. Модель "Диаграмма типов информационных систем" – ASTD Диаграмма классов (рис. 2.36). Класс в языке служит для обозначения множества объектов, которые имеют одинаковую структуру, поведение и отношения с объектами из других классов [8].  Рис. 2.36. Диаграмма классов На диаграмме класс изображают в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на две или три секции (рис. 2.37). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы). Иногда в графическом изображении класса добавляется четвертая секция, содержащая описание исключительных ситуаций. Обязательным элементом обозначения класса является его имя. На начальных этапах разработки диаграммы класс может обозначаться простым прямоугольником с указанием только его имени (рис. 2.37, а). В дальнейшем диаграммы описания классов дополняются атрибутами (рис. 2.37, б) и операциями (рис. 2.37, в). Чтобы сразу отличить класс от других элементов, секцию атрибутов и операций выделяют горизонтальной линией, даже если она является пустой.  Рис. 2.37. Изображение класса на диаграмме классов Имя класса должно быть уникальным в пределах диаграммы или совокупности диаграмм классов пакета. Оно указывается в первой верхней секции прямоугольника, записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. В качестве имен классов рекомендуется использовать одно или несколько существительных без пробелов между ними. Кроме того, в секции обозначения класса могут находиться ссылки на стандартные шаблоны или абстрактные классы, от которых образован данный класс и, соответственно, от которых он наследует свойства и методы. Диаграмма объектов – подвид диаграммы классов [44]. Она показывает экземпляры классов (изображенных на диаграмме классов) и отношений между ними в некоторый момент времени, т.е. диаграмма объектов - это своего рода снимок состояния системы в определенный момент времени, показывающий множество объектов, их состояния и отношения между ними в данный момент. Диаграмма компонентов (рис. 2.38) описывает особенности физического представления системы [44]. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.  Рис. 2.38. Диаграмма компонентов Диаграмма компонентов разрабатывается для следующих целей: Визуализации общей структуры исходного кода программной системы. Спецификации исполнимого варианта программной системы. Обеспечения многократного использования отдельных фрагментов программного кода. Представления концептуальной и физической схем баз данных. В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие - на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов. Диаграмма автомата (рис. 2.39) — это один из способов детального описания поведения в UML [44]. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей. Диаграмма автомата описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы автомата. На диаграмме автомата применяют один основной тип сущностей – состояния, и один тип отношений – переходы, но и для тех, и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги - переходам. Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний. Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.  Рис. 2.39. Диаграмма автомата Диаграмма деятельности (рис. 2.40) – еще один способ описания поведения, который визуально напоминает блок-схему алгоритма [44]. Используется для моделирования процесса выполнения операций. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. На диаграмме деятельности применяют один основной тип сущностей — действие, и один тип отношений – переходы (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.  Рис. 2.40. Диаграмма деятельности Диаграмма вариантов использования (рис. 2.41) – это наиболее общее представление функционального назначения системы [44]. Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером. На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются основные типы отношений. Диаграмма последовательности – это способ описания поведения системы "на примерах" [44]. Фактически, диаграмма последовательности – это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название. На диаграмме последовательности применяют один основной тип сущностей — экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений — связи, по которым происходит обмен сообщениями.  Рис. 2.41. Диаграмма вариантов использования Диаграмма синхронизации (рис. 2.42) представляет собой особую форму диаграммы последовательности, на которой особое внимание уделяется изменению состояний различных экземпляров класса и их временной синхронизации [44].  Рис. 2.42. Диаграмма синхронизации 2.3. Классификация методов анализа и проектирования систем управления Основные существующие в настоящее время методологии моделирования, используемые на этапах анализа, разработки и внедрения систем управления представлены на рис. 2.43. Их можно разделить на две большие группы: структурные и объектно-ориентированные [11]. Структурные методологии базируются на декомпозиции (разбиении) объекта на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на функции, подразделяемые на задачи и так далее [1; 14]. При этом система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. Наиболее известными структурными методологиями являются: структурный анализ/структурное проектирование (SA/SD), комплексная автоматизация производственных процессов (IDEF), архитектура интегрированных информационных систем (ARIS), методологии фирм-разработчиков (ORACLE, BAAN и др.).  Рис. 2.43. Виды методологий Объектно-ориентированные методологии основаны на представлении системы в виде совокупности объектов, каждый из которых является реализацией определенного типа, использует механизмы пересылки сообщений и классы, организованные в иерархию наследования [4]. Наиболее известными объектными методологиями являются: объектно-ориентированный системный анализ (OSA), технология объектного моделирования (OMT), унифицированный язык моделирования (UML). Каждая из методологий включает в себя набор методов графического моделирования аспектов предметной области (видов моделей, диаграмм, нотаций), рассмотренных нами в предыдущем разделе. Проведем классификацию основных методов моделирования, используемых при анализе и проектировании систем управления (рис. 2.44).  Рис. 2.44. Классификация методов анализа и проектирования систем управления Функциональные модели (метод структурного анализа и проектирования SADT; функциональная модель IDEF0) – модели, ориентированные на функции, и представляющие собой структурированное изображение функций системы или среды, информации и объектов, связывающих эти функции [2]. Функциональная модель – это искусственный объект, представляющий собой виртуальный образ системы и ее компонентов, в виде функциональной структуры объекта (совокупности диаграмм), отображающих производимые им действия и связи между этими действиями. Функциональные модели применяют при анализе требований к системе, при проектировании новой системы, а также для анализа бизнес-процессов при принятии решений о реконструкции (реинжиниринге) системы управления. Модели потоков данных (диаграмма потоков данных DFD; диаграмма потоков управления CSD; модель потоков данных ORACLE; модель управления BCM) – модели графического структурного анализа, описывающие внешние по отношению к системе источники и приемники данных, процессы, потоки данных и хранилища данных, к которым осуществляется доступ [9]. Модель системы представляет иерархию диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) передают и/или принимают информационные потоки, переносящие информацию к/от системы; процессы отображают выполняемые системой функции; хранилища данных моделируют отдельные объекты (сущности, таблицы) базы данных; потоки данных описывают информационные взаимосвязи между процессами, а также операции чтения/записи информации отдельными процессами в таблицы базы данных. Модели потоков данных используются на этапе проектирования систем управления. Модели бизнес-процессов (диаграмма потоков работ WFD; диаграмма потоков работ IDEF3; диаграмма окружения процесса FAD; диаграмма цепочки добавленной стоимости VACD; матрица выбора процессов PSM; расширенная цепочка процессов, управляемая событиями eEPC; модель бизнес-процессов «SwimmerLanes»; модель бизнес-процессов BPM) – модели видов деятельности организации, включающие описание деловых объектов (процессов, бизнес-функций, потоков работ, подразделений, должностей, ресурсов, ролей, информационных систем, носителей информации и т. д.) и указание связей между ними. Модель показывает взаимосвязи между функциями и последовательность их выполнения, а также материальные и информационные потоки, имеющие место при функционировании организации. Отметим, что модели бизнес-процессов являются динамическими моделями, т.к. описывают последовательность (и иногда условия) выполнения бизнес-процессов, в отличие от остальных групп структурных моделей, описывающих исключительно статику системы. Модели бизнес-процессов используются при описании и реинжиниринге видов деятельности компании, на этапах анализа и определения требований к системе, а также при внедрении систем управления на предприятиях. Событийные модели (диаграмма переходов состояний STD; модель динамического моделирования развития систем IDEF2) – это модели, в которых функционирование системы представляется в виде набора состояний объектов и перечня событий (функций) системы. События происходят в определенные моменты времени и знаменуют собой изменение состояний отдельных объектов системы. Событийные модели используются на этапах анализа требований и проектирования поведения динамических объектов (элементов) системы. Информационные модели (диаграмма сущность-связь ERD; диаграмма структур данных DSD; информационная модель IDEF1X; ER-модель ORACLE; модель Чена; информационная модель ERM) – модели данных конкретной предметной области или ее объектов, они отображают структуру данных проектируемых систем. Информационная модель описывает сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Информационные модели разрабатывается на этапах проектирования и реинжиниринга систем управления. Иерархические модели (диаграмма архитектуры системы SAD; диаграмма целей OD; дерево продуктов и услуг PST; дерево функций FT; модель организационной структуры ORG; диаграмма типов информационных систем ASTD; модель иерархии функций ORACLE; модель метаструктуры предприятия ESM; модель функций BFM; организационная модель BOM) – модели представления системы в виде древовидной (иерархической) структуры, состоящей из объектов различных уровней. Иерархическая модель описывает отношения между главными (родительскими) и подчиненными (дочерними) объектами в системе. С помощью иерархических моделей для организаций и подразделений описывают организационные структуры, деревья целей, выполняемых функций, выпускаемых продуктов и оказываемых услуг и т.д. Иерархические модели используют в управленческом консалтинге при реинжириринге систем управления. Объектные статические модели (диаграмма классов; диаграмма компонентов; диаграмма композитной структуры; диаграмма развертывания; диаграмма объектов; диаграмма автомата; диаграмма зависимостей между объектами; диаграмма поведения объектов; диаграмма взаимодействия объектов; диаграмма инстанций) – модели, которые не отражают динамику системы, т.е. изменения, происходящие с течением времени [10]. Статические модели описывают основные концепции предметной области системы, а также внутренние концепции элементов системы, необходимые для ее реализации. Основными статическими моделями на этапах объектно-ориентированного анализа и проектирования систем служат диаграммы, представляющие классы, объекты или компоненты системы и их отношений между собой: ассоциации, обобщения и различные виды зависимостей. Объектные динамические модели (диаграмма деятельности; диаграмма вариантов использования; диаграмма последовательности; диаграмма синхронизации; диаграмма событий; диаграмма переходов состояний) – модели, описывающие изменение (динамику) функций (параметров, состояний объектов) системы. Объектные динамические модели используются на этапах объектно-ориентированного анализа и проектирования и отображают процесс изменения состояний реальной или проектируемой системы, показывают различия между состояниями объектов, последовательность смены состояний и последовательность выполнения функций системы в течение времени. 2.4. Анализ применимости методов анализа и проектирования систем управления на различных этапах жизненного цикла программных средств На основании анализа стандарта ГОСТ Р ИСО/МЭК 12207:2010 «Процессы жизненного цикла программных средств» выделены технические и специальные процессы жизненного цикла программных средств. Эти процессы являются основой для анализа и проектирования систем управления, потому что они используются для определения требований к системе, преобразования требований в полезный продукт, для разрешения постоянного копирования продукта (где это необходимо), применения продукта, обеспечения требуемых услуг, поддержания обеспечения этих услуг и изъятия продукта из обращения, если он не используется при оказании услуги, преобразуют заданные характеристики поведения, интерфейсы и ограничения на реализацию в действия, результатом которых становится системный элемент, удовлетворяющий требованиям, вытекающим из системных требований, поддерживают возможности организации использовать повторно составные части программных средств за границами проекта. Для анализа применимости методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств методы (модели) были сгруппированы согласно разработанной классификации на структурные (функциональные, потоков данных, бизнес-процессов, информационные, иерархические, событийные) и объектные (статические и динамические). Результаты анализа приведены в таблице 2.5. Таблица 2.5. Результаты анализа применимости групп методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств
2.5. Выводы по главе 2 В данной главе даны определения основным понятиям (методология, метод, система). Проанализированы основные методологии проектирования систем управления, определены их особенности и компоненты. Проведен анализ методов (моделей, нотаций) анализа и проектирования систем управления, описаны основные свойства и ключевые характеристики методов, обозначены области применения методов. Проведена классификация методологий анализа и проектирования систем управления на структурные методологии (SA/SD; IDEF; ARIS; ORACLE; BAAN) и объектные методологии (OSA; OMT; UML). Проведена классификация основных методов на группы структурных и объектных методов. Структурные методы можно разделить на функциональные, потоков данных, бизнес-процессов, событийные, информационные и иерархические; объектные методы включают в себя статические и динамические модели. По выделенным группам методов даны характеристики и представлены примеры видов моделей. Проведен анализ применимости групп методов проектирования на этапах технических и специальных процессов жизненного цикла программных средств. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
