Мдк зачет. 2. Состав функциональной модели
 Скачать 59.41 Kb.
|
|
1 . Целью создания функциональной модели процесса является точная спецификация всех функций, осуществляемых в рамках процесса более высокого уровня иерархии, а также характера взаимосвязей между ними. Будучи построенной, такая модель способна обеспечить полное представление, как о функционировании обследуемого процесса, так и обо всех имеющих в нем место потоках информации и материалов. 2.Состав функциональной модели • Диаграммы – главные компоненты модели • Блоки – изображают функции моделируемой системы • Дуги - связывают блоки вместе и изображают взаимодействия и взаимосвязи между блоками • ICOM-блок 3.В IDEF0 различают пять типов дуг: 1.вход (Input) – материал или информация, которые используются или преобразуются блоком для получения результата (выхода). Блок может не иметь ни одной входной дуги. Данный вид дуги поступает на левую сторону блока. 2.управление (Сontrol) – условия, правила, стратегии, стандарты, которые влияют на выполнение функции. Каждый блок должен иметь хотя бы одну дугу управления. Данный вид дуг поступает на верхнюю сторону блока. 3.выход (Output) – результат выполнения функции (материал или информация). Каждая функция должна иметь хотя бы одну выходную дугу. Данный вид дуг выходит из правой стороны блока. 4.механизм (Mechanism) – ресурсы, с помощью которых выполняется работа. Это могут быть, например, денежные средства, персонал предприятия, станки. Данный вид дуг поступает на нижнюю сторону блока. (?)5.вызов (Call) – специальная дуга, указывающая на другую модель предметной области. Данный вид дуги выходит из нижней стороны блока. Дуга вызова не является компонентом собственно методологии SADT. Она является расширением IDEF0-методологии и предназначена для организации коллективной работы над моделью, разделения модели на независимые модели и объединения различных моделей предметной области в одну модель. 4.Определение и формализация цели разработки и точки зрения IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. 5.Функциональный блок - программный компонент, отображающий множество значений входных переменных на множество выходных. После выполнения экземпляра функционального блока все его переменные сохраняются до следующего выполнения. Следовательно, функциональный блок, вызываемый с одними и теме же параметрами, может производить различные выходные значения. Сохраняются все переменные, включая входные и выходные. Так, если мы вызовем экземпляр функционального блока, не определяя значения некоторых входных параметров, он будет использовать ранее установленные значения. Возможность задания переменного числа входных значений заложена по определению и не требует каких-либо усилий. 6.Модель может содержать четыре типа диаграмм: 1.контекстную диаграмму (общее описание системы и ее взаимодействия с внешней средой); 2.диаграммы декомпозиции (описывают каждый компонент и их взаимодействие); 3.диаграммы дерева узлов (отображают иерархическую взаимосвязь блоков (функций, работ) без описания взаимосвязей между ними); 4.диаграммы только для экспозиции (FEO) (строятся в основном для справочных целей). 7.DFD – это нотация, предназначенная для моделирования информационный систем с точки зрения хранения, обработки и передачи данных, то есть используется разработчиками ИС для разработчиков ИС. Эта нотация помогает понять, из чего должна состоять система, что нужно для автоматизации бизнес-процесса. Но DFD не является описанием непосредственно бизнес-процесса. Здесь, например, нет такого важного параметра, как время. Также в этой нотации не предусмотрены условия и «развилки». В DFD мы рассматриваем откуда появляются данные, какие данные нужны, их обработку и куда результаты отправить. Т.е. в этой нотации описывается не столько непосредственно процесс, сколько движение потоков данных. 8.Главным различием является то, что нотация IDEF0 является структурной. В ней отражены компонентный состав изучаемого объекта, взаимосвязи и взаимодействия между его элементами. Нотация DFD относится к динамическим. Она отражает поток данных и логику решения задач. Поэтому считают, что DFD лучше использовать для информационных систем, а IDEF0 – для функций и процессов. DFD содержит большее количество графических элементов, в то время как IDEF0 – только два. В связи с этим нотация IDEF0 более регламентирована. 9.Выделяют 4 элемента в диаграмме: Внешние сущности — внешние системы, из которых поступает или куда направляется информация в результате взаимодействия с изображаемой системой. Иными словами, это источники и пункты доставки информации, которая приходит или уходит из системы. Такими сущностями могут быть внешние организации, лица, компьютерные или бизнес-системы. Процессы — любые процессы, которые ведут к изменению информации и созданию выходных данных. Например, выполнение подсчетов, сортировка данных согласно установленной логике или направление информационного потока в соответствии с бизнес-правилами. Хранилища данных — файлы или репозитории, где хранится информация для последующего использования, например, базы данных или формы заявки на участие. Потоки данных — маршруты, по которым информация перемещается между внешними сущностями, процессами и хранилищами данных. Потоки данных иллюстрируют взаимодействие между другими компонентами и отображаются в виде стрелок, как правило, с краткими метками 16.Язык UML нужен, чтобы описать и визуализировать какую-то абстрактную модель. На практике это может быть: ●Создание модели объекта. Например, описание структуры базы данных. ●Создание модели процессов. Например, последовательность выполнения запросов ПО, чтобы клиент получил ожидаемый результат. Схему на языке UML можно составить по уже существующему объекту или процессу либо создать на этапе проектирования, чтобы разрабатывать объект или отлаживать процесс. UML применяют в проектировании, презентациях, описании или создании документации. В аналитике данных тоже используют UML — например, чтобы описать аналитическую программу или структуру информации в проекте. 17.Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью понятий соответствующего пакета и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. 18.Актер (действующее лицо, actor) - это внешне по отношению и разрабатываемого ПО сущность, которая взаимодействует с ним(ПО) в целях получения или предоставления какой-либо информации. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. На диаграммах вариантов использования актер изображается в виде человечка, под которым записывается его имя. 19.Вариант использования (прецедент, use case) - некоторое очевидное для действующего лица процедура, решающая конкретную задачу. прецедент должен обладать результирующей ценностью для актера, актер должен получить некоторый результат исполнения прецедента. Скорее всего, после исполнения прецедента в системе произойдут некоторые изменения: появятся новые данные, изменится поведение. Каждый вариант использования должен исполняться от начала до конца. Прецедент описывает, что делает система, но никак не уточняет, как она это делает. 20.Интерфейс(interface) служит для спецификации параметров модели, которые видимы извне, без указания их внутренней структуры. В языке UML интерфейс является классификатором и характеризует только ограниченную часть поведения моделируемой сущности. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов для актеров. На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя. В качестве имени может быть существительное или строка текста. 21.Примечания – это механизм, предусмотренный в UML для того, чтобы включить в модель произвольные комментарии и ограничения, поясняющие ее. Примечания могут представлять собой артефакты, играющие важную роль в жизненном цикле разработки программного обеспечения (например, требования) либо обзоры или пояснения, выраженные в свободной форме. 22.В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: ассоциации (association relationship) включения (include relationship) расширения (extend relationship) обобщения (generalization relationship) Отношение ассоциации - Отношение между вариантом использования и актером, отражающее связь между ними. Оно устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Включение (include) - Указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Отношение расширения (extend) - Определяет взаимосвязь базового варианта использования с некоторым другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении некоторых дополнительных условий. Отношение обобщения (generalization relationship) - Служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования Б (или актер А может быть обобщен до актера Б). 23.Диаграмма классов (от англ. "class diagram") предназначена для представления внутренней структуры программы в виде классов и связей между ними. Все сущности реального мира, с которыми собирается работать программист, должны быть представлены объектами классов в программе. При этом у каждого класса должно быть только одно назначение и уникально осмысленное имя, которое будет связано с этой целью. Диаграммы классов широко используются при моделировании объектно-ориентированных систем, поскольку они являются единственными диаграммами UML, которые могут быть отображены непосредственно на объектно-ориентированные языки. 24.Основные элементы диаграммы классов UML: Имя класса Атрибуты операции Класс – это план объекта, который может иметь одинаковые отношения, атрибуты, операции и семантику. Класс отображается в виде прямоугольника, включая его имя, атрибуты и операции в отдельных отсеках. Атрибут именуется свойством класса, который описывает моделируемый объект. Операцией класса называется именованная услуга, которую можно запросить у любого объекта этого класса. Операция – это абстракция того, что можно делать с объектом. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса. 25. 26. 27. 28.Диаграмма состояний - это тип диаграммы, используемый в UML для описания всех состояний системы и переходов между ними. Она отображает разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Кроме этого помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии. 29.Основные элементы диаграммы состояний: 1)Состояние (State) отображает одно из возможных состояний, в котором может находиться объект. 2)Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим 3)Событие (Event) представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели 4)Начальное состояние (Start) – это состояние, в котором объект находится непосредственно после его создания. Начальное состояние – это обязательный элемент диаграммы, причем на диаграмме может быть только один такой элемент (изображается черным кружком), стрелка перехода соединяет его с первоначальным состоянием объекта. 5)Конечное состояние (Stop) – состояние, в котором объект пребывает непосредственно перед его уничтожением. Это необязательный элемент, причем количество таких элементов на диаграмме не ограничено. 30. 31. Диаграмма деятельности - это своеобразная блок-схема, которая описывает последовательность выполнения операций во времени. Их можно использовать для моделирования динамических аспектов поведения системы. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. 32.Диаграммы деятельности представляют собой графическое представление рабочих процессов поэтапных действий и действий с поддержкой выбора, итерации и параллелизма. Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов. В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов. 33.Состояние деятельности (activity state) - состояние в графе деятельности, которое служит для представления процедурной последовательности действий, требующих определенного времени. Состояние действия (action state) - специальный случай состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом.  Графически состояния деятельности и действия изображаются одинаковой фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами. Внутри этой фигуры записывается имя состояния деятельности (а) или действия (б) в форме выражения (expression), которое должно быть уникальным в пределах одной диаграммы деятельности. 34. 35.При построении диаграммы деятельности используются только нетриггерные переходы, то есть такие, которые выполняются сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. Если из одного элемента выходит несколько переходов, то выполняться может только один из них. 36.Дорожка - часть области диаграммы деятельности, на которой отображаются только те активности, за которые отвечает конкретный объект. Предназначены дорожки для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует. (?)37.  38.Диаграммы последовательностей UML — это диаграммы взаимодействия, в которых подробно описывается, как выполняются операции. Они фиксируют взаимодействие между объектами в контексте сотрудничества. Диаграммы последовательности ориентированы на время и визуально показывают порядок взаимодействия, используя вертикальную ось диаграммы для представления времени, когда и какие сообщения отправляются. 39.Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники с названиями объектов), вертикальные «линии жизни», отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни» — фокусы контроля), и стрелки, показывающие обмен сигналами или сообщениями между объектами. 40.Сообщение (message) — спецификация передачи информации от одного элемента модели к другому с ожиданием выполнения определенных действий со стороны принимающего элемента. 41.Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей рабочей области диаграммы последовательности от самой верхней ее части до самой нижней. 42.На диаграммах последовательности могут присутствовать три разновидности сообщений, каждое из которых имеет свое графическое изображение:  Первая разновидность сообщения (а) используется для вызова процедур или обозначения отдельных вложенных потоков управления. Принимающий объект может получить фокус управления, становясь в этом случае активным. Передающий объект может потерять фокус управления или остаться активным. Вторая разновидность сообщения (б) используется для обозначения простого асинхронного сообщения, которое передается в произвольный момент времени. Передача такого сообщения обычно не сопровождается получением фокуса управления объектом-получателем. Третья разновидность сообщения (в) используется для возврата из вызова процедуры. В процедурных потоках управления эта стрелка может быть опущена. Для непроцедурных потоков управления, включая параллельные и асинхронные сообщения, стрелка возврата должна указываться явным образом. 43. Диаграмма вариантов использования помогает отобразить основные требования к моделируемой системе и обеспечить взаимопонимание функциональности системы между разработчиком и заказчиком. 44. Актер - внешне по отношению и разрабатываемого ПО сущность, которая взаимодействует с ним(ПО) в целях получения или предоставления какой-либо информации. Вариант использования - некоторое очевидное для действующего лица процедура, решающая конкретную задачу. Связь – взаимодействие действующих лиц и соответствующих вариантов использования. |