Проектирование информационных систем (ИС) CASE средствами. Case-технологии проектирования информационных систем
Обзор некоторых CASE-систем.
Список производителей CASE - инструментов и ряд полезных ссылок можно найти по адресу http://sunny.aha.ru/~belikov/index.htm, вопросам использования CASE посвящена русскоязычная конференция news://fido7.su.dbms.case/, в Internet также доступна книга Вендрова А.М. CASE-технологии. Современные методы и средства проектирования информационных систем..
Power Designer компании Sybase.
В состав Power Designer входят следующие модули:
· Process Analyst - средство для функционального моделирования, поддерживает нотацию Йордона - ДеМарко, Гейна - Сарсона и несколько других. Имеется возможность описать элементы данных (имена, типы, форматы), связанные с потоками данных и хранилищами данных. Эт элементы передаются на следующий этап проектирования, причем хранилища данных могут быть автоматически преобразованыв сущности.
· Data Analyst - инструмент для построения модели "сущность-связь" и автоматической генерации на ее основе реляционной структуры. Исходные данные для модели "сущность-связь" могут быть получены из DFD-моделей, созданных в модуле Process Analyst. В ER-диаграммах допускаются только бинарные связи, задание атрибутов у связей не поддерживается. Поддерживаются диалекты языка SQL примерно для 30 реляционных СУБД, при этом могут быть сгенерированы таблицы, представления, индексы, триггеры и т.д. В результате порождается SQL-сценарий (последовательность команд CREATE), выполнение которого создает спроектированную схему базы данных. Имеется также возможность установить соединение с СУБД через интерфейс ODBC. Другие возможности: автоматическая проверка правильности модели, расчет размера базы данных, реинжиниринг (построение модельных диаграмм для уже существующих баз данных) и т.д.
· Application Modeler - инструмент для автоматической генерации прототипов программ обработки данных на основе реляционных моделей, построенных в Data Analyst. Может быть получен код для Visual Basic, Delphi, а также для таких систем разработки в архитектуре "клиент-сервер" как PowerBuilder, Uniface, Progress и др. Генерация кода осуществляется на основе шаблонов, соответственно управлять генерацией можно за счет изменения соответствующего шаблона.
Ознакомительную версию Power Designer, в которой заблокированы функции сохранения построенных моделей, можно получить с российского web-сервера комании Sybase.
Silverrun компании Silverrun Technologies Ltd.
CASE-система Silverrun состоит из следующих инструментов:
· BPM - построение DFD-диаграмм. Поддерживает нотации Йордона-ДеМарко, Гейна - Сарсона, Уорда-Меллора и многие другие. Данный инструмент позволяет автоматически проверить целостность построенной модели, причем список критериев проверки определяется пользователем (например: отсутствие имен у элементов модели, потоки данных типа "хранилище - хранилище" или "внешняя сущность - внешняя сущность" и т.д.)
· ERX - построение диаграмм "сущность-связь". Поддерживаются не только бинарные связи, но и связи более высоких порядков, имеется возможность определения атрибутов у связей. Построенные ER-модели с помощью внешней утилиты могут быть сконвертированы в реляционный структуры (в той версии, с которой я работал, при этом, к сожалению, терялись атрибуты связей).
· RDM - инструмент реляционного моделирования, позволяет генерировать SQL-скрипты для создания таблиц и индексов примерно для 25 целевых СУБД.
Следует отметить, что компания Silverrun Technologies Ltd является не только разработчиком CASE - инструментария, но также создала собственную методологию создания информационных систем, получившую название Datarun. Эта методология включает описание всех этапов жизненного цикла информационной системы, перечень и последовательность работ, требования к содержанию и оформлению документов и многое другое.
Ознакомительную версию Silverrun, можно скачать с сервера комании Argussoft. В этой версии имеются ограничения на количество элементов в создаваемых моделях.
BPWin и ERWin компании LogicWorks.
LogickWorks выпускает два взаимнодополняющих инструмента проектирования информационных систем:
· BPWin - функциональное моделирование на основе методологии IDEF0. Допускается также использовние нотации IDEF3 и DFD в нотации Йордона - ДеМарко. Имеется возможность экспорта построенных моделей в системы функционально-стоимостного анализа (ABC - Activity Based Costing) и информационного моделирования ERWin.
· ERWin - средство информационного моделирования, используется нотация IDEF1X. Поддерживаются свыше 20 целевых СУБД, имеется возможность генерации прототипов прикладных программ для Visual Basic, Delphi и т.д.
Использование SilverRun
Методология
Планирование и разработка комплексных информационных систем невозможны без тщательно обдуманного методологического подхода. Какие этапы необходимо пройти, какие методы и модели использовать, как организовать контроль за продвижением проекта и качеством выполнения работ - эти вопросы решаются методологиями программной инженерии. Методологий существует много, и главное в них - единая дисциплина работы на всех этапах жизненного цикла системы. Если учитываются все критические задачи и контролируется их решение, качество создаваемых систем значительно возрастает. При этом, в общем случае, не важно, какие конкретно методы были выбраны для решения этих задач.
Для различных классов систем используются свои методы разработки. Они определяются как типом создаваемой системы, так и средствами реализации. Вероятно, самыми распространенными по объемам разработок являются информационные системы бизнес-класса. Практически в каждой организации имеются специалисты, разрабатывающие или сопровождающие информационные системы. Спецификация этих систем в большинстве случаев состоит из двух основных компонентов: функционального и информационного. По способу сочетания этих компонентов подходы к представлению информационных систем можно разбить на два основных типа - структурный и объектно-ориентированный. Разумеется, объектно-ориентированные методы также являются структурными в прямом понимании этого слова. Но исторически в программной инженерии этот термин закрепился за рядом дисциплин: структурное программирование, структурный дизайн, структурный анализ. В структурных технологиях функциональная и информационная модели строятся отдельно, чаще всего в виде диаграмм потоков данных и диаграмм "сущность-связь". Объектно-ориентированные технологии рассматривают информацию неотъемлемо от процедур ее обработки. Модели объектно-ориентированных технологий описывают структуру, поведение и реализацию систем в терминах классов объектов.
Объектно-ориентированные технологии доминируют в области создания операционных систем, средств разработки и исполнения приложений, систем реального времени. Концепция объекта помогает бороться с быстро растущей сложностью систем. Кроме того, взаимодействующие электронные устройства, как и элементы программ, естественно представляются объектами.
В области создания бизнес-систем лидируют структурные технологии, так как они максимально приспособлены для взаимодействия с заказчиками и пользователями, не являющимися специалистами в области информационных технологий. А анализ опыта разработок информационных систем показал, что активное привлечение пользователей на этапах выявления требований и постановки задачи является критическим фактором успеха крупных проектов. При разработке систем бизнес-класса основные усилия затрачиваются именно на понимание и спецификацию требований пользователя, а для реализации используются покупные средства разработки приложений (чаще всего языки четвертого поколения) и системы управления базами данных (чаще всего реляционные).
В терминах вышесказанного, место системы SILVERRUN в технологиях программной инженерии можно определить следующим образом: это CASE-система верхнего уровня, предназначенная для инструментальной поддержки структурных методологий создания информационных систем бизнес-класса. Таким образом, эта система может быть использована специалистами, занимающимися анализом и моделированием деятельности предприятий, разработчиками информационных систем, администраторами баз данных.
Методология RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
· небольшую команду программистов (от 2 до 10 человек);
· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
· повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны также уметь трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
· фаза анализа и планирования требований;
· фаза проектирования;
· фаза построения;
· фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС.
На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.
После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:
· общая информационная модель системы;
· функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
· точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
· построенные прототипы экранов, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.
В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация.
На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:
· определяется необходимость распределения данных;
· производится анализ использования данных;
· производится физическое проектирование базы данных;
· определяются требования к аппаратным ресурсам;
· определяются способы увеличения производительности;
· завершается разработка документации проекта.
Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям.
На фазе внедрения производится обучение пользователей, организационные изменения и параллельно с внедрением новой системы осуществляется работа с существующей системой (до полного внедрения новой). Так как фаза построения достаточно непродолжительна, планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.
Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.
Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.
Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается.
Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом:
В качестве итога перечислим основные принципы методологии RAD:
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов жизненного цикла;
· обязательное вовлечение пользователей в процесс разработки ИС;
· необходимое применение CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимое использование генераторов кода;
· использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
· грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Структурный подход
Сущность структурного подхода к разработке ИС заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы "снизу-вверх" от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов. В качестве двух базовых принципов используются следующие:
· принцип "разделяй и властвуй" - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
· принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:
· принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;
· принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
· принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
· принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
· DFD (Data Flow Diagrams) диаграммы потоков данных;
· ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".
На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Лекция 8. Case средства разработки информационных систем
Для автоматизации процессов проектирования и разработки информационных систем в 70–80-е года широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой системы и принимаемых технических решений. При этом использовались графические средства описания различных моделей информационных систем с помощью схем и диаграмм. Это явилось одной из причин появления программно-технологических средств, получивших название CASE-средств и реализующих их CASE-технологий создания и сопровождения информационных систем.
Термин CASE (Computer Aided Software/System Engineering) используется в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. В настоящее время этот термин получил более широкий смысл, означающий автоматизацию разработки информационных систем .
CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения информационных систем, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом.
CASE-систему можно определить как набор CASE-средств, имеющих определенное функциональное предназначение и выполненных в рамках единого программного продукта.
CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимосвязанных средств автоматизации.
CASE-индустрия объединяет сотни фирм и компаний различной направленности деятельности. Практически все серьезные зарубежные программные проекты осуществляются с использованием CASE-средств, а общее число распространяемых пакетов превышает 500 наименований.
Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (от англ. engineering – разработка).
Современные CASE-средства поддерживают разнообразные технологии проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, охватывающих весь жизненный цикл программного обеспечения.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом важную роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
САSЕ-средства составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Характерные особенности CASE-средств:
- Единый графический язык . CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными схемами (более простыми в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая простоту сопровождения и внесения изменений в систему.
- Единая база данных проекта . Основа CASE-технологии – использование базы данных проекта (репозитария) для хранения всей информации о проекте, которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитария включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила применения или обработки этих компонентов. Репозитарий может хранить объекты различных типов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных и логики их обработки, а также модели данных, организации и обработки, исходные коды, элементы данных и т.п.
- интеграция средств . На основе репозитария осуществляются интеграция СASE-средств и разделение системной информации между разработчиками. При этом возможности репозитария обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами.
- Поддержка коллективной разработки и управления проектом . CASE-технология поддерживает групповую разработку проекта, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, то есть функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитария. В частности, через репозитарий могут осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и т.п.
- Макетирование . CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она его устраивает и насколько она приемлема для будущих пользователей.
- Генерация документации . Вся документация по проекту генерируется автоматически на базе репозитария (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарий (известно, что при традиционных подходах к разработке программного обеспечения документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения).
- Верификация проекта . CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом.
- Автоматическая генерация программного кода . Генерация программного кода осуществляется на основе репозитария и позволяет автоматически построить до 85–90% текстов на языках высокого уровня.
- Сопровождение и реинжиниринг . Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов, автоматически изменять спецификации при редактировании кодов и т.п.
Разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может выступать специально для этого разработанный прототип, либо устаревшая система. В последнем случае для восстановления знаний о программной системе с целью последующего их использования применяют повторную разработку – реинжиниринг.
Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель, можно ее усовершенствовать, а затем вновь перейти к разработке. Одним из наиболее известных принципов такого типа является принцип возвратного проектирования (Round Trip Engineering (RTE)).
Современные CASE-системы обеспечивают и первичную, и повторную разработку, что существенно ускоряет разработку приложений и повышает их качество.
В настоящее время среди прочих требований к CASE-средствам предъявляются следующие:
Наличие возможностей определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);
Поддержка процесса проектирования с помощью библиотек, оснащенных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);
Наличие средств для создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т.п.);
Наличие возможностей для создания различных распределенных клиент-серверных приложений.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Автоматизированное проектирование ИС (CASE-технология)
Определение . CASE-технология (Computer Aided Software Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации.
Основные черты CASE-технологии
Назначение : автоматизация проектирования сложных информационных систем.
Изначально CASE-средства были ориентированы на разработку ПО. Сейчас чаще всего под такими средствами подразумевают любые средства проектирования ИС и/или моделирования предметной области.
CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение).
Не создают новых методологий, а повышают эффективность использования существующих - за счет автоматизации.
Цели использования CASE-технологии в индустриальном проектировании ИС
Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов;
Возможность повторного использования компонентов разработки;
Повышение уровня адаптивности и качества сопровождения ИС;
Использование методологии прототипного проектирования;
Ускорение работы за счет автоматизированной генерации кода и автоматизированного документирования проекта;
Возможность коллективной разработки ИС в режиме реального времени.
Методология - определяет шаги реализации проекта, а также правила используемых при его разработки методов.
Метод - процедура или техника генерации описания компонентов ИС (например, метод проектирования потоков данных).
Модель - совокупность символов (вербальных, математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
Нотация - Система условных обозначений, принятая в конкретной модели. Обычно для описания моделей используются графические символы (почему? ), а также формальные и естественные языки.
Инструментальные средства - CASE-средства
Определение . CASE-средство - это специальный программный продукт, который поддерживает одну или несколько методологий анализа и проектирования ИС.
Общая архитектура системы CASE-средств включает в себя следующие элементы:
Репозиторий (словарь данных) - специализированная база данных, являющаяся ядром системы. Обеспечивает хранение версий проекта и его отдельных компонентов и объектов, синхронизацию поступающей от проектировщиков информации, контроль метаданных на полноту и непротиворечивость. Репозиторий хранит описания следующих объектов:
Проектировщиков и их прав доступа к различным компонентам системы;
Организационных структур;
Диаграмм, компонентов диаграмм и связей между диаграммами;
Структур данных;
Программных модулей, процедур, библиотек и т.п.
Графические средства анализа и проектирования (редакторы диаграмм). Используются для создания иерархически связанных диаграмм - моделей ИС - в заданной графической нотации.
Верификатор диаграмм . Служит для контроля правильности построения диаграмм в заданной методологии проектирования. Основные функции: мониторинга, диагностика, информирование об ошибках.
Неграфические средства проектирования и разработки приложений . Используются для построения моделей ИС на формальных и естественных языках, а также для автоматизированной разработки программ проекта.
Документатор проекта . Позволяет получать информацию о проекте в виде различных отчетов.
Средства администрирования проектом . Представляют собой набор инструментов и служебных программ, необходимых для выполнения таких административных функций, как:
Инициализация проекта;
Задание начальных параметров проекта;
Назначение и управление правами доступа к отдельным элементам проекта;
Мониторинг выполнения проекта.
Служебные средства . Представляют собой набор служебных программ, которые необходимы для обслуживания БД репозитория: архивация, восстановление данных и т.п.
Классификация CASE-средств
По области действия в пределах ЖЦ ИС
Upper CASE - средства, используемые на стадии анализа предметной области;
Middle CASE - средства, используемые на стадии анализа и проектирования структуры ИС;
Примечание. В настоящее время в зарубежной литературе имеет место тенденция объединять средства Upper и Middle CASE в одну группу (Upper CASE).
Lower CASE - средства, используемые на стадиях разработки и внедрения (тестирования).
I-CASE - интегрированная система CASE-средств, которая может использоваться как на ранних, так и на поздних стадиях ЖЦ ИС (т.е. объединяет возможности Upper- и Lower- CASE).
По функциональному назначению:
Средства анализа и проектирования ИС (автоматизация наиболее популярных методологий проектирования);
Средства проектирования баз данных (моделирование данных и генерация схем БД);
Средства разработки приложений (в том числе, средства генерации и рефакторинга программного кода, средства быстрой разработки приложений);
Средства обратного инжиниринга (построение моделей действующей ИС для ее переноса в другую среду);
Средства документирования проекта;
Средства управления тестированием ПО;
Средства планирования и управления проектом.
По поддерживаемым методологиям проектирования:
Функционально-ориентированные;
Объектно-ориентированные;
Комплексные (поддерживают различные методологии).
По степени интеграции:
Отдельные средства, которые могут быть использованы на той или иной стадии проектирования ИС.
Частично интегрированные наборы средств, охватывающие несколько стадий разработки ИС;
Полностью интегрированные системы средств, охватывающие несколько стадий разработки ИС и связанные между собой общим репозиторием.
По реализованной архитектуре:
Локальные;
Корпоративные (с поддержкой взаимодействия по корпоративным информационным сетям и возможностью коллективной разработки проекта).
Методологии проектирования ИС с использованием CASE-средств
В настоящее время существует два основных подхода к проектированию, которые мы уже упоминали:
Функционально-ориентированный (структурный);
Объектно-ориентированный.
В основе функционально-ориентированного подхода лежат две идеи:
Декомпозиция;
Графическое представление.
В настоящее время в качестве основных средств структурного анализа и проектирования используют следующие виды диаграмм:
Business Function Diagram (BFD) - диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD - это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функциональных спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.
Диаграммы SADT (диаграммы работ и объектов).
Диаграммы потоков данных (DFD).
State Transition Diagram (STD) - диаграммы переходов состояний. Моделируют поведение системы во времени в зависимости от произошедших событий. Позволяют осуществить декомпозицию управляющих процессов, происходящих в системе и описать отношение между управляющими потоками. С формальной точки зрения, диаграммы переходов состояний описывают некоторый конечный автомат. К основным элементам диаграммы перехода состояний относятся:
Состояние - устойчивое значение некоторого свойства в течение определенного времени. В каждый момент времени система находится строго в одном состоянии. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в следующее состояние.
Начальное состояние - узел диаграммы, являющийся стартовой точкой для начального системного перехода. В диаграмме может быть множество конечных состояний, но только одно начальное.
Переход - определяет перемещение моделируемой системы из одного состояния в другое. Имя перехода определяется событием, которое вызвало этот переход. Переход может быть вызван каким-либо действием.
Триггер - логическое выражение, написанное на каком-либо макроязыке, которое показывает условие перехода в данное состояние.
Применяется два способа построения ST-диаграммы. Первый способ заключа-ется в идентификации всех возможных состояний и дальнейшем исследо-вании всех не бессмысленных связей (переходов) между ними. По второ-му способу сначала строится начальное состояние, затем следующие за ним и т.д. В результате формируется предварительная диаграмма перехода состояний, для которой необходимо выполнить контроль состоятельности. Обычно он заключается в отве-те на следующие вопросы;
все ли состояния определены и имеют уникальное имя?
все ли состояния достижимы?
все ли состояния имеют выход?
реагирует ли система соответствующим об-разом на все возможные условия (особенно на ненормальные)?
все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы?
Примеры диаграммы переходов состояний
Диаграммы состояний UML.
Диаграммы инфологических моделей «сущность-связь».
System Structure Diagram (SSD) - Диаграммы структуры программного приложения ИС. Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы.
Основные черты объектно-ориентированного проектирования
Предметная область моделируется как совокупность взаимодействующих во времени объектов;
Процесс обработки информации представляется как последовательность взаимодействий этих объектов;
Данные и операции моделируются совместно (неразрывно друг от друга);
За основу принимается спиральная модель проектирования. Модели предметной области накапливаются в репозитории и постепенно уточняются.
На основе сформированных моделей может быть автоматически сгенерирована система классов для программного приложения ИС;
Для моделирования широко используется унифицированный язык моделирования UML (Unified Modeling Language).
Самостоятельно:
Изучить, какие основные диаграммы включает в себя система объектно-ориентированных моделей в соответствии с нотациями UML;
Изучить общую характеристику и назначение каждой диаграммы;
Обратить внимание на диаграмму прецедентов, диаграмму состояний, диаграмму деятельности, диаграмму компонентов и диаграмму размещения.
Рассмотреть общую схему проектирования экономических ИС в рамках объектно-ориентированного подхода.
case проектирование информационный система
Размещено на http://www.allbest.ru/
Рис.1 . Пример диаграммы перехода состояний.
Размещено на Allbest.ru
...Подобные документы
Анализ структуры и методологии CASE-средств. Методологии проектирования, используемые в CASE-средствах. Основные понятия о системах электронного документооборота, их создание с помощью CASE-средств. Объектно-ориентированное и структурное проектирование.
курсовая работа , добавлен 18.07.2014
Основы методологии проектирования информационных систем, понятие их жизненного цикла. Основные модели жизненного цикла. Методология функционального моделирования SADT. Состав функциональной модели. Моделирование данных, характеристика case-средств.
реферат , добавлен 28.05.2015
Классификация автоматизированных информационных систем (АИС). Проектирование АИС складского учета с использованием CASE-средства Rational Rose. Подходы к проектированию, анализ CASE-средств. Программная реализация профессионально ориентированной АИС.
курсовая работа , добавлен 06.03.2012
Системы автоматического проектирования. Сравнительный анализ средств для проектирования автоматизированных информационных систем. Экспорт SQL-кода в физическую среду и наполнение базы данных содержимым. Этапы развития и характеристика Case-средств.
курсовая работа , добавлен 14.11.2017
Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.
курсовая работа , добавлен 25.04.2012
История развития информационных технологий. Классификация, виды программного обеспечения. Методологии и технологии проектирования информационных систем. Требования к методологии и технологии. Структурный подход к проектированию информационных систем.
дипломная работа , добавлен 07.02.2009
Использование CASE-средств для поддержки процессов создания и сопровождения информационных систем. Задачи графического редактора диаграмм, документатора и администратора проекта. Основные возможности IBM Rational Professional Bundle и IBM Rational Rose.
реферат , добавлен 30.05.2012
Жизненный цикл автоматизированных информационных систем. Основы методологии проектирования автоматизированных систем на основе CASE-технологий. Фаза анализа и планирования, построения и внедрения автоматизированной системы. Каскадная и спиральная модель.
курсовая работа , добавлен 20.11.2010
Основные методологии проектирования, модели жизненного цикла локальных систем, сущность структурного подхода. Моделирование потоков процессов и программные средства поддержки их жизненного цикла. Характеристика и технология внедрения CASE средств.
курсовая работа , добавлен 13.12.2010
Особенности основных, вспомогательных и организационных процессов жизненного цикла автоматизированных информационных систем. Основные методологии проектирования АИС на основе CASE-технологий. Определение модели жизненного цикла программного продукта.
CASE-средства проектирования информационных систем
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.
^CASE-технологии проектирования информационных систем
За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering) - в дословном переводе - разработка программного обеспечения информационных систем при поддержке (с помощью) компьютера. В настоящее время не существует общепринятого определения CASE, термин CASE используется в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обес-печения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных автоматизированных информационных систем в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (ПО) (приложений) и баз данных, генерацию кода, тести-рование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.
CASE-средства позволяют не только создавать "правильные" продукты, но и обеспечить "правильный" процесс их создания. Основная цель CASE состоит в том, чтобы отделить проектирование ИС от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования ИС. При использовании CASE-технологий изменяются все этапы жизненного цикла программного обеспечения (подробнее об этом будет сказано ниже) информационной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих специ-фикации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Такие методологии обеспечивают строгое и наглядное описание про-ектируемой системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. CASE-технологии успешно применяются для построения практически всех типов ИС, однако устойчивое положение они занимают в следующих областях:
обеспечение разработки деловых и коммерческих ИС, широкое применение CASE-технологий обусловлены массовостью этой прикладной области, в которой CASE применяется не только для разработки ИС, но и для создания моделей систем, помогающих решать задачи стратегического планирования, управления финансами, определения политики фирм, обучения персонала и др. (это направление получило свое собственное на-звание - бизнес-анализ);
разработка системного и управляющих ИС. Активное применение CASE-технологий связано с большой сложностью данной проблематики и со стремлением повысить эффективность работ.
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE-средства обладают следующими основными достоинствами:
улучшают качество создаваемых ИС за счет средств автоматического контроля (прежде всего контроля проекта);
позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат;
ускоряют процесс проектирования и разработки;
освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки;
поддерживают развитие и сопровождение разработки;
поддерживают технологии повторного использования компонента разработки.
Необходимо понимать, что успешное применение CASE-средств невозможно без понимания базовой технологии, на которой эти средства основаны. Сами по себе программные CASE-средства являются средствами автоматизации процес-сов проектирования и сопровождения информационных систем. Без понимания методологии проектирования ИС невозможно применение CASE-средств.
^
Характеристика современных CASE-средств
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл (ЖЦ) ИС.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых техни-ческих решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирова-ния предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых, так или иначе, используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ИС и обладающее следующими основными характерными особенностями:
мощными графическими средствами для описания и документирования ИС, обеспечивающими удобный интерфейс с разработчиком и развивающими его твор-ческие возможности;
интеграцией отдельных компонент CASE-средств, обеспечивающей управляемость процессом разработки ИС;
использованием специальным образом организованного хранилища проектных метаданных (репозитория). Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ИС) содержит следующие компоненты:
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархичес-ки связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
средства разработки приложений, включая языки 4GL и генераторы кодов;
средства конфигурационного управления;
средства документирования;
средства тестирования;
средства управления проектом;
средства реинжиниринга.
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPWin (Logic Works));
средства анализа и проектирований (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE. Аналитик (Макро-Проджект)). Выходом таких средств являются специ-фикации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных , обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее рас-пространенных СУБД. К ним относятся ERwin (Logic Works). S-Designor (SDP) и DataBase Designer (Oracle). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений . К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (Oracle), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга , обеспечивающие анализ про-граммных кодов и схем баз данных и формирование на их основе различных моделей и проектных специфи-каций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS (Intersolv));
средства тестирования (Quality Works (Segue Software));
средства документирования (SoDA (Rational Software)).
Silverrun;
Designer/2000;
Vantage Team Builder (Westmount I-CASE);
ERwin+BPwin;
S-Designor;
CASE-Аналитик.
Охарактеризуем основные возможности CASE-средств на примере имеющей широкое распространение системы Silverrun.
CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и про-ектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Настройка на конкретную методологию обеспечивается выбором требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATARUN (основная методология, поддерживае-мая Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. Для каждого понятия, введенного в проекте, имеется возможность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необходимости.
Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из которых является самостоятельным продуктом и может приобретаться и использоваться без связи с остальными модулями.
Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (ВРМ - Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автома-тическая перенумерация, работа с деревом процессов (вклю-чая визуальное перетаскивание ветвей), отсоединение и при-соединение частей модели для коллективной разработки. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов определенные пользователем поля.
Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.
Модуль реляционного моделирования (RDM- Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в ре-ляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т. д. Гибкая изменяемая нотация и расширяемость репозитория позволяют работать по любой методологии. Возможность создавать подсхемы соответствует подходу ANSI SPARC к представлению схемы базы данных . На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представле-ния. Этот модуль обеспечивает проектирование и полное документирование реляционных баз данных.
^ Менеджер репозитория рабочей группы (WRM - Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.
Платой за высокую гибкость и разнообразие изобразительных средств построения моделей является такой недостаток Silverrun, как отсутствие жесткого взаимного контроля между компонентами различных моделей (например, возможности автоматического распространения изменений между DFD различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток может иметь существенное значение только в случае использования каскадной модели ЖЦ ИС.
Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет доку-ментировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации базы данных и прикладные системы. При использовании моста Silverrun расширяет свой внутренний репозиторий специфичными для целевой системы атрибутами. После определения значений этих атрибутов генератор приложений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом, можно полностью определить ядро базы данных с использованием всех воз-можностей конкретной СУБД: триггеров, хранимых процедур, ограничений ссылочной целостности. При создании приложения на языке 4GL данные, перенесенные из репозитория Silverrun, используются либо для автоматической генерации интерфейсных объектов, либо для быстрого их создания вручную.
Для обмена данными с другими средствами автоматиза-ции проектирования, создания специализированных проце-дур анализа и проверки проектных спецификаций, составле-ния специализированных отчетов в соответствии с различными стандартами в системе Silverrun имеются три способа выдачи проектной информации во внешние файлы:
система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в текстовый редак-тор или включить в другой отчет;
система экспорта/импорта. Для более полного контро-ля над структурой файлов в системе экспорта/импор-та имеется возможность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не толь-ко формировать, но и загружать в репозитории. Это дает возможность обмениваться данными с различны-ми системами: другими CASE-средствами, СУБД, тек-стовыми редакторами и электронными таблицами;
хранение репозитория во внешних файлах через ODBC-драйверы. Для доступа к данным репозитория из наиболее распространенных систем управления базами данных обеспечена возможность хранить всю проектную информацию непосредственно в формате этих СУБД.
в стандартной однопользовательской версии имеется механизм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спецификации;
сетевая версия Silverrun позволяет осуществлять одно-временную групповую работу с моделями, хранящи-мися в сетевом репозитории на базе СУБД Oracle, Sybase или Informix. При этом несколько разработчи-ков могут работать с одной и той же моделью, так как блокировка объектов происходит на уровне отдельных элементов модели.
Помимо системы Silverrun, укажем назначение и дру-гих популярных CASE-средств и их групп.
Vantage Team Builder представляет собой интегрирован-ный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ИС и поддержку полного ЖЦ ИС.
Uniface 6.1 – продукт фирмы Compuware (США) - представляет собой среду разработки крупномасштабных прило-жений в архитектуре "клиент-сервер".
CASE-средство Designer/2000 2.0 фирмы Oracle является интегрированным CASE-средством, обеспечивающим в со-вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ИС для систем, использующих СУБД Oracle.
Пакет CASE/4/0 (microTOOL GmbH), включающий структурные средства системного анализа, проектирования и программирования, обеспечивает поддержку всего жизненного цикла разработки (вплоть до сопровождения), на основе сете-вого репозитория, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналитиков, проектировщиков, программистов).
^
Локальные средства
Пакет ERWin (Logic Works) используется при моделировании и создании баз данных произвольной сложности на ос-нове диаграмм "сущность-связь". В настоящее время ERWin является наиболее популярным пакетом моделирований дан-ных благодаря поддержке широкого спектра СУБД самых различных классов - SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQLBase, Ingress, Rdb и др.) и "настольных" СУБД типа xBase (Clipper, dBase, FoxPro, MS Access, Paradox и др.).
BPWin - средство функционального моделирования, реализующее методологию IDEFO. Модель в BPWin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс, разбивая его на шаги и подпроцессы.
S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERWin, отличаясь внешне ис-пользуемой на диаграммах нотацией. S-Designer реализует стандартную методологию моделирования данных и генери-рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB2, Microsoft SQL Server и др.
CASE-Аналитик 1.1 (Эйтекс) является практически един-ственным в настоящее время конкурентоспособным отече-ственным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответ-ствии с описанной ранее методологией.
^
Объектно-ориентированные CASE-средства
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ИС, а также для генерации кодов на различных языках и выпуска проектной документа-ции. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (язык UML - Unified Modeling Language) является в настоящее время и, очевид-но, останется в будущем общепринятым стандартом в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
^
Средства конфигурационного управления
Цель конфигурационного управления (КУ) - обеспечить управляемость и контролируемость процессов разработки и сопровождения ИС. Для этого необходима точная и достоверная информация о состоянии ИС и его компонент в каждый момент времени, а также о всех предполагаемых и выполненных изменениях.
Для решения задач КУ применяются методы и средства, обеспечивающие идентификацию состояния компонент, учет номенклатуры всех компонент и модификаций системы в це-лом, контроль за вносимыми изменениями в компоненты, структуру системы и ее функции, а также координирован-ное управление развитием функций и улучшением характеристик системы.
Наиболее распространенным средством КУ является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.
^
Средства документирования
Для создания документации в процессе разработки АИС используются разнообразные средства формирования отчетов, а также компоненты издательских систем. Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, предоставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).
Продукт SoDA предназначен для автоматизации разработки проектной документации на всех фазах ЖЦ ИС. Он позволяет автоматически извлекать разнообразную информацию, получаемую на разных стадиях разработки проекта, и включать ее в выходные документы. При этом контролируется соответствие документации проекту, взаимосвязь документов, обеспечивается их своевременное обновление. Результи-рующая документация автоматически формируется из множества источников, число которых не ограничено.
Пакет включает в себя графический редактор для подготовки шаблонов документов. Он позволяет задавать необходимый стиль, фон, шрифт, определять расположение заголовков, резервировать места, где будет размещаться извлекаемая из разнообразных источников информация. Изменения автоматически вносятся только в те части документации, на которые они повлияли в программе. Это сокращает время подготовки документации за счет отказа от перегенерации всей документации.
SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный набор средств по редактированию и верстке выпускаемой документации.
Итоговым результатом работы системы SoDA является готовый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого до-кумента (или его части) возможен из системы SoDA.
Среда функционирования SoDA - ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.
^
Средства тестирования
Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок. Регрессионное тести-рование - это тестирование, проводимое после усовершен-ствования функций программы или внесения в нее изменений.
Одно из наиболее развитых средств тестирования QA (новое название – Quality Works) представляет собой интег-рированную, многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя.
QA позволяет начинать тестирование на любой фазе ЖЦ, планировать и управлять процессом тестирования, отображать изменения в приложении и повторно использовать тесты для более чем 25 различных платформ.
В заключение приведем пример комплекса CASE-средств, обеспечивающего поддержку полного ЖЦ ИС. Нецелесообразно сравнивать отдельно взятые CASE-средства, поскольку ни одно из них не решает в целом все проблемы создания и сопровождения ИС. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ИС. Сравниваться могут комплексы методоло-гически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ИС и обеспеченные необходимой технической и методической поддержкой со стороны фирм-поставщиков (отметим, что рациональное комплексирование инструментальных средств разработки ИС является важнейшим условием обеспечения качества этой ИС, причем это замечание справедливо для всех предметных областей).
Лекция №8
Многоуровневая архитектура 9
Интернет/интранет-технологии 10
Требования, предъявляемые к информационным системам 10
Гибкость 11
Надежность 11
Эффективность 11
Безопасность 12
Жизненный цикл информационных систем 16
Общие сведения об управлении проектами 17
^ Классификация проектов 18
Основные фазы проектирования информационной системы 18
Концептуальная фаза 19
Подготовка технического предложения 19
Проектирование 19
Разработка 20
Ввод системы в эксплуатацию 20
Процессы, протекающие на протяжении жизненного цикла информационной системы 21
^ Основные процессы жизненного цикла 21
Разработка 21
Эксплуатация 21
Сопровождение 22
Вспомогательные процессы жизненного цикла 23
Организационные процессы 23
Структура жизненного цикла информационной системы 23
Начальная стадия 24
Стадия уточнения 24
^ Стадия конструирования 24
Стадия передачи в эксплуатацию 24
Жизненный цикл информационных систем 28
Модели жизненного цикла информационной системы 28
^ Каскадная модель жизненного цикла информационной системы 29
Основные этапы разработки по каскадной модели 29
Основные достоинства каскадной модели 29
Недостатки каскадной модели 30
^ Спиральная модель жизненного цикла 31
Итерации 31
Преимущества спиральной модели 32
Недостатки спиральной модели 33
Методология и технология разработки информационных систем 37
Методология RAD 40
Основные особенности методологии RAD 40
^ Объектно-ориентированный подход 41
Визуальное программирование 42
Событийное программирование 43
Фазы жизненного цикла в рамках методологии RAD 44
Фаза анализа и планирования требований 44
Фаза проектирования 44
Фаза построения 45
Фаза внедрения 46
^ Ограничения методологии RAD 46
Методология и технология разработки информационных систем 51
Профили открытых информационных систем 51
Понятие профиля информационной системы 52
Принципы формирования профиля информационной системы 53
^ Структура профилей информационных систем 55
Профиль прикладного программного обеспечения 57
Профиль среды информационной системы 57
Профиль защиты информации 58
Профиль инструментальных средств 58
^ Методология и технология разработки информационных систем 63
Стандарты и методики 63
Виды стандартов 64
Методика CDM фирмы Oracle 65
Общая структура 66
Особенности методики СDМ 68
^ Международный стандарт ISO/IEC 12207: 1995-08-01 69
Общая структура 69
Основные и вспомогательные процессы ЖЦ 69
Особенности стандарта ISO 12207 71
CASE-технологии проектирования информационных систем 77
Характеристика современных CASE-средств 80
^ Локальные средства 86
Объектно-ориентированные CASE-средства 87
Средства конфигурационного управления 87
Средства документирования 87
Средства тестирования 88
Принципы построения и этапы проектирования баз данных 93
Основные понятия и определения 93
Описательная модель предметной области 99
^ Принципы построения и этапы проектирования баз данных 111
Концептуальные модели данных 111
Типы структур данных 112
Операции над данными 113
^ Ограничения целостности 114
Иерархическая модель данных 115
Сетевая модель данных 117
Реляционная модель данных 118
Бинарная модель данных 119
Семантическая сеть 119
Технология моделирования информационных систем 124
Методы моделирования систем 124
^ Математическая модель системы 126
Классификация математических моделей 128
Имитационные модели информационных систем 136
Методологические основы применения метода имитационного моделирования 136
^ Имитационные модели информационных систем 146
Классификация имитационных моделей 146
Структура типовой имитационной модели с календарем событий 153
^ Имитационные модели информационных систем 161
Технология моделирования случайных факторов 161
Генерация псевдослучайных чисел (ПСЧ) 161
Мультипликативный метод 163
Аддитивный метод 164
Смешанный метод 164
^ Моделирование случайных событий 165
Последовательное моделирование 167
Моделирование после предварительных расчетов 167
Имитационные модели информационных систем 172
Технология моделирования случайных факторов 172
^ Моделирование случайных величин 172
Моделирование непрерывных случайных величин 173
Метод обратной функции 173
Метод исключения (Неймана) 174
Метод композиции 176
Моделирование дискретных случайных величин 177
Метод последовательных сравнений 177
Метод интерпретации 178
^ Моделирование случайных векторов 178
Метод условных распределений 179
Метод исключения (Неймана) 180
Метод линейных преобразований 181
Имитационные модели информационных систем 187
Основы организации имитационного моделирования 187
^ Этапы имитационного моделирования 187
Испытание имитационной модели 188
Задание исходной информации 189
Верификация имитационной модели 189
Проверка адекватности модели 189
Калибровка имитационной модели 190
Исследование свойств имитационной модели 190
Оценка погрешности имитации, связанной с использованием в модели генераторов псевдослучайных чисел (ПСЧ) 190
Определение длительности переходного режима 191
Оценка устойчивости результатов имитации 192
Исследование чувствительности модели 192
^
Языки моделирования 193