УДК 681.3.07

ЕА.Черткова, К.К.Дауренбеков

Московский государственный машиностроительный университет

Кызылординский государственный университет имени Коркыт Ата

ИНВАРИАНТНЫЕ ПРОБЛЕМЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Американский учёный в области теории вычислительных систем Ф. Брукс в классической статье по инженерии программного обеспечения определил свойства, характерные для программной инженерии. Согласно Бруксу сущность программной инженерии определяется собственными свойствами программного обеспечения, которые вызывают трудности при его создании.

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

Эти четыре «существенные трудности» создания программного обеспечения определяют инвариант или неизменную составляющую процесса его разработки. Инвариант констатирует тот факт, что программное обеспечение является продуктом творческого акта разработки — ремесла или даже искусства.

По определению Ф. Брукса, сложность программного обеспечения — не случайное его свойство и вызывается четырьмя основными причинами:

· сложностью реальной предметной области, из которой исходит заказ на разработку;

· трудностью управления процессом разработки;

· необходимостью обеспечить достаточную гибкость программы;

· неудовлетворительными способами описания поведения больших дискретных систем.

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

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

Практика создания ПО способствует разработке систем из настраиваемых программных пакетов — решений на основе COTS-продуктов или ERP-систем (Enterprise Resource Planning System— система планирования корпоративных ресурсов). Программный пакет может обеспечить функции стандартного бухгалтерского учета, компьютерной обучающей системы или системы управления кадрами. Акцент смещается от разработки «с чистого листа» к «настройке» программного обеспечения, однако процесс производства все равно занимает значительное место.

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

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

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

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

· CORBA (Common Object Request Broker Architecture — Общая архитектура брокера объектных запросов) от OMG (Object Management Group);

· DCOM (Distributed Component Object Mode — Распределенная модель компонентных объектов) от Microsoft;

· EJB (EnterpriseJavaBeans — Корпоративная технология для Java-приложений) от Sun.

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

Литература

1. Басс, Л. Архитектура программного обеспечения на практике / Л. Басс, П. Клементс, Р. Кацман; пер. с англ. — СПб.: Питер, 2006. — 575 с.

2. Боггс, У. UML и Rational Rose 2002. / У. Боггс, М. Боггс; пер. с англ. — М.: Изд. «Лори». 2004. — 510 с.

3. Вендров, А.М. Проектирование программного обеспечения экономических информационных систем / А.М. Вендров. — М.: Финансы и статистика. 2005. — 544 с.

4. Грэхем, И. Объектно-ориентированные методы. Принципы и практика / И. Грэхем; пер. с англ. — М.: Издательский дом «Вильямс». 2004.— 880 с.

5. Софиев А.Э., Черткова Е.А. Компьютерные обучающие системы. Монография: – М.: Изд. ДеЛи, 2006. – 296 с.

6. Черткова Е.А. Концепция спецификации требований для проектирования компьютерных обучающих систем. // Вестник Саратовского государственного технического университета. – 2005. № 4 (9). С. 90-97.