Проектирование автоматизированных систем

Скачать 4.46 Mb.

Название	Проектирование автоматизированных систем
страница	7/52
Тип	Книга

rykovodstvo.ru > Руководство эксплуатация > Книга

1 2 3 4 5 6 7 8 9 10 ... 52

1.2. CASE-технологии. Мифы и реальность

В грязный сосуд что ни влей, непременно прокиснет

Гораций
В свое время в мире был замечательный миф. Миф назывался «CASE-технологии». Этот миф зародился, возможно, либо внутри ЦРУ, либо в структурах армии США. Оттуда и пошли нотации IDEF0, IDEF1 и другие.

О чем этот миф говорил? Миф говорил о том, что мы можем любую деятельность нарисовать с помощью квадратиков, потом нажать кнопочку, и получить работоспособное решение.

Этот миф рухнул недавно, буквально лет 6-8 назад, когда стало понятно, что «CASE-технологии» не работают.

Одним из продуктов, который реализовывал принцип «CASE-технологий», был Oracle Designer. Сначала это был Oracle Case, который работал чуть ли не в цифровом режиме, под 4-5 версией, только под Unix. А потом его импортировали под X-Windows, а потом под Windows. Этот продукт в итоге оказался весьма недешев. Зато он полностью поддерживал IDEF0-1. С его помощью можно было описать бизнес полностью, с нуля.

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

Есть еще масса других примеров, самых разных. Общее резюме состоит в том, что «CASE-технологии» - это такие универсальные инструменты, которые позволяют описать любой бизнес, а потом получить готовый софт, но они почему-то не работают. С их помощью можно быстро описать программу по резервированию мест в гостинице. Это – любимый пример на курсах Oracle Designer. Или – другой пример: на курсах Oracle Designer научат нарисовать приложение по резервированию мест для обучающихся на курсах. Это приложение, которое состоит из нескольких табличек и нескольких экранных форм, и которому вас научат. Обучение этой нехитрой науке идет красной нитью через весь учебный курс.

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

Есть совершенно замечательный пример. Компания Форс года 4 назад решила написать свою банковскую систему нового поколения. До этого времени они торговали системой, которая называется «Ва-банк», сейчас она называется «Ва-банк Лайт». Так вот, Форс решил написать свою банковскую систему, и в качестве инструмента использовать Designer. В компании Форс сидят люди, которые читают курсы по Designer’у, и которые способны отрисовать все, начиная от начала и до конца: data-flow диаграммы, ER-диаграммы, функционально-иерархические диаграммы, функциональные диаграммы…

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

И в итоге вдумчивого опыта работы с CASE-средствами разработки можно прийти к следующему выводу. Идея конструктора – это хорошо. Действительно, если получить конструктор, который позволяет сильно облегчить труд программиста, было бы замечательно. Но универсальных конструкторов не бывает. Плата за универсализм – это невозможность реализации хоть сколько-нибудь уникальной, своей технологии, своих наработок и библиотек внутри системы. И софт, который вы получите, будет медленным, будем тупым, будет плохо модернизируемым, и в любом случае – все эти кейсы, они не умеют поддерживать кастомизацию, они не имеют такой возможности. Ну конечно, если не идти от самого начала, от описания бизнес-процессов. А на это никто не пойдет просто потому, что если описывать бизнес-процесс по тем же самым депозитам – который кодируется вручную на PL/SQL за пару дней со всеми своими процентами и расчетами, максимум – за неделю, а описать это в виде IDEF0, прописать там все функции с тем, чтобы нажать потом все кнопки и получить, как обещано, из картинки работоспособный код – там не неделя явно, там полгода. Поэтому так и не работают. То есть CASE-средства хороши для создания прототипов системы и отработки на них пользовательских функций, отработки требований пользователя к системе – и это первая стадия предпроектных работ. Собственно все дизайнеры, начиная со знаменитого дизайнера Clarion конца восьмидесятых годов прошлого века, предназначены для разработки прототипов и отработки функционала АС. И ведь уже тогда было известно, что работающее приложение надо писать в кодах.

Использование даже самых продвинутых специалистов и инструментов не предполагает безоблачного продвижения проекта по виткам спирали разработки. В мире коммерческих систем в расчет нужно принимать одну весьма непредсказуемую и влиятельную силу - заказчика, как явного, так и предполагаемого покупателя. Мир бизнеса развивается по своим законам и часто требует от обслуживающей его программной индустрии не просто быстрой, а стремительной перестройки, не взирая ни на какие UML модели. Кто настолько уверен в своих способностях, чтобы утверждать, что он сможет предвидеть все необходимые нюансы разработки, даже если не понадобиться вносить радикальные изменения. Мартин Фаулер - признанный эксперт в области проектирования программных систем и использования языка UML, говорит: "Even skilled designers, such as I consider myself to be, are often surprised when we turn such a design into software" (Даже опытные дизайнеры, каким я себя считаю, часто бывают удивлены, когда преобразуют такого рода дизайн в программное обеспечение).

Мы каждый день наблюдаем сообщения программ об ошибках, часто теряются некоторые данные, обычно не хватает каких-то операций и все это порой раздражает. Ну и что? Опыт и многочисленные исследования в этой области показывают, что пользователи ГОТОВЫ мириться с выходками программы, ПОКА она выполняет свои ГЛАВНЫЕ обязанности. По их мнению, это разумная плата за возможность приступить к использованию системы раньше, а не тогда, когда она станет безупречно свободна от ошибок и, как правило, уже никому не нужна. Естественно, все недостатки должны устраняться при их обнаружении и как можно скорее.

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

1 2 3 4 5 6 7 8 9 10 ... 52

Похожие:

	Должностная инструкция Специалиста отдела автоматизированных систем управления Специалист отдела автоматизированных систем управления находится в непосредственном подчинении Начальника отдела автоматизированных...		Рабочая программа дисциплины в. Од. 1«Проектирование автоматизированных систем» Целью дисциплины является формирование знаний и умений для выполнения проектных работ по созданию и функционированию систем автоматизации...
	Лабораторная работа 2 12 лабораторная работа 3 17 лабораторная работа... «Проектирование систем реального времени» для студентов специальности 09. 05. 01 «Применение и эксплуатация автоматизированных систем...		Информационное обеспечение автоматизированных машиностроительных производств Целью интеграции автоматизированных систем проектирования и управления является повышение эффективности создания и использования...
	Техническое задание на выполнение работ по теме: Создание, включая... Создание, включая проектирование автоматизированных центров контроля и надзора на транспорте (на базе существующих дежурно-диспетчерских...		Методические рекомендации по проведению практических занятий по дисциплине... Методическая разработка предназначена для использования студентами специальности: 230105 «Программное обеспечение вычислительной...
	1. 1 Предмет и содержание курса 2 Вопросы стандартизации систем Задачи планирования деятельности и управления процессами промышленных предприятий одна из основных областей применения автоматизированных...		Исследование современных автоматизированных систем управления гостиницей.... Реализация этих условий возможна только в рамках применения информационных компьютерных систем
	Инструкция по установке и настройке программного обеспечения пользователя... Удостоверяющего центра электронной цифровой подписи автоматизированных информационных систем единого информационного пространства...		Лабораторная работа №1. 7 Проектирование форм документов. 7 Цель... Методические указания к лабораторным работам по дисциплинам: «Проектирование информационных систем в экономике», «Информационные...
	Методические указания к лабораторному практикуму по курсу “Эксплуатация...		«Сжатие данных» Кафедра информационных технологий автоматизированных систем пояснительная записка
	Согласовано Начальник службы автоматизированных систем управления – помощник генерального директора		Пояснительная записка Сборник заданий по программированию содержит... Сборник заданий по программированию содержит индивидуальные задания для студентов специальности 230105 «Программное обеспечение вычислительной...
	Рабочая программа дисциплины б 27 проектирование мобильных систем... Целью освоения дисциплины является формирование у студентов теоретических основ и практических навыков программной разработки мобильных...		Программа «Робостарт» Необходимо прививать интерес у детей к области робототехники и автоматизированных систем

Руководство, инструкция по применению