
- •Лабораторная работа №1 «Знакомство с системой поддержки проектирования по Rational Rose. Создание представления вариантов использования системы»
- •Объектно-ориентированный анализ и проектирование. Язык uml.
- •Основные сведения о Rational Rose.
- •Диаграммы вариантов использования.
- •Рабочий интерфейс Rational Rose.
- •Создание представления вариантов использования в Rational Rose
- •Задание
Какую работу нужно написать?
Лабораторная работа №1 «Знакомство с системой поддержки проектирования по Rational Rose. Создание представления вариантов использования системы»
Цели работы:
Изучить основные сведения о языке UML.
Изучить основные этапы проведения проектирования ПО в RationalRose.
Изучить особенности интерфейса RationalRoseи принципы работы с ним.
Научиться работать с представлением вариантов использования при помощи CASE-средстваRationalRose.
Выполнить первый этап учебного проекта.
Прежде, чем приступить к изучению теоретического материала, вспомните материал курсов КПиЯП и ООП и ответьте на следующие вопросы:
Что представляет собой методология объектно-ориентированного программирования? Чем она отличается от методологии процедурного программирования?
Как Вы понимаете понятие «абстракция»?
Каковы основные принципы ООП?
Что представляет собой класс и в качестве чего рассматривается объект в контексте ООП?
Приведите пример наследования.
Что характеризует принцип инкапсуляции?
Какое свойство объектов понимается под понятием «полиморфизм»?
Краткие теоретические сведения:
Объектно-ориентированный анализ и проектирование. Язык uml.
Важным достижением развития методологии ООП явилось осознание того, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы. Прежде, чем начать программирование классов, их свойств и методов, необходимо определить сами эти классы. Более того, нужно дать ответы на следующие вопросы: сколько и какие классы нужно определить для решения поставленной задачи, какие свойства и методы необходимы для придания классам требуемого поведения, а также установить взаимосвязи между классами. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе, а также с анализом конкретной предметной области, для которой разрабатывается программа. Все эти обстоятельства привели к появлению специальной методологии, получившей название методологии объектно-ориентированного анализа и проектирования (ООАП).
Объектно-ориентированный анализ и проектирование (Object-Oriented Analysis/ Design, OOA/D) – технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов.
Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Более подробно о CASEсредствах, развитии графических нотаций, а также истории создания и развития языкаUMLВы прочтёте в[1].
Унифицированный язык моделирования (Unified Modeling Language, UML) является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит, программному обеспечению [2]. С помощью UML можно разработать детальный план создаваемой системы, содержащий не только ее концептуальные элементы (системные функции, бизнес-процессы), но и конкретные особенности (например классы, написанные на специальных языках программирования, схемы баз данных, программные компоненты многократного использования). Полной описание языка можно найти на сайтахwww.omg.orgиwww.rational.com.
Текущей версией UMLявляется 2.0, однако в качестве международного стандартаISO/IECпринятUML1.4.2. Основной (но далеко не полный) набор диаграмм для моделирования, представляемый данным стандартом:
Диаграммы вариантов использованияилиДиаграммы прецедентов(UseCaseDiagrams) – для моделирования бизнес-процессов и составления требований к проектируемой системе. На них изображаются отношения, существующие между актёрами (actors) и прецедентами (usecases).
Диаграммы классов(ClassDiagrams) – для моделирования статической структуры классов проектируемой системы и связей между ними.
Диаграммы поведения системы(BehaviorDiagrams), к которым относятся:
Диаграммы взаимодействия(Interaction Diagrams):
Диаграммы последовательности(SequenceDiagrams) – диаграммы, на которых изображается упорядоченное во времени взаимодействие объектов, в частности, участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.
Диаграммы коопераций(CollaborationDiagrams) – диаграммы, на которых также изображаются взаимодействия между структурными элементами системы. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).
Диаграммы состояний(StateMachineDiagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое.
Диаграммы деятельности(ActivityDiagrams) – для моделирования поведения системы в рамках различных вариантов использования. Аналогом диаграмм деятельности являются знакомые Вам схемы алгоритмов по ГОСТ 19.701-90.
Диаграммы реализации(Implementation Diagrams):
Диаграммы компонентов(ComponentDiagrams) – статические структурные диаграммы, показывающие разбиение системы на структурные компоненты и связи между ними.
Диаграммы размещения(DeploymentDiagrams) – диаграммы, ,моделирующие физическую архитектуру системы.