3-software_engineering_construction (1133543), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Конструирование программного обеспечения.конструирования. Но, к сожалению, многие забывают о необходимости мотивированностиизменений, даже на уровне рефакторинга. Применение измерений, в частности, метрик, позволяетопределить необходимость внесения таких изменений, проведения рефакторинга. И не потому что“так, наверное, будет всѐ же лучше, красивше...”, а потому, что в иерархии наследования из 10поколений классов – 9 являются абстрактными (“из любви к искусству”), а на 10-м (в силупревышений сроков проекта, после того, как долго и “в кайф” создавали архитектурно-красивый код)“повешено” 20 (!) бизнес-методов. Вот это – действительно обоснованная причина длярефакторинга, который, даже с применением самых совершенных инструментальных средств,вместе с обдумыванием необходимости рефакторинга, а потом, иногда, и борьбой с егопоследствиями из-за несогласованности членов команды (а это уже жизнь, даже в самом идеальномколлективе, где люди понимают друг друга с полуслова) часто является просто тратой времени.Если применяется рефакторинг, но не применяются метрики – в подавляющем большинствеслучаев, это отрицательно влияет на проект.

И таких примеров работ, требующих примененияизмерений, но, к несчастью, игнорирующих их, можно приводить достаточно долго. Вы, наверняка,сами можете рассказать на эту тему много примеров из жизни.Почему “авторизованный перевод” этой темы SWEBOK оказался столь эмоционален? Практикаавтора показывает, что в погоне за “красотой”, разработчики слишком часто забывают о цели ихработы и воспринимают деятельность по управлению проектами (не буду спорить, иногда лишьформальную, для “прикрытия” всего, что только можно …) со стороны менеджеров и, тем более,любой аудит – как однозначную помеху “полѐту мысли”. Зря. Если все именно так обстоит в вашемслучае – проект, с большой вероятностью, а иногда и просто, “если не случится чудо”, можно считатьпусть и не провальным (“фуух...

не закрыли....”), то, наверняка, выйдущим за рамки тех или иныхограничений, будь то сроки, деньги, качество или, наконец, время, которое разработчик мог провестис семьей. И не сидеть ночью, дописывая функциональность или отлавливая очередную ошибку занесколько дней до передачи проекта в эксплуатацию. Все эти вопросы преследуют однуединственную цель – предсказуемость работ и результата. И измерения – важный инструментдостижения этой цели.Область знаний “Software Engineering Process” уделяет специальное внимание вопросам измеренийпри создании программного обеспечения.3. Практические соображения (Practical Considerations)Конструирование – деятельность, в рамках которой программное обеспечение приводится ксоглашению с произвольными (иногда - хаотическими) ограничениями реального мира, которыетребуют от программного обеспечения точного следования им.

Приближаясь к ограничениямреального мира, конструирование (в большей степени, чем любая другая область знаний) ведетсяна основе практических соображений и техник.3.1 Проектирование в конструировании (Construction Design)Некоторые проекты предполагают больший объем работ по проектированию именно на стадииконструирования; другие проекты явно выделяют проектную деятельность в форме фазы дизайна.Вне зависимости от четкости выделения деятельности по проектированию, как таковой, практическивсегда на стадии конструирования приходится заниматься и вопросами детального дизайнасистемы. Такие проектные работы имеют стремление к следованию устойчивым ограничениям,навязываемым конкретными проблемами, решение которых должно быть обеспеченоиспользованием конструируемой программной системы.Детали деятельности по проектированию на стадии конструирования в основном те же самые, что иописанные в области знаний “Проектирование программного обеспечения” (Software Design).Отличие заключается в большем внимании деталям.3.2 Языки конструирования (Construction Languages)Языки конструирования включают все формы коммуникаций, с помощью которых человек можетзадать решение проблемы, выполняемое на компьютере.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия.

Конструирование программного обеспечения.Простейший тип языков конструирования – конфигурационный язык (configuration language),позволяющий задавать параметры выполнения программной системы.Инструментальный язык (toolkit language) – язык конструирования из повторно-используемыхэлементов; обычно строится как сценарный язык (script), выполняемый в соответствующей среде.Язык программирования (programming language) – наиболее гибкий тип языков конструирования.Содержит минимальный объем информации о конкретных областях приложения и процессеразработки, требуя больше всего (по сравнению с другими типами языков конструирования) усилийна изучение и наработку опыта для эффективного применения при решении конкретных задач.Существует три основных вида нотаций используемых при определении языков программирования: лингвистическая формальная визуальнаяЛингвистические нотации характеризуются, в частности, использованием строк текста,содержащих специализированные “слова”, представляющие сложные программные конструкции, икомбинируемые в шаблоны, напоминающие предложения, построенные в соответствии сопределенным синтаксисом.

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

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

Однако, визуальная нотация может играть роль достаточномощного инструмента, когда применяется в тех задачах программирования, где необходимопостроение пользовательского интерфейса для программ, чья логика. Детализированное поведениеопределено ранее.Сегодняшние работы (и их состояние) в области архитектур и приложений, управляемых моделями,в первую очередь - OMG MDA (Model-Driven Architecture www.omg.org/mda)/UML (Unified ModelingLanguage www.omg.org/uml), Microsoft DSL (Domain-Specific Language), направлены на то, чтобыиспользовать ту или иную визуальную нотацию, базирующуюся на мета-моделях, в качествеинструмента, применяемого и для определения функциональной логики системы. Можно ли в чистомвиде считать эти нотации именно визуальными - вопрос спорный.

Но в терминах, предлагаемыхSWEBOK, они относятся именно к визуальным нотациям, так как предполагают однозначнуюинтерпретацию визуального представления в виде текста и наоборот. Кроме того, исторически этинотации определялись изначально как нотации визуального представления функциональности и ужев дальнейшем эти визуальные представления были отражены на цровне соответствующих метамоделей (хотя это в большей степени верно для UML, чем DSL, но DSL можно рассматривать и каканалог UML, предполагающий бОльшую свободу применений и интегрированность с конкретнойплатформой - Microsoft). Другая область стандартов, направленных на применение визуальныхнотаций для описания функциональности – Business Process Management Notation (BPMN www.omg.org/bpmn) и связанный с ней язык Business Process Execution Language, построенный наCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.

Конструирование программного обеспечения.базе XML. Таким образом, область обоснованного применения визуальных нотаций дляконструирования программных систем качественно расшириться и, не исключено, мы станемсвидетелями de-facto формирования новой категории нотаций, соглашений и смешанных типовязыковых средств, предназначенных для конструирования программного обеспечения какестественного продолжения проектирования.3.3 Кодирование (Coding)Практика конструирования программного обеспечения показывает активное применение следующихсоображений и техник: техники создания легко понимаемого исходного кода на основе использования соглашенийоб именовании, форматирования и структурирования кода; использование классов, перечисляемых типов, переменных, именованных констант и другихвыразительных сущностей; организация исходного текста (в выражения, шаблоны, классы, пакеты/модули и другиеструктуры) использование структур управления; обработка ошибочных условий и исключительных ситуаций предотвращение возможных брешей в безопасности (например, переполнение буфера иливыход за пределы индекса в массиве) использование ресурсов на основе применения механизмов исключения (из рассмотрения) ипорядка доступа к параллельно используемым ресурсам (например, на основе блокировкиданных, использования потоков и их синхронизации и т.п.) документирование кода тонкая “настройка” кода рефакторинг (не упоминается SWEBOK)3.4 Тестирование в конструировании (Construction Testing)При конструировании используются две формы тестирования, проводимого инженерами,непосредственно создающими исходный код: модульное тестирование (unit testing) интеграционное тестирование (integration testing)Главная цель тестирования в конструировании уменьшить временной разрыв между моментомпроявления ошибок, имеющихся в коде, и моментом их обнаружения.

Характеристики

Список файлов книги