21. Семантические модели данных

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

22. Основные понятия модели Entity-Relationship (Сущность-Связи)

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Основными понятиями ER-модели являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа.

23. . Общая характеристика и классификация CASE-средств

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

При применении этого инструментария отмечается значительный рост производительности труда, составляющий (по оценкам фирм, использующих CASE) от 100 до 600% в зависимости от объема и сложности работ и опыта использования CASE. Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проекти­рования ИС: от простых средств анализа и документирова­ния до полномасштабных средств автоматизации, покры­вающих весь жизненный цикл ПО.

24. Технология внедрения CASE-средств

Процесс внедрения CASE-средств состоит из следующих этапов :

определение потребностей в CASE-средствах;

оценка и выбор CASE-средств;

оценка и выбор CASE-средств;

выполнение пилотного проекта;

практическое внедрение CASE-средств.

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

Определение стандартных процедур использования средств.

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

25. Проектирование программных систем

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

Существует два вида проектирования: архитектурное и детализированное. Осуществляясь, в принципе, последова­тельно, эти разделы могут итеративно перемешиваться друг с другом.

Архитектурное проектирование определяется как созда­ние общей структуры системы. Другими словами, это про­ектирование в терминах модулей. В теории архитектурное проектирование определяется как многоуровневая органи­зация классов, шаблонов, прецедентов.

Детализированное проектирование определяется как кон­кретизация и реализация модулей, операций, отношений .На этой же стадии дорабатывается структура системы. Полностью определяются алгоритмы, функционирующие в каждом модуле.

26. Основные составляющие методологии создания ИС: итерационная спиральная модель ЖЦ ИС

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

Спиральная модель основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.