Case средства - ВведениеВведение

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

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

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

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

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

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

Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

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

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

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

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

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

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

Технология.

Культура.

Управление.

важным этапам

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

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

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

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

Несмотря на все высказанные предостережения и некоторый пессимизм, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

1. В основе информационной системы лежит

а) среда хранения и доступа к данным

б) вычислительная мощность компьютера

в) компьютерная сеть для передачи данных

г) методы обработки информации

2. Информационные системы ориентированы на

а) конечного пользователя, не обладающего высокой квалификацией

б) программиста

в) специалиста в области СУБД

г) руководителя предприятия

3. Неотъемлемой частью любой информационной системы является

а) база данных

б) программа созданная в среде разработки Delphi

в) возможность передавать информацию через Интернет

г) программа, созданная с помощью языка программирования высокого уровня

4. В настоящее время наиболее широко распространены системы управления базами данных

а) объектно-ориентированные

б) реляционные

в) иерархические

г) сетевые

5. Более современными являются системы управления базами данных

а) иерархические

б) сетевые

в) реляцонные

г) постреляционные

6. СУБД Oracle, Informix, Subase, DB 2, MS SQL Server относятся к

а) сетевым

б) иерархическим

в) реляционным

г) объектно-ориентированным

7. Традиционным методом организации информационных систем является

а) архитектура клиент-клиент

б) архитектура клиент-сервер

в) архитектура сервер- сервер

г) размещение всей информации на одном компьютере

8. Первым шагом в проектировании ИС является

а) формальное описание предметной области

б) построение полных и непротиворечивых моделей ИС

в) выбор языка программирования

г) разработка интерфейса ИС

9. Для повышения эффективности разработки программного обеспечения применяют

а) CASE –средства

10. Под CASE – средствами понимают

а) программные средства, поддерживающие процессы создания и сопровождения программного обеспечения

б) языки программирования высокого уровня

в) среды для разработки программного обеспечения

г) прикладные программы

11. Средством визуальной разработки приложений является

а) Visual Basic

г) язык программирования высокого

12. Microsoft.Net является

а) платформой

б) языком программирования

в) системой управления базами данных

г) прикладной программой

13. По масштабу ИС подразделяются на

а) малые, большие

б) сложные, простые

в) объектно- ориентированные и прочие

г) одиночные, групповые, корпоративные

14. По сфере применения ИС подразделяются на

а) системы обработки транзакций

б) системы поддержки принятия решений

в)системы для проведения сложных математических вычислений

г)экономические системы

15. По сфере применения ИС подразделяются на

а) экономические

б) прикладные

в) информационно-справочные

г) офисные

16. Транзакция это

а) передача данных

б) обработка данных

в) совокупность операций

г) преобразование данных

17. Составление сметы и бюджета проекта, определение потребности в ресурсах, разработка календарных планов и графиков работ относятся к фазе

а)подготовки технического предложения

б)концептуальной

в)проектирования

г)разработки

18. Сбор исходных данных и анализ существующего состояния, сравнительная оценка альтернатив относятся к фазе

а) концептуальной

б) подготовки технического предложения

в) проектирования

г) разработки

19. Наиболее часто на начальных фазах разработки ИС допускаются следующие ошибки

а) неправильный выбор языка программирования

б) неправильный выбор СУБД

в) неправильный подбор программистов

г) ошибки в определении интересов заказчика

20. Жизненный цикл ИС регламентирует стандарт ISO/IEC 12207. IEC – это

а) международная организация по стандартизации

б) международная комиссия по электротехнике

в) международная организация по информационным системам

г) международная организация по программному обеспечению

21. Согласно стандарту, структура жизненного цикла ИС состоит из процессов

а) основных и вспомогательных процессов жизненного цикла и организационных процессов

б) разработки и внедрения

в) программирования и отладки

г) создания и использования ИС

22. Наиболее распространённой моделью жизненного цикла является

а) модель параллельной разработки программных модулей

б) объектно-ориентированная модель

в) каскадная модель

г) модель комплексного подхода к разработке ИС

23. Наиболее распространённой моделью жизненного цикла является

а) линейная модель

б) не линейная модель

в) непрерывная модель

г) спиральная модель

24. Более предпочтительной моделью жизненного цикла является

а) каскадная

б) модель комплексного подхода к разработке ИС

в) линейная модель

г) спиральная

25. Словосочетание – быстрая разработка приложений сокращённо записывается как

26. Методология быстрой разработки приложений используется для разработки

а) небольших ИС

б) типовых ИС

в) приложений, в которых интерфейс пользователя является вторичным

г) систем, от которых зависит безопасность людей

27. Согласно ISO 12207, объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для удовлетворения определённым потребностям или целям это

а) информационная система

б) система

в) полнофункциональный программно-аппаратный комплекс

г) вычислительный центр

28. Основой практически любой ИС является

б)язык программирования высокого уровня

г) набор методов и средств создания ИС

29. К основным функциям, выполняемым СУБД, обычно относят

а) управление транзакциями

б) протоколирование

в) выполнение вычислений

г) построение диаграмм

30. Поддержка механизма транзакций СУБД является

а) обязательной

б) желательной

в) не обязательной

г) весьма вероятной

31. Параллельное выполнение смеси транзакций, результат которого эквивалентен результату их последовательного выполнения, называется

а) распараллеливанием

б) комплексной обработкой

в) сериализацией

г) одновременной обработкой транзакций

32. Запись в журнале информации о изменениях происходящих в базе данных называется

а)протоколированием

б) учётом событий

в) фиксацией изменений

г) мониторингом

33. Благодаря работам Э. Кодда были созданы базы данных

а) реляционные

б) сетевые

в) иерархические

г) объектно-ориентированные

34. Реляционные базы данных получили своё название благодаря тому, что

а) таблицы данных связаны между собой

б) в них быстро обрабатывается информация

в) в них можно хранить данные сложной структуры

г) данные в них представлены в виде таблиц

35. Последнее обновление стандарта языка SQL было принято в году

36. Сущностям реального мира более близка модель данных

а) реляционная

б) объектно-ориентированная

в) иерархическая

г) сетевая

37. В постреляционных СУБД используются модели данных

а) объектно-ориентированная и реляционная

б) реляционная и иерархическая

в) иерархическая и сетевая

г) причинно-обусловленная

38. К основным достоинствам реляционного подхода к управлению базой данных следует отнести

а) возможность сравнительно просто моделировать большую часть распространённых предметных областей

б) наличие простого и мощного математического аппарата

в) возможность описания объектов любой сложности

г) простота отображения взаимосвязей реального мира

39. Множество атомарных значений одного и того же типа называется

а) доменом

б) кортежом

в) атрибутом

г) типом данных

40. Столбцы отношения называются

а) кортежами

б) доменами

в) атрибутами

г) столбцами с однотипными значениями

41. Строка отношения называется

а) кортежем

б) атрибутом

в) доменом

г) строкой таблицы

42. Число кортежей называется

а) кардинальным числом

б) мощностью отношения

в) величиной отношения

г) определяющим числом

43. Для обозначения пустых значений полей используется

а) прочерк

г) отсутствие каких-либо символов

44. Значение атрибута неизвестно, если в соответствующем поле

а) отсутствуют какие-либо символы

б) стоит прочерк

в) записано слово NULL

г) стоит цифра ноль

45. Первичный ключ обладает свойством

а)уникальность

б) простота использования

в) минимальность

г) интуитивная понятность

46. В таблицах реляционной базы данных

а) кортежи и атрибуты хранятся в неупорядоченном виде

б) упорядочены только атрибуты

в) упорядочены только кортежи

г) атрибуты и кортежи хранятся в упорядоченном виде

47. Нормализация данных направлена на

а) снижение избыточности информации

б) приведение данных к стандартному виду

в) приведение данных к нормальному виду

г) упорядочивание структуры данных

48. Языком управления реляционными данными является

49. Первый вариант языка SQL назывался

50. ANSI SQL- это

а) стандарт на язык

б) детальное описание языка

в) новейший язык манипулирования данными

г) расширение языка SQL

51. Команды языка SQL подразделяются на команды языка

Определения данных

Манипулирования данными

Преобразования данных

Хранения данных

52. Команды языка SQL подразделяются на команды языка

53. Команды языка SQL подразделяются на команды языка

54. Команды языка SQL подразделяются на команды

Администрирования базы данных

Управления транзакциями

Нормализации базы данных

Модернизации базы данных

55. Значение NULL эквивалентно

Отсутствию информации

Цифре ноль

Пробелу

Прочерку

56. Представление

Ничем не отличается от таблицы

Постоянно хранит какие-либо данные

Отличается от таблицы только форматированием

Большую часть времени не содержит данных

57. Хранимые процедуры представляют собой

Группы связанных SQL – операторов

Подпрограммы

Правила хранения данных

58. Триггеры представляют собой

Разновидность хранимых процедур

Способ хранения данных

Процедуры резервного копирования

Функции защиты данных от несанкционированного доступа

59. Разграничение доступа к информации, хранящейся в базе данных, регулируется с помощью привилегии

На создание таблицы

60. Разграничение доступа к информации, хранящейся в базе данных, регулируется с помощью привилегии

На создание хранимой процедуры

INSERT (имя_поля)

UPDATE (имя_поля)

61. Объектными привилегиями являются привилегии

На создание таблицы

На создание хранимой процедуры

На создание представления

62. Объектными привилегиями являются привилегии

На удаление таблицы

На удаление представления

На удаление хранимой процедуры

63. Привилегия REFERENCE разрешает

Ссылаться на все поля указанной таблицы

Создавать и удалять таблицы, представления и хранимые процедуры

Передавать права доступа другим пользователям

Изменять информацию в базе данных

64. Для управления доступом пользователей к базе данных в языке SQL существует оператор

65. Оператор GRANT служит для

Предоставления пользователю как системных, так и объектных привилегий

Отмены предоставленных пользователю привилегий

Предоставления пользователю системных привилегий

66. Оператор REVOKE служит для

Отмены предоставленных привилегий

Предоставление пользователю системных привилегий

Предоставление пользователю как системных, так и объектных привилегий

Предоставление пользователю объектных привилегий

67. Power Designer это

Система моделирования данных

Язык программирования высокого уровня

Программа для быстрой разработки сайтов

68. CASE средства могут осуществлять

Генерацию документации

Верификацию проекта

Помощь в принятии решений

Выбор языка программирования или СУБД

69. CASE средства могут осуществлять

Автоматическую генерацию программного кода

Сопровождение и реинжиниринг

Согласование этапов разработки с заказчиком

Оценку стоимости проекта

70. Возможность определения единственного имени для процедуры или функции, которые применяются ко всем объектам иерархии наследования, является следствием

Полиморфизма

Инкапсуляции

Наследования

Внедрения

71. Комбинирование данных с процедурами и функциями, манипулирующими этими данными, это следствие

Инкапсуляции

Наследования

Полиморфизма

Связывания

72. Возможность использования уже определённых классов для построения иерархии классов, производных от них, это –

Наследование

Согласованность классов

Приемственность

Инкапсуляция

Ответы к тесту по Информационные системы

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

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

2. Можно было бы довольно долго рассуждать на темы, что такое CASE-средства, с чем их едят, как они используются в тех или иных организациях, как правильно их использовать. Если выражаться образно, можно довольно долго витать в CASE-облаках. Однако мы все работаем в одной и той же конкретной организации - РУМС. А раз так, то желательно постоянно помнить об этом и стараться по мере возможности не терять привязки к конкретике. То есть мы должны исходить в своей работе из интересов нашей организации и анализировать CASE-средства исходя именно из этого обстоятельства.

3. Очевидно, что в реальности мы не можем себе позволить купить любое CASE-средство, имеющееся на рынке, тут есть вполне определенные ограничения, у кого-то могут возникнуть языковые проблемы при работе с теми зарубежными средствами, которые пока не получили достаточно широкого распространения в России и, наконец, у всех нас есть текущая плановая работа, от которой нас все равно никто не освободит.

Указанные выше три обстоятельства - доступ к сети Интернет, привязка к потребностям РУМС и ограниченность выбора CASE-средств позволяет заметно сузить диапазон обсуждаемых сегодня проблем.

Прелюдия или эпиграф

Начну с анекдота об итальянском рыбаке.

"Лежит на берегу теплого Адриатического моря итальянский рыбак и н-и-ч-е-г-о не делает. Мимо проходят американские туристы и обращаются к рыбаку с вопросом.

· А что это Вы тут лежите, ничего не делаете, не зарабатываете деньги?

· А ЗАЧЕМ?

· Ну как, удивляются американцы, Вы могли бы больше работать и стать не просто рыбаком, а владельцем лодки.

· А ЗАЧЕМ?

· Вы могли бы еще больше работать и стать владельцем нескольких лодок.

· А ЗАЧЕМ?

· Вы стали бы крупным собственником, зарабатывали бы много денег и могли бы себе позволить отдыхать на берегу и ничего не делать.

· А Я ЧТО ДЕЛАЮ?"

Анекдот любопытный. Недаром его приводят в некоторых руководствах по стратегическому менеджменту… Ответ на вопрос: а зачем мне это надо каждый дает себе сам. К сожалению, вы не получите от меня ответа на вопрос: а зачем именно вам нужны CASE-средства. Ни сегодня, ни завтра. Каждый умирает в одиночку и на этот вопрос каждый отвечает себе сам. Я же постараюсь рассказать о своем опыте, о своей точке зрения, о своей версии ответа на этот ключевой вопрос и высказать свое мнение, которое отнюдь не претендует на универсальность.

Есть такая наука: ботаника. Пестики, тычинки, стебли, корни и листья.. Описание природы. Обычно словесное, но в письменной форме. Есть другая наука: болтаника. Сегодня мы займемся именно этим: болтаника на тему что такое CASE-технологии и как с ними бороться. Прошу набраться терпения минут так на 30-40 и постараться суметь вынести мои вольные разлагольствования на вышеуказанную тему в течение всего этого промежутка времени. На всякий случай прошу прощения у дам, если некоторые примеры покажутся им чересчур, так скажем, легкомысленными..

2. Термины и определения

2.1. О терминах

Как это часто бывает, под одним и тем же термином разные люди понимают каждый свое. В этой связи начну с довольно широко известного примера: трое слепцов пытаются дать определение термина "слон". Один держит его за хобот, другой за хвост и третий за ногу. Очевидно, что определения, выданные каждым из слепцов, будут разными, хотя речь все будут вести об одном и том же объекте - слоне. Аналогично обстоит дело с термином CASE - технологии. Если набрать в строке поиска термин CASE-средства или CASE-технологии, можно получить сотни документов, так что любой из вас может это сделать самостоятельно на своем рабочем месте и… читать до потери пульса. На что можно обратить внимание?

В большинстве источников по умолчанию предполагается, что читатель уже знает, что такое CASE-средства или CASE-технологии и, более того, знает, что же сам автор публикации понимает под этим термином. Представьте, что было бы, если бы те трое слепцов надумали писать книгу на тему: слоны - общий обзор и сравнительные характеристики. И на этом основании делали бы выводы о целесообразности практического использования слонов, например, при сборе бананов или ловле рыбы, причем сами они при этом не сказали бы читателю, что слон - это что-то типа веревки (хвост), трубы (хобот) или столба (нога). Что делать читателю? Куда податься? И что интересно: выводы у трех слепцов были бы, наверное, разными. При этом довольно очевидно, что вряд ли бы они нашли взаимопонимание даже друг с другом. Хотя все они являются специалистами по CASE-технологиям, то есть, я хотел сказать, по слонам. Слоноведы, в общем... Примем для простоты, что каждый из трех слепцов добросовестный, искренний, старается во всем, что называется, дойти до сути.. А потому смотрит, что же пишут про слонов другие.. И что он видит? Тот, который слона за ногу держит, говорит, что слоны - удобный стульчик при ловле рыбы. А тот, который держал слона за хвост, с этим не согласен: слон - удобное орудие ловли, что-то типа лески. И т.д. и т.п. И вот начинают они спорить.. Как говорится, результат любого их спора можно легко предсказать заранее: переход на личности, выяснение отношений и… Да что вы понимаете! Да как вы так можете - слона на стул.. Это же веревка! Сам такой… А третий будет молча ухмыляться в усы, - он же знает, что слон - это нечто вроде трубы и только посмеивается над этими двумя.. В лучшем случае каждый останется при своих.. Почему? Просто на старте они не договорились о терминах. Такое довольно часто бывает в жизни.

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

Расшифровка аббревиатуры CASE: Computer Aided Software Engineering, что можно перевести на русский примерно как разработка программного обеспечения с помощью компьютера. В соответствии с ГОСТ 19781-90 Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации. А если говорить проще: ПО - это программы, используемые в компьютере вместе с их описанием. И что же мы имеем? То есть разработка программ, используемых в компьютере, с помощью компьютера. Так? А как же писать их без компьютера? Это что же получается.. Ухаживать за девушкой с помощью… девушки.. А как же ухаживать за ней когда нет девушки? Вы можете себе это представить? Я - как-то смутно. Можно, конечно, из камня там Галатею тесать или музыку сочинять, особенно когда тебе делать больше делать нечего… В общем, ясно, что ничего не ясно. Как это: разрабатывать ПО с помощью ПК? Вопрос, конечно, интересный.. Давайте разбираться вместе.

2.2. Спускаясь на землю

Очевидно, что ПО бывает разное. В частности, прикладное и системное. Тут все просто: мы работаем в ОПО - структурном подразделении РУМС и по роду своей профессиональной деятельности многие из нас вовлечены в процесс разработки прикладного ПО.

Что говорят нам наши заказчики? Обобщенно это можно охарактеризовать так: напишите нам программу, чтобы работала. Что это означает, сами заказчики, как правило, сформулировать свои желания на формальном языке не могут. И дело тут не в том, что именно нам так не повезло, и что именно наши заказчики, скажем, не сильно задумываются над тем, что они говорят и/или пишут в своих справках и ТЗ. Дело совсем даже не в этом. Заказчики у нас самые что ни на есть нор-маль-ны-е. Такая ситуация характерна для большинства организаций-заказчиков. Заказчик часто сам не знает чего хочет или знает, но не говорит, или знает, но сказать не может.. Прям как собака.. И это - нормально. Как бы то там ни было, но мы здесь, в ОПО, не можем сидеть сложа руки и смиренно ждать, когда же наши заказчики сумеют писать нам готовые ТЗ, по которым вот так вот прямо вот сразу вот можно было разрабатывать программное продукты. В этой связи, кстати, в свое время был разработан стандарт РУМС "Жизненный цикл ПО", в котором все довольно подробно расписано: что, зачем, куда и почему. И те, кто его еще не читал, можно порекомендовать пользоваться им в своей практике уже сейчас при общении с нашими заказчиками. Но в этом стандарте ничего не говорится ни о CASE-средствах, ни об особенностях разработки ПО, и даже модели ЖЦ ПО (каскадная, водопадная и спиральная), по-моему, там не описаны даже. Это все - наша внутренняя кухня. И сегодня речь идет именно об этом: о нашей внутренней кухне.

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

Вопрос: а как же все таки можно использовать наши компьютеры для разработки этого самого прикладного ПО?

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

Для тех, кто не читал книгу Гради Буча "Объектно-ориентированный анализ и проектирование", возможно, будет интересно узнать, а другим же просто напомню, что его классический труд начинается со следующего анекдота.

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

Как говорится, в каждой шутке есть доля шутки. Когда речь идет о необходимости разработки сложного (или, по терминологии Гради Буча, промышленного) ПО, возникают свои, довольно специфические проблемы, которые, возможно, и на самом деле могут быть в некоторых случаях преодолены за счет целенаправленного и осознанного использования CASE-средств, - кто знает?

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

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

В литературе можно найти много хороших, красивых, умных слов о том, что такое CASE-средства, для чего они используются, что с ними можно делать, и как они позволяют нам сэкономить силы, время, деньги, нервы, здоровье и т.д. и т.п. Ну, в общем, каждый может сам читать много хорошего на эту тему. В Интернете уже столько дифирамбов на эту тему имеется, что иногда волей-неволей возникает желание сказать: "Не надо агитировать меня за Советскую власть".. Или, как людоедка Эллочка, "Не учите меня жить.. Лучше помогите материально".. В переводе на русский это будет означать, дайте мне ответ на вопрос: какое средство и где применять? В сети информация и на эту тему чрезвычайно обширна. Можно проводить долгие часы у экранов мониторов и читать, читать, читать.. Аналогично, можно было бы сейчас болтать, болтать, болтать.. Смысла во всем этом занятии я лично не вижу. Предлагаю сейчас порассуждать на эту тему, исходя из элементарного здравого смысла.

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

Vantage Team Builder (Westmount I-CASE);

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

Чтобы попытаться найти ответ на этот вопрос, что абсолютно необходимо сделать до того, как мы будем проводить общий обзор и тем более анализ имеющихся на рынке CASE-средств, вернемся назад, к себе, в РУМС. Очевидно, что я могу отвечать только за себя. И буду искать свой вариант ответа. И предложу его сегодня на всеобщее обозрение.

Возвращаясь к Чеширскому коту и итальянскому рыбаку, зададим себе следующий вопрос: а зачем нам это надо, - применять какие-то там CASE-средства, когда это здесь, в РУМС, никому это не нужно, когда все равно ничего не изменится, выше головы не прыгнешь, никто не оценит и… премию за это не выпишут… И вообще: начальство у нас не сильно интересуется информационными технологиями и убедить их в необходимости закупки лицензионного ПО довольно затруднительно, и т.д. и т.п. Знакомо? Вспоминая классика: "Эх, ребяты, все не так, Все не так, как надо…" Перечень претензий может быть продолжен в курилке или здесь - не суть важно. Как говорится, каждый умирает в одиночку. И если у кого-то есть желание лежать на берегу Адриатического моря и любоваться на закат, он может продолжать это делать, по крайней мере до тех пор, пока не получит гм.. пинок от руководства или хотя бы морковку…

Итак, CASE-средства, - это средства, помогающие нам разрабатывать сложное ПО с помощью компьютера. О необходимости унификации разрабатываемого ПО, создания каких-то универсальных модулей, библиотек и т.д. и т.п. говорится в этих стенах давно. У многих есть предложения, что и как делать.. В общем, не будем перечислять все эти знакомые нам всем проблемы, болячки и т.д. Обратимся лучше к примерам. Вот почему-то никого не удивляет, что, когда мы приходим в местную поликлинику на прием, там есть кабинеты окулиста, терапевта, хирурга и т.д. и т.п. То есть медицина - это одно, а вот что касается информационных технологий, то… Если развить эту аналогию дальше, можно сказать, что программист - это аналог термина "врач". Не так ли? Но у каждого из нас есть своя узкая специализация..

Я стать хотел геологом, дерматовенерологом,

Потом хотел я быть, как мама, гинекологом,

А стал невропатологом назло врагам!

Теперь лечу их молотом по головам…

А. Розенбаум

Итак, уж нам-то промеж собой вряд ли нужно объяснять, что все мы тоже специализируемся каждый в своей области. Я вот стал невропатологом, то есть, я хотел сказать, занимаюсь разработкой информационных моделей отдельных структурных подразделений РУМС и всего РУМС в целом. Отсюда вытекает и выбор того инструментария, которым я пользуюсь; и в самом деле, не будет же хирург делать операции молоточком.. Верно? Так и тут.. В общем, на эту тему у нас будут отдельные занятия, а пока вернемся к нашим ба… то есть к CASE-средствам.

Я уж вернусь к себе и изложу свою точку зрения, не претендуя на какие-либо обобщения. Но особо подчеркну: пока ответ на этот вопрос не получен, все остальные усилия бессмысленны. Тогда все равно куда идти..

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

Как у нас обычно разрабатывается ПО? Мы - не свободные художники. У каждого из нас есть вполне определенный план, утвержденный Главным инженером РУМС. В этом плане подробно расписано, кто чем занимается. План висит на стенде. Откуда появились пункты из этого плана? - Ясно дело, все делается по просьбам трудящихся.

Примем в качестве аксиомы следующее утверждение: мы обязаны, то есть нам это нужно, - выполнять указания Главного инженера и просьбы наших заказчиков. Обоснование: нам именно за это здесь деньги платят. Мне кажется, обоснование довольно серьезное. И именно в этом контексте будем искать ответы на вопрос, какие именно CASE-средства нам нужно использовать. Тогда как следствие, получаем ответ на вопрос Чеширского кота: мы хотим выполнить Календарный план ОПО РУМС.

В списке задач ОПО 70 позиций, - это и тарификация (биллинг и предбиллинг), анализ аварии, статистики, программы учета и т.д. Многие из них так или иначе основаны на анализе информации, идущей от станций АХЕ10-1 и АХЕ10-2. Задачи очень серьезные, масштабные и сложные. Главная сложность состоит в том, что постоянно приходят все новые и новые вводные в форме справок, запросов, служебных записок и т.д. и т.п. Как говорится в той же классической книге Гради Буча, почему-то когда строитель строит 100-этажный дом, то когда уже выстроены верхние этажи, никому не приходит в голову просить строителя переделать или расширить фундамент. А у нас это сплошь и рядом. В чем тут дело, какие выходы могут быть, - например, во внедрении спирального ЖЦ ПО или другие, лучше пусть судят те, кто сам ежедневно с этим сталкивается. Я же лучше обращусь к тем проблемам, с которыми пришлось столкнуться мне, и уже на этом - своем - примере показать и рассказать, какое именно CASE-средство было выбрано для решения поставленных задач и почему именно оно, а не какое-то другое. Вот это и будет обзором и анализом сравнительных характеристик.

4.2. Мой опыт

Примерно год назад мне была поставлена задача, которую кратко можно сформулировать следующим образом: описать технологии и построить информационные модели структурных подразделений РУМС… И далее - список подразделений.. Получив такое задание в начале 2003 г., я довольно долго чесал репу, что же мне делать и как же мне быть.. Думал на самом деле долго.. В конце концов написал отчет на тему "Моделирование РУМС", в котором, что называется, высказал все, что думал по поводу полученного задания. Пар выпустил. Кому интересно, может почитать, мне не жалко. К моему удивлению, несмотря на все эти мои выкрутасы, с работы меня тем не менее все таки не выгнали, чему я, не скрою, очень даже рад. Потому что после длительной и продолжительной болезни, то есть, раздумий, сомнений, колебаний и размышлений была методом проб и ошибок выработана итерационная процедура описания технологических процессов, структуры и информационных моделей подразделений РУМС, которая в настоящее время реализована для ряда структурных подразделений.

На следующих занятиях мне предстоит сделать сообщения по темам "Диаграммы структурно-системного анализа" и "Универсальный язык моделирования (UML)". Видимо, тогда речь пойдет более конкретно обо всех этих делах, тогда мы и рассмотрим все более подробно, уже с конкретными примерами и диаграммами, а сейчас имеет смысл на том, из каких соображений выбиралось конкретное CASE-средство.

Очевидно, что далеко не последним фактором, определяющим выбор, является фактическая доступность или недоступность того или иного приложения. На старте выбор у меня был не очень велик: речь шла о продукте фирмы Platinum All Fusion Process Modeler (BPWin) и продукте фирмы Rational - Rational Rose. Оба эти продукта имелись в моем распоряжении, и сейчас они установлены на моем РС. Кто-то может выбрать и другие продукты, - это уже не суть важно. Чем отличаются эти продукты, как с ними работать, - тоже каждый может прочитать в описаниях программ, рекламе, Интернете и т.д. Сегодня же представляется целесообразным поговорить на другую тему, а именно: ответить самим себе на вопрос: чем один лучше (хуже) другого? Как уже неоднократно отмечалось выше, при этом ключевым является вопрос: "А зачем мне это надо?" Ответ на вопрос: чтобы строить информационные модели структурных подразделений РУМС. Итак, какой же из этих двух продуктов более подходит для построения информационных моделей и описания их технологических процессов. Чтобы ответить на этот вопрос, давайте немного порассуждаем.

Итак, я оказался в ситуации, когда нужно было хоть как, но моделировать технологии РУМС в целом и его отдельных структурных подразделений. Как я уже говорил, о моделировании РУМС в целом я уже от души высказался в своем отчете "Моделирование РУМС". Там высказано немало критических замечаний, касающихся нашей с вами жизни. Очевидно, что не только я один, но и многие из нас могут выпустить довольно изрядное количество стрел и в руководство наше, и по отдельным его специалистам, и в оборудовании мы еще не совсем, и линии у нас старые и система управления не отвечает современным требованиям т.д. и т.п. На все эти критические замечания я бы хотел ответить одной только фразой, произнесенной нашим Главным инженером во время одного из технических совещаний, с которым я лично согласен, как говорится, на все 100%. Итак, можно много ругать РУМС, Директора, Главного инженера, специалистов, охранников и т.д. и т.п. Но.. Есть одно Но.. РУМС - как система, как безусловно сложная техническая система - ра-бо-та-ет… Пусть где-то плохо, пусть где-то со скрипом, но ра-бо-та-ет.. То же самое можно сказать и про наше ПО: пусть оно и написано как-то не так, и быстродействие не очень, и базы там неудобные, и методы процедурные, и т.д. и т.п., но это все - ра-бо-та-ет.. Что же из этого следует? - Следует жить.. И, как следствие, ломать - не строить. Поэтому речь сейчас будет идти все таки о путях эволюционного, а не революционного развития.

Характеристики CASE средств

Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес процессов, являются следующие:

Наличие графического интерфейса. Для представления моделей процессов CASE средства должны обладать возможностью отображать процессы в виде схем. Схемы много проще в использовании, чем различные текстовые и числовые описания. Это позволяет получать легко управляемые компоненты модели, обладающие простой и ясной структурой.
Наличие репозитория. Репозиторий это общая база данных, которая содержит описание элементов процессов и отношений между ними. Каждый объект репозитария должен обладать перечнем свойств, характерных только для этого объекта.
Гибкость применения. Эта характеристика дает возможность представлять бизнес процессы в различных вариантах, важных с точки зрения анализа. CASE средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия.
Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек. Для одновременной работы над моделями процессов CASE средства должны обеспечивать управление изменениями любыми фрагментами моделей и их модификацией при коллективном доступе.
Построение прототипов. Прототипы процессов необходимы для того, чтобы на ранних стадиях изменения процессов можно было понять, насколько процесс будет соответствовать требованиям.
Построение отчетов. CASE средства должны обеспечивать построение отчетов по всем моделям процессов с учетом взаимосвязи элементов. Такие отчеты необходимы для анализа моделей и определения возможностей по оптимизации. За счет отчетов обеспечивается контроль полноты и достаточности моделей, уровень декомпозиции процессов, правильность синтаксиса диаграмм и типов применяемых элементов.

Выбор CASE средств

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