Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 111
Текст из файла (страница 111)
Если вы моделируете быстро и охватываете моделью самую суть приложения, никому и в голову не придет сказать такое. 464 Глава 21 ° Итерационная разработка Разработка приложения связана с определенными рисками. Итерации должны быть структурированы таким образом, чтобы самые серьезные угрозы устранялись в первую очередь. Таблица 21.1. Ключевые понятия главы риски разработки интеграция итерация итерационная разработка моделирование прототип быстрое прототипирование тестирование водопадная модель Библиографические замечания [Еаппап-03] содержит подробный рассказ об истории итерационной разработки со множеством ссылок.
Литература [ВгооЫ87) Ргег[епс[г Р. Вгоо[гз, ]г. Хо гй!чег Ьц!!ег; Еззепсе апг[ ассЫепгз о1 во[гааге епЕбпеепп8. 1ЕЕЕ Согпрцгег, Арп! 1987, 10 — 19. [1 аппап-03] Сга18 1аппап апд 'ч'!стог К. Вагй10 1гегабче апг[ гпсгегпепга1 дече!ор~пепг: а Ьпе1 Л1згогу. 1ЕЕЕ Согпрцгег, ]цпе 2003, 47 — 56.
[КцптЬац8Ь-05] ]апгез КцгпЬац8Ь. ТЬе 11п111ец Мог[е!1пб Ьап8цабе Ке[егепсе Мапца1, 5есопг[ Ег[1т1оп. Возтоп: Аг[йзоп-'ьтгез!еу, 2005. [5ог1гочзЫ-01] 13газ[го 5ог[гочзЫ. Нецпзбсз 1ог Кегабче зоКцаге г[ече!орптепк 1ЕЕЕ 5ойъаге, Мау/[цпе 2001, 66 — 73. Управление моделированием;.''."',"',",,':::~ ъ'~~==:-":-:;.=,"","-.'."' Моделирование необходимо для разработки качественного программного обеспечения, но перейти к его практическому применению может быть довольно сложно. Можно искренне хотеть работать с моделями, но затягивать их фактическое использование. Моделирование требует изменений культуры, которые должны активно стимулироваться самой организацией. 22.1. Обзор управления моделированием Мы часто сталкиваемся с тем, что сотрудники организации хотят использовать модели в своей работе, но не знают, с чего им следует начать.
В атой главе мы рассказываем о том, каким образом можно внедрить моделирование на предприятии. Здесь мы затронем следующие темы: ° виды моделей (раздел 22.2); ° ловушки моделирования (раздел 22.3); ° сеансы моделирования (раздел 22.4); ° организация персонала (раздел 22.5); ° методики изучения (раздел 22.6); ° методики обучения (раздел 22.7); ° технические средства (раздел 22.8); ° оценка затрат на моделирование (раздел 22.9). 22.2. Виды моделей Используемые на практике модели можно разделить на несколько категорий, каждая из которых обладает своим назначением, характеристиками и содержанием. 466 Глава 22 ° Управление моделированием часто путают модели между собой н забывают о причинах, по которым опи ли создавать модель определенного типа. Модель приложения. Это одна из наиболее распространенных моделей, о которой и рассказывается в нашей книге. Модель приложения помогает разработчикам понять требования и закладывает фундамент для построения соответствующего приложения.
В качестве примера можно привести наш пример с банкоматом. Метамодель. Метамодели подобны моделям приложений, но сложнее их. Они часто используются для сложных приложений. В качестве примера можно привести каркасы (глава 14) и редактор моделей классон.
Модель предприятия. Такая модель описывает целую организацию или какой-либо важный ее аспект. Модели приложений и метамодели используются для построения программного обеспечения. Модели предприятий предназначены совсем для другой цели, а именно для согласования концепций между несколькими приложениями и для понимания устройства предприятия. По своей природе модели предприятия имеют более широкую область охвата по сравнению с моделями приложений, но они редко оказываются более глубокими, так как им нужно описать только наиболее типичные аспекты.
В качестве примера можно привести модель всего программного обеспечения какого-либо банка. Оценка продукта. Модели можно использовать при приобретении программного обеспечения. Вам нужно подготовить несколько моделей: модель ваших требований и модель программы для каждого из конкурирующих продуктов. Модель требований отличается от модели приложения только тем, что в ней могут отсутствовать мелкие детали, так как вы не собираетесь создавать по ней само приложение. Производители редко предлагают модели своих продуктов, но вы часто можете создать свою собственную модель при помощи инженерного анализа (гечегзе епя1пеег1пя— 1В!а11а-041). Модель поможет вам оценить качество приложения и понять его сильные и слабые стороны, а также область его применения. В качестве примера можно рассмотреть такую ситуацию. Если вы хотите купить программное обеспечение для банкомата, вместо того чтобы писать его самостоятельно, модель поможет вам сделать выбор. Люди реши 22.3.
Ловушки моделирования Преимушества моделирования неоспоримы, но у него есть и недостатки, которые нужно стремиться обойти. ° Паралич анализа. Некоторые разработчики так глубоко уходят в моделирование, что им не удается его закончить. Такое часто случается с аналитиками, которые не занимаются собственно разработкой. Бывает зто и с теми, кто только начинает заниматься моделированием, делает это неэффективно и не знает, когда его можно считать завершенным.
22.3. Ловушки моделирования 467 Решение: план проекта поможет вам избежать паралича на этапе анализа благодаря выделению определенного времени под конкретные задачи. План должен предусматривать затраты на моделирование и ожидаемый выход. Оценку качества модели и степени выполнения проекта вы можете получить при помощи формальных обзоров. Это полезно, если у тех, кто занимается моделированием, есть опыт разработки. Параллельное моделирование. Нам приходилось сталкиваться с тем, что организации строили «запасные» модели, основанные на разных парадигмах. Часто бывает, что объектно-ориентированное моделирование осуществляется параллельно с моделированием баз данных без всякого взаимодействия между командами разработчиков.
В командах объектно-ориентированных разработчиков большинство программистов не разбираются в базах данных. Профессионалы по работе с базами данных используют свои привычные методики и часто незнакомы с объектно-ориентированной методологией. В литературе между двумя концепциями лежит такая же пропасть: как сообщество объектно-ориентированных программистов, так и сообщество специалистов по базам данных имеет свой собственный стиль и жаргон, и лишь немногие специалисты могут считать себя принадлежащими к обоим лагерям одновременно.
Ограничения существующих средств разработки еще более усиливают разделение. Решение: как ни странно, проблема больше в терминологии и в стиле, а не в сути дела. Лучше всего просто не забывать о различиях культур. Пусть разработчики создают модели обоих типов, если им это удобно. Это один из способов обойти недостатки современных средств. Самое главное, чтобы разработчики работали с моделями. Если эти модели разные, то нужно, чтобы они часто согласовывались между собой. Здесь помогает итерационная разработка — разработчикам приходится согласовывать усилия на каждой итерации. Неспособность мыслить абстрактно.
Многим людям трудно мыслить абстрактно. Они неспособны научиться искусству моделирования. Они быстро переходят в режим программирования и не могут отойти от задачи на шаг и взглянуть на нее в целом. Решение: единственное лекарство — как можно больше практики. Неопытным разработчикам, которые учатся моделировать, нужно решать упражнения. Они должны работать с реальными приложениями под руководством опытного наставника. Те, кто так и не научатся моделировать, должны быть задействованы в других задачах. Избыточная область охвата.
Модель должна отражать реальный мир, но лишь ту его часть, которая имеет отношение к вашим целям. Некоторые разработчики склонны к утрате сосредоточения, они помещают в свои модели много избыточных сведений. В принципе, неплохо охватывать моделью чуть больше, чем нужно для конкретного приложения, потому что до его создания точные его границы предсказать трудно. Но не стоит пытаться охватить гораздо больше, чем требуется, потому что такая модель будет спекулятивной и на ее основе тяжело будет создать что-то полезное. 468 Глава 22 ° Управление моделированием Решение: чтобы обойти эту ловушку, используйте план проекта и проводите регулярные проверки (рецензирование). Эксперты по бизнесу должны понимать, чем занимаются разработчики модели, потому что таким образом они будут получать представление о возможностях и ограничениях создаваемого приложения.
° Недостаток документации. Слишком часто нам приходится сталкиваться с недокументированными моделями. Одних диаграмм недостаточно, к ним нужны пояснения. Комментарий должен объяснять читателю суть каждой диаграммы и определять используемую терминологию. Он должен разъяснять тонкости и обосновывать все противоречивые решения, а также описывать примеры, иллюстрнруюшие трудные вопросы.
Решение: вы должны настаивать на том, чтобы модели документировались комментариями или словарями данных. Не ленитесь читать этп комментарии. ° Недостаток технического рецензирования. Так же часто мы сталкиваемся с недостатком технического рецензирования. Каждый сотрудник или небольшая группа работает в одиночку и не хочет делиться своим опьпом, знаниями и талантом. Разработчики не обсуждают друг с другом свои проекты, потому что обсуждение не влияет на подлежашие сдаче объемы работ и не поощряется руководством. Подобно тому, как эксперты по бизнесу являются источником требований к приложению, коллепоразработчикп могут рассказать вам много полезною о методах вычислений и о том опыте, который они приобрели в родственных приложениях. Формальные осмотры (рецензии) помогают устранить ошибки еше до этапа тестирования.
Решение: каждый проект должен пройти рецензпрование хотя бы один раз, а лучше — несколько. Если осмотр один, его следует осуществить после завершения основы модели и архитектуры. Если осмотров будет несколько, их следует проводить после завершения моделирования и разработки архитектуры на каждой основной итерации. Руководству следует поддерживать свободный, критический и конструктивный стиль общения. Оно должно сделать финансирование проекта зависящим от рецензирования.
Помните, что рецензии должны быть техническими, а не менеджерскими, то есть ориентированными на углубление технологии, а не на информирование руководства. В статье [Воеппм01] отмечается, что экспертная опенка позволяет обнаружить 60 Ы ошибок в программном обеспечении, поэтому техническое рецензнрование, несомненно, является достаточно важным. Мы рекомендуем делать совешания, посвященные техническим осмотрам, небольшими (не более 10 человек) и приглашать на них только тех, кто активно участвует в проекте.
22.4. Сеансы моделирования В главе 12 мы рассказывали об анализе предметной области — построении моделей реального мира, с помошью которых проясняются требования приложения. Когда вы приобретете опыт моделирования, вы сможете использовать другие 22.ч. Сеансы моделирования 469 методы взаимодействия с пользователями для получения от них необходимых входных данных.
Мы рассмотрим три альтернативы: скрытое моделирование, циклическое моделирование и моделирование на месте (чв прямом эфиреь), обсудим их преимущества и недостатки. 22.4.1. Скрытое моделирование Самый популярный подход к моделированию выглядит так. Сначала разработчик общается с экспертами, записывает их комментарии (сформулированные требования или описания вариантов использования), а затем уходит к себе и занимается моделированием. Многие аналитики выбирают именно этот подход, потому что они могут сосредоточиться на словах пользователя во время общения с ним, а потом спокойно заняться самой моделью в одиночестве.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
