Модульная реализация программы

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

Традиционным инструментом представления модульной структуры, получаемой с помощью процедур, является структурная схема (structure chart). На такой схеме каждый модуль (процедура) изображается в виде прямоугольника, а зависимости между модулями — с помощью стрелок, соединяющих прямоугольники. Структурная схема (рис. 6.3) отображает модульную структуру заказа товаров по сети Интернет, когда покупатель заходит на веб-сайт компании для того, чтобы просмотреть каталог и разместить заказ. Схема показывает, что модуль OverseeWebSite для выполнения своей задачи использует в качестве абстрактных инструментов модули ProcessIncomingCustomer, OverseeBrowsing и ProcessOrder. Точнее, процедура OverseeWebSite вызывает процедуру Process IncomingCustomer для получения идентифицирующей информации о пользователе, посетившем сайт. Затем она вызывает процедуру OverseeBrowsing, чтобы покупатель мог просмотреть каталог и сделать заказ. Как только заказ сделан, процедура OverseeWebSite вызывает процедуру ProcessOrder, чтобы проследить за доставкой и оплатой заказа.

В то время как структурные схемы используются для представления процедурной организации программы, для изображения структуры объектно-ориентированных систем в виде классов объектов и связей между ними используется диаграмма классов (class diagrams). Простая диаграмма классов системы заказов через Интернет (рис. 6.4) показывает, что система состоит из объектов трех типов: Customer, Catalogue и OrderForm, которые связаны отношениями Currently Browsing и CurrentlyConstructing.

Суть заключается в том, что объект типа Customer содержит данные и процедуры, относящиеся к отдельному покупателю, объект типа Catalogue содержит данные и процедуры, необходимые, чтобы показать продукты компании покупателю, и объект типа OrderForm содержит данные и процедуры для учета товаров, которые заказал данный покупатель. Отношение CurrentlyBrowsing отображает связь между покупателями и каталогом. Отношение CurrentlyConstructing отображает связь между покупателем и бланком заказа. Цифры, расположенные справа от связи CurrentlyConstructing, означают, что зависимость между покупателем и бланком заказа взаимно однозначная («один к одному»). В отличие от этого, отношение CurrentlyBrowsing представляет собой зависимость типа «многие к одному», то есть одновременно несколько покупателей могут просматривать каталог. Мы вернемся к этим понятиям при обсуждении схем представления отношений между объектами (раздел 6.5).

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