Информационные технологии управления

Вид материалаДокументы

Содержание


7.4. Экономическая эффективность автоматизированных систем
7.5. Инструментальные средства проектирования
7.5.1 Инструментальные средства и среды CASE-систем
7.5.2. Визуальные средства моделирования систем
Концептуальная модель UML
Виды диаграмм
Подобный материал:
1   ...   28   29   30   31   32   33   34   35   36

7.4. Экономическая эффективность автоматизированных систем



ГОСТ 24.702-85 определяет основные положения по эффективности автоматизированных систем управления, которую определяют сопоставлением результатов от функционирования АСУ и затрат всех видов ресурсов, необходимых для ее создания и развития. Основными обобщающими показателями экономической эффективности являются:
  • годовой экономический эффект;
  • расчетный коэффициент эффективности капитальных затрат на разработку и внедрение АСУ;
  • срок окупаемости капитальных затрат на разработку и внедрение АСУ.

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

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

На практике в последние годы расчет экономической эффективности не производят, а выполняют только расчет финансовых затрат на разработку и внедрение автоматизированных систем на стадии разработки ТЗ на создание автоматизированных систем.

7.5. Инструментальные средства проектирования


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

Функционально-модульный подход

Основан на принципе алгоритмической декомпозиции с выделением функциональных элементов и установлением строгого порядка выполняемых действий

Объектно-ориентированный подход

Основан на объектной декомпозиции с описанием поведения системы в терминах взаимодействия объектов.


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

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

В каждом классе ИС (АСУ, АСУ ТП, САПР, ГИС и т.д.) имеются фирмы, специализирующиеся на разработке программных (а иногда и программно-аппаратных) систем. Каждая рекламирует свою технологию создания ИС и придерживается стратегии либо тотального поставщика, либо открытости и расширения системы приложениям и дополнениями третьих фирм.

В последнее время прослеживается общее повышение интереса ко всем аспектам, связанным с разработкой сложных программных приложений для ИТ. Для многих организаций корпоративное программное обеспечение и БД представляют стратегическую ценность. Существует высокая заинтересованность в разработке и верификации методов и подходов, позволяющих автоматизировать создание сложных АИС. Известно, что систематическое использование таких методов позволяет значительно улучшить качество, сократить стоимость время поставки АИС. В настоящее время эти методы включают в себя:
  • компонентную технологию разработки моделей информационных систем;
  • визуальное программирование (RAD-средства);
  • использование образцов (patterns) при проектировании ИС;
  • визуальное представление различных аспектов проекта (CASE-средства, визуальное моделирование).

7.5.1 Инструментальные средства и среды CASE-систем


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

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

Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем:
  • автома­тизированное проектирование программного обеспечения – Computer Aided Software Engineering. Соответствующие CASE-системы часто называют инструментальными средами разработки программного обеспечения– RAD – Rapid Application Development;
  • поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных – Computer Aided System Engineering. Такие CASE-системы часто называют системами BPR – Business Process Reengineering.

На рынке программных продуктов имеется много CASE-систем для концептуального проектирования ИС. Чаще всего в них ИС поддерживается методология IDEF.

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

Этот стандарт позволяет создавать модели, которые графически изображают предметы и действия (рис. 7.3.)

Широко известны программные системы:



Система

Особенности системы

BPWin (Business Processing)

Разработка функ­циональных моделей по стандарту IDEFO.

ERWin

Разработка информационных моделей по стандарту IDEF1X. Имеются средства, обеспечивающие интерфейс с серверами БД (от пользователя скрыто общение на SQL-языке), перевод графических изображений ER-диаграмм в SQL-формы или в форматы других популярных СУБД. В систему включены также типичные для CASE средства разработки экранных форм.

OOWin

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

ProSim

Реализует стандарт IDEF3

SmartClass

Реализует стандарт IDEF4

BAAN IV

Система реинжиниринга. В основе - поведенческое моделирование пред­приятий


Известны также системы Design/IDEF фирмы Meta Software, CASE-Аналитик фирмы Эйтэкс, Silverrun фирмы CSA и др.

7.5.2. Визуальные средства моделирования систем


Мно­гими объектно-ориентированными CASE-продуктами поддерживается язык UML (Unified Modeling Language – Унифицированный Язык Моделирования) – стандартная нотация визуального моделирования систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г.

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

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

Визуальные модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков, обеспечивают ясность представления выбрани системных спецификаций и позволяют разобраться с возникающими проблемами разрабатываемой системы. Представив язык моделирования общего назначения, авторы проекта UML упростили задачу разработчикам, использовавшим до сих пор разнообразны частные интерфейсы. Большинство производителей (в том числе такие крупные корпорации, как IBM, Microsoft и Oracle) уже ceгoдня объединились на платформе UML. Этот язык использует про­стые и интуитивно понятные соглашения, поэтому в особенности модели без труда разбираются и непрограммистами, т.о., вероятность успеха реализации разработчиками необходимых функций существенно возрастает.

Язык визуального моделирования, как правило, включает в себя:
  • элементы модели – фундаментальные концепции моделирования и их семантику;
  • нотацию – визуальное представление элементов моделирования;
  • принципы использования – правила применения и интерпретации элементов в рамках построения тех или иных типомоделей ИС.

Концептуальная модель UML


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

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

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

Виды диаграмм

Назначение диаграмм

Диаграммы объектов и классов

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

Диаграммы действия

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

Диаграммы состояния

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

Диаграммы компонентов и развертывания

Предназначены для физического представления системы (в том числе исполняемых модулей, библиотек и интерфейсов).


Последовательность и взаимные связи диаграмм отражают интерактивные процессы: вы видите не только объекты и классы, но и сообщения, которыми они обмениваются. Таким образом, с помощью систем можно моделировать ситуации, применяя обычную в таких случаях технологию «что, если...».

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

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

UML не является языком визуального программирования, но модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. UML-модель можно отобразить на такие языки, как Java, C++, Visual Basic, и даже на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Те понятия, которые предпочтительно передавать графически, так и представляются в UML; те же, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования. UML - графический язык.

Последний вариант спецификаций UML содержит ряд улучшений, к которым относятся новые семантические конструкции, усовершенствованная организация и структуризация документов, а также поддержка нового интерфейса XMI (XML Metadata Interchange). В дальнейшем разработчики намерены предложить интерфейсы для технологий CORBA, Enterprise JavaBeans и XML, средства контроля версий моделей и взаимного обмена диаграммами, более точные обозначения для представлений корпоративной архитек­туры, улучшенную семантику для дальнейшей модернизации и отслеживания зависимостей.

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