![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Технология сквозного проектирования ⇐ ПредыдущаяСтр 2 из 2
Создание информационной системы любого уровня сложности проходит несколько основных этапов: постановка задачи, подготовка технического задания, разработка информационной структуры и базы данных, создание прототипа приложения, корректировка технического задания, создание готового приложения, подготовка и разработка новых версий. Для решения задач, возникающих на каждом из этих этапов, созданы специализированные инструменты, помогающие разработчикам минимизировать временные затраты и уменьшить количество ошибок. Однако при переходе от одного этапа к другому возникает проблема преемственности и интеграции специализированных средств, используемых при разработке приложения: требования аналитиков необходимо передать разработчикам базы данных, готовую базу передать для разработки пользовательского интерфейса, по получении замечаний заказчика к прототипу приложения сделать корректировку технического задания. При этом необходимо избежать тотальной переделки всей системы. В разработанных ранее системах автоматизации эти проблемы решались лишь частично. Подходы к проектированию приложений в предлагаемых системах автоматизации проектирования и разработки приложений можно неформально разделить на два типа, условно называемых: " до и от" и " от и до". Первый подход пропагандируется разработчиками билдеров и " легких" CASE средств и предполагает, что инструментарий CASE используется только для проектирования - (" до") создания базы данных, а разработка приложения осуществляется (" от" готовой базы) с помощью билдеров, которые обладают собственными средствами реверсинжениринга модели данных, библиотеками классов и многими другими инструментами. Основным недостатком этого подхода является разорванность технологического процесса, в результате чего модель данных, используемая билдером, значительно беднее модели, разработанной аналитиком с использованием инструментов CASE либо вручную. Дополнительную информацию аналитик вынужден передавать неформальными способами (" голосом"). Кроме того, в процессе разработки приложения зачастую оказывалось, что стандартные библиотеки классов, используемые билдером, недостаточны для разработки полнофункционального приложения и каждому программисту приходилось по-своему наращивать функциональность, что приводило к " лоскутному" интерфейсу. В результате, несмотря на наличие удобного инструментария у аналитиков и программистов, его использование не приводит ни к улучшению качества системы, ни к ускорению разработки. Второй подход, реализованный в так называемых " тяжелых" CASE средствах, например, в Tau UML Suite, предполагает, что CASE поддерживает разработку " от" анализа " до" конструирования логической модели данных и логической модели приложения, на основе которых создается база данных и осуществляется автоматическая генерация программного кода. Tau UML Suite предоставляет пользователю прекрасный инструментарий для проектирования приложения: диаграммы содержания экранных форм (FCD - Form Contence Diagram), которые позволяют описать структуру и (в значительной степени) функциональность сложных экранных форм (предназначенных для работы с несколькими таблицами); диаграммы структурных схем (SCD - Structure Charts Diagram), которые позволяют описать алгоритмы программных модулей и методы работы с экранными формами (в рамках структурного подхода работа с экранными формами элегантно осуществляется с помощью так называемых " предопределенных модулей"); диаграммы последовательности экранных форм (FSD - Form Sequence Diagram), которые задают общую структуру приложения. а также связывают формы и алгоритмы (методы). Главный недостаток этого подхода состоит в том, что идеология проектирования не учитывает реальные потребности проектировщика, который должен разработать информационную систему со стандартным интерфейсом, поскольку заказчику нужна система с легкими для освоения рабочими местами. Проектировщику нужны средства построения логической модели стандартного интерфейса, а не полной модели всех элементов интерфейса. Детальное проектирование каждой экранной формы (средствами FCD или в билдере) при создании стандартного интерфейса является не только нудной, но и зачастую вредной работой, а " уникальные" рабочие места, как правило, немногочисленны, их гораздо быстрее и проще создавать на основе типового рабочего места, а не " с чистого листа". Кроме того, затраты на приобретение и освоение " тяжелого" CASE окупаются только при создании достаточно крупных систем или при " поточном" производстве, многие возможности, предоставляемые продуктами этого класса, не столь уж необходимы для создания небольшой системы разработчиками, хорошо знающими предметную область или для воспроизведения существующей системы на другой платформе. Компания DataX/FLORIN поставила перед собой задачу разработки технологии проектирования, которая бы обеспечивала автоматический перенос данных при переходе от одного этапа разработки информационной системы к другому, позволяла бы создавать современные информационный системы со стандартизированным пользовательским интерфейсом в сжатые сроки и поддерживала бы полный жизненный цикл приложения. Такая технология была разработана и получила название " технологии сквозного проектирования". Она позволяет связать воедино все этапы построения информационной системы, начиная от постановки задания и заканчивая созданием бумажной документации. Использование этой технологии позволяет отказаться от ручной работы по кодированию базы и программных интерфейсов, дает возможность вносить изменения на любом уровне реализации и в результате дает заказчику не только готовую систему, но и средства для ее дальнейшего развития и сопровождения. Для реализации технологии сквозного проектирования было создано семейство программных продуктов GRINDERY, с помощью которых преодолен технологический разрыв между CASE-средствами и средствами программирования интерфейсов. Использование программных продуктов семейства GRINDERY позволяет производить логическое проектирование приложения одновременно с разработкой логической структуры базы данных в среде Telelogic Tau UML Suite, затем осуществлять автоматическую генерацию программного кода на любом языке программирования, поддерживаемом семейством GRINDERYTM. Задание и изменение управляющих параметров кодогенерации (атрибутов), а также управление правами доступа и версиями проекта осуществляется с использованием механизмов соответствующего CASE-инструмента. Для кодогенератора GRINDERYTM разработаны шаблоны, предназначенные для создания типового интерфейса приложения. В приложении с типовым интерфейсом для каждой предметной таблицы базы данных создается рабочее место, позволяющее выполнять основные операции с данными (INSERT, UPDATE, DELETE, QBE), содержащимися в этой таблице. Рабочее место, созданное для предметной таблицы, позволяет работать не только с главной, но и с другими (" вспомогательными" для данного рабочего места) таблицами базы данных. Конкретный вид экранных форм и функциональные возможности приложения зависят от установленных значений атрибутов. С их помощью можно задать, например, способ представления конкретного поля, заголовки форм и полей, необходимость представления записей из таблиц-потомков и таблиц-партнеров, режим доступа к таблицам-словарям. Набор атрибутов для каждой таблицы и ее полей задается один раз и используется для всех форм, в которых доступны данная таблица или ее поля. Ввод и редактирование атрибутов производятся либо из графического интерфейса GRINDERY GrabberTM, либо через графический интерфейс Telelogic Tau UML Suite TM. Разработчик в любой момент может вручную внести изменения в сгенерированный кодогенератором программный код приложения. Библиографические ссылки
3. Деньдобренко Б.Н., Маника А.С., Автоматизация конструирования РЭА, М.: Высшая школа, 1980г. 4. Ключев А.О., Постников Н.П., Технология сквозного проектирования информационно-управляющих систем, Тезисы докладов ХХХ научно-технической конференции профессорско-преподавательского состава, Санкт-Питерсбургский Государственный институт точной механики и оптики, СПб: 1999г. (https://www.florin.ru/win/articles/alma_ata.html) 5. Норенков И.П., Кузьмик П., Информационная поддержка наукоемких изделий. CALS – технологии, ISBN 5-7038-1962-8, 2002г. 6. Малиньяк Л. Дальнейшее расширение функциональных возможностей САПР // Элек-троника, 1991г., том 64, № 5. 7. Ган Л. Инструментальные средства автоматизации проектирования, обеспечивающие параллельную работу над проектами // Электроника, 1990, том 38, №7, с. 58-61. 8. А. Мазурин, Тенденции развития Unigraphics в 2001 году, журнала «САПР и графика», №12, 2000г (https://www.sapr.ru/Article.asp? id=671) 9.https://www.spb.sterling.ru/unigraphics/ug/cad/index.htm 11. Nevins J.L., Whithey D.E. Concurrent Design of Products and Processes. - McGraw-Hill, New York, 1989г. 12. Р.П.Киршенбаум, А.Р.Нагаев, П.А.Пальянов, В.П.Фрайштетер, Д.В.Мариненков Информационные технологии при проектировании обустройства нефтяных и газовых месторождений, (ОАО " Ги-протюменнефтегаз", Тюмень, 1998г. 13. Ishi K., Goel A., Adler R.E., A Мodel of Simultaneous Engineering Design - Artificial Intelligence in Design / Ed. by J.S.Gero, N-Y: Springer, 1989, р483-501. 15.https://www.nastran.com 22. Е. Карташева, Интегрированные технологии SDRC, журнал Открытые системы №5, 1997г., стр. 72-77. 23. Math. Models made in CAD/CAM system Pro/Engineer, https://ws22.mech.unn.runnet.ru/CADCAM/ProEngineer/GAZ/J1.html 25.https://arkty.itsoft.ru/edu/control/cada0b.htm
|