И. Соммервилл - Инженерия программного обеспечения (1133538), страница 56
Текст из файла (страница 56)
Когда преобразования последовательно обрабатывают пакеты данных, такал архитектурная модель называется пакетной последовательной моделью. Она является основой для многих классов систем обработки данных. Примером могут быть системы (напрнмср, системы обработки счетов), которыс гснсрируют большое количество выходных отчетов, получснных с помощью несложных вычислсний, ио с большим количеством входных эаписсй. Пример такого типа системной архитектуры показан на рис. 10.10.
Здесь органиэация выписывает счета заказчикам. Раз в неделю платежные квитанции согласуются со счетами. Для оплаченных счстов выдастся квитанция. По счетам, нс оплаченным в течение установлснного срока, выдастся соответствующее увсдомлснис. Рик 10.10. Модооь лоиокоо донных длл сиппелы оБ~тБотки ььиоьоо 220 т%асть П1. Проектирование Отметим, что данная модель представляет только часть системы обработки счетов— прн выписке счетов используются другие преобразования. Сравните данную модель с объ. екпю-ориентированной, рассмотренной в предыдущем разделе. Объектная модель более абстрактна, так как в ней не содержится информации о последовательности действий.
Данная архитектура имеет ряд преимуществ. 1. Возможность повторного использования преобразований, 2. Понятность, поскольку большинство людей также мыслят в терминах обработки входных и выходных данных 3. Возможность модификации системы путем непосредственного добавления новых преобразований. 4. Простота реализации как последовательной, так и параллельной систем.
Принципиальный недостаток модели связан с неабходниостью использования некоторого общего формата передачи данных, который должен распознаватьсл всеми преобразо. эаниями. Каждое преобразование либо следует согласовывать со смежными преобразованиями относительно формата обрабатываемых данных, либо нужно предложить стандарт. ный формат для всех обрабатываемых данных. Каждое преобразование должно выполнять грэмлгатическнй разбор входных данных и синтезировать выходные данные по соответствующей форме, при этом вычислительная нагрузка на систему возрастает.
Невозможно интегрировать преобразования, использующие несовместимые форматы данных. Взаимодействующие системы трудно описать с помощью модели потоков данных из-за от. суктвия прогнозируемого потока обрабатываемых данных. Хотя обычный текстовой ввод и вывод можно смоделировать с помощью модели потоков данных, графические интерфейсы пользователя ииеют более сложные форматы ввода-вывода и управление, основанное на разнообразных сабьггиях (например, щелчок кнопкой мыши илн выбор из меню). Перевод их в форму, совместимую с моделью потоков даннь1х, является достаточно сложной задачей.
10.4. Проблемно-зависимые архитектуры Рассмотренные ранее архитектурные модели являются обобщенными. Они широко применяются для многих классов приложений. Наряду с основными моделями, используются архитектурные модели, характерные для конкретной предметной области приложения. Эти модели называю гся ироблемиоиыиоиммми архиэиктурими. Можно выделить два типа проблемно-зависимых архнтекгурных моделей. 1. Ми)ыи кооггоо пивин. Отображают классы реальных систем, вобрав в себя основные хъ рзктернстнкн этих классов.
Как правило, архитектурные модели классов встречаются в системах реального времени. например в системах сбора данных, мониторинга н т д. 2. Бозооиэ модели. Более абстрактны и предоставляют разработчикам информацию по общей струкгуре какого. либо типа систем. Например, в работе [298) предложена базовая модель разработки ПО. Конечно, четких различий между этими видами моделей нет.
В некоторых случаях ма. дели классов служат в качестве базовых. Здесь я провожу различие между ними, поскольку базовые модели можно напрямую повторно испольэовать в проекте. Базовые модели обычно используются в системах коммуникаций и при сравнении возможных системных архитектур. Различны также процессы разработки этих моделей. Модели классов разрабатываются как обобщение существующих систем "снизу вверх", в то время как разработка бэзовык моделей идет "сверку вниз". 10.
Архитектурное проектирование 221 10.4.1. Модели классов систем Модель компилятора, вероятно, наиболее известный пример архитскгурной модели класса систем. В настоящее время разработаны тысячи компиляторов. Считается, что компилятор должен включать перечисленные ниже модули. 1. Лексический анализатор, транслирующий входной язык в некоторый внутренний код.
2. Таблица идентификаторов, выдаваемая лексическим анализатором, в которой со. держится информация об используемых в программе именах и типах. 3. Синтаксический анализатор, который проверяет синтаксис компилируемого кода. Он использует заданную грамматику языка и создает синтаксическое дерево.
4. Синтаксическое дерево, которое представляет внутреннюю структуру компилируе. мой программы. 5. Семантический анализатор, который проверяет семантическую корректность про. грамм на основании информации, полученной из синтаксического дерева и таблицы идентификаторов. 6. Генератор кода, который проходит по синтаксическому дереву и генерирует ма- шинный код. В компиляторе могут быть и другие компоненты, которые преобразуют синтаксическое дерево, повышают эффективность и устраняют избыточность из сгенерированного машинного кода.
Компоненты, из которых состоит компилятор, можно организовывать в соответствии с разными архитектурными моделями. Можно применить архитектуру потоков данных, в которой таблица идентификаторов служит хранилищем совместно используемых данных. Этот подход отображен на рис. 10.11, здесь этапы лексического, синтаксического и семантического анализа выполняются последовательно. Рис. 10. 11. Модель вожаков донныл для канякэлэюра Такая модель до сих пор широко применяется. Она эффективна там, где программы компилируются и выполняются без участия пользователя, т.е. в пакетном режиме. Однако такие модели оказываются менее эффективными, если компилятор интегрирован с другими языковыми средствами, например системой редактирования структур, интерактивным отладчиком, программой подготовки печатных документов и т.п. В этом случае, как показано на рис.
10.12, компоненты системы можно организовать в соответствии с моделью репозитория. В представленной модели компилятора таблица гщентификаторов и синтаксическое дерево используются как центральное кранилище информации, или рспозиторий, через который взаимодействуют инструментальные средства. Другие данные, такие кэк грамматические правила и определение выходного формата программы, беругся из инструментальных средств и также помещаются в репознторий. 222 а%эсть 1П.
Проектирование Рис. 10. 12. Модель реяозивифия длл как яиляоюрп В настоящее время разработано относительно небольшое количество проблемно- зависимых моделей классов систем. Организации, занимаюгциеся разработкой подобных моделей, рассматривают их как ценную интеллектуальную собственность, поскольку они явллются основой разработки программных систем. Такие модели часто представляют архитектуру целой серии программных продуктов. Например, для всех драйверов принтеров, независимо от свойств конкретного принтера, может использоватьсл одинаковая походная архитектура.
Подобные архитектуры рассматриваются в главе 14. 10.4.2. Базовые архитектуры Архитектурные модели классов систем отражают архитектуры уже существующих систем. В противоположность им базовые модели обычью появляются как результат исследо. вапнй в определенной предметной области приложения. Они представляют собой идеализированную архитектуру, в которой отражены особенности, присущие системам, рабо.
тающим в данной предиетной области. Примероьь базовой архитектуры может служить модель ОЯ [502], являющаяся стандартом взаимодействия открытых систем (краткое описание этой модели приведено в разделе 10.1 б). Если некоторая система совместима с этой моделью, она может взаимо. лействовать с любыми другими системами, поддерживающими этот стандарт.
Таким образом, система управления ассортиментом товаров в супермаркете, разработанная на основе модели О51, может непосредственно осуществлять обмен даниымн с системой заказов поставщиков, также разработанной на основе этой модели. С другой стороны, базовые модели обычно не рассматриваются в качестве методов реализации. Их основное назначение — служить эталоном для сравнения различных систсь~ в какой-либо предметной области, т.е, базовая модель явллется стандартом при оценке различных систем. Изображенная па рис.
10.13 модель О5! является семиуровневой моделью взаимодей. стана открытых систем. Точное назначение разных слоев здесь не существенно. Заметим только, что нижние уровни обеспечивают физическое взаимодействие, средние уровни— передач> данных, а верхние уровни — передачу семантически значимой информации, па. пример стандартизированных документов и т.п. 10. Архитектурное цроектнрованне 223 1зис. 10. 13.
АРкиямкозуда базовой модели 081 Перед разработчиками модели ОБ1 была постзвлена конкретная цель — создать стандарт, на основе которого осуществлялось бы взаимодейсгвис между совместимыми систе. мами. Каждый уровень зависел бы только от нижележащего уровня. По мере развития технологии любой иэ уровней можно было бы реализовать заново, не влияя при этом на другис уровни системы. На практике многоуровневый подход к архитектурному моделированию носит компромиссный характер. Если различия между компьютерными сетями слишком велики, простое взаимодействие межлу ними невозможно. Хотя функциональные характеристики каждого уровня четко определены, остаются неопределенными нефункциональные характеристики системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
