Программная инженерия

Проектирование ПО – логически сложная, трудоемкая и длительная работа. В начале 70-х годов в США был отмечен кризис программного обеспечения. Это проявилось в том, что большие проекты стали выполняться с отставанием от графика или с превышением сметы расходов. Программный продукт не обладал требуемыми функциональными возможностями, производительность его была низкой, качество не устраивало потребителя. Аналитические исследования и обзоры, которые провели аналитики оказались не слишком обнадеживающими. После анализа более 23 000 проектов оказалось: только 16,5% проектов завершились в срок и не превысили плановые затраты; 52,7% проектов завершились с опозданием, а расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были закрыты до завершения. В среднем бюджет среднего проекта превышался на 89%, а срок выполнения на 122%.

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

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

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

Проектирование ПО является формальным процессом, который можно изучать и совершенствовать.

Современные крупные проекты имеют следующие особенности:

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

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

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

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

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

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

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

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

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

СУЩНОСТЬ ОБЪЕКТНО – ОРИЕНТИРОВАННОГО

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

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

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

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

Кроме основных, имеются три дополнительных элемента, которые не являются обязательными:

типизация
параллелизм
устойчивость

Абстрагирование

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

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

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

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

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

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

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

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

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

Устойчивость – это свойство объекта существовать во времени и/или пространстве. Во времени – это вне зависимости от процесса, создавшего данный объект, в пространстве – это при перемещении объекта из адресного пространства, в котором он был создан.

Объект

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

Индивидуальность – это характеристика объекта, которая отличает его от всех других объектов.

Состояние объекта – это перечень всех свойств объекта и текущие значения каждого из этих свойств.

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

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

Стул

Стоимость

Вес Свойства

Размеры

Цвет

Положение

Купить()

Продать() Операции

Взвесить()

Переместить()

Покрасить()

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

модификатор (изменяет состояние объекта)
селектор (дает доступ к состоянию, но не изменяет его)
итератор (доступ к содержанию объекта по частям, в строго определенном порядке)
конструктор (создает объект и инициализирует его состояние)
деструктор (разрушает объект и освобождает занимаемую им память)

Примеры операций

Модификатор	пополнеть (кг)
Селектор	какойвес():integer
Итератор	показатьАссортиментТоваров ():string
Конструктор	создатьРобот (параметры)
Деструктор	уничтожитьРобот ()

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

Виды отношений между объектами

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

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

Агрегация. Связи обозначают равноправные отношения между объектами. Агрегация обозначает отношения объектов в иерархии «целое/часть». Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (свойствам).

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

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

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

Класс

Интерфейсные части:

Публичная

Защищенная

Приватная

Реализация

Интерфейс может быть разделен на три части:

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

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

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

Виды отношений между классами

Всего существует четыре основных вида отношений между классами:

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

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

ассоциация
наследование
агрегация
зависимость
конкретизация
метакласс
реализация

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

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

Конкретизация - это разновидность отношения обобщение – специализация. Применяется в некоторых языках программирования.

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

Реализация - это отношение, при котором класс – приемник обеспечивает свою собственную реализацию интерфейса другого класса – источника. Здесь речь идет о наследовании интерфейса.

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

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

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

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

UML – это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования (Java, C++, Visual Basic, Ada95, Object Pascal) и даже в таблицы для реляционной базы, поэтому UML называют визуальным языком моделирования.

Главными при разработки языка UML были следующие цели:

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

Создателями UML считаются Гради Буч, Джеймс Рамбо, Ивар Якобсон. Разработки велись в компании Rational Software. Язык UML принят всеми крупнейшими компаниями – производителями ПО. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, технических, организационных, экономических и других.

В языке UML используются: предметы, отношения и диаграммы.

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

Предметы в UML

В UML имеются четыре разновидности предметов:

структурные предметы
предметы поведения
группирующие предметы
поясняющие предметы

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

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

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

Человек

Имя

Возраст

Вес

Родиться()

Креститься()

Поправиться()

Похудеть()

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

IУчеба

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

Обслуживание клиента

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

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

Обработка заказов

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

ЦентрУправления

Запустить()

Остановить()

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

Proxy.cpp

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

Бизнес-логика

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

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

display

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

Регулирование
Эти два элемента – взаимодействия и конечные автоматы являются базисными предметами поведения, они могут включаться в UML-модели. Семантически (по смыслу) взаимодействия и конечные автоматы объединяются со структурными элементам, такими как классы, кооперации, объекты.

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

Интерфейсные эл-ты

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

Критичная по

длительности

следующая страница >>