Г.5.2.4. Проект San Francisco компании ibm

Проект San Francisco компании IBM создан с целью ускорить и удешевить разработку приложений для малых и средних предприятий (SME). Как показано на рис. 65, проект San Francisco включает различные уровни. Разработчик приложений занимает верхнюю ступеньку, откуда осуществляет доступ к остальным уровням. Виртуальная машина Java обеспечивает независимость прикладных решений от аппаратно-программной платформы.

Базовый уровень подразделяется на три компонента: базовые службы, базовые классы объектных моделей и утилиты.

Базовые службы основаны на стандарте OMG для служб объектов. Они представлены на языке Java и частично адаптированы к функциональным возможностям Java и специфическим требованиям IBM.

Базовые классы объектных моделей содержат механизмы для хранения или идентификации объектов.

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

Рис. 65. Проект San Francisco компании IBM

Общие бизнес-объекты (СВО) применимы ко многим вертикальным рынкам. Разработчикам программного обеспечения остается дополнить отдельные функции или добавить конкретные характеристики, отражающие специфику компании. Сюда могут входить такие функции, как управление адресами, условия платежа, календарное планирование или обмен данными (например, EDI). Эти СВО сопоставимы с общими бизнес-объектами OMG, что объясняет заинтересованность IBM в сертификации СВО Группой OMG. Базовые инфраструктуры бизнес-процессов предоставляют объекты для управления заказами, управления хранилищами (складами), а также для корпоративного учета. По оценкам IBM, на общие бизнес-объекты и базовые инфраструктуры бизнес-процессов приходится примерно 40% любого приложения. Остальное составляют экранные формы, характеристики, учитывающие конкретные особенности страны и отрасли, бизнес-правила и дополнительные функции, составляющие специфику приложения

Г.5.3. Перспективы развития индустрии программного обеспечения

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

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

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

Отбор и замена компонентов будут производиться по принципу «лучших представителей своего класса», а при сборке в центре внимания будет ноу-хау самого бизнеса и возможности его моделирование в соответствии с методом сборки. Таким образом, точками фокусировки при разработке программного обеспечения станут уровень инжиниринга как часть концепции АБИ с его методами моделирования, а также связи для интеграции с workflow и адаптации бизнес-объектов.

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

С другой стороны, не следует переоценивать возможности рынка компонентного ПО — здесь крупным поставщикам решений придется делать выбор. Проблема в том, что принцип конструктора «Лего», допускающего произвольную компоновку элементов, в этой области неприменим. Элементы «Лего» совершенно идентичны и собираются по типовой схеме. Для этого необязательно понимать их внутреннюю структуру, достаточно знать, что они имеют стандартные размеры и «связи».

В отличие от «Лего» программные компоненты содержат прикладную информацию — каждый свою. Для их сборки необходимо хорошо разбираться в технических интерфейсах и логике приложения. Этим определяется возможность или невозможность использования в сборке того или иного компонента. Главное условие для правильной сборки — наличие исчерпывающего документального описания компонентов. Создание сложных модулей требует объединения усилий поставщиков комплексных решений и поставщиков отдельных компонентов. Здесь можно провести аналогию с аэрокосмической и автомобильной отраслями. В этих отраслях обмен информацией о продуктах и тесное сотрудничество в процессе разработки называются параллельным инжинирингом. Опыт в области параллельного инжиниринга и многие его методы в значительной мере применимы и к разработке программного обеспечения. К сожалению, в отличие от сферы материального производства, поставщику программных компонентов труднее защитить свое ноу-хау. Если знания и опыт, которыми обладают изготовители автотранспортных средств в области научно-исследовательских и опытно-конструкторских разработок, а также в области производства, охватывают процедуры и технические ресурсы, и при этом они постоянно производят свою продукцию, то все, чем располагают поставщики ПО, — это методы и технологии разработки.

После совместной работы над каким-нибудь проектом поставщику решений не составит ни малейшего труда «позаимствовать» у партнера его ноу-хау.

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