Предварительные замечания
advertisement
Утёмов В.В.,2010г. Разработка и стандартизация программных средств и информационных технологий Конспект лекций Содержание ЛЕКЦИЯ 1. Введение. Группа проекта. Жизненный цикл. Предварительные замечания 3 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ....................................................................................................................................................................... 3 ГРУППА ПРОЕКТА ............................................................................................................................................................................................... 4 ЖИЗНЕННЫЙ ЦИКЛ ............................................................................................................................................................................................. 5 Предварительные замечания ..................................................................................................................................................................... 5 Последовательный тип .............................................................................................................................................................................. 5 Эволюционный тип ..................................................................................................................................................................................... 6 Выбор типа жизненного цикла .................................................................................................................................................................. 6 ЛЕКЦИЯ 2. АРХИТЕКТУРА ПРОГРАММНЫХ СИСТЕМ ......................................................................................................................... 7 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ....................................................................................................................................................................... 7 СТРУКТУРНЫЕ СУЩНОСТИ ................................................................................................................................................................................. 7 АРХИТЕКТУРНЫЕ ВИДЫ...................................................................................................................................................................................... 9 ЛЕКЦИЯ 3. РАЦИОНАЛЬНЫЙ УНИФИЦИРОВАННЫЙ ПРОЦЕСС................................................................................................... 10 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ..................................................................................................................................................................... 10 ХАРАКТЕРИСТИКИ ПРОЦЕССА .......................................................................................................................................................................... 10 ФАЗЫ, ИТЕРАЦИИ И ЦИКЛЫ РАЗРАБОТКИ ......................................................................................................................................................... 11 РАБОЧИЕ ПРОЦЕССЫ......................................................................................................................................................................................... 12 АРТЕФАКТЫ ...................................................................................................................................................................................................... 13 Модели ....................................................................................................................................................................................................... 13 Другие артефакты ................................................................................................................................................................................... 14 ЛЕКЦИЯ 4. АНАЛИЗ И ПРОЕКТИРОВАНИЕ. СТАДИЯ АНАЛИЗА ..................................................................................................... 15 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ..................................................................................................................................................................... 15 СТАДИЯ АНАЛИЗА ............................................................................................................................................................................................ 15 Стандарты семейства IDEF .................................................................................................................................................................. 15 Анализ на базе семейства IDEF ............................................................................................................................................................... 16 Объектно-ориентированный анализ и проектирование ........................................................................................................................ 19 ЛЕКЦИЯ 5. МОДЕЛЬ АНАЛИЗА ПРЕЦЕДЕНТОВ .................................................................................................................................... 20 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ..................................................................................................................................................................... 20 ПОТОК СОБЫТИЙ, СЦЕНАРИЙ, КООПЕРАЦИЯ ................................................................................................................................................... 21 ОРГАНИЗАЦИЯ ПРЕЦЕДЕНТОВ .......................................................................................................................................................................... 23 ЛЕКЦИЯ 6. ТИПИЧНЫЕ ПРИЕМЫ АНАЛИЗА ПРЕЦЕДЕНТОВ .......................................................................................................... 25 ПОВЕДЕНИЕ ЭЛЕМЕНТА .................................................................................................................................................................................... 25 ДИАГРАММА ПРЕЦЕДЕНТОВ ............................................................................................................................................................................. 26 МОДЕЛИРОВАНИЕ КОНТЕКСТА СИСТЕМЫ ........................................................................................................................................................ 27 МОДЕЛИРОВАНИЕ ТРЕБОВАНИЙ К СИСТЕМЕ .................................................................................................................................................... 27 ЛЕКЦИЯ 7. ВВЕДЕНИЕ В УНИФИЦИРОВАННЫЙ ПРОЦЕСС МОДЕЛИРОВАНИЯ ...................................................................... 29 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ..................................................................................................................................................................... 29 UML - это язык визуализации .................................................................................................................................................................. 30 UML - это язык специфицирования ......................................................................................................................................................... 30 UML - это язык конструирования ........................................................................................................................................................... 30 UML - это язык документирования ........................................................................................................................................................ 31 СУЩНОСТИ UML ............................................................................................................................................................................................. 32 ОТНОШЕНИЯ UML ........................................................................................................................................................................................... 35 ДИАГРАММЫ UML ........................................................................................................................................................................................... 37 ПРАВИЛА ЯЗЫКА UML ..................................................................................................................................................................................... 38 ОБЩИЕ МЕХАНИЗМЫ ЯЗЫКА UML................................................................................................................................................................... 39 ЛЕКЦИЯ 8. СИСТЕМЫ И МОДЕЛИ ............................................................................................................................................................. 41 ПРЕДВАРИТЕЛЬНЫЕ ЗАМЕЧАНИЯ ..................................................................................................................................................................... 41 СИСТЕМЫ И ПОДСИСТЕМЫ. МОДЕЛИ И ПРЕДСТАВЛЕНИЯ ............................................................................................................................... 41 МОДЕЛИРОВАНИЕ СИСТЕМНОЙ АРХИТЕКТУРЫ ............................................................................................................................................... 43 РАЗЛИЧНЫЕ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ ......................................................................................................................................................... 44 ЛЕКЦИЯ 9. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ И СРЕДСТВА АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ .................................................................................................................................................................. 47 ПРЕДВАРИТЕЛЬНЫЕ ИТОГИ .............................................................................................................................................................................. 47 КОМПОНЕНТНАЯ АРХИТЕКТУРА....................................................................................................................................................................... 48 КРАТКИЙ ПЕРЕЧЕНЬ ПРОИЗВОДИТЕЛЕЙ И ПРОГРАММНЫХ ПРОДУКТОВ .......................................................................................................... 48 СРАВНИТЕЛЬНЫЙ ОБЗОР ВОЗМОЖНОСТЕЙ RATIONAL ROSE И PARADIGM PLUS ......................................................................................... 50 Утёмов В.В.,2010г. Поддерживаемая нотация ....................................................................................................................................................................... 50 Методологии ............................................................................................................................................................................................. 50 Компонентно-базируемое проектирование ............................................................................................................................................ 51 Ведение репозитария объектов ............................................................................................................................................................... 51 Построение диаграмм моделей. Пользовательский интерфейс ........................................................................................................... 51 Генерирование программного кода .......................................................................................................................................................... 52 Наличие реинжиниринга........................................................................................................................................................................... 52 Проектирование баз данных. Поддержка SQL и мостов для реляционных баз данных, IDL для CORBA ......................................... 52 Создание экранного интерфейса ............................................................................................................................................................. 52 Возможность групповой работы ............................................................................................................................................................ 53 Наличие Script-языка................................................................................................................................................................................. 53 Генерирование отчетов и формирование проектной документации................................................................................................... 53 Поддерживаемые платформы ................................................................................................................................................................ 53 Место в общем цикле разработки программной системы ................................................................................................................... 53 Выводы....................................................................................................................................................................................................... 54 Утёмов В.В.,2010г. ЛЕКЦИЯ 1. Введение. Группа проекта. Жизненный цикл. Предварительные замечания Предварительные замечания В основе любой отрасли промышленного производства, к которым относится и создание программного обеспечения (ПО) или программных средств (ПС), лежит технологический процесс. Большинство характеристик программного продукта - качество, стоимость, сроки создания, актуальность - непосредственно определяются технологией разработки и точностью ее соблюдения. Фирма, занимающаяся производством программного обеспечения, может преуспевать только в том случае, если выпускаемая ею продукция всегда отличается высоким качеством и разработана в соответствии с потребностями пользователей. Компания, которая способна выпускать такую продукцию своевременно и регулярно, при максимально полном и эффективном использовании всех имеющихся человеческих и материальных ресурсов будет стабильно процветать. Ключевое понятие при этом качество - положено в основу международных стандартов ISO серии 9000. Обсудим основные положения этого стандарта. Основополагающая идея ISO 9000 состоит в том, что система качества предполагает построение такой структуры управления производством, которая гарантирует выпуск качественного продукта (в нашем случае, программного обеспечения) в любой момент, пока система действует. Приведем список элементов качества, на которые распространяются требования стандартов ISO 9000. Ответственность руководства. Система качества. Анализ контракта. Управление проектированием. Управление документацией. Закупки продукции. Продукция, предоставляемая потребителям. Идентификация продукции и ее прослеживаемость. Управление процессами. Контроль и проведение испытаний. Контрольное измерительное и испытательное оборудование. Статус контроля и испытаний. Управление продукцией, не соответствующей стандарту качества. Корректирующие и предупреждающие действия. Погрузочно-разгрузочные работы, хранение, упаковка и поставка. Регистрация данных о качестве. Внутренние проверки качества. Подготовка кадров. Техническое обслуживание. Статистические методы. Конечно, для компании, занимающейся разработкой ПО некоторые из перечисленных положений стандарта не совсем актуальны, но, тем не менее, анализ это списка указывает, что в нем отражены типичные бизнес-процессы, в той или иной мере, имеющие отношение к качеству выпускаемой продукции. Таким образом, функционально Утёмов В.В.,2010г. стандарты семейства ISO 9000 связаны с обеспечением качества системы управления производством изделия. Из сказанного выше следует, что основным продуктом компании по производству ПО является именно первоклассное программное обеспечение, удовлетворяющее повседневным нуждам пользователей. Все остальное: прекрасные документы, встречи на высшем уровне, великолепные лозунги, новаторские идеи и даже Пулитцеровская премия за идеальные строки исходного кода - вторично по сравнению с этой основной задачей. К сожалению, на первых порах, а иногда и в уже устоявшихся программистских коллективах путают понятия "вторичный" и "несущественный". Вы не имеете права забывать, что для разработки эффективной программы, которая соответствует своему предполагаемому назначению, необходимо постоянно встречаться и работать с пользователями, чтобы выяснить реальные требования к вашей системе. Если вы хотите создавать качественное программное обеспечение вам необходимо разработать прочное архитектурное основание проекта, открытое к возможным усовершенствованиям. Для быстрой и эффективной разработки программных средств с минимальным браком требуется привлечь достаточно квалифицированную рабочую силу, выбрать правильные инструменты и определить верное направление работы. Чтобы справиться с поставленной задачей и в конечном итоге получить прибыль, принимая во внимание затраты на обеспечение процесса разработки и внедрения системы, необходимо, чтобы процесс разработки приложения был тщательно продуман и мог быть адоптирован к изменяющимся потребностям вашего бизнеса и технологии. По способу производства различные виды ПО можно классифицировать на заказное и тиражное. Соответственно в достаточной степени различаются и технологические процессы его производства. В настоящем курсе речь пойдет о технологиях создания заказных продуктов. Теперь введем ряд важных понятий, которые мы будем активно использовать на протяжении всего нашего курса. Группа проекта В начале ответим на вопросы, связанные с составом команды разработчиков и распределением обязанностей внутри этой команды. Для разработки ПО так или иначе организуется некоторый коллектив. Это может быть подразделение компании или фирмы, работающей в этом сегменте рынка, или группа единомышленников, только начинающая свою деятельность в области разработки, в конце концов, это может быть просто единственный программист. Такую рабочую группу мы будем называть группой проекта. Давайте определим функциональные обязанности участников этой группы. В состав группы обычно входят следующие специалисты: руководитель проекта - координирует все действия, организует внешнее и внутреннее взаимодействия группы проекта, обеспечивает соблюдение сроков разработки и качество разрабатываемого ПО и его соответствие требованиям заказчика, несет полную ответственность за результат работ по проекту; системный аналитик - анализирует требования к системе, разрабатывает концепцию и логику работы системы, составляет технические задания или подобные документы, несет ответственность за соответствие предлагаемых решений требованиям заказчика; разработчики - реализуют принятые технические задания, отвечают за качество и сроки разрабатываемого кода, за его соответствие техническим заданиям; дизайнер - участвует в разработке концепции системы, разрабатывает ее пользовательский интерфейс и принимает участие в его реализации, несет ответственность за соблюдение фирменного стиля и требований к реализации пользовательского интерфейса; тестер - разрабатывает программу тестирования, осуществляет ее и несет ответственность за полноту тестирования готовых модулей и системы в целом; Утёмов В.В.,2010г. технический писатель - разрабатывает документацию на проект, несет ответственность за полноту и правильность описания. Оговорим ряд замечаний. Первое, дизайнер, тестер и технический писатель могут в группу постоянно не входить, а работать над несколькими проектами и привлекаться к работе по мере необходимости. Второе, в подразделение по разработке ПО, состоящее из нескольких проектных групп, может входить технолог, который разрабатывает, внедряет и поддерживает технологию производства программных продуктов. Третье, для сложных проектов, связанных с активным применением сетевых решений, Internet технологий и т. д. в группу проекта может подключаться специалист по использованию сетей. И, наконец последнее, наш состав группы проекта включает в себя только непосредственную команду разработчиков проекта, но кроме них над проектом могут работать и другие специалисты компании: менеджеры, маркетологи и т. д. Теперь перейдем непосредственно к самому процессу разработки. Жизненный цикл Предварительные замечания Одним из основополагающих понятий технологии разработки программного обеспечения является понятие жизненного цикла (ЖЦ). Под жизненным циклом ПО понимается совокупность процессов, связанных с последовательным изменением состояния ПО от формирования исходных требований к нему до окончания его эксплуатации. Жизненный цикл состоит из стадий - логически завершенных частей ЖЦ. Стадии характеризуются определенными состоянием ПО, видом предусмотренных работ и их результатом. Выделяют несколько основных типов ЖЦ, различающихся порядком следования стадий и взаимосвязями между ними, которые мы обсудим несколько ниже. При создании заказного ПО выделяют пять основных стадий ЖЦ: анализ и формализация требований заказчика; проектирование; реализация; тестирование; внедрение и эксплуатация. Теперь об обещанных типах ЖЦ. В литературе описано множество типов жизненных циклов. Среди всего этого разнообразия можно выделить два основных. Последовательный тип Данный тип ЖЦ предполагает, что каждая следующая стадия может быть начата только после завершения работ на предыдущей стадии. Он применим когда: требования к продукту четко определены и не меняются со временем; имеется достаточно большой опыт реализации подобного рода систем; время реализации проекта составляет от нескольких месяцев до года. Реализация проекта по данному типу ЖЦ легко планируется и контролируется. Однако для этого необходимо заранее иметь все требования к продукту. Данный тип ЖЦ не Утёмов В.В.,2010г. приспособлен к изменениям требований к продукту. Разрабатываемый продукт не может использоваться, пока проект не будет близок к завершению. В реальности в последнее время этот тип жизненного цикла практически никогда не применяется. Эволюционный тип Функциональные возможности системы в данном случае наращиваются постепенно. В процессе разработки основные стадии ЖЦ (проектирование, реализация, тестирование) проходятся несколько раз применительно к очередной добавляемой порции возможностей системы. Данный тип ЖЦ не требует заранее наличия всех требований к системе и позволяет заказчику активно участвовать в ее разработке, что является безусловным плюсом. Однако среди недостатков эволюционного типа: сложность в управлении и контроле выполнения проекта; сложность оценки затрат на разработку; риск бесконечного улучшения системы. Данный тип применим, когда требования к системе плохо определены или будут изменяться, отсутствует достаточный опыт в разработке подобных систем, используются новые технологии и (или) инструментальные средства, в ходе разработки системы необходимо иметь промежуточные версии продукта. Выбор типа жизненного цикла Выбор конкретного типа жизненного цикла зависит от ряда субъективных и объективных причин, сопутствующих проекту: наличия четких и подробных требований к ПО; ресурсов, имеющихся в наличии для проведения работ по проекту; наличия и доступности заказчика в процессе разработки; новизны используемых при разработке технологий и (или) инструментальных средств. Обычно решение о выборе конкретного типа жизненного цикла принимается руководителем проекта. Как правило, в реальности применяется смешанный тип жизненного цикла, а в последнее время все чаще Унифицированный Процесс Разработки, но прежде чем перейти к рассмотрению этого процесса необходимо дать понятие системной архитектуры. Утёмов В.В.,2010г. ЛЕКЦИЯ 2. Архитектура программных систем Предварительные замечания Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту: конечные пользователи, системные аналитики, руководители проекта, разработчики, тестеры, технические писатели, менеджеры и т.д. - преследуют собственные цели, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизненного цикла. При этом создаются самые разнообразные артефакты. Системная архитектура является, возможно, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем промежутке ее жизненного цикла. Раз уж мы ввели в использование эти два понятия, давайте дадим их точные определения, на сколько это возможно в таком предмете как программирование. Итак, итеративным (iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (risk-driven), так как в при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума. Теперь вернемся непосредственно к понятию архитектура. Под архитектурой программной системы понимается совокупность решений относительно: организации программной системы; выбора структурных элементов, составляющих систему и их интерфейсов; поведения этих элементов, специфицированного в кооперациях с другими элементами; составления из этих структурных и поведенческих элементов все более и более крупных подсистем; архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способы их объединения. Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы. Структурные сущности Сущности являются основными элементами артефактов объектно-ориентированного анализа и проектирования. С их помощью можно создавать корректные артефакты. Структурные сущности - это имена существительные в предметной области, решаемой задачи. Как правило, они представляют собой статические части, соответствующие Утёмов В.В.,2010г. концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей. Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Класс реализует один или несколько интерфейсов. Интерфейс (interface) - это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент. Интерфейс отвечает за видимое извне поведение элемента. С помощью интерфейса поведение класса или компонента может быть представлено полностью или частично, он определяет только спецификации операций (сигнатуры), но никогда - их практическую реализацию. Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых. Кооперация, таким образом, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях, которые представляют собой реализацию образцов поведения, определяющих систему. Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Основная цель применения прецедентов структурировать поведенческие сущности системы. Реализуются прецеденты посредством кооперации. Три другие сущности: активные классы, компоненты и узлы - подобны классам, они описывают совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Тем не менее, они в достаточной степени отличаются друг от друга и от классических классов и, учитывая их важность при моделировании определенных аспектов объектно-ориентированных систем, заслуживают персонального рассмотрения. Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Активный класс практически полная копия обычного, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Два последних элемента: компоненты и узлы - также имеют свои особенности. Они соответствуют физическим сущностям системы, а предыдущие пять - концептуальным и логическим сущностям. Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, классический пример тому компоненты COM+, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, обычно, представляет собой физическую упаковку логических объектов, таких как классы, интерфейсы и кооперации. Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Совокупность компонентов может размещаться на узле, а также мигрировать с одного узла на другой. Утёмов В.В.,2010г. Перечисленные семь базовых элементов: классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы - являются основными структурными сущностями, которые могут быть использованы при создании артефактов объектно-ориентированного анализа и проектирования. Существуют и другие разновидности сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов). Кроме структурных, существуют и другие виды сущностей, но о них несколько позже. Архитектурные виды На сегодняшний день считается, что архитектура программной системы наиболее оптимально может быть описана с помощью пяти взаимосвязанных видов или представлений, каждый из которых является одной из возможных проекций организации и структуры системы и заостряет внимание на определенном аспекте ее функционирования: вид с точки зрения прецедентов (use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестерами. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры; вид с точки зрения проектирования (design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид подчеркивает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям; вид с точки зрения процессов (process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы. вид с точки зрения реализации (implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой; вид с точки зрения развертывания (deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющий физическую систему. Каждый из перечисленных видов может считаться вполне самостоятельным, так что члены группы проекта, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. Правда, нельзя забывать о том, что эти виды взаимодействуют друг с другом, что неудивительно, так как они представляют разные взгляды на одну систему. Например, узлы вида с точки зрения развертывания содержат компоненты, описанные для вида сточки зрения реализации, а те в свою очередь представляют физическое воплощение классов, интерфейсов, коопераций и активных классов из видов с точки зрения проектирования и процессов. Утёмов В.В.,2010г. ЛЕКЦИЯ 3. Рациональный унифицированный процесс Предварительные замечания Процессом (process) называется частично упорядоченное множество шагов, направленных на достижение некоторой цели. В контексте проектирования программного обеспечения вашей целью является поставка в предсказуемые сроки продукта, удовлетворяющего потребностям бизнеса вашего клиента. Цель Рационального Унифицированного Процесса - обеспечить изготовление программного продукта высочайшего качества, соответствующего потребностям пользователя, в заданные сроки и в пределах заранее составленной сметы. Рациональный Унифицированный Процесс вобрал в себя лучшие из существующих методик разработки и придал им форму, которая может быть легко адаптирована для самых разных проектов и организаций. С точки зрения управления проектом Рациональный Унифицированный Процесс предлагает упорядоченный подход к тому, как должны распределяться работа и ответственность в организации, занимающейся производством программного обеспечения. В настоящем разделе описываются основные элементы Рационального Унифицированного Процесса. Характеристики процесса Рациональный Унифицированный Процесс итеративен. Если речь идет о простых системах, не представляет особого труда последовательно определить задачу, спроектировать ее целостное решение, написать программу и протестировать конечный продукт. Но, учитывая сложность и разветвленность современных систем такой линейный подход к разработке оказывается нереалистичным. Итеративный подход предполагает постепенное проникновение в суть проблемы путем последовательных уточнений и построение все более емкого решения на протяжении нескольких циклов. Итеративному подходу присуща внутренняя гибкость, позволяющая включать в бизнес-цели новые требования или тактические изменения. Его использование оставляет возможность выявить и устранить риски, связанные с проектом, на возможно более ранних этапах разработки. Суть работы в рамках Рационального Унифицированного Процесса - это создание и сопровождение моделей, а не бумажных документов. Модели, выраженные на языке UML (универсальный язык моделирования), делают семантически насыщенное представление разрабатываемого программного комплекса. На них можно смотреть с разных точек зрения, а представленную в них информацию допустимо мгновенно извлечь и проконтролировать электронным способом. Рациональный Унифицированный Процесс обращен прежде всего на модели, а не на бумажные документы; причина состоит в том, чтобы свести к минимуму накладные расходы, связанные с созданием и сопровождением документов, и повысить степень информационного наполнения проектирования. В центре разработки в рамках Рационального Унифицированного Процесса лежит архитектура. Основное внимание уделяется раннему определению архитектуры программного комплекса и формулированию основных ее особенностей. Наличие прочной архитектуры позволяет "распараллелить" разработку, сводит к минимуму переделки, увеличивает вероятность того, что компоненты можно будет использовать повторно, и в конечном счете делает систему более удобной для последующего сопровождения. Подобный архитектурный чертеж - это фундамент, на базе которого Утёмов В.В.,2010г. можно планировать процесс разработки компонентного программного обеспечения и управлять им. Разработка в рамках Рационального Унифицированного Процесса сосредоточена на прецедентах. В основу построения системы положено исчерпывающее представление о том, каково ее назначение. Концепции прецедентов и сценариев используются на всех стадиях процесса, от формулирования требовании до тестирования; они помогают проследить все действия от начала разработки до поставки готовой системы. Рациональный Унифицированный Процесс поддерживает объектно-ориентированные методики. Каждая модель объектно-ориентированна. Модели, применяемые в рамках Рационального Унифицированного Процесса, основаны на понятиях объектов и классов и отношений между ними, а в качестве общей нотации используют нотацию UML Рациональный Унифицированный Процесс поддастся конфигурированию. Хотя ни один отдельно взятый процесс не способен удовлетворить требованиям всех организаций, занимающихся разработкой программного обеспечения, Рациональный Унифицированный Процесс поддается настройке и масштабируется для использования как в совсем небольших коллективах, так и в гигантских компаниях. Он базируется на простой и ясной архитектуре, которая обеспечивает концептуальное единство во множестве всех процессов разработки, но при этом адаптируется к различным ситуациям. Составной частью Рационального Унифицированного Процесса являются рекомендации по его конфигурированию для нужд конкретной организации. Рациональный Унифицированный Процесс поощряет объективный контроль качества и управление рисками на всех стадиях воплощения проекта. Контроль качества является неотъемлемой частью процесса, охватывает все виды работ и всех участников. При этом применяются объективные критерии и методы опенки. Контроль качества не рассматривается как особый род деятельности, которой можно заняться по завершении разработки. Управление рисками также встроено в процесс так, что возможные препятствия на пути успешного завершения проекта выявляются и устраняются на ранних этапах разработки, когда для реагирования еще остается время. Фазы, итерации и циклы разработки Фаза (phase) - это промежуток времени между двумя важными опорными точками процесса, в которых должны быть достигнуты четко определенные цели, подготовлены те или иные артефакты и принято решение о том, следует ли переходить к следующей фазе. Рациональный Унифицированный Процесс состоит из следующих четырех фаз: Начало (inception) - определение бизнес-целей проекта. На этой стадии определяются цели системы и устанавливаются рамки проекта. Анализ целей включает выработку критерия успешности, оценку рисков, необходимых ресурсов и составление плана, в котором отражены основные опорные точки. Нередко создается исполняемый прототип, демонстрирующий реалистичность концепции. В конце начальной фазы еще раз подвергается внимательному изучению весь жизненный цикл проекта и принимается решение, стоит ли начинать полномасштабную разработку. Исследование (elaboration) - разработка плана и архитектуры проекта. На данном этапе стоит задача проанализировать предметную область, выработать прочные архитектурные основы, составить план проекта и устранить наиболее опасные риски. Архитектурные решения должны приниматься тогда, когда стала ясна структура системы в целом, то есть большая часть требовании уже сформулирована. Для подтверждения правильности выбора архитектуры создается система, демонстрирующая выбранные принципы в действии и реализующая некоторые наиболее важные прецеденты. В конце фазы исследования изучаются Утёмов В.В.,2010г. детально расписанные пели проекта, его рамки, выбор архитектуры и методы управления основными рисками, а затем принимается решение о том, надо ли приступать к построению. Построение (construction) - постепенное создание системы. В фазе построения постепенно и итеративно разрабатывается продукт, готовый к внедрению. На этом этапе описываются оставшиеся требования и критерии приемки, проект "обрастает плотью", завершается разработка и тестирование программного комплекса. В конце фазы построения принимается решение о готовности программ, эксплуатационных площадок и пользователей к внедрению. Внедрение (transition) - поставка системы конечным пользователям. В фазе внедрения программное обеспечение передается пользователям. После этого часто возникают требующие дополнительной проработки вопросы по настройке системы, исправлению ошибок, ранее оставшихся незамеченными, и окончательному оформлению ряда функций, реализация которых была отложена. Обычно эта стадия воплощения проекта начинается с выпуска бета-версии системы, которая затем замещается коммерческой версией. В конце фазы внедрения делается заключение о том, достигнуты ли цели проекта и надо ли начинать новый цикл разработки. Подводятся итоги работы над проектом и извлекаются уроки, которые помогут улучшить процесс разработки в ходе работы над новым проектом. Фазы начала и исследования охватывают проектные стадии жизненного цикла процесса разработки; фазы построения и внедрения относятся к производству. Внутри каждой фазы происходит несколько итераций. Итерация (iteration) представляет полный цикл разработки, от выработки требований во время анализа до реализации и тестирования. Итерация - это завершенный этап, в результате которого выпускается версия (для внутреннего или внешнего использования) исполняемого продукта, реализующая часть запланированных функций. Затем эта версия от итерации к итерации наращивается до получения готовой системы. Во время каждой итерации выполняются особые рабочие процессы, хотя в разных фазах основной упор делается на разных работах. В начальной фазе главной задачей является выработка требований, в фазе исследования - анализ и проектирование, в фазе построения - реализация, а в фазе внедрения - развертывание. Конечным результатом является выпуск готового продукта. Все фазы и итерации подразумевают определенные затраты усилий на снижение рисков. В конце каждой фазы находится четко определенная опорная точка, где оценивается, в какой мере достигнуты намеченные цели и не следует ли внести в процесс изменения, прежде чем двигаться дальше. Прохождение через четыре основные фазы называется циклом разработки. Каждый цикл завершается генерацией версии системы. Первый проход через все четыре фазы называют начальным циклом разработки. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы: начальную, исследования, построения и внедрения. Система таким образом эволюционирует, поэтому все циклы, следующие за начальным, называются эволюционными. Рабочие процессы Рациональный Унифицированный Процесс состоит из девяти рабочих процессов: моделирование бизнес-процессов - описывается структура и динамика организации; разработка требований - описывается основанный на прецедентах метод постановки требований; Утёмов В.В.,2010г. анализ и проектирование - описываются различные виды архитектуры системы; реализация - собственно разработка программ, автономное тестирование и интеграция; тестирование - описываются тестовые сценарии, процедуры и метрики для измерения числа ошибок; развертывание - охватывает конфигурирование поставляемой системы; управление конфигурацией - управление изменениями и поддержание целостности артефактов проекта; управление проектом - описывает разные стратегии работы с итеративным процессом; анализ среды - рассматриваются вопросы инфраструктуры, необходимой для разработки системы. Внутри каждого рабочего процесса сосредоточены связанные между собой артефакты и деятельности. Напомним, что артефакт (artifact) - это некоторый документ, отчет или исполняемая программа, которые производятся, а впоследствии преобразуют или потребляются. Термином деятельность (activity) описываются задачи - обдумывание, выполнение, анализ проекта - которые решаются сотрудниками с целью создания или модификации артефактов, а также способы и рекомендации по решению; этих задач. В число таких способов могут входить и инструментальные средства, позволяющие автоматизировать решение части задач. С некоторыми из рабочих процессов ассоциированы важные связи между артефактами. Например, модель прецедентов, созданная в ходе выработки требований, конкретизируется в виде проектной модели, являющейся результатом процесса анализа и проектирования, воплощается в модели реализации, которая получена в процессе реализации, и верифицируется моделью тестирования из процесса тестирования. Артефакты В начале дадим определение: артефакт (artifact) - это диаграмма, документ, модель, закон и т. д. - нечто, описывающее определенное понятие предметной области. Теперь давайте выясним какие производственные процессы выполняются при разработке программного обеспечения , и какие артефакты при этом разрабатываются. С каждой деятельностью в Рациональном Унифицированном Процессе связаны артефакты, которые либо подаются на вход, либо получаются на выходе. Артефакты используются как исходные данные для последующей деятельности, содержат справочные сведения о проекте или выступают в роли поставляемых по контракту составляющих. Модели Модели - это самый важный вид артефактов в Рациональном Унифицированном Процессе. Модель (model) - это упрощение реальности; она создается для лучшего понимания разрабатываемой системы. В Рациональном Унифицированном Процессе имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы: модель бизнес-процессов - формализует абстракцию организации; модель предметной области - формализует контекст системы; Утёмов В.В.,2010г. модель прецедентов - формализует функциональные требования к системе; аналитическая модель (необязательная) - формализует идею проекта; проектная модель - формализует словарь предметной области и области решения; модель процессов (необязательная) - формализует механизмы параллелизма и синхронизации в системе; модель развертывания - формализует топологию аппаратных средств, на которых выполняется система; модель реализации - описывает части, из которых собирается физическая система; модель тестирования - формализует способы проверки и приемки системы. Вид - это одна из проекций модели. В Рациональном Унифицированном Процессе существует пять тесно связанных друг с другом видов системной архитектуры, о которые мы рассматривали на предыдущей лекции (см. лекцию 3): с точки прения проектирования, процессов, развертывания, реализации и прецедентов. Другие артефакты Артефакты в Рациональном Унифицированном Процессе подразделяются на две группы: административные и технические. Технические артефакты, в свою очередь, делятся на четыре большие подгруппы: группа требований - описывает, что система должна делать; группа проектирования - описывает, как система должна быть построена; группа реализации - описывает сборку разработанных программных компонентов; группа развертывания - содержит все данные, необходимые для конфигурирования предоставленной системы. В группу требований включается информация о том, что система должна делать. В составе этих артефактов могут быть модели прецедентов, нефункциональных требований, предметной области и иные формы выражения потребностей пользователя, в том числе макеты, прототипы интерфейсов, юридические ограничения и т. д. Группа проектирования содержит информацию о том, как система должна быть построена с учетом ограничений по времени и бюджету, наличия унаследованных систем, повторного использования, требований к качеству и т. д. Сюда относятся проектная модель, модель тестирования и иные формы выражения потребностей пользователя, в том числе прототипы и исполняемые архитектуры. К группе реализации относится вся информация о программных элементах, из которых состоит система, в том числе исходный код на различных языках программирования, конфигурационные файлы, файлы данных, программные компоненты и т.д., а также информация о том, как собирать систему. Утёмов В.В.,2010г. ЛЕКЦИЯ 4. Анализ и проектирование. Стадия анализа Предварительные замечания Для создания программного приложения необходимо описать проблему и требования к системе. Стадия анализа (analysis) состоит в исследовании проблемы, а не в поисках ее решения. Например, при разработке новой экономической информационной системы необходимо описать экономические процессы, связанные с ее использованием. При разработке приложения необходимо также обеспечить высокий уровень и подробное документирование логики решения, удовлетворяющего требованиям к системе и налагаемым ограничениям. В процессе проектирования (design) основное внимание уделяется логическому решению, обеспечивающему выполнение основных требований. Например, как будет функционировать новая экономическая информационная система? Естественно, проект может быть реализован в виде аппаратных средств и программного обеспечения. В реальной жизни программные проекты чаще всего достаточно сложны, и их декомпозиция (по принципу "разделяй и властвуй") - это основная и, наверное, единственная стратегия борьбы со сложностью. Она состоит в разбиении проблемы на мелкие управляемые элементы. До появления объектно-ориентированного подхода во времена господства парадигмы структурного программирования наиболее популярной методологией декомпозиции являлись структурный анализ и проектирование (structured analysis and design). Этот подход заключается в декомпозиции задачи на функции или процессы, приводящий к созданию иерархии процессов и подпроцессов. Существовали и существуют и другие методы декомпозиции. В следующем разделе мы рассмотрим наиболее известные и часто применяемые методики анализа, позволяющие минимизировать риски и решать ключевые проблемы, возникающие на различных этапах жизненного цикла. Стадия анализа Стандарты семейства IDEF Это семейство методологий создавалось в то время, когда существовала "иллюзия всеобщего математического моделирования", в соответствии, с чем предполагалась следующая последовательность действий: определение функциональной (концептуальной) модели бизнеса - определение данных, необходимых для реализации модели - математическое моделирование - оценка результатов - реорганизация модели - и новая итерация, пока модель не будет "поставлена в рамки". В соответствии с этой концепцией и предполагалось создать серию стандартов: IDEF0 - стандарт функционального моделирования (принят). IDEF1 (X) - стандарт информационного моделирования (принят), хорошо известен еще и под названием "ER- диаграммы". IDEF2 - стандарт математического моделирования (не принят). Не принятие стандарта математического моделирования было вполне естественным, так как при реализации математической модели приходилось либо жертвовать ее точностью, либо ... самой возможностью что-то моделировать, ввиду чего никогда нельзя было с полной уверенностью говорить о "соответствии математической модели Утёмов В.В.,2010г. функциональной", разработанной в стандарте IDEF 0. Тем не менее, существуют программные продукты, которые позволяют проводить математическое моделирование по функциональному описанию в стандарте IDEF0. IDEF3 - наиболее важный из серии современных стандартов, определяет методологию моделирования процессов, проще говоря, построения технологических карт. Отсутствие методологии моделирования процессов (технологий) было существенным недостатком семейства методологий IDEF, что затрудняло использование их, например, в проектировании корпоративных информационных систем. В последние годы семейство методологий IDEF получило дальнейшее распространение, став полноценной системой разработки систем управления, от концепции проекта до создания кода программного продукта, выполняющего определенные на концептуальном уровне задачи. Наиболее интересные компоненты современного развития семейства IDEF перечислены ниже: DFD "Data flow diagram", "диаграммы потоков данных" - широко распространенная методология моделирования процессо-ориентированного типа. "Моделирование в терминах системы" - одной из существенных проблем при использовании "универсальных" методологий моделирования является дальнейшее использование результатов в практической работе, например при внедрении или создании корпоративной информационной системы. Часто оказывается (особенно до создания методологии IDEF 3), что применить результаты длительной работы достаточно сложно. Поэтому неудивительно, что все крупнейшие поставщики интегрированных программных систем озаботились созданием специализированных систем моделирования, адекватных применяемой системе. Наиболее интересная методология "моделирования в терминах системы" создана усилиями специалистов BAAN. Анализ на базе семейства IDEF Как мы уже говорили, прежде чем пытаться выбрать существующую или создать собственную информационную систему, а затем внедрить ее, необходимо проанализировать, как работает предприятие в настоящее время. Для анализа необходимо знать не только то, как работает предприятие в целом и как оно взаимодействует с внешними организациями, заказчиками и поставщиками, но и как организована деятельность на каждом рабочем месте, по крайней мере, на тех рабочих местах, которые планируется автоматизировать. Проблема в том, что один человек, как правило, не располагает такой информацией. Действительно, руководитель предприятия хорошо представляет, как работает организация в целом, но не в состоянии знать все особенности деятельности своих сотрудников. Рядовой же сотрудник хорошо знает свои обязанности, но плохо разбирается в том, как работают его коллеги. Следовательно, для анализа деятельности предприятия следует собрать знания множества людей в едином месте, а это означает, необходимость создания модели деятельности предприятия. Многие корпоративные информационные системы зарубежных производителей (SAP R/3, Baan, Ross iRenaissance и др.) имеют в своем составе специальные средства, основанные на собственных универсальных методиках. С помощью этих средств можно обследовать предприятие и построить модель их деятельности. Использование этих средств в нашей стране по вполне понятным причинам в на стоящее время затруднено. Однако существуют и стандартизированные методологии и инструментальные средства, Утёмов В.В.,2010г. прошедшие проверку временем, позволяющие решить эту задачу. К их числу и относятся стандарты семейства IDEF. Начнем с самого первого стандарта IDEF0, в основе которого лежит метод SADT (методология структурного анализа и проектирования). Основная идея этой методологии построение древовидной функциональной модели предприятия. Сначала функциональность предприятия описывается в целом, без подробностей, такое описание называется контекстной диаграммой. Взаимодействие с окружающим миром описывается в терминах входа (данные или объекты, потребляемые или изменяемые функцией), выхода (основной результат деятельности функции, конечный продукт), управления (стратегии и нормативные акты, которыми руководствуется функция) и механизмов (необходимых ресурсов). Кроме того, при создании контекстной диаграммы формулируется цель моделирования, область (т. е. описание того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точка зрения (позиция, в соответствии, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или позиция объекта, ответственного за работу моделируемой системы в целом. Затем общая функция в процессе функциональной декомпозиции разбивается на крупные подфункции, каждая подфункция, в сою очередь, декомпозируется на более мелкие - и так происходит вплоть до достижения необходимой детализации описания. На рис. показано дерево функций, которое называется деревом узлов функциональной модели. Каждый узел соответствует отдельному фрагменту описания - диаграмме (см. рис. ниже). Модель представляет собой совокупность иерархически выстроенных диаграмм, каждая из которых является описанием какой-либо функции или работы (activity). Утёмов В.В.,2010г. Работы на диаграммах изображаются в виде прямоугольников (функциональных блоков activity box). Каждая работа изображает какую-либо функцию или работу и именуется глаголом или глагольной фразой (если моделирование ведется на русском языке), обозначающей действие, например, "Изготовление изделия", "Обслуживание клиента" и т. д. Стрелки помечаются существительными и обозначают объекты или информацию, связывающие работы между собой и с внешним миром. В отличии от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в функциональной модели - это не элемент управления нижестоящими работами, а их совокупность. Работа нижнего уровня - это тоже самое, что и работа верхнего уровня, но в более детальном изложении. После каждого сеанса декомпозиции автором диаграммы формируется папка - набор документов, в который входят сама диаграмма, дополнительные отчеты, материалы и т. д. Папка направляется эксперту предметной области, который хорошо разбирается в моделируемом фрагменте деятельности предприятия, для проведения экспертизы. На уровне контекстной диаграммы это может быть управляющий предприятия, на уровне первой декомпозиции - начальник отдела и т. д., вплоть до рядового исполнителя. Прежде чем декомпозировать далее, на текущем уровне необходимо внести в диаграмму все замечания экспертов. В результате получается полностью адекватная системе модель, которая с одной стороны может служить основой для создания информационной системы, а с другой позволяет наглядно представить имеющиеся недостатки, перенаправить и усовершенствовать бизнес-процессы, произвести анализ себестоимости производства. Теперь более подробно о стандартах. В настоящее время самыми распространенными являются следующие три стандарта (нотации) IDEF0, DFD и IDEF3. Каждая из этих нотаций позволяет рассмотреть различные стороны деятельности предприятия. Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии. Они позволяют понять, какие объекты или информация служат сырьем для процессов, какие результаты следуют из проделанных работ, что является управляющими факторами и какие ресурсы для этого необходимы. Нотация IDEF0 помогает выявить формальные недостатки бизнес-процессов, что существенно облегчает анализ деятельности предприятия. Диаграммы потоков данных (Data Flow Diagramming, DFD) используются для описания документооборота и обработки информации. Для описания логики взаимодействия информационных потоков более подходит нотация IDEF3 (workflow diagramming), нотация моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектами, которые являются частью этих процессов. В результате обследования предприятия строится функциональная модель существующей организации работы "как есть" (AS-IS). На основе этой модели достигается консенсус между различными единицами бизнеса по вопросам, кто что сделал и что каждая единица бизнеса добавляет в процесс. Эта модель позволяет выяснить, что можно сделать сегодня, перед тем как решить, что следует сделать завтра. Внедрение информационной системы неизбежно приведет к пересторойке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся самые узкие места, в чем будет состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая организация бизнеса. Детализация бизнеспроцессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками несовершенной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужного документа не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (проведение работы не зависит от результата) и по входу (объекты и информация используется нерационально). При разработке программного обеспечения служит основной отправной точкой для процесса проектирования. Многие из Утёмов В.В.,2010г. перечисленных структурных методов великолепно работают ориентированном подходе, о котором сейчас и пойдет речь. и при объектно- Объектно-ориентированный анализ и проектирование Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектноориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектноориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И, наконец, в процессе конструирования (construction) или объектно-ориентированного программирования (object-oriented programming) обеспечивается реализация разработанных компонентов и классов. Рассмотрим вкратце некоторые основные принципы объектно-ориентированного анализа и проектирования, в дальнейшем мы дадим более точные определения и более полную расшифровку всех рассмотренных терминов. С начала производится так называемый анализ требований (requirements analysis) во время которого выделяются основные процессы, происходящие в моделируемой системе и их формулировка в виде прецедентов. Прецедент (precedent)- это текстовое описание процессов, происходящих в предметной области. Шаг второй. Объектно-ориентированный анализ предметной области (objectoriented domain analysis). Задача этого шага в определении видов деятельности участников процесса и составлении концептуальной модели (conceptual model), которая отражает различные категории элементов предметной области. Причем не только виды деятельности участников, но и все относящиеся к делу понятия. Шаг третий. Разбираемся, кто, чем занимается. Эта деятельность и называется объектно-ориентированным проектированием (object-oriented design), при котором основное внимание сосредоточено на распределении обязанностей. Распределение обязанностей (responsibility assignment) означает выделение задач и обязанностей различных программных объектов в приложении. Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы. Дело в том, что единственный вид деятельности, без которого невозможно обойтись. К тому же он оказывает определяющее влияние на робастность, масштабируемость, расширяемость и возможность повторного использования компонентов. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов (design class diagram) и диаграмм взаимодействий (collaboration diagram). Утёмов В.В.,2010г. ЛЕКЦИЯ 5. Модель анализа прецедентов Предварительные замечания Системы не существуют в изоляции. Как правило, они взаимодействуют с актерами, людьми или программами, которые используют систему в своих целях, причем каждый актер ожидает, что она будет вести себя определенным, вполне предсказуемым образом. Прецедент (use case) специфицирует поведение системы или ее части и представляет собой описание множества последовательностей действий (включая варианты), выполняемых системой для того, чтобы актер мог получить определенный результат. С помощью прецедентов можно описать поведение разрабатываемой системы, не определяя ее реализацию. Таким образом, они позволяют достичь взаимопонимания между разработчиками, системными аналитиками, экспертами и конечными пользователями продукта. Кроме того, прецеденты помогают проверить архитектуру системы в процессе ее разработки. Реализуются они кооперациями. Прецедент описывает множество последовательностей, каждая из которых представляет взаимодействие сущностей, находящихся вне системы (ее актеров), с системой как таковой и ее ключевыми абстракциями. Такие взаимодействия являются в действительности функциями уровня системы, которыми вы пользуетесь для визуализации, специфицирования, конструирования и документирования ее желаемого поведения на этапах сбора и анализа требований. Прецедент представляет функциональные требования к системе в целом. Прецеденты предполагают взаимодействие актеров и системы. Актер представляет собой логически связанной множество ролей, которые играют пользователи прецедентов во время взаимодействия с ними. Актерами могут быть как люди, так и другие автоматизированные системы. Развитие прецедентов может осуществляться по-разному. В любой хорошо продуманной системе существуют прецеденты, которые являются специализированными версиями других, более общих, либо входят в состав прочих прецедентов, либо расширяют их поведение. Общее поведение множества прецедентов, допускающее повторное применение, можно выделить, организуя их в соответствии с тремя описанными видами отношений. Всякий прецедент должен выполнять некоторый объем работы. С точки зрения данного актера, прецедент делает нечто представляющее для него определенную ценность, например, вычисляет результат, создает новый объект или изменяет состояние другого объекта. Прецеденты могут быть применены ко всей системе или к ее частям, в том числе и подсистемам или даже к отдельным классам и интерфейсам. В любом случае прецеденты не только представляют желаемое поведение этих элементов, но и могут быть использованы как основа для их тестирования на различных этапах разработки. Прецеденты в применении к подсистемам - это прекрасный источник регрессионных тестов, а в применении к системе в целом - источник комплексных и системных тестов. Подведем некоторые итоги. Хорошо структурированные прецеденты описывают только существенное поведение системы или подсистемы и не являются ни слишком общими, ни слишком специфическими. Утёмов В.В.,2010г. Поток событий, сценарий, кооперация Итак, прецедентом называется описание множества последовательностей действий, включая варианты, выполняемых системой для того, чтобы актер мог получить определенный результат. Графически прецедент изображается в виде эллипса. Нотация прецедента похожа на нотацию кооперации. Другой термин, который достаточно часто используется, процесс. Процесс (process) от начала и до конца описывает последовательность событий, действий и транзакций, требуемых для достижения какоголибо результата. Любой прецедент должен иметь имя, отличающее его от других прецедентов. Оно должно быть уникально внутри объемлющего пакета. Имя прецедента представляет собой текстовую строку. Взятое само по себе оно называется простым именем. К составному имени спереди добавляется имя пакета, в котором находится прецедент. Обычно, при изображении прецедента указывают только его имя. Актер представляет собой связанное множество ролей, которые пользователи прецедентов исполняют во время взаимодействия с ними. Обычно актер, представляет роль, которую в данной системе играет человек, аппаратное устройство или даже другая система. Экземпляр актера представляет собой конкретную личность, взаимодействующую с системой определенным образом. Хотя вы и используете актеров в своих моделях, более того на этапе анализа и формализации требований они являются одной из важнейших составляющих ваших моделей, они не являются частью системы, так как существуют вне ее. Актеров можно связывать с прецедентами только отношениями ассоциации. Ассоциация между актером и прецедентом показывает, что они общаются друг с другом, возможно, посылая или принимая сообщения. Можно использовать механизмы расширения UML для приписывания актеру стереотипа, чтобы создать другую пиктограмму, адекватную поставленным целям. Также можно определить общие типы актеров, а потом специализировать их, создавая разновидности, с помощью отношения специализации. Прецедент описывает, что делает система (подсистема, класс или интерфейс), но не определяет, каким образом она это делает. В процессе моделирования всегда важно разделять внешнее и внутреннее представления. Можно специфицировать поведение прецедента путем описания потока событий в текстовой форме - в виде, понятном для постороннего читателя. В описание необходимо включить указание на то, как и когда прецедент начинается и заканчивается, когда он взаимодействует с актерами и какими объектами они обмениваются. Важно обозначить также основной и альтернативный потоки поведения системы. Для полноты картины дадим полный список определений различных видов прецедентов, которые создаются на различных этапах планирования и анализа. Прецеденты высокого уровня (high-level use case) - это очень краткие описания процессов, обычно состоящие из 2-3 предложений. Язык UML не определяет какой-либо жесткий формат для представления прецедентов, одна из возможных структур описания приведена ниже, хотя в зависимости от требований к документации можно выбрать и другую, что может значительно облегчить дальнейшую работу. Прецеденты высокого уровня описывают процессы очень сжато, обычно в двух или трех предложениях. Такой тип описания очень удобно использовать на начальном этапе формулирования требований к системе для быстрого осознания степени сложности и функций системы. Прецеденты высокого уровня - это лишь краткое описание, имеющее слабое отношение к конкретным проектным решениям. Прецедент Название прецедента (русское и английское). Исполнители Исполнители, работающие с прецедентом. Тип Какой тип (типы прецедентов будут рассмотрены ниже). Описание Словесное описание прецедента, состоящее из двух - трех предложений. Утёмов В.В.,2010г. Рис. Описание прецедента высокого уровня Развернутые прецеденты (expanded use case) представляют собой более подробное описание, чем прецеденты высокого уровня. Они оказываются полезными для углубленного понимания происходящих процессов и требований. Очень часто развернутые прецеденты имеют форму диалога между исполнителем и системой. Развернутый прецедент описывает процесс более детально, чем прецедент высокого уровня. Основной особенностью этого прецедента является наличие раздела "Типичный ход событий", в котором описывается последовательность событий. На этапе формулирования требований в развернутом формате целесообразно представлять лишь наиболее важные и значительные прецеденты, а более подробное описание остальных прецедентов отложить до того цикла разработки, в котором они должны быть реализованы. Жесткого формата на представление развернутых прецедентов тоже нет. Один из вариантов их описания приведен ниже. В верхней части развернутой формы содержится обобщенная информация, большая часть которой берется из соответствующего прецедента высокого уровня. Прецедент Имя прецедента Исполнители Перечень исполнителей (внешних агентов), а также те из них, кто инициирует данный прецедент Цель Цель прецедента Краткое описание Копия содержимого прецедента высокого уровня или некоторая аналогичная обобщенная информация Тип 1. Главный, второстепенный или дополнительный 2. Идеальный или реальный Ссылки Связанные прецеденты и (или) функции системы. Следующий раздел описания "Типичный ход событий", является основной частью развернутого прецедента. В нем отображается содержание подробного диалога между исполнителями и системой. Обратите внимание, что в этом разделе описывается наиболее стандартная, или типичная, последовательность событий - нечто среднее между видами деятельности и успешным завершением процесса. Альтернативные ситуации в типичную последовательность не включаются. ТИПИЧНЫЙ ХОД СОБЫТИЙ Действия исполнителя Отклик системы Пронумерованные действия исполнителей Пронумерованные описания откликов системы Завершающий раздел, "Альтернативный ход событий", должен содержать важные альтернативы или исключения, которые могут возникать в ходе типичной последовательности. Если эти исключения слишком сложны, они могут быть развернуты в собственные прецеденты. Альтернатива Описание Альтернатива, которая может возникнуть в строке с номером. Описание исключения, либо ссылка на соответствующий прецедент По мере уточнения требований к системе потоки событий прецедента будет удобнее записать в графической нотации, используя диаграммы взаимодействий. Обычно для главного потока (типичного хода событий) используют диаграмму последовательностей, а Утёмов В.В.,2010г. для дополнительных (альтернатив) ее варианты. Обратите внимание, что типичный ход событий отделяется от альтернатив. Поскольку прецедент описывает не одну, а множество последовательностей, то выразить все детали интересующего вас прецедента с помощью одной последовательности просто невозможно. Один прецедент, обычно, описывает несколько последовательностей, или сценариев, каждый из которых представляет одну из возможных вариаций данного потока событий. Таким образом, сценарий (scenario) - это некоторая последовательность действий, иллюстрирующая поведение системы. Сценарии находятся в таком же отношении к прецедентами, как экземпляры (объекты) к классам, то есть сценарий - это экземпляр прецедента. Относительно сложная система содержит несколько десятков прецедентов, каждый из которых может разворачиваться в несколько десятков сценариев. Для любого прецедента можно выделить основные сценарии, описывающие важнейшие последовательности, и вспомогательные, описывающие альтернативы. Как уже не раз оговаривалось, прецедент описывает желательное поведение системы (подсистемы, класса или интерфейса), но не определяет их реализацию. Это важнейшая особенность, так как анализ системы, по результатам которого специфицируется ее поведение, по возможности не должен учитывать проблемы реализации, иными словами, как это поведение должно быть материализовано. В конце концов, однако, прецеденты придется реализовывать. Для этого необходимо будет создать сообщество классов и других элементов, в результате совместного поведения которых будет достигнуто желаемое поведение. Такое сообщество. Включая его динамическую и статическую структуру, называется в UML коопераций. Реализацию прецедента с помощью кооперации можно специфицировать явно, использовав отношение реализации. Но чаще всего один прецедент реализуется в точности одной кооперацией, так что явно это отношение описывать ненужно, в некоторых инструментальных средствах даже нет соответствующей пиктограммы, а наоборот некоторые из них, так или иначе, поддерживают это отношение. Нахождение минимального набора хорошо структурированных коопераций, реализующих определенный во всех прецедентах системы поток событий, основная задача системной архитектуры. Организация прецедентов Для организации прецедентов их группируют в пакеты, так же как и классы. Кроме того прецеденты можно организовать, определив между ними отношения обобщения, включения и расширения. Эти отношения применяют, чтобы выделить некоторое общее поведение, извлекая его из других прецедентов, которые его включают, или, наоборот, вариации, поместив такое поведение в другие прецеденты, которые его расширяют. Отношение обобщения между прецедентами аналогично отношению обобщения между классами. Это означает, что прецедент-потомок наследует поведение и семантику своего родителя, может замещать его или дополнять его поведение, а кроме того, может быть подставлен всюду, где появляется его родитель, кроме того, как родитель так и потомок могут иметь конкретные экземпляры. Отношение обобщения между прецедентами изображаются точно так же, как и обобщения между классами - в виде линии с незакрашенной стрелкой. Отношение включения между прецедентами означает, что в некоторой точке базового прецедента инкорпорировано поведение другого прецедента. Включаемый прецедент никогда не существует автономно, а инстанцируется только как часть объемлющего прецедента. Можно считать, что базовый прецедент заимствует поведение включаемых. Благодаря наличию отношения включения удается избежать многократного описания одного и того же потока событий, поскольку общее поведение можно описать в виде Утёмов В.В.,2010г. самостоятельного поведения, включаемого в базовые. Отношение включения является примером делегирования, при котором ряд обязанностей системы описывается в одном месте - во включаемом прецеденте, а остальные прецеденты, когда необходимо включают эти обязанности в свой набор. Отношения включения изображаются в виде зависимости со стереотипом include. Чтобы специфицировать место в потоке событий, где базовый прецедент включает поведение другого, вы просто пишите слово include, за которым следует имя включаемого прецедента. Отношение расширения применяют для моделирования таких частей прецедента, которые пользователь воспринимает как необязательное поведение системы. Тем самым можно разделить обязательное и необязательное поведение. Отношение расширения используется также для моделирования отдельных субпотоков, выполняемых только при определенных обстоятельствах. Наконец, их применяют для моделирования нескольких потоков, которые могут включиться в некоторой точке сценария в результате явного взаимодействия с актером. Отношение расширения изображают в виде зависимости со стереотипом extend. Точки расширения базового сценария перечисляют в дополнительном разделе. Они являются просто метками, которые могут появиться в потоке базового прецедента. Прецедент может содержать несколько точек расширения, причем каждую по несколько раз, идентифицируемых по именам. Если определено несколько точек расширения, то расширяющие прецеденты будут последовательно выполняться в собственных потоках. Организация прецедентов путем выделения общего поведения (отношение включения) и различных вариаций (отношение расширения) является важной составной частью процесса разработки простого сбалансированного и понятного набора прецедентов системы. Немного о других возможностях. Прецеденты являются классификаторами и могут иметь атрибуты и операции, которые изображаются так же, как для классов. Атрибуты можно считать объектами внутри прецедента, которые требуется для описания его внешнего поведения, а операции - действиями системы, необходимыми для описания потока событий. Эти объекты и операции разрешается включать в диаграммы взаимодействия, чтобы специфицировать поведение прецедента. Как и ко всем остальным классификаторам, к прецедентам можно присоединять автоматы. Позволительно расценивать их как еще один способ описания прецедента. Утёмов В.В.,2010г. ЛЕКЦИЯ 6. Типичные приемы анализа прецедентов Поведение элемента Чаще всего с помощью прецедентов моделируют поведение элемента: системы в целом, подсистемы или класса. При этом важно сконцентрироваться исключительно на том, что должен делать элемент, а не на том, как он это будет делать. Подобное применение прецедентов к элементам представляет важность по трем причинам. Во-первых, моделируя поведение элемента с помощью прецедентов, эксперты в предметной области (системные аналитики) могут описать взгляд на систему извне с такой степенью детализации, что разработчики сумеют сконструировать ее внутреннее представление. Прецеденты дают возможность экспертам, системным аналитикам, конечным пользователям и разработчикам общаться на одном языке. Во-вторых, прецеденты позволяют разработчикам понять назначение элемента. Система, подсистема или класс могут быть сложными образованьями с большим числом операций и других составных частей. Описав прецеденты элемента, вы поможете их потенциальным пользователям разобраться в том, как с ними обращаться. Иначе им пришлось бы на собственном опыте постигать, как использовать той или иной элемент. В-третьих, прецеденты являются основой для тестирования каждого элемента на всем протяжении его разработки. Постоянно сравнивая функционирование каждого элемента с прецедентами, вы имеете возможность контролировать корректность его реализации. При этом вы не только получаете источник регрессионных тестов, но и будете вынуждены при появлении нового прецедента данного элемента пересмотреть реализацию, чтобы убедиться в том, что элемент в достаточной степени изменяем. Если это не так. Следует пересмотреть архитектуру. Моделирование поведения элемента осуществляется следующим образом: Идентифицируйте актеров, взаимодействующих с данным элементом. К числу кандидатов в актеры относятся группы, которые требуют определенного поведения для выполнения своих задач или необходимы, прямо или косвенно, для выполнения функций элемента. Организуйте актеров, выделив общие и специализированные роли. Для каждого актера рассмотрите основные пути его взаимодействия с элементом. Рассмотрите также взаимодействия, изменяющие состояния элемента или его окружения или предполагающие реакцию на некоторое событие. Рассмотрите альтернативные (исключительные) способы взаимодействия актеров с элементом. Организуйте выявленное поведение в виде прецедентов, применяя отношения включения и расширения для выделения общего и исключительного поведения. По мере развития модели вы обнаружите тенденцию к объединению прецедентов в концептуально и семантически близкие группы. Напомним, что в UML для моделирования таких групп применяются пакеты. Моделируя прецеденты в UML, помните, что каждый из них должен представлять некоторое четко идентифицируемое поведение системы или ее части. Хорошо структурированный прецедент обладает следующими свойствами: именует простое, идентифицируемое и в некотором смысле атомарное поведение системы или ее части, выделяет общее поведение, извлекая его из всех прецедентов, которые его включают, выделяет вариации, помещая некоторое поведение в другие прецеденты, которые его Утёмов В.В.,2010г. расширяют, описывает поток событий в степени, достаточной для понимания посторонним читателем, описывается с помощью минимального набора сценариев, специфицирующих его нормальную и дополнительную семантику. Изображая прецеденты в UML, пользуйтесь следующими правилами: показывайте только те прецеденты, которые важны для понимания поведения системы или ее части в данном контексте, показывайте только тех актеров, которые связаны с этими прецедентами. Диаграмма прецедентов Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов системы (остальные четыре типа - это диаграммы деятельности, состояний, последовательностей и кооперации). Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая из таких диаграмм показывает множество прецедентов, актеров и отношения между ними. Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов. Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и понимания их внутреннего устройства при обратном проектировании. Диаграммой прецедентов (use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними. Диаграммы прецедентов обладают стандартными свойствами, присущими любой диаграмме, именем и графическим содержанием, которое представляет собой одну из проекций модели. Диаграмма прецедентов отличается от прочих своим конкретным содержанием. Диаграммы прецедентов обычно включают в себя: прецеденты, актеров, отношения зависимости, обобщения и ассоциации, как и все остальные диаграммы, они могут содержать примечания и ограничения. Иногда диаграммы прецедентов помещают в пакеты, применяемые для группирования элементов модели в более крупные блоки, в ряде случаев и экземпляры прецедентов, особенно если надо визуализировать конкретную исполняемую систему. Диаграммы прецедентов, или вариантов использования, применяют для моделирования статического вида системы с точки зрения прецедентов. Это вид охватывает главным образом поведение системы, то есть видимые извне сервисы, предоставляемые системой в контексте ее окружения. При моделировании статического вида системы с точки зрения прецедентов диаграммы использования обычно применяют двумя способами: для моделирования контекста системы и для моделирования требований. Утёмов В.В.,2010г. Моделирование контекста системы Моделирование контекста системы подразумевает, что мы обводим систему воображаемой линией и выявляем актеров, которые находятся за этой линией и взаимодействуют с системой. Диаграммы прецедентов нужны на этом этапе для идентификации актеров и семантики их ролей. Любая система содержит внутри себя какие-либо сущности, в то время как другие сущности остаются за ее пределами. Сущности внутри системы отвечают за реализацию поведения, которого ожидают сущности находящиеся снаружи. Сущности. Находящиеся вне системы и взаимодействующие с ней, составляют ее контекст. Таким образом, контекстом называется окружение системы. UML позволяет моделировать контекст с помощью диаграмм прецедентов, в которых внимание акцентируется на окружающих систему актерах. Важно правильно определить актеров, так как это позволяет описать класс сущностей взаимодействующих с системой. Еще важнее определить, что не является актером, так как при этом ограничивается окружение системы: в нем остаются только те элементы, которые участвуют в ее работе. Моделирование контекста системы состоит из следующих шагов: Идентифицируйте окружающих систему актеров. Для этого необходимо найти группы, которым участие системы требуется для выполнения их задач; группы, которые необходимы для осуществления системой своих функций; группы, взаимодействующие с ее внешними программными и аппаратными средствами, а также группы, выполняющие вспомогательные функции администрирования и поддержки. Организуйте похожих актеров с помощью отношений обобщения/специализации. Введите стереотипы для каждого актера, если это облегчает понимание. Поместите актеров на диаграмму прецедентов и определите способы их связи с прецедентами системы. Тот же метод позволят моделировать и контекст подсистемы. Вспомните, что элемент. Который на одном уровне абстракции выглядит как система, часто становится подсистемой на другом, более высоком уровне абстракции. Моделирование контекста подсистемы может пригодиться при построении системы из нескольких взаимосвязанных частей. Моделирование требований к системе Моделирование требований к системе предполагает указание на то, что система должна делать с точки зрения внешнего наблюдателя, независимо от того, как она должна это делать. Диаграммы прецедентов нужны здесь для специфицирования желаемого поведения системы. Они позволяют рассматривать всю систему как "черный ящик": вы видите все, что находится вне ее, наблюдаете за ее реакцией на события, но ничего не знаете о внутреннем устройстве. Требование (requirement) - это особенность проекта, свойство или поведение системы. Приступая к сбору требований, вы как бы описываете условия контракта, заключаемого между системой и сущностями вне ее, в котором декларируете, что система должна делать. При этом, как правило, вас заботит не то, как именно система будет выполнять поставленные перед ней задачи, а только то, что она будет делать. Хорошо спроектированная система должна полностью выполнять все требования, причем делать это предсказуемо и надежно. Ее создание начинается с соглашения о том, каково ее Утёмов В.В.,2010г. назначение, хотя в ходе разработки понимание требований будет постоянно изменяться. Аналогично при работе с готовой системой понимание того. Как она себя ведет, имеет принципиальное значение для ее правильного использования. Требования можно выразить по-разному, от неструктурированного текста до выражений на формальном языке, или, например, с помощью примечаний. Большая часть функциональных требований к системе, или даже все они, может быть выражена в виде прецедентов использования, в чем помогают диаграммы прецедентов UML. Моделирование требований осуществляется следующим образом: Установите контекст системы, идентифицировав окружающих ее актеров. Для каждого актера рассмотрите поведение, которого он ожидает или требует от системы. Назовите эти общие варианты поведения как прецеденты. Выделите общее поведение в новые прецеденты, которые будут использоваться другими; выделите вариации поведения в новые прецеденты, расширяющие основные потоки событий. Смоделируйте эти прецеденты, актеров и отношения между ними на диаграмме прецедентов. Дополните прецеденты примечаниями, описывающими нефункциональные требования, некоторые из таких примечаний можно присоединить к системе в целом. Создавая диаграммы прецедентов в UML, помните, что каждая из них является всего лишь графическим представлением статического вида системы с точки зрения вариантов использования. Это означает, что ни одна диаграмма прецедентов, взятая в отдельности, не может, да и не охватывает этот вид целиком. В совокупности диаграммы прецедентов дают полное представление о виде системы с точки зрения вариантов использования, а каждая из них в отдельности - только об одном из его аспектов. Хорошо структурированная диаграмма прецедентов обладает следующими свойствами: акцентирует внимание на одном аспекте статического вида системы с точки зрения вариантов использования, содержит только такие прецеденты и актеров, которые важны для понимания этого аспекта, содержит только такие детали, которые соответствуют данному уроню абстракции (следует показывать только те дополнения, которые необходимы для понимания системы), не настолько лаконична, чтобы ввести читателя в заблуждение относительно важной семантики. Группа развертывания сообщает о том, как программный комплекс разбита пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика. Утёмов В.В.,2010г. ЛЕКЦИЯ 7. Введение моделирования в унифицированный процесс Предварительные замечания Унифицированный язык моделирования (UML - Unified Modeling Language) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем. UML разработан таким образом, чтобы удовлетворять потребности при моделировании любых систем: от информационных систем масштаба предприятия до распределенных Webприложений и даже встроенных систем реального времени. Это выразительный язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост для понимания и использования. Изучение UML мы начнем с его концептуальной модели, которая содержит три основные элемента языка: базовые конструкции, правила, определяющие, каким образом эти конструкции могут сочетаться между собой, и некоторые общие механизмы языка. Несмотря на свои достоинства, UML - это всего лишь язык. Он является одной из составляющих программного обеспечения, и не более этого. Хотя UML не зависит от моделируемой реальности, лучше всего применять его, когда процесс моделирования основан на рассмотрении текстового описания процессов, происходящих в предметной области, является итеративным и пошаговым, а сама система имеет четко выраженную архитектуру. Таким образом он идеально подходит для Унифицированного процесса разработки. UML - это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем. Напомним что, артефакт (artifact) диаграмма, документ, модель, закон и т. д. - нечто, описывающее определенное понятие предметной области. Как и любой язык, UML состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. В языке моделирования словарь и правила ориентированны на концептуальное и физическое представление системы. Язык моделирования, подобный UML, является стандартным средством для составления "чертежей" программного обеспечения. Моделирование необходимо для понимания системы. Обычно, при этом единственной модели никогда не бывает достаточно. Наоборот, для понимания практически любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки. Словарь и правила такого языка, как UML, объясняют, как создавать и читать хорошо определенные модели, но ничего не сообщают, какие модели и в каких случаях нужно создавать. Эта задача всего процесса разработки программного обеспечения. Организация такого процесса дело сугубо индивидуальное в рамках различных программистских компаний, фирм и отдельных групп разработчиков программного обеспечения. Но хорошо организованный процесс должен показать вам, какие требуются артефакты, какие ресурсы необходимы для их создания, как можно использовать эти артефакты для того, чтобы оценить выполненную работу и управлять проектом в целом. Утёмов В.В.,2010г. UML - это язык визуализации Характерной особенностью мышления большинства программистов является то, что размышления о том, как реализовать проект, для нас практически эквивалентны написанию кода для этого проекта. Если мы думаем о проекте - значит, мы его кодируем. Конечно, некоторые вещи лучше всего выражаются непосредственно в коде на какомнибудь языке программирования, ведь листинг программы - это самый простой и короткий путь для записи алгоритмов и вычислений. А ведь даже в этих случаях программист занимается моделированием, хотя и неформально. И такой подход чреват рядом неприятностей. Во-первых, обмениваться мнениями по поводу построенной модели можно только тогда, когда все участники говорят на одном языке. А это означает, что ваша компания не сможет принять великолепного программиста на C, если она использует Delphi! Или вашему новичку будет совсем непросто догадаться, о чем идет речь. Во-вторых, нельзя получить представление об некоторых аспектах программных систем без модели, границы которой выходят за рамки текстового языка программирования. Например, назначение иерархии классов можно, конечно, понять, если внимательно изучить код каждого класса, а вот воспринять всю структуру сразу целиком ни за что не получится. Аналогично изучение кода системы не позволит составить полное представление о физическом распределении и возможных миграциях объектов в Web-приложении. В третьих, если ваш системный аналитик никогда не воплощал в явной форме разработанные модели, эта информация будет навсегда утрачена, если его вдруг переманят в конкурирующую фирму. В лучшем случае результаты его анализа можно будет только частично воссоздать исходя из реализации. Использование UML позволяет решить эти проблемы. Этот язык моделирования - это не просто набор графических символов. За каждым из них стоит определенная семантика, а это означает, что модель, написанная одним разработчиком, может быть однозначно интерпретирована другим, и не обязательно человеком, в роли второго разработчика может выступать и некоторое инструментальное средство. Конец первой проблемы. Некоторые особенности системы лучше всего моделировать в виде текста, другие графически. Практика свидетельствует, что во всех интересных системах существуют структуры. Которые невозможно представить с помощью одного языка программирования. А UML - графический язык, и это решает нашу вторую проблему. Ну и наконец, явная модель облегчает общение, это очевидно, а значит и третья проблема отпадает сама собой. UML - это язык специфицирования В данном контексте это означает построение точных, недвусмысленных и полных моделей. UML позволяет специфицировать все существенные решения, которые касаются анализа, проектирования и реализации, принимающиеся в процессе разработки и развертывания системы программного обеспечения. UML - это язык конструирования Хотя он и не является языком визуального программирования. Но модели, которые создаются с его помощью, могут быть непосредственно переведены на любой объектноориентированный язык программирования. Те понятия, которые удобнее представлять графически, так и подставляются в UML, те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования. Утёмов В.В.,2010г. Такое отображение модели на язык программирования позволяет выполнить прямое проектирование, т. е. генерацию кода по модели UML в какой-то конкретный язык. Можно решить и обратную задачу: реконструировать модель по существующей реализации. Такое обратное проектирование не представляет собой ничего необычного. Если вы не закодировали информацию в реализации, то она теряется при прямом переходе от моделей к коду. А поэтому для обратного проектирования необходимы как инструментальные средства, так и непосредственное участие программиста или системного аналитика. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между этими двумя представлениями проекта. Кроме того, помимо прямого отображения в языки программирования UML в силу своей выразительности и однозначности позволяет непосредственно выполнять модели, имитировать поведение системы и контролировать действующие системы. UML - это язык документирования Организация, серьезно работающая на рынке программных средств, кроме непосредственного написания программного кода производит и некоторые другие артефакты, в том числе следующие: требования к системе; архитектуру; проект; исходный код; проектные планы и сметы; тесты; прототипы; версии и другие. В зависимости от принятой методики разработки выполнение одних работ производится более формально, чем других. Перечисленные выше артефакты - это не просто поставляемые части проекта; они необходимы, прежде всего, для управления, для оценки результатов, а также как средство общения между членами коллектива во время работы над проектом и после его развертывания. UML позволяет решить проблему документирования системной архитектуры и ее деталей, предлагает язык для формального определения требований к системе и определения тестов и, наконец, предоставляет средства для моделирования работ на этапе планирования проекта и управления версиями. Язык UML предназначен, прежде всего, для разработки программных систем. Его использование особенно эффективно в следующих областях: информационные системы масштаба предприятия; банковские и финансовые услуги; телекоммуникации; транспорт; оборонная промышленность, авиация, космонавтика; торговые системы; медицинская электроника; наука; распределенные Web-системы. Утёмов В.В.,2010г. Сфера применения UML не ограничивается моделированием программного обеспечения. Его выразительность позволяет моделировать, например, документооборот в юридических системах, структуру и функционирование системы обслуживания пациентов в больницах, осуществлять проектирование аппаратных средств. Для понимания UML необходимо усвоить основные принципы, положенные в структуру этого языка. Этих принципов всего три, а сам язык как бы состоит из трех частей: основные конструкции языка, правила их взаимодействия и некоторые общие для всего языка механизмы. Освоив эти идеи, вы сумеете читать модели на UML и самостоятельно их разрабатывать, естественно, вначале не очень сложные. По мере приобретения навыков работы с языком вы научитесь использовать и более развитыми его возможностями. Словарь UML включает три вида основных конструкций: сущности - абстракции, являющиеся основными элементами модели; отношения - связи между сущностями; диаграммы, группирующие представляющие интерес множества сущностей и отношений. Теперь обо всем более подробно. Сущности UML В UML имеется четыре типа сущностей: структурные; поведенческие; группирующие; аннотационные. Сущности являются основными объектно-ориентированными элементами языка. С их помощью можно создавать корректные модели. Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Как уже упоминалось выше, существует семь разновидностей структурных сущностей, естественно, что все они нашли свое отражение в UML. Напомним определения структурных сущностей и дадим описание, соответствующего им графического образа UML. Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции, например как это показано на рисунке: ClassName -PrivateAttribute : char #ProtectedAttribute +PublicAttribute +Operation1(in S : String) +Operation2() Рис. Пиктограмма класса Утёмов В.В.,2010г. Интерфейс (interface) - это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент. На диаграммах интерфейс изображается в виде круга, под которым указывается его имя, как это показано на рис. Интерфейс очень редко, практически никогда, существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту. Рис. Пиктограмма интерфейса Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых. Графически кооперация изображается в виде эллипса, который ограничивается пунктиром, внутри обычно заключено только имя, пример на рис. Рис. Пиктограмма кооперации Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Графически прецедент тоже изображается в виде эллипса, только ограниченного непрерывной линией, обычно содержащего только его имя, как показано на рис. Рис. Пиктограмма прецедента Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Графически активный класс изображается также как и простой класс, но ограничивается прямоугольником, который рисуется жирной линией, и включает имя, атрибуты и операции, пример на рис. ClassName -PrivateAttribute : char #ProtectedAttribute +PublicAttribute +Operation1(in S : String) +Operation2() Рис. Пиктограмма активного класса Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя, как показано на рис. Утёмов В.В.,2010г. Рис. Пиктограмма компонента Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Графически для изображения узла используется куб, обычно содержащий только имя узла. Рис. Пиктограмма узла Перечисленные семь базовых элементов: классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы - являются основными структурными сущностями, которые могут быть использованы в модели UML. Существуют и другие разновидности сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов). Теперь определим другие типы сущностей, о которых мы не упоминали раньше. Поведенческие сущности (behavioral things) являются динамическими составляющими модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей. Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщениями) и связи (между объектами). Графически сообщение изображается в виде стрелки. Над которой почти всегда пишется имя соответствующей операции, как показано на рис. Рис. Пиктограмма сообщения Автомат (state machine) - алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автоматов описываются поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы из одного состояния в другое, события - сущности инициирующие переходы и виды действий - реакция на переходы. Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, промежуточные состояния. Рис. Пиктограмма состояния Утёмов В.В.,2010г. Взаимодействия и автоматы являются основными поведенческими сущностями, входящими в модель UML. Семантически они часто бывают связаны с различными структурными элементами, в первую очередь с классами, кооперациями и объектами. Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет. Пакеты (packages) представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить структурные, поведенческие и другие группирующие сущности. В отличие от компонентов, которые реально существуют во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только в процессе разработки. Для изображения пакета используется пиктограмма папки с закладкой, содержащей обычно только имя, но иногда и содержимое, см. рис. Рис. Пиктограмма пакета Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. Примечание (note) - это просто символ для изображения комментариев или ограничений, присоединенный к элементу или группе элементов. Графически примечание изображается в виде прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как показано на рис. Рис. Пиктограмма примечания Этот элемент является основной аннотационной сущностью, которую вы можете использовать в модели UML. Чаще всего примечания используют, чтобы снабдить диаграммы комментариями или ограничениями, которые можно выразить в виде неформального или формального текста. Существуют варианты этого элемента, например требования, в которых описывают некоторое желательное поведение системы с точки зрения внешней по отношению к модели. Отношения UML В языке UML определены четыре типа отношений: зависимость; ассоциация; обобщение; реализация. Утёмов В.В.,2010г. Эти отношения являются основными связующими конструкциями в UML и применяются для построения корректных моделей. Ну а теперь, по порядку. Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Графически для изображения зависимости используют пунктирную линию, обычно со стрелкой, которая может содержать метку (см. рис. ). Рис. Пиктограмма зависимости Ассоциация (association) - структурное отношение, описывающее совокупность связей, где под связью понимается некоторая смысловая связь между объектами. Разновидностью ассоциации является агрегирование (aggregation) - так называется структурное отношение между целым и его частями. Графически ассоциация изображается в виде линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей. На рис. Показан пример отношений этого вида. Рис. Пиктограмма ассоциации Обобщение (generalization) - это отношение "специализация/обобщение", при котором объект специализированного элемента (проще говоря, потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектноориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка. Как показано на рис. Рис. Пиктограмма обобщения И, наконец, реализация (realization) - это семантическое отношение между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях: вопервых, между интерфейсами и реализующими их классами или компонентами, а вовторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости (см. рис. ). Рис. Пиктограмма реализации Мы описали четыре элемента UML, которые являются основными типами отношений в моделях UML. Существую также их варианты, например уточнение (refinement), трассировка (trace), включение и расширение для зависимостей. Утёмов В.В.,2010г. Диаграммы UML Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации. Основная цель диаграмм - визуализация разрабатываемой системы с разных точек зрения. Диаграмма - в самом общем смысле некоторый срез системы. Обычно, за исключением самых простых моделей, диаграммы дают свернутое представление элементов, из которых состоит разрабатываемая система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый часто встречающийся вариант), или не присутствовать ни в одной (очень редко). Согласно теории диаграммы могут содержать любые комбинации сущностей, однако в практике моделирования применяется сравнительно небольшое количество типовых комбинаций, каждая из которых соответствует одному из пяти наиболее необходимых видов, составляющих архитектуру программной системы. Таким образом, в UML определены девять типов диаграмм. Диаграммы классов (class diagram), на которых показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектноориентированных систем этот тип диаграмм использует наиболее часто. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов. Диаграммы объектов (object diagram), на которых представляются объекты и отношения между ними. Это статические снимки экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы сточки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию. Диаграммы прецедентов (use case diagram), на которых представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения возможностей ее использования. Это вид диаграмм особенно важен при организации и моделирования поведения системы. Диаграммы взаимодействия, на которых представлены связи между объектами, показаны, в частности, сообщения, которыми объекты могут обмениваться. Обычно рассматриваются два частных случая это вида диаграмм: диаграммы последовательностей (sequence diagram), которые отражают временную упорядоченность сообщений, и диаграммы кооперации (collaboration diagram), на которых показана структурная организация обменивающихся сообщениями объектов. Эти виды диаграмм являются изоморфными, то есть свободно могут быть трансформированы друг в друга. Диаграммы состояний (statechart diagram) представляют автомат, включающий в себя состояния, переходы, события и виды действий. Эти диаграммы относятся к динамическому виду системы, особенно важна их роль при моделировании поведения интерфейса, класса или кооперации. Они заостряют внимание на поведении объекта, которое в свою очередь зависят от последовательности событий, что очень полезно при моделировании реактивных систем. Диаграммы деятельности (activity diagram) - это частный случай диаграмм состояний. На диаграмме этого типа представляются переходы потока управления от одной Утёмов В.В.,2010г. деятельности к другой внутри системы. Этот вид диаграмм относится к динамическим представлениям системы, и является наиболее полезным при моделировании ее функционирования, так как отражает передачу потока управления между объектами. Диаграммы компонентов (component diagram), на которых представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статистическому виду системы с точки зрения реализации. Они могут быть связаны с диаграммами классов в силу очень простой причины: один компонент обычно отображается на один или несколько классов, интерфейсов или коопераций. Диаграммы развертывания (deployment diagram), на которых представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов. Мы рассмотрели неполный список возможных диаграмм, применяемых в UML. Некоторые инструментальные средства позволяют генерировать и другие диаграммы, но перечисленные девять встречаются в практике моделирования чаще всего. Правила языка UML Конструкции UML нельзя объединять друг с другом в произвольном порядке. Как и в любом другом языке, в UML существует набор правил, которые определяют, как должна выглядеть хорошо оформленная модель. Под хорошо оформленной моделью понимается модель семантически согласованная и находящаяся в гармонии с другими моделями, которые с ней связаны. Семантические правила, которые имеются в UML, позволяют корректно и однозначно определять: имена, которые можно давать сущностям, отношениям и диаграммам; области действия - контексты, в которых имя имеет некоторое значение; видимость, когда имена видимы и могут использоваться другими элементами; целостность, как элементы должны правильно и согласованно соотноситься друг с другом; выполнение, что означает выполнить или имитировать некоторую динамическую модель. Модели, которые создаются в процессе разработки программных продуктов, со временем имеют свойство эволюционировать, и могут неоднозначно рассматриваться разными членами команды разработчиков в разное время. По этой причине создаются не только хорошо оформленные модели, но и такие, которые: содержат скрытые элементы (ряд элементов не показывают, чтобы упростить восприятие); неполные (отдельные элементы пропущены); несогласованные (целостность модели не гарантируется). Появление такого рода моделей неизбежно в процессе разработки, пока не все нюансы системы прояснились в полной мере. Правила языка UML побуждают, хотя явно и не требуют, в ходе работы над моделью решать наиболее важные вопросы анализа, Утёмов В.В.,2010г. проектирования и реализации, в результате, в конце концов, модель со временем становится хорошо оформленной. Общие механизмы языка UML Моделирование упрощается и ведется более эффективно, если придерживаться некоторых соглашений. Работу с UML существенно облегчает последовательное использование общих механизмов, которые мы сейчас перечислим: спецификации (specifications); дополнения (adornments); принятые деления (common divisions); механизмы расширения (extensibility mechanisms). UML является не просто графическим языком, за каждой частью его системы графической нотации состоит спецификация, содержащая текстовое представление соответствующей конструкции языка. Например, пиктограмме класса соответствует спецификация, которая полностью описывает его атрибуты, операции (совместно с полными сигнатурами) и поведение, хотя визуально, на диаграмме пиктограмма часто отражает только малую часть этой совокупности. Более того, в модели может присутствовать другое представление этого класса, отражающее совершенно иные его аспекты, но тем не менее соответствующее спецификации. Таким образом, графическую нотацию UML используют для визуализации системы, а с помощью спецификаций описывают ее детали. Эта двоякость дает с одной стороны, возможность построения моделей инкрементным, то есть пошаговым образом. Сначала нарисовать диаграмму, а потом добавить семантику в спецификацию модели. И наоборот, начать со спецификации (возможно, применив обратное проектирование к реальному проекту), а потом уже рисовать диаграммы. Спецификации UML определяют семантический задний план, который полностью включает в себя составные части всех моделей системы, и обеспечивает согласование их между собой. В этом разрезе диаграммы UML можно считать визуальными проекциями на это задний план, при этом каждая из них показывает один или несколько значимых аспектов системы. Практически каждый из элементов UML имеет соответствующее ему уникальное графическое представление, которое дает визуальную картину о самых важных аспектах этого элемента. Нотация класса содержит самые важные его характеристики: имя, атрибуты и операции. Спецификация класса может содержать и другие детали, например, видимость атрибутов и операций, комментарии или указание на то, что класс является абстрактным. Многие из этих деталей можно визуализировать в виде графических или текстовых дополнений к стандартному прямоугольнику, который изображает класс. При моделировании объектно-ориентированных систем реальность делится с учетом, по крайней мере, двух методов. Во-первых, существует деление на классы и объекты. Класс - это абстракция, а объект конкретное воплощение этой абстракции. В связи с этим, практически все конструкции языка характеризуются дихотомией "класс/объект". Например, имеются прецеденты и экземпляры прецедентов, компоненты и экземпляры компонентов, узлы и экземпляры узлов и т. д. В графическом представлении для объекта принято использовать тот же символ, что и для класса, а название подчеркивать. Во-вторых, существует деление на интерфейс и его реализацию. Интерфейс декларирует обязательства, а реализация представляет конкретное воплощение этих обязательств и обязуется точно следовать объявленной семантике интерфейса. А в связи с этим, почти Утёмов В.В.,2010г. все конструкции UML характеризуются дихотомией "интерфейс/реализация". Например, прецеденты реализуются кооперациями, а операции - методами. UML - это стандартный язык разработки моделей программных систем, но ни один замкнутый язык не в состоянии охватить нюансы всех возможных моделей в различных предметных областях. Поэтому UML является открытым языком, то есть допускает контролируемые расширения. Механизмы расширения UML включают: стереотипы (stereotype), которые расширяют словарь UML, позволяя на основе существующих блоков языка создавать новые, специфичные для решения конкретной проблемы.; помеченные значения (tagged value), которые расширяют свойства основных конструкций UML, позволяя включать новую информацию в спецификацию элемента; ограничения (constraints), которые расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила. Совместно эти три механизма расширения языка позволяют модифицировать UML в соответствии с потребностями вашего проекта или особенностями технологии разработки в вашей команде. Кроме того, они дают возможность адаптировать UML к новым технологиям разработки программного обеспечения, например к вероятному появлению более мощных языков распределенного программирования. С помощью механизмов расширения можно создавать новые конструкции языка, модифицировать существующие и даже изменять их семантику. Однако во всем нужно чувство меры: за расширениями важно не забывать одну из главных целей UML - возможность обмена информацией между разными группами разработчиков. Утёмов В.В.,2010г. ЛЕКЦИЯ 8. Системы и модели Предварительные замечания UML - это графический язык для визуализации, специфицирования, конструирования и документирования артефактов программной системы. Эго используют для того, чтобы моделировать системы. Модель - это упрощение реальности, абстракция, которая создается для лучшего понимания системы. Система, очень часто разложенная на ряд подсистем, - это множество элементов, организованных некоторым образом для выполнения определенной цели. Системы описывается набором моделей, по возможности рассматривающих ее с различных точек зрения. Важными составляющими частями модели являются, прежде всего, структурные сущности. В UML все абстракции программной системы организуются в виде моделей, каждая из которых представляет относительно независимый, но важный аспект разрабатываемой системы. Для визуализации интересующих вас наборов этих абстракций можно использовать диаграммы. Рассмотрение различных представлений архитектуры системы особенно полезно для удовлетворения потребностей различных участников процесса разработки программного обеспечения. В своей совокупности эти модели дают полное представление о структуре и поведении системы. В больших системах множество элементов можно подвергнуть декомпозиции на более мелкие подсистемы, каждая из которых на более низком уровне абстракции может рассматриваться как отдельная система. В UML предусмотрены средства для графического представления систем и подсистем. Такая нотация позволяет визуализировать декомпозицию системы на меньшие подсистемы. Изображаются система и подсистема в виде пиктограммы стереотипного пакета. Для моделей и видов нет специального графического представления, так как эти сущности - объект манипуляции инструментальных программ, которыми пользуются разработчики для организации представления различных видов системы, в самом плохом случае - это просто листы бумаги с нарисованными на них диаграммами. Системы и подсистемы. Модели и представления Система (system), возможно разложенная на ряд подсистем, - это множество элементов, организованных некоторым образом для выполнения определенной цели. Она описывается набором моделей, зачастую с различных точек зрения. Подсистема (subsystem) - это объединение элементов, ряд которых составляет спецификацию поведения, предложенного другими ее элементами. Система и подсистема изображаются в виде пиктограммы стереотипного пакета. Напомним, что модель (model) - это упрощение реальности, абстракция, которая создается для лучшего восприятия системы. Вид или представление (view) - это модель, рассматриваемая под определенным углом зрения: в ней отражены одни сущности и опущены другие, которые с данной точки зрения не представляют интереса. Система, собственно, и является той самой сущностью, для которой вы разрабатываете и строите модели. Система охватывает все артефакты, составляющие эту сущность, включая модели и элементы этих моделей, такие как классы, интерфейсы, компоненты, узлы и Утёмов В.В.,2010г. связи между ними. Все, что необходимо для визуализации, специфицирования, конструирования и документирования системы, является ее частью, а все, что для этой цели не требуется, лежит за пределами системы. В UML система изображается в виде стереотипного пакета, как показано на рис. . Рис. Системы и подсистемы. Являясь стереотипным пакетом, система владеет некоторыми элементами. Если рассмотреть систему изнутри, то можно увидеть все ее модели и отдельные элементы, в том числе и диаграммы, которые очень часто будут разложены на более мелкие подсистемы. Подсистемы - это образования, которые используются для декомпозиции системы на более простые, слабо зависящие друг от друга составляющие. То, что на одном уровне абстракции выглядит системой, на другом, более высоком, может рассматриваться как подсистема. В UML подсистема изображается в виде пиктограммы стереотипного пакета (см. рис. ). Основное отношение между системами и подсистемами - это агрегирование. Система (целое) может состоять из нуля и более подсистем (частей). Но между системами и подсистемами допускается существование отношения обобщения. С его помощью вы можете моделировать семейства систем и подсистем, ряд которых представляет общий случай, а другие являют собой специализацию для конкретных условий. Таким образом, система - это сущность самого высокого уровня в данном контексте, а составляющие ее подсистемы, разбивают эту сущность на непересекающиеся части. Модель, согласно определению представленному выше, - это упрощение реального мира, реальность в ней описывается в контексте моделируемой системы. Проще говоря, модель - это абстракция системы. В то время как подсистема представляет собой разбиение множества элементов большей системы на независимые части, модель - это разбиение множества абстракций, которые вы используете для визуализации, специфицирования, конструирования и документирования этой системы. Обратите внимание на это тонкое, но принципиально важное различие. Вы разбиваете систему на подсистемы, чтобы их можно было разрабатывать и развертывать в некоторой степени независимо друг от друга. Абстракции же системы и подсистемы вы раскладываете на модели, чтобы лучше понять, что именно вы собираетесь разрабатывать и развертывать. Модель - это разновидность пакета. Явно моделировать ее приходится не так уж часто, и поэтому специального графического символа для моделей в рамках UML не предусмотрено. Однако инструментальные средства должны каким-то образом манипулировать моделями, обычно, для этих целей они использую нотацию пакетов. Будучи пакетом, модель владеет некоторыми элементами. Модели, ассоциированные с системой и подсистемой, образуют исчерпывающее разбиение ее элементов. Это означает, что каждый элемент принадлежит одному и только одному пакету. Как правило, артефакты системы и подсистемы организуются в несколько неперекрывающихся моделей. Все возможные модели охватываются пятью представлениями, или видами архитектуры программного обеспечения, о которых мы говорили в начале нашего курса. Модель может содержать так много артефактов, что в большой системе всю их совокупность нельзя охватить сразу. Вид системной архитектуры можно представлять себе как одну из проекций модели. Для каждой модели предусмотрен ряд диаграмм, с помощью которых удобно рассматривать, принадлежащие ей сущности. Представление охватывает подмножество сущностей, входящих в состав модели. Границы моделей представления обычно пересекать не могут. UML не диктует вам, какими именно моделями следует пользоваться для визуализации, специфицирования, конструирования и документирования системы, хотя Рациональный Унифицированный Процесс предлагает некоторое множество разумных моделей, проверенное на практике. Специфицирование отношений между такими важными элементами, как классы, интерфейсы, компоненты и узлы, - это важная структурная составляющая модели. Для Утёмов В.В.,2010г. управления артефактами процесса разработки сложных систем, многие из которых существуют более чем в одной версии, большую роль играет описание отношений между такими элементами, как документы, диаграммы и пакеты, присутствующие в разных моделях. В UML концептуальные отношения между элементами, существующими в различных моделях, можно моделировать с помощью отношения трассировки (trace relationship). Трассировку нельзя применять к элементам в рамках одной модели. Трассировка представляется в виде стереотипной зависимости. Часто можно не обращать внимание на направление такой зависимости, хотя обычно стрелка указывает на более ранний или более специфичный элемент. Очень часто отношениями трассировки пользуются для того, чтобы показать путь от требований к реализации, на котором лежат все промежуточные артефакты, а также для отслеживания версий. Как правило вместо явного изображения трассировки удобнее использовать гиперссылки. Моделирование системной архитектуры Наиболее распространенный случай применения систем и моделей - это организация элементов, используемых с целью визуализации, специфицирования, конструирования и документирования архитектуры системы. При этом затрагиваются практически все артефакты, встречающиеся в процессе разработки программного обеспечения. Моделируя системную архитектуру, вы собираете в единое целое решения, принятые относительно требований к системе, ее логических и физических элементов. Моделируются структурные и поведенческие аспекты системы, образцы, формирующие ее различные представления. Наконец, следует обратить внимание на стыковку подсистем и трассировку решений, начиная от формирования требований до этапа развертывания. Моделирование системной архитектуры производится следующим образом: Идентифицируйте сущности, которые вы будете использовать для представления архитектуры. Чаще всего это виды с точки зрения прецедентов. Процессов, реализации и развертывания. Специфицируйте контекст системы, включая окружающих ее актеров. При необходимости разложите систему на элементарные подсистемы. При моделировании системы в целом и ее подсистем выполняются следующие действия: Специфицируйте вид системы с точки зрения вариантов ее использования или прецедентов, которые описывают поведение системы таким образом, каким оно представляется конечным пользователям, аналитикам и тестеров. Для моделирования статических аспектов примените диаграммы прецедентов, а для моделирования динамических - диаграммы взаимодействия, состояний и деятельности. Специфицируйте вид системы с точки зрения проектирования, в который входят классы, интерфейсы и кооперации, формирующие словарь предметной области и предлагаемого решения. Для моделирования статических аспектов применяйте диаграммы классов и объектов, а для моделирования динамических - диаграммы последовательностей, состояний и деятельности. Специфицируйте вид системы с точки процессов, в который входят процессы и нити, формирующие механизмы параллельности и синхронизации в системе. Используйте те же диаграммы, что и для вида с точки зрения проектирования, но основной внимание уделите активным классам и объектам, которыми, собственно говоря, в UML и представлены процессы и нити. Утёмов В.В.,2010г. Специфицируйте вид системы с точки зрения реализации, в который входят компоненты, используемые для сборки и выпуска готовой физической системы. Для моделирования статических аспектов примените диаграммы компонентов, а для моделирования динамических - диаграммы взаимодействия, состояний и деятельности. Специфицируйте вид системы с точки зрения развертывания, который содержит узлы, формирующие топологию аппаратных средств, на которых выполняется система. Для моделирования статических аспектов примените диаграммы развертывания, а для моделирования динамических - диаграммы взаимодействия, состояний и деятельности. Смоделируйте архитектурные образцы (паттерны) и образцы проектирования с помощью коопераций. Образец (pattern) - это типичное решение типичной проблемы в данном контексте. Помните, что системная архитектура не рождается в ходе единичного акта творения. Напротив, хорошо структурированный процесс применения UML подразумевает последовательное уточнение архитектуры на основе анализа прецедентов, итеративное и инкрементное (вспомните основные положения Рационального Унифицированного Процесса). Если не брать в расчет простейшие системы, вам необходимо будет управлять версиями системных артефактов. Для представления решений о версиях каждого элемента можно воспользоваться механизмами расширения UML, в частности помеченными значениями. Различные представления системы При моделировании системы с различных точек зрения вы фактически конструируете ее сразу в нескольких измерениях. Правильный выбор совокупности видов или представлений позволит задать нужные вопросы, касающиеся системы и выявить риск, который необходимо учесть. Если же виды выбраны плохо или вы сосредоточились только на одном из них в ущерб остальным, то возрастает опасность не заметить или отложить на будущее такие вопросы, пренебрежение которыми рано или поздно поставит под угрозу весь проект. Моделирование системы с использованием различных представлений осуществляется следующим образом: Решите, какие именно виды лучше всего отражают архитектуру системы и возможный технический риск, связанный с проектом. При этом стоит с описанных выше пяти взглядов на архитектуру. В отношении каждого из выбранных видов определите, какие артефакты необходимо создать для отражения его наиболее существенных деталей. Эти артефакты по большей части будут состоять из различных диаграмм UML. В ходе планирования процесса решите, какие из диаграмм удобнее всего превратить в инструмент контроля, формального или неформального, за разработкой системы. Эти диаграммы вы будете периодически корректировать и сохранять в составе проектной документации. На всякий случай сохраняйте даже забракованные диаграммы. Они могут пригодиться при анализе результатов ваших действий и для экспериментов по изменению каких-либо рабочих параметров. Утёмов В.В.,2010г. Допустим, если вы моделируете простое приложение, выполняемое на одном компьютере, могут потребоваться только перечисленные диаграммы: вид с точки зрения вариантов использования - диаграммы прецедентов; вид с точки зрения проектирования - диаграммы классов для структурного моделирования и диаграммы взаимодействия для моделирования поведения; Если же разрабатываемая система реактива или относится к управлению рабочим процессом, то для моделирования ее поведения понадобятся соответственно диаграммы состояний и действий. Если система построена на архитектуре "клиент/сервер", то стоит включить в работу диаграммы компонентов и развертывания для моделирования конкретных физических деталей реализации. Наконец моделируя сложную распределенную систему, используйте все имеющиеся в UML диаграммы, Они позволяют выразить ее архитектуру и связанный с проектом технический риск. Вам потребуется следующее: вид с точки зрения прецедентов - диаграммы прецедентов и диаграммы действий (для моделирования поведения); вид с точки зрения проектирования - диаграммы классов (структурное моделирование), диаграммы взаимодействия и диаграммы состояний (моделирование поведения); вид с точки зрения процессов - снова диаграммы классов (структурное моделирование) и диаграммы взаимодействия (моделирование поведения); вид с точки зрения реализации - диаграммы компонентов; вид с точки зрения развертывания - диаграммы развертывания. То, что одном уровне абстракции выглядит как система, на другом, более высоком, представляется подсистемой. Аналогичным образом, то что на одном уровне является подсистемой, вполне может рассматриваться как полноценная система группой проекта, ответственной за ее создание. Такая иерархия наблюдается во всех сложных системах. По мере возрастания сложности систем вы встаете перед необходимостью ее декомпозиции на более простые подсистемы, каждую из которых можно разрабатывать отдельно, а затем постепенно объединять их. Разработка подсистем выглядит в точности так же, как и разработка всей системы. Моделирование системы или подсистемы осуществляется следующим образом: Идентифицируйте основные функциональные составляющие системы, которые можно разрабатывать, выпускать и развертывать до некоторой степени независимо. На результаты этого разбиения системы часто влияют технические, юридические и организационные факторы; Для каждой подсистемы специфицируйте ее контекст, так же как это делается для системы в целом при этом число актеров, окружающих систему включаются все соседние подсистемы, поэтому необходимо проектировать их совместную работу; Смоделируйте архитектуру каждой подсистемы так же, как это делается для всей системы. Подведем некоторые итоги. Важно выбрать правильное множество моделей для визуализации, специфицирования, конструирования и документирования системы. Хорошо структурированная модель дает упрощенное представление реальности с одной относительно независимой точки зрения, самодостаточна, то есть не требует для понимания ее семантики никакой дополнительной информации, слабо связана с другими моделями посредством отношений трассировки, коллективно, совместно с другими моделями, дает полное представление обо всех артефактах системы. Утёмов В.В.,2010г. Столь же важно бывает представить сложную систему в виде декомпозиции хорошо структурированных подсистем. Хорошо структурированная система функционально, логически и физически связана, может быть разложена на почти независимые подсистемы, которые сами являются системами на более низком уровне абстракции, может быть визуализирована, специфицирована, сконструирована и документирована в виде набора взаимосвязанных, неперекрывающихся моделей. Для моделей в UML не предусмотрено специального графического представления за исключением диаграмм стереотипных пакетов, хотя инструментальные средства обычно изображают их в виде пакетов, каждому из которых соответствует разбиение системы с определенной точки зрения. При изображении системы в UML используйте каждую из них как начальную точку для всех артефактов, ассоциированных с ней, показывайте только основные виды агрегирования между системой и ее подсистемами, выносите детали связей между ними на диаграммы более низкого уровня абстракции. Утёмов В.В.,2010г. ЛЕКЦИЯ 9. Информационные технологии и средства анализа и проектирования информационных систем Предварительные итоги Внедрение информационных систем как основы для автоматизации деятельности предприятий направлено на поддержку принятия управленческих решений менеджерами предприятия. А это предполагает, что в зависимости от ранга менеджмента решаются задачи автоматизации рабочих мест, связанных с выполнением текущих производственных функций, автоматизации оперативного управления производственными процессами на уровне нижнего и среднего звена менеджеров, если речь идет о разработке системы корпоративного уровня. До последнего времени существовало два подхода к решению задачи автоматизации деятельности предприятия: Поэтапная разработка системы собственными силами (включая использование готовых или заказных программных продуктов сторонних фирм и организаций, позволяющих автоматизировать отдельные рабочие места или производственные процессы). Внедрение готовой информационной системы. Преимущество первого подхода состоит в том, что в создаваемой собственными силами системе в наибольшей степени можно было учесть потребности и специфику работы конкретного предприятия. Хотя, следует отметить, не всегда это качество является достоинством - достаточно сослаться на известную книгу Хаммера и Чампи "Реинжиниринг корпорации". В этой книге обоснованно утверждается, что автоматизация плохо организованных бизнес-процессов способна только ухудшить ситуацию на предприятии. Поэтому, разработке информационной системы должен предшествовать анализ, а если необходимо, то и реинжиниринг производственной деятельности. Кроме того, "эволюционный" характер постепенных улучшений с возможностью поэтапного финансирования разработок во многих случаях выглядит более привлекательно по сравнению с риском кардинальных преобразований и значительных затрат, связанных с внедрением готовых систем. К сожалению, этот путь решения проблемы автоматизации оказывается слишком растянут во времени, часто превращаясь в "постоянный процесс разработки", когда разработчики не успевают за изменениями, происходящими в организации. Предприятия, располагающие необходимыми финансовыми средствами, отдают предпочтение готовым программным системам. Однако, успех от внедрения такой системы, в значительной степени зависит от готовности (и возможности) самого предприятия работать по "правилам", диктуемым приобретаемой информационной системой. "Готовая" информационная система имеет модульную архитектуру, и процесс внедрения такой системы может быть выполнен по этапам - начиная с модулей, автоматизирующих наиболее критичные участки работы. При этом обеспечивается "целостность" системы, позволяющая воспользоваться на соответствующих рабочих местах новыми функциями подключаемых модулей. Утёмов В.В.,2010г. Компонентная архитектура Опыт разработки "готовых" информационных систем позволил сформировать новый подход к созданию больших информационных систем, основанный на "сборке" систем из программных "компонент" различных фирм-производителей. Компонентная архитектура информационных систем стала возможной благодаря поддержке ведущими производителями программного обеспечения общих стандартов на проектирование, разработку и технологию компонентной "сборки" информационных систем, реализуемых на различных программно-аппаратных платформах. На современном этапе развития информационных технологий компонентная технология создания информационных систем выглядит наиболее привлекательной и перспективной. Действительно, она объединяет гибкость в выборе необходимых компонент информационной системы, свойственную разработке системы собственными силами, с надежностью кода и функциональной полнотой, проверенными многократным использованием, характерным для коммерческих программных продуктов. Более того, компонентная технология позволяет оперативно вносить изменения в существующую информационную систему, не нарушая ее работоспособности. При этом новые приложения могут работать с новыми модулями, а старые - с прежними модулями, которые остаются в системе. Снимается проблема "унаследованных" систем - нет необходимости их замены для изменения или расширения функциональности, а значит уменьшаются затраты на сопровождение и модернизацию информационной системы. Для того, чтобы компонентная архитектура информационных систем стала реальностью необходимы три условия: наличие методологии анализа и проектирования информационных систем, обеспечивающих компонентную разработку и "сборку" систем, сформированный рынок готовых программных компонент, поддерживающих общие стандарты на технологию разработки и "сборки" компонент, стандартные компоненты программного обеспечения "инфраструктуры" информационной системы, поддерживающие взаимодействие между компонентами системы. Стремительный рост числа доступных программных компонент и их библиотек, постоянно расширяющийся рынок инструментальных программных средств анализа, проектирования и разработки систем с компонентной архитектурой и поддержка многокомпонентных систем на различных программно-аппаратных платформах способно, по мнению многих специалистов в области информационных технологий, коренным образом изменить "облик" современных информационных систем. Особенно сильно тенденция к созданию многокомпонентных систем проявилась в технологии Internet/Intranet, в которой активно используются компоненты ActiveX и JavaBeans. Воспользоваться преимуществами компонентной технологии, основанной на общих стандартах, стремятся и такие производители готовых систем, как SAP (R3). Краткий перечень производителей и программных продуктов Ключевым фактором успеха в реализации компонентной технологии становятся методология и средства анализа и проектирования многокомпонентных информационных систем. Методология создания информационных систем с компонентной архитектурой "выросла" из объектно-ориентированной методологии проектирования распределенных Утёмов В.В.,2010г. систем. Значительный вклад в развитие компонентной методологии внесли сотрудники фирмы Rational Software (особенно Г. Буч, Д. Рамбо и И. Якобсен). В настоящее время фирма Rational Software является безусловным лидером в области объектно-ориентированного анализа и проектирования информационных систем с компонентной архитектурой. Разрабатываемая этой фирмой методология, основанная на использовании унифицированного языка моделирования (UML - Unified Modeling Language в настоящее время принят OMG в качестве стандарта), поддержана целым спектром инструментальных программных средств визуального моделирования, совместной разработки (поддерживаются основные языки программирования С++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки - MS Visual Studio, Delphi, PowerBuilder), автоматизированного тестирования и документирования, охватывающих жизненный цикл создания программных систем. В Internet узел этой фирмы (www.rational.com) содержит обширную и постоянно пополняемую и обновляемую информацию о новых методологиях и стандартах, программных продуктах, публикациях и доступных ресурсах (включая примеры построения информационных систем и реализации отдельных решений). На этом же узле обсуждаются многие из, возникающих в процессе разработки системы, вопросов. Помимо Rational Rose, продукта фирмы Rational Software, к числу популярных средств визуального моделирования, поддерживающих стандарты UML, можно отнести Paradigm Plus (программный продукт фирмы Computer Associated) и SELECT (SELECT Software). Rational Rose - хорошо сбалансированный программный продукт с удобным интерфейсом и набором инструментов моделирования, ориентированным как на разработчиков программных систем, так и на бизнес- и системных аналитиков. На базе Rational Rose был создан Visual Modeler - средство визуального проектирования, включенное в состав среды разработки Microsoft Visual Studio (начиная с версии 6.0). Широкую известность и признание у аналитиков всего мира получили CASE средства BPWIN и ERWIN, теперь спектр продуктов компании Computer Associated пополнился новым пакетом, предназначенным для визуального моделирования объектноориентированных программных систем. Paradigm Plus, скорее всего, понравится не тем разработчикам, которые отдают предпочтение удобству настроек по умолчанию и простоте использования инструмента, а тем, которые больше всего ценят возможность максимальной адаптации инструмента к своим потребностям, вплоть до настройки шаблонов (скриптов), на основе которых реализуется генерация кода программной системы. Средство визуального моделирования Select в большей степени, чем два предыдущих, похоже на традиционное CASE (Computer-Aided System Engineering) средство моделирования, знакомое бизнес- и системным аналитикам еще со времен структурного анализа и проектирования систем. Хотя Select и ориентирован, в основном, на аналитиков, он может использоваться и разработчиками программных систем. Этот продукт, также, как и два предыдущих, поддерживает UML и компонентную технологию проектирования программных систем. Таким образом, компонентная технология проектирования и разработки информационных систем на сегодняшний день располагает необходимым арсеналом средств - начиная от инструментов визуального анализа и моделирования, поддерживающих существующие средства разработки, и кончая широким выбором библиотек готовых компонент, включая компоненты "инфраструктуры" для различных программно-аппаратных платформ. А это значит, что информационные технологии стоят на пороге появления "конструкторов" готовых систем, состоящих из наборов компонент от различных производителей. Утёмов В.В.,2010г. Сравнительный обзор возможностей Rational Rose и PARADIGM PLUS В завершении нашего курса дадим сравнительный обзор двух лидирующих на рыке программного обеспечения, предназначенных для визуального моделирования информационных систем. При исследовании визуальных средств проектирования информационных систем Rational Rose (RR) и Paradigm Plus(P+) мы рассмотрим следующие возможности: поддерживаемая нотация методологии компонентно-базируемое проектирование ведение репозитария объектов построение диаграмм моделей, пользовательский интерфейс генерирование программного кода наличие реинжиниринга проектирование баз данных, поддержка SQL и мостов для реляционных баз данных, IDL для CORBA создание экранного интерфейса возможность групповой работы наличие Script-языка генерирование отчетов и формирование проектной документации поддерживаемые платформы место в общем цикле разработки программной системы Поддерживаемая нотация RR: UML, также поддерживается нотация Буча и ОМТ-2. Диаграммы из различных нотаций автоматически взаимно конвертируются. P+: UML, всего поддерживается восемь нотаций из методологий ОМТ Рамбо, Буча, Шлеер/Меллора, Fusion, Мартина/Оделла, Кода/Йордана, OOCL. Проект должен вестись только в одной из выбранных нотаций. Наличие UML в том числе с возможностью моделирования Use Case, отличает современное средство визуального моделирования. Общепризнанно, что "война нотаций закончилась", (но не война методов). Значимость многонотационной поддержки постепенно снижается. В этом смысле средства равнозначны. Методологии RR: Средство предназначено для объектно-ориентированных методологии, в частности под разрабатываемую в фирме методологию "Rational Objectory Process". P+: Наличие многих нотаций позволяет поддерживать практически любую современную объектно-ориентированную методологию. Имеется фирменная методология "ECMEnterprise Component Modeling", поддерживаемая в электронном виде. Оба средства сочетают объектно-ориентированный подход с методологической поддержкой. Утёмов В.В.,2010г. Компонентно-базируемое проектирование RR: Позволяет моделировать и разрабатывать классы и компоненты, пригодные для повторного использования и включать их в разрабатываемые проекты. P+: Имеется возможность связывать разрабатываемые компоненты в диаграммы. Броузер позволяет разработчику искать и получать доступ к объектам в других приложениях и повторно использовать их в своих разработках. Оба средства отражают современные тенденции разработки программных систем. Ведение репозитария объектов RR: Открытого репозитария нет. Модели хранятся как ASCII-файлы, управляются через внутренний репозитарий. Поддерживается согласованность всех составных частей проекта. Явного доступа нет, репозитарий скрыт от пользователя, но к его элементам можно обратиться с помощью Script-языка. Ведутся активные работы по использованию стандартных MS-Repository и Unisys UREP. P+: Собственный репозитарий, реализованный на основе объектно-ориентированной СУБД ObjectStore фирмы ObjectDesign. Единый репозитарий используется при работе на различных платформах Unix, Windows, OS/2. Наличие репозитария обычно приводится как значительное преимущество P+, но явного выигрыша по отношению к RR здесь не видно. Более того позиции по отношению к использованию репозитария сближаются. Построение диаграмм моделей. Пользовательский интерфейс RR: Интерактивный многооконный интерфейс с возможностями OLE-технологий. Поддерживается согласованность между диаграммами, так что изменения в объектной модели немедленно отображаются в соответствующих сценарных диаграммах. Работа с диаграммами и их элементами осуществляется через диалоговые окна или через броузер. Все диаграммы сопровождаются подробными спецификациями. Можно исключать на диаграммах изображение отдельных деталей. Пользовательский интерфейс настраивается. Предусмотрены специальные средства поиска и диагностики. Есть возможность создавать новые стереотипы для элементов моделей. P+: Практически аналогичные функциональные возможности, но в более современном стиле, хотя интерфейс несколько перегружен. Поддерживается OLE2. Больше параметров можно указать при описании элементов моделей. Также можно управлять объемом отображаемой в моделях информации и погасить ненужную. Согласованность диаграмм поддерживается. Реализованы традиционные режимы графического редактора: создание, редактирование, удаление элементов модели. Различная степень визуализации модели. Кроме графического редактора диаграмм имеется матрично-табличная форма определения отношений между объектами. Изменения на любой диаграмме автоматически отражаются на всех других связанных диаграммах. Оба средства содержат основные возможности графического редактирования и работы в диалоговых окнах. В RR эти возможности попроще, а в P+ графическое отображение значительно медленнее. Очевидно, это связано с постоянным обращением к объектной базе данных, используемой как репозитарий. Утёмов В.В.,2010г. Генерирование программного кода RR: Генерируется каркас программы, заголовочные файлы, поля реализации и некоторые методы, но не законченное приложение. Rose генерирует коды на языках Ada, C++, Smalltalk, Java и IDL. Rational Rose - это семейство продуктов и в рамках одного CASEсредства можно генерировать программный код только для данного языка. Ожидается, что кодогенераторы будут поставляться отдельно при общем ядре визуального моделирования. Стиль программного модуля может формироваться пользователем в весьма широких пределах путем настраивания свойств кодогенератора как для всего проекта, так и для отдельных элементов. Возможность подключения базовых стандартных библиотек MFC, RogueWave и др. P+: Генерирует коды для Ada, C/C++, Visual C++, Smalltalk, Java, OO COBOL, Delphi. Также генерируются коды для SQL, Active/X и физических определений для объектных и реляционных баз данных. Свойства практически одинаковые. Нет возможности генерации из модели завершенного приложения. Наличие реинжиниринга RR: Поддерживает реинжиниринг и может загрузить код из С++, PowerBuilder, Forte, Java, IDL, Ada, Smalltalk или SQLWindows в свою среду и сгенерировать диаграммы отражающие изменения сделанные в коде по сравнению с более ранними диаграммами. Поддерживается концепция возвратного проектирования (RTE) с возможностью сравнения вновь сгенерированной диаграммы с предыдущей при очередной итерации. P+: Поддерживается реинжиниринг с кода на С, С++, Visual C++, Smalltalk, Forte, PowerBuilder, VisualBasic, Forte, Java, ObjectPro фирмы Platinum. Есть прямой инжиниринг, реинжиниринг и возвратное проектирование для основных языков программирования. Проектирование баз данных. Поддержка реляционных баз данных, IDL для CORBA SQL и мостов для RR: Для выделенных классов автоматическое создание DDL-файлов с учетом особенностей конкретных СУБД (Oracle7, Sybase SQL…). Возможности генерации схем весьма ограничены. Для проектирования баз данных существуют мосты к Silverrun, Erwin, PowerDesigner. Планируется связь с Oracle8. Rational Rose генерирует и делает реинжиниринг для CORBA2.0, совместимый код для Orbix Iona. P+: Интегрирована SQL-станция с возможностью проектирования таблиц баз данных путем отображения объектов в реляционную модель. Возможность создания и реинжиниринга схем для ведущих СУБД, включая Oracle, Sybase, Informix, DB2, SQL Server. По сути, встроен самостоятельный CASE проектирования реляционных баз данных с возможностью построения ER-моделей. В P+ проектирование баз данных существенно лучше, чем в RR, но уступает специализированным средствам типа Silverrun. Создание экранного интерфейса Возможность визуальной разработки экранов отсутствует. Утёмов В.В.,2010г. Возможность групповой работы RR: Поддерживает управление и контроль версий и разбиение проекта на модули(Units), так что индивидуальный разработчик может закрыть доступ (заблокировать) к части приложения. Более того, Rational Rose может организовать их так, чтобы каждый разработчик работал с полной моделью внутри своего рабочего пространства. Интеграция со стандартными системами контроля и управления версиями ClearCase, PVCS. P+: Группа разработчиков может работать над проектом одновременно используя либо централизованный, либо распределенный репозитарий объектов. Поддерживается контроль версий и блокирование модулей отдельными разработчиками. Собственная система контроля и управления версиями в рамках репозитария CCC/Harvest, а также Sourсe Safe, PVCS. Групповая работа поддерживается. Наличие Script-языка RR: Имеется script-язык и развитой набор API-функций, реализованных на базе Ms-VB 5.0, обеспечивающий полный доступ к элементам моделей Rational Rose. P+: Собственный BASIC-подобный язык с набором функций доступа к репозитарию и возможностью управления диаграммами проекта. Оба средства содержат Script-язык. Генерирование отчетов и формирование проектной документации RR: Диаграммы и их спецификации входящих в них объектов можно вывести на печать. Генератор отчетов в формате RTF интегрирован в MS Word. Есть возможность подготовки документации через генератор документации Rational SoDA. P+: Все сделанное в Paradigm Plus может быть документировано, выведено на печать и импортировано во множество существующих форматов. Генерируются статистические отчеты. Предполагается использовать инструмент подготовки документации Paradigm Publisher для вывода данных в MS Word 7.0. Оба средства позволяют выводить рабочую проектную документацию. Сравнительный обзор возможностей Rational Rose и PARADIGM PLUS Поддерживаемые платформы RR: Windows 95, NT Alpha NT, Solaris, HP-UX, AIX. P+: Windows 95, NT Alpha NT, Solaris, HP-UX, AIX. Оба средства многоплатформенные. Место в общем цикле разработки программной системы Утёмов В.В.,2010г. RR: Это средство для визуального объектно-ориентированного моделирования, анализа проектирования и программирования программных систем. Возможность построения различного рода диаграмм и их документирование позволяет использовать Rational Rose для сбора требований и документирования бизнесс-процессов, но это дополнительные возможности. Также можно, но нецелесообразно использовать данное средство для проектирования баз данных из-за недостаточной поддержки генерации SQL-кодов. Фирма Rational предлагает комплексное решение путем интеграции Rational Rose с Requisite Baseline, RequisitePro для сбора и документирования требований к системе, использование программных мостов для проектирования баз данных, SQA Suite или Rational Visual Test как средства тестирования. P+: Продукт объявлен как сочетающий в себе возможности объектно-ориентированного моделирования бизнес процессов, анализа и проектирования и программирования программных систем, разработки баз данных. Все эти возможности реализованы в одном продукте. Кроме того, для комплексного решения предлагается использовать дополнительно целый набор фирменных инструментальных средств по тестированию, управлению проектом, проектной генерации документации и т.д. Оба продукта - инструменты для итеративного объектно-ориентированного анализа проектирования и разработки программных систем. Выводы По оценкам экспертов оба средства - продукты одного класса, являются лидерами мирового уровня в своей области (RR продукт №1 и лидирует с большим отрывом от конкурентов по количеству продаж; PP+ занимает второе место) и содержат практически одинаковый набор характеристик и функциональных возможностей. Фирмы-разработчики данных средств, предлагают комплексные решения по разработке объектноориентированных компонентно-базируемых сложных масштабируемых программных систем уровня предприятия. Решения опираются на современную методологию, Rational Rose отличает легкий пользовательский интерфейс и высокое качество генерации кода и реинжиниринга. Средство легко принимаемое программистами. Большие усилия Rational уделяет продвижению UML, меньше занимаясь CASE-средствами. Наблюдается активное сотрудничество с Microsoft. Модуль визуального моделирования уже интегрировано в MS Visual Studio, ориентация на MS-репозитарий, созданы модели библиотек классов MFC в UML-нотации. (Объявлено, что такие же модели созданы и для библиотек Rogue Wave). Paradigm Plus имеет хороший репозитарий, построенный на объектно-ориентированной базе данных, достаточно удобен для аналитика и разработчика и предоставляет весь спектр услуг в одном средстве.
