12. Понятие и классификация case-средств. Особенности case-средства Erwin.

Для преодоления сложностей начальных этапов разработки предназначен структурный анализ - метод исследования, которое начинается с общего обзора системы и затем детализуется, приобретая иерархическую структуру со все большим числом уровней. На каждом уровне рассматривается ограниченное число элементов (обычно от 3 до 6-8), каждый из которых в свою очередь может быть декомпозирован на составляющие детали на следующем уровне. При этом соблюдаются строгие формальные правила записи информации (обычно используются диаграммы различных типов). Такая технология получила название CASE (Computer Aided Software Engeneering - создание программного обеспечения с помощью компьютера).

Как правило, CASE-системы поддерживают следующие этапы процесса разработки:

• Моделирование и анализ деятельности пользователей в рамках предметной области.

• Концептуальное моделирование.

• Реляционное моделирование.

• Генерация схемы базы данных.

• Генерация прототипов программных модулей по иерархии функций и потокам данных.

Классификация CASE-средств по типам:

• средства анализа и проектирования (BPwin, Silverrun, Oracle Designer, Rational Rose),

• средства проектирования БД (Erwin, Silverrun, Oracle Designer),

• средства управления требованиями (DOORS, ReguestePro),

• средства управления конфигурацией (PVCS, ClearCase),

• средства документирования (SoDA),

• средства тестирования (Rational Suite TestStudio),

• средства управления проектом (Open Plan Professional, Microsoft Project),

• средства реверсного инжиниринга (Erwin, Silverrun, Oracle Designer, Power Designer).

Классификация CASE-средств по категориям:

• отдельные локальные средства для решения небольших автономных задач,

• частично интегрированные средства, охватывающие большинство процессов ЖЦ ИС,

• полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные с общим репозитарием.

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

13. Базовый принцип структурного метода проектирования. Понятия технологии и методов проектирования ис. Требования, предъявляемые к современным технологиям проектирования ис.

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

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

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

Методы проектирования ЭИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

14. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе концептуального проектирования базы данных и пользовательских приложений.

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

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

1. концептуальное проектирование

2. логическое проектирование

3. физическое проектирование

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

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

• обследование предметной области, изучение ее информационной структуры;

• выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами;

• моделирование и интеграция всех представлений.

По окончании данной фазы проектирования этапа получают концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь". Элементы концептуальной модели БД – это сущности, атрибуты, связи.

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

1. определение типов сущностей;

2. определение типов связей;

3. определение атрибутов и связывание их с типами сущностей и связей;

4. определение доменов атрибутов;

5. выделение атрибутов, являющихся потенциальными и первичными ключами;

6. создание диаграмм "сущность-связь”;

7. обсуждение локальной концептуальной модели с конечным пользователем.

15. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе логического проектирования базы данных и пользовательских приложений.

Логическое проектирование – это процесс создания информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации. Предусматривает построение и проверку локальных логических моделей данных на основе представления программиста. В процессе логического проектирования выполняется преобразование требований к данным в структуры данных. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. На выходе получают СУБД-ориентированную структуру базы данных и спецификации прикладных программ.

Включает этапы:

1. преобразование локальной концептуальной модели в локальную логическую модель;

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

3. проверка модели с помощью правил нормализации;

4. проверка модели в отношении транзакции пользователя;

5. создание нормализованной диаграммы "сущность – связь”;

6. определение требований поддержки целостности данных;

7. обсуждение локальной логической модели с конечным пользователем;

Затем следует создание и проверка глобальной логической модели данных. Включает этапы:

1. слияние локальных логических моделей в единую глобальную модель;

2. проверка глобальной логической модели;

3. проверка возможности расширения проблемы в будущем;

4. создание окончательного варианта диаграммы "сущность – связь”;

5. обсуждение глобальной логической модели с конечным пользователем.

16. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе физического проектирования базы данных и пользовательских приложений.

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

Физическое проектирование включает этапы:

1. Перенос глобальной логической модели данных в среду целевой СУБД:

1) создание основных таблиц в среде СУБД;

2) реализация бизнес-правил предприятия среди СУБД.

2. Проектирование физического представления БД:

1) анализ транзакций;

2) выбор файловой структуры;

3) определение вторичных индексов;

4) контроль за избыточностью данных;

5) определение требований дисковой памяти.

3. Разработка механизмов защиты:

1) разработка пользовательских представлений;

2) определение прав доступа к данным.

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

17. Понятие сущности и типы сущностей. Способы отражения сущностей в диаграммах Чена и IDEF1Х. Признаки сущности. Понятие потенциального и первичного ключа. Роль первичного ключа для проектирования БД.

Типы сущностей – объекты или концепция, которые характеризуют­ся для данной предметной области как имеющие независимое существование

Сильный тип сущности – это тип сущности, существование которого не зави­сит от какого-то другого типа сущности. Например, ПОДРАЗДЕЛЕНИЕ, ГРУППА.

Слабый тип сущности – тип сущности, существование которого зависит от какого-то другого типа сущности. Например, СОТРУДНИК зависит от ПОДРАЗДЕЛЕНИЕ, СТУДЕНТ зависит от ГРУППА, УСПЕВАЕМОСТЬ зависит от СТУДЕНТ.

В нотации Чена и IDEF1X каждый сильный тип сущности изображается в виде прямоугольника с именем сущности внутри него, а каждый слабый тип сущности – в виде прямоугольника с двойным контуром в нотации Чена, а в нотации IDEF1X с – прямоугольником со скруглёнными краями:

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

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

18. Атрибуты и типы атрибутов. Способы отображения атрибутов в диаграммах Чена и IDEF1Х. Понятие доменов атрибутов. Требования, предъявляемые для проектирования доменов на разных этапах проектирования БД.

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

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

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

Однозначный атрибут - это атрибут, который содержит одно зна­чение для одной сущности. Номер отделения компа­нии. Многозначный атрибут - это атрибут, который содержит несколь­ко значений для одной сущности. Пример: сущность Отделение компании может иметь несколько значений для ат­рибута Номер телефона отделения компании.

Производный атрибут - это атрибут, который представляет значе­ние, производное от значения связанного с ним атрибута или некоторого множества атрибутов, принадлежащих некоторому (не обязательно данно­му) типу сущности. Например, возраст сотрудника является величиной, производ­ной от его даты рождения, и поэтому атрибуты Возраст и Дата рождения являются связанными

В нотации Чена атрибуты на диаграммах изображаются в виде эллипсов, присоеди­ненных линией к соответствующей сущности и помеченных именем атри­бута. Эллипс окружен пунктирным контуром, если атрибут является произ­водным, и двойным контуром, если атрибут является многозначным. Если атрибут является составным, его атрибуты-компоненты изоб­ражаются в виде присоединенных к нему эллипсов. Имя атрибута, который является первичным ключом данного типа сущности, подчеркивается.

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