Методические указания для выполнения лабораторных работ по дисциплине
 Скачать 3.64 Mb.
|
|
5. Использование объектов-ссылок. Объект ссылки (Referent) в IDEF3 — это объекты, используемые для ком- ментариев к элементам модели. Кроме того, они могут служить для описания цикли- ческих переходов, ссылок на другие диаграммы. Имя ссылки задается именем суще- ствительным, номер — числом. Для внесения объекта ссылки служит кнопка . Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки за- дается в диалоге Referent (рис. 2.7), вызываемом через контекстное меню (пункт Name). Рис. 2.7. Определение имени объекта-ссылки Чтобы связать ссылку с работой, выберите инструмент , щелкните на ссыл- ке (на любой стороне прямоугольника) и на работе (на любой стороне). Появится стрелка. Чтобы изменить ее стиль, выберите в контекстном меню пункт Style и в поя- вившемся диалоге Arrow Properties (см. рис. 2.5) выберите тип (Type) Relational Link. Стрелка изменит свой вид и будет пунктирной линией. Пример диаграммы с объектами-ссылками приведен на рис. 2.8. Рис. 2.8. Декомпозиционная диаграмма с объектами-ссылками 27 6. Создание диаграммы Swim Lane Диаграмма Swim Lane является разновидностью диаграммы IDEF3, позво- ляющей явно описать роли и ответственности исполнителей в конкретной технологи- ческой операции. Эта диаграмма разделена на горизонтальные полосы, каждая полоса соответствует определенному исполнителю (точнее, его роли) и все работы, выпол- няемые этим исполнителем, помещаются на эту полосу. Помимо UOW полоса может содержать и другие объекты диаграммы 1DEF3 (перекрестки и объекты ссылок), от- носящиеся к соответствующей роли. Ролью (Role) может быть должность или позиция конкретного исполнителя. Примеры ролей: Сборщик, Продавец, Технолог, Маркетолог, Разработчик, Дизайнер. Роли объединяются в группы ролей (Role Group). В качестве значения группы ро- лей может быть название предприятия, отдела, цеха или название региона, города и т. д. Одной роли может соответствовать несколько групп ролей. Конкретный исполни- тель, связанный с определенной ролью и группой ролей, называется ресурсом (Re- source). В качестве значения ресурса можно использовать фамилию и имя сотрудни- ка. Например, ресурс Иванов В.П. связан с ролью Продавец и группой Продажа. Прежде чем создавать диаграмму Swim Lane, необходимо создать словарь ро- лей и групп ролей. Откройте словарь Role Group Dictionary (меню Dictionary/Role Group, рис. 2.9), создайте несколько групп ролей. Для каждой группы ролей может быть внесено описание (Definition), указано изображение (предварительно импорти- рованное в словарь изображений Bitmap Dictionary) и важность группы (Importance). Рис. 2.9. Словарь групп ролей Словарь ролей вызывается из меню Dictionary/Role (рис. 2.10). Для каждой ро- ли можно внести определение, указать группу ролей, связать роль с изображением (Bitmap) и геометрической фигурой (Shape), указать важность роли. Рис. 2.10. Словарь ролей 28 Для создания диаграммы Swim Lane следует выбрать меню Diagram/Add Swim Lane diagram. Появляется гид Swim Lane diagram Wizard. В первом диалоге гида (рис. 2.11) следует внести название и имя автора диаграммы, выбрать имя и номер диа- граммы IDEF3, на основе которой будет построена диаграмма, и группу ролей, из ко- торой можно будет выбрать роли, связанные с диаграммой. Рис. 2.11. Первый диалог гида Swim Lane Diagram Wizard Во втором диалоге гида следует выбрать роли, на основе которых будет созда- на диаграмма (рис. 2.12). Диаграмма будет разделена на количество полос, указанных в колонке Display Swim Line. Рис. 2.12. Первый диалог гида Swim Lane Diagram Wizard После щелчка по кнопке Готово создается новая диаграмма, все объекты ко- торой расположены произвольно. Расположить объекты на полосах, соответствую- щих ролям, следует вручную (рис. 2.13). 29 Рис. 2.13. Диаграмма Swim Lane 7. Доработка IDEF3-модели Завершите создание IDEF3-модели для бизнес-процесса, выбранного вами на шаге 1 в качестве индивидуального задания. Законченная модель должна содержать, как минимум 3-4 диаграммы: контекстную, одну или несколько декомпозиционных диаграмм, диаграмму Swim Lane. Диаграммы декомпозиции должны содержать пере- крестки (желательно использовать перекрестки нескольких типов), а также объекты- ссылки. 30 Лабораторная работа №3 «Создание DFD-модели бизнес-процесса» Цель работы: Получить практические навыки в построении DFD-модели биз- нес-процесса средствами пакета BPWin. Порядок выполнения работы. 1. Выбор задания. Выберите бизнес-процесс, для которого будете формировать модель. Вы може- те выбрать один из вариантов процессов, описанных в приложении, или предложить свой вариант. Можно выбрать часть процесса, который моделировался на предыду- щих лабораторных работах. При выборе учтите, что процесс обязательно должен предусматривать обработку информации, лучше, чтобы это была автоматизированная обработка с использованием одной или нескольких информационных систем. 2. Знакомство с основами методологии DFD. Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD пред- ставляет модельную систему как сеть связанных между собой работ. Их можно ис- пользовать как дополнение к модели IDEF0 для более наглядного отображения те- кущих операций документооборота в корпоративных системах обработки информа- ции. DFD описывает: процессы обработки информации (работы); потоки данных (стрелки, arrow), которые могут моделировать и потоки ма- териальных объектов (изделия, документы); внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы; хранилища данных (data store). Как и в IDEF0, основными элементами DFD-диаграмм являются функциональ- ные блоки, которые называются процессами или работами. Они преобразуют входы в выходы (чаще всего это преобразование входных данных в выходные). Блоки соеди- няются стрелками. В отличие от стрелок IDEF0, которые представляют собой жесткие ограничения на работу блоков, стрелки DFD показывают, как объекты (как правило, данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на описание физических характеристик системы – движения объектов (data flow), хранения объектов (data stores), поставки и распространения объектов (external entities). При построении диаграмм потоков данных наиболее часто используют две но- тации: Йордана и Гейна-Сарсона. Обе нотации имеют одинаковый по названиям и значению элементный состав, но имеют различное его графическое изображение. В BPwin для построения диаграмм потоков данных используется нотация Гейна - Сарсона. 31 3. Создание контекстной DFD -диаграммы. Контекстная DFD-диаграмма создается так же, как и аналогичная диаграмма в нотации IDEF0 или IDEF3 (пункт меню File/New), но в диалоге нужно указать тип модели – Data Flow (DFD). Определите автора модели в диалоговом окне Properties. Появится окно с контекстной диаграммой, содержащее работу (процесс обра- ботки информации) верхнего уровня. Работы в DFD представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же как работы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0. Работа на контекстной диаграмме обычно именуется по названию системы, например "Система обработки информации". Определите цель, область и точку зрения на моделируемую систему так же, как и при создании контекстных диаграмм на предыдущих лабораторных работах. В отличие от IDEF0-диаграмм, DFD-диаграмма не должна иметь граничных стрелок. Чтобы показать связь системы с окружением, субъекты окружения (внешние сущности) явно отображаются на диаграмме, и соединяются с системой (работой) стрелками. Внешние сущности изображают входы в систему и/или выходы из системы. Как правило, они представляют собой материальный предмет или физическое лицо, например: Заказчик, Пользователь, Персонал, Поставщик, Клиент, Банк. Внешние сущности изображаются в виде прямоугольника с тенью и обычно располагаются по краям диаграммы. Одна внешняя сущность может быть использована многократно на одной или нескольких диаграммах. Обычно такой прием используют, чтобы не рисо- вать слишком длинных и запутанных стрелок. Чтобы добавить внешнюю сущность выберите кнопку (добавить внешнюю ссылку) в палитре инструментов и щелкните по свободному месту на диаграмме. За- дайте имя сущности аналогично заданию имени объекта ссылки при создании IDEF3- диаграммы (см. рис. 2.7). Номера внешним сущностям присваиваются автоматиче- ски. Если нужно, добавьте другие внешние сущности. Необходимо показать связи между работой и внешними сущностями, которые моделируются с помощью стрелок. Стрелки (потоки данных) описывают движение объектов из одной части сис- темы в другую, например, от одной работы к другой или от внешней сущности к ра- боте, или из хранилища данных к работе и т.д. Обычно это передача информацион- ных объектов (документов, сообщений), но допустимо с помощью стрелок моделиро- вать и материальные потоки. Поскольку в DFD каждая сторона работы не имеет чет- кого назначения, как в IDEF0, стрелки могут подходить выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа «команда-ответ» между работами, между работой и внешней сущностью и между внешними сущностями. Стрелки рисуются аналогично рисованию стрелок на IDEF0- или IDEF3- диа- граммах. Используя инструмент , нарисуйте связи работы с внешними сущностя- ми. Для каждой связи задайте имя, отражающее содержание соответствующего пото- ка. Чтобы сделать стрелку двунаправленной, в диалоге Arrow Properties (пункт Style контекстного меню) на вкладке Style выберите тип (Type) Bidirectional. 32 Пример контекстной DFD-диаграммы приведен на рисунке 3.1. Рис. 3.1. Контекстная диаграмма в нотации DFD 4. Создание декомпозиционной DFD -диаграммы. Выделите работу на контекстной диаграмме и декомпозируйте ее с помощью инструмента . Например, систему оформления заказа можно декомпозировать на три работы: «Консультирование клиента», «Оформление заказа» и «Прием оплаты». Расположение блоков на диаграмме, как и для диаграммы IDEF3, может быть любым, но обычно их располагают слева направо в порядке выполнения соответст- вующих работ. Для каждого блока работы задайте имя. Обычно в имени используется глагол или отглагольное существительное. Номер работы присваивается автоматически. Настроить параметры нумерации работ, а также внешних сущностей и хранилищ можно во вкладке Numbeing диалога Model Properties (меню Model /Model Properties). На диаграмму декомпозиции с контекстной диаграммы будут перенесены стрелки входа и выхода родительской работы. Они будут представлены в виде гра- ничных стрелок (см. рис. 3.2). Согласно нотации DFD диаграмма не должна иметь граничных стрелок – все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних сущностях. Поэтому следует удалить все гранич- ные стрелки, создать соответствующие внешние сущности и вместо граничных про- вести внутренние стрелки, связывающие внешние сущности и работы. При этом на контекстной диаграмме стрелки входа и выхода родительской работы, соответст- вующие удаленным граничным стрелкам, будут иметь знак туннелирования в виде квадратных скобок. 33 Рис 3.2. Декомпозиционная DFD-диаграмма с граничными стрелками Поместите на диаграмму внешние сущности (такие же, как на контекстной диа- грамме). Соедините их с работами внутренними стрелками, задайте имя для каждой связи. При этом в диалоге Arrow Propeties Вы можете выбирать имя из списка ранее введенных имен. Некоторые данные (объекты), которые обрабатываются в блоках работ, посту- пают не извне системы (от внешних сущностей) и не от других работ, а из хранилищ. Результаты работ также могут поступать в хранилища. Хранилища данных (Data store) представляют собой собственно данные, к ко- торым осуществляется доступ. Эти данные также могут быть созданы или изменены работами. В отличие от потоков данных, описывающих данные в движении, храни- лища данных отображают данные в покое, т. е. данные, которые сохраняются в памя- ти между последующими работами. Информация, которую содержит хранилище дан- ных, может использоваться в любое время после её определения. При этом данные могут выбираться в любом порядке. Примеры хранилищ: База данных, Репозитарий, Картотека, Архив, Журнал. В материальных системах, в которых обрабатываются материальные объекты, а не информационные, хранилища моделируют места, где объекты ожидают обработки и в которые поступают после обработки, например: Склад. Чтобы добавить хранилище данных выберите кнопку (добавить Data store) в палитре инструментов и щелкните по свободному месту на диаграмме. Каждое храни- лище данных имеет уникальный номер, который присваивается автоматически. За- дайте имя хранилища данных, отражающее его содержание. Соедините стрелками (потоками данных) работы, внешние сущности и храни- лища данных 34 В DFD стрелки могут сливаться и разветвляться, что позволяет описать декомпози- цию стрелок. Каждый новый сегмент сливающейся или разветвляющейся стрелки может иметь собственное имя. Пример декомпозиционной DFD-диаграммы приведен на рисунке 3.3. Рис 3.2. Декомпозиционная DFD-диаграмма В заключение желательно документировать работы на вкладке Definition диа- лога Activity Properties (пункт Definition/Note контекстного меню). 5. Доработка модели Завершите создание DFD-модели для бизнес-процесса, выбранного вами на ша- ге 1 в качестве индивидуального задания. Диаграммы обязательно должны содержать внешние сущности и хранилища данных. Все стрелки (потоки данных) должны быть обязательно поименованы. 35 Лабораторная работа №4 «Создание прецедентной UML-модели бизнес-процесса» Цель работы: Получить практические навыки в построении прецедентной UML-модели бизнес-процесса средствами пакета Rational Rose. Порядок выполнения работы. 1. Выбор задания. Выберите бизнес-процесс, для которого будете формировать модель. Вы може- те выбрать один из вариантов процессов, описанных в приложении, или предложить свой вариант. Можно выбрать один из процессов, для которого на предыдущих лабо- раторных работах строилась модель по одной из структурных методологий. Жела- тельно, чтобы процесс имел различные версии, т.е. альтернативные потоки событий. 2. Знакомство с основами языка моделирования UML. Унифицированный язык моделирования UML (Unified Modeling Language) предназначен для описания, визуализации и документирования бизнес-систем на базе объектно-ориентированного подхода с целью последующего использования моделей бизнес-процессов для реализации их в виде программного обеспечения. Бурное развитие объектно-ориентированных языков программирования, сопро- вождающееся возрастанием сложности прикладных программ, вызвало потребность в создании объектно-ориентированного языка для формирования предварительной мо- дели предметной области, для которой разрабатывается программа. Такая модель не- обходима заказчикам, программистам и менеджерам проекта по созданию информа- ционной системы для того, чтобы они могли выработать общий взгляд на цели и функции системы. И хотя модели предметной области, формируемые с помощью UML, предназначены, прежде всего, для последующей реализации в виде программ- ного обеспечения, они имеют и самостоятельную ценность, т.к. позволяют наглядно отобразить функции и процессы бизнес-системы, объекты, участвующие в бизнес- процессах, их отношения, а также динамику выполнения процессов. Начало работ над созданием унифицированного объектно-ориентированного языка моделирования относится к середине 1990-х годов. К тому времени уже было разработано более 50 различных языков объектно-ориентированного моделирования. Авторы наиболее распространенных языков – Г. Буч, Д. Румбах и А. Джекобсон, – собравшись «под крылом» компании Rational Software Corporation, начали работу над унифицированным методом. Ими был создан ряд версий унифицированного метода, который они назвали Unified Modeling Language (UML). В настоящее время большин- ством производителей информационных систем и такими комитетами по стандартам, как ANSI и OMG, язык UML был признан в качестве стандарта. В технологии реинжиниринга бизнес-процессов, пожалуй, впервые UML стали применять не только и не столько для создания информационных систем (ИС), сколь- ко для анализа и перепроектирования бизнеса. Вместо моделей процессов, реализуе- мых информационной системой, строятся модели бизнес-процессов, даже если они и не будут подвергнуты автоматизации, вместо объектов ИС (программных объектов) в моделях отражаются объекты бизнеса (исполнители, продукция, услуги и т.д.), вместо окружения ИС (пользователей ИС) моделируется окружение бизнеса (поставщики, партнеры, клиенты). 36 В рамках языка UML все представления о модели сложной системы фиксиру- ются в виде специальных графических конструкций (схем, графов), получивших на- звание диаграмм. Предполагается, что никакая единственная модель не может с дос- таточной степенью адекватности описывать различные аспекты сложной системы. Таким образом, модель сложной системы состоит из некоторого числа диаграмм, ка- ждая из которых отражает некоторый аспект поведения или структуры системы. В языке UML определены следующие виды диаграмм: • диаграмма вариантов использования (Use case diagram); • диаграмма состояний (State diagram); • диаграмма деятельности (Activity diagram); • диаграмма последовательности (Sequence diagram); • диаграмма кооперации (Collaboration diagram); • диаграмма классов (Class diagram); • диаграмма компонентов (Component diagram); • диаграмма развертывания (Deployment diagram). Диаграмма вариантов использования представляет собой наиболее общую кон- цептуальную модель системы, которая является исходной для построения всех ос- тальных диаграмм. Представление вариантов использования детализируется с помо- щью диаграмм состояний, деятельности, последовательности и кооперации. Диа- граммы классов используются для представления логической структуры информаци- онной системы, диаграммы компонентов и диаграммы развертывания – для представ- ления физических компонентов информационной системы. |