Размещено на http://www.allbest.ru/

Расчетно-графическое задание

по курсу "Объектно-ориентированное программирование"

Создание диаграммы классов и прототипа кода на языке С++ в системе "Enterprise architect"

Цель работы

Изучить средства работы с диаграммой классов и создания прототипа кода на языке С++, предоставляемые системой Enterprise Architect.

Содержание работы

1. Ознакомиться с назначением и элементами диаграммы классов, технологией разработки диаграмм классов и создания прототипа кода классов на языке С++ в системе Enterprise Architect.

2. Составить диаграмму классов, соответствующую графической системе, разработанной в лабораторных работах № 4, 5, и произвести автоматическую генерацию прототипа кода разработанных классов.

2.1. Поместить на диаграмму классы геометрических фигур и шаблон контейнера.

2.2. Специфицировать атрибуты и операции классов, а также отношения, существующие между классами.

2.3. Произвести автоматическую генерацию прототипа кода разработанных классов.

2.4. Сгенерированный код сравнить с кодом, полученным в лабораторных работах № 4, 5. В случае необходимости внести исправления в диаграмму классов и повторить генерацию кода.

4. Оформить отчет, содержащий постановку задачи, разработанную диаграмму классов и текст прототипа кода.

5. Защитить РГЗ, ответив на вопросы преподавателя.

Создание проекта

После запуска открывается главное окно программы, показанное на рис. 3.1. код диаграмма генерация

Решение задачи в системе Enterprise Architect происходит в рамках некоторого проекта. Проект - механизм для сохранения и управления компонентами одной или нескольких моделей UML. Модели определяют отдельные аспекты разрабатываемой системы.

Первым делом создайте проект с единственной моделью. Выберите пункт меню File/New Project или на странице Start Page, находящейся в центре рабочего стола системы, выберите пункт Create a New Project. В появившемся диалоговом окне выберите рабочую папку и введите имя проекта. В диалоговом окне Select model(s) нажмите кнопку ОК.

Рис. 3.1

В результате этих действий в окне Project Browser, находящемся в правой части рабочего стола, появится элемент Model (его можно переименовать).

Окно Project Browser предназначено для быстрого доступа к элементам модели (в частности, к диаграммам). Браузер - это иерархическая структура, позволяющая осуществлять навигацию по модели. Все, что добавляется к ней, будет показано в окне браузера. Организация браузера представляет собой древовидную структуру. Каждый элемент модели может содержать другие элементы, находящиеся ниже его в иерархии. Знак "-" около элемента означает, что его ветвь полностью раскрыта. Знак "+" - что его ветвь свернута.

Поместите в модель Model пакет, в котором будет содержаться диаграмма классов. Для этого, выбрав в браузере модель, выберите пункт меню Project/Add Package. В диалоговом окне введите имя пакета, например, Graphic System. Выбрав в браузере данный пакет, создайте диаграмму классов, выбрав пункт меню Project/Add Diagram, а затем в диалоговом окне задав имя диаграммы (можно оставить предложенное "Graphic System"), и ее тип Type/UML Structural/Class (рис 3.2).

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

Рис. 3.2

Выбрав в окне Project Browser пиктограмму созданной диаграммы классов, получаем доступ к ее рабочей области и панели инструментов (рис. 3.3). Рабочая область находится в середине (пока она пуста), панель инструментов - окно "Toolbox" - слева.



Рис. 3.3

Создание диаграммы классов

Если Вы открываете созданный ранее проект, то для отображения диаграммы дважды щелкните левой кнопкой мыши в окне "Project Browser" на пиктограмме диаграммы классов (или щелкните правой кнопкой мыши на пиктограмме диаграммы классов и выберите в контекстном меню пункт "Open").

Рассмотрим ряд инструментов, которыми будем пользоваться для создания диаграммы классов (рис 3.4).

В группе Class пиктограмма Class предназначена для помещения на диаграмму нового класса.

В группе Class Relationships пиктограмма Generalize предназначена для создания на диаграмме отношения наследования (обобщения), пиктограмма Compose - отношения композиции, пиктограмма Aggregate - отношения агрегации, пиктограмма Nesting - отношения вложения.

В группе Common находится пиктограмма Dependency, предназначенная для создания на диаграмме отношения зависимости.

Рис. 3.4

Спецификация класса

При добавлении класса на диаграмму открывается окно для установления его свойств. Его можно открыть из контекстного меню класса (на диаграмме или в браузере), выбрав пункт Properties, или просто сделав двойной щелчок мышью на изображении класса.

На вкладке General (рис. 3.5) необходимо ввести имя класса (Name), выбрать язык программирования Language - C++. Если класс является абстрактным - установить флажок Abstract.



Рис. 3.5

На вкладке Details (рис. 3.6) можно специфицировать параметризованный класс (шаблон). Для этого в группе Templates выберите в списке Type пункт Parameterized. Нажав кнопку Add, определите параметры шаблона. На этой же вкладке можно получить доступ к окнам, предназначенным для определения атрибутов класса (кнопка Attributes) и его операций (кнопка Operations).



Рис. 3.6

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

На вкладке General (рис. 3.7) внизу представлен список атрибутов класса, который можно редактировать при помощи кнопок и полей, расположенных в верхней части окна.

Основные поля, которые необходимо заполнить - это имя (Name), тип (Type) и видимость (Scope). Если возможно, то задать значение по умолчанию (Initial).

Специфицировав новый атрибут, или изменив существующий, нажмите кнопку Save для перенесения спецификации в список.



Рис. 3.7

Если атрибут представляет собой массив, то количество элементов в массиве можно задать на вкладке Detail (рис. 3.8). Необходимо установить флажок Attribute is a Collection и в поле Container Type ввести количество элементов в прямых скобках.



Рис. 3.8

Заметим, что на диаграмме классов результаты наших действий будут отображаться с лишними круглыми скобками. Например, атрибут array типа int, являющийся массивом из десяти элементов, будет выглядеть следующим образом:

array: int ([10])

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

На вкладке General (рис. 3.9) внизу представлен список операций класса, который можно редактировать при помощи кнопок и полей, расположенных в верхней части окна. Основные элементы, которые необходимо заполнить - это имя (Name), параметры (Parameters), тип возвращаемого значения (Return Type) и видимость (Scope). Для виртуальных функций необходимо установить флажок Virtual, а для чисто виртуальных - флажок Pure.

Специфицировав новую операцию, или изменив существующую, нажмите кнопку Save для перенесения спецификации в список.

Рис. 3.9

Для задания параметров операции служит окно Parameters, доступ к которому можно получить, нажав кнопку Edit Parameters (рис. 3.10). Для каждого параметра необходимо указать имя (Name), тип (Type) и указать вид (Kind): in - входной, out - выходной, inout - смешанный. Если возможно, то задать значение по умолчанию (Default).



Рис. 3.10

Спецификация отношений между классами

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

Для отношения обобщения окно свойств представлено на рис. 3.11. На вкладке General можно указать имя отношения (Name), видимость (Scope).



Рис. 3.11

Для остальных отношений окно свойств имеет одинаковый вид.

На вкладке General (рис. 3.12) можно указать имя отношения (Name).

Рис. 3.12

На вкладке Source Role (рис. 3.13) специфицируется агрегируемый класс для агрегации (композиции) или класс-клиент (для зависимости).

На вкладке Target Role (рис. 3.14) специфицируется класс-агрегат для агрегации (композиции) или класс-сервер (для зависимости).

На рисунках 3.12-3.14 приведен пример спецификации агрегируемого класса Circle и класса-агрегата Combi, содержащего класс Circle, для отношения композиции. Если в лабораторных работах класс "Две вложенные фигуры" агрегировал два экземпляра класса "Фигура", то при выполнении РГЗ рекомендуется создать на диаграмме отдельные отношения агрегации для каждой вложенной фигуры (см. рис. 3.17 в конце раздела).

На данных вкладках указывается роль класса в отношении (…Role). Данное имя для агрегируемого класса в прототипе кода будет именем агрегированного объекта (см. прототип кода в конце раздела).

Другие важные свойства:

§ Multiplicity - кратность ассоциации;

§ Containment - способ агрегации: Reference - по ссылке, Unspecified - не определено (например, для зависимости), Value - по значению;

§ Access - видимость;

§ Aggregation - тип агрегации: none - отсутствует (для зависимости), shared - агрегация, composite - композиция.



Рис. 3.13

Рис. 3.14

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

Создание прототипа кода на языке C++

Для генерации прототипа коде выберите пункт меню Project/Source Code Engineering/Generate Package Source Code. В диалоговом окне Generate Package Source Code выберите классы, для которых необходимо сгенерировать прототип кода, и нажмите кнопку Generate (рис. 3.15). В окне Batch Generation будет отражаться ход генерации (рис. 3.16). По ходу генерации может быть предложено выбрать папку и имя файла для сохранения кода. По окончании генерации нажмите кнопку Close, а в окне Generate Package Source Code - кнопку Cancel.

Можно сгенерировать прототип кода для отдельного класса, выбрав в контекстном меню пункт Generate Code.

Откройте сгенерированные файлы с расширениями cpp и h для каждого класса, проверьте соответствие диаграммы классов, сгенерированного прототипа кода и программ из лабораторных работ №4, 5.

Рис. 3.15



Рис. 3.16

На рис. 3.17 представлена частично специфицированная диаграмма классов. Ниже приведены фрагменты сгенерированных заголовочных файлов.

Рис. 3.17

Фрагмент файла Shape.h

class Shape

{

protected:

Point center;

public:

Shape();

virtual ~Shape();

virtual void draw() =0;

private:

};

Фрагмент файла Circle.h

#include "Shape.h"

class Circle : public Shape

{

protected:

int radius;

public:

Circle();

virtual ~Circle();

virtual void draw();

void set_radius(int new_rad);

private:

};

Фрагмент файла Combi.h

class Combi

{

private:

Circle circle1;

Circle circle2;

public:

Combi();

virtual ~Combi();

};

Фрагмент файла Container.h

template<Class Type>

class Container

{

public:

Container();

virtual ~Container();

Type pop(){

return NULL;

}

void push(Type Elem){

}

};

Контрольные вопросы

1. Диаграмма классов.

а. Как изображается класс? Какая информация указывается на его значке?

б. Каков формат спецификации атрибутов класса? Как обозначается на диаграмме видимость и кратность элементов?

в. Каков формат спецификации операций класса?

г. Как изображаются на диаграмме статические элементы и утилиты?

д. Как изображается на диаграмме интерфейс? Как специфицируется на диаграмме отношения между интерфейсом и реализующим его классом?

е. Как специфицируется на диаграмме отношение ассоциации между классами?

ж. Как специфицируются на диаграмме отношения зависимости, наследования, агрегации, композиции?

з. Как специфицируются на диаграмме шаблоны, отношение инстанцирования?

и. Что такое вложенный класс и как он специфицируется на диаграмме?

2. Диаграмма объектов.

а. Что отражает диаграмма объектов?

б. Как изображается объект? Какая информация указывается на его значке? Как изображаются на диаграмме отношения между объектами?

3. Диаграмма последовательностей.

а. Как изображаются на диаграмме объекты и вызовы операций?

б. Как изображается на диаграмме линия жизни объекта?

в. Как изображается на диаграмме фокус управления?

г. Как изображаются на диаграмме циклы и ветвления?

4. Диаграмма коммуникации.

а. Как изображаются на диаграмме объекты и вызовы операций?

б. Как изображаются на диаграмме итерации?

в. Как изображаются на диаграмме условия?

Объектно-ориентированный анализ

Цель работы

Изучить основные приемы объектно-ориентированного анализа, средства работы с диаграммами и создания прототипа кода на языке С++, предоставляемые системой Enterprise Architect.

Содержание работы

1. Изучить основные методы и этапы объектно-ориентированного анализа. Ознакомиться с назначением и элементами диаграмм классов, последовательностей и коммуникации, технологией разработки диаграмм и создания прототипа кода классов на языке С++ в системе Enterprise Architect (см. методические указания к стандартному заданию РГЗ).

2. Для выбранной предметной области выявить ключевые абстракции, составляющие словарь предметной области. На основе выявленных ключевых абстракций разработать систему классов и объектов, описывающих предметную область. Специфицировать атрибуты и операции классов, а также отношения, существующие между классами. Упорядочить классы в иерархии типа "является" (не менее одной) и иерархии типа "имеет". Представить разработанные классы в виде диаграмм классов языка UML.

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

4. Реализовать разработанные диаграммы классов в системе Enterprise Architect. Диаграммы последовательностей или коммуникации также можно реализовать в системе Enterprise Architect. Сгенерировать прототип кода средствами Enterprise Architect.

5. Оформить отчет, содержащий

- описание предметной области, словарь предметной области;

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

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

- прототип кода, сгенерированный в Enterprise Architect.

6. Защитить РГЗ путем собеседования по выполненному проекту.

Методические указания

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

Основные этапы процесса объектно-ориентированного анализа

Выявление классов и объектов.

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

Главным результатом этого шага является словарь данных - центральное хранилище относящихся к системе абстракций.

Выяснение семантики классов и объектов.

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

В результате уточняется словарь данных; вырабатываются спецификации к каждой абстракции путем перечисления операций в протоколе каждого класса; интерфейсы этих классов выражаются на языке реализации (создание.h-файлов для C++); составляются диаграммы объектов и диаграммы последовательностей (коммуникации), передающие семантику сценариев.

Выявление связей между классами и объектами.

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

Составляются диаграммы классов, объектов и последовательностей (коммуникации).

Спецификация интерфейса и реализация классов и объектов.

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

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

Основы объектно-ориентированного анализа

Одной из основных задач, решаемых на этапе анализа и ранних стадиях проектирования, является выявление ключевых абстракций задачи - классов и объектов, составляющих словарь предметной области.

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

Выделим следующие способы проведения объектно-ориентированного анализа:

- классический подход;

- анализ поведения;

- анализ предметной области;

- анализ вариантов;

- CRC-карточки;

- неформальное описание.

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

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

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

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

При данном подходе кандидатами в классы и объекты могут быть выбраны:

- осязаемые предметы (автомобили, датчики);

- роли (учитель, политик);

- события (посадка на Марс, запрос);

- взаимодействие (заем, встреча).

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

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

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

Анализ предметной области - это попытка выделить те объекты, операции и связи, которые эксперты данной области считают наиболее важными.

Анализ включает следующие этапы:

- построение скелетной модели предметной области при консультациях с экспертами в этой области;

- изучение существующих в данной области систем и представление результатов в стандартном виде;

- определение сходства и различий между системами при участии экспертов;

- уточнение общей модели для приспособления к нуждам конкретной системы.

Анализ области можно вести относительно аналогичных приложений (вертикально) или относительно аналогичных частей одного и того же приложения (горизонтально).

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

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

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

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

CRC-карточки - Class-Responsibilities-Collaborators (Класс-Ответственности-Сотрудники) - это простой и эффективный способ анализа сценариев.

Сотрудник - это другой класс, который взаимодействует с данным для обеспечения некоего общего набора поведений.

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

На рис. 3.1 приведен вид CRC-карточки для класса Stack.

Рис. 3.1.

Разработчики по ходу анализа сценария заводят по карточке на каждый обнаруженный класс и дописывают в нее новые пункты.

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

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

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

Некоторым существительным больше соответствуют не классы, а, например, признаки или свойства объектов (имя, возраст, вес, адрес и т.п.) или даже имена операций ("телефонный вызов" вряд ли означает какой-либо класс).

Рассмотрим вопросы поиска, выбора и уточнения ключевых абстракций.

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

Определение ключевых абстракций включает в себя два процесса: открытие и изобретение. Мы открываем абстракции, слушая специалистов по предметной области: если эксперт про нее говорит, то эта абстракция обычно действительно важна. Изобретая, мы создаем новые классы и объекты, не обязательно являющиеся частью предметной области, но полезные при проектировании или реализации системы. Например, пользователь банкомата говорит "счет", "снять", "положить"; эти термины - часть словаря предметной области. Разработчик системы использует их, но добавляет свои, такие, как "база данных", "список", "очередь" и т.д. Эти ключевые абстракции созданы уже не предметной областью, а проектированием. Наиболее мощный способ выделения ключевых абстракций - сведение задачи к уже известным классам и объектам.

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

Кроме того, по ходу работы возможно следующее:

- выделить излишек ответственности в новый класс;

- перенести ответственность с одного большого класса на несколько более детальных классов;

- передать часть обязанностей другому классу.

Варианты заданий

Студент может выбрать предметную область самостоятельно или из данного списка вариантов в соответствии со своими интересами; в любом случае необходимо сообщить о своем решении преподавателю.

1. Книжный магазин

2. Магазин промышленных товаров

3. Склад

4. Центр заказов

5. Почтовая служба, включая службу доставки

6. Почтовое отделение

7. Управление персоналом в компании (отдел кадров)

8. Управление компанией (заводом)

9. Цент междугородних (международных) переговоров

10. Аэропорт

11. Железнодорожный вокзал

12. Управление железной дорогой

13. Сортировочная станция

14. Автострада

15. Автовокзал

16. Автотранспортные услуги

17. Экосистема

18. Факультет ВУЗа

19. Школа

20. Спортивный клуб (организация и управление)

21. Библиотека

22. Банк

23. Процесс обучения какому-либо предмету, например, объектно-ориентированному программированию или иностранному языку (организация и управление)

Размещено на Allbest.ru

...