Информационные системы. Использование CASE-средств при описании бизнес-процессов: Методические указания к выполнению лабораторных работ N1-7

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Ãîñóäàðñòâåííîå îáðàçîâàòåëüíîå ó÷ðåæäåíèå âûñøåãî ïðîôåññèîíàëüíîãî îáðàçîâàíèÿ ÑÀÍÊÒ-ÏÅÒÅÐÁÓÐÃÑÊÈÉ ÃÎÑÓÄÀÐÑÒÂÅÍÍÛÉ ÓÍÈÂÅÐÑÈÒÅÒ ÀÝÐÎÊÎÑÌÈ×ÅÑÊÎÃÎ ÏÐÈÁÎÐÎÑÒÐÎÅÍÈß

ИНФОРМАЦИОННЫЕ СИСТЕМЫ Использование CASE-средств при описании бизнес-процессов Методические указания к выполнению лабораторных работ № 1–7

Ñàíêò-Ïåòåðáóðã 2005

Составители: А. Г. Степанов, Т. Ф. Осипова Под ред. канд. техн. наук проф. А. Г. Степанова Рецензент кандидат технических наук доцент Г. В. Преснякова Методические указания посвящены использованию CASE-средств для описания бизнес-процессов. Эти средства необходимы для формализованного описания постановки задачи как основы создания информационной системы. В методических указаниях дается краткая характеристика общих принципов разработки информационных систем для бизнес-процессов при применении CASE-средств Ration Rose и BPwin + ERwin (All Fusion Modeling). Методические указания предназначены для выполнения лабораторных работ по дисциплинам: "Информационное обеспечение и базы данных", "Информационные технологии", а также основной дисциплины "Проектирование информационных систем для специальностей": "Управление качеством", "Менеджмент", "Финансы , денежное обращение и кредит", "Прикладная информатика в менеджменте", "Корпоративные информационные системы в экономике и менеджменте". Выполнив лабораторные работы, студент должен узнать, что такое CASE-средства, какие виды моделей используются для описания бизнес-процессов, а также стандарты UML, IDF0, IDF3. В результате студент должен уметь построить диаграммы, описывающие бизнес-процесс в этих нотациях. Методические указания подготовлены к изданию кафедрой прикладных информационных технологий в экономике и менеджменте и рекомендованы к изданию редакционно-издательским советом Санкт-Петербургского государственного университета аэрокосмического приборостроения. Редактор В. П. Зуева Компьютерный набор и верстка Н. С. Степановой Подписано к печати 06.10.05. Формат 60×84 1/16. Бумага офсетная. Печать офсетная. Усл. печ. л. 2,38. Уч. -изд. л. 2,53. Тираж 300 экз. Заказ № 447

Редакционно-издательский отдел Отдел электронных публикаций и библиографии библиотеки Отдел оперативной полиграфии ГУАП 190000, Санкт-Петербург, ул. Б. Морская, 67

© ГОУ ВПО «Санкт-Петербургский государственный университет аэрокосмического приборостроения», 2005

40

ВВЕДЕНИЕ Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия. В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASEсредствами являются Rational Rose, BPwin, Silverrun, Process Analyst. Моделирование предметной области в этих средствах имеет скорее много общего, чем различий. Основными задачами при моделировании предметной области являются следующие описания: – бизнес-процессов предприятия; – действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия; – бизнес-сущностей; – сценариев выполнения бизнес-функций, подлежащих автоматизации; – состояний бизнес-сущностей; – бизнес-правил. Описания бизнес-процессов используются для описания технологии выполнения производственной задачи, подлежащей автоматизации. На основе описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе). При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). При описании предметной области не следует забывать о моделировании бизнес-правил. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Итак, подводя итог сказанному об описании предметной области при разработке программных систем, отметим следующее: 1. Описание предметной области должно включать не только описание бизнес-процессов, но и описание структуры автоматизируемого предприятия, его действующих лиц, их автоматизируемых функций, документов, связанных с автоматизированными функциями, прочих бизнессущностей, сценариев реализации бизнес-функций и состояний бизнессущностей. 1

2. Модель бизнес-процессов используется для определения бизнес-требований к разрабатываемой системе и выявления всех связей между подразделениями, принимающими участие в решение конкретной задачи. 3. Модель структуры предприятия используется для отражения действующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы. 4. Модели документов, бизнес-сущностей используются при проектировании пользовательского интерфейса, базы данных, формирования альбома выходных форм системы. 5. Модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса. 6. Модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и базы данных системы. 7. Модели бизнес-правил используются при моделировании правил программной системы. Полное и детальное описание предметной области удобно производить с помощью разнообразных CASE-средств. Case-средства Термин CASE – Computer Aided System/Software Engineering используется при автоматизации процесса разработки сложных информационных систем в целом. Появлению CASE-средств предшествовали исследования в области методологии проектирования. Методология определяет этапы и шаги реализации проекта, а также правила использования методов, которыми разрабатывается проект. Метод – это процедура или техника генерации описаний компонентов информационной системы (проектирование потоков и структур данных). Нотация – отображение структуры системы, элементов данных с помощью специальных графических символов. CASE-средства – это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования информационных систем. CASEтехнология, в рамках методологии, включает в себя методы, с помощью которых на основе нотаций строятся диаграммы, поддерживаемые конкретным CASE-средством. CASE-технологии не могут считаться самостоятельными, они только обеспечивают высокую эффективность их применения. 2

Краткая характеристика Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл программного обеспечения. Наиболее трудоемкими этапами разработки информационных систем являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Архитектура CASE-средств Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения и включающее в себя: 1. Репозиторий, являющийся основой CASE-средства. Он представляет собой специализированную базу данных проекта, предназначенную для отображения состояния проектируемой информационной системы в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. В репозитории хранятся описания следующих объектов: проектировщиков и их прав доступа к различным компонентам системы; организационных структур; диаграмм; компонентов диаграмм; связей между диаграммами; структур данных; программных модулей; процедур. 2. Графический редактор, обеспечивающий создание и редактирование в заданной нотации и в интерактивном (диалоговом) режиме элементов диаграмм, связей между ними, диаграмм. В любой момент времени они могут быть распечатаны и включены в техническую документацию проекта. 3

3. Верификатор диаграмм (средство тестирования), служащее для контроля правильности построения диаграмм в заданной методологии проектирования. Его функции: а) диагностика, b) выдача сообщений об ошибках, с) выделение на диаграмме ошибочных элементов. 4. Документатор проекта, позволяющий получать информацию о проектах в виде отчетов. Отчеты могут строиться: а) по времени, b) автору, с) элементам диаграмм, d) диаграмме, е) проекту в целом. 5. Администратор проекта, выполняющий следующие функции: а) инициализация (запуск), b) задание начальных параметров проекта, с) назначение и изменение прав доступа к элементам проекта. 6. Сервис, представляющий собой набор системных утилит по обслуживанию репозитория (архивация и восстановление данных, создание нового репозитория). На рисунке показана архитектура CASE-средства в общем виде. Верификатор диаграмм

Графический редактор диаграмм Репозиторий (словарь данных)

Документатор проекта

Сервис

Администратор проекта

Архитектура CASE-средства Используемые методологии При применении CASE-средств используются методологии структурного и объектно-ориентированного проектирования. Структурное 4

проектирование основано на алгоритмической декомпозиции, а объектноориентированное проектирование основано на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое внимание объектам или субъектам действия. CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML. Представления информационной системы на языке UML: 1. Представление использования – основная часть модели описания системы. 2. Логическое представление – описание функциональных возможностей системы. 3. Компонентное представление – описание структуры и взаимосвязей модулей системы. 4. Представление взаимодействия процессов – описание согласованных действий модулей системы. 5. Представление распределения – описание физической архитектуры системы. Каждое представление состоит из диаграмм, которые строятся из своих нотаций. Для структурного подхода используется методология SADT (Structured Analysis and Design Technique). Главным разработчиком методологии был Дуглас Росс. Он разработал язык структурного анализа, используемого для описания исследуемого объекта. Этот язык лег в основу стандартов семейства IDEF. Их использовали в США по предложению ВВС. В настоящее время семейство IDEF включают: IDEF0 – стандарт функционального моделирования IDEF1Х – стандарт моделирования потоков данных IDEF2 – стандарт динамического моделирования систем IDEF3 – стандарт документирования процессов IDEF4 – стандарт построения объектно-ориентированных систем IDEF5 – стандарт онтологического (принципиального, структурного) исследования систем. Правила оформления лабораторных работ Порядок выполнения работ 1. Выполнить тестовый пример. 5

2. Получить индивидуальное задание. 3. Сдать отчет по заданию. 4. Ответить на вопросы. Результаты выполнения работ После выполнения лабораторной работы должен быть составлен отчет. Содержание отчета: 1. Титульный лист. 2. Название и цель выполнения работы. 3. Описание своей задачи с перечислением того, что выполнено. 4. Письменные ответы на заданные вопросы. Темы лабораторных работ 1. Абитуриент одного из потоков стал студентом одной из групп одного из факультетов вуза. 2. Студент одной из групп изучает дисциплины и сдает экзамены и зачеты. 3. Студент одной из групп записывается на дисциплину к преподавателю одной из кафедр. 4. Преподаватель одной из кафедр одного из факультетов вуза проводит занятия по определенным дисциплинам. 5. Студент одной из групп одного из факультетов вуза изучает дисциплины определенной специальности на определенном курсе. 6. Студент регистрируется в одной из групп определенной специальности одного из факультетов одного из вузов города. 7. Абитуриент одного из потоков сдает экзамены по определенным предметам и получает отметки. 8. На один из складов фирмы поступают товары от различных поставщиков. 9. На один из складов одной из фирм города поступает товар от различных поставщиков. 10. Со складов фирмы выдаются товары от различных поставщиков различным потребителям из различных городов. 11. Со складов различных фирм города выдаются товары различным потребителям из различных городов. 12. Со склада фирмы выдаются товары различных поставщиков и различных производителей различным потребителям различных городов. 6

13. На склад поступают товары различных производителей различных стран от поставщиков различных городов 14. На склады различных фирм города поступает товар различных производителей от различных поставщиков 15. Клиенты делают покупки различных товаров в магазинах торговой фирмы наличными, по карточкам и в кредит. 16. Покупатели магазина делают покупки различных товаров различных производителей и различных поставщиков. 17. Клиенты покупают товар различных производителей в магазинах торговой фирмы наличными, по карточкам и в кредит. 18. В магазине торгуют товарами различного вида, различных производителей и от различных поставщиков. 19. В магазинах торговой фирмы торгуют товарами различного вида, различных производителей и от различных поставщиков. 20. В магазинах торговой фирмы торгуют товарами различного вида наличными, по карточкам и в кредит. 21. В магазине торгуют товарами различного вида, различных производителей и от различных поставщиков наличными, по карточкам и в кредит. 22. В отделе кадров ведется учет подразделений, должностей и сотрудников; в личном деле сотрудника регистрируются приказы и изменения в положении сотрудника. 23. Проекты состоят из разного набора документов; документы учитываются и отправляются заказчику. 24. Транзисторы классифицируются по типу, мощности и конструктиву; ведется учет поступлений и продаж. 25. Радиоэлементы классифицируются по типу, наименованию; ведется учет использования их в проектах. 26. Контролеры определяют качество изделий и ведут журнал учета годных, списанных и дорабатываемых изделий. 27. Контролеры регистрируют результаты тестирования партии изделий в маршрутных листах. 28. Эксперты назначают эталонные значения параметров изделия определенного типа; операторы измеряют параметры каждого изделия. 29. Изделия характеризуются эталонными параметрами, ведется журнал учета отклонений реальных параметров от эталонных. 30. Конденсаторы классифицируются по типу, мощности и конструктиву; ведется учет поступлений и продаж. 7

Лабораторная работа № 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), – средства контроля проекта, – средства сбора статистики – генератор документов. 8

К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг – восстановление модели проекта по исходным текстам программ. Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра обеспечивают "навигацию" по проекту, в том числе: перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент. В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: – диаграммы классов; – диаграммы состояний; – диаграммы сценариев; – диаграммы модулей; – диаграммы процессов; – спецификации классов, объектов, атрибутов и операций; 9

– заготовки текстов программ; – модель разрабатываемой программной системы. Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций). Взаимодействие с другими средствами и организация групповой работы Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA – для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема. Для управляемой подмодели предусмотрены операции: – загрузка подмодели в память; – выгрузка подмодели из памяти; – сохранение подмодели на диске в виде отдельного файла; – установка защиты от модификации; – замена подмодели в памяти на новую. Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании "чужих" подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными. Среда функционирования Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), HewlettPackard (HP UX), IBM RS/6000 (AIX). Для работы системы необходимо выполнение следующих требований: 10

Платформа Windows – процессор 80386SX или выше (рекомендуется 80486), память 8 Mб (рекомендуется 12 Mб), пространство на диске 8Mб + + 1–3 Mб для одной модели. Платформа UNIX – память 32 + (16 * число пользователей) Mб, пространство на диске 30 Mб + 20 при инсталляции + 1–3 Mб для одной модели. Совместимость по версиям обеспечивается на уровне моделей. Технология выполнения работы Запуск программы 1. Вызвать кнопкой Пуск Главное меню. 2. Найти в программах Rational Rose Enterprise Edition и выбрать Rational Rose Enterprise Edition Найти

Выбрать

3. Запустить программу. 4. Программа загрузится и появится окно с набором стандартных проектов. Нажать на Cancel.

11

Ознакомление с интерфейсом CASE – средство Rational Rose имеет простой и понятный пользовательский интерфейс для построения требуемых логических и физических моделей данных. Он зависит от используемой технологии. В любом случае при запуске средства моделирования появляются: – меню; – основная панель инструментов; – панель специальных инструментов; – навигатор моделей.

12

Окно пакета при запуске

Основная панель инструментов содержит следующие главные кнопки: – создание новой модели; – открытие имеющейся модели; – сохранение построенной модели; – копирование модели; – печать модели; – масштабирование. Навигатор модели показывает состав модели по уровням разработки. С его помощью можно легко и быстро переходить от одной модели к другой. Работа с навигатором модели аналогична работе с Проводником системы Windows. Навигатор поддерживает четыре представления: 13

– использования; – логическое; – компонентов; – размещения. Панель специальных инструментов содержит основные кнопки для создания выбранной диаграммы, например для построения диаграммы прецедентов представления использования: – создание субъекта; – создание аспекта; – создание ассоциации субъектов и аспектов; – создание обобщения; Для логического представления: – создание класса; – создание ассоциации классов. Окно модели является местом создания логической или физической модели данных исследуемой системы. Задания 1. Запустить Rational Rose. 2. Посмотреть навигацию по проекту. 3. Создать любой элемент, дать ему название и комментарий к нему. 4. Сохранить проект. Вопросы для самостоятельной работы 1. Что такое Rational Rose? 2. Описать окно. 3. Что такое навигатор? 4. Окно диаграмм. 5. Панель инструментов. 6. Назначение специальной панели инструментов.

14

Лабораторная работа № 2. СОЗДАНИЕ МОДЕЛИ ВАРИАНТОВ

ИСПОЛЬЗОВАНИЯ Цель работы: ознакомиться с созданием функциональной модели использования; изучить нотации, применяемые при построении диаграмм, и освоить их применение в процессе постановки задачи. Основные понятия Моделирование в Ration Rose проводится как спуск от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде диаграмм вариантов использования (Use – case diagram). Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком. Вариант использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел реализовать. Эти диаграммы служат основой для достижения взаимопонимания между программистами-профессионалами, разрабатывающими проект, и заказчиками проекта. Внутри каждого варианта использования (прецедента) могут быть определены: – вложенная диаграмма использования, – диаграмма взаимодействия объектов, – диаграмма последовательности взаимодействия, – диаграмма классов, – диаграмма перехода состояния. Действующее лицо (Actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Действующее лицо может быть внешней системой, которой необходима информация от данной системы. На рис. 2 приводится вариант использования, описывающий одну из функций системы управления проектами – обратную связь между менеджером проекта и исполнителем. 15

Нотации представления использования (диаграмма прецедентов) Каждое представление строится из диаграмм, которые используют свои нотации (обозначения). Для представления использования применяются следующие нотации: – субъект как внешняя сущность, взаимодействующая с системой; им может быть и человек, и устройство, и другая система; Имя

– аспект использования как определенное средство, предоставляемое системой; – односторонняя ассоциация, как взаимодействие, направленное от одного субъекта или аспекта к другим; – обобщение от одного субъекта или аспекта к другому;

Примеры обобщения показаны на рис. 1. Это сильный инструмент построения диаграмм. Так, один клиент, другой клиент обслуживающей фирмы обобщаются в клиента фирмы. Имя Обобщенный аспект

Имя

Обобщенный субъект

Имя

Специальные аспекты

Специальные субъекты

Рис. 1. Обобщения аспектов и субъектов

Пример. Менеджер модифицирует план, назначает ресурс и получает отчеты от исполнителей, сотрудников и субподрядчиков проекта. Информационную систему назовем "Управление проектами". На рис. 2 показаны функции менеджера относительно выполнения проекта.

16

Диаграмма прецедентов Внешняя сущность по отношению к проекту

Одна из функций системы Модифицировать план

Менеджер проекта

Назначить ресурс

Исполнитель

Получить отчет

Сотрудник

Субподрядчик

Рис. 2. Диаграмма использования. Управление проектами

Технология выполнения работы Технологический процесс создания диаграммы прецедентов 1. Подготовка: a. В навигаторе модели открыть Use Case View. b. Там же открыть Main. c. Дать имя диаграмме прецедентов. i. В контекстном меню для Main выбрать команду Rename. ii. Ввести имя диаграммы прецедентов. 2. Создание субъекта: a. Нажать кнопку создания субъекта. b. В окне диаграммы прецедентов указать место субъекта. c. Щелчком вызвать изображение субъекта. d. Ввести имя субъекта. 3. Создание аспекта: a. Нажать кнопку создания аспекта. b. Повторить п.п. 2b, c, d для аспекта. 17

4. Создание ассоциации a. Нажать кнопку создания ассоциации. b. Нарисовать стрелку от одного элемента диаграммы прецедентов к другому. c. Отрегулировать размещение элементов диаграммы прецедентов. Задания для построения представления варианта использования Построить диаграмму прецедентов по разработанному техническому заданию. 1. Присвоить имя диаграмме согласно предметной области и решаемой задаче. 2. Определить субъектов (актеров) и прецедентов и присвоить им имена согласно предметной области. 3. Определить ассоциации между ними. 4. Построить обобщения между субъектами и прецедентами. Вопросы для самостоятельной работы 1. В чем смысл варианта использования? 2. Назначение вариантов использования. 3. Назовите основные компоненты диаграмм вариантов использования. 4. Что такое действующее лицо? 5. Какую роль могут играть действующие лица по отношению к варианту использования? 6. Назначение обобщения. 7. Аспект в диаграмме прецедентов.

18

Лабораторная работа № 3. ДИАГРАММЫ КЛАССОВ

Цель работы: ознакомиться с созданием логической модели информационной системы; изучить нотации, применяемые при построении диаграмм классов и освоить их применение в процессе объектно-ориентированного анализа и проектирования. Основные понятия Диаграммы классов являются центральным звеном методологии объектно-ориентированного анализа и проектирования. Диаграмма класса показывает классы и их отношения, тем самым представляя логический аспект проекта. На стадии анализа диаграммы классов используются, чтобы выделить общие роли и обязанности объектов (сущностей), обеспечивающих требуемое поведение системы, на стадии проектирования – чтобы передать структуру классов, формирующих архитектуру системы. Каждый класс должен иметь имя. Имя каждого класса должно быть уникально в содержащем его проекте. Диаграмма классов определяет этапы объектов системы и различные статистические связи, которые существует между ними. Имеется два основных вида статистических связей: – ассоциации (например, менеджер может вести несколько проектов); – подтипы (работник является разновидностью личности). На диаграммах классов также изображаются атрибуты классов, операции и ограничения, которые накладываются на связи между объектами. Ассоциации представляют собой связи между экземплярами классов (личность работает в компании, компания имеет ряд офисов). Любая ассоциация обладает двумя ролями. Например (рис. 3) – ассоциация между Исполнителем и Отчетом содержит две роли: одна от Исполнителя к Отчету; другая – от Отчета к Исполнителю. Роль также обладает множественностью. Пример – символ "0..*" над ассоциацией между Менеджером и Контрактом показывает, что с одним Менеджером связано много Контрактов. 0 – показывает, что Менеджер может не управлять контрактом; 1 – показывает, что любой Контракт может управляться только одним Менеджером. Для ассоциации может указываться направление навигации, если направление не указывается, то ассоциация двунаправленная или ее направление неизвестно. 19

Атрибуты во многом подобны ассоциациям. Разница между ними заключается в том, что атрибуты предполагают единственное направление навигации – от типа к атрибуту. На рисунке указаны атрибуты для классов Контракт и Отчет. В зависимости от степени детализации диаграммы обозначение атрибута может включать имя атрибута, тип и значение, присваемое по умолчанию. В синтаксисе UML атрибут обозначен: <признак видимости> <имя>: <тип> = <значение по умолчанию>. Признак видимости может принимать следующие значения: – общий (public) – атрибут общий, доступен для всех классов клиентов; – защищенный (protected) – атрибут защищенный, доступен только для подклассов и друзей класса; – секретный (private) – атрибут собственный, доступен только для друзей класса; – реализация (implementation) – атрибут внедренный, доступен внутри обрамляющего пакета. Операции представляют процессы, реализуемые классом. Существует соответствие между операциями и методами над классом. На рис. 3 приведены операции над классом Контракт Закрыть (), над классом Отчет – Добавить(). Нотации логического представления (диаграммы классов) А Ключ

– класс А с известным ключом, набором атрибутов и операциями над объектами,

Атрибуты Операции

k

m

– ассоциация между классами с обозначением возможных видов связи: i. m ∈ {1, n, 0..1, 0..*, 1..*}, ii. k ∈ {1, n, 0..1, *, 0..*, 1..*}. Примечание: Первый атрибут в структуре реляционной таблицы имеет характеристику Ключ, что означает однозначное определение объекта в классе. 20

Пример. Диаграмма классов "Управление проектами". Статическая модель. Все данные о проекте можно свести в реляционную модель. Объекты сведены в классы, классы описываются атрибутами. Каждый класс имеет свое поведение по отношению к выполнению проекта.

К о нтр ак т М е не дж ер про ек та (f ro m U se C a se V i ew )

Ко д м ене д ж ер а Ф ам и ли я Телефо н

1

Назн ачить()

0 ..*

Н ом е р к он тр ак та Д ата зак лю ч ения З а к азчик Д ата ок о нчан ия С то им о с ть З а к рыть ()

1 0..*

Ис п олните ль

О тче т Ном ер отч ета Д ата

(fro m U se C a se V i ew )

0 ..*

0..1

К од ис пон ителя лн ит ел я Им я Ф ор м и ров ать()

С отру дни к (f ro m Use Ca se V i e w)

К о д с отру д н ик а Ф а м и лия Д оба ви ть()

Су бпо др яд ч ик (f ro m U se C a se V i ew )

Ко д с у бпод р яд чи ка Ф ир м а А д ре с Ко нта к тн ое лицо Д обав ить()

Рис. 2. Диаграмма классов. Управление проектами

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

21

Внеш няя су щ нос ть п о отнош ению к проекту

О д на из фу нкций с истемы м од ифицировать план М

М енед жер проекта

Н азначить ресу рс

К од менед ж ера Ф ам илия Телефон

Исп олнитель К од испонителя лните л я И мя

Н азначить() Полу чить отчет

С отруд ник К од сотруд ника Ф амилия Добав ить ()

Ф ормировать()

С убпод ряд чик К од с убпод ряд чика Ф ирма Ад рес К онтактное лицо Добавить()

Рис. 3. Диаграмма прецедентов после создания диаграммы классов

Технология выполнения работы Технологический процесс создания диаграммы классов 1. Подготовка: a. В навигаторе модели открыть Logical View. b. Там же открыть Main. c. Дать имя диаграмме классов. i. В контекстном меню для Main выбрать команду Rename. ii. Ввести имя диаграммы классов. 2. Создание класса: a. Нажать кнопку создания класса. 22

b. В окне диаграммы классов указать место класса. c. Щелчком вызвать изображение класса. d. Ввести имя класса: i. не повторяющееся с именами субъектов диаграммы прецедентов ii. Являющиеся субъектами, их необходимо привести в стандартный для класса вид командой Format/Stereotype Display. 3. Оформить класс: a. В контекстном меню класса выбрать команду New Attribute. b. Ввести имя атрибута. c. Активизировав класс, щелкнуть по значку атрибута. d. В списке выбрать требуемый значок атрибута: public (default) protected private implemented e. В контекстном меню класса выбрать команду New Operation. f. Ввести имя операции. g. Повторить п.п. 2e, iii, iv для операции. 4. Создание ассоциации: a. Нажать кнопку создания ассоциации. b. Нарисовать стрелку от одного класса к другому. c. Отрегулировать размещение классов в диаграмме. 5. Оформить ассоциацию: a. В контекстном меню ассоциации выбрать команду Multiplicity. b. В списке выбрать требуемый вид ассоциации 1 – обязательная однозначная; 0 .. * – Zero or More, необязательная многозначная; 1 .. * – One or More, обязательная многозначная; 0 .. 1 – Zero or One, необязательная однозначная; c. В контекстном меню ассоциации выбрать команду Navigable, убрав "галочку". Задания Построить диаграмму классов для представления использования варианта лабораторной работы 2. 5. Определить объекты (сущности), привязав их к диаграмме прецедентов. 23

a. Дать имя классу для однотипной группы объектов, например объекты Менеджеры можно поместить в класс Менеджер. b. Назначить атрибут – ключ (идентификатор объекта), например для объекта Менеджер – это может быть Код менеджера. c. Указать основную операцию над классом, например для класса Менеджер – Добавить(). 6. Построить отношения между классами на основе ассоциаций a. Определить направление и множественность, указав нижние и верхние границы. Вопросы для самостоятельной работы 1. Назначение диаграммы классов. 2. Для чего используется диаграмма классов на стадии анализа? 3. Назовите основные компоненты диаграммы классов. 4. Что собой представляет ассоциация? 5. В чем смысл множественной ассоциации? 6. Как описывается класс? 7. Значение характеристики атрибута ключ. 8. Что входит в описание атрибута? 9. Что такое признак видимости? 10. Что представляет собой операция класса?

24

Лабораторная работа № 4. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ

Цель работы: ознакомиться с созданием моделей, описывающих поведение взаимодействующих групп объектов; изучить нотации, применяемые при построении диаграмм взаимодействия и освоить их применение в процессе объектно-ориентированного анализа и проектирования. Основные понятия Диаграммы взаимодействия являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой в рамках одного варианта использования. Пример. Управление проектами (рис. 5) – Менеджер обдумывает поручение отчета исполнителю; – дает указания на создание Отчета Исполнителю; – если Отчет неудовлетворительный, Менеджер посылает – запрос Исполнителю на обновление Отчета; – Исполнитель создает новый Отчет; – Менеджер делает повторный запрос Отчета. Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные, или сотрудничества (collaboration diagrams). Диаграммы последовательности определяют временную последовательность передаваемых сообщений, порядок, вид и тип сообщения, происходящих в рамках варианта использования. Диаграммы последовательности и кооперативные являются разными взглядами на одни и те же процессы, поэтому Rational Rose позволяет создать из диаграммы последовательности диаграмму Кооперации и наоборот, а также производит автоматическую синхронизацию этих диаграмм. На диаграмме последовательности взаимодействие изображается в виде двумерной схемы: вертикальное (время) и горизонтальное (объекты, участвующие во взаимодействии). Существенна только последовательность сообщений, однако временная ось может служить реальной метрикой измерения активности объекта. – Действующие лица из варианта использования. – Объекты, требуемые системе для выполнения варианта использования. 25

– Линии жизни, представляющие фрагмент жизненного цикла объекта в процессе взаимодействия, где течение времени идет сверху вниз, идут сверху. – Активный период линии жизни. – Сообщение, передающееся от одного объекта к другому в порядке следования жизненного цикла, при желании может быть помечено именем и аргументом, управляющим событием, например, сообщение посылается, если Отчет не устарел. – Самоделегирование (рекурсивное сообщение) – сообщение самому себе. На кооперативной диаграмме экземпляры объектов показаны в виде пиктограмм. Линии между ними обозначают сообщения, обмен которыми осуществляется в рамках данного варианта использования. Каждый вид диаграмм имеет свои преимущества. На диаграмме последовательности легче наблюдать порядок, в котором происходят события. В случае кооперативных диаграмм можно использовать пространственное расположение объектов, чтобы показать их статическое взаимодействие. Нотации диаграммы последовательности Объект1: Имя

– Изображение Объекта – Линия жизни – Сообщение – Время активности объекта

– Самоделегирование

– Удаление объекта

26

Изображение диаграммы в виде двумерной схемы Объект1: Имя

Объект2: Имя

Пример. Последовательность действий и кооперация между объектами при создании отчета "Управление проектами".

Менеджер проекта

Исполнитель

Отчет

Рис. 4. Диаграмма последовательности создания отчета "Управление проектами"

27

1: 6: 2: 4:

Исполн и

Менеджер проект проекта а

Исполнитель

5: 3: Отчет

Рис. 5. Кооперативная диаграмма "Управление проектами"

Технология выполнения работы Технологический проц есс создания диаграммы посл едовательности 1. Подготовка: d. В меню выбрать команду Browse/Interaction Diagram/New для вызова окна Select Interaction Diagram. e. В подокне Package окна Select Interaction Diagram выбрать Use Case View, нажать ОК. f. В диалоговом окне New Interaction Diagram в поле Title ввести имя диаграммы последовательности. g. В диалоговом окне New Interaction Diagram выбрать тип диаграммы sequence, нажать ОК. 2. Создание объекта: a. Нажать кнопку создания объекта. b. В окне диаграммы классов указать место объекта. c. Щелчком вызвать изображение объекта и соответствующей ему линии жизни. d. Через контекстное меню открыть окно Object Specification и ввести имя объекта и соответствующий ему класс. 28

3. Создание сообщения: a. Нажать кнопку создания сообщения Object Message. b. Нарисовать стрелку от линии одного объекта к линии жизни другого объекта c. Отрегулировать размещение элементов диаграммы прецедентов. 4. Построение соостветствующей диаграммы кооперации: a. Нажать функциональную клавишу F5. b. Изменить сообщение, вызвав закладку Messages. Задания Построить диаграмму последовательности на основе диаграмм классов и диаграммы представления использования, разработанных на предыдущих занятиях 7. Дать имя диаграмме. 8. Определить объекты, привязав их к диаграмме классов и прецедентов. 9. Создать их линии жизни. 10. Установить сообщения между объектами. 11. Присвоить имена сообщениям. Вопросы для самостоятельной работы 1. Назначение диаграммы взаимодействия. 2. Для чего используется диаграмма последовательности на стадии анализа? 3. Назовите основные компоненты диаграммы последовательности. 4. Что собой представляет жизненная линия? 5. Как на диаграмме последовательности представляются сообщения? 6. Что такое самоделегирование? 7. Что показывает активизация объекта? 8. Как на диаграмме последовательности представляется уничтожение объекта?

29

Лабораторная работа № 5 . ДИАГРАММЫ СОСТОЯНИЯ

Цель работы: ознакомиться с созданием моделей, описывающих поведение взаимодействующих групп объектов; изучить нотации, применяемые при построении диаграмм последовательности и освоить их применение в процессе объектно-ориентированного анализа и проектирования. Общие понятия Диаграммы состояния (Statechart) являются средством описания поведения систем. Они определяют все известные состояния, в которых может находиться объект, а также процесс смены состояния объекта в результате влияния некоторых событий. Существуют два специальных состояния – начальное (start) и конечное (stop). Начальное состояние – состояние объекта, когда он только что создан, конечное – перед его уничтожением. Начальное состояние может быть только одно, а конечных – сколько вам нужно или вообще не быть. Процесс начинается с начальной точки, а затем переходит в состояние. В поведении объекта в системе можно выделить действия, отображаемые переходами, и деятельности, отображаемые состояниями. Действия связаны с переходами и рассматриваются как мгновенные и непрерываемые. Деятельности связаны с состояниями и могут длиться достаточно долго. Деятельность может быть прервана в результате наступления некоторого события. Событие – это то, что вызывает переход из одного состояния в другое.Переход может содержать метку. Метка перехода состоит из трех частей, каждая из которых является необязательной ( < Событие>I <Условие >I/<Действие >). Изображается на диаграмме вдоль линии перехода после имени события. Условный переход. История состояния. Диаграммы состояний хорошо использовать для описания поведения некоторого объекта в нескольких различных вариантах использования, их не надо создавать для каждого класса.

30

Нотации диаграммы состояния Состояние

Do:

Действие

Применение Переход Начальное состояние Конечное состояние

Пример. Получение отчета. Управление проектами. Отчет корректируется

Выдача отчета

Создается новый отчет

Отчет проверяется

Отчет создан

Рис. 6. Диаграмма состояния получения отчета

Технология выполнения работы Технологический процесс создания диаграммы состояния 1. Подготовка: – В меню выбрать команду Browse/Interaction Diagram/New для вызова окна Select Interaction Diagram. 31

– В подокне Package окна Select Interaction Diagram выбрать Logical View, нажать ОК. – В диалоговом окне New Interaction Diagram выбрать тип диаграммы New State Machine Diagram и подтип Statechart, нажать ОК. – В диалоговом окне New State Machine Diagram в поле Title ввести имя диаграммы. 2. Начало и создание диаграммы: – Выбрать объект, использовав кнопку Selection Tool. – В окне диаграммы состояния создать надпись, использовав кнопку TextBox. – вызвать начальное состояние объекта значком Start State. 3. Создание перехода и нового состояния: – Отразить переход в другое состояние, использовав кнопку State Transition. – Отразить состояние, в которое перешел объект, использовав кнопку State. – Ввести имя перехода, использовав кнопку. – Отразить при необходимости переход на себя кнопкой Transition To Self. – Спецификация состояния. – Параметры действия. – Скрытие вложенных состояний. 4. Создание завершения диаграммы: – Отразить переход. – Вызвать завершающее состояние объекта значком EndState. Задания Построить диаграмму состояния на основе диаграмм классов и диаграммы представления использования, разработанных на предыдущих занятиях. 1. Дать имя диаграмме. 2. Выбрать классы, для объектов которых будет строиться диаграмма состояний. 3. Построить для каждого выбранного класса диаграмму состояний, характеризующих поведение его объектов в нескольких вариантах использования.

32

Вопросы для самостоятельной работы 1. Назначение диаграммы состояний. 2. Как отображаются действия и деятельности на диаграммах состояния? 3. Что такое условный переход и как он описывается на диаграмме? 4. Какие особые состояния отображаются на диаграмме? 5. Что такое история состояния? 6. Что такое вложенные состояния и как их используют и создают? 7. В чем преимущества и недостатки диаграммы?

33

Лабораторная работа № 6. ДИАГРАММЫ АКТИВНОСТИ

Цель работы: ознакомиться с созданием моделей, описывающих поведение взаимодействующих групп объектов; изучить нотации, применяемые при построении диаграмм последовательности и освоить их применение в процессе объектно-ориентированного анализа и проектирования. Общие понятия Этот тип диаграмм может использоваться для моделирования различных типов действий. Например, финансовая компания может использовать данный тип диаграмм для моделирования потоков финансовых документов, прохождения оплаты счетов или заказов. Компания, создающая программные продукты, отслеживать процесс разработки и создания программного обеспечения. Диаграммы активности (Activity diagram) – это специальная разновидность диаграмм состояния. Главное отличие между диаграммами активности и состояния в том, что в первом случае основное – действие, а во втором – статичное состояние. Нотации диаграммы последовательности Из набора значков состояний можно составить представление о всем жизненном цикле объекта, у которого есть начало и конец действия работы объекта. Нотации используются те же самые, что и при построении диаграммы состояния, с дополнениями. Добавляются: – Activity – значок активности. Похож на значок состояния State, который обозначает ожидание события, а значок Activity означает действие. – Значки синхронизации. – Decision – решение, позволяет показать зависимость от внешних условий или решений (аналогичен If case в языках программирования). – Swimlanes – плавательные дорожки – моделирование действий различных объектов и связи между ними. Можно моделировать бизнес-процесы организации, отражая на диаграмме различные подразделения и объекты, играющие важные роли в процессе. Для этого необходимо поместить соответствующие значки активности или состоя34

ний в зону определенного подразделения, отделенного от остальных дорожкой. Пример. Алгоритм получения отчета. Управление проектами. Менеджер проекта

Исполнитель

Назначить дату начала и окончания создания отчета Выдать задание Проверить отчет Правильный? Нет Да

Получить задание на работу Создать новый отчет Доработать отчет

Установить дату выдачи проекта Принять отчет

Технология выполнения работы Технологический процесс создания диаграммы активности Подготовка: – В меню выбрать команду Browse/Interaction Diagram/New для вызова окна Select Interaction Diagram. – В подокне Package окна Select Interaction Diagram выбрать Logical View, нажать ОК. – Выбрать в диалоговом окне New Interaction Diagram тип диаграммы New State Machine Diagram и подтип Activity, нажать ОК. – В диалоговом окне New State Machine Diagram в поле Title ввести имя диаграммы. Начало создания диаграммы: – Вызвать начальное состояние объекта значком Start State и 35

состояние Idle. – Соединить их связью и дать название связи. – Перенести значки из созданной диаграммы состояний во вновь созданную нажатием клавиши Ctrl. – Установить дорожки для различных объектов. Создание перехода и нового состояния: – Отразить переход в другое состояние, использовав кнопку State Transition. – Отразить состояние, в которое перешел объект, использовав кнопку State. – Ввести имя перехода, использовав кнопку. – Отразить при необходимости переход на себя кнопкой Transition To Self. – Спецификация состояния. – Параметры действия. – Скрытие вложенных состояний. Настройка спецификаций: – Отразить переход. – Вызвать завершающее состояние объекта значком EndState. Добавление решения. Синхронизация процессов. Задания Построить диаграмму активности на основе диаграммы классов и диаграммы состояния, разработанных на предыдущих занятиях. 4. Дать имя диаграмме. 5. Выбрать классы, для объектов которых будут строиться диаграммы состояний. Построить для выбранных классов диаграмму активности, характеризующую алгоритм выполнения указанной работы. Вопросы для самостоятельной работы 1. 2. 3. 4. 5. 36

Для чего используется диаграмма активности? Какие отличия между диаграммой активности и состояния? Каков состав инструментов в диаграмме активности? Для чего применяются дорожки? Когда применяется элемент решения?

Лабораторная работа № 7. ДИАГРАММЫ ПАКЕТОВ

Цель работы: ознакомиться с созданием диаграмм пакетов, изучить нотации, применяемые при построении диаграмм пакетов, и освоить их применение в процессе объектно-ориентированного анализа и проектирования. Общие понятия Важной задачей систематизации информации о предметной области является разбиение большой системы на небольшие подсистемы. Именно здесь особенно заметны структурные и объектно-ориентированные различия между подходами. Одна из идей заключается в группировке классов в компоненты более высокого уровня. В UML такой механизм группировки носит название пакетов (package). Диаграммой пакетов является диаграмма, содержащая пакеты классов и зависимости между ними. Строго говоря, пакеты являются элементами диаграммы классов, т. е. диаграмма пакетов – это всего лишь диаграмма классов. Отличаются эти диаграммы практическим назначением и использованием. Зависимость между двумя элементами имеет место в том случае, если изменения в определении одного элемента могут повлечь изменения в другом. Что касается классов, то причины зависимостей могут быть разными: · один класс посылает сообщение другому; · один класс включает часть данных другого класса; · один класс ссылается на другой, как на параметр операции. Если класс меняет свой интерфейс, то сообщение, которое он посылает, может стать неправильным. На рис. 8 показаны классы предметной области, возникающие при моделировании деятельности менеджера по управлению проектами. Они сгруппированы в пакеты: контракты, менеджеры, отчеты, исполнители. Приложение Проект имеет связь с пакетами предметной области Менеджеры, Отчеты, Контракты. Приложение Специалисты имеет связь с Исполнителями, через которых можно узнать, какие отчеты они подготовили. Пакеты являются жизненно необходимыми для больших проектов. Особенно когда диаграмма классов, охватывающая всю систему, трудночитаемая. Пакеты не дают ответа на вопрос, каким образом можно уменьшить количество зависимостей в разрабатываемой системе, они 37

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

Пример. Получение отчета "Управление проектами".

Пользовательский интерфейс управление проектами

Приложение Специалисты

Приложение Проекты

Исполнители

Контракты

Менеджеры

Отчеты

Рис. 7. Диаграмма пакетов "Пользовательский интерфейс"

38

Технология выполнения работы Технологический процесс создания диаграммы активности Подготовка: – В меню выбрать команду Browse/ Component Diagram или воспользоваться значком Main вызова окна для построения и соответствующей панели инструментов. – Присвоить имя диаграмме. – Выбрать в диалоговом окне New Interaction Diagram тип диаграммы New State Machine Diagram и подтип Activity, нажать ОК. – В диалоговом окне New State Machine Diagram в поле Title ввести имя диаграммы. Начало создания диаграммы: – Вызвать начальное состояние объекта, значком Start State и состояние Idle. – Соединить их связью и дать название связи. – Перенести значки из созданной диаграммы состояний во вновь созданную нажатием клавиши Ctrl. – Установить дорожки для различных объектов. Создание зависимостей между пакетами: – Отразить переход в другое состояние, использовав кнопку State Transition. – Отразить состояние, в которое перешел объект, использовав кнопку State. – Ввести имя перехода, использовав кнопку. – Отразить при необходимости переход на себя кнопкой Transition To Self. – Спецификация состояния. – Параметры действия. – Скрытие вложенных состояний. Задания Построить для моделируемой системы общую диаграмму пакетов, отметить на ней приложения и зависимости между пакетами.

39

Вопросы для самостоятельной работы 1. Какую проблему призваны решить диаграммы пакетов? 2. В чем отличия диаграмм пакетов от диаграмм классов? 3. В чем смысл зависимости между элементами диаграммы пакетов? 4. Что такое интерфейс класса? 5. По каким признакам классы группируются в пакеты? Библиографический список 1. Хоменко А., Цыганков Л., Мальцев М. Базы данных: Учебник высших и средних учебных заведений. СПб.: КОРОНАпринт, 2000. 416 с. 2. Хансен Г., Хансен Дж. Базы данных: разработка и управление. М.: ЗАО "Издательство БИНОМ", 1999. 704 с. 3. Карпова Т. С. Базы данных: Учебник. СПб.: Питер, 1999. 310 с. 4. Информационные системы в экономике: Учебник / Под ред. В. В. Дика. М.: Финансы и статистика, 1996. 00 с. 5. Смирнов Г. Н. Проектирование экономических информационных систем. М.: Финансы и статистика, 2001. 00 с. 6. Гарнаев А. Office 2000: разработка приложений / Под общ. ред. Ф. Новикова. СПб.: БХВ – Санкт-Петербург, 2000. 656 с. 7. Миронов Д. Создание Web-страниц в MS Office 2000. СПб.: БХВ – Санкт-Петербург, 2000. 320 с. 8. Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. СПб.: Питер, 2002. 656 с. 9. Вендров А. Практикум по проектированию программного обеспечения экономических информационных систем: Учеб. пособие. М.: Финансы и статистика, 2002. 192 с. 10. Кратчен Ф. Введение в Rational Unified Process. М.: Издательский дом "Вильямс", 2002. 240 с 11. Квартрани Т. Rational Rose и визуальное моделирование. М.: ДМК Пресс, 2001. 176 с. 12. Фаулер М., Скотт К. UML. СПб.: Символ-Плюс, 2002. 192 с. 13. Федотова Д. CASE – технологии: Практикум. М.: Горячая линия – Телеком, 2003. 160 с. 14. Маклаков С. BPwin и Erwin. CASE – средства разработки информационных систем. М.: Диалог-МИФИ, 2001. 304 с. 15. Маклаков С. Создание информационных систем с OLLFusion Modeling Suite. M.: Диалог-МИФИ, 2003. 432 с. 40

Содержание Введение ................................................................................................... Темы лабораторных работ ...................................................................... Лабораторная работа № 1. Ознакомление с CASE-средством Rational Rose ......................................... Лабораторная работа № 2. Создание модели вариантов использования ...................................... Лабораторная работа № 3. Диаграммы классов ............................ Лабораторная работа № 4. Диаграммы взаимодействия ............. Лабораторная работа № 5. Диаграммы состояния ........................ Лабораторная работа № 6. Диаграммы активности ...................... Лабораторная работа № 7. Диаграммы пакетов ............................ Библиографический список .....................................................................

1 6 8 15 19 25 30 34 37 40

41