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

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

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

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

· Виды блюд.

· Персонал.

· Должности.

· Постоянные клиенты.

· Заказы.

Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:

Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;

Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;

Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;

Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;

Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».

Рис. 2. Концептуальная модель данных

2.3 Разработка логической модели информационной системы

Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.

Схема 1 - Многоуровневое представление данных БД под

управлением СУБД

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

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

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

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

Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.

Схема 2 - Этапы процесса проектирования базы данных

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

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

При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.

Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:

Фамилия Оклад

В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.

При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию.

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

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

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

Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

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

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

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

Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита.

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

Рисунок 1 - Графическое изображение функциональной зависимости реквизитов

В случае составного ключа вводится понятие функционально полной зависимости.

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

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

Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.

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

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

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

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

Целью работы является создание базы данных, обеспечивающей:

быстрый ввод новых данных;

хранения и поиск уже введённых данных;

печать необходимого количества персональных отчётов.

Данными являются:

Фамилия, имя, отчество;

Дата рождения;

Занимаемая должность;

Должностной оклад;

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

Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.

Для этого будем пользоваться средствами Database Desktop

В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:

Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.

Для автоматизации процессов проектирования и разработки информационных систем в 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 и т.п.);

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

12 и 13 октября прошел форум РИФ-Воронеж 2018. За два дня на мероприятии зарегистрировалось 4600 человек. Еще 3700 человек посмотрели онлайн-трансляцию. Перед аудиторией выступили более ста спикеров, актуальные темы сферы информационных технологий обсудили в формате презентаций и дискуссий. В первый день форума подвели итоги региональной интернет-премии. А завершилась деловая программа финалом первого студенческого IT-чемпионата по решению кейсов в области digital-технологий, проектирования и онлайн-коммуникации в Центральном Черноземье. Победителем стала команда ВГТУ. Чемпионат организован совместно с проектом Стажировка.ру.

В отборочном туре чемпионата IT-Generation приняли участие 30 команд из Воронежа, Курска, Липецка, Орла, Брянска, Санкт-Петербурга, Москвы, Самары, Алматы. Самый младший участник чемпионата - ученик 8 класса школы (он вошел в состав студенческой команды). В финале свои работы защищали 10 команд. Ребята решали реальные задачи, с которыми программисты сталкиваются в своей работе.

Для каждого кейса компании определили лучшее решение:

· Кейс компании DSR (разработка корпоративного мобильного приложения) - команда ВГТУ (Воронеж)

· Кейс компании Atos (доработка корпоративной информационной системы) - команда БГИТУ (Брянск)

· Кейс компании Dr.Web (поиск скрытого майнера в корпоративной сети) - команда ВГУ (Воронеж)

Также же эксперты выбрали победителя всего чемпионата, им стала команда ВГТУ! Победителей пригласили на стажировку в компании.

Итоги форума

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

Новое развитие получила на форуме тема digital-коммуникаций, доклады спикеров о тенденциях, контенте и продвижении в соцстеях, видеомаркетинге, личном брендинге прошли при полных залах. Максимально широко была представлена тема web-дизайна. Впервые в Воронеже прошла мини-конференция с участием спикеров Baltic Digital Days, эксперты говорили о поисковом продвижении сайтов и управлении репутацией в сети интернет.

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

В формате круглого стола обсудили вопросы регулирования интернета, развития цифровой экономики, digital-трансформации города.

Экспертами РИФ-Воронеж в 2018 году стали представители топовых IT-компаний: Mozilla Foundation, ВКонтакте, Яндекс, Mail.Ru Group, Rambler&Co, T-Systems, Ingate, Seopult, «НЛМК-Информационные технологии», «Северсталь-инфоком» и других.

Как всегда, все мероприятия ежегодного форума были бесплатными. Организаторы форума: Агентство инноваций и развития экономических и социальных проектов, Департамент экономического развития Воронежской области, Рекомендательный проект «LikenGo!», при поддержке Российской ассоциации электронных коммуникаций. Генеральным партнером форума стала авиакомпания Turkish Airlines.

О форуме:

Региональный интернет-форум (РИФ) проходит в Воронеже с 2009 года. В 2013 году мероприятие получило поддержку областного казенного учреждения «Агентство инноваций и развития экономических и социальных проектов» и департамента экономического развития Воронежской области, подтвердив статус значимого для региона события. В рамках «РИФ-Воронеж» также проходит интернет-премия, основные задачи которой - содействие развитию интернет-технологий на территории региона и демонстрация ярких проектов рынка.

Организаторы РИФ в 2018 году:

Областное казенное учреждение «Агентство инноваций и развития экономических и социальных проектов» www.innoros.ru

Департамент экономического развития Воронежской области www.econom.govvrn.ru

При поддержке:

Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, www.minsvyaz.ru
Российской ассоциации электронных коммуникаций,

Гайфуллов Руслан, студент 2 курса, специальность прикладная информатика ФГБОУ ВПО Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «МГТУ имени Носова»

Аннотация

В данной статье дается определение базы данных. Дальше рассматриваются типы данных в базах данных, и их использование при проектировании баз данных. Потом дается определение Case технологий. А в конце, рассказывается о Case технологиях в проектирования баз данных

CASE technologies in database design

Gayfullov Ruslan, 2nd year student, specialty Applied Informatics, FSBEI HPE “MSTU of a name Nosov”

Аnnotation

In this article provides a definition database. Further describes the types of data in databases and their use in database design. Then provides a definition database. And in the end, tells about case technologies in database design.

ЧТО ТАКОЕ БАЗЫ ДАННЫХ

Базы данных (БД) – множество связанных друг с другом данных, которые организуются со схемой БД для удобной работы с ними пользователя.

Определение из Википедии: Базы данных – множество документов в объективной форме, систематизированных для поиска и обработки с помощью ЭВМ (это электронная вычислительная машина).

База данных – множество данных, хранящихся согласно схеме данных, манипуляция с которыми происходит по правилам средств манипулирования данных.

База данных – сведения, хранящиеся неким упорядоченным способом.

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

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

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

Основные задачи:

Хранение в БД всей нужной информации.

Возможность получить данные по всем нужным запросам.

Уменьшение избыточности и дублирования данных.

Обеспечение целостности и дублирования данных

ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

Проектирование БД осуществляется в 3 этапа: концептуальное (инфологическое), логическое (даталогическое), физическое.

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

Концептуальное (инфологическое) проектирование – создание семантической модели предметной области (информационная модель самого высокого уровня абстракции). Эта модель создаётся без ориентации на СУБД и модель данных. Концептуальная модель БД состоит из описания информационных объектов (понятий предметной области) со связями меж ними и описания ограничений целостности, то есть требований к допускаемым значением данных связей меж ними.

Логическое проектирование – перенесение проекта на внутреннюю модель СУБД (это система управления БД).

Логическое (даталогическое) проектирование – это создание схемы БД с помощью реляционной модели данных.

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

Физическое проектирование – это создание схемы БД для конкретно для нужной системы управления БД (например, Access).

Есть еще один вариант этапов проектирования БД:

1 этап: постановка задачи

2 этап: Анализ предметной области.

3 этап: Создание модели.

4 этап: Выбор способов представления информации и программного инструментария.

5 этап: Создание компьютерной модели объекта.

6 этап: Работа с созданной базой данных.

ЧТО ТАКОЕ CASE ТЕХНОЛОГИИ

CASE – инструментарий системных аналитиков для проектирования и разработки. Цель CASE средств – отделить процессы проектирование от программирования. CASE технологии (Computer Aided Software Engineering) совокупность методологий анализа, проектирования, разработки, сопровождения сложных систем программного обеспечения(ПО), поддержанные комплексом взаимоувязанных средств автоматизации. CASE – инструменты и методы программной инженерии для проектирования ПО, обеспечивающее создание высококачественных программ, отсутствие ошибок, а также простоту обслуживания программных продуктов. Также CASE является множеством методов и средств проектирования информационных средств при помощи CASE инструментов.

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

Средства автоматизации разработки программ – это инструменты для автоматизации процессов проектирования и разработки ПО для системного аналитика, а также разработчика программного обеспечения и программиста. Изначально, Case средствами считали только инструменты, с помощью которых упрощались самые трудоемкие процессы анализа и проектирования, но позже Case средствами стали считать еще и как программные средства поддержки жизненных циклов ПО.

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

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

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

SADT (Structured Analysis and Design Technique), DFD (Data Flow Diagrams), а также ERD (Entity Relationship Diagrams).

Есть три основные модели в этом подходе:

функциональные, информационные и динамические

Этот подход реализуют Bpwin, Erwin, Business Studio, IBM WebSphere business modeler и Sybase Power Designer.

В объектно-ориентированном подходе основной инструмент – это язык UML – унифицированный язык моделирования, который может визуализировать и документировать объектно-ориентированные системы, ориентированные на разработку ПО. UML имеет систему разных диаграмм для построения представления о проектируемой системе.

Этот подход реализуют Rational Rose и ARIS.

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

Case инструменты делятся на типы и категории:

Типы (здесь отражается функциональная ориентация на разные процессы жизненного цикла разработки ПО и совпадает с составом компонент крупных интегрированных Case систем):

средства анализа, созданные для создания и анализа модели предметной области(Bpwin (logical works).

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

средства проектирования БД, моделирующие данные и генерирующие схемы БД (на SQL) для систем управления базами данных. Это Erwin (Logic works) и DataBase Designer (Oracle) и Designer/2000.

средства разработки приложений (Developer/2000), Delphi).

средства реинжиниринга, анализирующие программные коды и схемы БД, а также формирование с их помощью разных моделей и проектных спецификаций. Средства анализа схем БД и формирование ERD имеют Designer/2000, Erwin. При анализе программных кодов самыми известными являются объектно-ориентированные Case средства, помогающие проводить реинжиниринг программ на языке С++ (Rational Rose).

Вспомогательные типы

средства планирования и управления проектом (Microsoft Project).

средства конфигурационного управления (PVCS (Intersolv)).

средства тестирования (Quality Works (Segue Software)).

средства документирования (SoDA (Rational Software)).

CASE ТЕХНОЛОГИИ В ПРОЕКТИРОВАНИИ БАЗ ДАННЫХ

В качестве Case технологии я рассмотрю Erwin

На всех стадиях разработки БД, Erwin показывает структуру и основные элементы создаваемой базы данных. Это инструмент разработки, в автоматическом режиме создающий таблицы, а также генерирующий тысячи строк текста хранимых процедур и триггеров для систем управления базами данных. Erwin ускоряет создание приложений для обработки данных.

С Erwin проектирование БД легче. Для этого надо создается графическую E-R модель (объект-отношение), которая удовлетворяет требованиям к данным, а также вводятся бизнес-правила, создавая логическую модель, отображающую элементы, атрибуты, отношения и группировки. Erwin может манипулировать атрибутами при помощи их буксировки, вносить изменения, а также нормализовать во время создания БД. Можно редактировать прямо на диаграммах. Это означает внесение изменений в модель, не открывая специальных диалоговых окон. При помощи отчетов, которые формируются системой, проверяется правильность созданной БД.

Erwin не только инструмент для «рисования», но и автоматизирует проектирование. Ссылочная целостность БД обеспечивается автоматическим переносом ключей. Создающиеся в Erwine модели данных могут редактироваться, просматриваться и распечатываться разными способами. А при помощи RPTwin (имеющей графический интерфейс и умеющей формировать отчеты) и средства для просмотра настраиваемыми режимами, обеспечивающими контроль отображения содержимого отчетов, можно реализовать одинаковые стандарты проектирования и отображения настроек для всех моделей.

Erwin средство для быстрого создания БД. Erwin оптимизирует модель для соответствия физическим характеристикам нужной БД. Так же Erwin самостоятельно согласует логическую и физическую схемы и преобразовывает логические конструкции (например, многие ко многим) в их реализацию на физическом уровне. Реализация и прямого и обратного инжиниринга в Erwin достигается при помощи естественной динамической связи между моделью и базой данных. При помощью этой связи Erwin самостоятельно создает таблицы, представления, индексы, правила поддержания целостности ссылок (первичных и внешних ключей), устанавливает значения по умолчанию, а также ограничения для доменов/столбцов. В Erwine целостность ссылок обеспечивают множество оптимизированных шаблонов триггеров, а также мощный макроязык, при помощи которого создаются свои триггеры и хранимые процедуры. Для точной оценки и характера роста базы данных или хранилища имеются средства расчёта объема, облегчающие эффективное распределение ресурсов системы и планирование мощности.

Количество просмотров публикации: -

1.3.1. Общие требования к методологии и технологии

Методологии, технологии и инструментальные средства проектирования (CASE-средства) составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.

Технология проектирования определяется как совокупность трех составляющих:

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

Рис. 1.4. Представление технологической операции проектирования

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

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованям:

• технология должна поддерживать полный ЖЦ ПО;
• технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
• технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
• технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;
• технология должна обеспечивать минимальное время получения работоспособной ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации отдельных подсистем. Реализация ИС в целом в короткие сроки может потребовать привлечения большого числа разработчиков, при этом эффект может оказаться ниже, чем при реализации в более короткие сроки отдельных подсистем меньшим числом разработчиков. Практика показывает, что даже при наличии полностью завершенного проекта, внедрение идет последовательно по отдельным подсистемам;
• технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
• технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);
• технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры комплексов CASE-средств - в подразделе 5.7.

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

• стандарт проектирования;
• стандарт оформления проектной документации;
• стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

Стандарт оформления проектной документации должен устанавливать:

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

Стандарт интерфейса пользователя должен устанавливать:

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