Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лабораторная работа _1.doc
Скачиваний:
27
Добавлен:
11.05.2015
Размер:
213.5 Кб
Скачать

10

Лабораторная работа №1 «Знакомство с системой поддержки проектирования по Rational Rose. Создание представления вариантов использования системы»

Цели работы:

  1. Изучить основные сведения о языке UML.

  2. Изучить основные этапы проведения проектирования ПО в RationalRose.

  3. Изучить особенности интерфейса RationalRoseи принципы работы с ним.

  4. Научиться работать с представлением вариантов использования при помощи CASE-средстваRationalRose.

  5. Выполнить первый этап учебного проекта.

Прежде, чем приступить к изучению теоретического материала, вспомните материал курсов КПиЯП и ООП и ответьте на следующие вопросы:

  1. Что представляет собой методология объектно-ориентированного программирования? Чем она отличается от методологии процедурного программирования?

  2. Как Вы понимаете понятие «абстракция»?

  3. Каковы основные принципы ООП?

  4. Что представляет собой класс и в качестве чего рассматривается объект в контексте ООП?

  5. Приведите пример наследования.

  6. Что характеризует принцип инкапсуляции?

  7. Какое свойство объектов понимается под понятием «полиморфизм»?

Краткие теоретические сведения:

  1. Объектно-ориентированный анализ и проектирование. Язык 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. Основной (но далеко не полный) набор диаграмм для моделирования, представляемый данным стандартом:

  1. Диаграммы вариантов использованияилиДиаграммы прецедентов(UseCaseDiagrams) – для моделирования бизнес-процессов и составления требований к проектируемой системе. На них изображаются отношения, существующие между актёрами (actors) и прецедентами (usecases).

  2. Диаграммы классов(ClassDiagrams) – для моделирования статической структуры классов проектируемой системы и связей между ними.

  3. Диаграммы поведения системы(BehaviorDiagrams), к которым относятся:

    1. Диаграммы взаимодействия(Interaction Diagrams):

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

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

    2. Диаграммы состояний(StateMachineDiagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое.

    3. Диаграммы деятельности(ActivityDiagrams) – для моделирования поведения системы в рамках различных вариантов использования. Аналогом диаграмм деятельности являются знакомые Вам схемы алгоритмов по ГОСТ 19.701-90.

  4. Диаграммы реализации(Implementation Diagrams):

    1. Диаграммы компонентов(ComponentDiagrams) – статические структурные диаграммы, показывающие разбиение системы на структурные компоненты и связи между ними.

    2. Диаграммы размещения(DeploymentDiagrams) – диаграммы, ,моделирующие физическую архитектуру системы.