3. Функциональная модель

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

Должности и обязанности распределяются следующим образом: «Руководитель: ставит задачу», «Аналитик: анализ ПО и постановка задач программисту», «Программист: подготовка модели проекта», «Тестер: оценка реализуемости проекта». Управляющий элемент для каждого - сроки. Но механизмы у каждого свои, определяются в соот­ветствии с должностями (какая должность, такой и механизм). Выходные данные описаны при помощи связи, для первого выходные данные, для вто­рого они являются входными. Следуя из этого структуру можно описать так: на вход руководителю подается предметная область,руководитель выдает аналитику задачи членов группы, после полного изучения предметной об­ласти, аналитики выдают программисту его задачи, которые программист выполняет, а разработанная модель проекта предается тестеру на проверку и корректировку, после этого оформляются готовые модели в ВРWin.

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

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

Про­граммисты выполняют следующие задания: «Подготовка реферата о Rational Rose», «Выделить классы и связи», «Реализация диаграммы классов», «Реализация диаграммы состоя­ний». Следуя из этого структуру можно описать так: на вход программисту подаются задачи про­граммистов, после чего готовится реферат о среде Rational Rose; после под­робного изучения предметной области выделяются классы и связи, за тем за тем создаются диаграммы классов и состояний. На выход подается готовая модель проекта.

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

5 ДИГРАММА СОСТОЯНИЙ

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

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

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

Понятие состояния (state) является фундаментальным не только в метамодели языка UML, но и в прикладном системном анализе. Вся концепция динамической системы основывается на понятии состояния. Семантика же состояния в языке UML имеет ряд специфических особенностей.

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

На рисунке 5.1 представлена диаграмма состояний для данной системы.

Рисунок 5.2 – Диаграмма состояний

6 ДИАГРАММА ДЕЯТЕЛЬНОСТИ

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

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

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

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

На рисунке 6.1 изображена диаграмма деятельности для данной системы.

Рисунок 6.1 – Диаграмма деятельности

7 ДИАГРАММА «СУЩНОСТЬ-СВЯЗЬ»

Диаграмма сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области.

ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями.

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

На рисунке 7.1 изображена диаграмма «сущность-связь» для данной системы.

Контактные данные

Контактные данные

Статус

Администратор

Пользователь

ФИО

регистрация

ФИО

Добавить

Название

Сообщение

Раздел

Содержит

Дата добавления

Дата добавления

Название

Рисунок 7.1 – Диаграмма «Сущность-связь»

8 ДИАГРАММА КОМПОНЕНТОВ

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

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

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

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

спецификации исполняемого варианта программной системы;

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

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

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

На рисунке 8.1 представлена диаграмма компонентов для данной системы.

Рисунок 8.1 – Диаграмма компонентов

9 ДИАГРАММА РАЗВЕРТЫВАНИЯ

Диаграмма развёртывания (Deployment diagram) в UML моделирует физическое развертывание артефактов на узлах. Например, чтобы описать веб-сайт диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-приложение, база данных), и как различные части этого комплекса соединяются друг с другом (например, JDBC, REST, RMI).

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

Существует два типа узлов:

• Узел устройства

• Узел среды выполнения

• У злы устройств — это физические вычислительные ресурсы со своей памятью и сервисами для выполнения программного обеспечения, такие как обычные ПК, мобильные телефоны. Узел среды выполнения — это программный вычислительный ресурс, который работает внутри внешнего узла и который предоставляет собой сервис, выполняющий другие исполняемые программные элементы.

На рисунке 9.1 изображена диаграмма развертывания для данной системы.

Рисунок 9.1 – Диаграмма развертывания

10 ДИАГРАММА КЛАССОВ

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

Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях. похожего на облако. Таким образом класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

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

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

На рисунке 10.1 изображена диаграмма классов для данной системы.

Сообщение// message

Добавить,удалить,отредактировать

Установить добавление,установить редактирование

Заголовок// title

Заполнить,отредактировать

Установить заполнить,установить редактировать

Администратор//Admin

Регистрация,удаление сообщение, назначает,создает

Установить назначение

Раздел// section

Добавить, удалить, отредактировать

Установить добавление, установить отредактировать

Пользователь// user

Зайти,регистрируется,редактирует,добавляет

Установить добавление, установление регистрации

Web-форум

Переписка,обмен инф.// exchange

Рисунок 10.1 – Диаграмма классов

11 ДИГАРАММА ПОСЛЕДОВАТЕЛЬНОСТИ

Д иаграмма последовательности (англ. sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. Используется в языке UML.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.

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

Рисунок 11.1 – Диаграмма последовательности

12 ТЕОРИЯ О Microsoft Visio

Microsoft Visio — редактор диаграмм и блок-схем для Windows. Использует векторную графику для создания диаграмм. Выпускается в двух редакциях: Standard и Professional.

Visio 2010 — это приложение для создания диаграмм и схем, помогающее визуализировать, исследовать и распространять сложные данные. В Visio сложные для понимания таблицы и текст можно преобразовать в наглядные доступные схемы.

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

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

Данные можно интегрировать в фигуры в режиме реального времени из множества различных источников, включая Excel, Access, SQL, списки SharePoint и любые источники данных OLEDB и ODBC, путем нескольких щелчков мышью в одном из мастеров работы с данными.

В Visio 2010 можно использовать встроенные шаблоны, создавать собственные и искать подходящие шаблоны.

13 ТЕОРИЯ О RATIONAL ROSE

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

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

• Use case diagram (диаграммы прецедентов);

• Deployment diagram (диаграммы топологии);

• Statechart diagram (диаграммы состояний);

• Activity diagram (диаграммы активности);

• Interaction diagram (диаграммы взаимодействия);

• Sequence diagram (диаграммы последовательностей действий);

• Collaboration diagram (диаграммы сотрудничества);

• Class diagram (диаграммы классов);

• Component diagram (диаграммы компонентов).

Само название Rational Rose переводится с английского либо как "Рациональная роза", либо как "Повышение рациональности", что связано с неоднозначностью перевода слова "Rose".

Rational Rose разработана компанией Rational , которая основана в 1981 году и занимается созданием CASE- технологий. Программные продукты фирмы Rational предназначены для анализа требований к системе, разработки программного обеспечения, тестирования, управления проектами и поддержки команды разработчиков.

ВЫВОДЫ

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

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

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

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

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

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

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

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

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

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

Приложение А

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

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

Тема курсового проекта: Объектно-ориентированный анализ и проектирование программного обеспечения. “Web-форум ”.

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

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

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

Курсовой проект должен выполняться согласно графику, приведенному в таблице А.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а Ждан Олесе Андреевне.

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

А.3 Характеристики объекта

Анализируя приведенную предметную область были выделенные основные объекты и свойства. У объекта Пользователь выделены следующие свойства: ФИО, статус на форуме. У объекта Администратор: ФИО. У объекта Сообщение: тема, заголовок, текст. У объекта Раздел: тема.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• MS Windows Vista/XP/7

• .NET Framework.