4.Реализация

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

рис. 7 Пример диаграммы компонентов

5.Тестирование

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

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

23. Унифицированный язык моделирования. Предметы, отношения и диаграммы в uml.

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

• Диаграмма вариантов использования (use case diagram)

• Диаграмма классов (class diagram)

• Диаграммы поведения (behavior diagrams)

  • Диаграмма состояний (statechart diagram)

  • Диаграмма деятельности (activity diagram)

  • Диаграммы взаимодействия (interaction diagrams) 

    • Диаграмма последовательности (sequence diagram) 

    • Диаграмма кооперации (collaboration diagram) 

• Диаграммы реализации (implementation diagrams)

  • Диаграмма компонентов (component diagram)

Диаграмма развертывания (deployment diagram)

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

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

Графическое обозначение варианта использования

Актеры

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

Интерфейсы

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

• О тношение ассоциации (association relationship) между актером и вариантом использования

• Отношение расширения (extend relationship)

Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А.

О тношение обобщения (generalization relationship)

• Отношение включения (include relationship)

Пример построения диаграммы вариантов использования

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

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

Класс

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

Рис. 5.1. Графическое изображение класса на диаграмме классов

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

Рис. 6.5. Диаграмма состояний для моделирования почтовой программы-клиента

Диаграмма деятельности (activity diagram)

24. Унифицированный язык моделирования. Диаграмма прецедентов. Потоки событий.

25. Унифицированный язык моделирования.Классы. Спецификация классов. Диаграммы класов.

26. Унифицированный язык моделирования. Диаграммы взаимодействия (кооперативная, последовательности).

27. Унифицированный язык моделирования.Диаграмма состояния. Диаграмма деятельности.

28. Унифицированный язык моделирования. Диаграмма компонентов. Диаграмма размещения.

29. Автоматизация конструирования АСОИУ. CASE – системы Rational Rose. Примеры диаграмм.

Назначение Rational Rose:

• программный пакет для визуального объектно-ориентированного;

• моделирования систем на основе классов и их взаимодействия, а если еще более упрощенно, это визуальный редактор, позволяющий моделировать программные системы любой сложности на основе графических диаграмм языка UML (Unified Modeling Language).

Язык UML

Язык UML кардинально отличается от таких языков программирования как, например, Visual C++ или Visual Basic. Он предназначен для описания моделей, причем для работы с этим языком используется специальные редакторы диаграмм, такие как Rational Rose. UML не зависит от объектно-ориентированных языков программирования и может поддерживать любой из них. Этот язык также не зависит от используемой методологии разработки проекта, и созданные на UML диаграммы выразительны и понятны для всех разработчиков, вовлеченных в проект, причем, что немаловажно, не только в момент разработки, но и много месяцев спустя. UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга. Однако пакет Rational Rose поддерживает не только UML, но и другие нотации создания диаграмм, такие как ОМТ или Booch.

Что может и чего не может сделать Rational Rose

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

Возможность интеграции со средствами управления требованиями (Requisite Pro), со средствами тестирования (SQA Suite, Performance Studio), со средствами конфигурационного управления (ClearCase, PVCS) поднимает процесс ведения программного проекта на совершенно новый уровень.

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

Преимущества от применения Rational Rose

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

• увеличение продуктивности работы программистов. Меньше ручного кодирования - меньше ошибок, меньше отладки, больше продуктивность;

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

• способность вести большие проекты и группы проектов;

• возможность повторного использования уже созданного ПО за счет упора на разбор их архитектуры и компонентов;

• язык UML служит универсальным «мостиком» между разработчиками из разных отделов.