Технология разработки программного обеспечения

По крайней мере, дважды в неделю разработчик должен встраивать (check in) разрабатываемый «персональный» код в общую базу, где находится текущая «эталонная» версия (а можно это делать и каждый день). При этом он производит компиляцию и компоновку с обязательным выполнением регрессионного теста, который позволяет проверить реакцию общей «сборки» на вновь поступивший код. В случае проявления при этом какого-либо дефекта разработчик обязан тут же его «зафиксировать» (М. Кусумано, являющийся автором получивших мировую известность книг о японских промышленных технологиях, отмечает здесь сходство с действующим в сборочном цехе корпорации «Тойота» правилом, требующим немедленной остановки конвейера любым сборщиком, если он обнаружил дефект в собираемом автомобиле).

Операцию по встраиванию своего кода в общую эталонную базу разработчики имеют право выполнять до определенного назначенного часа; затем в дело вступает специально назначенный разработчик (project build master), который ежедневно генерирует полную «сборку» продукта на основе текущей эталонной версии исходного кода всего продукта. Эта процедура следует «сценарию сборки» (build script) в виде автоматически выполняемой последовательности команд и включает шаги по полной компиляции кода и получению в конечном счете одного или нескольких исполняемых файлов. При этом могут создаваться различные «библиотечные файлы», позволяющие конечным пользователям настроить продукт в соответствии со своей спецификой. Таким образом, ежедневно производится выпуск внутренней версии продукта (internal release), генерируемой для каждой платформы (Windows, Macintosh), а также для каждого значимого рынка (американский, европейский и т.п.). Вся эта технология, направленная на периодическую интеграцию функций и «стабилизацию» кода в его текущем состоянии, позволяет реализовать такой базисный принцип, как постоянное наличие во всех необходимых версиях «готового» (пусть еще далеко не полностью) продукта, который можно предъявить потребителю.

Выпуск продукта и механизмы обратной связи

В процессе разработки непрерывно используется несколько метрик, хотя в соответствии с общей корпоративной философией здесь не придают такого значения количественным индикаторам, как, например, в Motorola или HP, чья корпоративная культура предусматривает значительно более «выстроенные» процессы разработки. Тем не менее менеджеры каждый день отслеживают прогресс «ежедневных сборок» продукта именно на основе метрик, показывающих, сколько новых «багов» выявлено, сколько, наоборот, исправлено и, наконец, сколько всего остается «активных» дефектов.

В конце каждого подпроекта - после истечения срока параллельной работы команд над реализацией назначенных им функций - предусмотрен специальный период «буферное время» (buffer time), во время которого решаются всякие не предусмотренные планом, но неизбежно возникающие проблемы, особенно вызванные оперативно вносимыми изменениями в спецификации и взаимозависимостью функций, над которыми работали разные команды. Этот период используется и как тривиальное продление периода разработки подпроекта, потому что выходы за пределы временного графика наблюдаются почти всегда. Для проектов из разряда приложений буферное время занимает 20-30% всей продолжительности подпроекта, а для системных программ - 50%. Только после этого выпускается очередная «контрольная» версия (milestone release), с которой активно работают пользователи.

Важнейшим механизмом, обеспечивающим обратную связь с потенциальными потребителями продукта на протяжении всего процесса разработки, включая период работы над первым подпроектом, является институт лабораторий пользователя (Usability Lab). Первая такая лаборатория была открыта в 1989 г. и имела четыре тестовых комплекта, каждый из которых включал две разделенные полупрозрачным зеркалом комнаты: тестовую (test room), где пользователь имеет возможность «поиграть» с продуктом, и наблюдательскую (observation room), где располагается сотрудник, в чьи функции входит отслеживание всех деталей работы пользователя. Через три года была введена в действие еще одна лаборатория с пятью тестовыми комплектами; в 1995 г. добавили лабораторию, получившую название Microsoft Home, и не случайно: чтобы заставить пользователей чувствовать себя в буквальном смысле «как дома», здесь сымитирована домашняя обстановка, включая кухню, столовую и детскую. Наконец, в 1996 г. появилась лаборатория с пятью тестовыми комплектами, включающая специальное эргономичное оборудование.

В этих лабораториях работают более ста сотрудников (usability engineers), не только имеющих компьютерное образование, но и обладающих знаниями в специальных областях психологии и эргономики. Кроме того, непосредственно разработчикам, особенно отвечающим за интерфейсную часть, вменено в обязанность периодически присутствовать на тестовых экспериментах. Что касается контингента испытателей, то их стремятся подбирать так, чтобы они представляли все категории потенциальных пользователей - для этого накоплена и постоянно пополняется обширная база данных.

Главное, что измеряется и выражается в специальных метриках, - это легкость освоения продукта и удобство работы с ним. Следует отметить две метрики: первая показывает процент пользователей, которым удалось без обращения к руководству выполнить некое осмысленное действие; вторая метрика выражает процент корректных шагов на пути к выполнению задачи, сделанных с первой попытки. Опытным путем установлено, что для большинства продуктов на ранней стадии разработки вторая метрика (correct first-try rate) получается в районе 60%; цель же, которой в конечном счете стараются добиться, - это 90%.

Эксперименты проводятся не только в корпоративных лабораториях, но и «на выезде» в офисах, школах и университетах, по месту жительства возможных потребителей. Кроме того, в последней фазе разработки - фазе стабилизации - прошедшие всестороннее внутреннее тестирование «beta» версии отправляются для опытной эксплуатации к партнерам корпорации, принадлежащим к категориям OEM и ISV; здесь задействованы и многочисленные добровольцы-индивидуалы. После этого компания приступает к подготовке выпуска финальной версии продукта («golden master» discs), а также необходимой документации. Даже после выпуска «финальной» версии работа над продуктом не прекращается. Уже установилась традиция в среднем через 12 месяцев выпускать исправленную и дополненную версию, а через 24 месяца - радикально переработанную (с большим количеством новых функций и измененной архитектурой). Необходимо отметить, что работа отвечающих на телефонные звонки и другие обращения о помощи инженеров службы поддержки финансируется за счет бюджета команд разработчиков данного продукта; поэтому последние заинтересованы в постоянной минимизации дефектов в каждой последующей версии сравнительно с предыдущей.

Принципы работы с требованиями к программному обеспечению

Проблематика проектирования

Согласно статистическим исследованиям группы Стендиша (Standish Group) в США ежегодно тратится более 250 млрд долларов на разработку приложений информационных технологий в рамках примерно 175 000 проектов. Причем 31% проектов будет прекращен до завершения. Затраты на 52,7% проектов составят 189% от первоначальной оценки. В таком случае американские компании и правительственные учреждения потратят 81 млрд долларов на программные проекты, которые так и не будут завершены. Эти же организации заплатят дополнительно 59 млрд долларов за программные проекты, которые хотя и завершатся, но значительно превысят первоначально отведенное на них время.

Первым шагом на пути решения любой проблемы является осознание основных причин ее возникновения. В отчете группы Стендиша указаны три наиболее часто встречающихся ключевых фактора, создающих проблемы при проектировании программного обеспечения:

· недостаток исходной информации от клиента - 13% всехпроектов;

· неполные требования и спецификации - 12% проектов;

· изменение требований и спецификаций - 12% всех проектов.

В остальном данные сильно расходятся. Конечно, проект может потерпеть неудачу из-за нереалистично составленного графика или неправильно распределенного времени (4% проектов), нерационального подбора персонала и выделения ресурсов (6%), несоответствия технологических навыков (7%), а также по другим причинам. Тем не менее если считать, что приведенные цифры представляют реальное положение дел в отрасли, то, по крайней мере, неудачи трети проектов объясняются причинами, непосредственно связанными со сбором и документированием требований, а также с управлением ими.

Несмотря на то что большинство проектов действительно превышают отведенные время и бюджет, оказалось, что около 9% проектов крупных компаний были завершены вовремя и в пределах бюджета; аналогичного успеха удалось достигнуть в 16% проектов мелких компаний. Возникает очевидный вопрос: каковы главные «факторы успеха» в этих проектах? Согласно проведенному исследованию тремя наиболее важными факторами были следующие:

· подключение к разработке пользователя - 16% всех успешных проектов;

· поддержка со стороны исполнительного руководства -
14% проектов;

· четкая постановка требований - 12% всех успешных проектов.

Двумя самыми главными проблемами, упоминавшимися почти в половине ответов, оказались:

· спецификация требований;

· управление требованиями клиента.

Оценка стоимости ошибок

Некоторое время назад ряд компаний провел исследование оценки стоимости ошибок, возникающих на разных этапах создания программ. Каждая фирма действовала независимо, тем не менее результаты получены примерно одинаковые: если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость обнаружения и устранения ошибки на стадии сопровождения - в 20 раз больше (рис. 2.5).

Откуда берется такая высокая стоимость ошибки? Ко времени обнаружения ошибки в требованиях группа разработчиков уже могла потратить время и усилия на создание проекта по этим ошибочным требованиям. В результате проект, вероятно, придется отбросить или пересмотреть [1].

Истинная природа ошибки может быть замаскирована; при проведении тестирования и проверок на данной стадии все думают, что имеют дело с ошибками проектирования, и значительное время и усилия могут быть потрачены впустую.

Рис. 2.5 Оценка стоимости ошибок на разных этапах создания программных продуктов

В зависимости от того, где и когда при работе над проектом разработки программного приложения был обнаружен дефект, цена его может разниться в 50-100 раз. Причина состоит в том, что для его исправления придется затратить средства на некоторые (или все) ниже перечисленные действия.

1. Повторная спецификация.

2. Повторное проектирование.

3. Повторное кодирование.

4. Повторное тестирование.

5. Замена заказа - сообщить клиентам и операторам о необходимости заменить дефектную версию исправленной.

6. Внесение исправлений - выявить и устранить все неточности, вызванные неправильным функционированием ошибочно специфицированной системы, что может потребовать выплаты определенных сумм возмущенным клиентам, повторного выполнения определенных вычислительных задач на ЭВМ и т.п.

7. Списание той части работы (кода, части проектов и т.п.),
которая выполнялась с наилучшими побуждениями, но оказалась ненужной, когда обнаружилось, что все это создавалось на основе неверных требований.

8. Отзыв дефектных версий встроенного программного обеспечения и соответствующих руководств. Если принять во внимание, что программное обеспечение сегодня встраивается в различные изделия - от наручных часов и микроволновых печей до автомобилей - такая замена может коснуться как этих изделий, так и встроенного в них программного обеспечения.

9. Выплаты по гарантийным обязательствам.

10. Ответственность за изделие - если клиент через суд требует возмещение убытка, причиненного некачественным программным продуктом.

11. Затраты на обслуживание - представитель компании
должен посетить клиента, чтобы установить новую версию программного обеспечения.

12. Создание документации.

Управление требованиями

Требования задают возможности, которые должна предоставлять система, так что соответствие или несоответствие некоторому множеству требований часто определяет успех или неудачу проекта. Поэтому необходимо узнать, что собой представляют требования, записать их, упорядочить и отслеживать их изменения. Определение управления требованиями выглядит следующим образом [4].

Управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также процесс, в ходе которого вырабатывается и обеспечивается соглашение между заказчиком и выполняющей проект группой по поводу меняющихся требований к системе.

Учитывая, что системе будут предъявлены сотни, если не тысячи, требований, то очень важно организовать их.

Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса необходимо обеспечить документирование требований, которые следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений.

Кроме того, очень важными факторами являются размер проекта и его сложность. Управление требованиями наиболее важно в больших проектах, в которых участвует множество людей и число требований к проекту велико. Например, если требований 1000, то придется столкнуться с задачами организации, определения приоритетов, управления доступом, а также обеспечения ресурсами для выполнения всех этих требований.

Последовательность работы с требованиями

Анализ проблемы

У пользователя есть технические или бизнес-задачи, для решения которых нужны программисты. Задача последних состоит в том, чтобы понять проблемы пользователей в их собственной проблемной плоскости и на их языке и построить системы, удовлетворяющие их требованиям. Для понимания проблемы пользователей существует ряд профессиональных приемов, о которых пойдет речь ниже [3].

Программисты должны понять потребности пользователей и других заинтересованных лиц, на которых повлияет создание программы.

Следующим шагом является переход в область решения - непосредственно к программированию. Однако для начала будет полезно сформулировать знания о предметной области. На данном этапе составляется список функций, которые должна реализовывать система.

Для того чтобы провести анализ, следует определить, что же собственно представляет собой проблема. Проблема - это разница между желаемым и воспринимаемым.

Иногда самым простым решением является изменение бизнес-процесса, а не создание новой системы. Как всегда, начинать следует с определения цели. Цель анализа состоит в том, чтобы добиться лучшего понимания решаемой проблемы до начала разработки. Для этого необходимо осуществить следующие пять этапов:

достигнуть соглашения об определении проблемы;

выделить основные причины - проблемы, стоящие за проблемой;

выявить заинтересованных лиц и пользователей;

определить границу системы решения;

выявить ограничения, которые необходимо наложить на решение.

Этап 1. Достижение соглашения об определении проблемы.

Первый шаг состоит в достижении соглашения об определении проблемы, которую необходимо решить. Один из простейших способов заключается в том, чтобы просто записать проблему и выяснить, все ли согласны с такой постановкой. В рамках этого процесса зачастую полезно рассмотреть преимущества предлагаемого решения, причем их следует описывать на языке клиентов/пользователей. Это обеспечивает дополнительную содержательную основу для понимания реальной проблемы. Рассматривая эти преимущества с точки зрения клиента, программисты также достигают лучшего понимания их взгляда на проблему в целом.

Этап 2. Выявление основных причин - проблем, стоящих за проблемой.

На данном этапе важно понять корневые причины, лежащие в основе проблемы и ее проявления.

Например, электронный магазин решил бороться с проблемой недостаточной прибыльности. Для этого был проведен анализ причин плохих продаж. Выявлено, что следующие причины ведут к слишком большим остаткам продукции на складе:

1) устаревшие готовые изделия;

2) неправильные заказы на покупку;

3) повреждения при доставке;

4) производственные дефекты;

5) возвраты клиентами;

6) прочее.

Однако нужно ли устранять все эти причины? Зачастую нет. Некоторые корневые причины просто не стоят того, чтоб их устранять. Нужно определить влияние каждой корневой причины и устранять только те, которые наиболее серьезно влияют на саму проблему. В примере, допустим, наибольшее влияние оказывает корневая причина «Неправильные заказы на покупку».

Этап 3. Выявление заинтересованных лиц и пользователей.

В этом процессе могут помочь ответы на следующие вопросы:

· Кто является пользователем системы?

· Кто является заказчиком (экономическим покупателем) системы?

· На кого еще окажут влияние результаты работы системы?

· Кто будет оценивать и принимать систему, когда она будет представлена и развернута?

· Существуют ли другие внешние или внутренние пользователи системы, чьи потребности следует учесть?

· Кто будет заниматься сопровождением новой системы?

· Не забыли ли мы кого-нибудь?

Рис. 2.6 Границы системы

Этап 4. Определение границ системы.

Мир делится на две части (рис. 2.6):

· создаваемая система;

· то, что взаимодействует с системой, - фактор.

Очень важно правильно определить факторы. Для этого следует ответить на приводимые ниже вопросы.

· Кто будет управлять системой?

· Кто будет осуществлять сопровождение системы?

· Откуда система получает информацию?

· Какие внешние системы будут взаимодействовать с системой?

Этап 5. Выявление ограничений, налагаемых на решение.

Ограничения уменьшают степень свободы, которой располагают разработчики при реализации решения. Каждое ограничение может существенно сузить возможность создания предполагаемого решения. Следовательно, в процессе планирования необходимо тщательно изучить все ограничения.

Преграды на пути выявления требований

Синдром «да, но...». Одну из самых неприятных проблем, с которыми сталкиваются разработчики, можно назвать синдромом «да, но...» [3]. Это первичная наблюдаемая реакция пользователя на каждый разработанный фрагмент программного обеспечения.

Причина синдрома «да, но...» кроется глубоко в природе проектирования программного обеспечения как интеллектуального неосязаемого процесса. Проблема усугубляется тем, что команда разработчиков крайне редко предоставляет что-либо пользователям для обсуждения до окончания разработки (создания программного кода).

Реакция пользователей является следствием человеческой природы. Подобную реакцию можно часто наблюдать и при других повседневных обстоятельствах. Пользователи никогда ранее не видели новую систему или что-либо подобное; они не понимают, что программисты подразумевают, когда описывают ее. И вот теперь она перед ними - впервые после стольких месяцев (или лет) ожидания они имеют возможность взаимодействовать с системой. И оказывается, что это не совсем то, чего они ожидали.

Как это ни грустно, но нужно принять факт существования синдрома «да, но...» в качестве объективной реальности и сделать некоторые выводы, которые помогут членам команды смягчить влияние этого синдрома в будущих проектах.

Синдром «да, но...» является следствием человеческой природы и неотъемлемой частью разработки любого приложения.

Разработчики могут существенно уменьшить воздействие этого синдрома путем применения методов, которые выявят эти «но» как можно раньше. Выявив их на более ранних этапах, можно направить большую часть усилий на разработку программ, которые уже прошли тест «да, но...».

Синдром «пользователь и разработчик» является следствием расхождения взглядов пользователей и разработчиков. Они, как правило, принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели. Предлагаются следующие рекомендации по смягчению данной ситуации.

Функции. Использование функций - удобный способ описания возможностей без лишних подробностей.

Такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Тем не менее это высокий уровень абстракции, удобный для описания возможностей системы.

Рекомендуемое количество функций, которое дает полное представление о разрабатываемой системе, - 25-99, однако желательно, чтобы их число не превышало 50.

После того как все функции перечислены, можно приступить к принятию решения вида «отложить до следующей версии», «реализовать немедленно», «полностью отвергнуть» или «исследовать дополнительно». Этот процесс корректировки масштаба лучше проводить на уровне функций, а не на уровне требований, иначе можно увязнуть в деталях.

Для того чтобы лучше работать с этой информацией, введем понятие атрибутов функций - элементов данных, которые обеспечат дополнительную информацию о каждой функции.

Методы выявления требований:

· интервьюирование и анкетирование;

· совещания, посвященные требованиям;

· мозговой штурм и отбор идей;

· раскадровки;

· прецеденты;

· обыгрывание ролей;

· создание прототипов.

Интервьюирование и анкетирование. Интервью помогает понять проблему, не оказывая влияние на ответы пользователя. Ниже приведены примеры контекстно-свободных вопросов:

· Почему существует проблема?

· Как она решается в настоящее время?

· Как заказчик хотел бы ее решать?

· Кто такие пользователи?

· Каковы их навыки в компьютерной области?

После этого интервьюер перечисляет основные пункты, чтобы проверить, все ли было правильно понято: «Итак, вы сказали мне...» (перечисляются описанные заказчиком проблемы своими словами), «Какие еще проблемы вы испытываете?»

Правила подготовки интервью.

1. Все вопросы должны быть составлены заранее.

2. Перед интервью необходимо познакомится с информацией о клиенте.

3. Кратко записывайте ответы.

Совещания. Хорошо проведенное совещание по вопросам требований имеет множество преимуществ:

· помогает создать команду, подчиненную одной цели, - успеху данного проекта;

· все заинтересованные лица получают возможность высказать свое мнение, никто не остается в стороне;

· формирует соглашение между заинтересованными лицами и командой разработчиков по поводу того, что должно делать приложение;

· может высветить и разрешить политические вопросы, которые влияют на успех проекта;

· результат, предварительное определение системы на уровне функций, немедленно становится известным.

Все материалы к совещанию должны быть предоставлены участникам заранее.

Мозговой штурм. Все основные участники собираются в одной комнате, им раздаются материалы для заметок не менее - 25 листов формата от 712 до 1217.

Правила проведения мозгового штурма.

1. Не допускаются критика или дебаты.

2. Дайте свободу фантазии.

3. Генерируйте как можно больше идей.

4. Переделывайте и комбинируйте идеи.

Каждый записывает идеи на листок; позже они оглашаются. Критиковать их нельзя, дискутировать тоже не стоит, чтобы никого не обидеть. Идею надо попробовать развить или скомбинировать с какой-либо другой; если ничего не получится, то ее просто изымут из рассмотрения. Идеи обязательно записывают на бумагу по следующим причинам:

1. сохраняется авторская формулировка;

2. существует гарантия, что они не будут утрачены;

3. есть перспектива развития идеи в дальнейшем;

4. обеспечивается непрерывный творческий процесс - не надо ждать, пока секретарь запишет мысль участника.

Раскадровка. Цель раскадровки - в раннем выявлении реакции типа «да, но...». Существуют три типа раскадровок.

1. Пассивные. Пользователю излагают некую историю с применением рисунков, схем, картинок с экрана.

2. Активные. Пользователю показывают «еще не созданный фильм» с применением анимации или слайдов.

3. Интерактивные. Пользователь приобретает реальный опыт взаимодействия с системой (почти так же, как и на практике).

Применение прецедентов. Рисуются схемы с факторами; в овале пишется вид выполняемого ими действия.

Обыгрывание ролей. Этот способ позволяет разработчику прочувствовать проблемы пользователя. Разработчик на время становится на место клиента; причем можно заранее написать сценарий для программистов, по которому они попытаются выполнить действия пользователей.

Также очень эффективным способом является составление сценариев на основе CRC-карточек, которые описывают объект, его поведение и взаимодействие с другими объектами системы. Участники делят карточки между собой и используют их для ролевой игры, выполняя действия согласно предписаниям. Это эффективный способ для выявления проблем проектирования системы.

Прототипы требований. Прототип требований к ПО - это частичная реализация системы, созданная для того, чтобы помочь разработчикам, пользователям и клиентам точнее определить требования к системе. Этот метод также помогает решить проблему «да, но...» [3].

Таким образом, на базе знаний по составлению требований к ПО и при их корректном постоянном применении разработчик лучше поймет проблемы клиента и, как следствие, создаст качественный программный продукт, отвечающий потребностям пользователей, снизит риск краха проекта из-за функционального несоответствия приложения.

Контрольные вопросы

1. Что такое жизненный цикл программного обеспечения?

2. Каковы основные свойства каскадной (итерационной) модели жизненного цикла?

3. Из каких этапов состоит модель жизненного цикла UML?

4. Какой жизненный цикл используется при создании ПО фирмой Microsoft?

5. В чем специфика разработки ПО фирмой Microsoft?

6. Какова стоимость исправления ошибок в ПО на различных стадиях его разработки?

7. Что такое «управление требованиями»?

8. В чем заключается анализ проблемы?

9. Кто является пользователем программы и заинтересованным в ее создании лицом?

10. Какие виды ограничений на создаваемое ПО необходимо выявить в процессе работы над требованиями?

11. Каковы существующие атрибуты функций?

12. Каковы существующие методы выявления требований к ПО?

3. Проектирование программ

Начала унифицированного языка моделирования UML

Прежде чем начинать разработку хоть сколько-нибудь сложных приложений, нужно хорошо проработать план действий. Если у вас нет тщательно продуманного сценария, команда разработчиков напрасно потратит время и деньги и, что хуже всего, конечный результат может совершенно не отвечать предъявляемым требованиям. Тогда применяется унифицированный язык моделирования UML (Unified Modeling Language). Технология UML, одобренная консорциумом Object Management Group, является мощным средством описания бизнес-процессов и представления их в той форме, которая устраивает как разработчиков, так и пользователей.

Язык UML предлагает набор инструментальных средств, позволяющих проводить всесторонний анализ сложных проектов как с технической точки зрения, так и с точки зрения потребностей бизнеса. Данный язык упрощает процесс проектирования, снижает его стоимость и повышает эффективность. Концепция UML позволяет разработчикам определять методы технически сложных приложений, которые будут выполняться в многоуровневой распределенной среде.

Достоинства: стандартная методология; интуитивно понятные обозначения, мощные описательные средства языка; автоматическая генерация кода [12].

Модель - упрощенное представление реальности. С точки зрения программирования модель - это чертеж системы. Моделирование необходимо для решения следующих задач:

визуализации системы:

определения ее структуры и повеления:

получения шаблона, позволяющего затем сконструировать систему;

документирования принимаемых решений, используя полученные модели.

Перечислим принципы моделирования.

Выбор модели оказывает определяющее влияние на подход к решению проблемы.

Каждая модель может быть воплощена с разной степенью абстактности.

Лучшие модели те, которые ближе к реальности.

Нельзя ограничиваться одной моделью.

Унифицированный язык моделирования является графическим языком для визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению. С помощью UML можно разработать детальный план создаваемой системы, отображающий не только концептуальные элементы, такие, как системные функции и бизнес-процессы, но и конкретные особенности реализации, в том числе классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования [2].

Язык UML состоит из словаря и правил, позволяющих комбинировать входящие в него слова и получать осмысленные конструкции. Язык моделирования, подобный UML, является стандартным средством для составления чертежей программною обеспечения.

Моделирование необходимо для понимания системы, при этом единственной модели никогда не бывает достаточно. Напротив, для понимания любой нетривиальной системы приходится разрабатывать большое количество взаимосвязанных моделей. В применении к программным системам это означает, что необходим язык, с помощью которого можно с различных точек зрения описать представления архитектуры системы на протяжении цикла ее разработки.

Проблемы, решаемые с помощью UML.

1. Обмен мнениями между программистами возможен только тогда, когда все говорят на одном языке.

2. Становится возможным понять структуру системы, что нельзя сделать, просматривая код. Графически описанная система легко поддается восприятию.

3. Информация о разрабатываемой модели не будет утеряна со временем.

Строительные блоки UML:

· сущности:

· отношения;

· диаграммы.

Сущности - это абстракции, являющиеся основными элементами модели. Сущности бывают четырех типов: структурные, поведенческие, группирующие и аннотационные.

Различают следующие структурные сущности: Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором обычно записаны его имя, атрибуты и операции (рис. 3.1).

WINDOW
Width Heigth
Close () Open ()

Рис. 3.1 Графическая итерация класса

Интерфейс (Interface) - это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Графически интерфейс изображается в виде круга, под которым пишется его имя (рис. 3.2).

Размещено на http://www.allbest.ru/

ISpelling

Рис. 3.2 Графическая интерпретация класса

Кооперация (Collaboration) определяет взаимодействие: она представляет собой совокупность ролей и других элементов (в частности, классов), которые, работая совместно, производят некоторый общий эффект. Изображается в виде эллипса, ограниченного пунктирной линией, а в центре - имя.

Прецедент (Use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера, (Actor). Изображается в виде эллипса, ограниченного сплошной линией, а в центре - имя (рис. 3.3).

Рис. 3.3 Графическая интерпретация прецедента

Активным классом (Active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (Threads), и поэтому могут инициировать управляющее воздействие. Активный класс во всем подобен обычному классу, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов. Графически активный класс изображается так же, как простой класс, но ограничивающий прямоугольник рисуется жирной линией, обычно включает имя, атрибуты и операции.

Компонент (Component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Компонент, как правило, представляет собой физическую упаковку логических элементов, таких как классы, интерфейсы и кооперации. Графически компонент изображается в виде прямоугольника с вкладками, содержащего обычно только имя.

Узел (Node) - это элемент реальной (физической) системы, который существует во время функционирования программного комплекса и представляет собой вычислительный ресурс, обычно обладающий, как минимум, некоторым объемом памяти, а часто еще и способностью обработки. Совокупность компонентов может размещаться в узле, а также мигрировать с одного узла на другой. Графически узел изображается в виде куба, обычно содержащего только имя (рис. 3.4).

Перечислим теперь поведенческие сущности.

Взаимодействие (Interaction) - это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких, как сообщения, последовательности действий (поведение, инициированное сообщением) и связи (между объектами). Графически сообщения изображаются в виде стрелки, над которой почти всегда пишется имя соответствующей операции.



Рис. 3.4 Графическая интерпретация узла

Автомат (State machine) - это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автомата можно описать поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы (из одного состояния в другое), события (сущности, инициирующие переходы) и виды действий (реакция на переход). Графически состояние изображается в виде прямоугольника с закругленными углами (рис. 3.5).

Размещено на http://www.allbest.ru/

Рис. 3.5 Графическая интерпретация класса

Классы. Класс изображается в виде прямоугольника, поделенного на несколько частей. В самой крупной абстракции указывается только имя класса (рис. 3.6).



Рис. 3.6 Графическая интерпретация абстракции

При более детальном описании класса нужно указать атрибуты и операции, выполняемые классом (рис. 3.7).

Rectangle
Width Heigth
Add () Move ()

Рис. 3.5 Летальное описание класса

Существуют также обязанности класса - это то, что должен делать класс, для чего его создают.

Если в проект входит нечто большее, нежели пара несложных классов, следует позаботиться о сбалансированном распределении обязанностей. Это значит, что надо избегать слишком больших или, наоборот, чересчур маленьких классов. Каждый класс должен хорошо делать что-то одно.

Если абстрактные классы будут слишком велики, то модель будет трудно модифицировать и повторно использовать. Если они слишком малы, то придется иметь дело с таким большим количеством абстракций, что ни понять, ни управлять ими будет невозможно. Язык UML способен помочь в визуализации и специфицировании баланса обязанностей [2].

Моделирование распределения обязанностей в системе включает следующие этапы:

1. Идентификация совокупности классов, совместно отвечающих за некоторое поведение.

2. Определение обязанностей каждого класса.

3. Разбиение классов, у которых слишком много обязанностей, на подклассы и наоборот, объединение крошечных классов с элементарными обязанностями в более крупные.

4. Перераспределение обязанностей так, чтобы каждая абстракция стала в разумной степени автономной.

5. Анализ кооперируемых классов друг с другом и перераспределение обязанностей с таким расчетом, чтобы ни один класс в рамках кооперации не делал слишком много или слишком мало.

Непрограммные сущности

Моделируемые сущности могут не иметь аналогов в программном обеспечении. Например, частью рабочего процесса в модели предприятия розничной торговли могут быть люди, отправляющие накладные, и роботы, которые автоматически упаковывают заказанные товары для доставки со склада к месту назначения. В вашем приложении совсем не обязательно окажутся компоненты для представления этих сущностей [21].

Отношением называется связь между элементами. В объектно-ориентированном моделировании тремя самыми важными отношениями являются зависимости, обобщения и ассоциации. Графически отношение представлено линией, тип которой зависит oт вида отношения.

Зависимостью (Dependency) называют отношение использования, согласно которому изменение в спецификации одного элемента (например, класса Event) может повлиять на другой элемент, его использующий (в данном случае -- класс Window), причем обратное не обязательно. Графически зависимость изображается пунктирной линией со стрелкой, направленной от данного элемента на тот, от которого он зависит. Используйте зависимости, когда хотите показать, что один элемент использует другой.

Чаще всего зависимости применяются при работе с классами, чтобы отразить в сигнатуре операции тот факт, что один I класс использует другой в качестве аргумента.

Обобщение (Generalization) - это отношение между общей сущностью (суперклассом, или родителем) и ее конкретным воплощением (субклассом, или потомком). Обобщения иногда называют отношениями типа «является», имея в виду, что одна сущность (например, класс BayWindow) является частным выражением другой, более общей (например, класса Window). Другими словами, потомок может быть подставлен вместо родителя. При этом он наследует свойства родителя, в частности, его атрибуты и операции. Часто, хотя и не всегда, у потомков есть свои собственные атрибуты и операции, помимо тех, что существуют у родителя. Операция потомка с той же сигнатурой, что и у родителя, замещает операцию родителя; это свойство называют полиморфизмом (Polymorphism). Графически отношение обобщения изображается в виде линии с большой незакрашенной стрелкой, направленной на родителя. Применяйте обобщения, когда хотите показать отношения типа «родитель/потомок» (рис. 3.6).

Рис. 3.6 Обобщение

Ассоциацией (Association) называется структурное отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа. Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Ассоциация, связывающая дна класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются парными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. Используйте ассоциации, когда хотите показать структурные отношения.

Помимо описанной базовой формы существуют четыре наполнения, применимых к ассоциациям.

Имя. Ассоциации может быть присвоено имя, описывающий природу отношения. Для того чтобы избежать возможных двусмысленностей и понимании имени, достаточно с помощью черною треугольника указать направление, в котором оно должно читаться.

Роль. Класс, участвующий в ассоциации, играет в ней некоторую роль. По существу, это «лицо», которым класс, находящийся на одной стороне ассоциации, обращен к классу с другой ее стороны. Вы можете явно обозначить роль, которую класс играет в ассоциации.

Кратность. Ассоциации отражают структурные отношения между объектами. Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается как выражение, значением которого является диапазон значений. Каждому объекту на одном конце ассоциации должно соответствовать такое же количество объектов на другом конце. Кратность можно задать равной единице (I), можно указать диапазон: «ноль или единица (0..I). Разрешается также указывать определенное число (например, 3).

Агрегирование. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа «часть/целое», при котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа «имеет» (с учетом того, что объект-целое имеет несколько объектов-частей).

Правила UML позволяют определить [2]:

· имена, которые можно давать сущностям, отношениям, диаграммам;

· область действия (контекст, где имя имеет значение);

· видимость (когда имена видны и могут использоваться другими элементами);

· целостность (как элементы должны соотносится друг с другом);

· выполнение (как элементы выполняют или имитируют некоторую динамическую модель).

Различают хорошо оформленные и не хорошо оформленные модели. Ко второму типу относятся модели:

· содержащие скрытые элементы (для удобства восприятия);

· неполные (отдельные элементы пропущены);

· несогласованные (целостность модели не гарантируется).

Диаграммы UML

Диаграмма в UML - это графическое представление набора элементов, изображаемое чаше всего в виде связного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы предлагалают свернутое представление элементов, из которых составлена система. Один и тот же элемент может присутствовать во всех диаграммах или только в нескольких (самый распространенный вариант) или не присутствовать ни в одной (очень редко). Теоретически диаграммы могут содержать любые комбинации сущностей и отношений [2]. Таким образом, в UML выделяют девять типов диаграмм:

· классы;

· объекты;

· прецеденты;

· последовательности;

· кооперации;

· состояния;

· действия;

· компоненты;

· развертывания.

В процессе моделирования человек упрощает реальное, чтобы лучше понять проектируемую систему. Используя UML, можно строить модели из базовых блоков, таких как классы, интерфейсы, кооперации, компоненты, узлы, зависимости, обобщения и ассоциации. Диаграммы позволяют обозревать эти строительные блоки в удобной для понимания форме

При разработке программ необходимо руководствоваться следующими правилами:

1. Надо помнить, что цель создания диаграмм на языке UML - не рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммы - это только одно из средств, помогающих привести разработку программной системы к успешному завершению. Иногда стоит создавать их «на лету» - путем опроса элементов модели и использовать для анализа системы по мере построения. Многие диаграммы такого рода можно будет удалить после того, как они выполнят свое назначение (хотя семантика, лежащая в их основе, остается частью модели).

2. Следует избегать избыточных диаграмм, они только загромождают модель.

3. Каждая диаграмма должна содержать только необходимые детали. Лишняя информация отвлекает внимание от более важных элементов модели.

4. Диаграммы не должны быть слишком краткими, только если объект не требует представления на очень высоком уровне абстракции. Чрезмерное упрощение может скрыть детали, важные для понимания модели; необходимо поддерживать баланс между структурными диаграммами и диаграммами поведения. Лишь очень немногие системы являются только статическими или только динамическими.

5. Не следует делать диаграммы очень большими (если объем превышает несколько печатных страниц, то это затрудняет навигацию) или очень маленькими (лучше объединить несколько простых диаграмм в одну).

6. У каждой диаграммы должно быть осмысленное имя, ясно отражающее ее назначение.

7. Организация диаграмм осуществляется путем группировки в пакеты в соответствии с представлением.

8. Для форматирования диаграммы необходимо использовать соответствующие инструменты.

Хорошо структурированная диаграмма обладает следующей функциональностью:

· заостряет внимание на одном аспекте некоторого представления системы и содержит элементы, существенные для понимания только этого аспекта;

· содержит детали, соответствующие выбранному уровню абстракции (не загромождена деталями, без которых можно обойтись);

· не настолько лаконична, чтобы ввести разработчика в заблуждение относительно важных аспектов семантики. При изображении диаграммы следует воспользоваться нижеприведенными рекомендациями, в частности:

· присвоить диаграмме имя, соответствующее ее назначению;

· расположить элементы так, чтобы свести к минимуму число пересечений;

· пространственно организовать элементы так, чтобы семантические сущности располагались на диаграмме рядом.

· использовать примечания и цвет, чтобы привлечь внимание читателя к важным особенностям диаграммы.

Диаграммы классов

С помощью диаграммы классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем чаще всего используют этот тип диаграмм. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов.

Диаграммы классов обычно содержат следующие сущности:

· классы;

· интерфейсы;

· кооперации;

· отношения зависимости, обобщения и ассоциации.

Диаграммы объектов

В языке UML статические аспекты строительных блоков системы визуализируют с помощью диаграмм классов. Диаграммы взаимодействия позволяют увидеть динамические аспекты системы, включая экземпляры этих строительных блоков, и сообщения, которыми они обмениваются. Диаграмма объектов содержит множество экземпляров сущностей, представленных на диаграмме классов. Таким образом, диаграммы объектов выражают статическую составляющую взаимодействия и состоят из сотрудничающих объектов, однако сообщения на них не показаны. Диаграмма объектов отражает состояние системы и фиксированный момент времени [2].

На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими «фотографиями» экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.

Диаграммы прецедентов

На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы [2].

Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов системы, и играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая такая диаграмма показывает множество прецедентов, актеров и отношения между ними.

Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (или вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.

Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и для понимания их внутреннего устройства при обратном проектировании.

Предположим, что вы получили по почте загадочное устройство, с одной стороны которого находятся несколько кнопок и маленький жидкокристаллический дисплей. Помимо этого в нем нет ничего примечательного и нет даже намека на то_; как его использовать. Можно, конечно, использовать метод проб и ошибок: произвольно нажимать на кнопки и смотреть, что получится, но таким путем на изучение устройства вам придется потратить много времени.

Программные системы часто выглядят столь же непривычно. Вам как пользователю могут передать некоторое приложение и посоветовать поработать с ним. Если приложение следует принятым соглашениям используемой вами операционной системы, то, может быть, после нескольких попыток вы добьетесь каких-то полезных результатов, но понять более сложные и тонкие аспекты поведения программы вам никогда не удастся. Если вы разработчик, то вам могут передать на сопровождение унаследованное приложение или набор компонентов и сказать, что их надо применить в работе. Вряд ли вы сумеете постичь, как нужно с ними обращаться, пока не сформируете концептуальную модель их работы.

В языке UML диаграммы прецедентов как раз и позволяют визуализировать поведение системы, подсистемы или класса, чтобы пользователи могли понять, как их использовать, а разработчики - реализовать соответствующий элемент.

Диаграммы взаимодействий

Диаграммы последовательностей и кооперации (и те и другие называются диаграммами взаимодействий) относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов. На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними, в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации - на структурной организации посылающих и принимающих сообщения объектов [4].

Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, - и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента.

Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования.

Так, когда человек смотрит фильм в кинотеатре или по телевизору, восприятие его обманывает. На самом деле он видит не непрерывный процесс, как в жизни, а последовательность статичных изображений, меняющихся так быстро, что создастся иллюзия движения.

При планировании съемок фильма режиссеры и аниматоры используют ту же технику, но с меньшим разрешением. Выделяя основные кадры, они строят модель сцены, уровень детализации которой достаточен для того, чтобы определить роли всех участников съемочной команды. Фактически создание сценария - это ключевой момент кинематографического процесса, поскольку он помогает визуализировать, специфицировать, конструировать и документировать фильм.

...