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

Предпосылки возникновения объектно-ориентированного подхода

Рассмотрим тенденцию развития какого-либо программного продукта за последние 15 лет. Возьмем в качестве примера, компилятор Pascal фирмы Borland. В 1984 году появился компилятор версии 3.0, дистрибутив которого занимал 37 Кб вместе со всеми необходимыми библиотеками ( включая возможность работы с графикой ). Последняя версия компилятора - Delphi 3.0, дистрибутив которого в простейшем варианте занимает 100 Мб. Т.е. размер программы вырос примерно в 2700 раз за 15 лет. Аналогичную картину можно наблюдать на любом другом программном средстве.

В этой связи можно обратить внимание на следующие две особенности:

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

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

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

Жизненный цикл программного обеспечения. Стандартные модели жизненного цикла. Этапы жизненного цикла.

Традиционно, во всех стандартных моделях, выделяют следующие основные этапы жизненного цикла:

стратегическое планирование;
анализ требований;
проектирование (предварительное и детальное);
кодирование (программирование);
тестирование и отладка;
эксплуатация и сопровождение.

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

Рассмотрим подробнее отдельные этапы жизненного цикла.

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

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

На этапе проектирования создается структура будущей программой системы

Можно определить следующие фазы проектирования:

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

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

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

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

Модели жизненного цикла

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

Первой, по времени появления, и самой распространенной являлась каскадная модель:

Модель предполагает следующие свойства взаимодействия этапов:

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

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

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

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

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

Жизненный цикл UML (Rational Objectory Process).

Фирма Rational Software, разработавшая язык UML, предложила так же и свою модель жизненного цикла, которая называется Rational Objectory Process (данный термин труден для перевода, т.к., во-первых, слово Rational имеет значение рациональный и название фирмы одновременно, во-вторых, слова objectory нет в английском языке, оно построено по аналогии со словом repository (накопитель)).

Можно перечислить следующие основные свойства данной технологии:

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

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

Начало (Inception)

Совершенствование (Elaboration)

Построение (Construction)

Переход (Transition)

Рис. 2.2 Модель жизненного цикла UML

На рисунке ниже представлены основные модели UML в виде прямоугольников. Линии между ними обозначают отношение.

Рис. 2.3. Основные модели UML

Концепции объектно-ориентированного подхода к разработке больших программных систем. Инкапсуляция. Наследование. Полиморфизм.

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

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

- инкапсуляция - свойство при котором объекты содержат описание атрибутов и действий одновременно,

- наследование - такой метод определения объектов, при котором производные объекты (потомки) наследуют свойства (атрибуты и действия) от своих родителей,

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

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

Достоинства и недостатки объектно-ориентированного подхода.

Сокращение числа возможных ошибок. Типичные ошибки при решении различных задач :

Несогласованные параметры подпрограмм

Часто может наблюдаться передача в подпрограмму разных параметров, несогласованных друг с другом. Пусть есть подпрограмма, выводящая на экран матрицу А размером N x M. Ее заголовок может быть таким:

procedure ShowMatrix( A : TMatrix; N,M : integer );

при вызове подпрограммы, за счет ошибки программиста, N и M могут не соответствовать реальному размеру матрицы. Эта задача решается за счет инкапсуляции, когда N и M включаются в качестве атрибутов в матрицу.

Несогласованное изменение атрибутов

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

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

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

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

Недостатки объектно-ориентированного подхода

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

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

Универсальный язык моделирования ( Unified Modeling Language UML ). Пакеты, как средство работы с большими проектами.

UML - это универсальный язык моделирования, разработанный в фирме Rational Software при участии других партнеров. Очень многие организации проявили интерес к данной методологии. Был создан консорциум UML партнеров, в который вошли такие известные фирмы как DEC, HP, IBM, Oracle, Microsoft и другие. После создания такой группы появились спецификации UML 1.0 и UML 1.1. Ниже рассматривается незначительно сокращенный вариант графического синтаксиса языка UML 1.1.

Пакеты, как средство работы с большими проектами

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

Рис. 7.1. Обозначение пакета.

Полное обозначение пакета предназначено для представления этого пакета как такового:

Рис. 7.2. Полное обозначение пакета.

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

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

Рис. 7.3. Набор пакетов проекта "графический редактор"

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

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

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

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

Достоинства использования пакетов:

? декомпозиция задачи упрощает понимание каждой части в отдельности и задачи в целом,

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

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

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

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

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

Диаграммы использования являются широко применяемыми в различных технологиях проектирования. Их главная задача - спецификация требований к системе на начальных этапах проектирования, когда решаются наиболее общие задачи предназначения разрабатываемой системы. Широкое распространение диаграмм использования привела в частности и к тому, что они имеют очень широкое и иногда различное толкование. Так в книге [ 4 ] автор указывает, что он обнаружил 18 различных определений, которые отличаются друг от друга по очень многим параметрам.

Диаграмма состоит из следующих элементов:

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

Выделены следующие виды связей:

взаимодействие; (только между пользователем и блоком использования )
расширение - данный вид отношения от блока А к блоку В обозначает, что исполнение блока В может дополняется исполнением некоторых функций блока А;
использование - данный вид отношения от блока А к блоку В обозначает, что исполнение А также включает исполнение блока В;

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

Графическое обозначение для связей следующее:

взаимодействие - сплошная линия,
расширение - линия со стрелкой от блока, предоставляющего расширение к базовому блоку, помеченная словом extends
использование - линия со стрелкой от использующего блока к используемому блоку, помеченная словом uses.

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

Связи в диаграммах вариантов использования.

В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы.

Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization).

Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии со стрелкой).

Направление стрелки позволяет понять, кто инициирует коммуникацию.Page 10

Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность. В примере АТМ варианты использования «Снять деньги» и «Положить деньги на счет» должны опознать (аутентифицировать) клиента и его идентификационный номер перед тем, как допустить осуществление самой

транзакции. Вместо того чтобы подробно описывать процесс аутентификации

для каждого из них, можно поместить эту функциональность в свой собственный вариант использования под названием «Аутентифицировать клиента».

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

На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими стереотипами.

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

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

это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

Документирование потока событий.

Каждый вариант использования должен иметь связанное с ним короткое описание того, что он будет делать. Например, вариант использования «Перевести деньги» системы АТМ может содержать

следующее описание:

Вариант Использования «Перевести деньги» позволяет клиенту

или служащему банка переводить деньги с одного счета до

востребования или сберегательного счета на другой.

Предусловия

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

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

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

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

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

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

– способ запуска варианта использования;

– различные пути выполнения варианта использования;

– нормальный, или основной, поток событий варианта использования;

– отклонения от основного потока событий (так называемые

альтернативные потоки);

– потоки ошибок;

– способ завершения варианта использования.

Например, поток событий варианта использования «Снять деньги»

может выглядеть следующим образом:

Основной поток

1. Вариант использования начинается, когда клиент вставляет свою

карточку в АТМ.

2. АТМ выводит приветствие и предлагает клиенту ввести свой

персональный идентификационный номер.

3. Клиент вводит номер.

4. АТМ подтверждает введ¨нный номер. Если номер не подтвержден,

выполняется альтернативный поток событий А1.

5. АТМ выводит список доступных действий:

– положить деньги на счет;

– снять деньги со счета;

– перевести деньги.

6. Клиент выбирает пункт «Снять деньги».

7. АТМ запрашивает, сколько денег надо снять.

8. Клиент вводит требуемую сумму.

9. АТМ определяет, имеется ли на счету достаточно денег. Если денег

недостаточно, выполняется альтернативный поток А2. Если во время

подтверждения суммы возникают ошибки, выполняется поток ошибок Е1.

10. АТМ вычитает требуемую сумму из счета клиента.

11. АТМ выдает клиенту требуемую сумму наличными.

12. АТМ возвращает клиенту его карточку.

13. АТМ печатает чек для клиента.

14. Вариант использования завершается.

Альтернативный поток А1. Ввод неправильного идентификационного

номера.

1. АТМ информирует клиента, что идентификационный номер введ¨н

неправильно.

2. АТМ возвращает клиенту его карточку.

3. Вариант использования завершается.

Альтернативный вариант использования А2. Недостаточно денег

на счету.

1. АТМ информирует клиента, что денег на его счету недостаточно.

2. АТМ возвращает клиенту его карточку.

3. Вариант использования завершается.

Поток ошибок Е1. Ошибка в подтверждении запрашиваемой суммы.

1. АТМ сообщает пользователю, что при подтверждении

запрашиваемой суммы произошла ошибка и дает ему номер телефона

службы поддержки клиентов банка.

2. АТМ заносит сведения об ошибке в журнал ошибок. Каждая запись

содержит дату и время ошибки, имя клиента, номер его счета и код

ошибки.

3. АТМ возвращает клиенту его карточку.

4. Вариант использования завершается.

Постусловия

Постусловиями называются такие условия, которые всегда должны

быть выполнены после завершения варианта использования. Например,

в конце варианта использования можно пометить флажком какой-нибудь

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

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

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

Если, например, после одного из вариантов использования должен всегда

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

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

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

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

объект, обозначается прямоугольником с записанным в нем именем объекта;

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

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

вызов метода поведения объекта (сообщение), обозначается стрелкой между активациями объектов с именем действия, направление стрелки задает направление передачи данных,

текстовые метки (отметки времени, описание действий и т.п.)

На данном рисунке рассмотрена диаграмма для установки PPP - соединения через модем между сервером и клиентом. Такая задача выполнятся, например, при подключении персонального компьютера к Intenret через модем. На рисунке изображены четыре объекта: PPP - соединение, Номеронабиратель, Телефонная линия, Сервер. В рамках данной задачи объекты Номеронабиратель и Телефонная линия начинают свою жизнь сразу с активации, тогда как другие объекты имеют неактивную линию жизни ( см. штрих - пунктир ). Активация объектов PPP - соединение и Сервер начинается только с получения соответствующего сообщения. Объект PPP - соединение создается только после получения соответствующего сообщения. В этом случае стрелка с сообщением соединяется не с активацией, а непосредственно с объектом. Черный крест в конце активации обозначает, что объект перестает существовать в рамках данной задачи.

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

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

Кооперативные диаграммы.

Диаграмма сотрудничества ( Collaboration diagram ) предназначена для описания методов взаимодействия между объектами. Для пояснения смысла и назначения диаграммы необходимо ввести такое понятие как сотрудничество.

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

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

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

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

параметры процедур,

локальные переменные,

self ссылки (ссылки на сам объект).

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

Рис. 7.17. Пример диаграммы сотрудничества

Диаграммы классов и объектов. Классы.

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

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

Классы

Графическое представление класса - это прямоугольник, который может быть разделен на три части:

Рис. 7.4. Пример изображения класса.

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

Каждый атрибут представляется в следующем виде:

видимость имя: тип = начальное значение

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

+ общедоступный ( public ) атрибут # защищенный ( protected ) атрибут -закрытый ( private ) атрибут

Каждый метод представляется в следующем виде:

видимость имя( список параметров ): тип возвращаемого значения

Описатель видимости имеет те же значения, что и для атрибута.

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

вид имя: тип = значение по умолчанию

вид параметра может быть следующим:

inвходной параметр out выходной параметр inout входной и выходной параметр

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

Пример изображения класса представлен на рис. 7.5.

Рис. 7.5. Пример изображения класса "Геометрическая фигура".

Диаграммы классов и объектов. Отношения между классами.

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

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

Ассоциации

Ассоциация (association) – это семантическая связь между классами.

Их рисуют на диаграмме классов в виде обыкновенной линии.

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

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

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

экземплярами этого же класса.

Зависимости

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

изображают в виде стрелки, проведенной пунктирной линией.

При генерации кода для этих классов к ним не будут добавляться новые атрибуты. Однако, будут созданы специфические для языка операторы, необходимые для поддержки связи. Например, на языке С++ в код войдут необходимые операторы #include.

Агрегации

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

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

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

целому, и, кроме того, как правило, жизненный цикл частей совпадает с циклом целого: они живут и умирают вместе с ним. Любое удаление целого распространяется на его части. Такое каскадное удаление нередко рассматривается как часть определения агрегации, однако оно всегда подразумевается в том случае, когда множественность роли составляет 1..1; например, если необходимо удалить Клиента, то это удаление должно распространиться и на Заказы

(и, в свою очередь, на Строки заказа).

Обобщения

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

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

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

Множественность

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

Например, при разработке системы регистрации курсов в университете можно определить классы Course (курс) и Student (студент). Между ними установлена связь: у курсов могут быть студенты,

а у студентов – курсы. Вопросы, на который должен ответить параметр множественности: «Сколько курсов студент может посещать в данный момент? Сколько студентов может за раз посещать один курс?» Так как множественность дает ответ на оба эти вопроса, е¨ индикаторы устанавливаются на обоих концах линии связи. В примере регистрации курсов мы решили, что один студент может посещать от нуля до четырех курсов, а один курс могут слушать от 10 до 20 студентов. В языке UML приняты следующие нотации для обозначения множественности:

Множественность Значение 0..* Ноль или больше 1..* Один или больше 0..1 Ноль или один 1..1 (сокращенная запись: 1) Ровно один.

Имена связей

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

вопрос, является ли объект класса Person клиентом компании, е¨ сотрудником или владельцем? Чтобы определить это, ассоциацию можно назвать «employs» (нанимает): Company Person Employs

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

Проектирование диаграмм классов на Rose Delphi Link.

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

Заполнять массивы случайными числами в пределах от 1 до 10;
Вычислять сумму элементов каждого массива;
Определять среднее арифметическое значение элементов;
Очищать массивы (инициализировать их нулями).
Начнем с разработки пользовательского интерфейса в Delphi (рис. 4).

Рисунок 4. Интерфейс разрабатываемой программы

Сохраним этот проект с именами модулей, предлагаемыми Delphi по умолчанию, откроем новый проект Rational Rose, и запустим Delphi Rose Link. Выберем пункт меню Open Project, и откроем только что сохраненный в Delphi проект. В окне RDL отобразятся деревья объектов модели Rose и проекта Delphi (рис. 5).

Рисунок 5. Проект Delphi, открытый в RDL

Левое дерево объектов - это объекты модели Rose, правое дерево - это объекты, объявленные в исходном коде Delphi. Обратите внимание на красные восклицательные знаки слева от значков, обозначающих объекты. Они обозначают различия между кодом Delphi и моделью Rose. Сейчас отмечены все значки, так как модели в Rose пока еще вообще не существует.
Следующий шаг - генерация модели Rose по исходному коду. Для начала генерации нужно нажать кнопку Update All. В случае успешной генерации восклицательные значки у объектов исчезают, что означает, что модель Rose для каждого объекта соответствует исходному коду Delphi. Чтобы посмотреть историю сообщений генерации, надо выбрать пункт меню View -> Messages. В открывшемся окне будет отображен достаточно подробный лог сообщений RDL, выводимых при генерации модели или исходного кода.
Свернем Rose Delphi Link, и в браузере объектов Rose выберем ветку Logical View. Видим два появившиеся пакета: <>Unit1, который содержит объектную модель кода из модуля Unit1.pas, и External References, содержащий объекты Delphi, которые объявлены в модулях вне текущего проекта (объекты библиотеки VCL).
Теперь откроем в среде Rose диаграмму классов, соответствующую модулю Unit1 (Logical View -> Unit1 -> Overview). В первоначальном виде на диаграмме представлена немножко запутанная объектная модель, которую мы приведем в порядок, аккуратно расположив объекты согласно их иерархии (рис. 6).

Рисунок 6. Модель объектов модуля Unit1

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

Создадим новый модуль. Сделать это можно и в Delphi, и в Rose, и в RDL, но для чистоты эксперимента создавать все будем только в RDL. В Rose активизируем окно RDL и щелкнем правой кнопкой мыши по корневому элементу в дереве объектов модели Rose - в нашем случае это Model1.mdl. В контекстном меню выберем New -> Unit. Откроется окно редактора компонента (Component Editor) (рис. 7). На вкладке General указывается имя модуля (Unit2), и комментарий к создаваемому модулю, который при кодогенерации будет вставлен в модуль как комментарий. На вкладке Detail указывается вид (kind) компонента, и путь к исходному файлу. На вкладке Code Preview можно посмотреть код, который будет сгенерирован RDL для данного модуля. Выключение переключателя Allow Code/Model Updates запрещает генерацию кода и обновление модели для выбранного элемента.

Рисунок 7. Редактор компонента

После нажатия кнопки Ok видим, что в окне RDL появился значок, обозначающий новый модуль, и рядом с ним восклицательный знак, сигнализирующий о том, что модель Rose и код Delphi не синхронизированы. Обновим код Delphi, нажав кнопку Update All->. Теперь нужно переключиться на Delphi. Видим окно, предупреждающее, что модуль был изменен (рис. 8). Для загрузки обновленного модуля нажмем Ok.

Рисунок 8. Сообщение Delphi об изменении файла проекта

Теперь откроем только что сгенерированный модуль Unit2.pas. Можно убедиться, что генерация кода прошла успешно - объявлены все необходимые ключевые слова, вставлен комментарий. Следующий шаг - моделирование классов и их методов в этом модуле. Перейдем в Rose, и активизируем окно RDL. В дереве объектов выведем контекстное меню на объекте Unit2 и выберем пункты New -> Class. Появляется окно редактора класса (Class Editor) (рис. 9). На вкладке General нужно указать имя класса (Name), вид (Kind), видимость (Visibility) и комментарий к классу (Documentation). В нашем случае класс будет называться TMassiv, область видимости для него - Public.

Рисунок 9. Редактор класса

Для создания всех методов и атрибутов класса будем пользоваться пунктом меню New в контекстном меню класса в дереве объектов RDL. Редакторы атрибутов и методов в основном аналогичны редактору класса, поэтому подробности создания опустим. Создадим следующие атрибуты и методы (все методы с директивами видимости Public, атрибут M имеет видимость Private):
M: array [1..5, 1..5] of Integer; procedure Init; // Инициализация массива procedure FillMassiv; // Заполнение массива случайными числами procedure CalcSum; // Подсчет суммы элементов массива procedure CalcSr; // Подсчет среднего значения элементов массива function GetElement(X, Y: integer): Integer; // Получение элемента массива (x,y) Также создадим метод для класса TForm1, который будет заполнять компоненты TMemo, расположенные на форме, элементами из массивов:
procedure GetMassiv;

В создании методов с параметрами есть некоторая особенность. Сначала метод создается обычным способом, затем, в дереве объектов RDL, в контекстном меню на методе, для которого предлагается указать параметр, выбирается пункт New -> Parameter и указывается имя параметра, его тип и комментарий к нему. После создания класса обратите внимание на диаграмму классов для модуля Unit2 в Rose - наш класс отображен в соответствии со спецификацией UML (рис. 10).

Рисунок 10. Диаграмма классов с созданным классом

Итак, класс создан, точнее его оболочка, пока без реализации. Теперь в основном модуле Unit1 создадим два экземпляра этого класса. Объявим их как M1 и M2 в секции Public класса TForm1. Это делается выбором нужных пунктов в контекстном меню дерева объектов и указанием параметров в редакторе атрибутов. Измененная диаграмма, где в классе TForm1 показаны объявленные экземпляры класса, изображена на рис. 11.

Рисунок 11. Экземпляры класса, объявленные в секции public класса TForm1

Итак, модель построена, и теперь нужно сгенерировать окончательный код. В окне RDL жмем Refresh, Update All-> и переходим в среду Delphi. Теперь надо написать код, реализующий функциональность, и откомпилировать программу. При заполнении методов кодом иногда требуется добавить локальные или глобальные переменные. Это можно сделать в RDL, но лучше реализовать эти переменные в коде, а затем обновить модель Rose по исходному коду Delphi (Update All). Если в модели были удалены некоторые элементы, а в коде они уже реализованы, этот код заключается между директивами компилятора {$IFDEF DELETED} и {$ENDIF}. После реализации всего исходного кода в Delphi вернемся в RDL и еще раз выполним обратное проектирование, нажав Refresh и Update All. Класс TForm1 изменился - в нем появились методы - обработчики событий кнопок (рис. 12). В нашем случае это окончательный вариант диаграммы классов и всей модели в целом.

Рисунок 12. Окончательный вариант диаграммы классов для модуля Unit1

В рассмотренном примере мы следовали методике разработки приложений, предложенной разработчиком Rose Delphi Link, и в результате получили объектную модель системы. Все классы и диаграммы, описывающее деятельность системы были спроектированы в Rational Rose с помощью программы Rose Delphi Link. Итак, выделим основные преимущества совместного использования RDL и Rational Rose:

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

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

Диаграммы состояний. Состояния. События.

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

Состояния

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

имя - события список - параметров [ условие ] / действие

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

entry / действие - Действие, выполняемое при входе в состояние.

exit / действие - Действие, выполняемое при выходе из состояния.

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

Введено специальное ключевое слово do, обозначающее вызов вложенного автомата:

do / имя - автомата ( список - параметров )

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

Таблица 7.3. Обозначения элементов диаграммы состояний

t_7_3.gif (10227 bytes)

События

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

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

Сигналы определяются в следующем формате:

имя - события ( список - параметров )

каждый параметр имеет формат:

имя - параметра : тип

Сигналы могут образовывать иерархию наследования и, следовательно, изображаться с помощью диаграммы классов. Если на конечном автомате событие Х приводит к переходу из состояния в состояние, то любое производное событие от Х так же приводит к смене этому переходу. На диаграмме классов состояния изображаются с ключевым словом ?signal¦. Они не имеют методов поведения, могут иметь только атрибуты.

Диаграммы деятельности. Действия. Условия. Переходы. Полосы выполнения.

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

Диаграмма действий состоит из следующих элементов:

Таблица 7.4. Обозначение компонентов диаграммы действий.

t_7_4.gif (10090 bytes)

Действия

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

Условия

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

Переходы

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

Полосы выполнения

Диаграмма действий может быть разделена на полосы ( swim lanes ), которые включают в себя определенный набор действий и переходов. Каждая полоса имеет собственное имя и тем самым позволяет группировать действия в единое целое. Ее можно сравнить с пакетом для классов. Графически каждая полоса представляет собой вертикальное разделение диаграммы действий с помощью сплошной линии. Каждое действие может находиться только в одной полосе, тогда как переходы могут пересекать полосы.

Ниже представлен пример, на котором используются практически все возможные элементы диаграммы действий. Здесь обсуждается процедура обслуживания клиента узла Internet, подающего заявку на обслуживания. Заявка может быть двух типов: заявка на регистрацию и заявка на предоставление некоторой услуги. Диаграмма содержит две полосы ?клиент¦ и ?отдел обслуживания¦. После получения запроса на обслуживание клиент может подготовить платеж, а отдел обслуживания займется одновременно с этим выполнением заказа. В зависимости от типа запроса будет выполнено либо действие ?создать услугу¦ либо действие ?заполнить карточку регистрации¦. Далее будет выполнена подготовка документов и после выполнения платежа, он будет учтен и обслуживание закончится.

Рис. 7.22. Пример диаграммы действий.

Диаграммы реализации. Диаграммы компонентов.

Диаграммы реализации предназначены для отображения состава компилируемых и выполняемых модулей системы, а так же связей между ними. Диаграммы реализаций разделяются на два конкретных вида: диаграммы компонентов ( component diagrams ) и диаграммы развертывания ( deployment diagrams ).

Диаграммы компонентов

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

зависимость - это зависимость любого типа ( использование, совместная компиляция ),
композиция - это включение одних компонентов в состав других.

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

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

Ниже ( рис. 7.23 ) представлен пример диаграммы компонентов, состоящий из компонентов ?графический редактор¦ и ?оконная система¦. Оконная система зависит от интерфейса ?нарисовать¦, имеющегося у компонента ?графический редактор¦.

Рис. 7.23. Пример диаграммы компонентов

Диаграммы реализации. Диаграммы размещения.

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

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

имя типа,

в случае узла - экземпляра имя выглядит так:

имя узла : имя типа.

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

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

Ниже на рисунке (рис.7.24) представлен пример, состоящий из трех вычислительных систем, представляющих типичный случай системы доступа к базам данным на основе Internet/Intranet технологии, которая предполагает наличие двух компьютеров, один из которых выполняет функции web - сервера с возможностью исполнения ASP или CGI, который готовит данные для отображения на компьютере клиента. Для подготовки отображаемых данных web - сервер, в лице компонента ?исполнение ASP программ¦, выполняет запросы к SQL - серверу, который хранит данные и обрабатывает их. Все это делается по запросу с клиентского компьютера и на него же посылаются результаты запросов в подготовленном для отображения виде ( HTML ).

Рис. 7.24. Пример диаграммы развертывания

Количественная оценка диаграмм.

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

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

Количественную оценку диаграммы можно провести по следующей формуле:

где S - оценка диаграммы;

S_Obj оценки для элементов диаграммы;

S_Lnk оценки для связей на диаграмме;

O_bj- число объектов на диаграмме;

T_obj - число типов объектов на диаграмме;

Т_Lnk - число типов связей на диаграмме.

Если диаграмма содержит большое число связей одного типа (например, модель БД), то число и тип связей можно не учитывать и формула расчета приводится к виду:

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

Где, S_ds - оценка операций и атрибутов для класса;

О_р- число операций у класса,

A_rt - число атрибутов у класса.

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

Таблица 1 - Основные элементы языка UML

Тип элемента	Оценка для элемента
Класс (class)	5
Прецедент (use case)	2
Компонент (component)	4
Актер (actor)	5
Узел (node)	3
Взаимодействие (interaction)	6
Пакет (package)	4
Состояние (state)	4
Примечание (node)	2

Таблица 2 - Основные типы связей языка UML

Тип связи	Оценка для связи
Зависимость (dependency)	2
Ассоциация (association)	1
Агрегирование (aggregation)	2
Композиция (composition)	3
Обобщение (generalization)	3
Реализация (realization)	2

Остальные типы связей должны рассматриваться как ассоциации.

Недостатком диаграммы является как слишком низкая оценка (при этом диаграмма недостаточно информативна), так и слишком высокая оценка (при этом диаграмма обычно слишком сложна для понимания). В таблице 3 приведены диапазоны оптимальных оценок для основных типов диаграмм.

Таблица 3 - Диапазоны оптимальных оценок для диаграмм UML

Тип диаграммы	Диапазон оценок
Классов (class) - с атрибутами и операциями	5-5,5
Классов (class) - без атрибутов и операций	3-3,5
Компонентов (component)	3,5 -4
Вариантов использования (use case)	2,5-3
Развертывания (deployment)	2-2,5
Последовательности (sequences)	3-3,5л
Кооперативная (cooperative)	3,5-4
Пакетов (package)	3,5-4
Состояний (state)	2,5-3.

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

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

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

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

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

Интерфейс свободной навигации (6UJ). WYSJWJG (what you see is what you get)

Разработка пользовательских интерфейсов. Этапы разработки интерфейсов.

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

Психологические особенности человека

Особенности связанны с восприятием отображением и запоминанием информации.

В каждыи момент времени фокус внимания может фиксироваться в одной точке. Краткосрочная память – емкость 7+- 2 несвязных обьекта невостребованная инфолрмация хранится не боле 30сек. Мнемоника - наука занимающаяся ассоциативной памятью.

Особенности восприятия цвета

Особенности восприятия звука

Субъективное восприятие времени доказано что при ожидании 1-2сек

Тестирование программного обеспечения. Виды контроля качества ПО. Формирование тестовых наборов. Ручной контроль ПО.

Тестирование программного продукта – это процесс выполнения программы целью которой явл. выявление ошибок.

Зависимость вероятности правильного исправяления и его стоимости от этапа разработки (отн к рисунку).

Выделяют 3 вида тестирования:

1. Автономное тестирование компонентов ПО.

2. Комплексное тестирование

3. Системное или оценочное тестирование в соответствии с основными криетриями качества.

Для повышения качества тестирование рекомендуется соблюдать слде принципы:

1. Предлагаемые результаты должны быть известны до тестирования

2. Следует избегать тестирование программы автором

3. Необходимо досконально изучить результаты каждого теста

4. Необходимо проверять действие программы на неверных результатах.

5. Необходимо проверять программу на счет неожиданных эффектов.

Формирование тестовых наборов

Сущ. 2 подхода тестовых наборов:

1. Структурированный подход

2. Функциональный подход

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

Функциональный подход основывается на том что структура ПО неизвестна («Черный ящик»). В этом случае тесты строят опираясь на опираясь на функциональной спецификации.

Ручной контроль

Различ. след. методы ручного контроля:

1.Инспеция

2.Сквозные просмотры.

3. Проверка за столом

4. Оценка

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

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

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

Тестирование программного обеспечения. Структурное тестирование.

Тестирование программного продукта – это процесс выполнения программы целью которой явл. выявление ошибок.

Зависимость вероятности правильного исправяления и его стоимости от этапа разработки (отн к рисунку).

Выделяют 3 вида тестирования:

1. Автономное тестирование компонентов ПО.

2. Комплексное тестирование

3. Системное или оценочное тестирование в соответствии с основными криетриями качества.

Для повышения качества тестирование рекомендуется соблюдать слде принципы:

1. Предлагаемые результаты должны быть известны до тестирования

2. Следует избегать тестирование программы автором

3. Необходимо досконально изучить результаты каждого теста

4. Необходимо проверять действие программы на неверных результатах.

5. Необходимо проверять программу на счет неожиданных эффектов.

Структурное тестирование

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

procedure m(a,b: real; var x:real)

begin

if(a>1)and (b=0) then x:=x/a

if (a=2) or (x>1) then x:=x+1;

end;

Граф передачи управления

Формирование тестовых наборов для тестирования маршрутов может осуществляться по нескольким критериям:

1. Покрытие оператора

2. покрытие решения (переходов)

3. Покрытие условий

4.Покрытие решений/ условий

5. Комбинаторное покрытие условий

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

a=2 b=0 x=3

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

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

b=0 b?0, a=2, 0?2, x>1 x?1

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

Необходимо покрыть тестами восемь комбинаций

1) a>1, b=0

2)a>1, b?0

3) a?1, b=0

4)a?1, b<0

5)a=2, x>1

6)a=2, x<1

7)a?2, x>1

8)a?2, x?1

Эти комбинации можно проверить четырьмя тестами

1) a=2 ,b=0,x=4 (1,5)

2) a=2 ,b=1,x=1 (2,6)

3) a=1 ,b=0,x=2 (3,7)

4) a=1 ,b=1,x=1 (4,8)

Тестирование программного обеспечения. Функциональное тестирование.
Отладка ПО. Классификация ошибок.

Отладка – это процесс локализации и исправления ошибок обнаруженных при тестировании ПО.

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

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

Выделяют следующие виды ошибок:

Синтаксические ошибки – ошибки фиксируемые компилятором при выполнении синтаксического и частично семантического анализа программы.

Ошибки компоновки – ошибки обнаруженные компоновщиком при объединении модулей программы.

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

Неверное определение исходных данных происходит если возникают ошибки при выполнении операции ввода вывода.

Логические ошибки – имеют разную природу они могут следовать из ошибок допущенных при проектировании, выборе метода.

Определение структуры классов ошибки не корректного использования переменных:

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

Ошибки вычислении:

Не корректное использование целочисленной арифметики

Некорректное вычисление неарифметических переменных

Методы отладки

Метод ручного тестирования
Метод индукции
Метод дедукции
Метод обратного исследования

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

Составление программной документации. Виды программных документов.
Архитектура современных ИС.

Арихитектура современных ИС св трехлинейной и имеет следующие характеристики

Четко определенные слои
Формальные и явные интерфейсы между слоями
Скрытые защищенные детали внутри каждого слоя

Пользователь

Документы

Бизнес правила

База данных

ОС

Рис.1 Прикладная архитектура ИС

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

Слои	Анализ	Проектирование	Реализация
Бизнес правила	Поток процессов	Модель компонентов	Программы
База Данных	Моель Данных	Схема БД	таблица

Анализ требование: В слое «документы» рассматриваются обобщенные потоки между подразделениями и конкретными сотрудниками предприятиями без подробного описания каких-либо учетных форм и интерфейсов.

На уровне БД отроится концептуальная модель увязанная с функциональной моделью требований на уровне укрупненных бедующей информационной модели.

Проектирование: На уровне документа (шокитируется) послежовательность форм. На уровне бизнес-правила осуществляется детальное проектирование будущих рабочих мест с привязкой модели к конкретным сущностям информационной модели. На уровне БД концептуальная модель преобразуется в диаграмму «Сущность - связь».

Реализация: на данном этапе проект преобразуется с сметешу.

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

Паттерн – это описание взаимодействия объектов и классов адаптированных для решения общей задачи проектирования в конкретном контексте. Паттерны выявляются по мере накопления опыта работы.

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

Типы шаблонов проектирования.

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

List alist=new array list;

Iterator ID=alist.iterator();

While(ID.next())

String ST=(string)ID.next();

Для классов List, map, collection,set

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

Команда
Наблюдатель
Посетитель
Посредник
Переключатель

Шаблон switch.