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

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

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

И вот завершающий штрих проектирования — печать отчетов о столах. Создаем новый класс Desk, он будет представлять собой сущность «стол». Чтобы ввести поддержку печати отчетов о столах, создадим интерфейс IPrintable с методом GetPrintInfo. Класс, о котором можно создать отчет, должен поддерживать этот интерфейс — мы будем использовать не наследование классов, а интерфейсы.

Класс Report теперь использует интерфейсы, а не классы, поэтому, если потребуется напечатать отчет о каком-нибудь новом классе, то будет достаточно реализовать в нем метод GetReportInfo. Дальнейшее развитие программы в твоих руках :)…

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

Обрати внимание на связи между прецедентами: они точно такие же, как и на диаграмме классов.

[на начальном этапе проектирования] было бы очень неплохо разбить программу на части (обычно это отдельные библиотеки), для чего используют диаграмму компонентов. Опять же, рассмотрим пример приложения, которое работает с сетью и с базами данных MySQL, MSSQL и Oracle. Это приложение можно разбить на компоненты так, как показано на схеме «Разделяй на компоненты и властвуй».

Организацию взаимодействия библиотек можно осуществлять через интерфейсы, что тоже отражено в диаграмме.

[диаграмма развертывания.] Также ее называют диаграммой размещения, обычно она применяется при создании распределенных систем. Спроектируем систему удаленного управления (кому-то может показаться, что это Троян) :). Программа будет состоять из двух исполняемых файлов: server.exe — для запуска на управляемом компьютере, client.exe — для запуска на управляющим компьютере. Управляемых компьютеров может быть несколько, отразим это на диаграмме:

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

[диаграмма состояний.] При построении диаграммы состояний рассматривается некий автомат, который имеет начальное, конечное и промежуточные состояния. В зависимости от событий, происходит переход из одного состояния в другое. Начальное состояние обозначается кружком, а конечное — кружком в окружности. Остальные состояния представляют собой скругленные прямоугольники с текстом. Переходы из состояния в состояние указываются при помощи стрелки. Итак, на наш сайт пришел пользователь. Необходимо реализовать поддержку регистрации посетителей на сайте. Сценарий такой (его можно записать и в виде диаграммы прецедентов): если пользователь зарегистрирован, то просто показываем ему страницу, а если иначе, то предлагаем зарегистрироваться: