Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Обзор инструментов SEO-оптимизатора и методов продвижения" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
| ← Ноябрь 2005 → | ||||||
|
1
|
3
|
4
|
5
|
6
|
||
|---|---|---|---|---|---|---|
|
7
|
8
|
9
|
10
|
11
|
12
|
13
|
|
14
|
15
|
16
|
17
|
18
|
19
|
20
|
|
22
|
23
|
24
|
25
|
26
|
27
|
|
|
28
|
29
|
30
|
||||
Статистика
0 за неделю
Архитектор и Святой Грааль ...
| Информационный Канал Subscribe.Ru |
|
"Но вот очутилась в зале священная чаша Грааль под белым парчовым покровом, однако никому не дано было видеть ее Выпуск девятый. Архитектор и Святой Грааль ...
Доброй ночи! В названии не напрасно упоминается Святой Грааль. Если вы помните, он явился рыцарям Круглого Стола в Камелоте в день Пятидесятницы. Никто не смог увидеть его, но рыцари твердо решили разыскать Грааль, не жалея "целый год и один день и даже больше, если будет в том нужда". И расходятся они, каждый своим путем. С тех пор Грааль искали многие, но никому так и не было суждено увидеть его вновь. И даже когда наидостойнейшому и наичистейшему Галахаду удалось найти Святой Грааль, он навеки покинул нашу грешную юдоль вместе со священным сосудом. Конечно, я не хочу сказать, что ситуация с проектированием и генерацией кода на основании UML диаграмм напоминает мне эту историю, но ... "используете ли вы Rational Rose и UML в разработках?" - этот вопрос знаком любому опытному разработчику, проходившему собеседования. И правильным ответом всегда было "да". В английском языке, есть такая идиома "They say ..." ("Говорят, что ..."). Кто именно говорит? Да все - they. They say, что решения нужно проектировать при помощи UML диаграмм. They say, что теоретически по этим диаграммам должен генерироваться каркас программы и основные конструктивные изменения должны вноситься именно в диаграммы - они первичны по отношению к коду. They say, что диаграммы должны постоянно актуализироваться в процессе разработки приложения. Пока дело касалось ключевых моментов, иллюстрированных при помощи UML диаграмм, разработчики чуствовали себя уверенно. Действительно, это удобное средство для описания вашего решения, диаграммами классов можно описать ключевые концепции приложения, диаграммами последовательностей (sequence) и диаграммами состояний - логику программы. А вот чуть дальше - выходила заминка. Попытка описать хотя бы большую часть классов и сценариев в виде диаграмм (а в идеале - всю, ведь потом по диаграммам теоретически нужно сгенерировать код) приводила к таким затратам времени, что окончание обычно было одно - разработчики гордо показывали уже созданные диаграммы заказчику\менеджеру проекта\шефу ... и открывали Visual Studio, с головой окунаясь в программирование. "Вот это диаграммы классов проекта, правда они создавались давно, так что заглядывать сюда лучше не стоит" - еще одна фраза из набора ну очень знакомых. К диаграммам возращались как правило уже в конце разработки, когда начальство требовало как следует задокументировать весь проект. Почему происходило именно так? Основной причиной пожалуй был слишком высокий уровень абстракции и универсальность, заложенные в UML. По идее, он позволял описывать проект без привязки к какой-либо среде разработки, а потом, используя необходимый plug-in, сгенерировать проект на нужном нам языке программирования. Но "Вещи, годящиеся для многого, вряд ли смогут делать хорошо что-то одно". Да, UML отлично позволить описать диаграммой классов классический пример: объект "Зоопарк" агрегирует какое-то количество объектов, унаследованных от базового класса "Животные". Это могут быть как "Птицы", так и "Звери". Унаследованный от класса "Животные" класс "Птицы" имеет уникальный метод "Fly" и переменную-член класса "Wings" и т.д. Но если нам нужна более приземленная задача, например описать процесс формирования UI формы на основании XML описания - мы задумаемся, а стоит ли тратить на это время. К тому же нет, ну вот нет и все, в UML понятий, соответствующих многим ключевым словам современных языков, например типу доступа friend или диапазону видимости internal. Так что же все таки предлагает Архитекторам Visual Studio? Она включает в себя специальный DSL (Domain Specific Language) язык для работы с диаграммами, а так же соответствующие визуальные средства. Когда в предыдущих выпусках вы разучивали заклинания Архитекторов - вы неявно использовали именно этот язык. Именно на нем были описаны созданные вами Datacenter, Application, System и Deploy диаграммы. Кроме того, Visual Studio поддерживает еще один тип - Class Diagramm, о которых мы поговорим чуть ниже. Значит ли это, что Microsoft отказалась от UML и начала создавать свой язык описания? Вовсе нет. Просто она предлагает использовать каждый инструмент только там, где он действительно приносит явную пользу, а именно:
Используйте UML. Специально для этого, вместе с Visual Studio 2005 Team System поставляется Visio for Enterprise Architects, которое является отличным средством для построения UML диаграмм и поддерживает спецификацию UML версии 1.3. А применив заклятие "Reverce engineering" (опция главного меню "Project -> Visio UML -> Reverce engineering"), вы создадите UML class diagrams для всех классов вашего проекта. Если же вам нужны диаграммы, отображающие непосредственно код и инфраструктуру вашего приложения, диаграммы, которые не нужно будет постоянно обновлять вслед за меняющимся кодом, диаграммы, соответствующие конкретным абстракциям и реальным объектам - вы можете воспользоваться DSL и мощной поддержкой визуальных дизайнеров Visual Studio. Итак, еще одно заклинание Архитекторов - "Class Diagram". Его использование приводит к созданию диаграмм, аналогичных диаграммам классов в UML. Кирпичиками для таких диаграмм являются классы, перечисления, интерфейсы, структуры и отношения между ними. Компоненты диаграмм не являются описаниями классов вашей программы - это и есть эти классы. Иначе говоря, прямоугольник "Class" на диаграмме и исходный код "public class Program { ...." являются двумя представлениями одной и той же сущности - класса Program. Вот почему нет необходимости синхронизировать диаграммы с кодом, когда вы меняете диаграмму - на самом деле вы уже меняете код приложения, а диаграмма по сути содержит лишь ссылки на классы, которые она должна показать, плюс некоторые параметры, определяющие, как отображать те или иные компоненты диаграмм (например показывать или нет связи типа "ассоциация"). На рисунке 1 приведен пример диаграммы классов. Вы можете поместить новый элемент на диаграмму, выбрав его на панели Toolbox (там мы можем увидеть весь набор доступных нам элементов и типов связей) или перетащить существующий элемент с панели Solution Explorer. При помощи панелей Properties и Class Detail вы можете уточнять описания объектов, а так же задавать их свойства, методы, события, вплоть до указания описания, которое будет помещено в тег <summary> (самое нижнее поле панели Properties). То есть все, что вы можете описать в редакторе кода, вы можете задать и в этом визуальном дизайнере (конечно, за исключением кода, представляющего собой реализацию методов или свойств).
Перед завершением темы Архитекторов я приведу несколько полезных ссылок, описывающих их возможности и среду окружения:
Software Architects
- домашняя страница Архитекторов на сайте Team System. Большое вам спасибо за ваши письма. Кроме того что их просто приятно читать :), я стараюсь корректировать свои выпуски в соответствии с высказываемыми в них пожеланиями. Так, например, пора вспомнить, что эта рассылка посвящена не только архитекторам, но и другим участникам команды разработчиков. Кроме того, чистая теория - описание возможностей новой Visual Studio - не единственная интересная тема о программировании. Поэтому в ближайших выпусках мы вернемся к программированию, разобрав такой элемент инфраструктуры приложений как работа с источниками данных, а потом закрепим все это на практике, реализовав наш пример, рассматриваемый в выпусках начиная с 6-го. В результате, мы получим решение, состоящее из нескольких компонент (windows client, web service, database) и содержащее необходимую инфраструктуру для обработки ошибок и работы с данными. Такое решение послужит хорошим прототипом для большинства типичных приложений, с которыми обычно приходится сталкиваться. Так что еще раз спасибо, пишите мне на адрес comp.soft.prog.prgnotes-owner@subscribe.ru И, одна новость, не имеющего прямого отношения к сегодняшней теме. Сервер онлайнового тестирования Brainbench в рамках подготовки к играм Brainbench 2006 открыл бесплатный доступ более чем к 500 своих тестов на период с 1 по 15 ноября 2005 года. Учитывая, что обычно сдача экзамена стоит $49 (месячный unlimited порядка $100) - это хороший повод посетить сайт именно в эти две недели :)
Удачи и приятной работы! |
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.prog.prgnotes Архив рассылки |
Отписаться
Вспомнить пароль |
| В избранное | ||
