Дефрагментация мозга. Софтостроение изнутри
Шрифт:
Второе отступление по поводу требуемых компонентов. Собственно, TFS 2008, как выяснилось, требует для себя:
• SQL Server 2005 или выше;
• Reporting Services 2005 или выше;
• Analysis Services 2005 или выше;
• Sharepoint Services не ниже 3 SP1;
• Internet Information Server 6 или выше;
•.NET 3.5 SP1;
• ещё что-то по мелочи вроде конкретных хотфиксов.
По мере изучения сего списка я постепенно впадал в прострацию, сравнивая с ничего не требующим пакетом SVN.
Версия MS SQL Server 2005, поскольку 2008 клиентом не эксплуатируется и даже ещё не куплена. Гетерогенная сеть хоть и интегрируется с Active Directory, но не до конца: интегрированная безопасность ( integrated security ) для клиентов не работает, так как они входят в сеть под профилем NetWare. Ну, и ладно бы с этим, ведь создать регистрации на небольшую группу в TFS несложно, как и в SVN. Плохо другое, доступ с компьютера либо в Интернет с аутентификацией через прокси, либо в локальную сеть к серверам. То есть работать в режиме переключения с терминала на Интернет в браузере с обычного рабочего места нельзя, эта опция доступна только с компьютеров администраторов в отделе поддержки. В итоге все манипуляции проходят именно там в паре с сотрудниками компании.
Изначально под TFS был выделен виртуальный
Предлагаю использовать виртуальный сервер с Win 2003, чтобы избежать возможных проблем с 2005-ми версиями программ. Снова не встречаю понимания, так как скопировать образ – лениво, да и вообще надо переходить на новые технологии.
Через полтора дня ко мне обращаются за консультацией по этому поводу. Устанавливаем службу отчётов ( Reporting Service ). У 2005-й версии Reporting Services на 2008 сервере есть проблемы с Internet Information Server 7. Дополнительно устанавливаем совместимость с IIS 6. Базу данных на удалённом сервере программа установки создаёт. Танцуем с бубном вокруг создания Identity, но кроме как в Default Application Pool сервис не ставится. Танцы через несколько часов прекращаем, остаёмся в этом пуле.
Убеждаюсь что установщик TFS не находит службу аналитики ( Analysis Service ), иду читать документацию. Ребята безуспешно продолжают искать в гугле «код для прохода на следующий уровень игры». Вскоре вычитываю, что Analysis Services должны находиться на том же сервере, что и базы данных.
Служба там не установлена, так как сервер в кластере был выделен под базы данных. Ставить дополнительно Analysis Services на эксплуатационный кластер никто в здравом уме не хочет. Администратор пишет письмо Microsoft. Их поддержка изящно уходит от прямого ответа, говоря, что Analysis Services в кластере да ещё и рядом с эксплуатационной СУБД – это не вполне хорошо. Но в то же время говорит, что теоретически можно поставить и на разные серверы.
Только в официальной документации об этом не написано, нужен консультант, желательно от самого Microsoft. Вызов консультанта с предварительным утверждением бюджета – это ещё неделя простоя. Поэтому вариант отвергается.
Принято решение ставить все на один виртуальный сервер. Администраторы кисло морщат лбы, потому что кластер уже настроен под регулярные процедуры поддержки баз данных, а так они получат ещё один сервер в обслуживание, хоть и виртуальный. Но нехотя соглашаются.
Переустанавливаем на него: SQL Server, Reporting Service, Analysis Services. СУБД и все компоненты настроены и работают. Ухожу заниматься собственно делами проекта.
Вскоре у коллег начинаются новые проблемы: не ставится TFS с неким сообщением об ошибке, на которое в гугле находится всего 2 записи, и кода прохождения этого уровня занимательной игры в них нет.
Начинается переписка с экспертами по TFS уже нашей родной конторы. Находим, что вручную и строго предварительно нужно было ставить Sharepoint не ниже 3.0 Service Pack 1. Потому что под Windows 2008 Server установщик TFS этого не делает. Выясняется, что в Windows 2008 Server стандартной версии при попытке добавить роль AppServer искомые службы Sharepoint в списке отсутствуют. Надо её скачивать и устанавливать. Что и было в итоге сделано.
Чуть позже обнаружилось, что при инсталляции служб Sharepoint был выбран полный режим, что неправильно, потому что при этом установщик ставит собственный экземпляр SQL Server Express, игнорируя уже имеющийся на сервере.
Сносим службы Sharepoint, но оказывается, что созданный экземпляр SQL Server инсталлятор Sharepoint не удаляет. Ну что же, удаляем сервис руками, чистим каталоги и реестр.
Дальше работа возобновляется без моего участия, и к вечеру четверга приходит радостная весть: TFS встал, можно попытаться к нему присоединиться.
У всех пользователей похожие имена типа tfs_userNN. На моей локальной виртуальной машине есть проблема: не могу добавить файлы в репозиторий. Права у всех одинаковые. Сообщение об ошибке, связанное с « cloaked folder », также в гугле встречается редко. Ищем корень проблем в виртуальной машине (VitrualBox вместо VPC 2007), потом в виртуальном диске – проекции ( subst ) директория. Подозрения не подтверждаются. Проходит полдня, создаётся новый пользователь с аналогичными правами. Заработало, но причины так и остались неясны.
В этот момент администраторы прописывают имя нашего сервера в корпоративной DNS [123] , теперь можно отказаться от использования прямого адреса.
Первое же действие выдаёт окошко регистрации, которая проходит нормально, но все последующие операции дают ошибку 401 not authorized.
На удивлённый вопрос «Что случилось?» от администраторов приходит «письмо счастья» с прикреплённым файлом конфигурации для proxy , который надо поместить в корневой каталог локального (!) Internet Information Server, вот такая неочевидная связь. Проблема была в том, что сервер запрашивал авторизацию всякий раз, тогда как клиент TFS делает это только при первом обращении. Файл хитрым образом проблему решает.
Новая проблема, папка Documents в Visual Studio заблокирована, хотя на веб-портале проекта она видна и можно добавлять туда файлы. Ладно, это не фатальная проблема. Главное – репозиторий исходников работает. Почти как на SVN.Программная фабрика: дайте мне модель, и я сдвину Землю
Идея разрабатывать программы, минимизируя стадию кодирования на конкретных языках под заданные платформы, появилась достаточно давно. Прежде всего в связи с неудовлетворительной возможностью языков высокого уровня третьего поколения (3GL) описывать решаемые прикладные задачи в соответствующих терминах. За последнее время к этой причине добавилась ещё и поддержка независимости от целых платформ, ведь прогресс, как мы знаем, неотвратим, особенно «прогресс».
В управляемой моделями разработке [124] (УМР) и в программной фабрике [125] в частности наиболее интересной возможностью является генерация кода, скомпилировав который, можно сразу получить работающее приложение или его компоненты. Мы проектируем и сразу получаем нечто работающее, пусть даже на уровне прототипа. Уточняя модели, мы на каждом шаге имеем возможность видеть изменения в системе. Проектирование становится живым процессом без отрыва от разработки.
Историю управляемой моделями архитектуры и разработки, обобщаемой под термином УМИ – управляемой моделями инженерии [126] , можно вести с 1970-х годов. Именно тогда появились первые языки спецификации требований к программам и целые стандарты, типа упоминавшегося IDEF, включающего в себя ряд языков и нотаций. Однако реальная и доступная многим пользователям автоматизация моделирования появилась лишь вместе с персональными компьютерами. Не случайно форматы IDEF-диаграмм исторически сохранили рамки с ячейками информации, столь необходимыми при бумажной технологии анализа проектирования.
Первые инструменты CASE, выросшие из редакторов графических примитивов, были представлены в 1980-х годах, а одним из пионеров был небезызвестный Эдвард Йордон, соавтор, в компании с Томом ДеМарко, популярной методологии SADT [127] . В начале 1990-х годов наблюдалось возникновение множества языков, нотаций, подходов к анализу и проектированию и, как следствие, пик многочисленных CASE-инструментов, их реализующих.
У программистов «от сохи» отношение к CASE, как правило, негативное на уровне «я не верю, что какие-то картинки генерируют код лучше написанного руками». В таком отношении есть своя сермяжная правда, действительно, экскаватор, в отличие от мужика с лопатой, может вырыть не всякую яму. Доказывать обратное – бесполезная потеря времени.
У более продвинутых программистов, имевших опыт написания и сопровождения тысяч строк однотипного рутинного кода, претензии становятся обоснованными и касаются, как правило, следующих сторон применения CASE-средств:
• Если ручное написание кода принять за максимальную гибкость, то CASE может навязывать каркас, стиль кодирования и шаблоны генерации частей программ, ограничивающие не столько полёт фантазии программиста, сколько возможность тонкой настройки генерируемого кода. Неважно, что такая настройка не требуется в большинстве случаев, но если её нет, то менять придётся непосредственно сгенерированный код.
• CASE работает только в условиях дисциплины, когда ручные изменения генерируемого кода исключены или автоматизированы (пост-обработка). Как только программист залезает руками в код каркаса, модель оказывается рассинхронизированной по отношению к исходным текстам программ и процесс разваливается.
В качестве решения перечисленных проблем появились так называемые двусторонние CASE-инструменты ( two way tools ), позволяющие редактировать как модель, непосредственно видя изменения в коде, так и, наоборот, менять код с полу– или полностью автоматической синхронизацией модели. Зачастую, такой инструмент был интегрирован прямо в среду разработки.
Рис. 17. Двусторонний CASE-инструментарий ModelMaker имеет возможности работы как с моделями, так и непосредственно с кодом приложения
Нетрудно заметить, что двунаправленный подход в CASE-инструментарии в большей степени является мощным средством автоматизации отдельных программистов, так как обладает рядом ограничений:
• как правило, инструмент привязан к языкам и платформам;
• технология не выходит за рамки разработки конкретных программ и подсистем. То есть слои системы и архитектура остаются за рамками процесса;
• коллективная работа над моделями одновременно с кодом практически невозможна: приходится делить модели на независимые части, например подсистемы, разрабатываемые одним программистом;
• для достижения нужного эффекта методика по-прежнему требует навыков моделирования как минимум на уровне диаграммы классов. В противном случае CASE оказывается лишь очередным инструментов рефакторинга.Следующим шагом в развитии автоматизированных средств софтостроения явилась программная фабрика – синтез подходов управляемой моделями разработки и архитектуры, генерирующий не только отдельные компоненты системы, но целые слои в соответствии с выбранной архитектурой и платформами. На рынке уже имеется немало продуктов типа « software factory », если вы наберёте в поисковике эти ключевые слова, то получите множество ссылок на концепции и частные реализации. Например, неплохое руководство, хотя и привязанное к собственным средствам, составили в IBM[24]. Чтобы не утомлять вас текстами академического характера, в следующей главе я просто приведу пример одной фабрики под названием Genie Lamp sourceforge.net), применяемой непосредственно в различных моих проектах. Несмотря на то что подход УМР я использую с конца 1990-х годов, свести многие частные решения в несколько более общее удалось только за последние 2–3 года. Лень – двигатель прогресса, особенно когда надоедает переписывать генераторы кода и подстраивать относительно стандартные модели под частные требования.
Лампа, полная джиннов
Метафора системы достаточно проста: хочешь генерировать код компонента или слоя – попроси об этом соответствующего «джинна» в форме стандартного «заклинания». Джинны, как им и положено, живут в лампе.
Переходя к техническим терминам, программист описывает задачу в терминах логической модели, представляющей собой набор сущностей, их атрибутов, операций и связей между ними. Язык создан на основе XML, поэтому делать описания можно непосредственно руками в обычном текстовом редакторе.
Рис. 19. Общая схема работы с «лампой» и «джиннами»
Модель в виде XML-файлов поступает на вход «заклинателю» – входящей в состав пакета консольной утилите. Производятся проверки непротиворечивости модели, выдающие ошибки либо предупреждения разной степени важности. Во время анализа модель также преобразуется во внутренний формат в виде множества объектов с открытыми интерфейсами доступа.
Если модель корректна, «заклинатель» начинает призывать «джиннов» сделать свою работу, передавая каждому на вход кроме самой модели ещё и разнообразные параметры, конфигурацию, касающуюся не только самих джиннов, но и, например, таких настроек, как правила именования в конкретном слое системы.
Обработав модель в соответствии с конфигурацией проекта, джинн выдаёт готовый к компиляции в среде разработки код. Для слоя хранения данных кроме генерации специфичных для СУБД SQL-скриптов производится их прогон на заданном сервере разработки.
В случаях, когда система уже существует и подлежит, например, переделке, можно восстановить модель из схемы базы данных. Конечно, даже теоретически такое восстановление не может быть полным из-за разницы в семантике, но большую часть рутинной работы оно выполняет. Проведя один раз импорт, далее мы редактируем, структурируем модели и продолжаем работать только в обычном цикле изменений «через модель».
На что похожа логическая модель? Приведу пример описания из рабочего проекта, содержащего один пользовательский тип, один перечисляемый тип, две сущности и одну связь (отношение) между ними.