Ответы к экзамену по ИСПУ



Ответы к экзамену по ИСПУ (1-10)

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

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

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

2)

SADT-МЕТОДОЛОГИЯ – совокупность методов, правил и процедур, предназначенных для построения функциональной структуры сложных иерархических систем в виде модели, которая должна дать ответ на некоторые заранее определенные вопросы. В основе этого метода моделирования систем лежит описание системы, создаваемого с помощью естественного языка, позволяющего свободно описать функционирование моделируемой системы. На основе графических средств SADT/IDEF0 дескриптивное описание системы снабжается изображением ее модели, которое практически полностью устраняет возможную неоднозначность семантического описания.

В основе методологии SADT лежат два основных принципа:

1. SA-блоки, на основе которых создается иерархическая многоуровневая модульная система, каждый уровень которой представляет собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней.[1]

2. Декомпозиция: Построение Idef0-модели начинается с представления всей системы в виде простейшей компоненты — одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг — они также представляют полный набор внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Модель Idef0 представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. Некоторые дуги присоединены к блокам диаграммы обоими концами, у других же один конец остается раздельным. Раздельные дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Раздельные концы должны соответствовать дугам на исходной диаграмме. Все граничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой. На Idef0-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм.

Цель:SADT — это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственной системы средней сложности и ее среды до определения требований к программному обеспечению или к чему-либо другому.

Обычно SADT-методология применяется на ранних этапах жизненного цикла информационной системы. 

Cфера применения

SADT выделяется среди современных методологий описания систем благодаря своему широкому применению, т.к. SADT:

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

в дополнение к имеющимся концепциям и стандартам для создания систем добавлены развитые процедуры поддержки коллективной работы;

предназначена для применением на ранних стадиях создания системы;

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

Достоинствами применения моделей SADT являются:

• полнота описания бизнес-процесса (управление, информационные и ма-

териальные потоки, обратные связи);

• комплексность декомпозиции;

• возможность агрегирования и детализации потоков данных и информа-

ции (разделение и слияние дуг);

• наличие жестких требований, обеспечивающих получение моделей стан-

дартного вида;

• простота документирования процессов;

• соответствие подхода к описанию процессов стандарту ISO 9000:2000.

В то же время метод SADT обладает рядом недостатков:

• сложность восприятия (большое количество дуг на диаграммах);

• большое количество уровней декомпозиции;

• трудность увязки нескольких процессов, представленных в различных

моделях одной и той же организации.

3) функциональный (описывает функциональные подсистемы и пользователей),

Принцип моделирования по стандарту IDEF0 — построение древовидной функциональной модели предприятия. Это означает, что вся деятельность предприятия, его «основная функция», или любая ее часть, декомпозируется (разбивается) на отдельные виды деятельности («бизнес-процессы», «функции», «работы», англ. «activities»).Пример функциональной декомпозиции — разделение всей деятельности элементарного бизнеса на три «бизнес-процесса» — закупки, производство, продажи. Очевидно, что декомпозицию можно продолжать сколько угодно раз, все более и более детализируя описание деятельности организации. Результатом декомпозиции является иерархическая модель анализируемой деятельности, или дерево узлов функциональной модели. С каждым уровнем декомпозиции число узлов функциональной модели будет расти в геометрической прогрессии, что естественным образом ограничивает число уровней декомпозиции значением порядка 4-6. Надо заметить, что человек не способен одновременно воспринимать больше, чем 7-9 объектов, как единую систему. Поэтому желательно на каждом уровне не создавать большего количества узлов. Правильная декомпозиция обеспечивает восприятие моделируемой деятельности как единой системы, в которой все детали имеют значение.

IDEF0 — Function Modeling — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (WorkFlow).

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

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

Также отображаются все сигналы управления, которые на DFD (Диаграмме Потоков Данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

4)

IDEF1 — информационное моделированиеIDEF1X — моделирование данных

Предназначение IDEF1X

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

ущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. Примером сущности IDEF1X может быть сущность «СОТРУДНИК», которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, приведенном на рис. 1, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связи между сущностями

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой. Ниже приведен ряд примеров связи между сущностями:

Отдел <состоит из> нескольких Сотрудников

Самолет <перевозит> нескольких Пассажиров.

Сотрудник <пишет> разные Отчеты.

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

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

Разработка стандарта IDEF1 предполагает использование его в виде некого инструмента для детального анализа, а также изучения взаимосвязей среди информационных потоков коммерческой деятельности фирмы. Целью исследования — частичное дополнение и формирование структуры уже существующей информации и создание отличного менеджмента. Такая необходимость возникает обычно на первоначальном этапе построения корпоративной системы информации. Методология IDEF1 наглядно может представить образовавшиеся слабые и пустые места в современной инфраструктуре потоков. Использование такого подхода обеспечивает решение следующих задач:

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

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

определение потоков информации, которые предполагают дополнительный контроль над управлением.

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

1. Выявление проблем, которые могут образоваться вследствие отсутствия нормального управления информационным менеджментом2. Определение взаимосвязей среди существующих информационных потоков внутри предприятия3. Выяснение того, какие существуют законы и правила, а также принципы их координации4. Определение непосредственной информации и структуры ее потоков, которые имеют отношение к работе предприятия

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

Основные преимущества IDEF1

Методология IDEF1 позволяет на основе простых графических изображений моделировать информационные взаимосвязи и различия между:

Реальными объектами

Физическими и абстрактными зависимостями, существующими среди реальных объектов

Информацией, относящейся к реальным объектам

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

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

5) IDEF3 — моделирование процессов

IDEF3 (англ. Integrated DEFinition for Process Description Capture Method) — методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов представляет собой механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.

Два типа диаграмм в IDEF3

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

Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD),

а ко второму — диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN).

Иное встречающееся название для PFDD — диаграмма работ WFD (Work Flow Diagram).

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

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

Рисунок 1. Пример PFDD диаграммы.

На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Объект, обозначенный J1 — называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления.

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Рисунок 2. Пример OSTN диаграммы

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

6) IDEF3-модель отвечает на вопросы «Как система это делает?» Язык IDEF3 — язык диаграмм, помогающий разработчику моделей наглядно представить моделируемые процессы. В IDEF3 входят два типа описаний:

процесс-ориентированные в виде последовательности операций (Process Flow Description Diagrams, PFDD);

объект-ориентированные, выражаемые диаграммами перехода состояний, характерными для конечно-автоматных моделей (Object State Transition Network, OSTN).

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

Рис. 1.  IDEF3-диаграмма последовательности операций

Для указания разветвлений и слияний связей (их принято называть перекрестками) используют квадраты, у которых одна или обе вертикальные стороны представлены двойными линиями, а внутри квадрата записан один из символов &O или X. При разветвлении эти символы означают реакцию всех, некоторых или только одной из последующих функций на входное воздействие соответственно. Аналогичный смысл имеют символы &O или X при слиянии — последующая функция начинает выполняться после окончания всех, некоторых или только одной из входных операций. Например, перекрестки рис. 2 соответствуют логической операции И, т.е. все входные процессы должны быть завершены, а все выходные процессы должны быть запущены, отличие синхронного И (рис. 2,б) от асинхронного И (рис. 2,а) состоит в том, что в асинхронном случае все выходные процессы запускаются одновременно.

Рис. 2.  Перекрестки

На рис. 4 представлен пример объект-ориентированной IDEF3-диаграммы. В таких диаграммах имеются средства для изображения состояний системы, активностей, переходов из состояния в состояние и условий перехода.

Рис. 4.  IDEF3-диаграмма перехода состояний

7) IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: «Что делает система?», то в этих методиках детализируется ответ на вопрос: «Как система это делает». В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний. Перечисленные методики относятся к так называемым структурным методам.

IDEF4 Объектно-ориентированное проектирование

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

Object-Oriented Design — методология построения объектно-ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы.

IDEF5 Систематизация объектов приложения

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

Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 Использование рационального опыта проектирования

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

Design Rationale Capture — Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF8 Взаимодействие человека и системы

IDEF8 предназначен для проектирования диалогов человека и технической системы.

User Interface Modeling — Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 Учет условий и ограничений

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

Scenario-Driven IS Design (Business Constraint Discovery method) — Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF14 Моделирование вычислительных сетей

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

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

8) 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 средства поддерживают 2 технологии:

— all fusion (поддерживает структурную методологию, IDEF0, IDEF1 и т.д.) — datarun

— объектно-ориентированную методологию (UML). – RUP (рациональный унифицированный процесс)

Достоинства CASE-Технологии.

            Основными достоинствами CASE-технологии являются:

1.                 Повышение качества созлдаваемой системы за счет введения функции контроля.

2.                 Они позволяют за короткое время создать прототип будущей системы, оценить ожидаемый результат.

3.                 Они ускоряют процесс проектирования и разработки.

4.                 РОсбобождают разработчиков от рутинной работы, оставляя время для творческой деятельности.

5.                 Поддерживают развитие и сопровождение разработки.

                         Основы CASE-технологии.

Основой CASE-технологии является совокупность методологии (метод) нотации (средства).

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

— Метод – это системат. процедура или техника описания комплексных явлений.

— Нотации предназначены для описания структур систем, элементов данных, этапов обработки и включают: графики, блок-схемы, диаграммы, таблицы и др.

— Средство – это инструментарий для поддержки и усиления метода.

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

9)

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

1) средства программирования;

2) средства управления программным проектом;

3) средства верификации (анализа) программ;

4) средства документирования.

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

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

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

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



sitemap
sitemap