Дополнительные средства

Реорганизация.

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

Перепроектирование, в свою очередь, выливается в большую дополнительную работу, поскольку переписывание существующей программы порождает новые ошибки и проблемы. Однако, если не перепроектировать программу, дополнения могут оказаться более сложными, чем могли бы быть в противном случае. Со временем за такую «сверхсложность» придется платить все более высокую цену. Вследствие этого, как правило, приходится идти на компромисс: перепроектирование влечет за собой серьезные трудности в краткосрочном плане, зато приносит выгоду в перспективе. Находясь под прессом жестких плановых сроков, большинство разработчиков предпочитает отодвигать эти трудности на будущее [81].

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

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

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

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

Реорганизацию следует выполнять в следующих случаях [81]:

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

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

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

Образцы.

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

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

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

«У образцов анализа есть одна интересная особенность – они могут пригодиться в самый неожиданный момент. Когда я начал работать над проектом корпоративной системы финансового анализа, мне здорово помогли образцы, накопленные мною ранее в проекте из области здравоохранения» [81].

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

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

Образцы следует использовать постоянно. Чем бы вы ни занимались – анализом, проектированием, кодированием или управлением проектами – всегда стоит заняться поиском любых доступных образцов, которые могли бы вам помочь.

Содержание документа «Vision».

1. Введение.

1.1. Цели документа.

1.2. Область действия документа.

1.3. Список определений и сокращений.

1.4. Перечень ссылок.

1.5. Краткий обзор документа.

2. Позиции (основные характеристики) проекта.

2.1. Возможности (деловые), получаемые в результате выполнения проекта.

2.2. Постановка задачи (описание проблемы).

2.3. Описание назначения (позиций, характеристик) проектируемого ПО.

3. Описание заинтересованных лиц и потребителей.

3.1. Рынок.

3.2. Список и описание заинтересованных лиц.

3.3. Список и описание пользователей.

3.4. Условия работы пользователей.

3.5. Характеристика заинтересованных лиц.

3.5.1. Stakeholder Name.

3.6. Характеристика пользователей.

3.6.1. User Name.

3.7. Основные потребности (проблемы) заинтересованных лиц и пользователей.

3.8. Альтернативы и конкурирующие продукты.

3.8.1. Основные конкуренты.

3.8.2. Прочие конкуренты.

4. Общее описание проектируемого ПО.

4.1. Перспективы использования.

4.2. Перечень возможностей.

4.3. Предположения и допущения.

4.4. Калькуляция.

4.5. Лицензирование и ввод в эксплуатацию.

5. Свойства (особенности) разрабатываемого ПО.

5.1. Основные свойства (особенности).

5.2. Прочие свойства.

6. Ограничивающие условия.

7. Диапазон качества.

8. Приоритеты.

9. Другие требования к разрабатываемому ПО.

9.1. Применяемые стандарты.

9.2. Системные требования.

9.3. Требования к функционированию (эксплуатационные показатели).

9.4. Требования (экологические) к рабочей среде.

10. Требования к документации.

10.1. User Manual (Руководство пользователя).

10.2. Online Help (Интерактивная справка).

10.3. Installation Guides, Configuration, and Read Me File (Руководство по установке и конфигурированию).

10.4. Маркировка и упаковка.

Appendix 1 – Особые свойства / атрибуты особенностей: A.1. Статус. A.2. Польза (выгода). A.3. Объем работ. A.4. Риск. A.5. Устойчивость. A.6. Целевой выпуск (целевая версия). A.7. Назначение. A.8. Причина (основание).

Выводы

1. Объектно-ориентированная методология, использующая стандартный язык UML, предоставляет полезные средства анализа и моделирования как информационных, так и организационных систем.

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

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

4. UML лучше всего поддерживает Рациональный Унифицированный Процесс (Rational Unified Process – RUP) создания ПО. Этот пошаговый процесс, предполагает постепенное проникновение в суть проблемы с помощью последовательных уточнений, ПО, при этом, разрабатывается и реализуется по частям, путем получения все более емкого решения.

Дата добавления: 2014-12-27