Укажите что входит в определение контекста модели
Определение контекста
Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (Scope). Определение области моделирования подразумевает описание:
· субъекта моделирования (субъект – сама система), в процессе описания которого устанавливается:
ü что входит в систему (является ее компонентами),
ü что лежит за ее пределами (является внешним воздействием).
· цели моделирования (Purpose –закладка Purpose меню Edit/Model Properties), которая должна отвечать на следующие вопросы:
ü почему этот процесс должен быть замоделирован?
ü Что должна показывать модель?
ü Что может получить читатель?
Примеры: а) «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений»,
б) Идентифицировать роли и ответственность служащих для написания должностных инструкций,
в) описать функциональность предприятия с целью написания спецификаций ИС и т.д.
Точка зрения – перспектива, с которой наблюдалась система при построении модели (Черемных) или иначе – это взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно точки зрения, например, финансиста и технолога различны и поэтому выбирается точка зрения человека, ответственного за систему в целом, например руководителя предприятия.
· Источников информации для построения модели (Source)
Пример: «Опрос экспертов предметной области и анализ документации».
· Статуса модели: черновой вариант, рабочий, окончательный и т.д.
· Временных рамок (AS-IS или TO-BE)
Вначале создается модель, на которой можно определить слабые места предприятия, например бесполезные, дублирующие и неуправляемые работы, неэффективный документооборот (нет нужных документов на нужном месте в нужное время), отсутствие обратной связи по управлению (нет результата) или по входу (информация используется нерационально).
После анализа модели AS-IS и улучшения бизнес-процессов, создается модель TO-BE, и только на основе модели TO-BE строится впоследствии модель данных, прототип, а затем окончательный вариант ИС
События
Ясное понимание различий
Возможно, вы полагаете, что различие между типом события и самим событием очевидно, но в литературе эти понятия зачастую путаются, из-за чего простые вещи кажутся сложными. Это предупреждение должно помочь вам при изучении различных механизмов программирования, управляемого событиями.
Обзор событий
Здесь один и тот же термин «событие» в разных контекстах имеет разный смысл: иногда речь идет действительно о событиях, иногда о типах событий, иногда об обоих понятиях одновременно. Думаю, что вы согласитесь с моей интерпретацией. В частности:
Возможность непонимания особенно ярко проявляется в двух местах.
Так что при изучении схем управления событий проверяйте, о чем идет речь — о событиях или о типах событий, и убедитесь (это одно из наших очередных наставлений), что в вашей документации по событиям используется правильная терминология.
Контексты
Подписчик при регистрации говорит: «Для события этого типа выполняй это действие». На практике может быть полезно, особенно для приложений GUI, уточнить высказывание: «Для события этого типа, встречающегося в данном контексте, выполняй это действие». Например:
В первом случае «контекстом» является элемент управления, а событием — «щелчок мыши». Во втором контекст — окно, событие — появление мыши; в третьем контекст — датчик, событие — превышение режима.
Для GUI-программирования контекстом обычно является элемент управления. Как показывает последний пример, понятие контекста более общее; контекст может быть любым условием с булевским значением. Примеры GUI являются специальным случаем, где булевское условие задает свойство, такое как «курсор установлен на этой кнопке» или «курсор находится в этом окне». Вот общее определение:
Определение: контекст
Это аналогично тому, как контекст позволяет подписчику установить, что его интересуют события данного типа, но необходимо, чтобы в момент включения выполнялось определенное условие.
Без понятия «контекст» можно обойтись, если включать ассоциированное условие в само регистрируемое действие, например:
Удобнее отделять условие, задавая его вместе с типом события и действием.
Требования «Публиковать-подписаться»
Установив концепции, будем теперь заниматься поиском общего решения проблемы, проектируя архитектуру управления событиями. Начнем с ограничений, которым должно удовлетворять хорошее решение.
Издатели и подписчики
При проектировании архитектуры, поддерживающей парадигму «Публиковать-подписаться», следует рассмотреть следующие ограничения.
Последнее требование является критическим для качества системной архитектуры, особенно когда целью является построение пользовательских интерфейсов: не должно быть так, чтобы проектирование ядра зависело от особенностей интерфейса. Это наблюдение непосредственно приводит к нашим следующим понятиям — модели и облику.
Модель и облик
При проектировании интерфейса мы не только не должны различать подписчиков и издателей, но и различать два дополняющих аспекта приложения.
Определения: модель и облик программной системы
Модель (называемая также бизнес-моделью ) является той частью программной системы, которая обрабатывает данные, представляющие информацию прикладной области.
В этом определении термин «прикладная область» используется в общепринятом смысле, как техническая область, в интересах которой создается и работает приложение. Для платежной системы предприятия прикладной областью является штат компании, для ПО, управляющего полетом, таковой является система управления воздушным сообщением.
Модель является частью ПО — частью, имеющей дело с прикладной областью. Для платежной системы это та часть, которая обрабатывает информацию о служащих, их часах работы, начисляет зарплату, обновляет базу данных. Для системы управления полетом — прокладывает маршрут, вычисляет времена, авторизацию и прочее. Можно сказать, что модель — это часть, выполняющая «настоящую» работу, независимо от взаимодействия с пользователями ПО и остальным миром.
Понятие «бизнес-модель» является более точным, но мы обычно предпочитаем говорить просто «модель». Одна из причин в том, что термин «бизнес» порождает неверные ассоциации (управление компанией, финансами), исключая такие области, как обработка текстов или управление полетами.
Облик задает представление информации, обычно на входе и выходе. Обликом является GUI: например, система управления полетом имеет интерфейс, позволяющий контролировать следование запланированной траектории, вводить нужные команды.
Обычно программа предназначена для одной — возможно, весьма широкой — прикладной области, но обликов у программы может быть несколько. Хорошей практикой является рассмотрение программы с разных точек зрения. При наивном проектировании небольших программ не уделяется должного внимания этой проблеме. Но для серьезных систем необходимо планировать несколько обликов, таких как:
Вначале обычно достаточно одного облика. Вот почему типичной ошибкой проектирования является построение системы, где модель и облик сложно связаны. Затем, когда понадобятся другие облики, приходится прикладывать массу усилий по перепроектированию системы. Во избежание этого общим принципом должно быть разделение модели и ее обликов уже на начальных этапах проектирования системы.
Почувствуй методологию
Принцип разделения модель/облик
При проектировании архитектуры программной системы сводите к минимуму взаимодействие элементов модели и элементов облика.
Если мы используем архитектуру, управляемую событиями, то это правило хорошо сочетается с четким разделением издателей и подписчиков. Как издатели, так и подписчики взаимодействуют с обликом, но не связанными между собой способами.
Заметьте, два разделения — издатели-подписчики и модели-облики — взаимно ортогональны. Как издатели, так и подписчики могут взаимодействовать как с моделью, так и с обликами, как это можно видеть на примере системы обработки текстов.
Для проектирования GUI особый интерес представляет схема «Модель — облик — контроллер» (МОК). Роль третьего элемента — контроллера — состоит в управлении интерактивной сессией. Она может включать создание и координацию обликов.
Каждая из трех частей взаимодействует с двумя другими:
Присутствие контроллера обеспечивает дальнейшее разделение между моделью и обликами (помните, что обликов может быть несколько). Контроллер управляет действиями пользователя, которые могут приводить к обновлению модели, облика, или того и другого.
Как и ранее, облик обеспечивает визуальное представление модели или части ее.
Проектировщик системы может предполагать, что пользователи понимают модель. Используя текстовый процессор, пользователь обычно знаком со шрифтами, абзацами, разделами. Пользователь, играющий в видеоигру, должен чувствовать космическое пространство и летящие ракеты. Хорошая система позволяет пользователю думать в терминах модели. Хотя то, что я вижу на экране, не более чем несколько пикселей, образующих круг, я думаю об этом как о летящем космическом корабле. Контроллер позволяет мне действовать над такими обликами, например, вращая колесико мыши, увеличивать скорость космического корабля, при этом будет обновляться как модель (изменяются ее атрибуты — скорость, позиция), так и облик, отражающий изменения в визуальном представлении.
Парадигма МОК оказала существенное влияние на скорость распространения графических интерактивных приложений за последние десятилетия. В конце лекции мы увидим, что принимая понятие проектирования, управляемого событиями с вытекающими последствиями, можно получить преимущества МОК, но с более простой архитектурой, избегая некоторых отношений, показанных на предыдущем рисунке.
Укажите, чему должна соответствовать точка зрения
-: мнению различных людей
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. Формирование перечня ресурсов и стоимостных объектов («центров затрат»)
Укажите что входит в определение контекста модели
Подробно методология SADT излагается в книге Дэвида А.Марка и Клемента МакГоуэна»Методология структурного анализа и проектирования SADT», издательство Метатехнология, 1993.
При создании новой модели (меню File / New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом. Для внесения имени работы следует кликнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других аспектов контекста служит диалог Model Definition Editor (вызывается из меню Edit/Model Definition).
Стрелки управления, выхода, механизма и выхода изображаются аналогично.
 |
Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Словарь стрелок можно распечатать в виде отчета (меню Report / Arrow Report. ) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.
 |
Одна и та же информация может обрабатываться в нескольких работах, в то же время из нескольких работ могут выходить одинаковые данные, то есть стрелки могут разветвляться и сливаться. Для разветвления стрелки нужно в режиме редактирования стрелки кликнуть по фрагменту стрелки и по соответствующему сегменту работы.
Список синтаксических ошибок модели можно получить сгенерировав отчет об ошибках (Report / Model Consistency Report. ).
Моделирование бизнес-процессов средствами BPwin
Моделирование деловых процессов, как правило, выполняется с помощью case-средств. К таким средствам относятся BPwin (PLATINUM technology ), Silverrun (Silverrun technology ), Oracle Designer ( Oracle ), Rational Rose (Rational Software ) и др. Функциональные возможности инструментальных средств структурного моделирования деловых процессов будут рассмотрены на примере case-средства BPwin.
BPwin поддерживает три методологии моделирования: функциональное моделирование ( IDEF0 ); описание бизнес-процессов (IDEF3); диаграммы потоков данных ( DFD ).
Инструментальная среда BPwin
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. 7.2).
Построение модели IDEF0
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.
Процесс моделирования системы в IDEF0 начинается с создания контекстной диаграммы — диаграммы наиболее абстрактного уровня описания системы в целом, содержащей определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.
Цель моделирования
Цель моделирования определяется из ответов на следующие вопросы:
Точка зрения (Viewpoint).
Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.
В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, «Опрос экспертов предметной области и анализ документации»). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.
Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.
Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.
В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. 7.4).
На рис. 7.5 представлен отчет, сформированный по вышеуказанным полям.