Объектно-ориентированные технологии проектирования прикладных программных систем
Агрегация
Агрегация - это зависимость между классом составных объектов и классами, представляющими компоненты этих объектов (отношение "целое"-"часть"). Агрегация обозначается ромбиком: на рисунке 2.15 приведен пример агрегации; этот пример интерпретируется следующим образом: документ состоит из нескольких (нуля, или более) абзацев; каждый абзац состоит из нескольких (нуля, или более) предложений.
Рис. 2.15. Агрегация
Наиболее важным свойством отношения агрегации является его транзитивность (если A есть часть B, а B есть часть C, то A есть часть C): так, из рисунка 2.15 можно заключить, что документ состоит из нескольких (нуля, или более) предложений. Легко видеть, что отношение агрегации антисимметрично (если A есть часть B, то B не есть часть A). Отметим также, что часть свойств целого может быть перенесена и на его части, возможно, с несущественными изменениями (например, контекст каждого оператора некоторой функции совпадает с внутренним контекстом всей функции). Дальнейшие примеры агрегации показаны на рисунке 2.16. Отметим, что обе агрегации, показанные на рисунке 2.16(а), следует рассматривать не как зависимости между пятерками классов, а как четверки зависимостей между парами классов. Только при таком рассмотрении можно говорить о транзитивности и антисимметричности отношения агрегации.
Рис. 2.16. Примеры агрегации
| |
Comments:
Copyright ©
Атрибуты зависимостей
Зависимости, как и классы, могут иметь атрибуты: например, при организации доступа пользователя к файлу разрешение_на_доступ является атрибутом зависимости доступен: см. рисунок 2.10, на котором атрибут зависимости обозначается прямоугольником, связанным дугой с прямой, изображающей зависимость. Такое обозначение атрибутов зависимостей принято в технологии OMT. Отметим, что разрешение на доступ связано как с пользователем, так и с файлом, и не может быть атрибутом ни пользователя, ни файла в отдельности.
Рис. 2.10. Пример атрибута зависимости
Еще один пример зависимостей, имеющих атрибуты, показан на рисунке 2.11. Из примера видно, что зависимость может иметь несколько атрибутов. Кроме того, на рисунке 2.11 указаны роли различных объектов в зависимости (подробнее см. ниже). Зависимость руководит на этом рисунке удобнее именовать как начальник-сотрудник.
Рис. 2.11. Атрибуты двух зависимостей между одним и многими
Иногда зависимости, имеющие много атрибутов, представляют с помощью классов. Такие зависимости в базах данных представляются временными таблицами, организуемыми в процессе обращения с базой данных. Пример зависимости, представленной через класс, показана на рисунке 2.12, на котором представлена информация о регистрации пользователей на рабочих станциях. Пользователь может быть зарегистрирован на нескольких рабочих станциях, каждая регистрация содержит приоритет пользователя и его привилегии доступа (атрибуты зависимости). Пользователь может иметь свою директорию для каждой зарегистрированной рабочей станции, но одна и та же директория может принадлежать одновременно нескольким пользователям или нескольким рабочим станциям.
Рис. 2.12. Представление зависимости в виде класса
| |
Comments:
Copyright ©
Динамическая модель системы или подсистемы
Объектная модель представляет статическую структуру проектируемой системы (подсистемы). Однако знания статической структуры недостаточно, чтобы понять и оценить работу подсистемы. Необходимо иметь средства для описания изменений, которые происходят с объектами и их связями во время работы подсистемы. Одним из таких средств является динамическая модель подсистемы. Она строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена. Динамическая модель подсистемы состоит из диаграмм состояний ее объектов и подсистем.| |
Comments:
Copyright ©
Функциональная модель подсистемы
Функциональная модель описывает вычисления в системе. Она показывает, каким образом выходные данные вычисляются по входным данным, не рассматривая порядок и способ реализации вычислений. Функциональная модель состоит из набора диаграмм потока данных, которые показывают потоки значений от внешних входов через операции и внутренние хранилища данных к внешним выходам. Функциональная модель описывает смысл операций объектной модели и действий динамической модели, а также ограничения на объектную модель. Неинтерактивные программы (например, компиляторы) имеют тривиальную динамическую модель: их цель состоит в вычислении значения некоторой функции. Основной моделью таких программ является функциональная модель (хотя если программа имеет нетривиальные структуры данных, для нее важна и объектная модель). | |Comments:
Copyright ©
Имена ролей, квалификаторы
Роль определяет одну сторону зависимости. В бинарной зависимости определены две роли. Имя роли однозначно определяет одну сторону зависимости. Роли дают возможность рассматривать бинарную зависимость как связь между объектом и множеством зависимых объектов: каждая роль является обозначением объекта или множества объектов, связанных зависимостью с объектом на другом конце зависимости. Имя роли можно рассматривать как производный атрибут, множеством значений которого является множество связанных с этой ролью объектов. В бинарной зависимости пара имен ролей может использоваться для идентификации этой зависимости. На рисунке имена начальник и сотрудник в зависимости руководит - это имена ролей; как уже было отмечено, эту зависимость удобнее назвать начальник-сотрудник. Еще один пример имен ролей показан на рисунке 2.13.
Рис. 2.13. Имена ролей Пользователь может быть либо владельцем, либо зарегистрированным пользователем директории; директория может содержать в себе другие директории. Имена ролей следует обязательно указывать в тех случаях, когда зависимость устанавливается между объектами одного и того же класса (как в случаях, показанных на рисунках и 2.13). Имена ролей должны быть уникальны, так как они используются для различения объектов, участвующих в зависимости. Квалификатором называется некоторый атрибут, который позволяет снизить эффективную кратность зависимости. Квалификаторы применяются в зависимостях типов "один-ко-многим" или "много-ко-многим". Так в примере, показанном на рисунке 2.14, использование квалификатора имя_файла позволяет привести зависимость дает_доступ от вида, приведенного на рисунке 2.14(а), к виду, показанному на рисунке 2.14(б), сократив число зависимых объектов до одного. Еще один пример использования квалификатора показан на рисунке 2.14(в): использование квалификаторов и здесь позволяет сократить кратность зависимости до одного объекта. Квалификаторы указываются на схемах в прямоугольничках, пририсованных к прямоугольнику, изображающему соответствующий класс.
Рис. 2.14. Использование квалификаторов
Рисунок 2.14(в) может быть проинтерпретирован следующим образом: центральный компьютер + код_ATM определяют конкретную ATM (отметим, что код_ATM - имя одного из атрибутов класса ATM, а не класса центральный_компьютер); аналогично центральный_компьютер + код_банка определяют конкретный компьютер банка. Использование квалификаторов повышает точность описания семантики и наглядность описания зависимостей. | |
Comments:
Copyright ©
Объектная модель системы
Объектная модель описывает структуру объектов, составляющих систему, их атрибуты, операции, взаимосвязи с другими объектами. В объектной модели должны быть отражены те понятия и объекты реального мира, которые важны для разрабатываемой системы. В объектной модели отражается прежде всего прагматика разрабатываемой системы, что выражается в использовании терминологии прикладной области, связанной с использованием разрабатываемой системы.| |
Comments:
Copyright ©
Операции и методы
Операция - это функция (или преобразование), которую можно применять к объектам данного класса. Примеры операций: проверить, снять, поместить (для объектов класса счет - ), открыть_на_чтение, читать, закрыть (для объектов класса файл - рисунок 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.5. Возможные классы для системы AMT (банковское обслуживание)
| |
Comments:
Copyright ©
Первая фаза жизненного цикла
Как известно, проектирование прикладной программной системы начинается с анализа требований, которым она должна будет удовлетворять. Такой анализ проводится с целью понять назначение и условия эксплуатации системы настолько, чтобы суметь составить ее предварительный проект. При объектно-ориентированном подходе анализ требований к системе сводится к разработке моделей этой системы. Моделью системы (или какого-либо другого объекта или явления) мы называем формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами. Построение моделей - широко распространенный способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено и в науке, и в технике. Модели помогают:В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. Мы подробно ознакомимся с одной из таких технологий - OMT (Object Modeling Techniques). Эта технология оказала большое влияние на других разработчиков объектно-ориентированных технологий, а книга, в которой она описана, является одной из наиболее часто цитируемых книг по данному направлению. Более того, система обозначений (графический язык) для описания моделей, предложенная в этой книге, широко применяется в других технологиях и в статьях по объектно-ориентированной разработке программных систем. В технологии OMT проектируемая программная система представляется в виде трех взаимосвязанных моделей:
Эти три вида моделей позволяют получить три взаимно-ортогональных представления системы в одной системе обозначений. Совокупность моделей системы может быть проинтерпретирована на компьютере (с помощью инструментального программного обеспечения), что позволяет продемонстрировать заказчику характер работы с будущей системой и существенно упрощает согласование предварительного проекта системы. Модели, разработанные и отлаженные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, ее отладку и тестирование, сопровождение и дальнейшую модификацию. Как будет показано в дальнейшем, модели системы не связаны с языком программирования, на котором будет реализована система.
| |
Comments:
Copyright ©
Понятие подсистемы
Итак, прикладная система представляет собой множество взаимозависимых объектов (см. п. ). Каждый объект характеризуется набором атрибутов, значения которых определяют состояние объекта, и набором операций, которые можно применять к этому объекту. При разработке прикладных систем удобно считать, что все атрибуты объектов являются закрытыми (т.е. они не доступны вне объекта, и для того, чтобы в некотором объекте узнать значение атрибута другого объекта, или изменить его, необходимо воспользоваться одной из открытых операций этого объекта, если, конечно, такая операция определена). Операции объектов могут быть как открытыми, так и закрытыми. Таким образом, каждый объект имеет строго определенный интерфейс, т.е. набор открытых операций, которые можно применять к этому объекту. Все объекты одного класса имеют одинаковый интерфейс. Интерфейс класса (а, следовательно, и каждого объекта этого класса) задается списком сигнатур его открытых (общедоступных) операций (и реализующих их методов); сигнатуры закрытых операций в интерфейс объектов соответствующего класса не входят. Объектная модель системы задает множество взаимозависимых объектов, составляющих систему, и, следовательно, определяет набор интерфейсов, доступных внутри системы. Все возможности по обработке данных внутри системы (т.е. в каждом объекте, входящем в состав системы) определяются этим набором интерфейсов, который определяет внутреннее окружение (или среду) системы. Наряду с внутренним окружением системы можно определить ее внешнее окружение. Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, различных редакторов, системы управления базами данных и т.п.), а также в других прикладных системах и библиотеках, используемых совместно с системой. Объекты и операции, составляющие внешнее окружение системы, тоже могут быть доступны внутри системы. Чтобы не упустить этого из виду, можно было бы добавить в объектную модель еще один объект, интерфейс которого представлял бы возможности внешнего окружения, используемые в системе (такой интерфейс обычно представляет лишь часть возможностей внешнего окружения).Но это было бы не совсем точно, так как внешнее окружение реализуется не одним, а несколькими объектами. С другой стороны внутри системы нет резона рассматривать структуру ее внешнего окружения. Выход из указанного противоречия во введении в рассмотрение еще одной сущности - подсистемы. Подсистема - это набор объектов и подсистем, обеспечивающих некоторую функциональность, и взаимодействующих между собой в соответствии с их интерфейсами. Интерфейс подсистемы представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может входить один, или более взаимозависимых объектов и/или подсистем. Множество интерфейсов объектов (и подсистем), которые в своей совокупности составляют некоторую подсистему, составляет внутреннее окружение этой подсистемы. В состав каждой подсистемы должна быть включена подсистема окружение, представляющая внешнее окружение этой подсистемы. Подсистема окружение для системы банковского обслуживания, рассматриваемой в качестве сквозного примера представлена на рисунке 2.41. Интерфейс подсистемы окружение определяет в каком программном окружении будет работать проектируемая система и какие возможности этого окружения будут использоваться во время ее работы (это важно, когда возникает потребность модификации или замены отдельных компонентов окружения). Отметим, что подсистема окружение представляет только интерфейс системы банковского обслуживания с ее внешним окружением. Внешнее окружение системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже может быть разработана объектная модель, которая может содержать и разрабатываемую систему (в этой объектной модели она будет одной из подсистем). Объектную модель системы банковского обслуживания и ее системного (внешнего) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав этой объектной диаграммы будут входить не объекты, а только подсистемы; каждая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами).
Зависимости между подсистемами, изображенные на этой объектной диаграмме (рисунок 2.42), отражают взаимодействие проектируемой системы банковского обслуживания и соответствующих подсистем в процессе работы системы. Тем самым определяются требования проектируемой системы к ее системному окружению.
Рис. 2.41. Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением
Рис. 2.42. Объектная диаграмма банковской сети и ее системного окружения
Введение понятия подсистемы и возможность включать в объектную модель наряду с объектами (классами) и подсистемы определяет иерархическую структуру объектной модели и позволяет использовать методологию OMT при проектировании достаточно сложных программных систем, содержащих большое число различных объектов и классов. | |
Comments:
Copyright ©
Построение объектной модели
Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:| |
Comments:
Copyright ©
Пример объектной модели
Рассмотрим процесс построения объектной модели для системы банковского обслуживания (см. п. ) в процессе анализа требований и предварительного проектирования этой системы. Для построения объектной модели рассматриваемой системы нам необходимо выполнить все этапы, перечисленные в п| |
Comments:
Copyright ©
Заключительные замечания к разделу
Цель анализа - обеспечить правильную постановку и адекватное понимание рассматриваемой прикладной задачи, помочь убедиться, что предварительно спроектированная прикладная система сможет удовлетворить заказчика. Хороший анализ охватывает все существенные особенности задачи, не внося каких-либо реализационных особенностей в предварительный проект системы. Тем самым обеспечивается свобода реализационных решений на этапе реализации. Объектная модель показывает статическую структуру проблемной области, для которой разрабатывается система. Сначала определяются классы объектов, затем зависимости между объектами, включая агрегацию. Для упрощения структуры классов используется наследование. Объектная модель должна содержать краткие комментарии на естественном языке. Динамическая модель показывает поведение системы, в особенности последовательность взаимодействий. Сначала готовятся сценарии типичных сеансов взаимодействия с системой, затем определяются внешние события, отражающие взаимодействие системы с внешним миром; после этого строится диаграмма состояний для каждого активного объекта, на которой представлены образцы событий, получаемых системой и порождаемых ею, а также действий, выполняемых системой. Построенные диаграммы состояний сравниваются между собой, чтобы убедиться в их непротиворечивости. На этом построение динамической модели заканчивается. Функциональная модель показывает функциональный вывод значений безотносительно к тому, когда они вычисляются. Сначала определяются входные и выходные значения системы как параметры внешних событий. Затем строятся диаграммы потоков данных, показывающие как вычисляется каждое выходное значение по входным и промежуточным значениям. Диаграммы потоков данных выявляют взаимодействие с внутренними объектами системы, которые служат хранилищами данных в периоды между сеансами работы системы. В заключение определяются ограничения и критерии оптимизации. | |Comments:
Copyright ©
Зависимости между классами (объектами)
С каждым объектом связана структура данных, полями которой являются атрибуты этого объекта и указатели функций (фрагментов кода), реализующих операции этого объекта (отметим, что указатели функций в результате оптимизации кода обычно заменяются на обращения к этим функциям). Таким образом, объект - это некоторая структура данных, тип которой соответствует классу этого объекта. Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 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 плохо приспособлена для решения следующих проблем:
| |
Comments:
Copyright ©
Методология OMT
Методология OMT (Object Modeling Technique), достаточно подробно рассмотренная в разделах и , поддерживает две первые стадии разработки программных систем. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. В настоящее время OMTTool входит в состав системы Paradigm+. | |Comments:
Copyright ©
Методология 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 |
Модель зависимостей между объектами аналогична объектной модели методологии 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:
Copyright ©
Сравнительный анализ объектно-ориентированных методологий разработки программных систем
Разработка программных систем охватывает первые две стадии их жизненного цикла: стадию анализа требований и предварительной разработки, на которой будущая программная система рассматривается только в аспекте ее прагматики (никакие аспекты, связанные с ее будущей реализацией не принимаются во внимание), и стадию проектирования (конструирования), на которой принимаются основные решения, связанные с реализацией проектируемой программной системы, а ее структура, разработанная на первой стадии, изменяется с учетом требований ее эффективности. Методология 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:
Copyright ©
Архитектура системы управления банковской сетью
Система управления банковской сетью, рассматриваемая нами в качестве примера, является гибридной системой: это, во-первых, система с интерактивным интерфейсом (интерактивные воздействия осуществляются с помощью кассовых терминалов и ATM), а, во-вторых, это система управления транзакциями, так как она обеспечивает выполнение проводок, которые и есть транзакции. Архитектура системы управления банковской сетью показана на рисунке 3.7. Система имеет три основных подсистемы: подсистему обслуживания ATM, подсистему консорциум и подсистему банк. Система имеет топологию звезды, в центре которой - подсистема консорциум, а на лучах - подсистемы ATM и банк (ясно, что в состав системы входит одна подсистема консорциум и по несколько подсистем ATM и банк).
Рис. 3.7. Архитектура системы управления банковской сетью
Постоянные хранилища данных (счета клиентов и банковская отчетная документация) имеются у подсистем банк, которые работают на компьютерах банков. Поскольку важно сохранять целостность данных и обеспечивать параллельное обслуживание нескольких проводок (транзакций), хранилища данных реализованы на основе баз данных банков (доступ к данным осуществляется через СУБД, которая, в частности, обеспечивает синхронизацию доступа к данным). Асинхронная параллельность возникает в связи с необходимостью параллельного обслуживания нескольких независимо работающих ATM и кассовых терминалов. Каждый терминал может одновременно обслуживать только одну проводку (транзакцию), но каждая проводка связана также с центральным компьютером консорциума и компьютером одного из банков, которые должны одновременно обслуживать несколько проводок. Как видно из рисунка 3.7 каждая проводка распределена по трем устройствам, управляющее ее выполнением программное обеспечение состоит из трех частей; каждая из этих частей может быть реализована в виде отдельного класса. | |
Comments:
Copyright ©
Другие объектно-ориентированные системы программирования
Язык C++ является сейчас наиболее распространенным объектно-ориентированным языком. Однако существуют и другие популярные объектно-ориентированные языки и системы программирования. Здесь мы кратко рассмотрим языки Eiffel и Smalltalk. | |Comments:
Copyright ©
Не объектно-ориентированные системы программирования
Прикладную программную систему, спроектированную по методологии OMT, совсем не обязательно реализовывать на объектно-ориентированном языке. Рассмотрим, как объектно-ориентированный проект можно реализовать на языке C (как известно, он не является объектно-ориентированным). Проще всего это сделать, отобразив объектно-ориентированные конструкции на язык C (для объектно-ориентированных языков такое отображение автоматически реализуется компилятором). Реализация состоит в выполнении следующих шагов:Рассмотрим, как можно выполнить перечисленные шаги при реализации на языке C, на примере реализации графического редактора (см. п. ). | |
Comments:
Copyright ©
Объектно-ориентированные системы программирования
Рассмотрим проблемы реализации проекта, разработанного с использованием методологии OMT, в системах программирования объектно-ориентированных языков. В качестве примеров таких систем программирования будут рассмотрены системы программирования известных объектно-ориентированных языков C++, Eiffel и Smalltalk. Все три модели методологии OMT, разработанные на этапе анализа требований к системе и уточненные на этапе ее проектирования, используются на этапе реализации программного обеспечения системы. Объектная модель определяет классы, атрибуты, иерархию наследования, зависимости. Динамическая модель определяет стратегию управления, которая будет принята в системе (процедурно-управляемая, событийно-управляемая, или многозадачная). Функциональная модель содержит функциональность объектов, которая должна быть воплощена в их методах.
Рис. 5.1. Часть объектной модели графического редактора
Изложение будет вестись на примере реализации графического редактора, часть объектной модели которого представлена на рисунке 5.1. Редактор поддерживает манипулирование рекурсивными группами графических объектов, составленных из прямоугольников и овалов (в частности, кругов); при этом определена операция "сгруппировать", которая превращает группу объектов в единый объект (все это очень похоже на графическую подсистему редактора Microsoft Word). | |
Comments:
Copyright ©
Объектно-ориентированный стиль программирования
Правильно разработанные программы должны не только удовлетворять своим функциональным требованиям, но и обладать такими свойствами, как:Правильный объектно-ориентированный стиль программирования обеспечивает наличие этих свойств. Поясним это на примере свойства системности. Программа обладает свойством системности, если она применима в качестве обобщенного оператора при "крупноблочном программировании". Крупноблочное программирование - это систематическое использование ранее разработанных крупных программных единиц (таких, как классы, подсистемы, или модули) при разработке новых программных систем. Следующие рекомендации могут помочь разрабатывать классы, обладающие свойством системности.
Естественно, что к этим и им подобным "рекомендациям" следует относиться с известной долей юмора. Но выполнять их, тем не менее, полезно. | |
Comments:
Copyright ©
Обзор архитектур прикладных систем
Существует несколько типов архитектур, обычно используемых в существующих системах. Каждая из них хорошо подходит к определенному типу систем. Проектируя систему одного из нижеперечисленных типов, имеет смысл использовать соответствующую архитектуру. Мы рассмотрим следующие типы систем:При разработке системы пакетной обработки необходимо выполнить следующие шаги:
Рис. 3.5. Система непрерывной обработки: машинная графика
При разработке системы непрерывной обработки необходимо выполнить следующие шаги:
Рис. 3.6. Система с интерактивным интерфейсом: ATM
При разработке системы с интерактивным интерфейсом необходимо выполнить следующие шаги:
При разработке системы динамического моделирования необходимо выполнить следующие шаги:
Разработка системы реального времени аналогична разработке системы с интерактивным интерфейсом. При разработке системы управления транзакциями необходимо выполнить следующие шаги:
| |
Comments:
Copyright ©
Пограничные ситуации
Необходимо предусмотреть поведение каждого объекта и всей системы в пограничных ситуациях: инициализации, терминации и обвале. Инициализация. Перед тем, как начать работать, система (объект) должна быть приведена в фиксированное начальное состояние: должны быть проинициализированы все константы, начальные значения глобальных переменных и параметров, задачи и, возможно, сама иерархия классов. Во время инициализации, как правило, бывает доступна лишь часть возможностей системы. Терминация. Терминация состоит в освобождении всех внешних ресурсов, занятых задачами системы. Обвал. Обвал - это незапланированная терминация системы. Обвал может возникнуть в результате ошибок пользователя, нехватки ресурсов, или внешней аварии. Причиной обвала могут быть и ошибки в программном обеспечении системы. | |Comments:
Copyright ©
Порождение объектов
В языке 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:
Copyright ©
Разработка объектов
Разработав архитектуру системы, переходим к разработке объектов (классов), составляющих систему. Часть объектов была выявлена на этапе анализа системы, эти объекты могут рассматриваться как основа системы. На рассматриваемом этапе разработки системы необходимо выбрать способ их реализации, стремясь минимизировать количество потребляемых ими ресурсов (времени их выполнения, используемой памяти и др.). При реализации объектов классы, атрибуты и зависимости должны быть реализованы в виде соответствующих структур данных, операции - в виде функций. При этом может возникнуть необходимость введения новых классов (объектов) для промежуточных данных. Разработка объектов предполагает выполнение следующих шагов:| |
Comments:
Copyright ©
Реализация классов
Определение класса 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:
Copyright ©
Реализация управления программным обеспечением
Во время анализа все взаимодействия представляются в виде событий. Управление аппаратурой соответствует этой модели, но необходимо выбрать метод управления программным обеспечением системы. Существует два класса методов управления программным обеспечением: методы внешнего управления и методы внутреннего управления. Известны три метода внешнего управления:При последовательном управлении процедурами в каждый момент времени действует одна из процедур; это наиболее легко реализуемый способ управления. При последовательном управлении событиями управлением занимается монитор (диспетчер). При параллельном асинхронном управлении этим заведует несколько управляющих объектов (мониторов). Внутреннее управление связано с потоками управления в процессах. Оно существует только в реализации и потому не является только последовательным или параллельным. В отличие от внешних событий, внутренние передачи управления, как например, вызовы процедур или обращения к параллельным задачам контролируются программой и могут быть структурированы в случае необходимости. Здесь мы рассматриваем, в основном, процедурное программирование, но, конечно, возможны и другие парадигмы, как например, логические программные системы, функциональные программные системы и другие виды непроцедурных программных систем. В этом курсе такие системы не рассматриваются. | |
Comments:
Copyright ©
Реализация зависимостей
Зависимости в языке 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:
Copyright ©
Шаблоны в языке 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:
Copyright ©
Совместное рассмотрение трех моделей
В результате анализа мы получаем три модели: объектную, динамическую и функциональную. При этом объектная модель составляет базу, вокруг которой осуществляется дальнейшая разработка. При построении объектной модели в ней не всегда указываются операции над объектами, так как с точки зрения объектной модели объекты это, прежде всего, структуры данных. Поэтому разработка системы начинается с сопоставления действиям и активностям динамической модели и процессам функциональной модели операций и внесения этих операций в объектную модель. С этого начинается процесс разработки программы, реализующей поведение, которое описывается моделями, построенными в результате анализа требований к системе. Поведение объекта задается его диаграммой состояния; каждому переходу на этой диаграмме соответствует применение к объекту одной из его операций; можно каждому событию, полученному объектом, сопоставить операцию над этим объектом, а каждому событию, посланному объектом, сопоставить операцию над объектом, которому событие было послано. Активности, запускаемой переходом на диаграмме состояний, может соответствовать еще одна (вложенная) диаграмма состояний. Результатом этого этапа проектирования является уточненная объектная модель, содержащая все классы проектируемой программной системы, в которых специфицированы все операции над их объектами. | |Comments:
Copyright ©
Третья фаза жизненного цикла - реализация объектно-ориентированного проекта
Третья фаза жизненного цикла программной системы состоит в реализации разработанных программных единиц (классов, функций, библиотек), которые в совокупности составляют разрабатываемую программную систему. Реализация каждой программной единицы может осуществляться как на объектно-ориентированном, так и на не объектно-ориентированном языке программирования, с использованием ранее разработанных программ, библиотек и баз данных. Каждый язык программирования имеет средства для выражения трех сторон спецификации разрабатываемой прикладной системы: структур данных, потоков управления и функциональных преобразований. В этом разделе будут рассмотрены проблемы, решаемые на этапе реализации объектно-ориентированного проекта, разработанного с использованием методологии OMT.| |
Comments:
Copyright ©
Управление глобальными ресурсами
Необходимо определить глобальные ресурсы и разработать механизмы управления доступом к ним. Глобальными ресурсами могут быть: процессоры, устройства внешней памяти, экран рабочей станции, логические имена (идентификаторы объектов, имена файлов, имена классов), доступ к базам данных и т.п. | |Comments:
Copyright ©
Вторая фаза жизненного цикла - конструирование системы
После того как прикладная задача исследована и результаты ее исследования зафиксированы в виде объектной, динамической и функциональной моделей, можно приступить к конструированию системы. На этапе конструирования системы принимаются решения о распределении подсистем по процессорам и другим аппаратным устройствам и устанавливаются основные принципы и концепции, которые формируют основу последующей детальной разработки программного обеспечения системы. Внешняя организация системы называется архитектурой системы. Выбор архитектуры системы является еще одной задачей, решаемой на этапе ее конструирования. Конструирование системы завершается конструированием ее объектов. На этом этапе разрабатываются полные определения классов и зависимостей, используемые на этапе реализации системы. Кроме того, определяются и конструируются внутренние объекты и оптимизируются структуры данных и алгоритмы. | |Comments:
Copyright ©
Вызов операций
В языке 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:
Copyright ©
Объектно-ориентированная разработка программ
Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. Говоря об объектно-ориентированной разработке, я имею в виду:Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным. На этапе разработки объекты - это некоторые формальные конструкции (например, прямоугольники с закругленными углами, с помощью которых они изображаются на схемах), никак пока не связанные с их будущей реализацией на одном из языков программирования. Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных методологий (технологий). Обычно эти объектно-ориентированные методологии поддерживаются инструментальными программными средствами, но и без таких средств они полезны, так как позволяют хорошо понять различные аспекты и свойства разрабатываемой программной системы, что в последующем существенно облегчает ее реализацию, тестирование, сопровождение, разработку новых версий и более существенную модификацию. Различные объектно-ориентированные методологии разработки программного обеспечения рассматриваются в разделах , и . Наиболее подробно рассматривается объектно-ориентированная методология OMT (Object Modeling Technique) (разделы 2 и 3), которая поддерживает две первые стадии жизненного цикла программных систем. Эта методология выбрана для демонстрации объектно-ориентированного подхода, потому что является одной из наиболее продвинутых и популярных объектно-ориентированных методологий. Более того, ее графический язык (система обозначений для диаграмм) получил достаточно широкое распространение и используется в некоторых других объектно-ориентированных методологиях, а также в большинстве публикаций по объектно-ориентированным методологиям. Методология OMT поддерживается системой Paradigm+, одной из наиболее известных инструментальных систем объектно-ориентированной разработки. Будут рассмотрены и некоторые другие объектно-ориентированные методологии разработки программных систем в сравнении с методологией OMT (раздел ):
| |
Comments:
Copyright ©
Объектно-ориентированные языки программирования
Вопросы реализации программного обеспечения, разработка которого велась с применением одной из объектно-ориентированных методологий, рассматриваются в разделе 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 ©
Абстрактные классы
Рассмотрим пример, представленный на рисунке 2.19. В нем рассмотрена операция подсчет выплат для различных категорий служащих фирмы: временных служащих с почасовой оплатой труда, постоянных служащих с понедельной оплатой труда и руководящих работников фирмы с помесячной оплатой. Каждая из категорий служащих представлена своим подклассом класса служащий, от которого они наследуют атрибут годовой_доход и операцию подсчет_выплат. Но подсчет выплат для каждой категории служащих производится по-своему, с учетом значений их собственных (неунаследованных) атрибутов; поэтому в каждом из подклассов операция подсчет_выплат переопределяется. Следовательно, в суперклассе операция подсчет_выплат может быть определена произвольным образом, так как она никогда не будет выполняться. В то же время сигнатуры всех операций подсчет_выплат в суперклассе и в подклассах должны быть одинаковыми (иначе это будут разные операции). Из сказанного следует, что в суперклассе можно задать только сигнатуру операции подсчет_выплат, это обеспечит одинаковые сигнатуры этой операции во всех подклассах. Методы, реализующие операцию подсчет_выплат, достаточно определить только в подклассах класса служащий. Суперкласс, в котором заданы только атрибуты и сигнатуры операций, но не определены методы, реализующие его операции, называется абстрактным классом. Методы, реализующие операции абстрактного класса, определяются в его подклассах, которые называются конкретными классами.
Рис. 2.19. Абстрактный класс
Абстрактный класс не может иметь объектов, так как в нем не определены операции над объектами; объекты должны принадлежать конкретным подклассам абстрактного класса. Абстрактные классы используются для спецификации интерфейсов операций (методы, реализующие эти операции впоследствии определяются в подклассах абстрактного класса). Абстрактные классы удобны на фазе анализа требований к системе, так как они позволяют выявить аналогию в различных, на первый взгляд, операциях, определенных в анализируемой системе. | |
Comments:
Copyright ©
Активности и действия
Диаграмма состояний была бы не очень полезной, если бы она содержала только переходы (безусловные и условные), соответствующие генерируемым во время работы системы событиям. Являясь описанием поведения объекта, диаграмма состояний должна описывать, что делает объект в ответ на переход в некоторое состояние или на возникновение некоторого события. Для этого в диаграмму состояний включаются описания активностей и действий. Активностью называется операция, связанная с каким-либо состоянием объекта (она выполняется, когда объект попадает в указанное состояние); выполнение активности требует определенного времени. Примеры активностей: выдача картинки на экран телевизора, телефонный звонок, считывание порции файла в буфер и т.п.; иногда активностью бывает просто приостановка выполнения программы (пауза), чтобы обеспечить необходимое время пребывания в соответствующем состоянии (это бывает особенно важно для параллельной асинхронной программы). Активность связана с состоянием, поэтому на диаграмме состояний она обозначается через "do: имя_активности" в узле, описывающем соответствующее состояние (см. рисунок 2.48).
Рис. 2.48. Указание активностей и действий на диаграмме состояний Действием называется мгновенная операция, связанная с событием: при возникновении события происходит не только переход объекта в новое состояние, но и выполняется действие, связанное с этим событием. Например, в телефонной сети событие повесил трубку сопровождается действием разъединить связь (см. рисунок 2.49). Действие указывается на диаграмме состояний вслед за событием, которому оно соответствует, и его имя (или описание) отделяется от имени события косой чертой ("/") (см. рисунок 2.48).
Рис. 2.49. Диаграмма состояний телефонной линии, на которой указаны активности и действия
Действия могут также представлять внутренние операции управления объекта, как например, присваивание значений атрибутам или генерация других событий. | |
Comments:
Copyright ©
Чем неудобны не объектно-ориентированные системы программирования
Различия между не объектно-ориентированными и объектно-ориентированными системами программирования в основном связаны не с возможностью выразить в программе требуемую функциональность (согласно теории алгоритмов любая функциональность может быть выражена на каждом языке программирования, либо не может быть выражена ни на одном языке программирования), а с выразительностью языка программирования, удобством составления программ, их отладки и сопровождения. Целесообразность использования объектно-ориентированных систем программирования связана со следующими обстоятельствами:Тем не менее даже в случае разработки прикладных программных систем в не объектно-ориентированных системах программирования использование методологии объектно-ориентированного проектирования этих систем, описанной в данном курсе, существенно упрощает их реализацию и последующее сопровождение. |
Comments:
Copyright ©
Дальнейшее исследование и усовершенствование модели
Лишь в очень редких случаях построенная объектная модель сразу же оказывается корректной. Модель должна быть исследована и отлажена. Некоторые ошибки могут быть найдены при исследовании модели без компьютера, другие - при ее интерпретации совместно с динамической и функциональной моделями на компьютере (эти модели строятся после того, как объектная модель уже построена). Здесь мы рассмотрим приемы бескомпьютерного поиска и исправления ошибок в объектной модели. В их основе лежат внешние признаки, по которым можно находить ошибки в модели; эти признаки могут быть объединены в следующие группы. Признаки пропущенного объекта (класса):Признаки ненужного (лишнего) класса:
Признаки пропущенных зависимостей:
Признаки ненужных (лишних) зависимостей:
Признаки неправильного размещения зависимостей:
Признаки неправильного размещения атрибутов:
Примеры практического применения описанных признаков см. в п. | |
Comments:
Copyright ©
Дальнейшее усовершенствование модели
Карточка выступает в двух сущностях: как регистрационная единица в банке (сберкнижка), обеспечивающая клиенту доступ к его счетам, и как структура данных, с которой работает ATM. Поэтому удобно расщепить класс карточка на два класса: регистрация_карточки и карточка; первый из этих классов обеспечивает клиенту доступ к его счетам в банке, а второй определяет структуру данных, с которой работает ATM. Класс проводка удобно представить как агрегацию классов изменение, так как проводка - это согласованная последовательность внесения изменений в счета и другие банковские документы; при работе с банковскими документами рассматривается три вида изменений: снятие, помещение и запрос. Класс банк естественно объединить с классом компьютер_банка, а класс консорциум - с классом центральный_компьютер.
Рис. 2.40. Окончательный вид объектной диаграммы для банковской сети
После внесения перечисленных изменений объектная диаграмма примет вид, представленный на рисунке 2.40. На этом построение объектной модели этапа предварительного проектирования заканчивается. Дальнейшие уточнения объектной модели будут производиться на следующих фазах жизненного цикла системы. | |
Comments:
Copyright ©
Диаграммы потоков данных
Функциональная модель представляет собой набор диаграмм потоков данных (далее - ДПД), которые описывают смысл операций и ограничений. ДПД отражает функциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. ДПД - это граф, на котором показано движение значений данных от их источников через преобразующие их процессы к их потребителям в других объектах. ДПД содержит процессы, которые преобразуют данные, потоки данных, которые переносят данные, активные объекты, которые производят и потребляют данные, и хранилища данных, которые пассивно хранят данные. Процессы Процесс преобразует значения данных. Процессы самого нижнего уровня представляют собой функции без побочных эффектов (примерами таких функций являются вычисление суммы двух чисел, вычисление комиссионного сбора за выполнение проводки с помощью банковской карточки и т.п.). Весь граф потока данных тоже представляет собой процесс (высокого уровня). Процесс может иметь побочные эффекты, если он содержит нефункциональные компоненты, такие как хранилища данных или внешние объекты. На ДПД процесс изображается в виде эллипса, внутри которого помещается имя процесса; каждый процесс имеет фиксированное число входных и выходных данных, изображаемых стрелками (см. рисунок 2.60).
Рис. 2.60. Примеры процессов
Процессы реализуются в виде методов (или их частей) и соответствуют операциям конкретных классов. Потоки данных Поток данных соединяет выход объекта (или процесса) со входом другого объекта (или процесса). Он представляет промежуточные данные вычислений. Поток данных изображается в виде стрелки между производителем и потребителем данных, помеченной именами соответствующих данных; примеры стрелок, изображающих потоки данных, представлены на рисунке 2.61. На первом примере изображено копирование данных при передаче одних и тех же значений двум объектам, на втором - расщепление структуры на ее поля при передаче разных полей структуры разным объектам.
Рис. 2.61. Потоки данных Активные объекты Активным называется объект, который обеспечивает движение данных, поставляя или потребляя их. Активные объекты обычно бывают присоединены к входам и выходам ДПД. Примеры активных объектов показаны на рисунке 2.62. На ДПД активные объекты обозначаются прямоугольниками.
Рис. 2.62. Активные объекты (экторы) Хранилища данных Хранилище данных - это пассивный объект в составе ДПД, в котором данные сохраняются для последующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в котором они были туда помещены. Агрегатные хранилища данных, как например, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, либо по ключам. Примеры хранилищ данных приведены на рисунке 2.63.
Рис. 2.63. Хранилища данных Потоки управления ДПД показывает все пути вычисления значений, но не показывает в каком порядке значения вычисляются. Решения о порядке вычислений связаны с управлением программой, которое отражается в динамической модели. Эти решения, вырабатываемые специальными функциями, или предикатами, определяют, будет ли выполнен тот или иной процесс, но при этом не передают процессу никаких данных, так что их включение в функциональную модель необязательно. Тем не менее иногда бывает полезно включать указанные предикаты в функциональную модель, чтобы в ней были отражены условия выполнения соответствующего процесса. Функция, принимающая решение о запуске процесса, будучи включенной в ДПД, порождает в ДПД поток управления (он изображается пунктирной стрелкой).
Рис. 2.64. Поток управления
На рисунке 2.64 изображен пример потока управления: клиент, желающий снять часть своих денег со счета в банке, вводит в ATM пароль и требуемую сумму, однако фактическое снятие и выдача денег происходит только в том случае, когда введенный пароль совпадает с его образцом. Несмотря на то, что потоки управления иногда оказываются весьма полезными, следует иметь в виду, что включение их в ДПД приводит к дублированию информации, входящей в динамическую модель. | |
Comments:
Copyright ©
Динамическая модель банковской сети
В качестве примера применения рассмотренных принципов построения динамической модели построим динамическую модель банковской сети. Начнем с составления и изучения сценариев.ATM просит клиента вставить карточку клиент вставляет карточку ATM принимает карточку и читает ее номер ATM просит ввести пароль
клиент вводит "1234." ATM передает номер и пароль в консорциум, консорциум проверяет номер и пароль, определяет код банка - "39" и сообщает ATM, что запрос принят
ATM просит клиента (с помощью меню на экране) выбрать вид проводки (снятие, вклад, перевод, запрос) клиент выбирает снятие ATM спрашивает клиента какова требуемая сумма клиент вводит $100 ATM убеждается, что введенная сумма в пределах лимита и просит консорциум выполнить проводку, консорциум передает запрос в банк, банк выполняет проводку и возвращает новое значение баланса счета ATM выдает сумму и просит клиента взять ее клиент берет деньги ATM спрашивает не нужно ли клиенту чего еще клиент вводит нет
ATM печатает счет, выдает карточку и просит клиента взять их клиент берет счет и карточку ATM просит (другого) клиента ввести карточку
Рис. 2.53. Нормальный сценарий для банковской сети
На рисунке 2.53 представлен нормальный сценарий обслуживания клиента в банковской сети; один из возможных сценариев, содержащих исключительные ситуации, показан на рисунке 2.54.
ATM просит клиента вставить карточку клиент вставляет карточку ATM принимает карточку и читает ее номер ATM просит ввести пароль клиент вводит "9999." ATM передает номер и пароль в консорциум; консорциум, проконсультировавшись с соответствующим банком, отвергает запрос ATM сообщает, что пароль введен неверно
клиент вводит "1234." ATM передает номер и пароль в консорциум, консорциум проверяет номер и пароль, определяет код банка - "39" и сообщает ATM, что запрос принят ATM просит выбрать вид проводки клиент выбирает снятие ATM спрашивает какова требуемая сумма клиент (раздумав брать деньги) набирает отмену ATM выдает карточку и просит клиента взять ее клиент берет карточку ATM просит (другого) клиента вставить карточку
Рис. 2.54. Сценарий для банковской сети, содержащий исключительные ситуации
Для каждого сценария можно составить соответствующую трассу событий (рисунок 2.55). Для этого выделяем в сценарии имена событий (событиями являются все сигналы, вводы данных, решения, прерывания, переходы и действия, выполняемые клиентом или внешними устройствами), указывая для каждого события объект, порождающий это событие (активный объект). Имея трассы событий, можно построить диаграммы состояний объектов проектируемой системы. Банковская сеть есть агрегация определенного числа параллельно и независимо работающих объектов четырех классов: консорциум, банк, ATM (банкомат) и клиент; поэтому состояние банковской сети определяется как кортеж состояний составляющих ее объектов: 1 объекта класса консорциум, b объектов класса банк, a объектов класса ATM (банкомат) и c объектов класса клиент (a, b, c - количество ATM, банков и клиентов сети соответственно). Классификация объектов, используемая при объектно-ориентированном подходе, позволяет вместо a+b+1 диаграмм состояний построить всего три (диаграммы состояний клиентов строить не нужно, так как их текущее состояние ясно и так).
Рис. 2.55. Трасса событий в банковской сети
Рис. 2.56. Привязка событий к объектам банковской сети
Построение диаграмм состояний начинается с привязки событий к объектам банковской сети (см. рисунок 2.56), являющимся источниками этих событий. Сначала рассматриваются нормальные события, потом исключительные события. Построение диаграммы состояний объекта (класса) может считаться законченным, когда диаграмма охватывает все рассматриваемые сценарии. Диаграммы состояний объектов классов ATM (банкомат), консорциум и банк представлены на рисунках 2.57, 2.58 и 2.59 соответственно.
Рис. 2.57. Диаграмма состояний объектов класса ATM (банкомат)
Рис. 2.58. Диаграмма состояний объектов класса консорциум
Рис. 2.59. Диаграмма состояний объектов класса банк
| |
Comments:
Copyright ©
Функциональная модель банковской сети
Функциональная модель показывает как вычисляются значения в системе и как они зависят одно от другого. Для конструирования функциональной модели необходимо выполнить следующее:Выполним все эти шаги, чтобы построить функциональную модель банковской сети (ATM). Определение входных и выходных значений Начнем с определения входных и выходных значений. Эти значения являются параметрами событий между системой и окружающим ее миром. Входные и выходные значения банковской сети показаны на рисунке 2.66 (пунктирная линия показывает границу системы).
Рис. 2.66. Входные и выходные значения банковской сети
Поскольку все взаимодействия между внешним миром и системой проходят через ATM (или кассовый терминал, который здесь не рассматривается), все входные и выходные значения являются параметрами событий, связанных с объектом ATM (банкомат). Построение ДПД ДПД обычно строится по уровням. На верхнем уровне, как правило, показывают один единственный процесс, или, как в нашем примере (рисунок 2.67), процесс ввода, основной процесс вычисления требуемых значений и процесс вывода. Входные и выходные данные на этой диаграмме поставляются и потребляются внешними объектами (клиент, карточка).
Рис. 2.67. Процессы верхнего уровня в системе обслуживания банковской сети
На ДПД каждого уровня указываются элементы данных более высоких уровней, чтобы показать данные, обрабатываемые каждым процессом (см. рисунок 2.68). Большая часть систем содержит внутренние хранилища данных, в которых хранятся данные в периодах между взаимодействиями. Для процесса выполнить проводку таким хранилищем является объект счет. Внутренние хранилища данных отличаются тем, что получаемые ими данные не выдаются немедленно, а хранятся в объекте для использования в будущем.
Рис. 2.68. ДПД процесса выполнить проводку в системе обслуживания банковской сети
ДПД показывают только зависимости между операциями; они не содержат информации о последовательности выполнения операций (операции, показанные на ДПД могут быть не всегда выполняемыми или исключающими одна другую). Например, пароль должен быть подтвержден до внесения изменений в счет; если он указан неверно, изменения в счет не вносятся. Последовательность выполнения операций указывается в динамической, а не в функциональной модели. Некоторые значения данных влияют на выбор последовательности вычислений в динамической модели; тем не менее эти значения не влияют непосредственно на выходные значения ДПД, так как ДПД показывает все возможные пути вычислений. Однако может оказаться полезным поместить функции, осуществляющие выбор последовательности вычислений, и в функциональную модель, так как эти функции могут выражать сложные зависимости от входных данных. Такие функции показаны на ДПД, но их выходными значениями являются управляющие сигналы, показанные пунктирными линиями. Примером такой функции является функция проверить пароль. Описание функций После того как ДПД составлена, необходимо составить описание каждой функции из ДПД. Пример описания функции приведен на . Мы не приводим других примеров описания функций банковской сети в виду их тривиальности. Описание ограничений Ограничения - это функциональные зависимости между объектами, не сводящиеся к непосредственным зависимостям между выходами и входами. Ограничения могут накладываться одновременно на два объекта, на различные объекты одного класса в различные моменты времени (инвариант), или на объекты разных классов в различные моменты времени (хотя в последнем случае это, как правило, связи между входами и выходами). Ограничения, которым должны удовлетворять входные значения функции, называются ее предусловиями, а ограничения, которым удовлетворяют выходные значения функции, - ее постусловиями. В банковской сети можно ввести следующие ограничения:
Определение критериев оптимизации Определяем какие значения необходимо максимизировать или минимизировать в процессе работы системы; если критериев оптимизации несколько и они противоречат один другому, следует определить компромиссные решения. На этой стадии не следует принимать по этому поводу слишком точных решений, так как в процессе дальнейшего проектирования критерии будут уточняться и изменяться. Оптимизационные критерии для банковской сети:
Операции вводятся на различных стадиях разработки модели проектируемой системы (см. выше):
На заключительном этапе разработки модели проектируемой системы все введенные операции вводятся в ее объектную модель. К перечисленным операциям добавляются операции, связанные с внешним поведением объектов рассматриваемых классов: эти операции определяются природой объектов, а не свойствами разрабатываемой системы. Такие операции расширяют определение объекта, выводя его за рамки непосредственных требований со стороны конкретной системы. Примерами таких операций для банковской сети являются: закрыть счет, создать сберегательный счет, создать банковскую карточку и т.п. С точки зрения системы эти операции не имеют смысла, но они отражают реальные свойства классов счет и карточка и могут оказаться полезными при использовании этих классов в других системах. В заключение следует исследовать объектную модель на предмет упрощения операций ее классов. Пример банковской сети недостаточно сложен, чтобы продемонстрировать это.
| |
Comments:
Copyright ©
Интерфейсы и окружения
Объекты и подсистемы, составляющие подсистему более высокого уровня, будем называть компонентами последней. Как уже было отмечено, для каждого компонента, входящего в состав объектной модели подсистемы, определен его интерфейс, т.е. набор открытых (общедоступных) операций, которые можно применять к этому компоненту (объекту или подсистеме). Интерфейс объекта определяется интерфейсом соответствующего класса и задается списком сигнатур его открытых операций (методов). Интерфейс подсистемы определяется через итерфейсы составляющих ее объектов и подсистем следующим образом: операция может быть включена в интерфейс подсистемы, если в составе этой подсистемы имеется объект (подсистема), интефейс которого содержит эту операцию. Интерфейсы описываются на языке описания интерфейсов IDL (Interface Definition Language). Все возможности по обработке данных внутри подсистемы (т.е. в каждом компоненте, входящем в ее состав) определяются набором интерфейсов ее компонентов, который определяет внутреннее окружение подсистемы. Если для некоторой подсистемы оказывается, что ни один ее компонент не содержит операции, которую желательно включить в ее интерфейс, в ее состав можно добавить объект, реализующий такую операцию. Такой объект называется интерфейсным объектом. Интерфейсные объекты позволяют согласовать внешний интерфейс подсистемы с ее внешним окружением, т.е. с интерфейсами других объектов и подсистем, которые вместе с рассматриваемой подсистемой составляют подсистему более высокого уровня. Поясним введенные понятия на примере системы банковского обслуживания. В ее составе можно выделить подсистему банк (на самом деле в системе будет несколько экземпляров подсистемы банк - по одной для каждого банка, входящего в консорциум). При этом объектная модель системы примет вид, изображенный на рисунке 2.43.
Рис. 2.43. Объектная диаграмма банковской сети после выделения подсистемы банк
При этом внешние интерфейсы подсистем банк и окружение вместе с интерфейсами объектов ATM и консорциум образуют внутреннее окружение системы банковского обслуживания. Ее внешнее окружение представлено на ; оно состоит из внешних интерфейсов различных программных систем, используемых в системе банковского обслуживания (на рисунке показана лишь часть этих систем), и ее собственного внешнего интерфейса. | |
Comments:
Copyright ©
Объектно-ориентированное программирование на Фортране
Объектно-ориентированное программирование на Фортране связано с большими техническими трудностями в связи с отсутствием в этом языке структур (записей) и динамических объектов. Но поскольку все еще имеется много любителей Фортрана, следует хотя бы кратко рассмотреть основные принципы реализации на Фортране проекта, разработанного по объектно-ориентированной методологии. Реализация классов с помощью массивов языка Фортран. В Фортране определен всего один структурный тип данных - массив, так что структуры (записи) тоже следует моделировать. Класс представляется как неявный набор массивов, по одному для каждого атрибута класса. Массивы должны иметь одинаковый размер, который должен быть достаточным для включения всех объектов этого класса, которые будут существовать во время выполнения программы, так как Фортран не поддерживает динамического распределения памяти. Значения индекса массивов представляют уникальный идентификатор объекта внутри соответствующего класса. При этом идентификаторы объектов разных классов будут иметь одинаковые значения, так что программист должен сам следить за тем, какому классу принадлежит объект (впрочем реализация механизма наследования, описываемая ниже, может несколько облегчить это). Все массивы одного и того же класса можно объединить в общий блок. Например, память для тысячи окон из рассматриваемого в этом разделе примера может быть организована следующим образом:COMMON/WINDOW/XMIN,YMIN,XMAX,YMAX,WINDOW REAL XMIN(1000),YMIN(1000),XMAX(1000),YMAX(1000),WINDOW(1000) INTEGER NWINDOW
Программист должен организовать счетчик порожденных объектов данного класса (NWINDOW), и присваивать его значения уникальным идентификаторам вновь порождаемых объектов. В Фортране нет средств определения новых типов данных, поэтому нет возможности определить тип Length: данные этого типа должны иметь один из определенных в Фортране типов (INTEGER, REAL, COMPLEX, LOGICAL и CHARACTER). В Стандарте Фортрана ограничена длина идентификаторов, однако большая часть компиляторов поддерживают идентификаторы в 32 и более символов.
В примерах фрапгментов фортранных программ предполагается, что допустимы достаточно длинные идентификаторы, которые могут содержать символ подчеркивания ("_"). Если компилятор не поддерживает длинных имен, все идентификаторы из примеров следует заменить более короткими, что, естественно, ухудшит читаемость программ. Таким образом, в объектной программе на Фортране каждый объект некоторого класса может быть представлен индексом атрибутных массивов этого класса, причем указанный индекс определяет доступ к атрибутам этого объекта:
INTEGER AWINDOW REAL X1 X1 = XMIN(AWINDOW)
При передаче параметров методам объект может передаваться как соответствующий ему индекс атрибутных массивов соответствующего класса:
SOUBROUTINE WINDOW__ADD_TO_SELECTIONS (SELF, SHAPE) INTEGER SELF, SHAPE
Объект, значение которого запрашивается, но не изменяется, может быть в случае необходимости передан как список значений его атрибутов, хотя, конечно, индекс обычно короче, и его передавать удобнее.
FUNCTION CIRCLE__PICK(X0, Y0, RADIUS, X, Y) LOGICAL CIRCLE__PICK REAL X0, Y0, RADIUS, X, Y
Размещение объектов в памяти. Обычно размещение новых объектов производится в заранее определенные массивы. Если требуется динамическое распределение памяти, необходимо самому смоделировать управление кучей в своей программе:
FUNCTION CREATE_WINDOW(X1, Y1, WIDTH, HEIGHT) COMMON/WINDOW/XMIN,YMIN,XMAX,YMAX,WINDOW REAL XMIN(1000),YMIN(1000),XMAX(1000),YMAX(1000),WINDOW(1000) INTEGER NWINDOW INTEGER CREATE_WINDOW REAL X1, Y1, X2, Y2 NWINDOW = NWINDOW + 1 XMIN(NWINDOW) = X1 YMIN(NWINDOW) = Y1 XMAX NWINDOW) = X1 + WIDTH YMAX NWINDOW) = Y1 + HEIGHT CREATE_WINDOW = NWINDOW RETURN END
Реализация наследования. В Фортране нет записей (структур) и тем более вариантных записей. Поэтому наследование при программировании на Фортране можно реализовать либо в виде универсальной записи, либо моделируя вариантные записи. Первый способ связан с излишними затратами памяти, его следует применять, когда вариантная часть записей сравнительно невелика.
При этом подходе организуется универсальная запись, содержащая все атрибуты корневого класса и все атрибуты всех наследующих ему классов. При работе с конкретным классом из рассматриваемой иерархии классов те атрибуты, которые для него не определены, просто игнорируются. Универсальная запись реализуется, как и раньше, через набор массивов одинаковой длины, по одному на каждое поле записи:
COMMON/SHAPE/XMIN,YMIN,XMAX,YMAX,WINDOW,RADIUS,NSHAPE REAL XMIN(1000),YMIN(1000),XMAX(1000),YMAX(1000),WINDOW(1000) REAL RADIUS(1000) INTEGER NSHAPE
Второй способ более экономен. Он состоит в представлении класса как набора подклассов, каждый из которых реализован как самостоятельный класс со своим набором массивов и индексами объектов. Каждый класс представляется парой целых массивов: один из этих массивов содержит код подкласса, другой - индексы объектов в соответствующем массиве подкласса. В следующем примере определен класс ITEM, который имеет подклассы SHAPE (содержит не более 1000 объектов) и GROUP (содержит не более 100 объектов). Общий блок CLASSES определяет целочисленный код для каждого класса.
COMMON/ITEM/ITEM_CLASS,ITEM_ID,NITEM INTEGER ITEM_CLASS(1100),ITEM_ID(1100) INTEGER NITEM/0/ COMMON/CLASSES/GROUP,BOX,CIRCLE INTEGER GROUP/1/,BOX/2/,CIRCLE/3/
Когда создается новый объект, значение индекса должно выбираться как из суперкласса, так и из соответствующего подкласса. Например, следующий код создает новый круг (CIRCLE):
FUNCTION CREATE_CIRCLE(X0,Y0,RADIUS0) COMMON/WINDOW/XMIN,YMIN,XMAX,YMAX,WINDOW сюда следует поместить описания общих блоков ITEM, SHAPE и CLASSES INTEGER CREATE_CIRCLE NSHAPE = NSHAPE + 1 X(NSHAPE) = X0 Y(NSHAPE) = Y0 RADIUS(NSHAPE) = RADIUS0 NITEM = NITEM + 1 ITEM_CLASS(NITEM) = CIRCLE ITEM_ID(NITEM) = NSHAPE CREATE_CIRCLE = NITEM RETURN END
Резолюция методов. Вызовы методов для объектов, класс которых известен во время компиляции, осуществляются как непосредственные вызовы соответствующих фортранных подпрограмм. Остальные объекты должны содержать номер класса (см.выше общий блок CLASSES). Для каждой операции можно составить управляющую подпрограмму, которой в качестве параметров передаются номер класса и индекс объекта. Управляющая подпрограмма содержит оператор перехода по вычислению, который позволяет вызывать требуемый метод:
FUNCTION PICK(CLASS,ID,PX,PY) LOGICAL PICK LOGICAL GROUP_PICK,BOX_PICK,CIRCLE_PICK INTEGER CLASS,ID GOTO(100,200,300) CLASS PICK = .FALSE. RETURN 100 PICK = GROUP_PICK(ID,PX,PY) RETURN 200 PICK = BOX_PICK(ID,PX,PY) RETURN 300 PICK = CIRCLE_PICK(ID,PX,PY) RETURN END
| |
Comments:
Copyright ©
Обобщение и наследование
Обобщение и наследование позволяют выявить аналогии между различными классами объектов, определяют многоуровневую классификацию объектов. Так, в графических системах могут существовать классы, определяющие обрисовку различных геометрических фигур: точек, линий (прямых, дуг окружностей и кривых, определяемых сплайнами), многоугольников, кругов и т.п. (рисунок 2.17).
Рис. 2.17. Обобщение (выделение суперклассов)
Обобщение позволяет выделить класс одномерные фигуры и считать классы прямая, дуга и сплайн подклассами класса одномерные фигуры, а класс одномерные фигуры - суперклассом классов прямая, дуга и сплайн. Если при этом принять соглашение, что атрибуты и операции суперкласса действительны в каждом из его подклассов (говорят, что эти атрибуты и операции наследуются подклассами), то одинаковые атрибуты и операции классов прямая, дуга и сплайн (подклассов) могут быть вынесены в класс одномерные фигуры (суперкласс). Аналогично можно поступить и с двумерными фигурами, определив для классов многоугольник и круг суперкласс двумерная фигура. Наконец, можно определить класс фигура как суперкласс классов нульмерная фигура, одномерная фигура и двумерная фигура. Легко видеть, что отношения "подкласс - суперкласс" (обобщение) и "суперкласс - подкласс" (наследование) транзитивны, что позволяет строить классификационные деревья. При этом атрибуты и операции каждого суперкласса наследуются его подклассами всех уровней (мы как бы выносим за скобки одинаковые операции). Это значительно облегчает и сокращает описание классов. На схемах обобщение (наследование) изображается треугольничком (рисунок 2.17). Треугольничек следует ставить даже в том случае, когда суперкласс имеет всего один подкласс. Слово размерность, следующее за верхним треугольничком на рисунке 2.17, является дискриминатором. Дискриминатор - это атрибут типа "перечисление", показывающий, по какому из свойств объектов сделано данное обобщение. Другие примеры обобщения (наследования) показаны на рисунке 2.18 (эти примеры связаны с основным нашим примером - системой обслуживания клиентов банковским консорциумом).
Рис. 2.18. Другие примеры обобщения (наследования)
Необходимо отметить, что, как показывает опыт практического проектирования систем, следует избегать обширных многоуровневых классификаций, так как поведение подклассов низших уровней многоуровневой классификации бывает трудно понять: большая часть (а нередко и все) атрибутов и операций таких классов определена в их суперклассах различных уровней. Если количество уровней классификации стало непомерно большим, нужно слегка изменить структурирование системы. Чтобы понять, какое число уровней является непомерно большим, можно руководствоваться следующими оценками: два-три уровня наследования, как правило, приемлемы всегда (мне известна одна фирма, разрабатывающая программные системы, в которой издан стандарт фирмы, запрещающий более чем трехуровневые классификации в программах); десятиуровневая классификация почти всегда неприемлема; пять-шесть уровней, как правило, достаточно для программистов и не слишком обременяет администрацию. Обобщение и наследование широко применяются не только при анализе требований к программным системам и их предварительном проектировании, но и при их реализации. Иногда в подклассе бывает необходимо переопределить операцию, определенную в одном из его суперклассов. Для этого операция, которая может быть получена из суперкласса в результате наследования, определяется и в подклассе; это ее повторное определение "заслоняет" ее определение в суперклассе, так что в подклассе применяется не унаследованная, а переопределенная в нем операция. Напомним, что каждая операция определяется своей сигнатурой; следовательно, сигнатура переопределения операции должна совпадать с сигнатурой операции из суперкласса, которая переопределяется данной операцией. Так, в примере, изображенном на рисунке 2.17, в классе круг переопределяется операция вращение его суперкласса фигура (при повороте круга его изображение не меняется, что позволяет сделать операцию вращение в классе круг пустой). Переопределение может преследовать одну из следующих целей:
Целесообразно придерживаться следующих семантических правил наследования:
Следуя этим правилам, которые, к сожалению, редко поддерживаются объектно-ориентированными языками программирования, можно сделать разрабатываемую программу более понятной, легче модифицируемой, менее подверженной влиянию различных ошибок и недосмотров.
| |
Comments:
Copyright ©
Одновременные события Синхронизация
На рисунке 2.50 представлена диаграмма состояний составного объекта: он состоит из четырех параллельно и независимо работающих компонентов (состояние каждого компонента не зависит от состояний остальных компонентов). Состояние такого объекта определяется как кортеж, членами которого являются состояния каждого из составляющих объектов. Диаграмма состояний при этом распадается на четыре независимые диаграммы состояний каждого из компонентов. В системах, состоящих из нескольких параллельно работающих объектов, иногда бывает необходимо согласовать (синхронизировать) работу двух или более объектов. Для этого тоже используются события, так как синхронизация по существу состоит в необходимости задержать переход одного из синхронизируемых объектов в очередное состояние, пока другой объект не придет в некоторое фиксированное состояние, а переходы из состояния в состояние управляются событиями. Синхронизирующее событие может вырабатываться в любом из синхронизируемых объектов, либо в каком-либо третьем объекте.
Рис. 2.50. Диаграмма состояний составного объекта (подсистемы)
Если синхронизирующее событие вырабатывается вне синхронизируемого объекта, оно может быть передано ему из другого объекта; на диаграмме это обозначается как показано на рисунке 2.51.
Рис. 2.51. Передача события из одного объекта другому
Если объект получает события из нескольких независимых объектов, то состояние, в которое он перейдет, может зависеть от порядка, в котором будут получены эти события (а этот порядок случаен, так как объекты независимы). Это называется условием конкуренции. Одной из задач проектирования является исключение нежелательных условий конкуренции. Это достигается с помощью синхронизации. Синхронизация используется и в случае, когда в каком-либо состоянии требуется параллельно выполнить несколько активностей. В качестве примера рассмотрим устройство вывода ATM (рисунок 2.52). Оно одновременно (параллельно) выдает наличные деньги и карточку; обе эти операции можно рассматривать как составную активность, состоящую из двух параллельно работающих активностей (пунктирная линия на диаграмме состояний делит состояние на две области, в каждой из которых выполняется одна из указанных активностей). Разделение управления на два параллельных потока схематически показано в виде стрелки, которая разделяется на две: событие готов вызывает переход из состояния установка сразу в два параллельных подсостояния состояния выдача; переход в следующее состояние происходит по двум событиям деньги взяты и карточка взята; если какое-либо из этих событий произойдет раньше другого, перехода все равно не будет, пока не произойдет и второе событие (в этом и состоит синхронизация).
Рис. 2.52. Синхронизация в подсистеме
Из рассмотренного примера видно, что в различных состояниях может параллельно работать разное число процессов (активностей). | |
Comments:
Copyright ©
Ограничения
Ограничение указывает на зависимость между соответственными значениями двух объектов, либо между различными значениями одного объекта. Ограничение может быть выражено в виде некоторой функции (количественное ограничение), либо отношения (качественное ограничение). Нас интересуют ограничения на атрибуты объектов, а также на состояния и события. Важным видом ограничений являются инварианты: утверждения о том, что значение некоторой функции от атрибутов, состояний и событий остается постоянным при функционировании объекта. | |Comments:
Copyright ©
Описание операций
Процессы ДПД в конце концов должны быть реализованы как операции объектов. Каждый процесс нижнего (базового) уровня, так же как и процессы верхних уровней, в состав которых входят процессы более нижних уровней, реализуются как операции. При этом реализация процессов верхних уровней может отличаться от их представления на ДПД, так как при реализации обычно производится их оптимизация: в результате оптимизации процессы нижних уровней, составляющие процесс более высокого уровня могут "слиться", после чего они станут невидимы. Все операции должны быть специфицированы. Спецификация операции содержит ее сигнатуру (имя операции, количество, порядок и типы ее параметров, количество, порядок и типы возвращаемых ею значений) и описание ее эффекта (действия, преобразования). Для описания эффекта операции можно использовать:Пример описания операции (эффект ее описан на естественном языке) приведен на рисунке 2.65.
изменить_счет (счет, сумма, вид_проводки) -> деньги, квитанция если сумма снимается и больше баланса счета, то "отменить_проводку" если сумма снимается и меньше баланса счета, то "дебетовать_счет" и "выдать_деньги" если сумма вносится на счет то "кредитовать_счет" если запрос то "выдать_запрос" во всех случаях: квитанция должна содержать номер ATM, дату, время, номер счета, вид проводки, сумму проводки (если она есть), новый баланс счета
Рис. 2.65. Спецификация операции изменить_счет (при описании эффекта операции использованы операции отменить_проводку, выдать_запрос, выдать_деньги, дебетовать_счет и кредитовать_счет)
Внешняя спецификация операции описывает только те изменения, которые видны вне операции. Операция может быть реализована таким образом, что при ее выполнении будут использоваться некоторые значения, определенные внутри операции (например, в целях оптимизации), некоторые из этих значений могут даже быть частью состояния объекта.
Эти детали реализации операции скрыты от остальных объектов и не участвуют в определении внешнего эффекта операции. Изменения внутреннего состояния объекта, не видные вне его, не меняют значения объекта. Все нетривиальные операции можно разделить на три категории: запросы, действия и активности. Запросом называется операция без побочных эффектов над видимым извне объекта его состоянием (чистая функция). Запрос, у которого нет параметров, кроме целевого объекта, является производным атрибутом. Например, для точки на координатной плоскости, радиус и полярный угол - производные атрибуты; из этого примера видно, что между основными и производными атрибутами нет принципиальной разницы, и выбор основных атрибутов во многом случаен. Действием называется операция, имеющая побочные эффекты, которые могут влиять на целевой объект и на другие объекты системы, которые достижимы из целевого объекта. Действие не занимает времени (логически, оно совершается мгновенно). Каждое действие может быть определено через те изменения, которые оно производит в состоянии объекта, меняя значения его атрибутов и связей; в каком порядке производятся эти изменения, несущественно: мы считаем, что все они происходят одновременно и мгновенно. Наиболее распространенным способом описания действия является задание алгоритма его выполнения на компьютере. Активностью называется операция, выполняемая объектом, или над объектом, выполнение которой занимает определенное время. Активность имеет побочные эффекты. Активности могут быть только у активных объектов, так как пассивные объекты есть попросту склады данных. | |
Comments:
Copyright ©
Определение классов
Анализ внешних требований к проектируемой прикладной системе позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стэк и т.п. на этом этапе вводить не следует. Начать нужно с выделения возможных классов из письменной постановки прикладной задачи (технического задания и другой документации, предоставленной заказчиком). Следует иметь в виду, что это очень сложный и ответственный этап разработки, так как от него во многом зависит дальнейшая судьба проекта. При определении возможных классов нужно постараться выделить как можно больше классов, выписывая имя каждого класса, который приходит на ум. В частности, каждому существительному, встречающемуся в предварительной постановке задачи, может соответствовать класс. Поэтому при выделении возможных классов каждому такому существительному обычно сопоставляется возможный класс. Далее список возможных классов должен быть проанализирован с целью исключения из него ненужных классов. Такими классами являются:После исключения имен всех ненужных (лишних) возможных классов будет получен предварительный список классов, составляющих проектируемую систему. | |
Comments:
Copyright ©
Определение объектов и классов
В пункте сформулирована задача и приведена схема сети банковского обслуживания (). Анализируя эту постановку задачи, можно выделить возможные классы, сопоставив их существительным, упомянутым в ее предварительной формулировке; получится следующий список возможных имен классов (в алфавитном порядке):| ATM (банкомат) | кассир | программное обеспечение |
| банк | кассовый терминал | система |
| банковская сеть | квитанция | проверка безопасности |
| данные проводки | клиент | служба ведения записей |
| данные счета | компьютер банка | счет |
| деньги | консорциум | цена |
| доступ | пользователь | центральный компьютер |
| карточка | проводка |
Исследуем этот список, исключая из него имена классов в соответствии с рекомендациями п. :
После исключения всех лишних имен возможных классов получаем следующий список классов, составляющих проектируемую систему банковского обслуживания (эти классы представлены на ):
| ATM (банкомат) | кассовый терминал | проводка |
| банк | клиент | счет |
| карточка | компьютер банка | центральный компьютер |
| кассир | консорциум |
| |
Comments:
Copyright ©
Определение зависимостей
На следующем этапе построения объектной модели определяются зависимости между классами. Прежде всего из классов исключаются атрибуты, являющиеся явными ссылками на другие классы; такие атрибуты заменяются зависимостями. Смысл такой замены в том, что зависимости представляют собой абстракцию того же уровня, что и классы, и потому не оказывают непосредственного влияния на будущую реализацию (ссылка на класс лишь один из способов реализации зависимостей). Аналогично тому, как имена возможных классов получались из существительных, встречающихся в предварительной постановке прикладной задачи, имена возможных зависимостей могут быть получены из глаголов или глагольных оборотов, встречающихся в указанном документе. Так обычно описываются: физическое положение (следует_за, является_частью, содержится_в), направленное действие (приводит_в_движение), общение (разговаривает_с), принадлежность (имеет, является_частью) и т.п. Пример выделения явных и неявных глагольных оборотов из предварительной постановки конкретной прикладной задачи рассмотрен в п. Затем следует убрать ненужные или неправильные зависимости, используя следующие критерии:пример в п. ); при исключении избыточных (производных) зависимостей нужно быть особенно осторожным, так как не все дублирующие одна другую зависимости между классами избыточны; в некоторых случаях другие зависимости позволяют установить только существование еще одной производной зависимости, но не позволяют установить кратность этой зависимости; например, в случае, представленном на рисунке 2.36, фирма имеет много служащих и владеет многими компьютерами; каждому служащему предоставлено для персонального использования несколько компьютеров, кроме того, имеются компьютеры общего пользования; кратность зависимости предоставлен_для_использования не может быть выведена из зависимостей служит и владеет; хотя производные зависимости и не добавляют новой информации, они часто бывают удобны; в этих случаях их можно указывать на диаграмме, пометив косой чертой.
Рис. 2.36. Неизбыточные зависимости
Удалив избыточные зависимости, нужно уточнить семантику оставшихся зависимостей следующим образом:
| |
Comments:
Copyright ©
Оптимизация разработки
Объектная модель, построенная на этапе анализа требований к программной системе, содержит информацию о логической структуре системы; на этапе разработки объектная модель уточняется и пополняется: в нее добавляются детали, связанные с необходимостью обеспечить более эффективный доступ к информационным структурам во время работы системы. Цель оптимизации разработки - заменить семантически корректную, но недостаточно эффективную модель, построенную на этапе анализа, более эффективной. В процессе оптимизации разработки выполняются следующие преобразования:На этапе анализа требований к программной системе избыточные зависимости нежелательны, так как они не вносят в модель новой информации. Однако на этапе разработки мы должны приспособить структуру объектной модели к требованиям эффективной реализации системы. Пример использования избыточной (производной) зависимости для повышения эффективности поиска представлен на рисунке 3.9: на рисунке 3.9(а) показаны зависимости из исходной объектной модели; добавление производной (и, следовательно, избыточной) зависимости (рисунок 3.9(б)) позволяет резко ускорить поиск сотрудников, говорящих по-китайски.
Рис. 3.9. Ускорение поиска с помощью производной зависимости
Использование производных атрибутов для исключения повторных вычислений показано на рисунке 3.10: запоминание координат однажды найденных атрибутов и операций в специальных списках позволяет избежать повторного поиска.
Рис. 3.10. Использование производных атрибутов для исключения повторных вычислений
Рис. 3.11. Использование производной зависимости
На рисунке 3.11 показано, как введение производной зависимости позволяет не перевычислять координаты перекрывающихся элементов окон в оконной системе для графического дисплея. Производные атрибуты должны изменять свои значения, когда меняются их базовые значения. Для обеспечения этого пользуются одним из трех методов:
| |
Comments:
Copyright ©
Организация системы классов, используя наследование
Далее необходимо постараться найти суперклассы для введенных классов. Это полезно, так как проясняет структуру модели и облегчает последующую реализацию. Соответствующий пример рассмотрен в п. . | |Comments:
Copyright ©
Организация системы классов с использованием наследования
В рассматриваемом примере естественно определить суперклассы для объектов, определяющих различные терминалы: кассовый_терминал и ATM (банкомат), и для объектов, определяющих проводки: проводка_кассира и удаленная_проводка (с банкомата). Внеся соответствующие изменения, получим объектную диаграмму, представленную на рисунке 2.39.
Рис. 2.38. Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов
Рис. 2.39. Объектная диаграмма для банковской с учетом наследования
| |
Comments:
Copyright ©
Передача параметров методам
Дополнительный параметр каждого метода, определяющий экземпляр структуры (класса), к которому следует применить этот метод, рекомендуется реализовывать как указатель. Хотя в языке C и допускаются параметры, имеющие тип структуры, передача значения структуры в качестве параметра связана с переписыванием значения этой структуры в автоматическую память соответствующей функции, что не только связано с потерей эффективности, но и семантически неверно, когда структура определяет объект, так как применение метода должно изменить значения соответствующих полей этой структуры (они представляют атрибуты объекта). Пример передачи параметров одному из методов (этот метод входит в список методов, приведенный в комментарии к определению структуры Window):add_to_selections (shape, self) struct Window* self; struct Shape* shape;
| |
Comments:
Copyright ©
Подготовка словаря данных
Отдельные слова имеют слишком много интерпретаций. Поэтому необходимо в самом начале проектирования подготовить словарь данных, содержащий четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте. Без такого словаря обсуждение проекта с коллегами по разработке и заказчиками системы не имеет смысла, так как каждый может по-своему интерпретировать обсуждаемые термины. Пример такого словаря см. в п. . | |То же самое лицо, держащее счет и в другом банке рассматривается как другой клиент. Компьютер_банка - компьютер, принадлежащий банку, который взаимодействует с сетью ATM (банкоматов) и собственными кассовыми_терминалами банка. Банк может иметь свою внутреннюю компьютерную сеть для обработки счетов, но здесь мы рассматриваем только тот компьютер_банка, который взаимодействует с сетью ATM. Консорциум - объединение банков, которое обеспечивает работу сети ATM (банкоматов). Сеть передает в консорциум проводки банков. Проводка - единичный интегрированный запрос на выполнение некоторой последовательности операций над счетами одного клиента. Было сделано предположение, что ATM (банкоматы) только выдают деньги, однако для них не следует исключать возможности печати чеков или приема денег и чеков. Хотелось бы также обеспечить гибкость системы, которая в дальнейшем обеспечит возможность одновременной обработки счетов разных клиентов, хотя пока этого не требуется. Различные операции должны быть правильно сбалансированы. Счет - единичный банковский счет, над которым выполняются проводки. Счета могут быть различных типов; клиент может иметь несколько счетов. Центральный_компьютер - компьютер, принадлежащий консорциуму, который распределяет проводки и их результаты между ATM (банкоматами) и компьютерами_банков. Центральный_компьютер проверяет коды банков, но не выполняет проводок самостоятельно. | |
Comments:
Copyright ©
Преобразование классов в структуры данных
В языке C класс можно рассматривать как тип структуры, определенный в этом языке: поля структуры соответствуют атрибутам класса (при этом каждый атрибут может иметь простой, либо составной тип, т.е. тип структуры или массива). В таком случае каждый объект некоторого класса будет представлен конкретной структурой, экземпляром соответствующего типа структуры. Методы реализуются в виде набора функций, описания которых можно указать в комментарии при определении типа структуры, определяющего описываемый класс. Программист должен сам следить за тем, чтобы при работе с экземплярами этого типа структуры использовались для доступа к ее полям только функции, перечисленные в указанном комментарии. В языке C++ это автоматически отслеживается компилятором и его подсистемой поддержки выполнения программ. Все функции, соответствующие методам, имеют дополнительный параметр, определяющий экземпляр структуры (объект), к которому применяется метод. В языке C++ этот параметр автоматически подставляется компилятором. Например, класс Window можно представить как следующую структуру (struct) языка C:struct Window { /* структура соответствует классу * class Window * для которого определены следующие методы (все методы имеют * дополнительный параметр, Window* this, определяющий экземпляр * структуры (объект), к которому применяется метод): * public: * Window(Length x0, Length y0, Length width, Length height, * Window* this); * D_Window (Window* this); -- соответствует деструктору ~Window() * void add_box (Length x, Length y, Length width, Length height, * Window* this); * void add_circle (Length x, Length y, Length radius, Window* this); * void clear_selections (Window* this); * void cut_selections (Window* this); * Group* group_selections (Window* this); * void move_selections (Length deltax, Length deltay, Window* this); * void redraw_all (Window* this); * void select_item (Length x, Length y, Window* this); * void ungroup_selections (Window* this); * private: * void add_to_selections (Shape* shape, Window* this); */ Length xmin; Length ymin; Length xmax; Length ymax; }; При этом предполагается, что тип Length введен через typedef floast Length; Ссылки на объекты класса Window реализуются как указатели языка C: struct Window* window; Length x1 = window->xmin;
Объект может быть при этом размещен статически, автоматически (в стеке), или динамически (в куче). | |
Comments:
Copyright ©
Размещение объектов в памяти
Объекты, определенные в программе на языке C могут размещаться в памяти программы (статические глобальные объекты), в стеке (автоматически размещаемые локальные объекты), или в куче (динамические объекты). Время жизни статических объектов - это все время выполнения программы. Они используются для хранения глобальных переменных и констант, но при объектно-ориентированной разработке программ стараются использовать как можно меньше глобальных объектов, так как они нарушают модульную структуру программы. Глобальные объекты в языке C объявляются на внешнем уровне программного файла, вне составляющих его функций; инициализация таких объектов обычно производится при их порождении во время компиляции программы. Пример объявления статического (глобального) объекта:static struct Window outer_window = {0.0, 0.0, 8.5, 11.0};
При вызове методов, использующих объявленную глобальную переменную, им следует передавать ее адрес (&outer_window). Промежуточные временные данные обычно размещаются в стеке. Удобство использования таких данных в том, что они размещаются в памяти и удаляются из нее автоматически. При этом программист сам должен следить, чтобы при выходе из блока не оставалось бы указателей на автоматические объекты этого блока, являющихся значениями объектов (или их частей), которые остаются в памяти после выхода из блока. Объекты, живущие дольше функций, в которых они порождаются, не следует размещать в переменных, автоматически размещаемых в стеке; это может привести к изощренным ошибкам в программе, которые очень трудно обнаружить. Динамически размещаемые объекты необходимо использовать, когда во время компиляции программы неизвестно их количество. Такие объекты размещаются в куче по запросу (функции malloc или сalloc) во время выполнения программы. Будучи размещенным в памяти динамический объект сохраняется в ней до тех пор, пока не будет явным образом отменен (функция free). Пример функции размещения и инициализации динамического объекта:
struct Window* create_window(xmin, ymin, width, height); Length xmin, ymin, width, height; { struct Window* window; /*размещение объекта*/ window = (struct Window*)malloc(sizeof(struct Window)); /*инициализация объекта*/ window-> xmin = xmin; window-> ymin = ymin; window-> xmax = xmin + width; window-> ymax = ymin + height; return window; };
Перед удалением динамического объекта с помощью функции free необходимо удостовериться, что не осталось указателей на этот объект. | |
Comments:
Copyright ©
Разработка алгоритмов, реализующих полученные операции
Каждой операции, определенной в уточненной объектной модели, должен быть сопоставлен алгоритм, реализующий эту операцию. При выборе алгоритма можно руководствоваться следующими соображениями:
Рис. 3.8. Сравнение рекурсивного и нерекурсивного алгоритмов вычисления n!
Выбор алгоритмов связан с выбором структур данных, обрабатываемых этими алгоритмами. Удачный выбор структур данных позволяет существенно оптимизировать алгоритм. Еще одним способом упрощения и оптимизации алгоритмов является введение внутренних (вспомогательных) классов. Эти классы не имеют соответствий в реальном мире; они связаны с реализацией, но могут существенно упростить ее (примеры: класс стек, класс двусвязный список и т.п.). Наконец, во многих случаях бывает полезным внести некоторые изменения в структуру объектной модели. Эти изменения сводятся к введению дополнительных классов и к перераспределению операций между классами. При распределении операций по классам руководствуются следующими соображениями:
| |
Comments:
Copyright ©
Разработка зависимостей
Зависимости - это "клей" объектной модели: именно они позволяют рассматривать модель как нечто целое, а не просто как множество классов. Односторонние зависимости можно реализовать с помощью ссылок (указателей) (см. рисунок 3.14). При этом, если кратность зависимости равна единице, ей соответствует один указатель, если кратность больше единицы, то множество указателей.
Рис. 3.14. Реализация односторонней зависимости
На рисунке 3.15 показан способ реализации двусторонней зависимости с помощью указателей.
Рис. 3.15. Реализация двусторонней зависимости
На рисунке 3.16 показан способ реализации зависимости с помощью таблицы (как в реляционных базах данных).
Рис. 3.16. Реализация зависимости с помощью таблицы
При реализации зависимостей с помощью указателей атрибуты зависимостей (связей) переносятся в один из классов, участвующих в зависимости. | |
Comments:
Copyright ©
Реализация наследования
В языке Eiffel список наследования помещается вслед за ключевым словом inherit:class ITEM export cut, move, pick, ungroup feature cut is deferred end; move (deltax, deltay: REAL) is deferred end; pick (x, y: REAL): BOOLEAN is deferred end; ungroup () is deferred end class SHAPE export cut, draw, erase, move, pick, ungroup, write inherit ITEM feature * x, y: REAL; cut is end; draw is end; erase is end; move (deltax, deltay: REAL) is end; pick (x, y: REAL): BOOLEAN is end; ungroup is end; write (acolor: COLOR) is deferred end; end classrBOX export pick, write inherit SHAPE redefine pick, write feature width, height: REAL; Create (x0, y0, width0, height0:*REAL) is end; pick (x, y: REAL): BOOLEAN is end; write (acolor: COLOR) is end end class CIRCLE export pick, write inherit SHAPE redefine pick, write feature radius: REAL; Create (x0, y0, radius0: REAL) is end; pick (x, y: REAL): BOOLEAN is end; write (acolor: COLOR) is end end
Для обозначения абстрактных операций используется ключевое слово deferred; такие операции должны быть реализованы во всех подклассах. Переопределение свойств класса в подклассе отмечается в разделе redefine. В языке Smalltalk описание класса Item, его подкласса Shape, а также подклассов Box и Circle класса Shape может иметь следующий вид:
class name Item superclass Object class name Shape superclass Item instance variables x y instance methods cut draw erase move: aPoint ungroup class name Box superclass Shape instance variables width height instance methods pick: aPoint write: aColor class methods createAt: aPoint width: widthSize length: lengthSize class name Circle superclass Shape instance variables radius instance methods pick: aPoint write: aColor class methods createAt: aPoint radius: radiusSize
Все атрибуты суперкласса доступны всем его потомкам. Все методы могут быть переопределены в подклассах. Множественное наследование не поддерживается. | |
Comments:
Copyright ©
Наследование в языке C реализуются через указатели. Рассмотрим, например, конкретные подклассы Box и Circle абстрактного класса Shape. На языке C их можно представить следующим образом:
struct Shape { struct ShapeClass* class; Length x; Length y; }; struct Box { struct BoxClass* class; Length x; Length y; Length width; Length height; }; struct Circle { struct CircleClass* class; Length x; Length y; Length radius; };
Указатель на структуры Box или Circle можно передать функции, ожидающей указатель на Shape, так как первые несколько членов структур Box и Circle идентичны первым членам структуры Shape (это позволяет привести тип указателя на структуру Box или Circle привести к типу указателя на структуру Shape). | |
Comments:
Copyright ©
Реализация управления
Реализация управления связана с реализацией динамической модели объектов системы. Известны три подхода к реализации динамической модели:Процедурное управление является традиционным способом реализации динамической модели; в этом случае состояние объекта определяется текущим оператором программы, а каждому переходу соответствует оператор ввода: следующее состояние определяется по текущему состоянию и вводимому имени события. Пример практического использования процедурного управления представлен на рисунке 3.12.
Рис. 3.12. Псевдокод, соответствующий динамической модели ATM
| |
В языке Eiffel для реализации зависимостей применяются конструкции, аналогичные соответствующим конструкциям языка C++. Поддерживаются параметризованные (родовые (generic)) контейнерные объекты (обычно эти объекты параметризуются относительно типов объектов, которые они содержат). Базовая библиотека классов системы Eiffel содержит контейнерный класс LINKED_LIST, который можно использовать для реализации зависимости типа "много к одному" между классами ITEM и GROUP:
class ITEM export get_group -- выборочный экспорт в класс GROUP set_group(GROUP), forget_group(GROUP) feature get_group: GROUP is do Result := mygroup end; set_group(g:GROUP) is do mygroup := g end; forget_group is do forget(mygroup) end; end --ITEM class GROUP export add_item, remove_item, get_items inherit ITEM feature items: LINKED_LIST[ITEM]; --параметризованный тип Create is do items.Create end; add_item(value:ITEM) is do items.finish; items.insert_right(value); value.set_group(Current) end; remove_item(value:ITEM) is do items.search(value,l); items.delete; value.forget_group end; get_items(number:INTEGER):ITEM is do Result := items end; end --GROUP
Язык Eiffel обеспечивает выборочный экспорт относительно любого свойства. В рассматриваемом примере в класс GROUP экспортируются свойства set_group и forget_group класса ITEM. Это поддерживает инкапсуляцию путем ограничения доступа по записи данных в объекты классов, участвующих в зависимости между ITEM и GROUP. Операция forget языка Eiffel предназначена для освобождения памяти; она освобождает память, занимаемую объектом, который является ее операндом, а также присваивает объектной ссылке неопределенное значение. В языке Smalltalk большую часть зависимостей помогает реализовать богатая системная библиотека классов. Например, для реализации зависимости типа "много-к-одному" между графическими объектами (Item) и группой, в которую они входят (Group) можно использовать библиотечный класс Set:
class name Item superclass Object class name Shape superclass Item instance variables group instance methods cut draw erase move: aPoint ungroup --дополнительные методы getGroup |group --приватные методы putGroup: aGroup group <- aGroup class name Group superclass Item instance variables items class methods new |((super new)putItems:(Set new)) instance methods pick: aPoint write: aColor addItem: anItem items add: anItem. anItem putGroup: self removeItem items remove: anItem. anItem putGroup: nil getItems |items copy --приватные методы putItems: aSet items <- aSet
Ввиду того, что в системе Smalltalk не производится контроль типов, нет никаких ограничений на тип объектов, которые можно добавить в группу: любой объект, который соответствует сообщению putGroup:, допустим. Строка приватные методы является комментарием, сообщающим программисту, что методы, перечисленные после этой строки лучше использовать как приватные; если он не последует этому совету, система все равно не зафиксирует ошибку, так как Smalltalk не поддерживает приватности методов и данных, и на самом деле все методы общедоступны. | |
Comments:
Copyright ©
Для реализации зависимостей есть те же две возможности, что и в случае объектно-ориентированных окружений: отображение зависимостей на указатели (ссылки), или реализация зависимостей с помощью вспомогательных объектов. Если зависимости отображаются на указатели (наиболее традиционный подход для бинарных зависимостей), для этих указателей предусматриваются дополнительные поля в структурах (записях), представляющих объекты взаимно-зависимых классов; если зависимость множественная (хотя бы в одну из сторон), то представляющий ее указатель ссылается не на класс, а на последовательность (в смысле STL) указателей объектов соответствующего класса. Поскольку все зависимости двусторонние, каждый объект из указанной последовательности тоже должен иметь указатель, определяющий рассматриваемую зависимость. С помощью вспомогательных объектов обычно реализуются зависимости, которые трудно представить через указатели (например, зависимости между несколькими классами). В качестве примера первого способа реализации зависимостей рассмотрим реализацию зависимости (типа "много к одному") между классами Item и Group:
struct Item { struct ItemClass* class; struct Group* group; }; struct Group { struct GroupClass* class; int item_count; struct Item** items; };
| |
Comments:
Copyright ©
События, состояния объектов и диаграммы состояний
Текущее состояние объекта характеризуется совокупностью текущих значений его атрибутов и связей. Во время работы системы составляющие ее объекты взаимодействуют друг с другом, в результате чего изменяются их состояния. Единицей влияния является событие: каждое событие приводит к смене состояния одного или нескольких объектов в системе, либо к возникновению новых событий. Работа системы характеризуется последовательностью происходящих в ней событий. События Событие происходит в некоторый момент времени (нередко оно используется для определения соответствующего момента времени). Примеры событий: старт ракеты, старт забега на 100 м, начало проводки (в банковской сети), выдача денег и т.п. Событие не имеет продолжительности (точнее, оно занимает пренебрежимо малое время). Одно из событий может логически предшествовать другому, либо следовать за другим, либо они могут быть независимыми; примерами логически (причинно) связанных событий являются старт и финиш одного забега, начало проводки и выдача денег клиенту (в результате этой проводки), примерами независимых событий - старт ракеты и финиш забега, проводки, запущенные с разных ATM, и т.п. Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent); такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности. События передают информацию с одного объекта на другой. Существуют классы событий, которые просто сигнализируют о том, что что-то произошло или происходит (примеры: загорание лампочки лифта, гудок в телефонной трубке). В программировании рассматриваются исключительные события (иногда их называют исключениями), которые сигнализируют о нарушениях работы аппаратуры, либо программного обеспечения. Сценарии и трассы событий Сценарием называется последовательность событий, которая может иметь место при конкретном выполнении системы.Сценарии могут иметь разные области влияния: они могут включать все события, происходящие в системе, либо только события, возникающие и влияющие только на определенные объекты системы. На рисунке 2.44 приведен пример сценария пользования телефонной линией. Каждое событие в этом сценарии передает информацию с одного объекта на другой; например событие начинается длинный гудок передает сигнал от телефонной линии к вызывающему (пользователю). При анализе динамики работы системы необходимо составить и рассмотреть несколько сценариев, отражающих типичные варианты ее работы. вызывающий снимает трубку начинается длинный гудок вызывающий набирает цифру (9) гудок прекращается вызывающий набирает цифру (3) вызывающий набирает цифру (9) вызывающий набирает цифру ( ) вызывающий набирает цифру ( ) вызывающий набирает цифру ( ) вызывающий набирает цифру ( ) вызванный телефон начинает звонить вызывающий слышит гудки вызванный телефон отвечает гудки прекращаются телефоны соединены вызванный по телефону вешает трубку телефоны разъединены вызывающий вешает трубку
Рис. 2.44. Пример сценария: разговор по телефону
Следующим этапом после разработки и анализа сценариев является определение объектов, генерирующих и принимающих каждое событие сценария. Последовательности событий с привязкой к объектам проектируемой системы удобно представлять на диаграммах, называемых трассами событий. Пример трассы событий для разговора по телефону представлен на рисунке 2.45. Вертикальные линии изображают на этой диаграмме объекты, а горизонтальные стрелки - события (стрелка начинается в объекте, генерирующем событие, и заканчивается в объекте, принимающем событие). Более поздние события помещены ниже более ранних, одновременные - на одном уровне.
Рис. 2.45. Трасса событий для разговора по телефону Состояния Состояние определяется совокупностью текущих значений атрибутов и связей объекта. Например, банк может иметь состояния платежеспособный и неплатежеспособный (когда большая часть банков одновременно оказывается во втором состоянии, наступает банковский кризис). Состояние определяет реакцию объекта на поступающее в него событие (в том, что реакция различна нетрудно убедиться с помощью банковской карточки: в зависимости от состояния банка обслуживание (реакция банка на предъявление карточки) будет разным).
Реакция объекта на событие может включать некоторое действие и/или перевод объекта в новое состояние. Объект сохраняет свое состояние в течение времени между двумя последовательными событиями, которые он принимает: события представляют моменты времени, состояния - отрезки времени; состояние имеет продолжительность, которая обычно равна отрезку времени между двумя последовательными событиями, принимаемыми объектом, но иногда может быть больше. При определении состояний мы не рассматриваем тех атрибутов, которые не влияют на поведение объекта, и объединяем в одно состояние все комбинации значений атрибутов и связей, которые дают одинаковые реакции на события. Диаграммы состояний Диаграмма состояний связывает события и состояния. При приеме события следующее состояние системы зависит как от ее текущего состояния, так и от события; смена состояния называется переходом. Диаграмма состояний - это граф, узлы которого представляют состояния, а направленные деги, помеченные именами соответствующих событий, - переходы. Диаграмма состояний позволяет получить последовательность состояний по заданной последовательности событий.
Рис. 2.46. Диаграмма состояний телефонной линии
На рисунке 2.46 приведена, в качестве примера, диаграмма состояний телефонной линии. Другие примеры диаграмм состояний см. в последующих пунктах. | |
Comments:
Copyright ©
Условия
Условие - это логическая (булева) функция от значений объектов, как например, карточку удалось прочитать, температура ниже нуля и т.п. Условие может выполняться в течение некоторого отрезка времени; событие, в отличие от условия, происходит мгновенно и не имеет продолжительности во времени. Условия могут использоваться как ограничения на переходы: условный переход выполняется только тогда, когда и произошло соответствующее событие, и выполнено условие этого перехода (диаграмма состояний, представленная на рисунке 2.47, демонстрирует это на примере автомобильного движения по магистралям "Север-Юг" и "Запад-Восток"). На диаграммах состояний условия записываются вслед за событиями в квадратных скобках.
Рис. 2.47. Диаграмма состояний, на которой указаны условия
| |
Comments:
Copyright ©
Уточнение атрибутов
На следующем этапе уточняется система атрибутов: корректируются атрибуты классов, вводятся, в случае необходимости, новые атрибуты. Атрибуты выражают свойства объектов рассматриваемого класса, либо определяют их текущее состояние. Атрибуты обычно соответствуют существительным; например цвет_автомобиля (свойство объекта), позиция_курсора (состояние объекта). Атрибуты, как правило, слабо влияют на структуру объектной модели. Не следует стремиться определить как можно больше атрибутов: большое количество атрибутов усложняет модель, затрудняет понимание проблемы. Необходимо вводить только те атрибуты, которые имеют отношение к проектируемой прикладной системе, опуская случайные, малосущественные и производные атрибуты. Наряду с атрибутами объектов необходимо ввести и атрибуты зависимостей между классами (связей между объектами). При уточнении атрибутов руководствуются следующими критериями:Применяя критерии, сформулированные в п. , получим: Карточка содержит код_банка и код_карточки; их можно считать атрибутами объектов класса карточка, но удобнее использовать в качестве квалификаторов, так как код_банка обеспечивает выбор банка, сокращая кратность зависимости консорциум - банк; для аналогичного использования кода_карточки необходимо добавить зависимость Банк выпускает карточки, квалификатором которой будет код_карточки. После внесения перечисленных изменений диаграмма примет вид, представленный на . | |
Comments:
Copyright ©
Уточнение наследования классов
Уточняя определения классов и операций, стараемся увеличить степень наследуемости: чем больше классов находятся в отношении наследования, тем меньше функций, реализующих операции этих классов необходимо будет запрограммировать. Для увеличения степени наследуемости следует:Иногда одна и та же операция бывает определена в нескольких классах, что позволяет ввести общий суперкласс для этих классов, в котором и реализуется эта операция. Но чаще операции в разных классах бывают похожими, но не одинаковыми. В таких случаях нужно попытаться внести несущественные изменения в определения этих операций, чтобы они стали одинаковыми, т.е. имели одинаковый интерфейс и семантику. При этом можно использовать следующие приемы:
Использование делегирования операций можно пояснить на следующем примере (рисунок 3.13). Класс стек близок классу список, причем операциям стека push и pop соответствуют очевидные частные случаи операций списка add и remove. Если реализовать класс стек как подкласс класса список, то придется применять вместо операций push и pop более общие операции add и remove, следя за их параметрами, чтобы избежать записи или чтения из середины стека; это неудобно и чревато ошибками. Гораздо лучше объявить класс список телом класса стек (делегирование), обращаясь к операциям списка через операции стека. При этом, не меняя класса список, мы заменяем его интерфейс интерфейсом класса стек.
Рис. 3.13. Реализация стека с использованием наследования(а) и делегирования(б)
| |
Comments:
Copyright ©
Вложенные диаграммы состояний
Диаграмма состояний компонента трансмиссия () имеет узел (состояние) вперед, который сам является диаграммой состояний (вложенная диаграмма состояний). Интерпретация этой диаграммы следующая: трансмиссия имеет три состояния: нейтральное, назад и вперед; состояние вперед имеет три подсостояния (они уточняют состояние вперед): первая, вторая и третья. На диаграммах состояний суперсостояние изображается как прямоугольник с закругленными углами, внутрь которого помещаются все его подсостояния. | |Comments:
Copyright ©
Выбор методов для операций
В объектно-ориентированных языках одна и та же операция нередко реализуется одновременно несколькими методами (полиморфизм). Выбор нужного метода осуществляется в объектно-ориентированных окружениях автоматически, и в этом одно из главных преимуществ объектно-ориентированных языков. Если программа, разработанная по объектно-ориентированной методологии, реализуется на языке, не являющемся объектно-ориентированным, то проблема выбора методов обычно решается во время выполнения программы. Методы, выбор которых возможен во время компиляции, на языке C могут быть реализованы как непосредственные вызовы соответствующих функций. Это прежде всего относится к тем операциям, которые реализуются только одним методом, что снимает проблему выбора. Например, все методы в классе Window уникальны (единственны). Однако наиболее общий подход состоит в определении для каждого класса дескриптора, содержащего указатели на все методы для каждой операции, видимой из этого класса, включая унаследованные операции. Каждый дескриптор класса является структурой языка C, элементами которой являются все операции, определенные в этом классе или унаследованные им от суперкласса. Следующий фрагмент программы содержит определения дескрипторов класса для классов Item, Shape, Box и Circle:struct ItemClass { char* class_name; void(* cut)(); void(* move)(); Boolean(* pick)(); void(* ungroup)(); }; struct ShapeClass { char* class_name; void(* cut)(); void(* move)(); Boolean(* pick)(); void(* ungroup)(); void(* write)(); }; struct BoxClass { char* class_name; void(* cut)(); void(* move)(); Boolean(* pick)(); void(* ungroup)(); void(* write)(); }; struct CircleClass { char* class_name; void(* cut)(); void(* move)(); Boolean(* pick)(); void(* ungroup)(); void(* write)(); };
В дескрипторе класса определены операции, видимые в этом классе, но остается необходимость определить и проинициализировать дескрипторы класса для каждого класса: в каждом поле дескриптора класса должно стоять имя функции, которая реализует метод, определенный в этом классе или унаследованный им (например, класс Box наследует операцию move у класса Shape, но заменяет операции pick и write своими собственными методами:
struct BoxClass BoxClass = { "Box", Shape__cut, Shape__move, Box__pick, Shape__ungroup, Box__write, }; struct CircleClass CircleClass = { "Circle", Shape__cut, Shape__move, Circle__pick, Shape__ungroup, Circle__write, };
Если у класса есть атрибуты уровня класса, их тоже можно запомнить в дополнительных полях дескриптора класса. Например, можно поместить в дескриптор класса имя этого класса и использовать его во время отладки, или каким-либо другим образом. Отметим, что дескриптор класса не нужен абстрактному классу (например, Shape). Когда порождается новый объект, указатель на его дескриптор класса помещается в поле Class структуры, представляющей этот объект:
struct Circle * create_circle(x0,y0,radius0) Length x0,y0,radius0; { struct Circle * new_circle; new_circle = (struct Circle*)malloc(sizeof(struct Circle)); new_circle->class = &CircleClass; new_circle->x = x0; new_circle->y = y0; new_circle-> radius = radius0; return new_circle; };
Если выбор метода для операции должен быть сделан во время выполнения программы, то для определения нужной функции используется дескриптор класса. Например, вызов операции pick для формы (Shape), определяемой во время выполнения программы, требует следующего кода:
struct Shape* shape; Length x,y; Boolean status; status = (*shape->class->pick)(shape,x,y);
Динамический выбор метода требует двух дополнительных обращений к памяти по сравнению с непосредственным вызовом функции. | |
Comments:
Copyright ©
Программирование: Языки - Технологии - Разработка
- Программирование
- Технологии программирования
- Разработка программ
- Работа с данными
- Методы программирования
- IDE интерфейс
- Графический интерфейс
- Программирование интерфейсов
- Отладка программ
- Тестирование программ
- Программирование на Delphi
- Программирование в ActionScript
- Assembler
- Basic
- Pascal
- Perl
- VBA
- VRML
- XML
- Ada
- Lisp
- Python
- UML
- Форт
- Языки программирования