«Изучение средств автоматизации проектирования и разработки корпоративных систем»

Государственное автономное профессиональное образовательное учреждение Иркутской области

«Ангарский техникум строительных технологий»

«Изучение средств автоматизации проектирования и разработки

корпоративных систем»

Методические рекомендации к практическим занятиям и самостоятельной работе по междисциплинарному курсу «Информационные технологии и платформы разработки информационных систем»

Ангарск, 2015г.

Рассмотрено на заседании методического совета

Протокол № ____ от ______________

Председатель совета,

зам.директора по УМР

_______________

УТВЕРЖДАЮ

Директор АТСТ

____________/В.Н. Леснов/

«___»_____________20___г.

Составитель:

Дорош Е.Г., преподаватель информатики

Рецензент:

Лихтер Ирина Исаевна преподаватель информатики высшей квалификационной категории, зав. отделением СПО ГБОУ СПО «Ангарский автотранспортный техникум»

СОДЕРЖАНИЕ

Пояснительная записка

4

Учебно-тематический план

5

Глоссарий

5

1. основные понятия корпоративных систем

6

1.1 Этапы проектирования КИС:

6

1.2 процесс разработки информационной системы

7

1.3 Назначение и разновидности CASE-систем

9

1.4 Paradigm Plus

8

1.5 Rational Rose

14

2. Методика выполнения

22

2.1 Задание 1. Создание действующих лиц в среде Rational Rose

22

2.2 Задание 2. Создание вариантов использования в среде Rational Rose

23

2.3 Задание 3. Добавление описаний к вариантам использования

12

2.3 Задание для самостоятельного выполнения

29

2.4 Контрольные вопросы

30

Список литературы

31

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

Методические указания к практическим занятиям и для самостоятельной работы разработаны в соответствии с рабочей программой междисциплинарного курса «Информационные технологии и платформы разработки информационных систем», федеральными государственными стандартами для обучающихся 2-4 курса.

В работе рассматриваются основные возможности MS Visio, прилагаются упражнения по практическому применению рассмотренных функций. Методическое пособие может быть рекомендовано для студентов СПО специальностей «Информационные системы в строительстве», изучающих профессиональный модуль «Участие в разработке информационных систем»

Методические указания предназначены для изучения темы «Изучение средств автоматизации проектирования и разработки корпоративных систем», содержание которой позволяет изучить:

— средства автоматизации проектирования и разработки корпоративных систем: Rational Rose, Paradigm Plus, SELECT.

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

Новизна данного методического указания заключается в том, что её содержание выстроено под содержание учебной программы для образовательных учреждений среднего профессионального образования.

Цель методических указаний научить обучающихся создавать, редактировать, оформлять, сохранять, передавать информационные объекты различного типа с помощью современных информационных технологий.

Данная методическая разработка содержит учебно-тематический план междисциплинарного курса «Информационные технологии и платформы разработки информационных систем», пошаговое выполнение работ, список используемой литературы.

Уровень качества усвоения знаний обучающихся оценивается в рамках экзамена.

УЧЕБНО-ТЕМАТИЧЕСКИЙ ПЛАН ПРАКТИЧЕСКИХ ЗАНЯТИЙ И САМОСТОЯТЕЛЬНЫХ РАБОТ ПО междисциплинарному курсу «Технологии публикации цифровой мультимедийной информации»»

Тема 1.4. Средства автоматизации проектирования корпоративных систем. Особенности платформы Microsoft .NET для разработки корпоративных систем

Содержание

12

100-101

Основные типы и классификация средств автоматизации проектирования и разработки корпоративных систем. Корпоративные сети. Этапы жизненного цикла корпоративных систем.

102-103

Средства автоматизации проектирования и разработки корпоративных систем, их основные типы и классификация.Этапы жизненного цикла поддерживаемые ими.

104-405

Работа по курсовому проектированию. Описание исследовательской части

406-107

Особенности платформы Microsoft .NET для разработки корпоративных систем. Программная платформа Microsoft.NET;

108-109

Работа по курсовому проектированию. Описание исследовательской части

110-111

Характеристики, много-профильность платформы, ее использование при производстве промышленных корпоративных систем.

Практические занятия

10

112-113

Изучение средств автоматизации проектирования и разработки корпоративных систем (Rational Rose, Paradigm Plus, SELECT)

114-115

Применение средств автоматизации проектирования и разработки корпоративных систем (Rational Rose, Paradigm Plus, SELECT)

116-117

Анализ и оценка средств автоматизации проектирования и разработки корпоративных систем.

118-119

Оценка программной платформы Microsoft .NET для промышленного производства корпоративных систем

120-121

Использование программной платформы Microsoft.NET при разработке промышленных корпоративных систем.

122-123

Контрольная работа на тему «Средства автоматизации проектирования корпоративных систем»

2

ГЛОССАРИЙ

Название

Значение

Стандарт DFD

это стандарт моделирования, в котором система представляется в виде сети работ, соединенных между собой объектами, взаимодействующими с результатами данных работ

Модель AS-IS

это модель «как есть», т.е. модель уже существующего процесса/функции.

UML

англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения

Бизнес-процесс

это совокупность взаимосвязанных мероприятий или задач, направленных на создание определённого продукта или услуги для потребителей. 

IDEF0

DEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов.

Модель данных

Базовый инструментарий, обеспечивающий на формальном абстрактном уровне конкретные способы представления объектов и связей.

Модель инфологическая (концептуальная)

Описание предметной области, выполненное с использованием естественного языка, математических выражений, таблиц, графов и других средств, понятных всем сотрудникам, работающим над проектированием.

Предметная область

Набор объектов, представляющих интерес для актуальных или предполагаемых пользователей, когда реальный мир отображается совокупностью конкретных и абстрактных понятий, между которыми фиксируется определенные связи.

1. основные понятия корпоративных систем.

Информационная система (ИС) – это вся инфраструктура предприятия, задействованная в процессе управления всеми информационно-документальными потоками.

Корпоративные информационные системы (КИС) — это интегрированные системы управления территориально распределенной корпорацией, основанные на углубленном анализе данных, широком использовании систем информационной поддержки принятия решений, электронных документообороте и делопроизводстве. КИС призваны объединить стратегию управления предприятием и передовые информационные технологии.

Корпоративная информационная система — это совокупность технических и программных средств предприятия, реализующих идеи и методы автоматизации.

Комплексная автоматизация бизнес процессов предприятия на базе современной аппаратной и программной поддержки может называться по-разному. В настоящее время наряду с названием Корпоративные информационные системы (КИС) употребляются, например, следующие названия:

1.     Автоматизированные системы управления (АСУ);

2.     Интегрированные системы управления (ИСУ);

3.     Интегрированные информационные системы (ИИС);

4.     Информационные системы управления предприятием (ИСУП).

Главная задача КИС — эффективное управление всеми ресурсами предприятия (материально- техническими, финансовыми, технологическими и интеллектуальными) для получения максимальной прибыли и удовлетворения материальных и профессиональных потребностей всех сотрудников предприятия.

КИС по своему составу — это совокупность различных программно-аппаратных платформ, универсальных и специализированных приложений различных разработчиков, интегрированных в единую информационно-однородную систему, которая наилучшим образом решает в некотором роде уникальную задачу каждого конкретного предприятия. То есть, КИС — человеко-машинная система и инструмент поддержки интеллектуальной деятельности человека, которая под его воздействием должна:

  1. Накапливать определенный опыт и формализованные знания;

  2. Постоянно совершенствоваться и развиваться;

  3. Быстро адаптироваться к изменяющимся условиям внешней среды и новым потребностям предприятия.

1.1. Этапы проектирования КИС:

1. Анализ

Обследование и создание моделей деятельности организации, анализ (моделей) существующих КИС, анализ моделей и формирование требований к КИС, разработка плана создания КИС.

2. Проектирование

Концептуальное проектирование, разработка архитектуры КИС, проектирование общей модели данных, формирование требований к приложениям.

  1. Разработка

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

4.Интеграция и тестирование

Интеграция и тестирование приложений в составе системы, оптимизация приложений и баз данных, подготовка эксплуатационной документации, тестирование системы.

5.Внедрение

Обучение пользователей, развертывание системы на месте эксплуатации, инсталляция баз данных, эксплуатация.

6.Сопровождение

Регистрация, диагностика и локализация ошибок, внесение изменений и тестирование, управление режимами работы ИС.

1.2. процесс разработки информационной системы

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

Сам процесс рассматривается с двух точек зрения:

 по содержанию действий разработчиков (групп разработчиков). В данном случае рассматривается статический аспект процесса разработки, описываемый

 в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;

 по времени, или по стадиям жизненного цикла разрабатываемой системы. В данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов.

Информационная система предприятия разрабатывается как некоторый проект. Многие особенности управления проектами и фазы разработки проекта (фазы жизненного цикла) являются общими, не зависящими не только от предметной области, но и от характера проекта (неважно, инженерный это проект или экономический). Поэтому имеет смысл вначале рассмотреть ряд общих вопросов управления проектами.

Проект — это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенными целями, достижение которых определяет завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов и к организационной структуре.

Обычно для сложного понятия (каким, в частности, является понятие проекта) трудно дать однозначную формулировку, которая полностью охватывает все признаки вводимого понятия. Поэтому приведенное определение не претендует на единственность и полноту.

Технология проектирования, разработки и сопровождения интегрированных систем отвечает следующим требованиям:

  1. поддерживать полный жизненный цикл системы;

  2. обеспечивать гарантированное достижение целей разработки системы с заданным качеством и в установленное время;

  3. обеспечивать возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;

  4. обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на части, разрабатываемые группами ограниченной численности с последующей интеграцией составных частей);

  5. обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами;

  6. обеспечивать получение эффективной и работоспособной интегрированной автоматизированной системы обработки данных за минимальное время;

  7. предусматривать возможность управления конфигурацией проекта, версиями проекта и его составляющих;

  8. обеспечивать независимость выполняемых проектных решений от средств реализации системы.

Очевидным является то, что реальное применение любой технологии проектирования, разработки и сопровождения интегрированной системы в конкретной организации невозможно без выработки ряда стандартов, которые должны соблюдаться всеми участниками создания проекта.

К таким стандартам относятся:

  • стандарт проектирования;

  • стандарт оформления проектной документации;

  • стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

правила фиксации проектных решений на диаграммах, в том числе правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;

— требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки средств разработки, общие настройки проекта;

— механизм обеспечения совместной работы над проектом, в том числе правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость.

Стандарт оформления документации должен устанавливать:

комплектность, состав и структуру документации на каждой стадии проектирования;

требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц);

правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

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

требования к настройке средств разработки для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса должен устанавливать:

  • правила оформления экранов;

  • состав и расположение окон и элементов управления;

  • правила использования периферийных устройств;

  • правила оформления текстов помощи;

  • перечень стандартных сообщений;

  • павила обработки реакции пользователя.

1.3. Назначение и разновидности CASE-систем

CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла программного обеспечения и обладающее следующими основными характерными особенностями:

  1. мощные графические средства для описания и документирования информационных систем, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

  2. интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки информационных систем;

  3. использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл программного обеспечения) содержит следующие компоненты;

  1. репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;

  2. графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ER-диаграмма и др.), образующих модели информационных систем;

  3. средства разработки приложений, включая языки 4GL и генераторы кодов;

  4. средства конфигурационного управления;

  5. средства документирования;

  6. средства тестирования;

  7. средства управления проектом;

  8. средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла информационных систем (toolkit) и полностью интегрированные средства, поддерживающие весь жизненный цикл информационных систем и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по сле-дующим признакам:

  1. применяемым методологиям и моделям систем и БД;

  2. степени интегрированности с СУБД;

  3. доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

  1. средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

  2. средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

  3. средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

  4. средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun;

  5. средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ER-диаграмм входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке Си++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

  1. средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

  2. средства конфигурационного управления (PVCS (Intersolv));

  3. средства тестирования (Quality Works (Segue Software));

  4. средства документирования (SoDA (Rational Software

1.4. Paradigm Plus

Первый объектно-ориентированный инструментарий для анализа и проектирования ИС, который обеспечивает полностью интегрированное моделирование бизнес-процессов, физическое моделирование, баз данных и объектное моделирование. Такая интеграция дает возможность менеджерам, администраторам, разработчикам и проектировщикам БД взаимодействовать друг с другом, согласовывать требования и разрабатывать прикладные программы.

Paradigm Plus предназначен для поддержки инфраструктуры разработки прикладных систем, компонентной разработки ИС корпоративного уровня, компонентного моделирования ИС предприятия, объектно-ориентированного анализа и проектирования ИС, моделирования бизнес-процессов, моделирования физической структуры БД.

Основные характеристики Paradigm Plus

  1. Интенсивная поддержка групповой разработки ИС

  2. Совместное межпроектное использование программных компонент на основе репозитария Paradigm Plus и сети Web

  3. Автоматическая генерация объектного кода

  4. Прямое и обратное проектирование (round-trip engineering) без потери данных и без использования маркеров кода

  5. Генерация документации и отчетов

  6. Автоматическое отображение объектных моделей по существующим таблицам реляционных БД и наоборот

Использование Paradigm Plus дает следующие преимущества:

Эволюция прикладных программ ИС синхронизирована с темпом изменений бизнес-требований, поскольку бизнес-модели лежат в основе и «управляют» разработкой проекта ИС

Поддерживается согласованность между:

— моделированием бизнес-процессов

— моделями используемых прецедентов (use case) 

— объектно-ориентированным моделированием 

— моделированием баз данных 

— сценариями тестирования 

Такая поддержка гарантирует корректную реализацию бизнес-требования заказчика

Уменьшается риск неудачи разработки ИС за счет улучшения организационного взаимодействия, основанного на использовании единственного инструмента моделирования для бизнес-моделирования, для объектно-ориентированного анализа и проектирования (например, с использованием нотаций UML, OMT, Fusion, Booch, Martin/Odell, Shlaer/Mellor, and Coad/Yourdon), для физического моделирования баз данных

Уменьшаются издержки сопровождения ИС, поскольку методика циклического проектирования позволяет проводить итерационную разработку ИС, что упрощает документирование и модификацию программ, а также обеспечивает консервацию (сохранение) прикладных программ уже существующей ИС

Улучшается производительность разработчиков и уменьшаются издержки за счет параллельной разработки модулей, совместного и повторного использования компонент, хранимых в репозитарии Paradigm Plus и доступных программистам через средства Web

Сокращается время поставки программ заказчику за счет итерационной разработки и автоматизированной поддержки компонентной сборки приложений, за счет синхронизации модели проекта и кода, автоматической генерации объектного кода прикладных программ

Требования к системе:

Windows NT, Windows 95, OS/2, Sun Solaris, HP-UX, AIX, IRIX 
Платформа PC: 90 MB hard disk space, 24 MB RAM (32 MB recommended) 
Платформа UNIX: 80 MB of hard disk space, 32 MB RAM (64 MB recommended)

1.5. Rational Rose

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.

Структура и функции

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для Си++, обеспечивающий реинжиниринг — восстановление модели проекта по исходным текстам программ.

Репозиторий представляет собой объектно-ориентированную базу данных. Средства просмотра обеспечивают «навигацию» по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.

Средства автоматической генерации кодов программ на языке Си++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке Си++. Анализатор кодов Си++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на Си++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу. Например, можно определить типы исходных файлов, базовый компилятор, задать, какая информация должна быть включена в формируемую модель и какие элементы выходной модели следует выводить на экран. Таким образом, Rational Rose/Си++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

  1. диаграммы классов;

  2. диаграммы состояний;

  3. диаграммы сценариев;

  4. диаграммы модулей;

  5. диаграммы процессов;

  6. спецификации классов, объектов, атрибутов и операций

  7. заготовки текстов программ;

  8. модель разрабатываемой программной системы.

Последний из перечисленных документов является текстовым файлом, содержащим всю необходимую информацию о проекте (в том числе необходимую для получения всех диаграмм и спецификаций).

Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы.

Взаимодействие с другими средствами и организация групповой работы

Rational Rose интегрируется со средством PVCS для организации групповой работы и управления проектом и со средством SoDA — для документирования проектов. Интеграция Rational Rose и SoDA обеспечивается средствами SoDA.

Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать категория классов или подсистема.

Для управляемой подмодели предусмотрены операции:

  1. загрузка подмодели в память;

  2. выгрузка подмодели из памяти;

  3. сохранение подмодели на диске в виде отдельного файла;

  4. установка защиты от модификации;

  5. замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интеграции Rational Rose со специальными средствами управления конфигурацией и контроля версий (PVCS). В этом случае защита от модификации устанавливается на все управляемые подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае признак защиты от записи устанавливается для файлов, которые содержат подмодели, поэтому при считывании «чужих» подмоделей защита их от модификации сохраняется и случайные воздействия окажутся невозможными.

Среда функционирования

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Для работы системы необходимо выполнение следующих требований:

  1. Платформа Windows — процессор 80386SX или выше (рекомендуется 80486), память 8Mб (рекомендуется 12Mб), пространство на диске 8Mб + 1-3Mб для одной модели.

  2. Платформа UNIX — память 32+(16*число пользователей)Mб, пространство на диске 30Mб + 20 при инсталляции + 1-3Mб для одной модели.

Совместимость по версиям обеспечивается на уровне моделей.

Назначение элементов экрана интерфейса Rose:

Браузер (browser) — используется для быстрой навигации по модели. C помощью браузера можно добавлять к модели элементы, просматривать существующие элементы модели и связи между ними, перемещать и переименовывать элементы модели, добавлять элементы модели к диаграмме, группировать элементы в пакеты, связывать элемент с файлом или адресом Интернета, работать с детализированной спецификацией элемента, открывать диаграмму. Браузер поддерживает четыре представления (view): представ­ление вариантов использования, компонентов, размещения и логическое представление.

Окно документации (documentation window) – применяется для работы с текстовым описанием элементов модели. C его помощью можно документировать элементы модели Rose. Например, можно сделать краткое описание каждого действующего лица. При документировании класса все, что будет написано в окне документации, появится затем как комментарий в сгенерированном коде. Документация будет выводиться также в отчетах, создаваемых в среде Rose.

Панели инструментов (toolbars) — применяются для быстро­го доступа к наиболее распространенным командам. Панели инструментов Rose обеспечивают быстрый доступ к наиболее распространенным командам. B этой среде существу­ют два типа панелей инструментов: стандартная панель и панель диаграммы. Стандартная панель видна всегда, ее кнопки соот­ветствуют командам, которые могут использоваться для работы с любой диаграммой. Панель диаграммы своя для каждого типа диаграмм UML.

Все панели инструментов могут быть изменены и настроены пользователем. Для этого используется пункт меню Tools ­ Options, затем вкладку Toolbars.

Окно диаграммы (diagram window) — используется для просмотра и редактирования одной или нескольких диаграмм UML. B нем показано, как выглядит диаграммы UML-модели. При внесении в элементы диаграммы изменений Rose автоматически обновит браузер. Аналогично при внесении изменений в элемент с помощью браузера Rose автоматически обновит соответствующие диаграммы. Это помогает поддерживать модель в непротиворечивом состоянии.

Журнал (log) — применяется для просмотра ошибок и отче­тов о выполнении различных команд. По мере работы над моделью определенная информация будет направляться в окно журнала. Например, туда помещаются сообщения об ошибках, возникающих при генерации кода. Не существует способа закрыть журнал совсем, но его окно может быть минимизировано.

На рис.1 показаны различные части интерфейса Rose.

Рис.1. Интерфейс Rose

Четыре представления модели Rose

В модели Rose поддерживаются четыре представления — это представление вариантов использования, логическое представле­ние, представление компонентов и представление размещения. Каж­дое из них предназначено для своих целей.

Представление вариантов использования содер­жит всех действующих лиц, все варианты использования и их ди­аграммы для конкретной системы. Оно может также содержать некоторые диаграммы последовательности и кооперативные ди­аграммы. На рис.2 изображено представление вариантов ис­пользования в браузере Rose.

Представление вариантов использования содержит:

  1. Действующих лиц.

  2. Варианты использования.

  3. Документацию по вариантам использования, описывающую происходящие в них процессы (потоки событий), включая обработку ошибок. Эта пиктограмма соответствует внешнему файлу, прикрепленному к модели Rose.

  4. Диаграммы вариантов использования. Обычно у системы бывает несколько таких диаграмм, каждая из которых показывает подмножество действующих лиц и/или вариантов использования.

  5. Пакеты, являющиеся группами вариантов использования и/или действующих лиц.

Рис.2. Представление вариантов использования

Логическое представление (рис. 3) показывает, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей системы и описывает взаимодействие этих частей. Логи­ческое представление включает конкретные классы, диаграммы классов и диаграммы состояний. С их помощью конструируется детальный проект создаваемой системы.

Рис. 3 Логическое представление системы

Логическое представление содержит:

  1. Классы.

  2. Диаграммы классов. Как правило, для описания системы используется несколько диаграмм классов, каждая из которых отображает некоторое подмножество всех классов системы.

  3. Диаграммы взаимодействия, применяемые для отображе­ния объектов, участвующих в одном потоке событий варианта использования.

  4. Диаграммы состояний.

  5. Пакеты, являющиеся группами взаимосвязанных классов.

Представление компонентов содержит:

  • Компоненты, являющиеся физическими модулями кода.

  • Диаграммы компонентов.

  • Пакеты, являющиеся группами связанных компонентов.

Представление размещения — это последнее пред­ставление Rose. Оно соответствует физическому размещению си­стемы, которое может отличаться от ее логической архитектуры.

В представление размещения входят:

  1. Процессы, являющиеся потоками (threads), исполняемыми в отведенной для них области памяти.

  2. Процессоры, включающие любые компьютеры, способные обрабатывать данные. Любой процесс выполняется на одном или нескольких процессорах.

  3. Устройства, т.е. любая аппаратура, не способная обраба­тывать данные (например, терминалы ввода-вывода и принтеры).

  4. Диаграмма размещения.

Параметры настройки отображения (изображение атрибутов и операций на диаграммах классов)

В Rose имеется возможность настроить диаграммы классов так, чтобы:

  1. Показывать все атрибуты и операции.

  2. Скрыть операции/ Скрыть атрибуты.

  3. Показывать только некоторые атрибуты или операции.

  4. Показывать операции вместе с их полными сигнатурами или только их имена.

  5. Показывать или не показывать видимость атрибутов и опе­раций.

  6. Показывать или не показывать стереотипы атрибутов и операций.

Значения каждого параметра по умолчанию можно задать с помощью окна, открываемого при выборе пункта меню Tools Options.

Существуют два способа изменения параметров представле­ния атрибутов на диаграмме. Можно установить нужные значе­ния у каждого класса индивидуально. Можно также изменить значения нужных параметров по умолчанию до начала создания диаграммы классов. Внесенные таким образом изменения повли­яют только на вновь создаваемые диаграммы.

Дня переключения между нотациями видимости Rose и UML:

  1. В меню модели выберите пункт Tools Options.

  2. Перейдите на вкладку Notation.

  3. Для переключения между нотациями воспользуйтесь пере­ключателем Visibility as Icons. Если этот переключатель помечен, будет использоваться нотация Rose, в противном случае — нота­ция UML. Изменение этого параметра повлияет только на новые диаграммы. Существующие диаграммы классов останутся пре­жними.

2. Методика выполнения

1. Выберите пункт Tools Options и откройте вкладку Toolbars.

Чтобы сделать видимой или невидимой стандартную па­нель инструментов, пометьте (или снимите пометку) контрольный переключатель show standard Тоо1Bar (или show Diagram ToolBar).

2. Увеличьте размер кнопок на панели инструментов:

— Щелкните правой кнопкой мыши по требуемой панели.

— Выберите во всплывающем меню пункт Use Large Buttons (Использовать большие кнопки), вернитесь к нормальному размеру кнопок.

3. Настройте панель инструментов:

1. Щелкните правой кнопкой мыши по панели диаграммы Main пакета Use Case View.

2. Выберите пункт Customize (настроить) и добавьте несколько кнопок.

Чтобы добавить или удалить кнопки, выберите соответствующую кнопку и затем щелкните мышью по кнопке Add (доба­вить) или Remove (удалить).

Задание 1. Построить диаграммы вариантов использования для определения основных функций будущей системы.

Создание действующих лиц в среде Rational Rose

Действующие лица:

Student (Студент) — записывается на курсы.

Professor (Профессор) — выбирает курсы для преподавания.

Registrar (Регистратор) — формирует учебный план и ката­лог курсов, ведет все данные о курсах, профессорах и студентах.

Billing System (Расчетная система) — получает от данной системы информацию по оплате курсов.

Course Catalog (Каталог курсов) — передает в систему ин­формацию из каталога курсов, предлагаемых университетом.

Для того чтобы поместить действующее лицо в браузер:

  1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.

  2. Выберите пункт New Actor в открывшемся меню.

  3. В браузере появится новое действующее лицо под названи­ем NewClass. Слева от его имени вы увидите пиктограмму действующего лица UML.

  4. Выделив новое действующее лицо, введите его имя.

  5. После создания действующих лиц сохраните модель под именем coursereg (analysis) с помощью пункта меню File Save.

Задание 2. Создание вариантов использования в среде Rational Rose

Для того чтобы поместить вариант использования в браузер:

  1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.

  2. Выберите в появившемся меню пункт New Use Case.

  3. Новый вариант использования под названием NewUseCase появится в браузере. Слева от него будет видна пиктограмма ва­рианта использования UML.

  4. Выделив новый вариант использования, введите его назва­ние.

  5. Результат выполнения упражнения показан на рис.4.

Диаграмма вариантов использования

Создайте диаграмму вариантов использования для системы регистрации. Требуемые для этого действия подробно перечис­лены далее. Готовая диаграмма вариантов использования изображена на рис.5.

В среде Rose диаграммы вариантов использования создают­ся в представлении вариантов использования. Главная диаграм­ма (Main) предлагается по умолчанию. Для моделирования сис­темы можно затем разработать необходимое количество допол­нительных диаграмм.

Рис.4. Представление вариантов использования в браузере

Для того чтобы получить доступ к главной диаграмме вариан­тов использования:

1. Откройте данное представление, щелкнув по значку «+» рядом с представлением вариантов использования в браузере.

2. Откройте главную диаграмму, дважды щелкнув мышью. Строка заголовка изменится, включив фразу [Use Case Diagram: Use Case view / Main].

Для создания новой диаграммы вариантов использования:

  1. Щелкните правой кнопкой мыши по пакету представления вариантов использования в браузере.

  2. Выберите пункт New Use Case Diagram из всплывающего меню.

  3. Выделив новую диаграмму, введите ее имя.

  4. Дважды щелкните по названию этой диаграммы в браузе­ре, чтобы открыть ее.

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

Задание 3. Добавление описаний к вариантам использования

1. Выделите в браузере вариант использования Register for Courses.

2. В окне документации введите следующее описание к этому варианту использования: «This use case allows а student to register for courses in the current semester» («Этот вариант использования дает студенту возможность зарегистрироваться на курсы в теку­щем семестре»).

3. Создайте с помощью MS Word три текстовых файла с опи­саниями вариантов использования Login (Войти в систему), Register for Courses (Зарегистрироваться на курсы) и Close Registration (Закрыть регистрацию).

Вариант использования Login

Краткое описание. Данный вариант использования описыва­ет вход пользователя в систему регистрации курсов.

Основной поток событий

Данный вариант использования начинает выполняться, ког­да пользователь хочет войти в систему регистрации курсов.

  1. Система запрашивает имя пользователя и пароль.

  2. Пользователь вводит имя и пароль.

  3. Система проверяет имя и пароль, после чего открывается доступ в систему.

Альтернативные потоки

Неправильное имя/пароль. Если во время выполнения Основного потока обнаружится, что пользователь ввел неправильное имя и/или пароль, система выводит сообщение об ошибке. Пользователь может вернуться к началу Основного потока или отказаться от входа в систему, при этом выполнение варианта использования завершается.

Предусловия

Отсутствуют.

Постусловия

Если вариант использования выполнен успешно, пользователь входит в систему. В противном случае состояние системы не из­меняется.

Вариант использования Register for Courses

Краткое описание. Данный вариант использования позволяет студенту зарегистрироваться на конкретные курсы в текущем се­местре. Студент может изменить свой выбор (обновить или уда­лить курсы), если изменение выполняется в установленное время в начале семестра. Система каталога курсов предоставляет спи­сок всех конкретных курсов текущего семестра.

Основной поток событий

Данный вариант использования начинает выполняться, ког­да студент хочет зарегистрироваться на конкретные курсы или изменить свой график курсов.

  • Система запрашивает требуемое действие (создать, обно­вить, удалить график).

  • Когда студент указывает действие, выполняется один из под­чиненных потоков (создать, обновить, удалить или принять график).

Создать график

  • Система выполняет поиск в каталоге курсов доступных кон­кретных курсов и выводит их список.

  • Студент выбирает из списка 4 основных и 2 альтернативных курса.

  • После выбора система создает график студента.

  • Выполняется подчиненный поток «Принять график».

Обновить график

  • Система выводит текущий график студента.

  • Система выполняет поиск в каталоге курсов доступных кон­кретных курсов и выводит их список.

  • Студент может обновить свой выбор курсов, удаляя или добавляя конкретные курсы.

  • После выбора система обновляет график.

  • Выполняется подчиненный поток «Принять график».

Удалить график

  • Система выводит текущий график студента.

  • Система запрашивает у студента подтверждения удаления графика.

  • Студент подтверждает удаление.

  • Система удаляет график. Если график включает конкрет­ные курсы, на которые записался студент, он должен быть уда­лен из списков этих курсов.

Принять график

Для каждого выбранного, но еще не «зафиксированного» кон­кретного курса в графике система проверяет выполнение студен­том предварительных требований (прохождение определенных курсов), факт открытия конкретного курса и отсутствие конф­ликтов графика. Затем система вносит данные о студенте в список выбранного конкретного курса. Курс фиксируется в графике, и график сохраняется в системе.

Альтернативные потоки

Сохранить график

В любой момент студент может вместо принятия графика со­хранить его. В этом случае шаг «Принять график» заменяется на следующий:

1. «Незафиксированные» конкретные курсы помечаются в графике как «выбранные».

2. График сохраняется в системе.

Не выполнены предварительные требования, курс заполнен или имеют место конфликты графика.

Если во время выполнения подчиненного потока «Принять гра­фик» система обнаружит, что студент не выполнил необходимые предварительные требования, или выбранный им конкретный курс заполнен, или имеют место конфликты графика, то выдается сообщение об ошибке. Студент может либо выбрать другой конкретный курс и продолжить выполнение варианта использования, либо со­хранить график, либо отменить операцию, после чего основной поток начнется с начала.

График не найден. Если во время выполнения подчиненных потоков «Обновить график» или «Удалить график» система не может найти графин студента, то выдается сообщение об ошиб­ке. После того как студент подтвердит это сообщение, основной поток начнется с начала.

Система каталога курсов недоступна. Если окажется, что не­возможно установить связь с системой каталога курсов, то будет выдано сообщение об ошибке. После того как студент подтвер­дит это сообщение, вариант использования завершится.

Регистрация на курсы закончена. Если в самом начале выполнения варианта использования окажется, что регистрация на те­кущий семестр закончена, будет выдано сообщение, и вариант использования завершится.

Удаление отменено. Если во время выполнения подчиненно­го потока «Удалить график» студент решит не удалять его, уда­ление отменяется, и основной поток начнется сначала.

Предусловия

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

Постусловия

Если вариант использования завершится успешно, график студента будет создан, обновлен или удален. В противном случае состояние системы не изменится.

Вариант использования Close Registration

Краткое описание. Данный вариант использования позволяет регистратору закрывать процесс регистрации. Конкретные кур­сы, на которые не записалось достаточного количества студен­тов, отменяются. В расчетную систему передается информация о каждом студенте по каждому конкретному курсу, чтобы студен­ты могли оплатить курсы.

Основной поток событий

Данный вариант использования начинает выполняться, когда регистратор запрашивает прекращение регистрации.

  • Система проверяет состояние процесса регистрации. Если регистрация еще выполняется, выдается сообщение, и вариант использования завершается.

  • Для каждого конкретного курса система проверяет, ведет ли его какой-либо профессор и записалось ли на него не менее трех студентов. Если эти условия выполняются, система фикси­рует конкретный курс в каждом графике, который включает данный курс.

  • Для каждого студенческого графика проверяется наличие в нем максимального количества основных курсов; если их недо­статочно, система пытается дополнить альтернативными курса­ми из списка данного графика. Выбирается первый доступный альтернативный курс. Если таких курсов нет, то никакое допол­нение не происходит.

  • Система закрывает все конкретные курсы. Если в каком-либо конкретном курсе оказывается менее трех студентов (с уче­том добавлений, сделанных в п.3), система отменяет его и исклю­чает из каждого содержащего его графика.

  • Система рассчитывает плату за обучение для каждого сту­дента в текущем семестре и направляет информацию в расчет­ную систему. Расчетная система посылает студентам счета для оплаты с копией их окончательных графиков.

Альтернативные потоки

Конкретный курс никто не ведет. Если во время выполнения основного потока обнаруживается, что некоторый конкретный курс не ведется никаким профессором, то этот курс отменяется. Система исключает данный курс из каждого содержащего его графика.

Расчетная система недоступна. Если невозможно установить связь с расчетной системой, спустя некоторое установленное вре­мя система вновь попытается связаться с ней. Попытки будут повторяться до тех пор, пока связь не установится.

Предусловия

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

Постусловия

Если вариант использования завершится успешно, регистрация закрывается. В противном случае состояние системы не изменится.

Задание для самостоятельного выполнения.

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

Контрольные вопросы

1.Что называется корпоративными информационными системами.

2. Какие этапы используются при проектировании КИС?

3. Какие функции выполняет программа Paradigm Plus?

4. Какие функции выполняет программа

Список рекомендуемой литературы

  1. Н.З., Емельянова Т.Л., Партыка, И.И.Попов Проектирование информационных систем: учебник, М.:ФОРУМ,2014.-432с.

  2. Электронный ресурс СОВРЕМЕННЫЕ КОМПЬЮТЕРНЫЕ ТЕХНОЛОГИИ ДЛЯ ДЕТЕЙ: http://www.modern-computer.ru/practice/macromedia-flash/prcatic-macromedia-flash-mx.html.

  3. Электронный ресурс Использование ADOBE® FLASH® PROFESSIONAL CS5http://bourabai.ru/library/flash_cs5_help.pdf

  4. http://iablov.narod.ru/igupit/kislec.htm#_Toc151864572

  5. http://www.interface.ru/logworks/paradigm.htm

27

Легко учиться!