Очередной веб лог…

Вот прошла неделя и с небольшой задержкой, вызванной отсутствием времени, выкладываю результаты первой итерации.
Что сделано:

• Описаны прецеденты на эту итерацию
• Реализованы диаграммы классов и последовательностей
• Создана базовая файловая архитектура
• Реализованы задачи
• Сделаны некоторые открытия в области ООА/ООП

Но обо всем по порядку

Осторожно - много текста!!!

Описание прецедентов

Собственно задача “описать требования прецедентов” является самой сложной и самой важной в рамках проектирования системы. Нередко допущенные на этой стадии ошибки приводят к плачевным результатам и затягивают сроки из-за изменения требований.

Прецедент - это некоторая история, написанная для участников (actors) системы. Прецедент описывает пути достижения целей, а так же рассматривает все альтернативные сценарии развития - будь то ошибки по вине участников, различное поведение в зависимости от некоторых факторов или банальные ошибки в функционировании ПО.

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

Вначале перечисляются участники. Это могут быть как различные пользователи (администраторы, покупатели, менеджеры), так и сама система. Если прецедент не сложный, а участников не более двух-трех, то опустить эту часть можно, так как роли будут легко восприниматься из контекста описания.

Вторая важная часть - предусловия. Некоторые состояния и события всей системы, которые должны быть выполнены, что бы прецедент мог выполняться. В нашем случае, при рассмотрении обоих выбранных прецедентов предусловиями является авторизованность пользователя в системе.

Следующим в списке является описание триггера - события, которое инициирует начало выполнения сценария. Если рассматривать прецедент “создание счета”, то описать триггер можно как “Пользователь находится на странице Счета::новый”, либо “Пользователь переходит на страницу Счета::новый”.

Далее мы описываем успешный сценарий - последовательность действий, которые приводят к достижению поставленных целей. Необходимо выбрать уровень детализации таким образом, что бы сценарий был информативным и не выглядел глупым. Таким образом заранее стоит отбросить попытки создать описаняи вида:

1. Пользователь нажал на кнопку “добавить”
2. Система добавила счет пользователю

Такое описание не дает нам дополнительного объяснения как достигалась цель и, соответственно, не несет никакой пользы. Вторая крайность - слишком детальное описание сценария:

1. Пользователь открыл страницу Счета::новый
2. Пользователь указал название
3. Пользователь указал тип валюты
4. Пользователь указал остаток на счете
5. Пользователь навел указатель мыши на кнопку “отправить”
6. Пользователь нажал на кнопку “отправить”
7. Система получила запрос с данными
8. Система нашла необходимый контроллер
9. …

Нет. Такое решение нам тоже не подходит, так как оно отвлекает от основной идеи и только запутывает в поиске правильного пути. Да и для детального описания какой-либо части мы можем использовать перекрестные ссылки, не отвлекаясь атким образом на детяли в настоящее время.

После описания основного сценария, следует задуматься о сценариях альтернативных. Для их описания необходимо рассмотреть каждый пункт основного сценария и найти в них возможные пути ветвления. Начинать альтернативный сценарий стоит с цифро-буквенного кода, который указывает на пункт основного сценария, для которого пишем альтернативный, а так же позволяет создавать несколько альтернативных сценариев для одного основного пункта. Так код “4a” подразумевает, что это первое ветвление для шага номер 4 в основном сценарии, а код “4б”, говорит о том, что это второй вариант исхода событий. Альтернативные сценарии могут так же начинаться со звездочик “*” - это будет означать, что такой ход событий может возникнуть в любом месте основного сценария. Надеюсь объяснил понятно, хоть и запутанно

Далее дополняем описание постусловиями - тем, что должно быть достигнуто в случае удачного исхода событий, к чему нам надо стремиться при реализации.

Другими возможными деталями описания могут быть “Специальные условия” (перечисление возможных специфических требований) и некоторые другие дополнения.

Диаграммы

Как только с описанием закончили, стоит его перечитать и, возможно, дополнить или… переписать заново Не стоит забывать что описания - основная наша цель! и уже потом - все остальное: диаграммы, код, структура баз данных.

Когда же описание подогнано под необходимый уровень детализации и содержит все необходимые нам сведения, стоит рассмотреть аспекты, которые могут быть непонятными. Очень тяжело в описании продемонстрировать связи различных объектов и участников системы, поэтому часто стоит построить диаграммы классов.

Диаграмма классов

Диаграмма классов - статическая диаграмма, иллюстрирующая связи между объектами, архитектурные решения, акцентирующая внимание на свойствах и методах объектов. Это первый шаг к реализации системы.

Посмотрим на пример для нашего прецедента “создание счета”. Даже без знания UML можно понять эту диаграмму: вот есть некий Пользователь (User), у пользователя может быть от 0 до бесконечности Счетов (Account), каждый счет может принадлежать к какому-то типу (кредит, займ, кредитная карта, наличные, депозит) и каждый из них имеет методы save() и getPropertiesForm(). Диаграмма вроде бы понятна. О том, где мы взяли методы еще поговорим, а пока рассмотрим что обозначают непонятные символы на диаграмме.

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

Прямая с пустой стрелочкой - обобщение (уточнение). Указывает на то, что класс, на который указывает стрелочка более общий, а другой класс - более конкретный. Такую же прямую с пустой стрелочкой можно провести от “мыши” или “трекбола” к “манипулятору” - мышь и трекбол - более конкретные классы по отношению к манипулятору.

Диаграмма последовательностей

Второй тип даиграммы, который стоит рассмотреть - диаграмма последовательностей. Этот тип диаграмм используется для демонстрациивзаимодействия между классами/объектами/участниками системы.

Диаграмма последовательностей близка к описанию конкретных методов классов.

Что может поведать наша диаграмма? Во-первых следует помнить, что диаграмма читается сверху вниз, если не указан иной порядок (обычно указывается цифрами возмле вызовов методов). Прямоугольные желтые области - классы, либо экземпляры классов, либо участники системы, а вертикальные пунктирные линии, отходящие от них - линии “жизни”. Каждая стрелка - обращение к методу класса, на который она указывает. Так самое первое действие можно прочитать так: Пользователь (заметьте, что не класс, а участник) вызывает метод newAction() класса AccountsController (тоесть AccountsController обладает методом newAction ). Таким описанием мы подразумеваем, что вызов из браузера некоей страницы, приведет к обращению к данному методу данного контроллера. Этот пример очень приближен к нашей области применения, так как архитектура будет построена на ZF с использованием подхода ZendMVC.

Так же стоит учитывать, что не все указания на диаграмме стоит воспринимать буквально. Так довольно часто можно встретить вызовы методов new() или create(), но они зачастую означают инстанциирование экземпляров классов и последующий вызов конструкторов.

Пунктирные линии с надписями “rendered content” - это указание на возвращение к инициатору событий, а в нашем случае означает рендеринг страницы в браузере пользователя.

Думаю что прочитать диаграмму вам стоит самостоятельно, а если возникнт вопросы - обсудим их в коментариях

З.Ы. Кстати если интересно почему какой-то конкретный класс порождает другие классы, то пишите в коментарии или на почту и я все объясню более детально.

Базовая файловая архитектура

В репозитории проекта уже можно забрать некоторое кол-во кода, на основании проектного решения. А если проследить историю изменений, то можно найти десятую ревизию с комментарием: “созданы основные файлы/каталоги и проведена базовая настройка окружения”. Что же было проделано на этом этапе? На этом этапе были созданы предусловия для использования ZendMVC: создан .htaccess с необходимыми правилами mod_rewrite, создана точка входа по шаблону FrontController (index.php); был создан файл первичной конфигурации config.ini-sample (который используется как шаблон для файла config.ini, который добавлен в список исключений (svn:ignore в значение “*.ini”) для каталога includes/, что бы мы могли сделать настройки специфическими для каждого из серверов разработки). Так же был создан файл вторичной конфигурации на основе config.ini - bootstrap.php. Он создает необходимые для работы ресурсы, настраивает переменные окружения и подготавливает для работы необходимые классы. К нему же подключены файлы constants.php и functions.php, которые, соответствуя своим названиям, содержат общесистемные константы и некоторый набор функций соответственно. Последними шагами было создание контроллера IndexController с дейтсвием indexAction и соответствующего ему представлению scripts/index/index.phtml. Это все, что необходимо для первого запуска нашего приложения в браузере.

Другим, заслуживающим отдельного абзаца моментом, является подключение внешних библиотек: Doctrine и ZendFramework. Можно было бы конечно их скачать архивчиком и расположить в созданной для них папочке libs/, но я как любитель всего самого свежего и свежепоправленного, то эти библиотеки мы подключаем таким образом, что бы они всегда были в актуальном состоянии. Благо SVN предоставляет такую возможность на базовом уровне - это совйство “svn:externals”, указав такое свойство через svn propset мы добъемся того, что в наш проект будет подтягиваться последняя версия из SVN’ов Doctrine и ZendFramework. Но с плюсами от работы с последней версией, не стоит забывать и о том, что иногда недобросовестные разработчики могут закоммитить некошерный код - и тогда бывает бяка…

Реализация проектного решения

Следуюший шаг - написание кода. Если честно, то его можно сгенерировать из наших диаграмм (BOUML хорошо с этим справляется), но из-за того, что мы будем использовать внешние фреймворк и ОРМ, то такой надобности я не нахожу и код пишу весь с ноля, стараясь не заыбвать о комментировании

Если вы сделаете себе checkout проекта и заглянете в можели и контроллеры, то обнаружите, что единственным отклонением от нарисованных диаграмм ялвляется описание геттеров и сеттеров (get*, set* методы), а так же специфические вещи типа инстанциирование журналов (logs), описание структуры БД в моделях (требование Dcotrine ORM) и прочие несущественные мелочи, которые понятны из контекста. Все же остальное полностью следует предоставленным диаграммам и выполняет сценарии описанные в прецедентах.

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

Кстита для того, что бы запустить пример, необходимо всего несколько действий:

• Сделать checkout проекта
• Скопировать файл config.ini-sample в config.ini
• Отредактировать config.ini
• Проверить права на каталог /logs (php cli и apache должны уметь в него писать)
• Запустить файл /scripts/setup.php

Все. Создание БД и таблиц пройдет в автоматическом режиме, а проект будет доступен из браузера как только вы создадите в Apache новый VirtualHost, указывающий своим DocumentRoot на каталог html.

Заключительная часть

Заключительным шагом итерации является определение требований на следующую итерацию. Руководствуемся теми же принципами что и раньше - выбираем либо самую сложную, либо самую подверженную изменениям часть системы, либо часть, которая тесно связана с уже реализованными частями. В данном случае считаю что таковой может быть прецедент “создание чека” - им и займемся на этой неделе

ПыСы

Пока готовил свои первые в жизни реальные диаграммы, многое показалось сложным, так как сильно отличалось от теории, посему приходилось обращаться в гугл за помощью. Но, хочу заметить, что просидев около 4х часов для моделирования первых диаграмм, на все последующие трачу не более 5-7 минут.

А еще в дебрях интернета я наткнулся на отличный ресурс uml2, который в формате форума может помочь решить множество вопросов для начинающих в области ООА/ООП.

This entry was posted on Понедельник, Ноябрь 3rd, 2008 at 20:32 and is filed under Проект hMoney по шагам. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.