CC BY
37
[®] Кафедра молодых
От программистов часто приходится слышать, что разработка моделей бессмысленна, Рассмотрим основные доводы, приводимые в этом случае:
• Разработка моделей - очень длительный и неинтересный процесс. Однако графические модели в ¡.Portal MSE служат основой для генерации каркаса приложения. Написание вручную большого числа вспомогательных артефактов системы приводит к большому объёму механической работы, при которой допускается множество ошибок.
• Модели нужны лишь для документирования, они не имеют реальной ценности для программиста, так как Java-код сам по себе является моделью данных. При такой точке зрения не учитываются два важных аспекта. Во-первых, графические модели гораздо более наглядны для ключевых пользователей заказчика, чем словесное описание и уж, тем более, программный код. Это позволяет общаться с представителями заказчика на «одном языке» и как следствие выявить большинство особенностей и требований системы на этапе проектирования. Во-вторых, программный код является удобной для чтения моделью лишь в случае, когда используются достаточно простые шаблоны работы с данными. В случае использования сложных многоуровневых моделей разработки не всегда достаточно легко представить модель данных из кода системы.
• Модель является упрощением реальной ситуации, невозможно сгенерировать из модели реальное приложение. В какой-то мере этот довод является верным. Однако в ¡.Portal MSE предполагается лишь генерация каркаса приложения с последующей его доработкой командой разработчиков. Кроме того, в реальной жизни большая часть функционала программного продукта имеет достаточно регулярную структуру. Так, в частности, рассмотренный выше пример с управлением справочниками подразумевает использование стандартных элементов управления, ручное создание которых потребовало бы много механической работы по кодированию.
Главным преимуществом, которое вносит в разработку веб-приложений второй этап ¡.Portal MSE, является использование во всех приложениях типовых шаблонов проектирования и реализация программных компонентов. Ни для кого не является секретом, что сопровождение разработанных программных решений требует от их владельца значительных инвестиций. Использование типовых шаблонов управления данными позволяет уменьшить время, требуемое на изменение программного кода в соответствии с новыми бизнес-требованиями.
Test-Driven Development (TDD) [6] - одна из наиболее популярных концепций, используемых в настоящее время при разработке приложений. Основа такой популярности TDD - широкое распространение Agile-методик разработки и значительный рост их популярности.
Как было отмечено ранее, при генерации каркаса приложения в ¡.Portal MSE создаётся набор тестов для модульного тестирования приложения [7]. Например, при
создании фабрики для управления жизненным циклом новостей генерируются реализации стандартных методов класса SimpleLifeCycleDactorySupport:
• public abstract Item createlfem(Dn parentDn, Item item);
• public abstract Item deleteltem(ltem item);
• public abstract Item editltem(ltem item).
Эти методы отвечают за создание, изменение и удаление объектов из хранилища данных. Так как это public методы фабрики - в соответствии с TDD для них должны быть подготовлены модульные тесты. Такие тесты как раз и генерируются при создании каркаса приложения из модели. Данные тесты требуют специализированной среды исполнения в контексте сервера приложений JBoss, что как раз и учитывается при их генерации.
Почему ¡.Portal MSE включает в себя TDD?
Во-первых, третий этап описываемой технологии подразумевает использование Agile для реализации каркаса. А большинство Agile-техник требуют использования тестов для верификации программного кода.
Во-вторых, любое применение рефакторинга к программному коду требует наличия тестов для проверки его работоспособности [8]. Чем более полным является набор тестов для приложения, тем более «агрессивный» рефакторинг допустимо применять к программному коду. Например, все современные среды разработки позволяют применять шаблон рефакторинга «переименование метода». Однако это не всегда безопасно. Если этот метод вызывается через java reflection, то среда разработки не сможет установить этот факт и изменить исходный код. Соответственно в данной ситуации может возникнуть ошибка, которая достаточно легко может быть найдена на уровне модульного тестирования.
В-третьих, написание тестов по своей сути является одной из моделей документирования исходного кода. В данном случае под документацией понимается набор исполняемых файлов, представляющих собой исполняемую спецификацию продукта. Тем самым получается, что внесение изменений в программный продукт начинается с изменения тестов, что приводит к переходу в красную стадию разработки, когда некоторые из тестов не проходят. После исправления исходного кода переходят к зелёной стадии, когда все тесты проходят успешно. А уже далее применяют рефакторинг для повышения качества и читаемости кода приложения.
В-четвёртых, модульное тестирование позволяет снизить общее время отладки приложения за счёт сокращения времени на локализацию и исправление ошибок. Особенно это важно при внесении изменений в функционирующую систему.
В-пятых, тесты служат отличной основой для формирования многих метрик по проекту, Так, общее количество тестов характеризует объём реализуемого кода, Соотношение между числом public-методов и тестов характеризует степень покрытия тестами функционала системы, В соответствии с ¡.Portal MSE оно должно превышать
молодых
80%. Совокупное время выполнения всех тестов может служить мерой эффективности написанного кода и.т.д.
Кроме модульных тестов обязательной составляющей разрабатываемого решения должны являться функциональные тесты. Базовый набор шаблонов таких тестов также генерируется на втором этапе ¡.Portal MSE. Однако сгенерированные тесты данного типа нельзя рассматривать как законченное решение. Это объясняется тем, что в большинстве случаев сгенерированный каркас потребует значительных изменений интерфейса для удовлетворения требований дизайнеров проекта. При этом придется полностью изменять набор функциональных тестовых скриптов. Это изменение в соответствии с моделью разработки i,Portal MSE обязательно.
Внедрение ¡.Portal MSE в компании по разработке программного обеспечения может столкнуться с целым рядом сложностей как человеческого, так и технического характера. К первым относится как стремление использования только Agile-методик, когда первый этап ¡.Portai MSE будет отторгаться, так и стремление к классическим «тяжеловесным» процессам разработки, где не требуется написание большого количества тестов. Проблемы данного рода разрешаются менеджментом проекта по разработке через обучение персонала, рассматриваемой технологии для иллюстрации её возможностей. Хорошо себя зарекомендовало проведение краткосрочных одно-двухдневных тренингов/деловых игр по разработке командой тестового приложения.
Также проблемы данного рода позволяет решить введение чётких измеряемых метрик на всех стадиях проекта. Например, на третьем этапе такой метрикой может служить степень покрытия тестами программного кода проекта, а на первом - наличие базовых Use-Case-диаграмм для диаграмм классов.
Технические сложности заключаются, как правило, в наличии у команды уже готовых проектов и унаследованного исходного кода. Встраивание ¡.Portal MSE в уже существующие проекты очень сложно, так как зачастую
требует значительного изменения уже существующего кода. Однако при создании нового функционала в дополнение к уже существующему это возможно,
Для успешного внедрения ¡.Portal MSE необходимо участие в этом всей команды разработчиков, от которых требуется готовность следовать достаточно жестким ограничениям, накладываемым на архитектуру системы и программный код. Только в этом случае возможно повышение эффективности работы команды в целом, а как следствие и улучшение качества и скорости разработки ПО.
Библиографический список
1. Кулешов И, «Язык BPEL в системах автоматизации бизенс-процессов: общая схема решения и опыт реализации» II Материалы конференции SECR2006. - М., 2006.
2. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides «Design Patterns; Elements of Reusable Object-Oriented Software». - Addison-Wesley, 1995.
3. ¡.Portal, Система управления содержимым сайтов. Руководство администратора. - Иркутск., 2005.
4. Мартин Фаулер «Новые методологии программирования»,http://www.silicontaiga.ru/home.asp7artld =4889
5. Kent Beck, Cynthia Andres «Extreme Programming Explained: Embrace Change. 2-nd edition». - USA, Addison-Wesley Professional, 2005.
6. Сергей Белов «Модульное тестирование и Test Driven Development» II Материалы конференции SECR2006. - М., 2006.
7. Andrew Hunt, David Thomas «Pragmatic Unit Testing in Java with JUnit», - USA, The pragmatic bookshelf, 2003.
8. Martin Fowler, Kent Beck, John Brant, William Op-dyke, Don Roberts «Refactoring: improving the Design of Existing Code». - USA, Addison-Wesley Professional, 1999.
Статья принята к публикации 20.12.06
В.А. Шакуров
Программная поддержка принятия решений по разме щенню энергетических объектов
Размещение энергетических объектов, таких как электростанция, линия электропередачи, является сложной комплексной проблемой. Риск и потенциальные последствия любого конкретного решения очень велики, что обуславливает необходимость проведения формализованного анализа вопроса.
Целью исследования была разработка системы поддержки принятия решения (СППР), способной учесть многочисленные факторы и цели, неопределенность в
оценке воздействий при размещении энергообъектов. В результате, предложены и реализованы в виде программ для ЭВМ многокритериальные подходы к решению следующих задач.
1. Идентификация возможных площадок для размещения энергетических объектов. При идентификации необходимо выделить лучшие площадки для предполагаемого объекта. Разработанная СППР БЖпдЕР выполняет отбор с одной стороны путем учета нормативных требо-
Кафедра молодых
ваний, с другой - путем учета ценностных установок, сформулированных лицом, принимающим решение (ДПР). Для учета ценностных суждений ДПР используются многокритериальные модели компенсационного и сравнительного отбора, метод последовательного сужения множества Парето. В СППР SitingEF реализовано использование моделей отбора в определенной последовательности с реализацией информационного обмена. Проведенное исследование по идентификации площадок в энергодефицитном районе Читинской области показало эффективность такого подхода. Повышена результативность исключения площадок. Для отбора требуется меньше дополнительной информации о местности. Использование сочетания моделей отбора не связано с увеличением загрузки ДПР благодаря информационному взаимодействию моделей.
2. Многокритериальный выбор одной из отобранных при идентификации площадок. Выбор в SitingEF проводится на основе метода MAUT (Multi-Attribute Utility Theory) с использованием процедур, направленных на снижение загрузки ДПР. Применены полученные в теории полезности теоремы и следствия, позволяющие значительно сократить число проверок критериев на независимость по предпочтению. Используется информация об отношении ДПР к риску, что позволяет упростить построение функций полезности. При сохранении достоинств метода повышена его гибкость, снижена загрузка ДПР.
Для оценки работы парка машин предложено много показателей, что создает трудности при выборе наиболее эффективных вариантов его использования ввиду возможной противоречивости показателей. При оценке эффективности техники важно решение проблемы соизмерения разнокачественных затрат и результатов. Подходы к соизмерению затрат и результатов на основе оптимизационных моделей рассматривались в работах Л.В. Канторовича, В.В. Новожилова, В.Н Лившица, АЛ Лурье и др. Известно, что в модели оптимальной структуры машинного парка, описываемой с достаточной степенью приближения линейно-программной задачей, наряду с амортизационными отчислениями, входящими в себестоимость работ, учитывается и нормативный экономический эффект от применения приобретаемой техники.
Решение на модели оптимизации структуры парка позволяет определить не только оптимальную политику пополнения и использования парка, но и оценки в единицах измерения целевой функции всех учитываемых в
3. Многокритериальный выбор конфигурации электрической сети. Разработанный для решения задачи
программный комплекс OptiLine использует метод последовательных уступок. Производятся учет основных технических особенностей проблемы и целенаправленная минимизация потерь активной мощности. При выборе конфигурации выполняются требования ПУЭ в отношении надежности электроснабжения потребителей.
4. Многокритериальный выбор трассы ЛЭП. Рассматриваемый район в SitingEF разбивается сеткой на участки сравнительно малой площади. Производится ранжирование всех участков в соответствии с предпочтениями ЛПР на основе метода MAUT. Оценки участков позволяют определить наиболее приемлемый вариант трассы ЛЭП.
Многокритериальные подходы к решению задачи размещения энергетических объектов позволяют учесть множественность целей при развитии энергосистемы. Формализация анализа позволяет повысить качество, обеспечить доводами и основаниями при принятии решений.
Программный комплекс прошел официальную регистрацию в федеральной службе по интеллектуальной собственности, патентам и товарным знакам.
Статья принята к публикации 26.09.06
модельный
модели факторов: оценки работ, оценки вклада ресурсов, в том числе трудовых, условий социального характера, оценки времени как фактора производства и оценки используемых машин (оценки фондов). Последние получили название прокатных оценок и представляют собой форму ренты от эксплуатации машин в рассматриваемый период [1, с. 102].
Итак, модели процесса технической обеспеченности производства, являющейся в данном случае задачей линейного программирования, ставится в соответствие двойственная задача:
тахЦу)^Ь,.у1 Ш
при условиях
= = (2)
(=1
Компоненты вектора у ~(у¡,у2><~>Ут ) в Двойственной задаче трактуются как оценки ингредиентов модели, выраженные в единицах ингредиента, выделен-
М.С. Ильина
Прокатные оценки машин и оборудования -подход
