 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Лекция №3: Рабочий продукт, дисциплина обязательств, проект
Рабочий продуктОдним из существенных условий для управляемости промышленного процесса является наличие отдельно оформленных результатов работы – как в окончательной поставке так и промежуточных. Эти отдельные результаты в составе общих результатов работ помогают идентифицировать, планировать и оценивать различные части результата. Промежуточные результаты помогают менеджерам разных уровней отслеживать процесс воплощения проекта, заказчик получает возможность ознакомиться с результатами задолго до окончания проекта. Более того, сами участники проекта в своей ежедневной работе получают простой и эффективный способ обмена рабочей информацией – обмен результатами. Таким результатом является рабочий продукт (work product) – любой артефакт, произведенный в процессе разработки ПО, например, файл или набор файлов, документы, составные части продукта, сервисы, процессы, спецификации, счета и т.д.
Рис. 3.1.
Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем (not to be engineered), хотя может быть таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный процесс – промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д. Важно отметить, что рабочий продукт совсем не обязательно является составной частью итоговой поставки. Например, налаженный процесс тестирования системы не поставляется заказчику вместе с самой системой. Умение управлять проектами (не только в области программирования) во многом связано с искусством определять нужные рабочие продукты, настаивать на их создании и в их терминах вести приемку промежуточных этапов работы, организовывать синхронизацию различных рабочих групп и отдельных специалистов. Многие методологии включают в себя описание специфичных рабочих продуктов, используемых в процессе – CMMI, MSF, RUP и др. Например, в MSF это программный код, диаграммы приложений и классов (application diagrams и class diagrams), план итераций (iteration plan), модульный тест (unit test) и др. Для каждого из них точно описано содержание, ответственные за разработку, место в процессе и др. аспекты. Остановимся чуть детальнее на промежуточных рабочих продуктах. Компонента ПО, созданная в проекте одним разработчиком и предоставленная для использования другому разработчику, оказывается рабочим продуктом. Ее надо минимально протестрировать, поправить имена интерфейсных классов и методов, быть может, убрать лишнее, не имеющее отношение к функциональности данной компоненты, разделить public и private, и т.д. То есть проделать некоторую дополнительную работу, которую, быть может, разработчик и не стал делать, если бы продолжал использовать компоненту только сам. Объем этих дополнительных работ существенно возрастает, если компонента должна быть представлена для использования в разработке, например, в другой центр разработки (например, иностранным партнерам, что является частой ситуацией в оффшорной разработке). Итак, изготовление хороших промежуточных рабочих продуктов очень важно для успешности проекта, но требует дополнительной работы от их авторов. Работать одному, не предоставляя рабочих продуктов – легче и для многих предпочтительнее. Но работа в команде требует накладных издержек, в том числе и в виде трат на создание промежуточных рабочих продуктов. Конечно, качество этих продуктов и трудозатраты на их изготовление сильно варьируются в зависимости от ситуации, но тут важно понимать сам принцип. Итак, подытожим, что промежуточный рабочий продукт должен обязательно иметь ясную цель и конкретных пользователей, чтобы минимизировать накладные расходы на его создание.
Рис. 3.2. Дисциплина обязательствВ основе разделения обязанностей в бизнесе и промышленном производстве, корпоративных правил и норм лежит определенная деловая этика, форма отношений – дисциплина обязательств. Она широко используется на практике и является одной из возможных форм социального взаимоотношения между людьми. Привнесение в бизнес и промышленность иных моделей человеческих отношений – семейных, сексуальных, дружеских и т.д. часто наносит делам серьезный урон, порождает конфликтность, понижает эффективность. Основой этой формы отношений являются обязательства, которые: – даются добровольно; – не даются легко – работа, ресурсы, расписание должны быть тщательно учтены; – между сторонами включает в себя то, что будет сделано, кем и в какие сроки; – открыто и публично сформулированы (то есть это не "тайное знание"). Кроме того: – ответственная сторона стремится выполнить обязательства, даже если нужна помощь; – до наступления deadline, как только становится очевидно, что работа не может быть закончена в срок, обсуждаются новые обязательства. Отметим, что дисциплина обязательств не является каким-то сводом правил, законов, она отличается также от корпоративной культуры. Это – определенный групповой психический феномен, существующий в обществе современных людей. Приведенные выше пункты не являются исчерпывающим описанием этого феномена, но лишь проявляют и обозначают его, так сказать, вызывают нужные воспоминания. Дисциплина обязательств, несмотря на очевидность, порой, не просто реализуется на практике, например, в творческих областях человеческой деятельности, в области обучения и т.д. Существуют отдельные люди, которым эта дисциплина внутренне чужда вне зависимости от их рода деятельности. С другой стороны, люди, освоившие эту дисциплину, часто стремятся применять ее в других областях жизни и человеческих отношений, что оказывается не всегда оправданным. Подчеркнем, что данная дисциплина является далеко не единственной моделью отношений между людьми. В качестве примера можно рассмотреть отношения в семье или дружбу, что, с очевидностью, не могут быть выражены дисциплиной обязательств. Так, вместо точности и пунктуальности в этих отношениях важно эмоционально-чувственное сопереживание, без которого они невозможны. Дисциплине обязательств уделяется много внимания в рамках MSF, поскольку там в модели команды нет лидера, начальника. Эта дисциплина реализована также в Scrum: Scrum-команда имеет много свобод, и в силу этого – большую ответственность. Регламентируются также правила действий, когда обязательства не могут быть выполнены такой командой. ПроектКлассическое операционное разделение труда идет еще от Адама Смита и является сутью массового индустриального производства. То есть существует четко налаженный процесс работы и имеются области специализации – один цех точит, другой строгает, третий собирает, четвертый красит и т.д. Пропускная способность такого производства намного превосходит выполнение всей работы одним человеком или одной группой. Таким образом в XIX веке операционное разделение труда стало основой мануфактур, вытеснивших индивидуальное, ремесленное производство. В начале XX века эту структуру работ перенесли и на управление – то есть многочисленные менеджеры контролировали отдельные участки работ. Однако высокий уровень сложности ряда задач в промышленности и бизнесе не позволяет (к счастью!) так работать везде. Существует много творческих, новых задач, где, быть может, в будущем и удастся создать конвейеры, но в данный момент для их решения требуется существенная концентрация сил и энергии людей, неожиданные решения, а также удача и легкая рука. Это и есть область проектов. Проект – это уникальная (в отличии от традиционной пооперационного промышленного производства) деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата/цель, создание определённого, уникального продукта или услуги, при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска. В частности, разработка программного обеспечения, является, преимущественно, проектной областью. Необходимо различать проекты промышленные и проекты творческие. У них разные принципы управления. Сложность промышленных проектов – в большом количестве разных организаций, компаний и относительной уникальности самих работ. Пример – строительство многоэтажного дома. Сюда же относятся различные международные проекты и не только промышленные – образовательные, культурные и пр. Задача в управлении такими проектами – это все охватить, все проконтролировать, ничего не забыть, все свести воедино, добиться движения, причем движения согласованного. Творческие проекты характеризуются абсолютной новизной идеи – новый сервис, абсолютно новый программный продукт, какого еще не было на рынке, проекты в области искусства и науки. Любой начинающий бизнес, как правило, является таким вот творческим проектом. Причем новизна в подобных проектах не только абсолютная – такого еще не было. Такое, может, уже и было, но только не с нами, командой проекта. То есть присутствует огромный объем относительной новизны для самих людей, которые воплощают этот проект. Проекты по разработке программного обеспечения находятся между двумя этими полюсами, занимая в этом пространстве различное положение. Часто они сложны потому, что объемны и находятся на стыке различных дисциплин – того целевого бизнеса, куда должен встроиться программный продукт, и сложного, нетривиального программирования. Часто сюда добавляется еще разработка уникального электронно-механического оборудования. С другой стороны, поскольку программирование активно продвигается в разные сферы человеческой деятельности, то происходит это путем создания абсолютно новых, уникальных продуктов, и их разработка и продвижение обладают всеми чертами творческих проектов. Управление проектами (project management) – область деятельности, в ходе которой, в рамках определенных проектов, определяются и достигаются четкие цели при нахождении компромисса между объемом работ, ресурсами (такими как время, деньги, труд, материалы, энергия, пространство и др.), временем, качеством и рисками. Отметим несколько важных аспектов управления проектами. – Stakeholders – это люди со стороны, которые не участвуют непосредственно в проекте, но влияют на него и/или заинтересованы в его результатах. Это могут быть будущие пользователи системы (например, в ситуации, когда они и заказчик – это не одно и то же), высшее руководство компании-разработчика и т.д. Идентификация всех stakeholders и грамотная работа с ними – важная составляющая успешного проектного менеджмента – Project scope – это границы проекта. Это очень важное понятие для программных проектов в виду изменчивости требований. Часто бывает, что разработчики начинают создавать одну систему, а после, постепенно, она превращается в другую. Причем для менеджеров по продажам, а также заказчика, ничего радикально не произошло, а с точки зрения внутреннего устройства ПО, технологий, алгоритмов реализации, архитектуры – все радикально меняется. За подобными тенденциями должен следить и грамотно с ними разбираться проектный менеджмент. – Компромиссы – важнейший аспект управления программными проектами в силу согласовываемости ПО. Важно не потерять все согласуемые параметры и стороны и найти приемлемый компромисс. Одна из техник управления компромиссами будет рассказана в контексте изучения методологии MSF. При разработке программных проектов, следуя MSF 3.1, важны следующие области управления.
Лекция №4 Архитектура ПО ОбсуждениеКак-то раз один менеджер объяснял основные идеи одного достаточно крупного проекта, которым он руководил. Он начертил на доске три кубика: frontend, backend, tools. И сказал, что это и есть главное строение проекта. И в смысле внутреннего устройства продукта, и в смысле распределения работ в команде по трем дистанционно разнесенным центрам разработки. Задачи backend сложные, ресурсоемкие, выполняются пакетно. Они отделены от графического интерфейса продукта (frontend), который также непросто устроен. Frontend – это пользовательский интерфейс: сложный, параметризуемый, с рядом встроенных пользовательских сервисов (в частности, браузер информации), а также настраиваемый. Обе эти подсистемы взаимодействуют друг с другом через хорошо определенный и детально описанный программный интерфейс: алгоритмы backend разбиты на методы, которые frontend может вызывать по особым правилам, с параметрами, выстраивая в цепочку для достижения своих задач. "Сбоку" от всего этого находятся дополнительные tools. Они интегрируются во frontend, но не пользуются методами backend, а реализуют свои задачи самостоятельно. Эти задачи не требуют сложной пакетной обработки, а нацелены на интерактивное взаимодействие с пользователем. При их реализации особенно много внимания уделялось usability. Каждая из трех подсистем требовала от разработчиков особых навыков. В случае backend это было умение и опыт по реализации такого рода пакетных алгоритмов, в случае с frontend – умение создавать сложный пользовательский интерфейс, в случае с tools требовалось искусство в проектировании и реализации "легковесных" инструментов, предоставляющих пользователям системы дополнительные сервисные возможности. В том, чтобы разделить работы таким образом, был еще и ряд политических аспектов. В частности, руководство проекта хотело иметь процесс разработки пользовательского интерфейса рядом с собой, в одном из трех центров разработки, который совпадал со штаб-квартирой. Считалось, что внешний вид продукта очень важен для его успешной продажи и требует особенного внимания. В результате выполнения проекта (а он развивался более 15 лет, достигая в апогее до 150 человек, одновременно занятых в нем) такая четкая структура несколько сместилась – так географически интерфейс почти "переехал" в тот центр, где разрабатывался backend. Но в целом такое сквозное разделение проекта на части оставалось много лет и было основным скелетом всей разработки. Это и есть пример архитектуры программного проекта. ОпределениеБудем понимать под архитектурой ПО внутреннюю структуру продукта (компоненты и их связи), основы пользовательского интерфейса продукта, а также квинтэссенцию знаний и решений, являющихся инструментом разработки и управления проектом. То есть архитектура – это сквозная концепция или набор таковых для преодоления энтропии и хаоса, стремящихся "проглотить" разработку в виду сложности, нематериальности, согласовываемости и изменчивости ПО. При этом мы не разделяем продукт и проект, так как на практике это, как правило, одно целое, причем эта "сквозность", если она имеется, является "сильной" стороной данной разработки. Часто под архитектурой понимают например, только внутреннее устройство ПО, выраженное в UML-диаграммах. Вот шутка на тему того, что архитектуру нельзя понимать односторонне. Одного известного трансляторщика спросили, почему в его знаменитом трансляторе ровно 21 просмотр. Ожидали услышать перечисление про алгоритмических проблем, которые таким способом удалось преодолеть, что-то про особую эффективность алгоритмов, организованных таким образом, и т.д. Всех удивил ответ мэтра. Он сказал, что именно столько человек (то есть ровно 21), было у него в команде разработчиков….. Итак, архитектура продукта оказывается инвариантом проекта, встречается и неожиданно возникает в его разных частях. Это и есть аналог "простым" естественно-научным постулатам и законам, отсутствие которых в разработке ПО, по мнению Брукса, является причиной сложности ПО (в смысле хаоса, то есть "плохой" сложности). Создавать такие структуры – непростое дело, требующее большого искусства. Но именно это путь к управлению хаосом, увеличивающейся энтропией в виде изменяющихся требований к системе, потере разработчиками ясного понимания, какую же именно систему они создают. И именно разработка таких структур доставляет истинное творческое наслаждение при разработке программных систем. Хорошо "работают" простые модели, которые не просто создавать. Они оказываются путеводной нитью проекта, ведущей его через пучины хаоса. Эти модели имеют такое свойство, что показывая или упоминая о них можно рассказывать о проекте очень долго, их можно красиво оформить и повесить на стенку, а можно этого и не делать. В рамках многих проектов не создается оригинальной архитектуры, поскольку они являются типовыми и/или небольшими и основываются на готовых технологиях, архитектурных образцах, моделях команды и оргструктуры проекта. Однако часто перед коллективами, которые хорошо себя зарекомендовали в таких проектах, возникает задача построить действительно оригинальную новую архитектуру, основывающуюся на прежних разработках. Или не основывающуюся – просто количество стремиться перейти в качество. Здесь прежде всего важно заметить этот переход, осознать, что старые методы работы не годятся и требуется принципиально новый опыт. Которого, очень часто, у коллектива и его лидеров нет….. Множественность точек зренияПри разработке архитектуры ПО важным оказывается совмещение множества точек зрения. ПО оказывается настолько сложным, что его архитектуру не построить как единую модель – множество отдельных аспектов должны быть представлены в архитектуре, их связи сложны и плохо выразимы в явном виде. Полезнее оказывается создание множества моделей, созданных с разных точек зрения. Причина множественности точек зрения при разработке ПО. Умение рассматривать предмет с разных точек зрения является важнейшей философией успешной практики при работе с большими объемами разнородной и сложной информации. Посмотрим на разработку ПО и то, почему там востребованы разные взгляды на процесс, систему и т.д. Это происходит, прежде всего, из-за разных видов деятельности процесса разработки ПО (см. рис. 4.1). При составлении функциональных требований к ПО обращают внимание на то, какая именно функциональность должна быть реализована, но при этом опускаются принципы и детали реализации. При проектировании, наоборот, на первое место выходят принципы реализации ПО. А при тестировании детали реализации снова неважны — на ПО смотрят как на черный ящик, реализующий (не важно каким способом) некоторый набор пользовательской функциональности. При развертке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д. Рис. 4.1. Разные виды деятельности – разные взгляды на систему
Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (см. рис. 4.2). Для всех эти специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды…
Рис. 4.2. Разные специалисты – разные взгляды на систему
Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО. То есть разработка ПО во многом "state of art". Часто приходится изобретать новую точку зрения моделирования прямо по ситуации – чтобы именно этот эксперт тебя понял, чтобы именно эти особенности системы были отражены. Часто здесь – как в лотерее: создается несколько описаний системы с разных точек зрения, какое-то оказывается удачным и его все используют в дальнейшем. Итак, разные виды деятельности при разработке ПО, разные категории специалистов, задействованные в программном проекте, и уникальность каждой конкретной ситуации при разработке — все это приводит к созданию и использованию различных моделей, выполненных с разных точек зрения. Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Точку зрения нужно ясно осознавать при создании визуальных моделей, например, варианты использования. Важно понимать, что она может быть в каждом конкретном случае своя. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается). Важным вопросом, на который нужно честно себе ответить в самом начале моделирования — это зачем вы используете диаграммы (в частности, UML). Это и есть определение цели моделирования. Потому, что так создавать модели правильно? И все проблемы (даже те, о которых ничего еще не известно) волшебным образом исчезнут? Очень часто, например, при создании модели случаев использования присутствует именно такая "цель" моделирования. А потом оказывается, что никакие проблемы не "вылечились", а наоборот, возникли новые (например, созданные нами диаграммы никто не понимает и не принимает). Да и сам аналитик чувствует, что диаграммы получились какие-то странные…. А может все происходит совсем не так. Например, аналитик действительно задался целью выявить требования к системе — не навязать свое собственное видение другим, а выяснить нужную информацию, смоделировать и изложить ее доступно. Для этого он и использует диаграммы случаев использования. Ему важно, чтобы будущие пользователи системы могли участвовать в этом процессе, диаграммы рисуются для них, они понятны и не избыточны. И эти же диаграммы структурируют и проясняют информацию для самого аналитика. Подобных сюжетов на практике происходит множество. Тут важно понимать, что цель модели — это не какая-то гипотетическая задача типа "описания архитектуры, потому что так нужно, так правильно", а целевая аудитория — это не абстракция типа "люди, желающие познакомиться с ПО". И то и другое — что-то очень конкретное, реально существующее в проекте или рядом с ним. Ведь разработчики ПО не могут позволить себе за деньги заказчика создавать нечто на все века и для всех народов. И цель моделирования, и аудитория, которая будет работать с диаграммами, всегда существуют, важно лишь ясно понимать, какие они… Вот полезный практический прием для ориентации на целевую аудиторию, для которой предназначена создаваемая вами модель. Можно выбрать одного представителя такой аудитории — конкретного и известного вам человека — и создавать диаграммы, понятные именно ему. При этом важно не обсуждать чрезмерно с ним ваши модели, поскольку это может создать дополнительный контекст, которого другие пользователи моделей будут лишены. Полезно представлять воображать себе этого человека при работе над моделями — его реакции, вопросы, недоумения и пр. И, исходя из этого, корректировать, исправлять созданное. И, конечно же, полезно проверить свои предположения, показав ему, что получилось. Кроме того, важно, чтобы точка зрения была "живая", а не выдумывалась аналитиком или бездумно копировалась из книжек и тренингов, посвященных UML. Незаметно для себя аналитик может придумать свой собственный проект, своих собственных пользователей системы, заказчика и т.д. То есть аналитик исподволь, навязывает самому себе определенное восприятие реально существующих людей, задач, сильно искажая реальное положение дел. И именно в контексте этой воображаемой ситуации он создает свои модели. Но ведь реальные люди, реальные ситуации обладают своеобразием, большим диапазоном вариативности. Соответственно, аналитик должен обладать гибкостью сознания, большим диапазоном техник, а также чуткостью и искренним стремлением к тому, чтобы сделать каждый конкретный проект, где он участвует, более гармоничным, более адекватным. Язык UMLЧасто понятие архитектуры сильно сужают, понимая под ним лишь описание основных, важных аспектов ПО, создаваемых, например, архитектором при разработке дизайна системы. Для этих целей используется язык моделирования UML (Unified Modeling Language). Этот язык является итогом развития средств схематического описания программных систем, которые развивались с блок-схем, предложенных еще фон Нейманом в конце 40-х годов. Он предполагал, что эти схемы станут высокоуровневым языком ввода алгоритмов в вычислительные машины, но эволюция языков программирования пошла по пути текстовых языков. Тем не менее блок-схемы получили распространение при спецификации и документировании ПО, были стандартизованы, однако широкого практического применения не получили. В конце 60-х годов, в связи с поиском новых средств разработки ПО, рождением программной инженерии и общими следованиями в области проектирования и разработки искусственных систем появился термин структурный анализ (structured analysis) систем. Термин был введен ученым из MIT, Дугласом Россом, который также предложил диаграммный метод анализа и проектирования больших искусственных систем. Метод назывался SADT (Structured Analisys and Design Technique), стал основой серии военных стандартов США серии IDEF и широко распространился в индустрии. Однако диаграммный язык в SADT был очень скромным – набор блоков и связей между ними, с поддержкой декомпозиции блоков. В 70-х годах, в связи с массовым выходом ПО на свободный рынок (то есть программные системы стали создаваться не только в военной области, для крупного бизнеса, но также для среднего и малого бизнеса) структурный анализ стал бурно эволюционизировать – набор диаграмм обогатился диаграммами состояний и переходов, сущность-связь, потоков данных и т.д. С развитием объектно-ориентированных средств разработки (конец 80-х – середина 90-х) структурный анализ превратился в объектно-ориентированный анализ и проектирование. Появилось большое количество методологий, и постепенно сложился единый язык моделирования, который и был закреплен в стандарте UML. Произошло это в 1997 году. С тех пор вышло несколько версий стандарта UML. Текущая версия UML 2.1. Виды диаграмм"Скелетом" UML является диаграммная структура. Каждый вид диаграмм является типом моделей, реализующим определенную точку зрения на программную систему. Виды диаграмм не являются строго обязательными в UML – их можно перемешивать, создавать свои собственные виды диаграмм. Тем не менее стандартные виды диаграмм являются определенным достоянием программной инженерии, так как отражают опыт многих исследователей и практиков. Структурные диаграммы: – диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом; – диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов; – диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов; – диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.; – диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует); – диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много. Поведенческие диаграммы:– диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов; – диаграммы случаев использования (use case diagrams) предназначены для "вытягивания" требований из пользователей, заказчика и экспертов предметной области; – диаграммы конечных автоматов (state machine diagram) применяются для задания поведения реактивных систем; – диаграммы взаимодействий (interaction diagram): – диаграммы последовательностей (sequence diagram) используются для моделирования временных аспектов внутренних и внешних протоколов ПО; – диаграммы схем взаимодействия (interaction overview diagram) служат для организации иерархии диаграмм последовательностей; – диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой манере); – временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы. Примеры. Центральным видом диаграмм являются диаграммы классов. Пример представлен на рис. 4.3.
Рис. 4.3. Пример диаграмм классов
Еще один вид структурных диаграмм – диаграммы размещений, пример представлен ниже.
Рис. 4.4. Пример диаграмм размещений
Отметим также еще один важный вид диаграмм UML – диаграммы компонент (пример представлен на рис. 4.5).
Рис. 4.5. Пример диаграмм компонент
Интересен также вариант диаграмм композитных структур – сложные компоненты для систем реального времени и телекоммуникаций. Пример представлен ниже.
Рис. 4.6. Пример диаграмм композитных структур
Ниже приводятся примеры на поведенческие диаграммы UML. Диаграммы конечных автоматов позволяют создавать полные спецификации поведения телекоммуникационных, событийно-управляемых алгоритмов и автоматически генерировать по этим описаниям программный код. Пример такой диаграммы для класса COperator представлена ниже.
Рис. 4.7. Пример диаграмм конечных автоматов
Еще один важный вид диаграмм – диаграммы последовательностей. Они позволяют задавать главные ветки сложных телекоммуникационных алгоритмов, а также рисовать цепочки вызовов для объектно-ориентированных приложений, которые программируются в терминах объектов, но проектируются часто в терминах цепочек вызовов. Пример представлен ниже.
Рис. 4.8. Пример диаграмм последовательностей. |
