Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 114
Текст из файла (страница 114)
Пользователи могут обратиться к журналу и определить даты изменения файлов и авторов этих изменений. ° Отчет о состоянии. Необходимо иметь возможность уведомлять сотрудников об изменениях. Если моделирование осуществляет один человек, ответственно относящийся к резервному копированию, он может обойтись и без средства управления конфигурациями. По мере увеличения количества моделей и разработчиков такой подход становится все более затрулнительным.
Для управления несколькими моделями и координации усилий нескольких человек нужно использовать средства управления конфигурациями. Наиболее известны )ВМ Каг(опа! С!еагСазе, Мегапт РНСЯ, М(сгозо(г Н!зпа! ЯоцгсеЯаге, СНЯ. 22.8.3. Генераторы кода Многие средства моделирования позволяют генерировать код приложения. Обычно такое средство может генерировать объявления данных для программного кода и для базы данных (если вы работаете с ней). Некоторые средства могут генерировать и алгоритмы, но эту задачу автоматизировать сложнее. Например, такое средство может генерировать программный код по диаграмме состояний.
22.8. Средства 477 Независимо от используемого средства разработчики должны с осторожностью относиться к генерированному коду, проверять его на правильность и эффективность. Некоторые средства генерируют плохой код с малозаметными ошибками. Другие средства, к нашему удивлению, допускают грубые ошибки в коде.
Если программисты будут читать код, генерируемый программным средством, опп будут лучше представлять, что именно оно делает. 22.8М. Средства интерпретации моделей Для предсказания поведения и производительности готового приложения можно использовать средства симуляции моделей. Некоторые средства моделирования содержат встроенные механизмы для этой цели. В качестве примера можно привести программу е Еоп1х Ягатешаге, которая может симулировать диаграммы состояний.
22.8.5. Репозиторий Репознтории важны для разработки при.ложений, потому что в нпх хранятся метаданные, позволяющие различным средствам взаимодействовать друг с другом. Репозиторий является посредником между программными средствами. Поскольку репозиторий работает с метаданными, внедрить его довольно сложно, по зато работа с ним может увеличить эффективность остальных средств. Репозитории производятся АИеп Яуэгеш Сгоцр, Сошрцгег Аьвос1агез,! ВМ и Мьсгоэой.
22.9. Оценка затрат на моделирование Разработка программы — это коммерческое предложение. Бизнесмены оценивают затраты на создание программы, ожидаемую выручку и экономию. Моделирование обычно составляет малую часть (гораздо менее 10 ч') общих затрат на создание приложения. Затраты на моделирование зависят от следующих факторов. ° Сложность приложения. Конкретные приложения всегда проще, чем абстрактные. Проще создать программу для обработки звонков клиентов, чем создать систему для всех видов взаимодействия с клиентами. ° Профессионализм. Опьггный разработчик может работать на порядок быстрее неопытного.
Кроме того, опытный разработчик скорее создаст качественную модель с правильным абстрагированием. ° Средства. Хорошо, если разработчик может работать с мощным средством моделирования и умеет зто делать. ° Размер модели. Время на создание модели нелинейно возрастает с ее размером. Можно считать, что время создания пропорционально количеству классов в степени 1.5. Таким образом, создание молели с 500 классами требует в 30 раз больше времени, чем создание модели с 50 классами. ° Рецензирование. Рецензирование сокращает количество итераций, необходимых для построения модели.
С учетом всех этих факторов большинство моделей создаются за срок от двух недель до шести месяцев. 478 Глава 22 ° Управление моделированием 22.10. Резюме В этой главе мы рассмотрели несколько тем, призванных помочь внедрению технологии моделирования на предприятии. Модели можно разбить на несколько категорий, с разным назначением, характеристиками и содержанием. Многие разработчики не учитывают это. Например, модель предприятия не может содержать все особенности приложений, потому что иначе она станет неудобной.
Модели могут использоваться для оценки приобретаемых продуктов. Модели обладают множеством достоинств, но, как и любая другая технология, приводят к дополнительным рискам. Мы идентифицировали основные риски и указали действия по их снижению. Существует несколько подходов к взаимодействию с пользователями в процессе моделирования. Мы перечислили некоторые виды взаимодействия (скрытое моделирование, циклическое моделирование, моделирование на месте), их преимущества и недостатки. Чтобы изучить моделирование, сотрудник может прибегнуть к различным методам (обучение, воспитание, командная работа, семинары, непрерывное обучение, техническое рецензирование).
Учить моделированию тоже можно по-разному. Наиболее успешно ознакомление на практике, потому что изучить моделирование можно только в процессе моделирования. Преподавателям следует проводить со студентами практические занятия по созданию моделей и заниматься с ними исправлением ошибок.
Студенты должны понять, что модель всегда можно реализовать. Опытные разработчики моделей могут распознавать и применять образцы. Для разработки серьезного приложения необходимо использовать программные средства. Мы перечислили некоторые существующие программы п указали критерии для их выбора, а также для оценки затрат на моделирование. Библиографические замечания В этой книге мы почти не говорим о вопросах, связанных с управлением, таких как планирование проекта, оценка проекта, оценка затрат, метрики, оценка персонала и динамика команд. Эти важные темы рассмотрены в других книгах, таких как [Ргеюпап-97] и [В]аЬа-01]. В книге [Со!и е11-03] автор описывает свой собственный опыт работы с рецензиями проектов и подчеркивает их важность для качества программ. [Вегпдгззоп-Оч] описывает свой девятилетний опыт преподавания курсов объектно-ориентированного анализа и проектирования.
Он приходит к следующим заключениям: ° Успешность программирования — не индикатор успешности моделирования. 65 7' студентов, успешно завершивших курс объектно-ориентированного программирования, плохо справлялись с объектно-ориентированным моделированием. Литература 479 ° Успешность моделирования может служить индикатором успешности программирования. 84 74 студентов, успешно завершивших курс моделирования, справились и с программированием. ° Основная трудность моделирования — абстрактность. Оценки курса объектно-ориентированного моделирования в высокой степени коррелнруют с курсом распределенных систем (столь же высокий уровень абстрактности).
[Вох-00] заключает, что объектно-ориентированная технология требует более высокого уровня абстрагирования, чем структурное программирование. Изучение абстракции требует значительных усилий. Литература [Вегпг]гззоп-04] Мйае! Вегпбгззоп. Тезей!п8 оЬ)ест-опепгед гпог]е1!п8 апб г!еы8п. Ргай рарег, 2004. [В!аЬа-01] М!сЬае] К. В!аЬа. А Мапайег'з ОпЫе го РагаЪазе ТесЬпо!ойу; ВшЫш8 апг] Рпгсйаз1п8 Веггег Арр1кагюпы 1)ррег Яаг]8!е В!тег, Щ: Ргепбсе На!1, 2001. [В1аЬа-04] МкЬае1 В!аЬа.
А соррег Ьп1!ег !ог зойзиаге г!па]йу !шрготешепп 1ЕЕЕ Согпрпгег, ГеЬгпагу 2004, 21 — 25. [ВоеЬш-01] Ваггу Воейш апд Чкгог К. Вая!Ь Яойзчаге де]есс гег!псгюп сор 101!зг. 1ЕЕЕ Сошрцгег, ]апцагу 2001, 135 — 137. [Вох-00] Койег Вох апг] МкЬае! ЪЪйе1азч. Ехрег1епсез жЬеп ш!8гаг!п8 1гош зггпсгцгег] апа!уыз го оЬ)есг-оПепгег1 шог]е1!п8, РопггЬ Апзгга!аз!ап Сошрпг!п8 Ег]псабоп Соп[егепсе, Ме!Ъопгпе, Апзгга!!а, РесешЬег 4 — 6, 2000, 12 — 18. [Со!ве!1-03] ВоЬ Со!ч е!!. Рея8п геч!еды 1ЕЕЕ Согпрптег, ОстоЬег 2003, 8 — 10. [Ргезяпап-97] Войег 8. Ргезяпап.
5ойшаге Еп81пеег!п8: А Ргасг!г1опег'з АрргоасЬ, Еопггй Ег]!г!оп. Ь!езч Ъ'ог1г: Мсбгазч-Н!11, 1997. Унаследованные системы Чаще всего разработка — это не создание новых приложений, а усовершенствование существующих. Очень редко приходится творить новое приложение с нуля.
Даже в этом редком случае обычно приходится собирать информацию из существующих приложений и обеспечивать интеграцию с ними. Вы можете использовать технические требования, идеи, данные и код унаследованных приложений. Сложно изменить приложение, если вы не понимаете его устройство. Если приложение было разработано с использованием объектно-ориентированных моделей, причем моделей точных, они помогут вам понять и усовершенствовать это приложение. Если моделей не было или они были утеряны, вам придется начать с построения модели существующей структуры. 23.1.
Инженерный анализ Инженерный анализ (гечегзе еп81пеег1п8) — процесс изучения артефактов реализации и выявления лежащей в их основе логики. Инженерный анализ применялся к аппаратному обеспечению: разгадывание проектов по готовым продуктам было широко распространено 1йекой'-85~. Модели помогают инженерному анализу, потому что они позволяют выражать как абстрактные концепции, так и детали реализации.
При построении новых приложений инженерный анализ позволяет сохранить полезную информацию из старых приложений. Не обязательно увековечивать старые ошибки. Аналитик должен определить, что следует сохранить, а что — отбросить. Модели, полученные в результате такого анализа, следует рассматривать как источник требований для нового приложения. Инженерный анализ требует принятия решений, интерпретации системы разработчиком и поэтому не может быть полностью автоматизирован. Программные средства позволяют механически проанализировать весь объем кода, но им сложно выявить человеческие решения.
Многие средства позволяют генериро- 23.1. Инженерный анализ 481 вать начальную модель, но эта модель будет немногим более, чем визуальным представлением структуры программы. Аналитик должен справиться по мень- шей мере с двумя проблемами: получением малопонятной или утраченной ин- формации и описанием скрытого поведения. 23.1.1.
Инженерный анализ и разработка Таблица 23.1. Инженерный анализ и разработка Разработка Инженерный анализ Разрабо~ать приложение по имеющимся требованиям Более точная. У разработчика есть требования, н он обязан создать приложение, которое будет нм отвечать Предписывающая. Разработчикам говорят, как нм следует работать Более зрелая. Широко доступен опытный персонал Требует времени. Может занимать месяцы н даже годы Определить требования цо имеющемуся приложению Менее точный. Реализация может дать различные требования, в зависимости от интерпретации аналитика Адаптивный. Аналитик должен понять, что именно сделал разработчик Менее зрелый.
Опытные аналитики встречаются редко Может быть выполнен в 10 — 100 раз быстрее, чем разработка (днн нлн недели) Модель может быть несовершенной. Частичная информация все равно будет полезной Модель должна быть коррекгной н полной, иначе приложение не будет работать 23.1.2. Входные данные для инженерного анализа При проведении инженерного анализа нужно быть изобретательным и рассматривать все возможные источники входных данных. Доступная информация сильно зависит от конкретной задачи. ° Программный код. Исходный код программы может быть богатым источником информации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
