Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Автоматизированное проектирование информационных систем с использованием технологий RAD, ERP, CASE.
Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ЭИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств. CASE-технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект. Метод - это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных). Нотация - отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках. Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС.
Рассмотрим архитектуру CASE-средства, которая представлена на рис. 13.1. Рис. 13.1. Архитектура CASE-средства Ядром системы является база данных проекта - репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следу ющих объектов: · проектировщиков и их прав доступа к различным компонентам системы; · организационных структур; · диаграмм; · компонентов диаграмм; · связей между диаграммами; · структур данных; · программных модулей; · процедур; · библиотеки модулей и т.д. Графические средства моделирования предметной области позволяют разработчикам автоматизированных ИС в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в интерактивном (диалоговом) режиме, вводятся в словарь данных, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений. В любой момент времени диаграммы могут быть распечатаны для включения в техническую документацию проекта. Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции: · создавать элементы диаграмм и взаимосвязи между ними; · задавать описания элементов диаграмм; · задавать описания связей между элементами диаграмм; · редактировать элементы диаграмм, их взаимосвязи и описания. Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции: · мониторинг правильности построения диаграмм; · диагностику и выдачу сообщений об ошибках;
· выделение на диаграмме ошибочных элементов. Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом. Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций: · инициализации проекта; · задания начальных параметров проекта; · назначения и изменения прав доступа к элементам проекта; · мониторинга выполнения проекта. Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория. Современные CASE-системы классифицируются по следующим признакам: 1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования); 2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями; 3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием); 4) по типу и архитектуре вычислительной техники: ориентированные на компьютеры, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа; 5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов; 6) по типу операционной системы (ОС): работающие под управлением WINDOWS; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.). В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших компьютеров. Современные CASE-системы охватывают обширную область поддержки различных технологий проектирования и программирования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС. Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию баз данных и пользовательских интерфейсов. Генерация интерфейсов с базами данных и возможность преобразования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные среды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить разработку приложений от ведения архива проектной документации. Наиболее трудоемкими этапами разработки ЭИС являются этапы анализа и проектирования, поэтому CASE-системы, как правило, предназначены для автоматизации отслеживания качества принимаемых проектных решений и подготовки документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил.
Стратегия выбора CASE-систем для конкретного применения зависит как от целей и потребностей самого проекта, так и от квалификации вовлеченных в процесс проектирования специалистов. В большинстве случаев одно средство не может обеспечить все потребности проекта. Разработчики, как правило, применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое - для проектирования систем. В общем случае при выборе CASE-системы необходимо учитывать следующие аспекты. · Наличие базы проектных данных, архива или словаря. СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями. · Интерфейсы с другими CASE-системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые CASE-системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методологий. · Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной ЭИС, могут быть использованы для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спецификаций в различные CASE-системы. · Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект. · Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна позволять безболезненно переходить от одной CASE-системы к другой. · Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью совершенствоваться с учетом появления новых требований или новых предметных областей.
· Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений. · Обеспечение качества проектной документации. Это требование относится к возможностям CASE-системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации, находящейся в архиве или словаре. · Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектирования, служат источником документирования системы. Часто возникает потребность получения твердой копии спецификаций в текстовой или графической форме. · Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД. · Планирование и управление проектом. Использование CASE-систем не исключает потребности в эффективном управлении проектом. Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спецификации, которые используются этими средствами, представляют собой опорные точки управления, позволяющие определять сроки разработки. RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания средств разработки программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. Практическое определение: RAD — это жизненный цикл процесса проектирования, созданный для достижения более высокой скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию. С конца XX века RAD получила широкое распространение и одобрение. Концепцию RAD также часто связывают с концепцией визуального программирования. Технологию RAD целесообразно применять, когда четко определены некоторые приоритетные направления разработки проекта. Сравнение RAD и Каскадного метода
Принципы RAD технологии направлены на обеспечение трех основных её преимуществ — высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.
Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн и перепихивания.
Модель быстрой разработки приложений (RAD)
Технология быстрой разработки приложений (RAD) позволяет обеспечить:
ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности[1][2]. ERP-система — конкретный программный пакет, реализующий стратегию ERP. Концепция ERP сформулирована в 1990 году аналитиком Gartner как видение развития методик MRP II и CIM (англ.), в начале — середине 1990-х годов появилось несколько успешных тиражируемых ERP-систем для крупных организаций, наиболее известные — разработки компаний Baan (нидерл.), Oracle, PeopleSoft, SAP, JD Edwards[3], сформировался рынок услуг по внедрению ERP-систем с участием компаний большой четвёрки, в 2000-е годы произошла консолидация поставщиков, появилось значительное количество ERP-систем для малого и среднего бизнеса, наиболее известными поставщиками которых стали Sage Group и Microsoft[4]. Внедрение ERP-системы считается фактически необходимым условием для публичной компании и, начиная с конца 1990-х годов, ERP-системы, изначально внедрявшиеся только промышленными предприятиями, эксплуатируются большинством крупных организаций вне зависимости от страны, формы собственности, отрасли[ В качестве характеристической особенности ERP-стратегии отмечается принципиальный подход к использованию единой транзакционной системы для подавляющего большинства операций и бизнес-процессов организации, вне зависимости от функциональной и территориальной разобщённости мест их возникновения и прохождения, обязательность сведе́ния всех операций в единую базу для последующей обработки и получения в реальном времени сбалансированных планов[20]. Тиражируемость, то есть возможность применить один и тот же программный пакет для разных организаций (возможно, с разными настройками и расширениями), фигурирует как одно из обязательных условий ERP-системы[21]. Одной из причин повсеместного использования тиражируемых ERP-систем вместо разработки на заказ указывается возможность внедрения лучших практик посредством реинжиниринга бизнес-процессов согласно решениям, применённым в ERP-системе[22]. Однако, встречаются и упоминания интегрированных систем, разработанных для отдельной организации на заказ как ERP-систем[23]. Необходимость всеобъемлющего применения ERP-системы в территориально-распределённых организациях требует поддержки в единой системе множества валют и языков[24]. Более того, необходимость поддерживать несколько организационных единиц (несколько юридических лиц, несколько предприятий), несколько различных планов счетов, учётных политик, различных схем налогообложения в едином экземпляре системы оказывается необходимым условием для применения в холдингах, транснациональных корпорациях. Применимость в различных отраслях накладывает на ERP-системы, с одной стороны, требования к универсальности, с другой стороны — поддержку расширяемости отраслевой спецификой. Основные крупные системы включают готовые специализированные модули и расширения для различных отраслей (известны специализированные решения в рамках ERP-систем для машиностроительных и обрабатывающих производств, предприятий добывающей промышленности, розничной торговли, дистрибуции, банков, финансовых организаций и страховых компаний, предприятий электросвязи, энергетики, организаций сектора государственного управления, сферы образования, медицины и других отраслей).
|
|||||||||
Последнее изменение этой страницы: 2017-01-19; просмотров: 166; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.227.161.132 (0.025 с.) |