7 Диаграмма взаимодействия

Диаграмма деятельности или как её ещё называют «Последовательности» отображает работу не с классами, а с объектами классов. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии.

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

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

Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов

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

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

Рисунок 12 - Диаграмма взаимодействия

8 Теория о bpWin

BPwin - ведущий инструмент визуального моделирования бизнес-процессов. Дает возможность наглядно представить любую деятельность или структуру в виде модели, что позволит оптимизировать работу организации, проверить ее на соответствие стандартам ISO9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции, повысить гибкость и эффективность. Являясь стандартом де-факто, BPwin поддерживает сразу три нотации моделирования: IDEF0 (федеральный стандарт США), IDEF3 и DFD. Полное (новое) название BPwin: AllFusion Process Modeler Кому нужен BPwin: всем компаниям, желающим добиться оптимальности и эффективности собственного бизнеса или бизнеса заказчиков. Руководителям проектов, бизнес-аналитикам, системным аналитикам, руководителям, маркетологам, консультантам, менеджерам по качеству и др.

• поддерживает сразу три стандартные нотации - IDEF0 (функциональное моделирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ). Эти три основных ракурса позволяют описывать предметную область более комплексно.

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

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

• недорог, распространён, по нему много информации и компетентных специалистов.

• лёгок в освоении и применении, есть курсы на русском языке.

• позволяет облегчить сертификацию на соответствие стандартам качества ISO9000

• является стандартом де-факто, интегрирован с ERwin (для моделирования БД), Paradigm Plus (для моделирования компонентов ПО) и др.

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

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

• содержит собственный генератор отчётов.

• позволяет эффективно манипулировать моделями - сливать и расщеплять их.

• имеет широкий набор средств документирования моделей, проектов.

9 ТЕОРИЯ О RATIONAL ROSE

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

Среда RationalRose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы Взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диаграммы Размещения применяют для визуализации проекта распределенных систем.

RationalRose - CASE-средство фирмы RationalSoftwareCorporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. RationalRose использует методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - UnifiedModelingLanguage) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.  Текущая версия RationalRose реализует генерацию кодов программ для С++, Visual C++, VisualBasic, Java, PowerBuilder, CORBA InterfaceDefinitionLanguage (IDL), генерацию описаний баз данных для ANSI SQL, Oracle, MS SQL Server, IBM DB2, Sybase, а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций.  Кроме того, RationalRose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.  В основе работы RationalRose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В составе RationalRose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг - восстановление модели проекта по исходным текстам программ.  Репозиторий представляет собой объектно-ориентированную базу данных. Браузер обеспечивают "навигацию" по проекту, в том числе, перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания.  Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.  Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме RationalRose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах.  В результате разработки проекта с помощью CASE-средства RationalRose формируются следующие документы:

1. диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы; 

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

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

Тексты программ являются заготовками для последующей работы программистов. Они формируются в рабочем каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp (заготовки программ для методов). Система включает в программные файлы собственные комментарии, которые начинаются с последовательности символов //##. Состав информации, включаемой в программные файлы, определяется либо по умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты развиваются программистами в полноценные программы. Среда функционирования RationalRose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).  Для работы системы необходимо выполнение следующих требований: 

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

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

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

ВЫВОДЫ

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

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

Начальный этап развития CASE - технологий характеризовался тем, что разные фирмы предлагали свои собственные средства визуального представления концептуальных средств. Зачастую выбор того или иного CASE-средства разработчиками определялся простотой нотации поддерживаемого средством языка представления схем и диаграмм. Появление первых стандартов в этой области лишь на какое-то время стабилизировало ситуацию. Однако острейшая конкуренция среди фирм- производителей программного обеспечения требовала от CASE-средств реализации объектно-ориентированной технологии разработки программ и поддержки широкого диапазона языков программирования и конкретных баз данных.

Среди всех фирм-производителей CASE-средств именно компания RationalSoftwareCoip. одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно- ориентированноеCASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Г. Буч, Д. Рамбо, А. Джекобсон , Программирование : Язык UML.

Руководство пользователя : Питер , 2005. – 206стр.

2. С. Макконнелл , Совершенный код. Мастер-класс./ Пер. с англ. – М. :

Издательско-торговый дом «Русская редакция» ; СПб. : Питер , 2005.-896 стр.

3.М. Фаулер, К. Скотт., Программирование : UML: Основы .

Приложение А

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

А.1 Общие сведения

Тема курсового проекта: игра «Пасьянс-косынка».

Основанием для разработки ПП является задание, выданное кафедрой ПОИС.

Дата выдачи: 08.02.12

Плановый срок завершения работы: 18.04.12

Курсовой проект должен выполняться согласно графику, приведенному в таблице А.1.

Таблица А.1 – Этапы, результаты и сроки разработки ПП

№	Этап работы	Результат работы	Срок выполнения (№ недели)
1	Получение задания на КП	Задание на разработку	08.02.2012
2	Выявление требований к разрабатываемому программному продукту	Техническое задание	1-2
3	Разработка метода решения задачи. Модульный анализ.	Определение структуры модулей	3-4
4	Разработка основного алгоритма функционирования.	Определение структуры программы, организация взаимосвязи модулей	5-6
5	Реализацияи отладка демонстрационной части	Организация взаимосвязи процедур и функций	7-8
6	Реализация и отладка программы. Проведение тестирования ПП.	Текст программы. Описание программы и тестов.	9-11
7	Оформление пояснительной записки и сопроводительных материалов.	Прошитая ПЗ с CD-ROM	12-13
8	Защита курсового проекта		18.04.2012

A.2 Основания для разработки и цель создания работы

Основанием для разработки является задание на курсовой проект по дисциплине “Проектный практикум”, выданное кафедрой программного обеспечения интеллектуальных систем студенту группы ПОС-10а Матвиенко Александру Сергеевичу.

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

А.3 Требования к программному продукту в целом

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

г) ввод начальных параметров для поиска;

д) вывод результатов решения на экран и в файл.

А.3.2 Требования к задачам и функциям программного продукта

В процессе работы необходимо обеспечить выполнение следующих функций:

а) ввод начальных значений;

б) надежное хранение информации;

в) вывод результатов на экран ;

А.3.3 Требования к техническому обеспечению

К техническому обеспечению предъявляются следующие требования:

1. процессор – 32-битный x86-совместимый (уровня Pentium и выше);

2. объем оперативной памяти – не менее 512Мб;

3. свободное дисковое пространство – 100 МБ.

4. графический адаптер – VGA-совместимый;

5. монитор – VGA-совместимый;

6. клавиатура.

А.3.4 Требования к программному обеспечению

Для стабильно работы к программному обеспечению предъявляются следующие требования:

• MS Windows Vista/XP/7

• .NET Framework.

А.4Требования к оформлению проектной документации

Проектная документация должна содержать следующие диаграммы:

• морфологическая модель;

• диаграмма состояний

• диаграмма деятельности;

• диаграмма «сущность-связь»;

• диаграмма компонентов;

• диаграмма размещения;

• диаграмма классов;

• диаграмма взаимодействия.