Математика делает то, что можно, так, как нужно, то-гда как информатика делает то, что нужно, так, как можно

15.2. Особенности объектного подхода к разработке внешнего описания программного средства.
При объектном подходе этап внешнего описания ПС оказывается существенно более емким и содержательным по сравнению с реляционным подходом [15.3, 15.4, 15.5, 15.6].
Определение требований заключается в неформальном описании модельного мира, который пользователь собирается изучать или просто использовать с помощью требуемого ПС. При этом повышается роль прототипирования, которое при этом подходе часто окупается уменьшением объема работы на последующих этапах разработки ПС. Часто определение требование завершается разработкой диаграммы вариантов использования, в которой фиксируются, в каких случаях будет использоваться ПС. Это позволяет при разработке ПС ограничиться только такими ее функциональными возможностями, которые поддерживают эти случаи (варианты) использования. По существу, диаграмма вариантов использования представляет собой описание некоторого контекста использования (см. лекцию 4). На рис. 15.1. приведен пример диаграммы вариантов использования [15.6].
Существенно изменяется содержание процесса спецификации требований: вместо разработки функциональной спецификации ПС создается формальное описание модельного мира, состоящее из трех частей:

9. 
   объектной модели,
   
10. 
    динамической модели,
    
11. 
    функциональной модели.
    

Назначение этих частей можно образно определить следующим образом [15.3]: объектная модель определяет то, с чем что-то случается; динамическая модель определяет, когда это случается; функциональная модель определяет то, что случается.

Рис. 15.1. Диаграмма вариантов использования для банкомата.

Объектная модель показывает статическую объектную структуру модельного мира, который должно представлять разрабатываемое ПС (программная система). Она включает определения используемых классов объектов и отношений между этими классами, а также определение используемых объектов этих классов и отношения между этими объектами.
Обычно класс объектов в объектной модели представляется в виде тройки
(Имя класса, Список атрибутов, Список операций).
Каждый атрибут представляется некоторым именем и может принимать значения определенного типа. По существу, атрибут класса выражает некоторое простое свойство объектов этого класса. Представление некоторых простых свойств объектов атрибутами весьма удобно, особенно когда по значениям этих атрибутов осуществляется классификация объектов. Операции, указываемые в представлении класса, отражают другие свойства объектов этого класса (как простые, так и ассоциативные). Они показывают, что можно делать с объектами этого класса (или что могут делать сами эти объекты).
В объектной модели отношение между объектами некоторых классов обобщаются в отношения между этими классами. При этом используются, как правило, только одноместные и двуместные отношения между объектами. Более сложные отношения приводит к неоправданному усложнению объектных моделей, а с другой стороны, такие отношения всегда могут быть сведены к двуместным за счет определения дополнительных классов. Одноместные отношения называют атрибутами, причем некоторые атрибуты объекта получаются из атрибутов класса присвоением им конкретных значений. Отношение между двумя (и более) объектами называют связями, а их обобщение (отношение между классами) обычно называют ассоциациями. Ассоциации определяют допустимые связи между объектами. Различают следующие виды ассоциаций:

14. 
    взаимодействия состояний объектов,
    
15. 
    агрегирования (структурирования) объектов,
    
16. 
    абстрагирования (порождения) классов.
    

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

Рис. 15.2. Пример отношения между классами объектов.

Для представления объектной модели часто используются графические языки спецификации объектов (например, язык UML [15.5]). На таких языках классы и объекты задаются прямоугольниками, которых указывается специфицирующая их информация. Для задания отношений между двумя классами соответствующие им прямоугольники связываются линией, снабженной различными графическими значками и некоторыми надписями. Графические значки специфицируют характер (вид) отношения между этими классами, а надписи обеспечивают полную идентификацию этого отношения (делают его конкретным). Например, на рис. 15.2 заданное отношение между классами Страна и Город имеет характер «один к одному». Более конкретно это отношение означает, что каждый объект класса Страна обязательно связан отношением «имеет столицей» с одним и только одним объектом класса Город, и этот объект класса Город не связан таким отношением ни с каким другим объектом класса Страна.

Для описания декомпозиции объектов используется отношение вида агрегирования. Например, отношение «программа состоит из одного или нескольких модулей» представлено на рис. 15.3.

Рис. 15.3. Пример отношения агрегирования между классами объектов.

Следует заметить, что объектная модель полностью включает описание внешней информационной среды при реляционном подходе.