ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 02.12.2023
Просмотров: 30
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
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) представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели