программирование на доске почета

БОРИС ВОЛЬФСОН

Спецвыпуск: Хакер, номер #065, стр. 065-056-3

[посмотрим на диаграммы,] которые используются чаще всего. Полный список диаграмм и их описание можно посмотреть на врезке. Чаще всего при создании объектно-ориентированных систем используется диаграмма классов. Довольно часто этот вид диаграмм путают с самим языком UML, хотя он гораздо шире. На таких диаграммах с той или иной степенью детализации изображаются классы, интерфейсы (иногда кооперации) и отношения между ними, то есть фактически строится объектно-ориентированная модель. Частое использование этих диаграмм также обусловлено тем, что большинство инструментов UML умеют создавать код по диаграммам классов. Другими словами, работа будет происходить в два этапа: на первом происходит создание диаграмм и кода по ним, на втором — реализация методов классов. Самые продвинутые инструменты UML умеют создавать диаграммы классов по готовому коду, такой процесс называется обратным проектированием, или реинженерингом. Его применяют в тех случаях, когда необходимо разобраться в написанном исходном коде программы: рассмотреть диаграмму с парой десятков классов проще, чем разбираться в тысячах строчек кода. На простом примере посмотрим, как строятся такие диаграммы.

Допустим, от нас потребовали написать программу, которая печатает некие отчеты о студентах. Мы спроектируем (хотя это громко сказано) ядро программы. Обычно проектирование начинается с составления словаря предметной области, в котором существуют два понятия: студент и отчет. Студент — это человек с именем и фамилией, датой рождения, факультетом, специальностью, группой и т.д. Отчет — это некая информация, представленная в бумажной форме, о студенте или студентах. Данные две сущности являются прямыми кандидатами в классы, причем класс Report (отчет) будет зависеть от класса Student (студент):

Если в отчетах, кроме фамилии и имени, необходимо печатать, скажем, и возраст студента на данный момент, то он должен вычисляться самим классом Student по текущему дню рождения студента. Для печати класс отчетов будет использовать метод Print, а сама распечатка будет происходить через подсистему печати. Данные о студентах будем брать из базы данных при помощи специальных классов. Теперь диаграммы выглядят так, как показано на схеме «Уточненная диаграмма классов».

Дальше можно уточнять подсистемы и довести программу до логического конца. Однако в мире есть три неизбежные вещи: смерть, налоги и изменение требований к программе. Наш заказчик говорит, что теперь необходимо поддерживать печать отчетов не только о студентах, но и о преподавателях. Вот и введем новый класс Professor и выясним, в каких отношениях с другими классами он состоит. Очевидно, что от него зависит класс Report, а с классом Student у него находится что-то общее. Действительно, и студенты, и преподаватели суть люди :). Создаем общий абстрактный класс с методом GetPrintInfo, который будет возвращать информацию для печати: по студентам — размер стипендии (или возраст, или номер группы), по преподавателям — размер зарплаты (схема «У преподавателей и студентов есть что-то общее» :)).