3. Вторая фаза жизненного цикла - конструирование системы

3.1. Разработка архитектуры системы

3.1.1. Разбиение системы на модули 3.1.2. Выявление асинхронного параллелизма 3.1.3. Распределение модулей и подсистем по процессорам и задачам 3.1.4. Управление хранилищами данных 3.1.5. Управление глобальными ресурсами 3.1.6. Реализация управления программным обеспечением 3.1.7. Пограничные ситуации 3.1.8. Обзор архитектур прикладных систем

3.2. Архитектура системы управления банковской сетью

3.3. Разработка объектов

3.3.1. Совместное рассмотрение трех моделей 3.3.2. Разработка алгоритмов, реализующих полученные операции 3.3.3. Оптимизация разработки 3.3.4. Реализация управления 3.3.5. Уточнение наследования классов 3.3.6. Разработка зависимостей

4. Сравнительный анализ объектно-ориентированных методологий разработки программных систем

4. 1. Методология OMT 4.2. Методология SA/SD 4.3. Методология JSD 4.4. Методология OSA

5. Третья фаза жизненного цикла - реализация объектно-ориентированного проекта

5.1. Объектно-ориентированный стиль программирования

5.2. Объектно-ориентированные системы программирования

5.3. Реализация на языке C++

5.3.1. Реализация классов 5.3.2. Порождение объектов 5.3.3. Вызов операций 5.3.4. Использование наследования 5.3.5. Реализация зависимостей 5.3.6. Шаблоны в языке C++

5.4. Другие объектно-ориентированные системы программирования

5.4.1. Реализация классов 5.4.2. Порождение объектов 5.4.3. Вызов операций 5.4.4. Реализация наследования 5.4.5. Реализация зависимостей

5.5. Не объектно-ориентированные системы программирования

5.5.1. Преобразование классов в структуры данных 5.5.2. Передача параметров методам 5.5.3. Размещение объектов в памяти 5.5.4. Реализация наследования 5.5.5. Выбор методов для операций 5.5.6. Реализация зависимостей 5.5.7. Объектно-ориентированное программирование на Фортране 5.5.8. Чем неудобны не объектно-ориентированные системы программирования

1. Основные понятия объектно-ориентированного подхода

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

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

Рис. 1.1. Семантика (смысл программы с точки зрения выполняющего ее компьютера) и прагматика (смысл программы с точки зрения ее пользователей)

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

Таким образом, объектно-ориентированный подход помогает справиться с такими сложными проблемами, как

• уменьшение сложности программного обеспечения;

• повышение надежности программного обеспечения;

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

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

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

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

Рис. 1.2. Жизненный цикл программной системы

Объектно-ориентированный подход имеет два аспекта:

• объектно-ориентированная разработка программного обеспечения;

• объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированное проектирование Принципы объектно-ориентированного проектирования Объектно-ориентированный анализ и проектирование (ООАП) - конструктивное использование языка UML основывается на понимании общих принципов моделирования сложных систем и особенностей процесса объектно-ориентированного анализа и проектирования в частности. Выбор выразительных средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей сложных систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели. Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты сложной системы. Применительно к методологии ООАП это означает, что достаточно полная модель сложной системы допускает некоторое число взаимосвязанных представлений (views), каждое из которых адекватно отражает некоторый аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые в свою очередь могут подразделяться на другие более частные представления.) феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы. Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы. Рис.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования Таким образом, процесс ООАП можно представить как поуровневый спуск от наиболее общих моделей и представлений концептуального уровня к более частным и детальным представлениям логического и физического уровня. При этом на каждом из этапов ООАП данные модели последовательно дополняются все большим количеством деталей, что позволяет им более адекватно отражать различные аспекты конкретной реализации сложной системы. Общая схема взаимосвязей моделей ООАП представлена на примере. Классы и их свойства. Диаграммы классов Класс имеет следующий внешний вид: Рис2. Пример структуры класса Рис3. Пример классов Классы – это описания совокупности объектов с общими атрибутами, операциями, отношениями (у каждого класса обязательно есть имя). Имя бывает простое и составное. Составное – состоит из: имени пакета и названия класса. Атрибут – это именованное свойство класса, включающее описание множества значений, которые могут принимать экземпляры этого класса, при описании атрибута можно указать его тип и начальные значения, принятые системой по умолчанию. Операция – это реализация услуг которые можно запросить у любого объекта класса для воздействия на его поведение, т. е. это абстракция того, что позволено делать с объектом. У операций можно указывать сигнатуру, в которую входят имена всех параметров, значения принятые по умолчанию, а по отношению к функциям еще и тип возвращаемого значения. Класс может быть абстрактным, т. е. не иметь экземпляров и объектов. Имя для него записывается курсивом. Если надо указать пакет, к которому относится класс, то используется составное имя(Например: Банк :: Счет). Абстрактные классы создаются на диаграмме в качестве резерва для последующей расшифровки, во второй сверху секции прямоугольника записываются атрибуты в виде отдельной строки. <квантор видимости><имя атрибута [кратность]>:<тип атрибута>= <исходное значение>{строка – свойство} Область видимости:

• public (общий открытый) атрибут виден всем остальным классам любой класс может посмотреть или изменить этот атрибут. В нотации UML обозначается («+»)

• protected (защищенный) атрибут доступен только самому классу или его потомкам («#»)

• private (закрытый, секретный) атрибут не виден ни каким другим классам, но другой класс может попросить у данного разрешение на просмотр или изменение значения атрибута («-»)

• package of Implementation (пакетный) атрибут является общим, но только в пределах своего пакета.

Диаграмма классов – включает классы, интерфейсы и их отношения. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. При описании системы классы автономно не существуют, следовательно, их необходимо описывать их взаимодействия. При моделировании системы не только выделяют сущности, но и описывают отношения между ними (см. ниже «Отношения и их свойства»). Объекты и их свойства. Диаграммы объектов Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. В силу самых различных причин может возникнуть необходимость показать взаимосвязи не только между классами модели, но и между отдельными объектами, реализующими эти классы. В данном случае может быть разработана диаграмма объектов, которая, хотя и не является канонической в метамодели языка UML, но имеет самостоятельное назначение. Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются. При этом запись имени объекта представляет собой строку текста "имя объекта: имя класса", разделенную двоеточием. Имя объекта может отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает на данное обстоятельство. Отсутствовать может и имя класса. Тогда указывается просто имя объекта. Атрибуты объектов принимают конкретные значения. Рис.4.Пример графического изображения объектов на диаграммах языка UML В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они получают. Активный объект (active object) имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами. При этом под нитью понимается некоторый облегченный поток управления, который может выполняться параллельно с другими вычислительными нитями или нитями управления в пределах одного вычислительного процесса или процесса управления. Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней. Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X". Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий. Рис.5. Графическое изображение различных вариантов линий жизни Пакеты: видимость, импорт и экспорт, обобщения Пакет (package) – это часть модели. Любая такая часть модели может принадлежать только одному пакету. разработчик может распределить содержание модели по целому набору пакетов. При этом распределение по пакетам должно производится с учетом сходства функций элементов и их взаимосвязей при реализации в программном коде. В пакетах содержатся высокоуровневые элементы модели. Одни пакеты могут содержать в себе другие. В модели имеется также корневая папка которая содержит в себе все ее содержимое. пакеты можно также организовывать: по виду модели, по функциональности или по любому другому признаку, который выберет разработчик. Пакеты – это иерархически организованные блоки UML-модели. Набор пакетов, на которые разбита модель, отображает архитектуру всей системы (ее деление на подклассы и зависимости между ними). Зависимость Зависимости существуют между единичными элементами, однако они должны находить отражение и на высоком уровне проектирования. Зависимость между пакетами указывает на то, что между единичными элементами этих пакетов существует (при восходящем подходе) или допускается к существованию (при нисходящем подходе) как минимум одно отношение такого типа деятельности:

• Нисходящий подход – отражает архитектуру всей системы

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

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

1. facado – определят пакет, который является лишь представлением другого пакета

2. framework – определяет пакет состоящий из образов

3. stub - определяет пакет служащий заместителем открытого содержимого другого пакета

4. subsystem - определяет пакет представляющий часть моделируемой системы

5. system – определяет пакет представляющий всю моделируемую систему .

6. import - отношение зависимости между пакетами, один из которых импортирует другой.

Моделирование пакетов:

1. найти семантические и концептуально близкие элементы системы

2. объединить в один пакет

3. определить видимость пакета

4. определение импорта, использовать с теми пакетами, от которых есть зависимость

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

6. сбалансировать количество элементов в пакете

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

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

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

Рис.6. Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_Л и Класс_Б) У зависимости может быть: имя(указывает на роль которую она исполняет в моделировании); стереотип (обозначает её истинную природу, а также подробное текстовое описание). Виды зависимости:

• Доступ «access» - пакет имеет доступ к содержимому другого пакета

• Вызов «call» - метод одного класса вызывает операцию другого класса

• Вывод «derive» - один экземпляр может быть вычислен на основе информации представленной другим экземпляром

• Дружественность «friend» - элемент имеет доступ к содержимому другого пакета и добавляет имена из пространства имен этого пакета в пространство имен импортера

• Отправка «send» - отношение между объектом, который принимает сообщение и объектом, который этот сигнал получает

• Трассировка «trace» - используется для гарантии выполнения моделями системных требований и отслеживания тех изменений, которые могут повлиять на другие модели

• Использование «use» - одному элементу для правильного функционирования нужны услуги другого элемента

Рис.7. Пример зависимости Обобщение:

• Это отношение между общей сущностью и конкретным видом

• Это отношение типа «is a», т. е. когда одна сущность является частным выражением более общей

• Потомок наследует свойства родителей (атрибуты, операции)

• Можно создать классы имеющие любое число родителей (множественное наследование)

Рис.8. Графическое изображение отношения обобщения в языке UML Рис.9. Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий