Определение контекста
Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (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).
Стрелки управления, выхода, механизма и выхода изображаются аналогично.
 |
Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий. Словарь стрелок можно распечатать в виде отчета (меню Report / Arrow Report. ) и получить тем самым толковый словарь терминов предметной области, использующихся в модели.
 |
Одна и та же информация может обрабатываться в нескольких работах, в то же время из нескольких работ могут выходить одинаковые данные, то есть стрелки могут разветвляться и сливаться. Для разветвления стрелки нужно в режиме редактирования стрелки кликнуть по фрагменту стрелки и по соответствующему сегменту работы.
Список синтаксических ошибок модели можно получить сгенерировав отчет об ошибках (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) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей.
