Базовые информационные технологии и процессы. И процессы
 Скачать 2.47 Mb.
|
|
4.2 Истоки возникновения CASE-технологий Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности информационных систем (ИС), создава- емых в различных областях экономики. Современные крупные проекты ИС ха- рактеризуются, как правило, следующими особенностями: сложность описания (достаточно большое количество функций, про- цессов, элементов данных и сложные взаимосвязи между ними), требу- ющая тщательного моделирования и анализа данных и процессов; наличие совокупности тесно взаимодействующих компонентов (подси- стем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транз- акций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегла- ментированные запросы к данным большого объема); отсутствие прямых аналогов, ограничивающее возможность использо- вания каких-либо типовых проектных решений и прикладных систем; необходимость интеграции существующих и вновь разрабатываемых приложений; функционирование в неоднородной среде на нескольких аппаратных платформах; разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств; существенная временная протяженность проекта, обусловленная, с од- ной стороны, ограниченными возможностями коллектива разработчи- ков, и, с другой стороны, масштабами организации-заказчика и различ- ной степенью готовности отдельных ее подразделений к внедрению ИС. 88 Для успешной реализации проекта объект проектирования (ИС) должен быть прежде всего адекватно описан, должны быть построены полные и непро- тиворечивые функциональные и информационные модели ИС. Накопленный к настоящему времени опыт проектирования ИС показывает, что это логически сложная, трудоемкая и длительная по времени работа, требующая высокой ква- лификации участвующих в ней специалистов. Однако до недавнего времени про- ектирование ИС выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования ИС. Кроме того, в процессе создания и функционирования ИС информационные потребности пользователей могут изменяться или уточ- няться, что еще более усложняет разработку и сопровождение таких систем. В 1970–1980-х гг. при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических ре- шений. Она основана на наглядной графической технике: для описания различ- ного рода моделей ИС используются схемы и диаграммы. Наглядность и стро- гость средств структурного анализа позволяла разработчикам и будущим поль- зователям системы с самого начала неформально участвовать в ее создании, об- суждать и закреплять понимание основных технических решений. Однако широ- кое применение этой методологии и следование ее рекомендациям при разра- ботке конкретных ИС встречалось достаточно редко, поскольку при неавтомати- зированной (ручной) разработке это практически невозможно. Действительно, вручную очень трудно разработать и графически представить строгие формаль- ные спецификации системы, проверить их на полноту и непротиворечивость, и тем более изменить. Если все же удается создать строгую систему проектных документов, то ее переработка при появлении серьезных изменений практически неосуществима. Ручная разработка обычно порождала следующие проблемы: неадекватная спецификация требований; неспособность обнаруживать ошибки в проектных решениях; низкое качество документации, снижающее эксплуатационные качест- ва; затяжной цикл и неудовлетворительные результаты тестирования. 89 С другой стороны, разработчики ИС исторически всегда стояли послед- ними в ряду тех, кто использовал компьютерные технологии для повышения ка- чества, надежности и производительности в своей собственной работе (феномен «сапожника без сапог»). Перечисленные факторы способствовали появлению программно-техно- логических средств специального класса – CASE-средств, реализующих CASE- технологию создания и сопровождения ИС. Термин CASE (Computer Aided Soft- ware Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматиза- ции разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные сред- ства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение ка- чества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС. Появлению CASE-технологии и CASE-средств предшествовали исследо- вания в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний систем- ных требований и спецификаций и т. д. Кроме того, появлению CASE-техноло- гии способствовали и такие факторы, как: подготовка аналитиков и программистов, восприимчивых к концеп- циям модульного и структурного программирования; широкое внедрение и постоянный рост производительности компьюте- ров, позволившие использовать эффективные графические средства и автоматизировать большинство этапов проектирования; внедрение сетевой технологии, предоставившей возможность объеди- нения усилий отдельных исполнителей в единый процесс проектирова- ния путем использования разделяемой базы данных, содержащей необ- ходимую информацию о проекте. 90 CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моде- лировать предметную область, анализировать эту модель на всех этапах разра- ботки и сопровождения ИС и разрабатывать приложения в соответствии с ин- формационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объ- ектно-ориентированного анализа и проектирования, использующих специфика- ции в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры про- граммных средств. Однако, несмотря на все потенциальные возможности CASE-средств, су- ществует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся «полочным» ПО (shelfware). В связи с этим необхо- димо отметить следующее: CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время; реальные затраты на внедрение CASE-средств обычно намного превы- шают затраты на их приобретение; CASE-средства обеспечивают возможности для получения существен- ной выгоды только после успешного завершения процесса их внедре- ния. Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворе- ния тех или иных ожиданий от их внедрения. Можно перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств: широкое разнообразие качества и возможностей CASE-средств; относительно небольшое время использования CASE-средств в различ- ных организациях и недостаток опыта их применения; широкое разнообразие в практике внедрения различных организаций; отсутствие детальных метрик и данных для уже выполненных и теку- щих проектов; широкий диапазон предметных областей проектов; различная степень интеграции CASE-средств в различных проектах. 91 Вследствие этих сложностей доступная информация о реальных внедре- ниях крайне ограничена и противоречива. Она зависит от типа средств, характе- ристик проектов, уровня сопровождения и опыта пользователей. Некоторые ана- литики полагают, что реальная выгода от использования некоторых типов CASE- средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жиз- ненного цикла ИС, когда технологические улучшения могут привести к сниже- нию эксплуатационных затрат. Для успешного внедрения CASE-средств организация должна обладать следующими качествами: 1. Технология. Понимание ограниченности существующих возможно- стей и способность принять новую технологию. 2. Культура. Готовность к внедрению новых процессов и взаимоотноше- ний между разработчиками и пользователями. 3. Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения. Если организация не обладает хотя бы одним из перечисленных качеств, то внедрение CASE-средств может закончиться неудачей независимо от степени тщательности следования различным рекомендациям по внедрению. Для того чтобы принять взвешенное решение относительно инвестиций в CASE-технологию, пользователи вынуждены производить оценку отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта проблема зачастую усугубляется недостаточным знанием всех возможных «подводных камней» использования CASE-средств. Среди наиболее важных проблем выде- ляются следующие: достоверная оценка отдачи от инвестиций в CASE-средства затрудни- тельна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО; внедрение CASE-средств может представлять собой достаточно дли- тельный процесс и не принести немедленной отдачи. Возможно даже краткосрочное снижение продуктивности в результате усилий, затра- чиваемых на внедрение. Вследствие этого руководство организации- пользователя может утратить интерес к CASE-средствам и прекратить поддержку их внедрения; 92 отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые исполь- зуются в данной организации, может привести к дополнительным труд- ностям; CASE-средства зачастую трудно использовать в комплексе с другими подобными средствами. Это объясняется как различными парадиг- мами, поддерживаемыми различными средствами, так и проблемами передачи данных и управления от одного средства к другому; некоторые CASE-средства требуют слишком много усилий для того, чтобы оправдать их использование в небольшом проекте, при этом, тем не менее, можно извлечь выгоду из той дисциплины, к которой обязы- вает их применение; негативное отношение персонала к внедрению новой CASE-техноло- гии может быть главной причиной провала проекта. Пользователи CASE-средств должны быть готовы к необходимости долго- срочных затрат на эксплуатацию, частому появлению новых версий и возмож- ному быстрому моральному старению средств, а также постоянным затратам на обучение и повышение квалификации персонала. Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодо- леть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды, как: высокий уровень технологической поддержки процессов разработки и сопровождения ПО; положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стан- дартов, документирование; приемлемый уровень отдачи от инвестиций в CASE-средства. 4.3 Структурный подход к проектированию ИС Сущность структурного подхода к разработке ИС заключается в ее деком- позиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть 93 до конкретных процедур. При этом автоматизируемая система сохраняет целост- ное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы «снизу вверх» от отдельных задач ко всей системе це- лостность теряется, возникают проблемы при информационной стыковке от- дельных компонентов. Все наиболее распространенные методологии структурного подхода бази- руются на ряде общих принципов. В качестве двух базовых принципов исполь- зуются следующие: принцип «разделяй и властвуй» – принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения; принцип иерархического упорядочивания – принцип организации со- ставных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне. Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего про- екта). Основными из этих принципов являются следующие: принцип абстрагирования – выделение существенных аспектов си- стемы и отвлечение от несущественных; принцип формализации – необходимость строгого методического под- хода к решению проблемы; принцип непротиворечивости – обоснованность и согласованность эле- ментов; принцип структурирования данных – данные должны быть структури- рованы и иерархически организованы. В структурном анализе используются в основном две группы средств, ил- люстрирующих функции, выполняемые системой, и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT (Structured Analysis and Design Technique) – модели и соответ- ствующие функциональные диаграммы; DFD (Data Flow Diagrams) – диаграммы потоков данных; ERD (Entity-Relationship Diagrams) – диаграммы «сущность – связь». 94 На стадии проектирования ИС модели расширяются, уточняются и допол- няются диаграммами, отражающими структуру программного обеспечения: ар- хитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС незави- симо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описа- ния системы. 4.4 Методология функционального моделирования SADT Методология SADT разработана Дугласом Россом. На ее основе разрабо- тана, в частности, известная методология функционального моделирования IDEF0 (Icam DEFinition), которая является основной частью программы ICAM («Интеграция компьютерных и промышленных технологий»), проводимой по инициативе ВВС США. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на сле- дующих концепциях: Графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы вхо- да/выхода представляются дугами, соответственно входящими в блок и выходя- щими из него. Взаимодействие блоков друг с другом описывается посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь опре- деляют, когда и каким образом функции выполняются и управляются. Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: ограничение количества блоков на каждом уровне декомпозиции (пра- вило 3-6 блоков); связность диаграмм (номера блоков); уникальность меток и наименований (отсутствие повторяющихся имен); синтаксические правила для графики (блоков и дуг); разделение входов и управлений (правило определения роли данных); 95 отделение организации от функции, исключение влияния организаци- онной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки си- стемы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функ- ций, выполняемых системой, а также для указания механизмов, посредством ко- торых они осуществляются. Результатом применения методологии SADT является модель, которая со- стоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком опреде- ляет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой сто- роны блока, а результаты выхода показаны с правой стороны. Механизм (чело- век или автоматизированная система), который осуществляет операцию, пред- ставляется дугой, входящей в блок снизу (рис. 4.2). Управление Функция Выходы Входы Механизм Рис. 4.2 – Функциональный блок и интерфейсные дуги Одной из наиболее важных особенностей методологии SADT является по- степенное введение все больших уровней детализации по мере создания диа- грамм, отображающих модель. На рисунке 4.3, где приведены четыре диаграммы и их взаимосвязи, пока- зана структура SADT-модели. Каждый компонент модели может быть декомпо- зирован на другой диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме. 96 А-0 А0 1 2 3 4 41 421 42 422 43 423 А4 А42 Более общее представление Более детальное представление Эта диаграмма является «родителем» этой диаграммы Рис. 4.3 – Структура SADT-модели. Декомпозиция диаграмм Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю си- стему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг, они также представляют полный набор внешних интерфей- сов системы в целом. Такая диаграмма, содержащая один блок, называется кон- текстной. Затем блок, который представляет систему в качестве единого модуля, де- тализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исход- ной функции. Данная декомпозиция выявляет полный набор подфункций, каж- дая из которых представлена как блок, границы которого определены интер- 97 фейсными дугами. Каждая из этих подфункций может быть декомпозирована по- добным образом для более детального представления. Число блоков на диа- грамме, обратим внимание еще раз, поскольку данное ограничение часто забы- вается, не менее 3 и не более 6. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т. е., как уже отмечалось, родительский блок и его интер- фейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не мо- жет быть ничего удалено. Модель SADT представляет собой серию диаграмм с сопроводительной до- кументацией, разбивающих сложный объект на составные части, которые пред- ставлены в виде блоков. Детали каждого из основных блоков показаны в виде бло- ков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается не присоединенным. Не присоединенные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на роди- тельской диаграмме, не присоединенные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родитель- ской диаграмме, чтобы она была полной и непротиворечивой. Каждый блок дол- жен иметь дуги управления и выхода. На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Как было отмечено, механизмы (дуги с нижней стороны) показывают сред- ства, с помощью которых осуществляется выполнение функций. Механизм мо- жет быть человеком, компьютером или любым другим устройством, которое по- могает выполнять данную функцию (рис. 4.4). 98 Порядок подачи заявки Рыночные условий Оформление заявки для биржи Контракт Заявка клиента Брокер Рис. 4.4 – Пример механизма Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы мо- жет быть далее описан диаграммой нижнего уровня, которая в свою очередь мо- жет быть далее детализирована с помощью необходимого числа диаграмм. Та- ким образом формируется иерархия диаграмм. Для того чтобы указать положение любой диаграммы или блока в иерар- хии, используются номера диаграмм. Например, А21 является диаграммой, ко- торая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На основе методологии SADT было разработано целое семейство методо- логий, связанных с построением функциональных моделей и семантических ха- рактеристик данных. Семантические модели данных могут использоваться в сфере бизнеса для управления данными как ресурсами, интеграции информаци- онных систем и построения систем управления базами данных. Необходимость в семантических моделях данных была впервые осознана ВВС США в середине 1970-х гг. при выполнении программы ICAM (программы интегрированной компьютеризации производства). Цель этой программы состо- яла в повышении продуктивности производства посредством систематического внедрения компьютерных технологий. Повышение продуктивности производ- ства в рамках программы ICAM потребовало совершенствования методов ана- лиза и передачи информации. В результате был разработан ряд технологий, из- вестных как IDEF-методологии (ICAM DEFinition). Всего известно 14 методоло- гий IDEF, но базовое ядро IDEF состоит из трех методологий моделирования, основанных на графическом представлении производственных систем: IDEF0 используется для создания функциональной модели, которая яв- ляется структурированным изображением функций производственной системы или среды, а также информации и объектов, связывающих эти 99 функции (как правило, моделирование средствами IDEF0 является пер- вым этапом изучения любой системы); IDEF1x применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды; IDEF2 позволяет построить динамическую модель меняющегося во времени поведения функций, информации и ресурсов производствен- ной системы или среды. |