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

Определение контекста

Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (Scope). Определение области моделирования подразумевает описание:

· субъекта моделирования (субъект – сама система), в процессе описания которого устанавливается:

ü что входит в систему (является ее компонентами),

ü что лежит за ее пределами (является внешним воздействием).

· цели моделирования (Purpose –закладка Purpose меню Edit/Model Properties), которая должна отвечать на следующие вопросы:

ü почему этот процесс должен быть замоделирован?

ü Что должна показывать модель?

ü Что может получить читатель?

Примеры: а) «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений»,

б) Идентифицировать роли и ответственность служащих для написания должностных инструкций,

в) описать функциональность предприятия с целью написания спецификаций ИС и т.д.

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

· Источников информации для построения модели (Source)

Пример: «Опрос экспертов предметной области и анализ документации».

· Статуса модели: черновой вариант, рабочий, окончательный и т.д.

· Временных рамок (AS-IS или TO-BE)

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

После анализа модели AS-IS и улучшения бизнес-процессов, создается модель TO-BE, и только на основе модели TO-BE строится впоследствии модель данных, прототип, а затем окончательный вариант ИС

Источник

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

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

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. Формирование перечня ресурсов и стоимостных объектов («центров затрат»)

Источник

События

Ясное понимание различий

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

Обзор событий

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

Возможность непонимания особенно ярко проявляется в двух местах.

Так что при изучении схем управления событий проверяйте, о чем идет речь — о событиях или о типах событий, и убедитесь (это одно из наших очередных наставлений), что в вашей документации по событиям используется правильная терминология.

Контексты

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

В первом случае «контекстом» является элемент управления, а событием — «щелчок мыши». Во втором контекст — окно, событие — появление мыши; в третьем контекст — датчик, событие — превышение режима.

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

Определение: контекст

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

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

Удобнее отделять условие, задавая его вместе с типом события и действием.

Требования «Публиковать-подписаться»

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

Издатели и подписчики

При проектировании архитектуры, поддерживающей парадигму «Публиковать-подписаться», следует рассмотреть следующие ограничения.

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

Модель и облик

При проектировании интерфейса мы не только не должны различать подписчиков и издателей, но и различать два дополняющих аспекта приложения.

Определения: модель и облик программной системы

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

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

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

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

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

Обычно программа предназначена для одной — возможно, весьма широкой — прикладной области, но обликов у программы может быть несколько. Хорошей практикой является рассмотрение программы с разных точек зрения. При наивном проектировании небольших программ не уделяется должного внимания этой проблеме. Но для серьезных систем необходимо планировать несколько обликов, таких как:

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

Почувствуй методологию

Принцип разделения модель/облик

При проектировании архитектуры программной системы сводите к минимуму взаимодействие элементов модели и элементов облика.

Если мы используем архитектуру, управляемую событиями, то это правило хорошо сочетается с четким разделением издателей и подписчиков. Как издатели, так и подписчики взаимодействуют с обликом, но не связанными между собой способами.

Заметьте, два разделения — издатели-подписчики и модели-облики — взаимно ортогональны. Как издатели, так и подписчики могут взаимодействовать как с моделью, так и с обликами, как это можно видеть на примере системы обработки текстов.

Для проектирования GUI особый интерес представляет схема «Модель — облик — контроллер» (МОК). Роль третьего элемента — контроллера — состоит в управлении интерактивной сессией. Она может включать создание и координацию обликов.

Каждая из трех частей взаимодействует с двумя другими:

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

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

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

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

Источник

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

Подробно методология SADT излагается в книге Дэвида А.Марка и Клемента МакГоуэна»Методология структурного анализа и проектирования SADT», издательство Метатехнология, 1993.

При создании новой модели (меню File / New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует кликнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Definition Editor (вызывается из меню Edit/Model Definition).

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

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

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

Рис.3 Словарь стрелок.

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

Список синтаксических ошибок модели можно получить сгенерировав отчет об ошибках (Report / Model Consistency Report. ).

Источник

Принципы построения модели IDEF0

Лекция 4. Создание модели в стандарте IDEF0

Принципы построения модели IDEF0

Работы (Activity)

Стрелки (Arrows)

Нумерация работ и диаграмм

Принципы построения модели IDEF0

Под моделью в IDEF0 понимают описание системы (текстовое и графи­ческое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

Процесс моделирования какой-либо системы в IDEF0 начинается с опре­деления контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.

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

· Почему этот процесс должен быть смоделирован?

· Что должна показывать модель?

· Что может получить читатель?

Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений», «Идентифицировать роли и ответственность служащих для написания долж­ностных инструкций», «Описать функциональность предприятия с целью написания спецификаций информационной системы» и т. д.

Точка зрения (Viewpoint).Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соот­ветствовать цели моделирования. Очевидно, что описание работы пред­приятия с точки зрения финансиста и технолога будет выглядеть совер­шенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения челове­ка, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтер­нативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

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

Для задания цели моделирования, точки зрения и иных свойств модели предназначен диалог Model Properties (меню Model → Model Properties) (рис. 1).

Рис. 1. Диалог Model Properties

В закладке Purpose следует внести цель и точку зрения, а в закладке Definition – пояснительный текст (описание) к модели и описание области. В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). В закладке Status того же диалога можно описать статус модели(рабочая версия, черновик, рекомендовано, публикация), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате).

В закладке Numbering задаются правила нумерации функциональных блоков.

В закладке Display задается список элементов отображаемых на диаграммах.

Закладка Layout задает параметры расположения объектов на диаграмме.

Закладка ABC Units задает единицы функционально-стоимостного анализа.

PageSetup– закладка, на которой задаются параметры страницы.

Header /Footer– закладка, на которой задаются опции заголовка и нижнего колонтитула каркаса.

В закладке Shapesустанавливаются виды фигур для объектов диаграмм по умолчанию.

DrawStyle— закладка, на которой задаются опции графического стиля.

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

Модель может содержать четыре типа диаграмм:

· контекстную (в каждой модели может быть только одна контекстная
диаграмма);

· только для экспозиции (FEO).

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

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

Источник