Агрегация

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

Рис. 2.15. Агрегация

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

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

Рис. 2.16. Примеры агрегации

| |

Comments:

Атрибуты зависимостей

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

Рис. 2.10. Пример атрибута зависимости

Еще один пример зависимостей, имеющих атрибуты, показан на рисунке 2.11. Из примера видно, что зависимость может иметь несколько атрибутов. Кроме того, на рисунке 2.11 указаны роли различных объектов в зависимости (подробнее см. ниже). Зависимость руководит на этом рисунке удобнее именовать как начальник-сотрудник.

Рис. 2.11. Атрибуты двух зависимостей между одним и многими

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

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

Рис. 2.12. Представление зависимости в виде класса

| |

Comments:

Динамическая модель системы или подсистемы

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

| |

Comments:

Функциональная модель подсистемы

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

| |

Comments:

Имена ролей, квалификаторы

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

На рисунке имена начальник и сотрудник в зависимости руководит - это имена ролей; как уже было отмечено, эту зависимость удобнее назвать начальник-сотрудник. Еще один пример имен ролей показан на рисунке 2.13.

Рис. 2.13. Имена ролей

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

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

Квалификатором называется некоторый атрибут, который позволяет снизить эффективную кратность зависимости. Квалификаторы применяются в зависимостях типов "один-ко-многим" или "много-ко-многим". Так в примере, показанном на рисунке 2.14, использование квалификатора имя_файла позволяет привести зависимость дает_доступ от вида, приведенного на рисунке 2.14(а), к виду, показанному на рисунке 2.14(б), сократив число зависимых объектов до одного. Еще один пример использования квалификатора показан на рисунке 2.14(в): использование квалификаторов и здесь позволяет сократить кратность зависимости до одного объекта. Квалификаторы указываются на схемах в прямоугольничках, пририсованных к прямоугольнику, изображающему соответствующий класс.

Рис. 2.14. Использование квалификаторов

Рисунок 2.14(в) может быть проинтерпретирован следующим образом: центральный компьютер + код_ATM определяют конкретную ATM (отметим, что код_ATM - имя одного из атрибутов класса ATM, а не класса центральный_компьютер); аналогично центральный_компьютер + код_банка определяют конкретный компьютер банка. Использование квалификаторов повышает точность описания семантики и наглядность описания зависимостей.

| |

Comments:

Объектная модель системы

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

| |

Comments:

Операции и методы

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

Рис. 2.2. Другие примеры классов

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

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

Каждой операции соответствует метод - реализация этой операции для объектов данного класса. Таким образом, операция - это спецификация метода, метод - реализация операции. Например, в классе файл может быть определена операция печать (print). Эта операция может быть реализована разными методами: (а) печать двоичного файла; (б) печать текстового файла и др. Логически эти методы выполняют одну и ту же операцию, хотя реализуются они разными фрагментами кода.

Каждая операция имеет один неявный аргумент - объект к которому она применяется. Кроме того, операция может иметь и другие аргументы (параметры). Эти дополнительные аргументы параметризуют операцию, но не связаны с выбором метода. Метод связан только с классом и объектом (некоторые объектно-ориентированные языки, например C++, допускают одну и ту же операцию с разным числом аргументов, причем используя то или иное число аргументов, мы практически выбираем один из методов, связанных с такой операцией; на этапе предварительного проектирования системы удобнее считать эти операции различными, давая им разные имена, чтобы не усложнять проектирование).

Операция (и реализующие ее методы) определяется своей сигнатурой, которая включает, помимо имени операции, типы (классы) всех ее аргументов и тип (класс) результата (возвращаемого значения).
Все методы, реализующие операцию должны иметь такую же сигнатуру, что и реализуемая ими операция. Операции перечисляются в третьей части прямоугольника (), описывающего класс. Каждая операция должна быть представлена своей сигнатурой, однако на ранних стадиях проектирования можно ограничиваться указанием имени операции, отложив полное определение сигнатуры на конец рассматриваемой фазы жизненного цикла (либо даже на последующие фазы). В графическом языке технологии OMT тип любого объекта данных указывается вслед за именем этого объекта после двоеточия (как в языке Паскаль). При моделировании системы полезно различать операции, имеющие побочные эффекты (эти эффекты выражаются в изменении значений атрибутов объекта, т.е. в изменении его состояния), и операции, которые выдают требуемое значение, не меняя состояния объекта. Эти последние операции называются запросами. Значения некоторых атрибутов объекта могут быть доступны только операциям этого объекта. Такие атрибуты называются закрытыми. На рисунке 2.3 показаны закрытые атрибуты для объектов класса счет. Значения закрытых атрибутов объекта можно узнать вне объекта только в том случае, если среди операций этого объекта определены соответствующие запросы. Аналогично, в объекте можно определить и закрытые (вспомогательные) операции, однако на ранних стадиях проектирования этого, как правило, не делают, так как выделение закрытых операций связано, в основном, с реализацией системы.

Рис 2.3. Открытые и закрытые атрибуты и операции

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

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

ИМЯ_КЛАССА

имя_атрибута 1: тип_1 = значение_по_умолчанию_1
имя_атрибута 2: тип_2 = значение_по_умолчанию_2
. . . . . . . . . . . . . . .

имя_операции_1 (список_аргументов_1): тип_результата
сигнатура_операции_2
сигнатура_операции_3
. . . . . . . . . . . . . . . .

Рис. 2.4. Полное представление объекта в OMT

Рис. 2.5. Возможные классы для системы AMT (банковское обслуживание)

| |

Comments:

Copyright ©

Первая фаза жизненного цикла

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

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

Модели помогают:

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

В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. Мы подробно ознакомимся с одной из таких технологий - OMT (Object Modeling Techniques). Эта технология оказала большое влияние на других разработчиков объектно-ориентированных технологий, а книга, в которой она описана, является одной из наиболее часто цитируемых книг по данному направлению. Более того, система обозначений (графический язык) для описания моделей, предложенная в этой книге, широко применяется в других технологиях и в статьях по объектно-ориентированной разработке программных систем.

В технологии OMT проектируемая программная система представляется в виде трех взаимосвязанных моделей:

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

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

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

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

| |

Comments:

Понятие подсистемы

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

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

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

Наряду с внутренним окружением системы можно определить ее внешнее окружение. Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, различных редакторов, системы управления базами данных и т.п.), а также в других прикладных системах и библиотеках, используемых совместно с системой. Объекты и операции, составляющие внешнее окружение системы, тоже могут быть доступны внутри системы. Чтобы не упустить этого из виду, можно было бы добавить в объектную модель еще один объект, интерфейс которого представлял бы возможности внешнего окружения, используемые в системе (такой интерфейс обычно представляет лишь часть возможностей внешнего окружения).
Но это было бы не совсем точно, так как внешнее окружение реализуется не одним, а несколькими объектами. С другой стороны внутри системы нет резона рассматривать структуру ее внешнего окружения. Выход из указанного противоречия во введении в рассмотрение еще одной сущности - подсистемы. Подсистема - это набор объектов и подсистем, обеспечивающих некоторую функциональность, и взаимодействующих между собой в соответствии с их интерфейсами. Интерфейс подсистемы представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может входить один, или более взаимозависимых объектов и/или подсистем. Множество интерфейсов объектов (и подсистем), которые в своей совокупности составляют некоторую подсистему, составляет внутреннее окружение этой подсистемы. В состав каждой подсистемы должна быть включена подсистема окружение, представляющая внешнее окружение этой подсистемы. Подсистема окружение для системы банковского обслуживания, рассматриваемой в качестве сквозного примера представлена на рисунке 2.41. Интерфейс подсистемы окружение определяет в каком программном окружении будет работать проектируемая система и какие возможности этого окружения будут использоваться во время ее работы (это важно, когда возникает потребность модификации или замены отдельных компонентов окружения). Отметим, что подсистема окружение представляет только интерфейс системы банковского обслуживания с ее внешним окружением. Внешнее окружение системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже может быть разработана объектная модель, которая может содержать и разрабатываемую систему (в этой объектной модели она будет одной из подсистем). Объектную модель системы банковского обслуживания и ее системного (внешнего) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав этой объектной диаграммы будут входить не объекты, а только подсистемы; каждая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами).

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

Рис. 2.41. Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением

Рис. 2.42. Объектная диаграмма банковской сети и ее системного окружения

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

Comments:

Copyright ©

Построение объектной модели

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

; ; ; ; ; .

| |

Comments:

Пример объектной модели

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

| |

Comments:

Заключительные замечания к разделу

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

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

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

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

| |

Comments:

Зависимости между классами (объектами)

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

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

Рис. 2.6. Зависимости между классами

Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 2.6 имя зависимости имеет_столицу предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является_столицей. Точно таким же образом, во втором примере на рисунке 2.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.

В языках программирования зависимости между классами (объектами) обычно реализуются с помощью ссылок (указателей) из одного класса (объекта) на другой. Представление зависимостей с помощью ссылок обнаруживает тот факт, что зависимость является свойством пары классов, а не какого-либо одного из них, т.е. зависимость - это отношение.
Отметим, что хотя зависимости между объектами двунаправлены, их не обязательно реализовать в программах как двунаправленные, оставляя ссылки лишь в тех классах, где это необходимо для программы. Дальнейшие примеры зависимостей между классами приведены на рисунке 2.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 2.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь. Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 2.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 2.9 показаны зависимости между объектами для примеров, изображенных на рисунке 2.7.

Рис. 2.7. Дальнейшие примеры зависимостей. Обозначения

Рис. 2.8. Зависимости между объектами

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

Рис. 2.9. Более сложные зависимости между объектами

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

Comments:

Copyright ©

Методология JSD

Методология JSD (Jackson Structured Development) предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80-х годов, особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. На этом этапе решается вопрос "что должно быть сделано"; вопрос "как это должно быть сделано" решается на следующем этапе - этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени.

Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT.

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

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

На фазе разработки действий и объектов разработчик, руководствуясь внешними требованиями к проектируемой системе, составляет перечень сущностей (объектов) и действий реального мира, связанных с этой системой. Так например, проектируя систему управления двумя лифтами в шестиэтажном доме, можно выделить два объекта "лифт" и "кнопка" и три действия - "нажатие кнопки", "лифт приходит на этаж n" и "лифт покидает этаж n". И объекты, и действия взяты из реального мира, а не искусственно введены в рассмотрение проектировщиком.
Все действия являются атомарными (неразложимыми на поддействия) и происходят в фиксированные моменты времени. На фазе разработки структуры объектов действия каждого объекта частично упорядочиваются во времени. Так, в рассматриваемом примере действия "лифт приходит на этаж n" и "лифт покидает этаж n" должны чередоваться: два действия "лифт приходит на этаж n" не могут идти одно за другим. Фаза разработки исходной модели связывает реальный мир с абстрактной моделью, устанавливая соответствие между вектором состояния и потоком данных. Вектор состояния обеспечивает "развязку" по управлению; так в примере с лифтами первая же нажатая кнопка вверх установит значение переключателя (флажка) "вверх" после чего лифт не будет реагировать на дальнейшие нажатия кнопок вверх, так что нажатие кнопки вверх один или пять раз приведет к одинаковому результату. Аналогично, поток данных позволяет обеспечить "развязку" по данным: примером может служить буфер файла. На фазе разработки функций с помощью специального псевдокода устанавливаются выходные данные каждого действия. Для системы управления лифтами примером функции является переключение лампочек на панели лифта при прибытии лифта на очередной этаж. На фазе разработки временных ограничений решается вопрос о допустимых временных отклонениях системы от реального мира. В результате получается множество временных ограничений. В примере с лифтами одним из временных ограничений будет решение вопроса о том, как долго нужно нажимать на кнопку лифта, чтобы добиться его реакции. Наконец, на фазе реализации системы решаются проблемы управления процессами и распределения процессов по процессорам. Методология JSD может быть названа объектно-ориентированной с большой натяжкой: в ней почти не рассматривается структура объектов, мало внимания уделяется их атрибутам. Некоторые действия в смысле методологии JSD являются, по существу, зависимостями между объектами в смысле методологии OMT. Тем не менее, методология JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:

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

Методология JSD плохо приспособлена для решения следующих проблем:

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

| |

Comments:

Copyright ©

Методология OMT

Методология OMT (Object Modeling Technique), достаточно подробно рассмотренная в разделах и , поддерживает две первые стадии разработки программных систем. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+.

| |

Comments:

Методология OSA

Методология OSA (Object-Oriented System Analysis) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.

Методологии объектно-ориентированного анализа нередко критикуются за то, что они являются больше реализационно-ориентированными, чем проблемно-ориентированными, обеспечивая больше предварительную разработку, чем анализ требований к системе. Действительно, все рассмотренные методологии (такие, как OMT, SA/SD, JSD) поддерживают прежде всего предварительную разработку программных систем, а не анализ требований к ним. Это следует из таблиц 4.1 и , в которых рассмотрены возможности различных методологий, поддерживающие процесс анализа (таблица 4.1) и процесс разработки (таблица ).

Таблица 4.1. Аналитические возможности сравниваемых методологий объектно-ориентированного анализа

Возможность	OSA	OMT	SA/SD	JSD
Объекты: должны иметь индивидуальное и независимое состояние и поведение	+	+	+	+
Классы объектов: должны определять свойства своих членов и должны иметь место в памяти	+	+	+	+
Множества связей: множества соединений объектов	+	+	+	+
Реляционные классы объектов: рассматривают связи как объекты	+	+	-	+
Полностью интегрированные подмодели: допускают произвольную интеграцию подмоделей анализа; знак "-" в таблице означает, что подмодели, представленные, например, блок-схемами, не могут комбинироваться с другими видами подмоделей (например, моделями поведения)	+	-	-	+
Агрегация: часто используемый механизм абстракции, который представляет взаимосвязи между системами и их частями	+	+	+	+
Обобщение/наследование: механизм абстракции: если A есть специализация B, то свойства A подразумевают свойства B	+	+	-	+
Полномасштабные ограничения мощности связей: допускают мощности связей, являющихся произвольными множествами неотрицательных целых чисел (не только 1-1, 1-M, M-1, M-M)	+	-	-	-
Синонимы и омонимы: допускают несколько имен для одной конструкции и многократное использование одного имени для различных конструкций; полезно при интеграции моделей	+	-	-	-
Полная система триггеров: допускаются только условия, только события, или комбинации условий и событий	+	+	-	-
Действия: описывают поведение, которое завершается	+	+	+	+
Недетерминированное поведение: описание поведения, которое при отсутствии внешних воздействий может и не завершиться	+	+	-	-
Межобъектный параллелизм: более одного объекта могут быть активными одновременно	+	+	+	+
Внутриобъектный параллелизм: в одном объекте допускается одновременное активное существование двух или более трэдов	+	+	-	-
Исключения: допускается обнаружение и обработка условий ошибок	+	-	-	-
Временные ограничения: обеспечивают средства ограничения времени на какое-либо действие	+	-	+	+
Темпоральные условия: поддерживают возможность формулировать условия, ссылающиеся на события в прошлом, настоящем и будущем	+	-	-	-
Метамодель: определяет правильный экземпляр модели	+	-	-	-
Родовой класс: параметризация классов - механизм абстракции, помогающий осуществлять анализ, хотя иногда его считают особенностью языка	-	-	-	-
Взаимодействие данных и событий: обеспечивает возможность объектам посылать и принимать данные и события	+	+	+	-
Унифицированные взаимодействия: разрешают взаимодействие и по данным, и по событиям одновременно; многие модели разделяют взаимодействия по данным (поток данных) и по событиям	+	-	-	-
Детализация взаимодействий: показывает когда и почему объект взаимодействует с другими объектами	+	-	-	-
Непрерывные взаимодействия: допускает непрерывный поток информации	+	-	-	-
Взаимодействия по бродкастингу: разрешает иметь много приемников для одной передачи данных или события; бродкастинг разрешен только для данных, но не для событий	+	-	-	-
Общее число аналитических возможностей	29	13	8	9

<
Таблица 4.2.Возможности сравниваемых методов объектно- ориентированного анализа, используемые на этапе разработки системы

Возможность	OSA	OMT	SA/SD	JSD
Значения: имеют состояние, но не имеют поведения и индивидуальности; хотя значения можно считать постоянными объектами, во многих подходах существует различие между пространствами значений и объектов	-	+	+	+
Атрибуты и/или методы: определяют классы объектов в терминах атрибутов и/или методов, аналогично тому, как классы объектов определяются в объектно-ориентированных языках	-	+	+	+
Шаблоны классов объектов: шаблоны, по которым создаются экземпляры классов объектов, что подразумевает, что свойства экземпляра объекта определяет класс, а не свойства объекта определяют его класс	-	+	-	+
Абстрактные классы: шаблоны, которые определяют свойства, но не разрешают создавать экземпляры	-	+	+	+
Псевдонаследование: разрешает, чтобы атрибуты и сигнатуры методов подкласса совпадали с атрибутами и сигнатурами методов суперкласса	-	+	+	+
Тождественность по значениям: множества атрибутов (их обычно называют возможными ключами), используемые для определения тождественности объектов	-	+	+	-
Изменение семантики: разрешает переопределять в подклассе семантику методов суперкласса	-	+	+	-
Императивный вызов операций: позволяет вызов метода в отношении клиент-сервер	-	-	-	+
Общее число возможностей по разработке	0	7	6	6

Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы: OSA реализована в системе программирования C++ на рабочей станции Hewlett-Packard 700 под управлением ОС HP-UX 9.01. Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления (модели) проектируемой системы:

модель зависимостей между объектами; модель поведения объектов; модель взаимодействия объектов.

Модель зависимостей между объектами аналогична объектной модели методологии OMT. В ней рассматриваются объекты, множества отношений между объектами и различные ограничения. Для ее представления используются диаграммы, которые, как видно из рисунке 4.1, очень похожи на диаграммы для представления объектной модели методологии OMT.

Рис. 4.1. Модель зависимостей между объектами для системы управления топкой в теплоцентрали

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

Рис. 4.2. Поведение объекта "термостат"

Модель взаимодействия объектов - это набор представлений проектируемой системы, на которых показаны взаимодействия объектов между собой и с окружением системы (см. рисунок 4.3).

Рис. 4.3. Различные представления модели топки

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

Рис. 4.4. Формальная модель топки, разработанная с помощью методологии OSA

| |

Comments:

Copyright ©

Методология SA/SD

Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.

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

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

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

Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии OMT.

Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.

Таким образом, мы видим, что у методологий SA/SD и OMT много общего: обе методологии используют похожие конструкции для моделирования и поддерживают три взаимно-ортогональных представления проектируемой системы. Методологии SA/SD и OMT можно рассматривать как два способа использования инструментального средства - OMTTool.

Но в методологии SA/SD ведущей является функциональная модель (набор ДПД), на втором месте по важности стоит динамическая модель и на последнем месте - объектная модель. Таким образом, в методологии SA/SD проектируемая система описывается с помощью процедур (процессов), что несколько противоречит объектно-ориентированному подходу. Методология OMT гораздо ближе к нему: в ней моделирование концентрируется вокруг объектной модели, т.е. вокруг объектов, из которых строится проектируемая система.

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

В то же время методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.

| |

Comments:

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

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

Методология OMT (Object Modeling Technique), которая была подробно рассмотрена в разделах и , поддерживает две первые стадии жизненного цикла программных систем. Это не единственная объектно-ориентированная методология разработки программных систем. Она была выбрана для демонстрации объектно-ориентированного подхода, потому что является одной из наиболее продвинутых и популярных объектно-ориентированных методологий. Более того, графический язык (система обозначений для диаграмм) методологии OMT получил достаточно широкое распространение и используется в некоторых других объектно-ориентированных методологиях, а также в большинстве публикаций по объектно-ориентированным методологиям.

В этом разделе мы рассмотрим другие объектно-ориентированные методологии разработки программных систем. Они будут сравниваться с методологией OMT. В последнее время интерес к объектно-ориентированным методологиям разработки программных систем продолжает возрастать: много публикаций в журналах, докладов на конференциях и т.д. Программное обеспечение объектно-ориентированных методологий стало настолько популярным, что все интересные инструментальные и CASE-системы давно исчезли из public domain и распространяются только как коммерческие системы. Наиболее известной такой системой является система Paradigm+, которая поддерживает восемь объектно-ориентированных методологий, и в том числе, методологию OMT.

В этом разделе будут рассмотрены следующие объектно-ориентированные методологии анализа и разработки программных систем: OMT (Object Modeling Technique), SA/SD (Structured Analysis/Structured Design), JSD (Jackson Structured Development), OSA (Object-Oriented System Analysis), Проклос (Проектирование в кластерной среде).

| |

Comments:

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

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

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

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

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

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

| |

Comments:

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

Язык C++ является сейчас наиболее распространенным объектно-ориентированным языком. Однако существуют и другие популярные объектно-ориентированные языки и системы программирования. Здесь мы кратко рассмотрим языки Eiffel и Smalltalk.

| |

Comments:

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

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

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

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

| |

Comments:

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

Рассмотрим проблемы реализации проекта, разработанного с использованием методологии OMT, в системах программирования объектно-ориентированных языков. В качестве примеров таких систем программирования будут рассмотрены системы программирования известных объектно-ориентированных языков C++, Eiffel и Smalltalk.

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

Рис. 5.1. Часть объектной модели графического редактора

Изложение будет вестись на примере реализации графического редактора, часть объектной модели которого представлена на рисунке 5.1. Редактор поддерживает манипулирование рекурсивными группами графических объектов, составленных из прямоугольников и овалов (в частности, кругов); при этом определена операция "сгруппировать", которая превращает группу объектов в единый объект (все это очень похоже на графическую подсистему редактора Microsoft Word).

| |

Comments:

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

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

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

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

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

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

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

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

| |

Comments:

Обзор архитектур прикладных систем

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

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

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

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

Рис. 3.5. Система непрерывной обработки: машинная графика

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

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

Рис. 3.6. Система с интерактивным интерфейсом: ATM

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

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

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

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

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

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

| |

Comments:

Copyright ©

Пограничные ситуации

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

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

Терминация. Терминация состоит в освобождении всех внешних ресурсов, занятых задачами системы.

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

| |

Comments:

Порождение объектов

В языке Eiffel объявление переменной (в этом языке вместо термина "переменная" используется термин сущность (entity)) отделено от порождения соответствующего объекта. Объявление сущности определяет имя, значением которого может быть (объектная) ссылка на объект объявленного типа, но эта ссылка при объявлении получает неопределенное значение (void), т.е. не ссылается ни на какой объект. Пример объявления переменной:

w: WINDOW

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

w.Create (0.0, 0.0, 8.5, 11.0);

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

class WINDOW ... feature Create (x0, y0, width, height: REAL) is do xmin := x0; ymin := y0; xmax := x0 + width; ymax := y0 + height; end ... end -- class WINDOW

Кроме операции Create, определена операция создания копий уже существующего объекта - Clone.

В языке Eiffel невозможно явным образом уничтожить объект (в нем отсутствует операция, подобная операции delete языка C++). Операция Forget убирает объектную ссылку из соответствующей сущности, но не уничтожает сам объект. Объект, на который нет ни одной объектной ссылки, уничтожается во время "чистки мусора", которая, если она не отключена программистом (для этого имеется специальная системная операция), выполняется автоматически.

Все объекты языка Smalltalk - динамические и размещаются в динамической памяти - куче. Удаление объектов осуществляется автоматически подсистемой чистки мусора. Все переменные не имеют типа и могут содержать объекты любого класса.
Порождение объектов осуществляется операцией new, определенной в системном классе Object (все классы языка Smalltalk - наследники класса Object). Например, порождение окна со стандартными параметрами (определяемыми по умолчанию) осуществляется операцией:

w <- Window new

Операция new является одним из методов уровня класса. С ее помощью можно определить еще один метод порождения окна (уже с параметрами):

w <- Window createAt: 0 @ 0 ofWidth: 8.5 ofHeight: 11.0

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

class name Window ... class methods createAt: aPoint ofWidth: width ofHeigt: heigt | w | w <- self new. w initialize: aPoint ofWidth: width ofHeigt: heigt. |w instance methods initialize: aPoint ofWidth: width ofHeigt: heigt. xmin <- aPoint x. ymin <- aPoint y. xmax <- xmin + width. ymax <- ymin + height

Отметим, что метод уровня класса не имеет непосредственного доступа к атрибутам объектов. Поэтому для инициализации окна потребовалось определить метод уровня объекта initialize. | |

Comments:

Copyright ©

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

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

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

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

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

| |

Comments:

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

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

Разработка объектов предполагает выполнение следующих шагов:

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

| |

Comments:

Реализация классов

Определение класса Window на языке Eiffel мало отличается от соответствующего определения на языке C++ (сравните с п. ):

class WINDOW export add_box, add_circle, clear_selections, cut_selections, group_selections, move_selections, redraw_all, select_item, ungroup_selections feature xmin, ymin, xmax, ymax: REAL; Create (x0, y0, width, height: REAL) is body end; add_box (x, y, width, height: REAL) is body end; add_circle (x, y, radius: REAL) is body end; add_to_selections (ashape: SHAPE) is body end; clear_selections is body end; cut_selections is body end; group_selections: Group is body end; move_selections (deltax, deltay: REAL) is body end; redraw_all is body end; select_item (x, y: REAL) is body end; ungroup_selections is body end; end -- class WINDOW

Все свойства (feature) класса (соответствуют членам класса в языке C++) считаются приватными, если только они не объявлены явно как общедоступные: все общедоступные свойства перечисляются в разделе export. Свойство Create (аналог конструктора класса в языке C++) всегда является общедоступным. Остальные особенности синтаксиса понятны и без пояснений.

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

Определение класса Window на языке Smalltalk имеет следующий вид:

class name Window superclass Object instance variables xmin, ymin, xmax, ymax: REAL class methods instantiating createAt aPoint ofWidth: width ofHeigt: heigt instance methods adding shapes addboxAt aPoint ofWidth: width ofHeigt: heigt addCircleAt aPoint ofRadius: radius refreshing window redrawAll manipulating selections clearSelections cutSelections groupSelections moveSelectionsBy: deltaPoint selectItemAt: aPoint ungroupSelections private addToSelections: aShape

Все классы языка Smalltalk являются подклассами системного класса Object, что позволяет использовать принадлежащие им по наследованию системные операции системы Smalltalk, определенные в классе Object. Строки в описании класса, выделенные курсивом, определяют категории методов. Они служат только для структурирования набора методов. Методы, включенные в категорию private, являются приватными и не доступны извне класса. Чтобы сделать атрибуты приватными, следует не определять методы для запроса и установки значений атрибутов. В системе Smalltalk определен системный метод @, который объединяет пару числовых значений в одно составное значение. Это позволило вместо двух переменных x и y (координат точки) использовать в нашем примере одну переменную aPoint, представляющую обе координаты точки(x,y). Операция присваивания значения (3,4) переменной aPoint с использованием метода @ имеет вид:

aPoint <- 3 @ 4

| |

Comments:

Copyright ©

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

Язык C++ является наиболее распространенным объектно-ориентированным языком программирования. Поэтому рассмотрение вопросов реализации начнем с этого языка. Поскольку язык C++ хорошо известен и достаточно широко распространен (это один из самых популярных языков программирования), здесь приводится лишь краткий обзор некоторых свойств и конструкций этого языка. В настоящее время издано огромное количество учебных пособий, справочников и других руководств по языку C++. Одним из наиболее полных, изданных на русском языке, является книга Ирэ Пол. Объектно-ориентированное программирование с использованием C++. // DiaSoft Ltd., Киев -- 1995.

| |

Comments:

Реализация управления программным обеспечением

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

Известны три метода внешнего управления:

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

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

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

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

| |

Comments:

Реализация зависимостей

Зависимости в языке C++ реализуются с помощью указателей или с помощью специальных объектов. Например, зависимость "много-к-одному" между классами Item и Group реализована через указатели:

class Item{ public: virtual void cut (); virtual void move (Length deltax, Length deltay) = 0; virtual Boolean pick (Length px, Length py) = 0; virtual void ungroup () = 0; private: Group* group; friend Group::add_item (Item*); friend Group::remove_item (Item*); public: Group* get_group () {return group;}; }; class Group: public Item { public: void cut (); void move (Length deltax, Length deltay); Boolean pick (Length px, Length py) = 0; void ungroup () { }; private: ItemSet* items; public: void add_item (Item*); void remove_item (Item*); ItemSet* get_items () {return items;} };

Каждый раз, когда к зависимости добавляется (или из нее удаляется) связь, оба указателя должны быть изменены:

void Group::add_item (Item* item) { item->group = this; items->add (item); } void Group::remove_item (Item* item); { item->group = 0; items->remove (item); }

Методы Group::add_item и Group::remove_item могут изменять приватные (private) атрибуты класса Item, хотя они определены в его подклассе Group, так как они определены как дружественные (friends) для класса Item.

В рассмотренном примере опущены проверки:

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

Иногда связанные между собой (зависимые) объекты включают в так называемые коллективные классы. В качестве примера такого класса рассмотрим класс ItemSet (набор объектов):

class ItemSet { public: ItemSet(); //создать пустой набор объектов ~ItemSet(); //уничтожить набор объектов void add(Item*); //включить объект в набор void remove(Item*); //исключить объект из набора Boolean includes(Item*); //проверить наличие объекта в наборе int size(Item*); //определить количество объектов в наборе };

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

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

| |

Comments:

Шаблоны в языке C++

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

Параметрическое программирование в языке C++ реализовано с помощью шаблонов (template). В C++ определено два вида шаблонов: шаблоны-классы и шаблоны-функции.

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

Возможность параметрического программирования на языке C++ обеспечивается стандартной библиотекой шаблонов STL (Standard Template Library). Она включена в последнюю предварительную версию Стандарта языка C++. Библиотека подробно описана в книге D.R.Musser, A.Saini "STL Tutorial and Reference Guide. C++ Programming with the Standard Template Library" Addison-Wesley, 1996 (книга доступна также по ). Документация по текущей версии STL доступна по или . Наконец, реализация текущей версии STL доступна по .

| |

Comments:

Совместное рассмотрение трех моделей

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

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

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

| |

Comments:

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

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

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

| |

Comments:

Управление глобальными ресурсами

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

| |

Comments:

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

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

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

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

| |

Comments:

Вызов операций

В языке Eiffel методы называются подпрограммами (routines). При вызове этих подпрограмм им передаются параметры, которые могут иметь простой тип (REAL, INTEGER, BOOLEAN, или CHARACTER) или быть объектами классов, определенных программистом. В подпрограмме не разрешается изменять значения формальных параметров путем присваивания им новых значений или применения к ним операции (такие, как Create, Clone, или Forget), которые могут менять значение объектной ссылки. В то же время остальные операции могут быть применены к объектам, являющимся формальными параметрами, что вызовет изменение состояния указанных объектов.

Синтаксис вызова операции в языке Eiffel такой же, как в языке C++, причем операция '.' языка Eiffel соответствует операции '->' языка C++:

local aShape: SHAPE; dx, dy: REAL do ... aShape.move (dx, dy); end

В языке Eiffel определен неявный доступ к свойствам целевого объекта по имени соответствующего свойства. Идентификаторы x и y являются именами атрибутов целевого объекта SHAPE:

move (deltax, deltay: REAL) is -- move a shape by delta do x = x + deltax; y = y + deltay end

В языке Eiffel имеется предопределенный идентификатор Current, который именует целевой объект операции (он аналогичен идентификаторам this языка C++ и self языка Smalltalk). Поэтому предыдущий фрагмент программы можно записать следующим эквивалентным образом:

move (deltax, deltay: REAL) is -- move a shape by delta do Current.x = Current.x + deltax; Current.y = Current.y + deltay end

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

aShape moveDelta: aPoint Этот метод можно реализовать следующим образом: class name Shape instance variables x y instance methods moveDelta: aPoint x <- x + aPoint x y <- y + aPoint y

Внутри метода разрешен непосредственный доступ по имени к атрибутам целевого объекта операции (в языке Smalltalk атрибуты называются переменными объекта (instance variables)).

Как уже упоминалось, в языке Smalltalk предопределена псевдо-переменная self, именующая целевой объект (получатель сообщения).

| |

Comments:

Объектно-ориентированная разработка программ

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

объектно-ориентированные методологии (технологии) разработки программных систем; инструментальные средства, поддерживающие эти технологии.

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

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

Различные объектно-ориентированные методологии разработки программного обеспечения рассматриваются в разделах , и . Наиболее подробно рассматривается объектно-ориентированная методология OMT (Object Modeling Technique) (разделы 2 и 3), которая поддерживает две первые стадии жизненного цикла программных систем. Эта методология выбрана для демонстрации объектно-ориентированного подхода, потому что является одной из наиболее продвинутых и популярных объектно-ориентированных методологий. Более того, ее графический язык (система обозначений для диаграмм) получил достаточно широкое распространение и используется в некоторых других объектно-ориентированных методологиях, а также в большинстве публикаций по объектно-ориентированным методологиям. Методология OMT поддерживается системой Paradigm+, одной из наиболее известных инструментальных систем объектно-ориентированной разработки.

Будут рассмотрены и некоторые другие объектно-ориентированные методологии разработки программных систем в сравнении с методологией OMT (раздел ):

SA/SD (Structured Analysis/Structured Design); JSD (Jackson Structured Development); OSA (Object-Oriented System Analysis).

| |

Comments:

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

Вопросы реализации программного обеспечения, разработка которого велась с применением одной из объектно-ориентированных методологий, рассматриваются в разделе 5. Реализация программного обеспечения связана с использованием одного из языков программирования. Показано, что наиболее удобными для реализации программных систем, разработанных в рамках объектно-ориентированного подхода, являются объектно-ориентированные языки программирования, хотя возможна реализация и на обычных (не объектно-ориентированных) языках (например, на языке C и на языке Fortran).

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

Первый объектно-ориентированный язык программирования Simula 67 был разработан в конце 60-х годов в Норвегии. Авторы этого языка очень точно угадали перспективы развития программирования: их язык намного опередил свое время. Однако современники (программисты 60-х годов) оказались не готовы воспринять ценности языка Simula 67, и он не выдержал конкуренции с другими языками программирования (прежде всего, с языком Fortran). Прохладному отношению к языку Simula 67 способствовало и то обстоятельство, что он был реализован как интерпретируемый (а не компилируемый) язык, что было совершенно неприемлемым в 60-е годы, так как интерпретация связана со снижением эффективности (скорости выполнения) программ.

Но достоинства языка Simula 67 были замечены некоторыми программистами, и в 70-е годы было разработано большое число экспериментальных объектно-ориентированных языков программирования: например, языки CLU, Alphard, Concurrent Pascal и др. Эти языки так и остались экспериментальными, но в результате их исследования были разработаны современные объектно-ориентированные языки программирования: C++, Smalltalk, Eiffel и др.

Наиболее распространенным объектно-ориентированным языком программирования безусловно является C++.
Свободно распространяемые коммерческие системы программирования C++ существуют практически на любой платформе. Широко известна свободно распространяемая система программирования G++, которая дает возможность всем желающим разобрать достаточно хорошо и подробно прокомментированный исходный текст одного из образцовых компиляторов языка C++. Завершается работа по стандартизации языка C++: последний Draft стандарта C++ выпущен в июне 1995 г. (он доступен по Internet). Разработка новых объектно-ориентированных языков программирования продолжается. С 1995 года стал широко распространяться новый объектно-ориентированный язык программирования Java, ориентированный на сети компьютеров и, прежде всего, на Internet. Синтаксис этого языка напоминает синтаксис языка C++, однако эти языки имеют мало общего. Java интерпретируемый язык: для него определены внутреннее представление (bytecode) и интерпретатор этого представления, которые уже сейчас реализованы на большинстве платформ. Интерпретатор упрощает отладку программ, написанных на языке Java, обеспечивает их переносимость на новые платформы и адаптируемость к новым окружениям. Он позволяет исключить влияние программ, написанных на языке Java, на другие программы и файлы, имеющиеся на новой платформе, и тем самым обеспечить безопасность при выполнении этих программ. Эти свойства языка Java позволяют использовать его как основной язык программирования для программ, распространяемых по сетям (в частности, по сети Internet). | |

Comments:

Copyright ©

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

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

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

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

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

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

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

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

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

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

; .

|

Comments:

Copyright ©

Сквозной пример

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

Рис. 1.3. Схема банковской сети

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

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

Рис. 1.4. Схема банкомата (ATM)

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

Comments:

Copyright ©