Опубликован: 23.10.2005 | Доступ: свободный | Студентов: 4086 / 201 | Оценка: 4.44 / 4.19 | Длительность: 33:04:00
Специальности: Программист
Лекция 2:

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

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >

Описание полной системы

Для завершения проекта следует заняться управлением сессией. При функциональной декомпозиции эту задачу выполняла процедура execute_session - главная программа. Но мы знаем, как сделать это лучшим образом. Как ранее говорилось (см. лекцию 5 курса "Основы объектно-ориентированного программирования") главная функция системы, позиционируемая как верхняя функция в проектировании сверху вниз, - это нечто мифическое. Большие программные системы выполняют множество одинаково важных функций. И здесь основанный на АТД подход является предпочтительным. Вся система в целом рассматривается как множество абстрактных объектов, способных выполнять ряд служб ( services ).

Ранее мы рассмотрели одну ключевую абстракцию - STATE. Какая же абстракция в нашем рассмотрении осталась пропущенной? Ответ очевиден: центральным в нашей системе является понятие APPLICATION, описывающее специфическую интерактивную систему, подобную системе резервирования билетов. Это приводит нас к следующему классу.

Компоненты классов State и Application

Рис. 2.8. Компоненты классов State и Application

Заметьте, все не вошедшие в класс STATE программы функциональной декомпозиции стали теперь компонентами класса APPLICATION:

  • Execute_session - описывает, как выполнять сессию, ее имя теперь разумно упростить и называть просто execute, так как дальнейшую квалификацию обеспечивает имя класса.
  • Initial и is_final - указывают, какие состояния имеют специальный статус в приложении. Конечно же, их разумно включить именно в класс APPLICATION, а не в класс STATE, поскольку они описывают свойства приложения, а не состояния, которое является заключительным или начальным только по отношению к приложению, а не само по себе. При повторном использовании состояние, бывшее заключительным в одном приложении вполне может не быть таковым для другого приложения.
  • Transition - описывает переходы между состояниями приложения.

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

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

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

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

Все эти операции и другие будут в равной степени являться компонентами класса APPLICATION. Здесь нет более или менее важных программ, чем наша бывшая "главная программа", - процедура execute, ставшая теперь обычным компонентом класса, равная среди других, но не первая. Устраняя понятие вершины, мы подготавливаем систему к эволюции и повторному использованию.

Класс приложения

Для завершения рассмотрения класса APPLICATION рассмотрим несколько возможных реализационных решений:

  • Будем нумеровать состояния приложения числами от 1 до n. Заметьте, эти числа не являются абсолютными свойствами состояний, они связаны с определенным приложением, поэтому в классе STATE нет атрибута "номер состояния". Вместо этого, одномерный массив associated_state, атрибут класса APPLICATION, задает состояние, связанное с заданным номером.
  • Представим функцию переходов transition еще одним атрибутом - двумерным массивом размерности n * m, где m - число возможных пользовательских выборов при выходе из состояния.
  • Номер начального состояния хранится в атрибуте initial и устанавливается в подпрограмме choose_initial. Для конечных состояний мы используем соглашение, что переход в псевдосостояние 0 означает завершение сессии.
  • Процедура создания в классе APPLICATION использует процедуры создания библиотечных классов ARRAY и ARRAY2. Последний описывает двумерные массивы и построен по образцу ARRAY ; его процедура создания make принимает четыре аргумента, например create a.make (1, 25, 1, 10), а его подпрограммы item и put используют два индекса - a.put (x, 1, 2). Границы двумерного массива a можно узнать, вызвав a.lower1 и так далее.

Вот определение класса, использующего эти решения:

indexing
    description: "Интерактивные приложения, управляемые панелями"
class APPLICATION creation
    make
feature -- Initialization
    make (n, m: INTEGER) is
    -- Создает приложение с n состояниями и m возможными выборами
    do
            create transition.make (1, n, 1, m)
            create associated_state.make (1, n)
    end
feature -- Access
    initial: INTEGER
            -- Номер начального состояния
feature -- Basic operations
    execute is
            -- Выполняет сессию пользователя
        local
            st: STATE; st_number: INTEGER
        do    
            from
                st_number := initial
            invariant
                0<= st_number; st_number <= n
            until st_number = 0 loop
                st := associated_state.item (st_number)
                st.execute
            -- Вызов процедуры execute класса STATE.
            -- (Комментарии к этой ключевой инструкции даны в тексте.)
                st_number := transition.item (st_number, st.choice)
            end
        end
feature -- Element change
    put_state (st: STATE; sn: INTEGER) is
            -- Ввод состояния st с индексом sn
        require
            1 <= sn; sn <= associated_state.upper
        do
            associated_state.put (st, sn)
        end
    choose_initial (sn: INTEGER) is
            -- Определить состояние с номером sn в качестве начального
        require
            1 <= sn; sn <= associated_state.upper
        do
            initial := sn
        end
    put_transition (source, target, label: INTEGER) is
            -- Ввести переход, помеченный label,
            -- из состояния с номером source в состояние target
        require
            1 <= source; source <= associated_state.upper
            0 <= target; target <= associated_state.upper
            1 <= label; label <= transition.upper2
        do
            transition.put (source, label, target)
        end
feature {NONE} -- Implementation
    transition: ARRAY2 [STATE]
    associated_state: ARRAY [STATE]
    ... Другие компоненты ...
invariant
    transition.upper1 = associated_state.upper
end -- class APPLICATION

Обратите внимание на простоту и элегантность вызова st.execute. Компонент execute класса STATE является эффективным (полностью реализованным) поскольку описывает известное общее поведение состояний, но его реализация основана на вызове компонентов: read, message, correct, display, process, отложенных на уровне STATE, эффективизация которых выполняется потомками класса, такими как RESERVATION. Когда мы помещаем вызов st.execute в процедуру execute класса APPLICATION, у нас нет информации о том, какой вид состояния обозначает st, но благодаря статической типизации мы точно знаем, что это состояние. Далее включается механизм динамического связывания и в период исполнения st становится связанной с объектом конкретного вида, например RESERVATION, - тогда вызовы read, message и других царственных особ автоматически будут переключаться на нужную версию.

Значение st, полученное из associated_state, представляет полиморфную структуру данных ( polymorphic data structure ), содержащую объекты разных типов, все из которых согласованы (являются потомками) со STATE. Текущий индекс st_number определяет операции состояния.

Полиморфный массив состояний

Рис. 2.9. Полиморфный массив состояний

Вот как строится интерактивное приложение. Приложение должно быть представлено сущностью, скажем air_reservation, класса APPLICATION. Необходимо создать соответствующий объект:

create air_reservation.make (number_of_states, number_of_possible_choices)

Далее независимо следует определить и создать состояния приложения, как сущности классов-потомков STATE, либо новые, либо уже готовые и взятые из библиотеки повторного использования. Каждое состояние s связывается с номером i в приложении:

air_reservation.put_state (s, i).

Затем одно из состояний выбирается в качестве начального:

air_reservation.choose_initial (i0)

Для установления перехода от состояния sn к состоянию с номером tn, с меткой l используйте вызов:

air_reservation.enter_transition (sn, tn, l)

Это включает и заключительные состояния, для которых по умолчанию tn равно 0. Затем можно запустить приложение:

air_reservation.execute_session.

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

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

< Лекция 1 || Лекция 2: 123456 || Лекция 3 >