Лабораторные работы RR. Методические указания к выполнению лабораторных работ 17 введение
 Скачать 1.41 Mb.
|
|
МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ Использование CASE-средств при описании бизнес-процессов Методические указания к выполнению лабораторных работ № 1-7 ВВЕДЕНИЕ Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия. В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE- средствами являются Rational Rose, BPwin, Silverrun, Process Analyst. Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Основными задачами при моделировании предметной области являются следующие описания: - бизнес-процессов предприятия; - действующих лиц бизнес-процессов и их функций, подлежащих авто- матизации в привязке к структуре автоматизируемого предприятия; - бизнес-сущностей; - сценариев выполнения бизнес-функций, подлежащих автоматизации; - состояний бизнес-сущностей; - бизнес-правил. Описания бизнес-процессов используются для описания технологии выполнения производственной задачи, подлежащей автоматизации. На основе описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе). При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Итак, подводя итог сказанному об описании предметной области при разработке программных систем, отметим следующее: 1. Описание предметной области должно включать не только описание бизнес-процессов, но и описание структуры автоматизируемого предприятия, его действующих лиц, их автоматизируемых функций, документов, связанных с автоматизированными функциями, прочих бизнес- сущностей, сценариев реализации бизнес-функций и состояний бизнес- сущностей. 2. Модель бизнес-процессов используется для определения бизнес-тре- бований к разрабатываемой системе и выявления всех связей между под- разделениями, принимающими участие в решение конкретной задачи. 3. Модель структуры предприятия используется для отражения дей- ствующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы. 4. Модели документов, бизнес-сущностей используются при проек- тировании пользовательского интерфейса, базы данных, формирования альбома выходных форм системы. 5. Модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса. 6. Модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и базы данных системы. 7. Модели бизнес-правил используются при моделировании правил программной системы. Полное и детальное описание предметной области удобно производить с помощью разнообразных CASE-средств. Case-средства Термин CASE - Computer Aided System/Software Engineering используется при автоматизации процесса разработки сложных инфор- мационных систем в целом. Появлению CASE-средств предшествовали исследования в области методологии проектирования. Методология определяет этапы и шаги реализации проекта, а также правила использования методов, которыми разрабатывается проект. Метод - это процедура или техника генерации описаний компонентов информационной системы (проектирование потоков и структур данных). Нотация - отображение структуры системы, элементов данных с помощью специальных графических символов. CASE-средства - это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования информационных систем. CASE- технология, в рамках методологии, включает в себя методы, с помощью которых на основе нотаций строятся диаграммы, поддерживаемые конкретным CASE-средством. CASE-технологии не могут считаться самостоятельными, они только обеспечивают высокую эффективность их применения. Краткая характеристика Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Архитектура CASE-средств Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения и включающее в себя: 1. Репозиторий, являющийся основой CASE-средства. Он представляет собой специализированную базу данных проекта, предназначенную для отображения состояния проектируемой информационной системы в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. В репозитории хранятся описания следующих объектов: проектировщиков и их прав доступа к различным компонентам системы; организационных структур; диаграмм; компонентов диаграмм; связей между диаграммами; структур данных; программных модулей; процедур. 2. Графический редактор, обеспечивающий создание и редактирование в заданной нотации и в интерактивном (диалоговом) режиме элементов диаграмм, связей между ними, диаграмм. В любой момент времени они могут быть распечатаны и включены в техническую документацию проекта. 3. Верификатор диаграмм (средство тестирования), служащее для контроля правильности построения диаграмм в заданной методологии проектирования. Его функции: a) диагностика, b) выдача сообщений об ошибках, c) выделение на диаграмме ошибочных элементов. 4. Документатор проекта, позволяющий получать информацию о про- ектах в виде отчетов. Отчеты могут строиться: a) по времени, b) автору, c) элементам диаграмм, d) диаграмме, e) проекту в целом. 5. Администратор проекта, выполняющий следующие функции: a) инициализация (запуск), b) задание начальных параметров проекта, c) назначение и изменение прав доступа к элементам проекта. 6. Сервис, представляющий собой набор системных утилит по об- служиванию репозитория (архивация и восстановление данных, создание нового репозитория). На рисунке показана архитектура CASE-средства в общем виде. Архитектура CASE-средства Используемые методологии При применении CASE-средств используются методологии структурного и объектно-ориентированного проектирования. Структурное проектирование основано на алгоритмической декомпозиции, а объектно- ориентированное проектирование основано на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое внимание объектам или субъектам действия. CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML. Представления информационной системы на языке UML: 1. Представление использования - основная часть модели описания системы. 2. Логическое представление - описание функциональных возможностей системы. 3. Компонентное представление - описание структуры и взаимосвязей модулей системы. 4. Представление взаимодействия процессов - описание согласованных действий модулей системы. 5. Представление распределения - описание физической архитектуры системы. Каждое представление состоит из диаграмм, которые строятся из своих нотаций. Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Главным разработчиком методологии был Дуглас Росс. Он разработал язык структурного анализа, используемого для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF. Их использовали в США по предложению ВВС. В настоящее время семейство IDEF включают: IDEF0 - стандарт функционального моделирования IDEF1X - стандарт моделирования потоков данных IDEF2 - стандарт динамического моделирования систем IDEF3 - стандарт документирования процессов IDEF4 - стандарт построения объектно-ориентированных систем IDEF5 - стандарт онтологического (принципиального, структурного) исследования систем. Правила оформления лабораторных работ Порядок выполнения работ 1. Выполнить тестовый пример. 2. Получить индивидуальное задание. 3. Сдать отчет по заданию. 4. Ответить на вопросы. Результаты выполнения работ После выполнения лабораторной работы должен быть составлен отчет. Содержание отчета: 1. Титульный лист. 2. Название и цель выполнения работы. 3. Описание своей задачи с перечислением того, что выполнено. 4. Письменные ответы на заданные вопросы. Темы лабораторных работ 1. Абитуриент одного из потоков стал студентом одной из групп одного из факультетов вуза. 2. Студент одной из групп изучает дисциплины и сдает экзамены и зачеты. 3. Студент одной из групп записывается на дисциплину к преподавателю одной из кафедр. 4. Преподаватель одной из кафедр одного из факультетов вуза проводит занятия по определенным дисциплинам. 5. Студент одной из групп одного из факультетов вуза изучает дисциплины определенной специальности на определенном курсе. 6. Студент регистрируется в одной из групп определенной специальности одного из факультетов одного из вузов города. 7. Абитуриент одного из потоков сдает экзамены по определенным предметам и получает отметки. 8. На один из складов фирмы поступают товары от различных поставщиков. 9. На один из складов одной из фирм города поступает товар от различных поставщиков. 10. Со складов фирмы выдаются товары от различных поставщиков различным потребителям из различных городов. 11. Со складов различных фирм города выдаются товары различным потребителям из различных городов. 12. Со склада фирмы выдаются товары различных поставщиков и раз- личных производителей различным потребителям различных городов. 13. На склад поступают товары различных производителей различных стран от поставщиков различных городов 14. На склады различных фирм города поступает товар различных производителей от различных поставщиков 8 15. Клиенты делают покупки различных товаров в магазинах торговой фирмы наличными, по карточкам и в кредит. 16. Покупатели магазина делают покупки различных товаров различных производителей и различных поставщиков. 17. Клиенты покупают товар различных производителей в магазинах торговой фирмы наличными, по карточкам и в кредит. 18. В магазине торгуют товарами различного вида, различных произ- водителей и от различных поставщиков. 19. В магазинах торговой фирмы торгуют товарами различного вида, различных производителей и от различных поставщиков. 20. В магазинах торговой фирмы торгуют товарами различного вида наличными, по карточкам и в кредит. 21. В магазине торгуют товарами различного вида, различных произ- водителей и от различных поставщиков наличными, по карточкам и в кредит. 22. В отделе кадров ведется учет подразделений, должностей и сотрудников; в личном деле сотрудника регистрируются приказы и изменения в положении сотрудника. 23. Проекты состоят из разного набора документов; документы учитываются и отправляются заказчику. 24. Транзисторы классифицируются по типу, мощности и конструктиву; ведется учет поступлений и продаж. 25. Радиоэлементы классифицируются по типу, наименованию; ведется учет использования их в проектах. 26. Контролеры определяют качество изделий и ведут журнал учета годных, списанных и дорабатываемых изделий. 27. Контролеры регистрируют результаты тестирования партии изделий в маршрутных листах. 28. Эксперты назначают эталонные значения параметров изделия оп- ределенного типа; операторы измеряют параметры каждого изделия. 29. Изделия характеризуются эталонными параметрами, ведется журнал учета отклонений реальных параметров от эталонных. 30. Конденсаторы классифицируются по типу, мощности и конструктиву; ведется учет поступлений и продаж. Лабораторная работа № 1. ОЗНАКОМЛЕНИЕ С CASE-СРЕДСТВОМ RATIONAL ROSE Цель работы. Изучить интерфейс Rational Rose и принципы работы с ним. Основные понятия Rational Rose - это CASE-средство фирмы Rational Software Corporation (США), предназначенное для автоматизации этапов анализа и проектирования программного обеспечения, для генерации кодов на различных языках и выпуска проектной документации . Rational Rose использует методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать про- граммные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование про- граммных компонент в новых проектах. Структура и функции В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, про- цессов.В составе Rational Rose можно выделить 6 основных структурных компонент: - репозиторий, - графический интерфейс пользователя, - средства просмотра проекта (browser), - средства контроля проекта, - средства сбора статистики - генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ. Репози- торий представляет собой объектно-ориентированную базу данных. Средства просмотра обеспечивают "навигацию" по проекту, в том числе: перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose^++ обеспечивает возможность повторного использования программных компонент. В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: - диаграммы классов; - диаграммы состояний; - диаграммы сценариев; - диаграммы модулей; - диаграммы процессов; - спецификации классов, объектов, атрибутов и операций; - заготовки текстов программ; - модель разрабатываемой программной системы. Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций). Взаимодействие с другими средствами и организация групповой работы Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA - для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема. Для управляемой подмодели предусмотрены операции: - загрузка подмодели в память; - выгрузка подмодели из памяти; - сохранение подмодели на диске в виде отдельного файла; - установка защиты от модификации; - замена подмодели в памяти на новую. Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными. |