31734

CASE-средства, практическое внедрение CASE-средств

Лекция

Информатика, кибернетика и программирование

Технология внедрения CSEсредств Процесс внедрения CSEсредств включает следующие этапы: определение потребностей в CSEсредствах; оценка и выбор CSEсредств; выполнение пилотного проекта; практическое внедрение CSEсредств. Несмотря на все потенциальные возможности CSEсредств существует множество примеров их неудачного внедрения в результате чего эти средства становятся полочным ПО shelfwre. В связи с этим необходимо отметить следующее: CSEсредства не обязательно дают немедленный эффект; он может быть получен только спустя...

Русский

2014-10-04

150.5 KB

3 чел.

ЛЕКЦИЯ ПИС 8.05.02

3. Технология внедрения CASE-средств

Процесс внедрения CASE-средств включает следующие этапы:

определение потребностей в CASE-средствах;

оценка и выбор CASE-средств;

выполнение пилотного проекта;

практическое внедрение 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-средств должны быть готовы к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также к постоянным затратам на обучение новых сотрудников и повышение квалификации действующего персонала.

Структурный подход к проектированию систем

1. Основные понятия структурного подхода

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

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

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

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

Все методологии структурного анализа базируются на ряде общих принципов, часть из которых регламентирует организацию работ на начальных этапах ЖЦ, а часть используется при выработке рекомендаций по организации работ. В качестве двух базовых принципов используются следующие: принцип "разделяй и властвуй" и принцип иерархического упорядочивания.

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

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

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

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

2. Принцип формализации — заключается в необходимости строгого методического подхода к решению проблемы.

3. Принцип упрятывания — заключается в упрятывании несущественной на конкретном этапе информации:   каждая   часть   "знает"   только необходимую ей информацию.

4. Принцип концептуальной общности — заключается в следовании единой философии  на всех этапах ЖЦ (структурный анализ — структурное проектирование —   структурное программирование — структурное тестирование).

5. Принцип полноты —   заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости — заключается в обоснованности и согласованности элементов.

7. Принцип логической независимости   —   заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

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

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

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

2. Средства структурного анализа

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

  •  функции, которые система должна выполнять;
  •  отношения между данными;
  •  зависящее от времени поведение системы (аспекты реального времени).

Для функционального моделирования используются SADT-модели и DFD-модели. Функциональная модель отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Для моделирования данных используются ER-модели.

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

3. Методологии структурного системного анализа и проектирования

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

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

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

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

• разделение проекта на 10-50 модулей;

• организация иерархии модулей;

• определение маршрутов данных между модулями;

• определение форматов внешних файлов;

• определение способов доступа к внешним файлам;

• определение структур данных;

• проектирование ключевых алгоритмов;

• определение подпрограмм внутри каждого модуля.

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

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

4. Классификация структурных методологий

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

проектирования классифицируются по следующим признакам:

по отношению к школамSoftware Engineering (SE) и Information Engineering (IE);

по порядку построения модели — процедурно-ориентированные, ориентированные на данные и информационно-ориентированные;

по типу целевых систем — для систем реального времени (СРВ) и для информационных систем (ИС).

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

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

Разработка ИС основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели.

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

При подходе, ориентированном на данные, вход и выход являются наиболее важными — структуры данных определяются первыми, а процедурные компоненты являются производными от данных.

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

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

Таблица 2 классифицирует наиболее часто используемые методологии в соответствии с перечисленными признаками (данные по частоте использования получены на основе анализа информации по 127 CASE-пакетам).

Во всех перечисленных методологиях проектирования информационных систем в различных комбинациях используются приведенные в таблице 9.3 техники структурных  диаграмм.  Необходимо  отметить,  что  для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.

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

Основные этапы подхода Мартина

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

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

2. На этапе анализа основные бизнес-процессы, разработанные на этапе 1, используются для разбиения общей задачи на частные, при этом основное   внимание   уделяется   определению информационной и функциональной моделей для частных задач. При этом диаграммы   "сущность-связь" трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD,   диаграммы зависимости данных (диалект DFD) и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы "сущность/процесс".

3. На этапе логического проектирования IE становится аналогична SE для разработки ПО. Базой для проектирования являются процессы, разработанные на этапе анализа. Используя методики нисходящей     функциональной     декомпозиции, проектируются спецификации обработки в процессах и их логические структуры данных. При этом используются диаграммы структуры данных (диалект ERD), определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы деятельности (вид миниспецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов.

4. На этапе физического проектирования и реализации производится преобразование логической модели ИС в физическую и ее реализация.


 

А также другие работы, которые могут Вас заинтересовать

9070. Схоластическая система Фомы Аквинского 17.39 KB
  Схоластическая система Фомы Аквинского Фома Аквинский - ангельский доктор. Монах доминиканского ордена. Ему необходимо было что-то противопоставить линии Августина. Его целью было примирить Аристотеля с христианством. И ему это с блеском удало...
9071. Трактовка человека в философии Пико дела Мирандолы 21.54 KB
  Трактовка человека в философии Пико дела Мирандолы По произведению Речь о достоинстве человека. Прежде всего обращаем внимание на эпиграф Человек - свободный творец самого себя. Первое о чем рассказывает- в писании арабов некий Абдалла Сарацин...
9072. Никколо Макиавелли Государь 32.76 KB
  Никколо Макиавелли Государь Здесь фактически просто мой краткий пересказ произведения по главам. Глава I. Скольких видов бывают государства и как они приобретаются. Есть либо республики, либо государства, управляемые единовластно. Последние могут бы...
9073. Философия Рене Декарта (смысл и назначение философии, принцип методологического сомнения, сущность дедуктивного метода, учение о врожденных идеях.) 17.96 KB
  Философия Рене Декарта (смысл и назначение философии, принцип методологического сомнения, сущность дедуктивного метода, учение о врожденных идеях.) Рене Декарт (1596- 1650).Его философия- рационалистическая. Декарт- основоположник рационализма. Прот...
9074. Рационализм 17 века: основные идеи и представители 15.67 KB
  Рационализм 17 века: основные идеи и представители Основное положение рационализма: главный источник знания- идеи, т. е .мысли и понятия, изначально присущие человеку или являющиеся его врожденными способностями. Рационалисты: Рене Декарт, Г.В...
9075. Эмпиризм 17 века. Основные идеи и представители 15.87 KB
  Эмпиризм 17 века. Основные идеи и представители. Эмпиризм- направление в философии, сторонники которого считают, что в основе познаний лежит опыт. Английские эмпирики- Ф. Бэкон, Г. Гоббс, Дж. Локк. Бэкон: Рационалисты науки- философы. Муравьи- собир...
9076. Христианский предэкзистенциализм С. Кьеркегора 15.58 KB
  Христианский предэкзистенциализм С. Кьеркегора Экзистенциализм- направление философии, главным предметом изучения которого стал человек, его проблемы, трудности, существование в окружающем мире. Основателем экзистенциализма считается датский ф...
9077. Воля к жизни А. Шопенгауэра, воля к власти Ницше 15.63 KB
  Воля к жизни А. Шопенгауэра, воля к власти Ницше Ницше: Воля к власти - это одна из разновидностей волевых импульсов человеческого поведения. Волю к власти Ницше считал определяющим стимулом деятельности и главной способностью человека. Осново...
9078. Имморализм и теория сверхчеловека в философии Ницше 17.35 KB
  Имморализм и теория сверхчеловека в философии Ницше ИММОРАЛИЗМ (или аморализм), направление в этике, отрицающее мораль и какие бы то ни было нравственные нормы, связывающие волю индивида. В качестве представителей Имморализма в новой философии можно...