exam_03

Понятие инкапсуляции в объектно-ориентированном подходе. Применение принципов инкапсуляции при трансформации диаграмм IDEF0 в UML.

Объектно-ориентированный подход (ООП) использует объектную декомпозицию, то есть поведение системы описывается в терминах взаимодействия объектов. Прежде всего, необходимо ввести некоторые понятия. Класс – абстракция множества сущностей реального мира, объединенных общностью структуры и поведения. Объект – элемент класса, то есть абстракция определенной сущности. Интерфейс – это набор методов класса, доступных для использования другими классами. При объектно-ориентированном подходе программа представляет собой описание объектов, их свойств, отношений между ними, способов их взаимодействия и операций над объектами (или методов). Шесть принципов ООП:

• Абстракция – в ООП это придание объекту характеристик, которые четко выделяет его на фоне остальных, определяя его концептуальные границы. Абстрагирование - В ООП это способ выделить набор значимых характеристик объекта, исключая из рассмотрения не значимые.
• Инкапсуляция – сокрытие реализации программных частей для безопасности. В качестве примера машина без корпуса (инкапсуляции) и с корпусом. Создавая свойства и методы не делайте их сразу public, делайте их открытыми только тогда, когда это нужно или если это было сразу так задумано. Паблик свойства вообще не желательны.Другими словами, концепция инкапсуляции призвана обеспечивать безопасность проектирования и реализации программного обеспечения на основе локализации манипулирования объектом в областях его полей и методов . Практическая важность концепции инкапсуляции для современных языков объектно-ориентированного программирования (в том числе и для языка C#) определяется следующими фундаментальными свойствами.
• Наследование – создание нового объекта на основании старого или создание нового класса на основании старого;
• Полиморфизм – возможность дополнять объект функционалом. Возможность выступать объекту в разных формах. Классический полиморфизм – замещение, переопределение методов. Подмена объектов во время выполнения программы с одинаковыми методами через интерфейс;
• Посылка сообщений – вызов метода. Так же события и их обработчики;
• Повторное использование – все, что перечислено выше работает на повторное использование кода.

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

Алгоритм конвертации заключается в следующем: На первом этапе модуль синтаксического анализа выполняет парсинг файла экспорта из BPWin в формате IDL. Этот формат файлов является стандартным для обмена информацией в нотации IDEF0 между CASE-средствами различных производителей. Модуль выполняет синтаксический разбор файла формата IDL и формирование объектов, описывающих элементы модели (диаграммы, работы, стрелки) с учётом иерархии диаграмм декомпозиций. Эти объекты являются исходным материалом для конвертирования «IDEF0=>UML». Последующие четыре этапа реализуют алгоритм конвертирования. Вначале выполняется определение первых работ на диаграмме IDEF0. В стандарте IDEF0 нет специального элемента для обозначения начала процесса. Обычно принято располагать функции в порядке: сверху-вниз и слева-направо в соответствии с их взаимосвязями. Но такой порядок является только рекомендуемым.В каждой ситуации реализуются свои правила. В результате выполнения очередного шага алгоритма определяется одна или несколько работ, которые будут соответствовать на UML-диаграмме одной или нескольким первым параллельным состояниям деятельности. На следующих шагах алгоритма определяется последовательность выполнения работ, поскольку стандарт IDEF0 однозначно отражает на диаграмме лишь взаимосвязи работ по входам/выходам или выходам/управлению. Здесь важным является признак наличия/отсутствия обратных связей на диаграмме. Все множественные выходы в диаграммах IDEF0 по умолчанию будут преобразованы в элементы разделения. Однако в некоторых случаях по логике необходимо отразить не параллельное выполнение, а альтернативное ветвление процесса. Поэтому в процессе преобразования целесообразно предусмотреть возможность замены элемента разделения на блок условия. Эти изменения добавляются по инициативе пользователя во время или после основного процесса преобразования IDEF0 в UML. На следующем этапе выполняется распределение состояний деятельности по дорожкам. Использование этого удобного механизма языка UML позволяет четко распределить ответственность за выполнение этапов работ по исполнителям. Необходим диалог с пользователем для выделения механизмов-исполнителей для каждой работы.Дорожки добавляются на диаграмму в порядке появления на них состояний деятельности (работ). Если один механизм-исполнитель выполняет несколько работ, то они будут располагаться на одной дорожке. Если какую-то работу выполняют несколько механизмов-исполнителей, то необходима отдельная дорожка, у которой в заголовке будут указаны все исполнители, которые совместно выполняют работу. На заключительном этапе предполагается формирование файла формата .frm, соответствующего внутренней структуре модели.

Понятие потока информации и его математическая интерпретация. Способы описания информационных потоков в UML.

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

Существует множество способов математической интерпретации потоков информации:

• Графический метод - используется для описания потоков информации (главным образом документопотоков) небольшой размерности на макроуровне, для выявления общей структуры и функций системы управления, а также для совершенствования существующих потоков информации;
• Описание с использованием теории графов – с помощью данного метода достигается наглядность функционирования системы управления и движения потоков информации; применение математического аппарата теории графов позволяет оптимизировать работу управления и каналов связи; имеется возможность также представить динамику управления и движения информации, которая ускользает при пользовании другими методами. В настоящее время имеется много примеров использования теории графов в описании данных процессов. Они различаются по характеру описываемых объектов, по видам графов;
• Метод функционально-операционного анализа - предназначен для организации, синтеза и обработки информации, необходимой органам территориального планирования. Кроме того, он применяется в работе высших функциональных органов планирования и управления, не связанных непосредственно с управлением технологическими процессами;
• Модуль-метод – применяется для анализа структуры информационного потока после использования других методов. Для каждого фиксированного сообщения составляется типовая карточка, которая затем пускается по выявленному структурному каналу. При движении карточки на ней отмечаются все операции обработки информации по данному каналу. Операции обработки информации включают съем, кодирование, отображение, передачу, переработку, представление информации и выработку решений. В результате обработки карточек простейшими средствами механизации можно получить подробные сведения о количестве информации, определить пропускную способность, вычислительные мощности, выявить дублирование, определить периодичность, частоту поступления информации и другие количественные и качественные характеристики;
• Метод матричного моделирования – представляет собой таблицу, отражающую соответствующие взаимосвязи всех подразделений предприятия и его окружения (через движение документов и показателей), а также формирование новых данных в процессе функционирования системы управления.При разработке моделей существуют различные виды информационных потоков, которые используются в качестве переходов информации в диаграммах UML, особенно это заметно на диаграммах взаимодействия. К диаграммам взаимодействия относятся:
• Диаграмма взаимодействия – в UML диаграммы классов не содержат сообщений, которые усложняют их чтение. Поток сообщений между объектами выносится на диаграммы взаимодействия. Диаграмма взаимодействия описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются и охватывает поведение объектов в рамках одного варианта использования. Взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Также можно рассматривать структурные особенности взаимодействия объектов. Для представления структурных особенностей передачи и приема сообщений между объектами используется диаграмма кооперации.
• Диаграмма кооперации – акцентирует внимание на организации объектов, принимающие участие во взаимодействии. Так же, как и диаграммы последовательности, кооперативные диаграммы отправляют поток событий через конкретный сценарий варианта использования, но диаграмма последовательности упорядочена по времени, а кооперативные диаграммы предназначены для описания методов взаимодействия между объектами.
• Диаграмма деятельности – это своеобразная блок-схема, которая описывает последовательность выполнения операций во времени. Их можно использовать для моделирования динамических аспектов поведения системы. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. В диаграммах деятельности используются пиктограммы "действие", "переход", "выбор" и "линии синхронизации". В языке UML действие изображается в виде прямоугольника с закругленными углами, переходы - в виде направленных стрелок, элементы выбора - в виде ромбов, линии синхронизации - в виде горизонтальных и вертикальных линий. Состояние действия является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Когда действие или деятельность в некотором состоянии завершается, поток управления сразу переходит в следующее состояние действия или деятельности. Для описания этого потока используются переходы, показывающие путь из одного состояния действия или деятельности в другое.
• Диаграмма обзора взаимодействия – разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.