Звоните! 
 (926)274-88-54 
 Бесплатная доставка. 
 Бесплатная сборка. 
Ассортимент тканей

График работы:
Ежедневно. С 8-00 до 20-00.
Почта: soft_hous@mail.ru
Читальный зал -->  Диаграммы параллельных состояний 

1 2 3 4 5 6 7 8 9 10 [ 11 ] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

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

Реорганизацию можно упростить, если следовать следующим принципам:

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

До начала реорганизации убедитесь в том, что у вас имеются хорошие тесты.

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

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

Дополнительную информацию по реорганизации можно найти в книге Фаулера (Fowler), 1999 [19].

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

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



Когда план заканчивается неудачей

Чтобы быть уверенным в выполнении плана, вам необходимо знать только одну вещь, а именно - все что происходит, происходит в соответствии с планом. Управление планом состоит главным образом в эффективном отслеживании происходящих изменений.

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

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

Использование языка UML на фазе построения

На этой стадии могут оказаться полезными все методы языка UML. Поскольку я собираюсь говорить о методах, рассмотреть которые у меня еще не было возможности, можете спокойно пропустить этот раздел и вернуться к нему позже.

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

Преимущество этих методов на данной стадии заключается в том, что они могут быть использованы в сотрудничестве с экспертом предметной области. Как говорит Брэд Кэйн (Brad Kain): Анализ возможен только тогда, когда рядом находится эксперт предметной области (в противном случае это не анализ, а псевдоанализ) .

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



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

Не прош;ающий ничего программный код неизбежно вскроет все недостатки проекта. Не бойтесь вносить изменения в проект в процессе его изучения. Если подобные изменения серьезны, то следует использовать специальные обозначения для последуюш;его обсуждения идей со своими коллегами.

После того как вы разработали программное обеспечение, для подготовки документации о проделанной работе может быть использован язык UML. Я пришел к выводу, что диаграммы языка UML оказываются весьма полезными для достижения обш;его понимания системы. Однако должен подчеркнуть, что при этом вовсе не имею в виду построение детальных диаграмм для системы в целом. В этой связи уместно процитировать Уорда Каннингхема (Ward Cunningham), 1996 [16]:

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

Я полагаю, что подробную документацию следует разрабатывать на основе готового программного кода (подобно, например, JavaDoc). Чтобы обратить внимание на наиболее важные понятия, лучше подготовить дополнительную документацию. Считайте ее составной частью первого этапа знакомства с программой, перед тем как приступить к детальному изучению кода. Я предпочитаю представлять документацию в форме текста, достаточно краткого, чтобы прочесть его за чашкой кофе, и с использованием диаграмм языка UML, которые помогают придать наглядный характер обсуждению.

Я использую диаграмму пакетов (см. главу 7) как своего рода логическую карту дорог системы. Эта диаграмма помогает мне понять логические блоки системы и обнаружить зависимости между ними (держа их под контролем). Диаграмма развертывания (см. главу 10) может су-ш;ественно улучшить понимание на этой стадии, поскольку позволяет представить обш;ую физическую картину системы.

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

Если некоторый класс в течение своего жизненного цикла имеет сложное поведение, то для описания такого поведения я изображаю диаграмму состояния (см. главу 8). Но поступаю так только в том случае.



1 2 3 4 5 6 7 8 9 10 [ 11 ] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57



ООО «Мягкий Дом» - это Отечественный производитель мебели. Наша профильная продукция - это диваны еврокнижка. Каждый диван можем изготовить в соответствии с Вашими пожеланияи (размер, ткань и материал). Осуществляем бесплатную доставку и сборку.



Звоните! Ежедневно!
 (926)274-88-54 
Продажа и изготовление мебели.


Копирование контента сайта запрещено.
Авторские права защищаются адвокатской коллегией г. Москвы
.