Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 63

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

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

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

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

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

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

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

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

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

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

Мы считаем следующие три роли разработчиков важнейшими вобъектно-ориентированном подходе:•архитектор проекта•ответственные за подсистемы•прикладные программисты.Архитектор проекта - его творец, человек с сильно развитымвоображением; он отвечает за эволюцию и сопровождение архитектурысистемы.

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

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

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

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

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

Когда они наберутся опыта виспользовании хорошо определенных классов, они смогут сами проектироватьклассы. Вывод: не обязательно каждому разработчику быть экспертом поабстракциям, но каждый разработчик может со временем этому научиться.В больших проектах могут потребоваться и другие роли. Большинствоиз них (например, роль специалиста в средствах разработки) явно не связаны собъектно-ориентированной технологией, но некоторые непосредственновытекают из нее (такие, как инженер, отвечающей за повторноеиспользование):• Менеджер проектаОтвечает за управление материалами проекта, заданиями, ресурсами и графиком работ.• АналитикОтвечает за развитие и интерпретацию требований конечных пользователей; должен быть экспертом впроблемной области, однако его не следует изолировать от остальной команды разработчиков.• Инженер по повторному использованиюУправляет хранилищем (репозитарием) материалов проекта; участвуя в просмотре и других действиях,активно ищет общее и добивается его использования; находит, разрабатывает или приспосабливаеткомпоненты для общего использования в рамках конкретного проекта или целой организации.• Контролер качестваИзмеряет результаты процесса разработки; задает общее направление (на системном уровне)тестирования всех прототипов и релизов.• Менеджер интеграцииОтвечает за сборку совместимых друг с другом версий категорий и подсистем в релизы; следит за ихконфигурированием.• ИнструментальщикОтвечает за создание и адаптацию инструментов программирования, которые облегчают производствопрограмм и (особенно) генерацию кода.Библиотека должна содержать семейство классов, объединенных согласованным внешниминтерфейсом, но с разными представлениями, так чтобы разработчики могли выбрать то, семантикакоторого наиболее точно соответствует приложению.Предполагает тестирование отдельных классов имеханизмов; является обязанностью инженера, который их реализовал.Тестирование должно фокусироваться на внешнем поведении системы; его побочная цель определить границы системы чтобы понять, как она может выходить из строя при определенныхусловиях.7.4.

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

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