Обобщение

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

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

Обобщение геометрических фигур

……..

Операции (move select rotate display) наследуются всеми подклассами. Операция Scale наследуется только одномерными фигурами. Операция Fill наследуется только двумерными фигурами. Слово, написанное на диаграмме рядом с линией обозначающей обобщение, это имя набора обобщений (demensionality). Имя набора обобщений это перечислимый атрибут, показывающий какой аспект объекта абстрагируется конкретным обобщением. Каждый набор должен абстрагировать только один аспект, соответственно имя набора указывать не обязательно.

Не следует создавать слишком глубокую иерархию подклассов. Поскольку это затрудняет понимание модели. Можно руководствоваться следующим правилом: два или три уровня наверняка приемлемы, 10 уровней много, 5-6 уровней может быть как приемлемо, так и нет.

Использование обобщения.

Обобщения служат трем основным целям:

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

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

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

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

Подмена составляющей.

Подкласс может подменять или перекрывать составляющую суперкласса, определяя новую составляющую с тем же именем внутри себя. Подменяющая составляющая уточняет и заменяет подмененную. Подмена составляющих может потребоваться по нескольким причинам: для спецификаций поведения зависящего от подкласса(display) для уточнения спецификации составляющего и для повышения производительности. Операция rotate класса Circle заменена пустым блоком кода. Никогда не следует подменять сигнатуру составляющей(имя, список, тип аргументов, число аргументов), подмена должна сохранять тип атрибута, количество и тип аргументов операций, а так же тип возвращаемого операцией значения.

Квалифицированные ассоциации.

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

+accountNumberber

Account

Bank

Квалифицированная

1

Account

Bank

0..1

неквалифицированная

1 *

В контексте банка уникальный счет определяется своим номером. Номер счета – это квалификатор. Обе модели вполне корректны, но модель с квалифицированной ассоциацией сообщает дополнительную информацию. В квалифицированной модели добавляется ограничение на кратность т.е.: сочетание банка и номера счета дает не более одного счета. Так же модель передает значение номера счета для прослеживания модели т.е. сначало следует найти банк затем указать номер счета и в результате вы получаете нужный счет. Для обозначения квалификатора используется небольшой прямоугольник который пристыковывается к исходному классу около конца линии обозначающей ассоциацию. Исходный класс вместе с квалификатором определяют целевой класс: Bank & account number вместе дают аккаунт.

Пример использования квалификатора.

……

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

Написание ПО.

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

Сборка ПО.

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

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

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

Аттестация программной системы.

Верификация и аттестация предназначена, чтобы показать соответствие системы, её спецификации и ожидания заказчика. Крупные системы невозможно протестировать как единое целое, поэтому тестирование производиться поэтапно.(По мере реализации системы)

Процесс тестирования

………..

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

Тестирование компонентов.

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

Тестирование модулей.

Модуль – совокупность зависимых компонентов, таких как описание классов, наборы функции и процедур и т.п.

Каждый модуль тестируется независимо от других.

Тестирование подсистем.

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

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

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

Приемочные испытания.

Конечный этап тестирования. Система тестируется с привлечением данных предоставляемых заказчиком системы.

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

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

Этапы тестирования в процессе разработки ПО.

…….

Приемочные испытания называют альфа-тестированием. Оно проводится до тех пор пока разработчик и заказчик системы не удостоверится в том что разработанная система полностью соответствует системным требованиям.

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

Эволюционирование.

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

Эволюция систем.

…………………………………

Модели процесса создания ПО.

Типы моделей создания ПО:

· Модель последовательности работ

· Модель потоков данных и процессов

· Ролевая модель

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

Модель потоков данных и процессов – процесс создания ПО представляется в виде множества активностей(процессов), в ходе реализации которых выполняются преобразования определенных данных.

Ролевая модель – здесь представляются роли людей включенных в процесс создания ПО и действия выполняемые ими в этих ролях.

Модели создания ПО: