Укажите чему должна соответствовать точка зрения

Точка зрения

В процессе моделирования, когда авторы выбирают точку зрения для модели, осуществляется стратегия разделения проблем. Хотя при построении модели учитываются мнения многих людей, согласно требованиям методологии IDEF0, модель должна строиться с определенной позиции рассмотрения, которая в системном моделировании называется точкой зрения. Точка зрения- позиция, с учетом которой создается модель и с которой наблюдается система в целом. Точка зрения обозначает основное направление развития модели и уровень необходимой детализации, должна соответствовать цели моделирования. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
Точка зрения не ограничивает предмет рассмотрения, но заставляет аналитика учитывать приоритеты различных аспектов системы. Поэтому при выборе точки зрения на модель можно фиксировать дополнительные/альтернативные точки зрения. Но в большинстве случаев только одна из множества возможных точек зрения может дать описание, полностью удовлетворяющее цели модели.
Точка зрения:

выбирается с целью получить как можно больше полезной информации о субъекте и форму ее подачи;

определяет, что будет рассматриваться и под каким углом зрения;

определяет уровень рассмотрения моделируемого процесса, расстановку акцентов и ис-пользуемую терминологию.

Описание процесса производственной системы

‹ Цель модели
Вверх
Описание процесса производственной системы ›

Источник

Укажите, чему должна соответствовать точка зрения

-: мнению различных людей

21. Какое назначение имеет стоимостный анализ?

+: понять происхождение выходных затрат

-: определить очередность выполнения работ

+: определить действительную стоимость производства продукта

+: обеспечить менеджеров финансовой мерой предлагаемых изменений

22. Для описания сценариев действий сотрудников организации или вариантов работы информационной системы служат:

+: диаграммы нотации IDEF3

-: диаграммы потоков данных

-: диаграммы нотации IDEF0

-: диаграммы нотации IDEF1X

23. Объект Переход в диаграммах STD определяет:

+: перемещение моделируемой системы из одного состояние в другое

-: стартовую точку для начала функционирования системы

-: условие устойчивости для системы

-: связь между двумя или более сущностями

24. Словарь данных при построении диаграмм потоков данных (DFD):

+: обеспечивает аналитика средствами описания деталей компонентов DFD, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ

-: рассматривается как условие функционирования проектируемой системы

-: используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD

25. Тип взаимосвязей между блоками SADT диаграммы Выход – Механизм отражает ситуацию, при которой:

-: один из блоков должен полностью завершить работу, перед началом работы другого блока и Выход становится Входом для блока с меньшим доминированием

-: Выход одного блока непосредственно влияет на блок с меньшим доминированием

-: Выход некоторого блока влияет на блок с большим доминированием

+: Выход одной функции становится средством достижения цели другой функции

-: Выход одного блока становится Входом другого с большим доминированием

26. Миниспецификации обработки, описывающие DFD-процессы:

-: обеспечивают аналитика средствами описания деталей компонентов DFD, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ

-: позволяет формально описать расщепление/объединение потоков

-: представляют собой алгоритмы описания задач, выполняемых процессами

+: используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD

27. Назначение диаграммы переходов состояний (STD)-:

-: документировать механизмы передачи и обработки информации в моделируемой системе

+: моделировать последующее функционирование системы на основе ее предыдущего и текущего функционирования

-: описывать информационные потоки между моделируемой областью и внешними объектами

28. SADT модель может основываться на:

+: входных данных системы

+: выходных данных системы

29. Сущность представляет собой множество:

-: отношений между хранилищами данных

-: потоков данных и потоков управления

+: экземпляров реальных или абстрактных объектов, обладающих общими атрибутами или характеристиками

30. Информационную модель системы (ERD) можно описать с помощью следующих терминов:

-: отношение, состояние, переход, поток данных

-: поток данных, хранилище данных, процесс, внешняя сущность

+: отношение, связь, сущность, атрибут

-: категория, условие, действие

-: атрибут, состояние, связь

31. Идентифицирующая связь в диаграммах ERD:

-: связь, при которой экземпляр дочерней сущности не идентифицируется через свою ассоциацию с родительской сущностью

+: связь, при которой экземпляр дочерней сущности идентифицируется через свою ассоциацию с родительской сущностью

-: служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней

32. Упорядочите приведенные этапы создания функциональных диаграмм процесса Моделирования:

1: выбор цели о точки зрения

2: составление списка данных

3: составление списка функций

4: построение и обобщение диаграммы А0(А0 – А-0)

5: декомпозиция ограниченного объекта

7: итерационный процесс рецензирования

8: завершение моделирования

-: техника генерации описаний компонентов ИС

-: правила использования методов, с помощью которых разрабатывается проект ИС

-: описание проекта системы на формальных и естественных языках

-: специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС

+: отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм

34. Дайте определение понятию «Основные бизнес-процессы»

+: процессы, ориентированные на производство товаров и услуг

-: процессы, обеспечивающие получение дохода

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

35. Какая модель отвечает на вопросы кто-что-как-кому?

-: стратегическая модель целеполагания

-: модель структуры данных

+: процессные потоковые модели

-: модели структур данных

37. Какая модель отражает представление о новых технологиях работы организации?

+: модели «как должно быть»

38. Какие основные понятия используются при создании функциональной диаграммы IDEF0?

-: внешние источники и получатели данных

-: хранилища, требуемые процессами для своих операций

39. Какие стрелки называются граничными? Стрелки, которые:

-: служат для описания взаимодействия с окружающим миром

+: начинаются у границы и заканчиваются у работы

+: начинаются у работы и заканчиваются у границы

-: начинаются у границы и заканчиваются у границы

40. Укажите, с какой целью строятся диаграммы для экспозиции (FEO)?

+: для иллюстрации отдельных фрагментов модели

+: для иллюстрации альтернативной точки зрения

+: для иллюстрации специальных целей

-: для иллюстрации взаимосвязи между работами

41. Укажите, что входит в определение контекста модели&

+: определение субъекта моделирования

+: определение цели моделирования

+: определение точки зрения

-: определение количества уровней декомпозиции

42. Диаграмму потоков данных (DFD) можно описать с помощью следующих терминов:

-: состояние, хранилище данных, связь, действие

-: хранилище данных, поток, процесс, атрибут, условие

+: сущность, поток, процесс, накопитель данных

-: отношение, категория, функция, переход

43. Какой вариант правильно описывает цифрами последовательность этапов АВС-анализа?

2. Формирование перечня ресурсов и стоимостных объектов («центров затрат»)

Источник

Методология IDEF0

Описание системы с помощью IDEF0 называется функциональной моделью. Функциональная модель предназначена для описания существу­ющих бизнес-процессов, в котором используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником графического языка является сама методология IDEF0.

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

IDEF0 требует, чтобы в диаграмме было не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм и модели на уровне, доступном для чтения, понимания и использования.

Блоки в IDEF0 размещаются по степени важности, как ее понимает автор диаграммы. Этот относительный порядок называется доминированием. Доминирование понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком диаграммы может быть либо первый из требуемой последовательности функций, либо планирующая или контролирующая функция, влияющая на все другие.

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок, изображаемых одинарными линиями со стрелками на концах. Стрелки представляют собой некую информацию и именуются существительными.

Типы стрелок

В IDEF0 различают пять типов стрелок.

Рис. 2.1Типы стрелок

В методологии IDEF0 требуется только пять типов взаимодействий между блоками для описания их отношений: управление, вход, обратная связь по управлению, обратная связь по входу, выход-механизм. Связи по управлению и входу являются простейшими, поскольку они отражают прямые воздействия, которые интуитивно понятны и очень просты.

Рис. 2.2. Связь по выходу

Рис. 2.3. Связь по управлению

Отношение управления возникает тогда, когда выход одного блока непосредственно влияет на блок с меньшим доминированием.

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

Обратная связь по управлению возникает тогда_; когда выход некоторого блока влияет на блок с большим доминированием.

Связи «выход-механизм» встречаются нечасто. Они отражают ситуацию, при которой выход одной функции становится средством достижения цели для другой.

Рис. 2.4. Обратная связь по входу

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.

Разветвление дуг, изображаемое в виде расходящихся линий, означает, что все содержимое дуг или его часть может появиться в каждом ответвлении. Дуга всегда помечается до разветвления, чтобы дать название всему набору. Кроме того, каждая ветвь дуги может быть помечена или не помечена в соответствии со следующими правилами:

Слияния дуг в IDEFO, изображаемое как сходящиеся вместе линии, указывает, что содержимое каждой ветви идет на формирование метки для дуги, являющейся результатом слияния исходных дуг. После слияния результирующая дуга всегда помечается для указания нового набора объектов, возникшего после объединения. Кроме того, каждая ветвь перед слиянием может помечаться или не помечаться в соответствии со следующими правилами:

Рис. 2.6. Связь выход-механизм

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

Данный набор факторов относится к каждой диаграмме модели. Далее будут перечислены рекомендации по желательным значениям факторов диаграммы.

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

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

Помимо анализа графических элементов диаграммы необходимо рассматривать наименования блоков. Для оценки имен составляется словарь элементарных (тривиальных) функций моделируемой системы. Фактически в данный словарь должны попасть функции нижнего, уровня декомпозиции диаграмм. Например, для модели БД элементарными могут являться функции «найти запись», «добавить запись в БД», в то время как функция «регистрация пользователя» требует дальнейшего описания.

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).

Рис.2.8 Диалог создания модели

Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Пример

После изучения исходных документов и опроса заказчиков и пользователей системы необходимо сформулировать цель моделирования и определить точку зрения на модель. Рассмотрим технологию ее построения на примере системы «Служба занятости в рамках вуза», основные возможности которой были описаны в лабораторной работе № 1.

Сформулируем цель моделирования: описать функционирования системы, которое было бы понятно ее пользователю, не вдаваясь в подробности, связанные с реализацией. Модель будем строить с точки зрения пользователей (студент, преподаватель, администратор, деканат, фирма).

Начнем с построения контекстной IDEF0-диаграммы- Согласно описанию системы основной функцией является обслуживание ее клиентов посредством обработки запросов, от них поступающих. Таким образом, определим единственную работу контекстной диаграммы как «Обслужить клиента системы». Далее определим входные и выходные данные, а также механизмы и управление.

Для того чтобы обслужить клиента, необходимо зарегистрировать его в системе, открыть доступ к БД и обработать его запрос. В качестве входных данных будут использоваться «имя клиента», «пароль клиента», «исходная БД», «запрос клиента». Выполнение запроса ведет либо к получению информации от системы, либо к изменению содержимого БД (например, при составлении экспертных оценок), поэтому выходными данными будут являться «отчеты» и «измененная БД». Процесс обработки запросов будет выполняться монитором системы под контролем администратора.

Контекстная диаграмма

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Рис 2.9.Контекстная диаграмма системы

Проведем декомпозицию контекстной диаграммы, описав последовательность обслуживания клиента:

Получим диаграмму, изображенную на рис. 2.10.

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

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

После прохождения процедуры доступа в систему монитор анализирует запрос клиента, выбирая подсистему, которая будет обрабатывать запрос. Декомпозиция работы «Обращение к подсистеме» не отвечает цели и точке зрения модели. Пользователя системы не интересуют внутренние алгоритмы ее работы. В данном случае ему важно, что выбор подсистемы будет произведен автоматически, без его вмешательства, поэтому декомпозиция обращения к подсистеме только усложнит модель.

Декомпозируем работу «Обработка запроса клиента», выполняемую подсистемой обработки запросов, определения категорий и полномочий пользователей. Перед осуществлением поиска ответа на запрос необходимо открыть БД (подключиться к ней). В общем случае БД может находиться на удаленном сервере, поэтому может потребоваться установление соединения с ней. Определим последовательность работ:

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

Необходимо отметить, что в «Выполнение запроса» включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. На этапе выполнения запроса может потребоваться изменениесодержимого БД, например при составлении экспертных оценок. Поэтому, на диаграмме необходимо предусмотреть такую возможность.

Рис. 2.12. Декомпозиция работы «Обработка запроса клиента»

Корректировка диаграммы

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.

Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.

Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

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

Данную модель реализовать другим способом, предоставив возможность обновления БД непосредственно по запросам, минуя процесс контроля данных. В этом случае необходимо обеспечить контроль целостности БД для избежания ее повреждения. В этом случае диаграмма будет выглядеть следующим образом (рис. 2.17).

Рис. 2.16. Декомпозиция работы «Изменение БД»

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

Проведение дальнейшей декомпозиции «Изменения БД» будет усложнять модель, объясняя, как осуществляется физическое изменение БД в системе. При этом пользователь не получит никакой дополнительной информации о работе системы службы занятости. Декомпозицию этой работы целесообразно проводить в процессе проектирования БД системы на этапе создания логической модели БД.

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента К_b у двух вариантов моделей.

для второго варианта

Коэффициент К_b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.

Контрольные вопросы

Список Контрольных вопросов:

Источник