Logo GenDocs.ru

Поиск по сайту:  


Загрузка...

Лекции - Объектно-ориентированное программирование - файл ООП.doc


Лекции - Объектно-ориентированное программирование
скачать (28.9 kb.)

Доступные файлы (1):

ООП.doc126kb.27.01.2006 14:17скачать

содержание
Загрузка...

ООП.doc

Реклама MarketGid:
Загрузка...
Типичная диаграмма жизненного цикла проекта включает в себя следующие стадии:

- анализ

- проектирование

- реализация

- поддержка


Основные концепции.

Значение – это конечное обозначение, которое мы можем рассматривать как ответ или результат вычисления. Каждое значение имеет соответствующий тип. Мы можем рассматривать типы как наборы подобных значений.


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


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


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


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


Моделирование – процесс создания модели чего-то; означает выделение важных значащих свойств, характеристик и отбрасывание всех неважных. Это отбрасывание называется абстрагированием.


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


Некоторые свойства объекта могут никогда не изменять своего значения. Когда свойство объекта меняет значение, мы говорим, что объект меняет свое состояние.


Если и свойства, и их значения двух объектов одинаковы, то эти объекты неразличимы.


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


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


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


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


^ Объектная декомпозиция.


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


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

  1. физический объект (дом, ручка, книга);

  2. характеристика (форма буквы, форма фигуры);

  3. местоположение (улица);

  4. абстрактное обозначение (животное, графическая фигура);

  5. событие (встреча, ЧП);

  6. сложная сущность, состоящая из других сущностей (очередь людей, список книг, матрица целых чисел).

Каждая сущность моделируется с помощью отдельного класса.


На второй стадии отмечаются свойства, которые описывают объекты.


На третьем этапе описываются отдельные действия, которые могут совершать объекты. Эти действия моделируются с помощью функций объекта.


На четвертой стадии определяется реализация каждого объекта.


^ Идеи ООП: инкапсуляция и наследование.

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


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


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


Иерархия классов это коллекция классов с их зависимостями типа “предок - потомок”.

^

ООП принцип – полиморфизм


Каждый объект некоторого класса в тоже время объект всех предков этого класса. Следовательно, ссылка на объект может иметь не только экземпляр класса, но также экземпляр потомка. Однако, каждая ссылка на объект на некоторый класс позволяет вызывать только методы этого класса независимо от настоящего класса объекта.


Каждый метод может быть переобъявлен в потомке. Однако, вызов метода основного класса не вызовет переобъявленный метод, несмотря на настоящий класс объекта.


Эта ситуация решается использованием полиморфных методов. Метод может быть объявлен в основном классе полиморфным и перереализован в потомке.


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


Эта ситуация называется runtime binding. Это выполняется во всех вызывающих выражениях, не только в явных.


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


^ Область действия и видимость.


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


Каждый объект проектируется “чёрным ящиком”. Это означает, что его реализация и внутренняя часть должны быть скрыты, в то время как интерфейс должен быть ясно определен. В ООП это обычно достигается приписыванием атрибутов видимости свойствам и методам. Когда вы объявляете свойство или метод, новый член класса имеет видимость указанную одним из слов: private, protected, public. Видимость члена определяется доступностью для других объектов и единиц.


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


Protected член доступен внутри методов того же класса и всех потомков.


Public член доступен отовсюду.


^ События и обработчики событий.

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


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


Создатель события и отправитель ->

Среда ->

Событие ->

Диспетчер другого объекта ->

Обработчик события объекта.


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


1. Чисто-событийный подход (чистое Win32 программирование)

2. Процедурно-событийный подход (CBuilder, Delphi)


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


Один из ключей к традиционному программированию для Windows – это обработка сообщений, отправляемых Windows'ом приложениям. Сообщение Windows – это запись данных, которая содержит несколько полей. Наиболее важное из них – это целое значение, идентифицирующее сообщение. Другая полезная информация приходит в двух полях-параметрах. Каждый объект приложения, который проектируется для получения сообщений, объявляет Windows'у обработчик событий, или так называемую оконную процедуру. Эта оконная процедура – это метод, который обрабатывает сообщения для окна. Когда приложение создает окно, оно регистрирует оконную процедуру в ядре.


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


Виды событий, которые могут произойти, могут быть разделены на две главные категории: пользовательские события и системные события. Пользовательские события – действия, производимые пользователем. Эти события всегда связаны с действиями пользователя. Системные события – события, которые ОС совершает для вас.


^ Множественное наследование и интерфейсы.


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


Другим решением будет объявление потомка от двух классов. Это называется множественным наследованием. При множественном наследовании потомок наследует все методы и свойства всех своих предков.


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


Интерфейс может иметь предков и наследовать все их методы. Но интерфейс не реализует методы. Классы, поддерживающие интерфейс, должны реализовывать его методы.


^ Обработка исключений в ООП.


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


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


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


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


Чтобы создать объект исключения, программисту требуется вызвать конструктор класса исключений оператором raise (throw).


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


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


Если исключение осталось необработанным, выполнение переходит во вложенный обработчик исключений, и так далее.


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


Когда возникает ошибка, приложение вызывает исключение. Существует 2 наиболее общих модели ответа на ошибки: выполнение очищающего кода и обработка исключения. Простейший способ ответить на исключение – гарантировать, что выполнится некоторый очищающий код. Этот тип ответа не исправляет условие, которое вызвало ошибку, но позволяет вам быть уверенным, что ваше приложение не оставит свою среду в нестабильном состоянии.


Обработка исключения устраняет условия ошибки и уничтожает объект исключения, что позволяет приложению продолжить выполнение.


^ Жизненный цикл объектов и управление памятью.


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


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


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


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


^ Автоматическое управление памятью.


Техника автоматического управления памятью позволяет программисту передавать ответственность за управление памятью языку.


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


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


^ Объектный рефакторинг.


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


Рефакторинг часто ассоциируется с:

  • множеством малых изменений, применяемых повторно;

  • каталогом широко обсуждаемых действий;

  • явными единичными тестами, применяемыми до и после каждого минимального изменения;

  • взаимодействующим, инструментально поддерживаемым, но не автоматическим.


Основные рефакторинги.


  1. Переименование метода.

  2. Инкапсуляция поля (сделать public поля private полями, предоставить доступ с помощью функций).

  3. Выделение класса (имеется класс, выполняющий работу, которая должна выполняться двумя. Создайте новый класс и перенесите соответствующие поля в него).

  4. Инлайн класс (если класс делает немного, перенесите все его функциональные возможности в другой класс, а этот удалите).

  5. Инлайн метод (если тело метода понятно из его имени, то перенесите тело метода в тело его вызова, а метод удалите).

  6. Вытягивание метода (вы имеете методы с идентичными результатами в подклассах. Создайте такой метод в суперклассе, а в подклассах удалите).

  7. Вталкивание метода (поведение суперкласса существенно только для некоторых его подклассов. Перенесите метод в эти подклассы).

  8. Сворачивание иерархии (если суперкласс и подкласс различаются не сильно, соедините их).

  9. Выделение метода (если вы имеете фрагмент кода, делающий две различные вещи, выделите один фрагмент в метод с именем, объясняющим цель нового метода).

  10. Замещение массива объектом (если вы имеете массив, в котором какие-то элементы означают разные вещи, замените массив на объект, который имеет поля для каждого элемента).

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


^ Шаблоны проектирования.


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

Листинг 3

class Singleton

{

static Singleton* _self;

protected:

Singleton(){}

public:

static Singleton* Instance()

{

if(!_self) _self = new Singleton();

return _self;

}

//методы

void aFunc1();

void aFunc2();

//данные

int aData;

};


Singleton* Singleton ::_self=NULL;

ПРИМЕЧАНИЕ
Конструктор класса объявлен в защищенной секции. Благодаря этому отсутствует возможность создавать объекты класса по оператору new или статически. Вместо этого для конструирования объекта служит метод Instance(), который гарантирует, что в программе будет существовать только один экземпляр данного класса.

Таким образом, класс Singleton инкапсулирует в себе методы и свойства данной сущности, может быть доступен из любого места программы благодаря методу Instance(), а, кроме того, теперь мы можем управлять временем жизни этого объекта.

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


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


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

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

Паттерн, в общем случае, состоит из четырех элементов:

  1. Имя – однозначное определение паттерна, говорящее о его назначении.

  2. Задача – условия применения паттерна.

  3. Решение – абстрактное описание решения задачи и модель решения в виде набора связанных классов.

  4. Результат – ожидаемые последствия применения паттерна.


Классификация.


  1. Фундаментальные шаблоны.

  2. Создающие шаблоны.

  3. Структурные шаблоны.

  4. Шаблоны поведения

  5. ...


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


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


Шаблоны поведения описывают распространенные шаблоны взаимодействия между объектами.




public class Client1

{

Button button = null;

ButtonFactory bf = null;

pubic Client1(ButtonFactory bf)

{

this.bf = bf;

button = bf.createButton();

}

}



public class ClientN

{

Button button = null;

ButtonFactory bf = null;

pubic ClientN(ButtonFactory bf)

{

this.bf = bf;

button = bf.createButton();

}

}


public abstract class ButtonFactory

{

public createFactory()

{

if (swing)

return SwingButtonFactory();

if (myType)

return MyTypeButtonFactory();

}

public Button createButton();

}


public class SwingButtonFactory() extends ButtonFactory

{

Button public createButton()

{

return new JButton();

}

}


public class MyTypeButtonFactory() extends ButtonFactory

{

Button public createButton()

{

return new MyTypeButton();

}

}


^ ДРУГОЙ ПРИМЕР


/*

* GUIFactory example

*/


abstract class GUIFactory

{

public static GUIFactory getFactory()

{

int sys = readFromConfigFile("OS_TYPE");


if (sys == 0)

{

return(new WinFactory());

}

else

{

return(new OSXFactory());

}

}

public abstract Button createButton();

}


class WinFactory : GUIFactory

{

public override Button createButton()

{

return(new WinButton());

}

}


class OSXFactory : GUIFactory

{

public override Button createButton()

{

return(new OSXButton());

}

}


abstract class Button

{

public string caption;

public abstract void paint();

}


class WinButton:Button

{

public override void paint()

{

Console.WriteLine("I'm a WinButton: "+caption);

}

}


class OSXButton:Button

{

public override void paint()

{

Console.WriteLine("I'm a OSXButton: "+caption);

}

}


class Application

{

static void Main(string[] args)

{

GUIFactory aFactory = GUIFactory.getFactory();

Button aButton = aFactory.createButton();

aButton.caption = "Play";

aButton.paint();

}


//output is

//I'm a WinButton: Play

//or

//I'm a OSXButton: Play


}

Можно заметить, что из-за одного создаваемого продукта (Button) создаются 3 класса (ButtonFactory, SwingButtonFactory, MyTypeButtonFactory).

Более удачным решением в этом случае является создание MyTypeButton в качестве наследника JButton. В КАЖДОМ клиентском классе мы, как и было сказано выше, просто заменяем JButton на MyButton. Эту замену можно сделать с помощью какого-нибудь инструмента по замену текста.

Итак, можно сказать следующее. Используйте паттерн абстрактная фабрика, когда:

  1. Класс заранее не знает, классы каких продуктов он должен создавать (полиморфизм). Режим run-time

  2. Абстрактная фабрика возвращает больше чем один тип продуктов


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


^ Введение в UML.


UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.


UML (Unified Modeling Language) — в разработке программного обеспечения отраслевой стандарт визуального языка моделирования 3-го поколения, который служит в основном для моделирования программных систем. Однако использование UML не ограничивается моделированием программного обеспечения. Он может быть использован для моделирования технических средств; кроме того, это язык употребляется для моделирования бизнес-процессов и организационных структур.


^ UML - это язык визуализации

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

UML - это язык специфицирования

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

Строительные блоки UML

Словарь языка UML включает три вида строительных блоков:

  • сущности;

  • отношения;

  • диаграммы.



Сущности

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

В UML имеется четыре типа сущностей:

  • структурные;

  • поведенческие;

  • группирующие;

  • аннотационные.

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

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

  1. ^ Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой

  2. Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом

  3. Кооперация (Collaboration) определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект

  4. Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели (см. главу 16). Прецеденты реализуются посредством кооперации.

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

  6. Компонент (Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию

  7. Узел (Node) - это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и способностью обработки



Поведенческие сущности (Behavioral things) являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве:

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

  2. Автомат (State machine) - это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события



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

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



Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели:

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


Отношения


В языке UML определены четыре типа отношений:

  1. Зависимость (Dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой

  2. Ассоциация (Association) - структурное отношение, описывающее совокупность связей. Разновидностью ассоциации является агрегирование (Aggregation) - так называют структурное отношение между целым и его частями.

  3. Обобщение (Generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Таким образом, потомок (Child) наследует структуру и поведение своего родителя (Parent).

  4. Реализация (Realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет "контракт", а другой гарантирует его выполнение



Диаграммы


Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).


Типы диаграмм:

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

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

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

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

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

  6. На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости.

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



Скачать файл (28.9 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации
Рейтинг@Mail.ru