Сергей Зыков - Основы проектирования корпоративных систем

Ознакомительный фрагмент

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

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

Другие подходы к жизненному циклу включают в себя гибкие методологии, такие как Agile (рис. 3.10), Scrum (рис. 3.11), eXtreme Programming (рис. 3.12). Следует отметить, что направление этих подходов ортогонально моделям жизненного цикла. Они, в отличие от IBM Rational и MSF, применимы к проектам с большими неопределенностями, возможно, большими рисками, но меньшего масштаба, чем корпоративные информационные системы. С другой стороны, методологии – это параллельное направление проектирования систем, которое связано скорее с задачей проектного менеджмента, чем с задачей построения системной архитектуры.

Рис. 3.10. Жизненный цикл ПО, гибкие методологии, Agile

В заключение стоит еще раз отметить, что был рассмотрен ряд моделей – Build-and-fix, водопадная, быстрого прототипирования, инкрементальная, синхростабилизации, объектно-ориентированная, упоминалась эволюционная модель. Build-and-fix пригодна не для корпоративных проектов, а для небольших проектов с предсказуемым циклом развития и объемом порядка 1000 строк. Водопадная модель применима для корпоративных систем, обеспечивает четкую дисциплину проекта и хорошую управляемость, так как основана на большом количестве документов, которые производятся в ходе жизненного цикла, но в итоге из-за только одного прохода получившееся ПО может не соответствовать потребностям заказчика. Быстрое прототипирование несамостоятельно, в ряде случаев вызывает у разработчиков соблазн повторного использования быстро разработанного ненадежного, недокументированного кода. Способствует сопровождаемости и обеспечивает максимально ранний возврат инвестиций, так как приводит к консенсусу по поводу требований заказчика. Инкрементальная модель требует открытой архитектуры и может выродиться в Build-and-fix, но в целом удовлетворяет потребностям клиента из-за эволюционного процесса разработки продукта. Модель синхростабилизации обладает рядом преимуществ, но не получила широкого применения вне Microsoft. Спиральная модель пригодна в первую очередь для внутренних проектов, так как требует специфических знаний по оценке рисков. Объектно-ориентированная модель обеспечивает итерации и паралеллизм, но опять же при слабой дисциплине проекта может выродиться в модель Build-and-fix.

Рис. 3.11. Жизненный цикл ПО, гибкие методологии, Scrum

Рис. 3.12. Жизненный цикл ПО, гибкие методологии, eXtreme Programming (XP)

Глава 4

Выбор модели жизненного цикла корпоративных систем

В предыдущей главе были рассмотрены преимущества и недостатки основных моделей ЖЦ – Build-and-fix, водопадной (каскадной) модели, где проектирование корпоративных информационных систем происходит в один проход, модели быстрого прототипирования (несамостоятельной, так же как и Build-and-fix), инкрементальной, модели синхронизации и стабилизации Microsoft, которая в настоящее время смещается в сторону MSF, спиральной и объектно-ориентированной модели. Также были рассмотрены основные характеристики и особенности моделей, их основные достоинства и недостатки.

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

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

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