Visual Studio 2010 Ultimate предоставляет достаточно удобные возможности для реверс-инжиниринга. С помощью средств Visual Studio мы можем на основе существующего кода построить UML-модель и понять как у нас, собственно, все работает, но при этом не прилагать гигантские усилия по созданию диаграмм вручную и поддержанию их в актуальном состоянии.
Все бы хорошо, но у данного инструмента напрочь отсутствует возможность синхронизации модель с кодом. Т.е., после изменения модели, нам приходится вручную изменять классы. В случае большого количества мелких изменений, получается довольно неудобно, и по этой причине от полноценного моделирования частенько отказываются.
Недавно Microsoft выпустила дополнение под названием Microsoft Visual Studio 2010 Feature Pack 2. Данный инструмент дает нам прекрасную возможность синхронизировать изменения модели в код. Вкратце расскажу, как это можно использовать.
Для примера допустим, что у нас есть примитивный блог. Предметная область представлена двумя классами: Author и Article. Добавляем в солюшн новый Modeling Project. В нем создаем UML Class Diagram.
Воспользуемся возможностями Reverse Engineering. Перетаскиваем классы из Architecture Explorer-а на диаграмму. При этом на диаграмме сущность появляются вместе с атрибутами. Периодически между сущностями образуются связи, которые должны быть (и даже периодически правильно показывается тип связи), но в каких случаях – определить пока не получилось.
Как нам всем известно, стандарт UML 2.0 определяет четыре стандартных типа данных: Boolean, Integer, String и UnlimitedNatural. Остальные типы автоматически создаются в пакетах в соответствии с расположением в пространствах имен.NET.
Итак, попытаемся «починить» модель до адекватного состояния, а заодно, немного расширим ее. Для этого, создаем на диаграмме новый класс, в UML Model Explorer-е перетаскиваем его в нужный Package и выбираем стереотип C# Class (Microsoft добавила несколько специфичных для.NET стереотипов, которые используются при кодогенерации).
Заметьте, данный класс еще не присутствует в сборке Domain. Для того чтобы прописать его туда, а заодно применить все наши изменения, нужно сделать следующее.
В Model Explorer выбираем сборку Domain, идем в Properties и в пункте Text Template Binding тыкаем кнопочку «…». Добавляем новый элемент, в поле Project Path указываем имя проекта, в который будет генерироваться код, в поле Target Directory указываем папочку относительно проекта (мы генерим в корень) и указываем адрес шаблона. По умолчанию они находятся в папке «C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Visualization and Modeling Feature Pack\2.0\Templates\Text». Можно задать несколько шаблонов на все случаи жизни. В нашем случае, выбираем ClassTemplate.t4.
После этого, нажимаем правой кнопочкой мыши в свободное место диаграммы и выбираем пункт Generate Code.
И – вуаля! Новый класс добавлен в сборку, все изменения применены в соответствии с моделью.
Кстати говоря, с помощью стереотипов имеется возможность указывать практически все: видимость членов, атрибуты, подключаемые при генерации пространства имен и пр.
Итак, M$ предлагает нам прекрасный инструмент, серьезно облегчающий жизнь архитекторам и разработчикам. К сожалению, этот очень необходимый пакет доступен только подписчикам MSDN, и компания почему-то не позволяет использовать его всем желающим легальным пользователям. И это при стоимости VS Ultimate порядка 300 тыс. рублей. Будем надеяться, что в ближайшем будущем такое положение вещей изменится.
Аннотация: Предметом этого курса является The UML - унифицированный язык моделирования. В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML - это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм
Прежде чем перейти к обсуждению основного материала этой лекции, давайте поговорим о том, зачем вообще строить какие-то диаграммы. Разработка модели любой системы (не только программной) всегда предшествует ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри команды разработчиков, и для взаимопонимания с заказчиком. В конце концов, это позволяет убедиться в "архитектурной согласованности" проекта до того, как он будет реализован в коде.
Мы строим модели сложных систем, потому что не можем описать их полностью, "окинуть одним взглядом". Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой "стандартной" технологии используется унифицированный язык моделирования ( Unified Modeling Language , UML ), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML -модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм.
Примечание . Мы рассмотрим не все, а лишь некоторые из видов диаграмм. Например, диаграмма компонентов не рассматривается в этой лекции, которая является лишь кратким обзором видов диаграмм. Количество типов диаграмм для конкретной модели приложения никак не ограничивается. Для простых приложений нет необходимости строить диаграммы всех без исключения типов. Некоторые из них могут просто отсутствовать, и этот факт не будет считаться ошибкой. Важно понимать, что наличие диаграмм определенного вида зависит от специфики конкретного проекта. Информацию о других (не рассмотренных здесь) видах диаграмм можно найти в стандарте UML.
Почему нужно несколько видов диаграмм
Для начала определимся с терминологией. В предисловии к этой лекции мы неоднократно использовали понятия системы, модели и диаграммы. Автор уверен, что каждый из нас интуитивно понимает смысл этих понятий, но, чтобы внести полную ясность , снова заглянем в глоссарий и прочтем следующее:
Система - совокупность взаимосвязанных управляемых подсистем, объединенных общей целью функционирования.
Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам:
Системой называют набор подсистем, организованных для достижения определенной цели и описываемых с помощью совокупности моделей, возможно, с различных точек зрения.
Что ж, ничего не попишешь, придется искать определение подсистемы. Там же сказано, что подсистема - это совокупность элементов, часть из которых задает спецификацию поведения других элементов. Ян Соммервилл объясняет это понятие таким образом:
Подсистема - это система, функционирование которой не зависит от сервисов других подсистем. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами.
Тоже не слишком понятно, но уже лучше. Говоря "человеческим" языком, система представляется в виде набора более простых сущностей, которые относительно самодостаточны. Это можно сравнить с тем, как в процессе разработки программы мы строим графический интерфейс из стандартных "кубиков" - визуальных компонентов, или как сам текст программы тоже разбивается на модули, которые содержат подпрограммы, объединенные по функциональному признаку, и их можно использовать повторно, в следующих программах.
С понятием системы разобрались. В процессе проектирования система рассматривается с разных точек зрения с помощью моделей, различные представления которых предстают в форме диаграмм. Опять-таки у читателя могут возникнуть вопросы о смысле понятий модели и диаграммы . Думаем, красивое, но не слишком понятное определение модели как семантически замкнутой абстракции системы вряд ли прояснит ситуацию, поэтому попробуем объяснить "своими словами".
Модель - это некий (материальный или нет) объект , отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные - материальные и нематериальные, искусственные и естественные, декоративные и математические...
Приведем несколько примеров. Знакомые всем нам пластмассовые игрушечные автомобильчики, которыми мы с таким азартом играли в детстве, это не что иное, как материальная искусственная декоративная модель реального автомобиля. Конечно, в таком "авто" нет двигателя, мы не заполняем его бак бензином, в нем не работает (более того, вообще отсутствует) коробка передач, но как модель эта игрушка свои функции вполне выполняет: она дает ребенку представление об автомобиле, поскольку отображает его характерные черты - наличие четырех колес, кузова, дверей, окон, способность ехать и т. д.
В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека.
Уравнение, изображенное выше - тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести.
Осталось лишь сказать, что такое диаграмма . Диаграмма - это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема , и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree , и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст...
Но вернемся к проектированию ПО (и не только). В этой отрасли с помощью диаграмм можно визуализировать систему с различных точек зрения . Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая - изменение состояний системы в процессе ее работы, третья - взаимодействие между собой элементов системы и т. д. Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей-диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции . Другими словами, каждая модель соответствует некоторой определенной, частной точке зрения на проектируемую систему.
Несмотря на то что в предыдущем абзаце мы весьма вольготно обошлись с понятием модели, следует понимать, что в контексте приведенных выше определений ни одна отдельная диаграмма не является моделью . Диаграммы - лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма , вырванная из контекста.
Виды диаграмм
UML 1.5 определял двенадцать типов диаграмм , разделенных на три группы:
- четыре типа диаграмм представляют статическую структуру приложения;
- пять представляют поведенческие аспекты системы;
- три представляют физические аспекты функционирования системы (диаграммы реализации).
Текущая версия UML 2.1 внесла не слишком много изменений. Диаграммы слегка изменились внешне (появились фреймы и другие визуальные улучшения), немного усовершенствовалась нотация , некоторые диаграммы получили новые наименования.
Впрочем, точное число канонических диаграмм для нас абсолютно неважно, так как мы рассмотрим не все из них, а лишь некоторые - по той причине, что количество типов диаграмм для конкретной модели конкретного приложения не является строго фиксированным. Для простых приложений нет необходимости строить все без исключения диаграммы. Например, для локального приложения не обязательно строить диаграмму развертывания. Важно понимать, что перечень диаграмм зависит от специфики разрабатываемого проекта и определяется самим разработчиком. Если же любопытный читатель все-таки пожелает узнать обо всех диаграммах UML , мы отошлем его к стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Напомним, что цель этого курса - не описать абсолютно все возможности UML , а лишь познакомить с этим языком, дать первоначальное представление об этой технологии.
Итак, мы кратко рассмотрим такие виды диаграмм, как:
- диаграмма прецедентов ;
- диаграмма классов;
- диаграмма объектов ;
- диаграмма последовательностей;
- диаграмма взаимодействия;
- диаграмма состояний;
- диаграмма активности ;
- диаграмма развертывания .
О некоторых из этих диаграмм мы будем говорить подробнее в следующих лекциях. Пока же мы не станем заострять внимание на подробностях, а зададимся целью научить читателя хотя бы визуально различать виды диаграмм, дать начальное представление о назначении основных видов диаграмм. Итак, начнем.
Диаграмма прецедентов (use case diagram)
Любые (в том числе и программные) системы проектируются с учетом того, что в процессе своей работы они будут использоваться людьми и/или взаимодействовать с другими системами. Сущности, с которыми взаимодействует система в процессе своей работы, называются экторами , причем каждый эктор ожидает, что система будет вести себя строго определенным, предсказуемым образом. Попробуем дать более строгое определение эктора. Для этого воспользуемся замечательным визуальным словарем по UML Zicom Mentor :
Эктор (actor) - это множество логически связанных ролей, исполняемых при взаимодействии с прецедентами или сущностями (система, подсистема или класс). Эктором может быть человек или другая система, подсистема или класс, которые представляют нечто вне сущности.
Графически эктор изображается либо " человечком ", подобным тем, которые мы рисовали в детстве, изображая членов своей семьи, либо символом класса с соответствующим стереотипом , как показано на рисунке. Обе формы представления имеют один и тот же смысл и могут использоваться в диаграммах. "Стереотипированная" форма чаще применяется для представления системных экторов или в случаях, когда эктор имеет свойства и их нужно отобразить (рис. 2.1).
Внимательный читатель сразу же может задать вопрос: а почему эктор, а не актер ? Согласны, слово "эктор" немного режет слух русского человека. Причина же, почему мы говорим именно так, проста - эктор образовано от слова action , что в переводе означает действие . Дословный же перевод слова "эктор" - действующее лицо - слишком длинный и неудобный для употребления. Поэтому мы будем и далее говорить именно так.
Рис. 2.1.
Тот же внимательный читатель мог заметить промелькнувшее в определении эктора слово "прецедент". Что же это такое? Этот вопрос заинтересует нас еще больше, если вспомнить, что сейчас мы говорим о диаграмме прецедентов . Итак,
Прецедент (use-case) - описание отдельного аспекта поведения системы с точки зрения пользователя (Буч).
Определение вполне понятное и исчерпывающее, но его можно еще немного уточнить, воспользовавшись тем же Zicom Mentor "ом:
Прецедент (use case) - описание множества последовательных событий (включая варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату. Прецедент представляет поведение сущности, описывая взаимодействие между экторами и системой. Прецедент не показывает, "как" достигается некоторый результат, а только "что" именно выполняется.
Прецеденты обозначаются очень простым образом - в виде эллипса, внутри которого указано его название. Прецеденты и экторы соединяются с помощью линий . Часто на одном из концов линии изображают рис. 2.3
Несколько месяцев назад мне поручили выбрать инструмент для проектирования и документации систем. В компании, где я работаю, всё это делалось в ворде и прочих офисных программах, а продукты, которые компания производит, становились всё более сложными, всё больше людей участвовало в разработке, и прочее. Поэтому появилась необходимость использовать какой-нибудь более подходящий инструмент для работы аналитиков, проектировщиков и разработчиков. Поделюсь находками.
После короткого ознакомления с подобными инструментами, были выделены 5, которые оценены более детально. При оценке, мы с коллегой выделили около 30 критериев, для объективности оценки. Критерии эти мы сгруппировали так:
- Проектирование системы
– даёт ли инструмент достаточно функциональности для документации требований, юс-кейсов, ОО проектирования и прочих UML диаграмм. Есть ли в нём функциональность для создания зависимости между объектами разных типов, возможность отслеживать изменения. Это – обязательный критерий для инструмента.
- Экспорт
– инструмент должен поддерживать удобный экспорт артефактов, произведённых в нём. Должны быть доступны разные форматы экспорта – хотя бы html и doc. Шаблоны документов должны легко модифицироваться. Это тоже обязательный критерий.
- Удобство пользования.
Инструмент должен быть удобным, интуитивно понятным, с простым интерфейсом для часто используемых функций.
- Минимизация рутины
. Было бы неплохо, чтобы инструмент делал некоторые вещи сам – например, генерировал тест-кейсы, объектный дизайн из БД, может, куски кода.
Итак, 5 инструментов и их оценка.
1. Case Complete
– инструмент для записи требований, создания юс-кейсов и связей между ними. Удобный интерфейс, экспорт, но один серьёзный минус – дальше юс-кейсов эта штука не идёт. Вообще непонятно, как она попала в наш список. 2 из 5.
2. Artiso Visual Case
– первое, что бросается в глаза при использовании этого инструмента – дико неудобный пользовательский интерфейс. Чтобы создать элементарный класс, мне понадобилось 5 минут. Кроме того, в инструменте нету возможности связывать объекты (как юс-кейс<->класс) и пр. 1 из 5.
3. Magic Draw
– у инструмента очень сильная сторона для UML, но из-за этого становиться немного неудобно. Ещё, там нет связи между разными объектами (как класс и activity и пр.). 3 из 5.
4. Sparx Enterprise Architect
– соответствует практически всем выдвинутым критериям, только что некоторые часто используемые функции куда-то спрятаны. Наверно, если привыкнуть - хорошо. Ещё, я у него не нашла, как связывать требования с объектами дизайна. Может, плохо искала. 4 из 5.
5. Sybase PowerDesigner
– первое впечатление после открытия программы – это совсем другой уровень. Все функции находятся именно там, где ожидаешь их найти, и этот инструмент удовлетворил все 30 критериев из описанных групп. Кроме того, в PowerDesigner есть куча очень полезных функций, которые не попали в список критериев – как например, оценка изменения(impact), проверка модели, Repository и многое другое. 5 из 5.
Вот сюда я выложила полное сравнение, если кому интересно.
Хотя PowerDesigner в разы дороже других, мы выбрали его. На сегодняшний день я его использую 2 месяца – если кому интересно, могу написать об этом - не всё в нём идеально(но близко!).
Наверно сразу спросите, почему в список не вошёл Rational Rose. Не люблю я его! Он некрасивый. И ещё, не смогла найти, где б его легально скачать. Но в принципе он хороший. Но PowerDesigner лучше
Для всех математических функций необходим заголовок
| 1 | acos | Функция double acos(double arg arg |
| 2 | asin | Функция double asin(double arg ) возвращает арккосинус аргумента arg . Значение аргумента функции должно лежать в интервале от -1 до 1, иначе произойдет ошибка. |
| 3 | atan | Функция double atan(double arg ) возвращает арктангенс аргумента arg . |
| 4 | atan2 | Функция double atan2(double x , double y ) возвращает арктангенс значения y /x . |
| 5 | ceil | Функция double ceil(double num ) возвращает ближайшее целое число (представленное как действительное число с плавающей точкой), которое не меньше значения аргумента num . Например, ceil(1.02) вернет 2.0. Такое преобразование называется округлением с избытком. |
| 6 | cos | Функция double cos(double arg ) возвращает косинус аргумента arg |
| 7 | cosh | Функция double cosh(double arg ) возвращает гиперболический косинус аргумента arg . |
| 8 | exp | Функция double exp(double arg ) возвращает основание натурального логарифма e, возведенное в степень arg . |
| 9 | fabs | Функция double fabs(double num ) возвращает абсолютное значение (значение по модулю) аргумента num . |
| 10 | floor | Функция double floor(double num ) возвращает наибольшее целое число (представленное как действительное число с плавающей точкой), не превышающее значения аргумента num . Например, floor(1.02) вернет число 1.0. Такое преобразование называется округлением с недостатком. |
| 11 | fmod | Функция double fmod(double x, double y) возвращает остаток от деления x/y. |
| 12 | frexp | Функция double frexp(double num , int *exp ) раскладывает число num на мантиссу, изменяющуюся в диапазоне от 0.1 до 1, не включая 1, и целый показатель степени, так что num = mantissa . Функция возвращает мантиссу, а значение показателя степени сохраняется в переменной, на которую ссылается указатель exp . |
| 13 | log | Функция double log(double num ) возвращает натуральный логарифм числа num . Если аргумент num |
| 14 | log10 | Функция double log10(double num ) возвращает десятичный логарифм числа num . Если аргумент num отрицателен или равен нулю, возникает ошибка. |
| 15 | pow | Функция double pow(double base , double exp ) возвращает число base , возведенное в степени exp . Если основание степени base равно нулю, а показатель степени exp меньше или равен нулю, может произойти ошибка, связанная с выходом аргумента из области определения функции (domain error). Это ошибка возникает также, если аргумент base отрицателен, а аргумент exp не является целым числом. |
| 16 | sin | Функция double sin(double arg ) возвращает синус аргумента arg . Значение аргумента должно быть выражено в радианах. |
| 17 | sinh | Функция double sinh(double arg ) возвращает гиперболический синус аргумента arg . |
| 18 | sqrt | Функция double sqrt(double num ) возвращает квадратный корень аргумента num . Если значение аргумента отрицательно, возникает ошибка, связанная с выходом из области определения функции. |
| 19 | tan | Функция double tan(double arg ) возвращает тангенс аргумента arg . Значение аргумента должно быть выражено в радианах. |
| 20 | tanh | Функция double tanh(double arg ) возвращает гиперболический тангенс аргумента arg . |
