6.3 Модульность
Одна из основных мыслей, изложенных в разделе 6.2, заключалась в том, что прежде чем модифицировать программу, нужно понять ее или, по крайней мере, ее релевантную часть. Это трудно сделать даже в случае небольших программ и было бы практически невозможно в случае больших систем программного обеспечения, если бы не модульность, то есть разделение программы на более мелкие элементы, каждый из которых выполняет только часть общей задачи.
6.3.1Модульная реализация программы
Модульности можно добиться разными способами. В главах 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.