Объектные модели

Объектно-ориентированная архитектурная модель структурирует систему в виде совокупности слабо связанных объектов с четко определенными интерфейсами. Объекты вызывают сервисы, предоставляемые другими объектами. На рис. 10.9 представлен пример объектно-ориентированной архитектурной модели я системы обработки счетов. Данная система выписывает счета заказчикам, получает платежи, отправляет квитанции по поступившим платежам и уведомления по неоплаченным счетам. В этом примере используется система нотации языка моделирования UML И. главу 7), в которой классы объектов имеют имена и набор атрибутов. Операции, если си есть, определяются в нижней части прямоугольника, обозначающего объект. Штри-1вые стрелки означают, что объекты используют свойства или сервисы, предоставляемыe другими объектами.

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

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

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

Модели потоков данных

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

Если преобразования представлены в виде отдельных процессов, такую модель иногда на­зывают конвейером или моделью фильтров, следуя терминологии, принятой в системе Unix. Последняя поддерживает конвейеры, которые действуют как хранилища данных, и набор ко­манд, представляющих функциональные преобразования. Здесь используется термин "фильтр", поскольку преобразование "фильтрует" данные во время обработки потока данных.

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