Шпаргалка по "Проектированию сетей"

1.Понятие об  архитектуре ИС. Виды, области применения. Одноранговые, централизованные, распределенные, терминальные системы. Архитектура клиент-сервер, терминальные системы, трехзвенные системы.

Архитектура ИС – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. Архитектура программы или компьютерной системы – это структура или структуры системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. Одноранговая сеть - все компьютеры равноправны, каждый из них выполняет как роль рабочего места пользователя, так и роль сервера по обеспечению доступа к своим данным и ресурсам. Централизованная архитектура вычислительных систем была распространена в 70-х и 80-х годах и реализовывалась на базе мейнфреймов, либо на базе мини-ЭВМ. Распределенная ИС – ИС, объекты данных и/или процессы которой физически распределяются на две или более компьютерные системы. В этом определении оговариваются два момента. Первый относится к аппаратуре: все машины автономны. Второй касается программного обеспечения: пользователи думают, что имеют дело с единой системой. Распределённые ИС  разделяют на: файл-серверные ИС; клиент-серверные ИС. Клиент-серверные ИС разделяют на двухзвенные и многозвенные. Терминальная система — организация схемы работы сетевой информационной системы, позволяющая оптимизировать финансовые затраты для построения мощной, гибкой и надежной информационной системы (ИС). Централизованная информационная система - информационная система централизованного хранения и коллективного использования данных (файл-сервер, клиент-сервер). Терминальная система — организация схемы работы сетевой информационной системы, позволяющая оптимизировать финансовые затраты для построения мощной, гибкой и надежной информационной системы, построена на основе сетевых технологий, и включает в себя сервер (чаще группу специализированных серверов) и связанные с ним (ними) рабочие станции (тонкие клиенты). Все необходимые пользовательские приложения запускаются на терминальном сервере. Тонкий клиент представляет собой упрощенный компьютер полностью реализованный на одной плате несущей на себе все необходимые компоненты. Главная задача тонкого клиента - обеспечить интерфейс пользователя с приложениями, выполняемыми на терминальном сервере. Тонкие (терминальные) клиенты не нуждаются в установке и обслуживании ПО, помогают сократить до минимума необходимость вызова на рабочее место технических специалистов, обеспечивает централизованную установку и модернизацию программ, устраняет риск воздействия зловредных программ на уровне клиентской системы, позволяет эффективно распределять ресурс сервера между всеми рабочими местами. Кроме того, тонкие клиенты имеет чрезвычайно малое энергопотребление – порядка 5 Вт, что составляет 3% от энергопотребления типового ПК. (Ресторанная система R-Keeper).

Клиент-серверная  архитектура  – характеризуется наличием двух взаимодействующих самостоятельных  процессов - клиента и сервера, которые, в общем случае, могут выполняться  на разных компьютерах, обмениваясь  данными по сети. Трёхзвенная система предполагает наличие следующих компонентов приложения: клиентское приложение (обычно говорят «тонкий клиент» или терминал), подключенное к серверу приложений, который в свою очередь подключен к серверу базы данных.

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

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

2.Системы. Основные  определения и закономерности  систем. Классификация систем по  уровню сложности. Системный подход  к построению ИС.

Существует много определений  системы.

1. Система есть комплекс элементов, находящийся во взаимодействии.

2. Система — это множество объектов вместе с отношениями этих объектов.

3. Система — множество элементов находящихся в отношениях или связях друг с другом, образующая целостность или органическое единство

- Элемент. Под элементом принято понимать простейшую неделимую часть системы.

- Подсистема - часть системы с некоторыми связями и отношениями.

- Структура - это совокупность элементов и связей между ними.

- Связь - обеспечивает возникновение и сохранение структуры и целостных свойств системы.

- Входы и выходы - материальные  или информационные потоки входящие  и выходящие из системы.

- состояние - это множество существенных свойств, которыми система обладает в данный момент времени.

- Внешняя среда - множество элементов, которые не входят в систему, но изменение их состояния вызывает изменение поведения системы.

- Модель - описание системы,  отображающее определенную группу  ее свойств.

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

- Устойчивость

- цель

Закономерности  систем

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

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

1. Наличие сформулированной  единой цели у информационных  технологий в рамках разрабатываемой  системы. 2. Согласование информационных  технологий по входам и выходам  с окружающей средой. В информационных  технологиях как системе должны  быть определены оптимальные  точки доступа пользователей  при условии их высокой интеллектуализации, что будет способствовать широкому  внедрению информационных технологий  во все сферы человеческой  деятельности. 3. Типизация структур  информационных технологий. Должны  быть проведены типизация систем, в которые внедряются информационные  технологии, и типизация структур  базовых технологий по областям  их применения. 4. Стандартизация  и взаимная увязка средств  информационной технологии. 5. Открытость  информационных технологий как  системы. При разработке информационной  технологии исходная цель ее  создания в ряде случаев будет  неполной, поэтому создаваемая информационная  технология должна быть способна  к развитию как по вертикали, так и по горизонтали и охватывать все уровни управления и автоматизации производства.

3.Пользовательский  интерфейс и его эргономика. Интерфейс  ИС как сценарий поведения  пользователя. Роль графического  дизайна в ИС.

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

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

Интерфейс обеспечивает связь  между пользователем и процессом, выполняющим некоторое задание. Некоторые типичные устройства ввода-вывода:

– монохромные и цветные  дисплеи на базе ЭЛТ (оперативная  текстовая и графическая информация);

– лазерные, матричные, струйные принтеры (текстовый и графический  вывод);

– синтезаторы речи (речевой  вывод);

– клавиатура (текстовый  ввод);

– планшеты (графический  ввод);

– знаковый и строчный сканер (ввод документов);

– световое   перо,   сенсорный    экран,    манипуляторы    «мышь», «джойстик» (позиционирование и выбор);

– речевой ввод и машинное зрение.

Интерфейс «человек-компьютер» включает два основных компонента:

– процесс диалога, который  связывает фоновые процессы в  один процесс;

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

Вопрос и ответ; Меню; Экранные формы; На базе каманд;

Окно – это специальная (обычно прямоугольная) область физического окна, с помощью которого пользователь обозревает отдельные аспекты своего взаимодействия с задачей. Пиктограмма – это небольшое окно с изображением, отражающим содержимое буфера, с которым она связана. Эргономика (от греч. ergon работа и nomos закон) – научно-прикладная дисциплина, занимающаяся изучением и созданием эффективных систем, управляемых человеком.

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

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

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

Естественность, согласованность, дружественность, обратная связь, простота, гибкость, эстетическая привлекательность.

4.Принципы проектирования  сложных объектов. Нисходящее и  восходящее проектирование.

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

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

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

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

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

Объектно-ориентированный  подход.

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

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

Индивидуальность – свойства объекта, отличающие его от всех других объектов. Основные принципы ООП: Абстрагирование; ограничение доступа; модульность; существование иерархий.

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

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

Основные достоинства  нисходящего проектирования:

Проявление логики программы  возникает уже при чтении головного  модуля, что делает программу боле простой;

Возможность контроля хода работы над программой в процессе последовательной детализации программы обеспечивает ее непрерывную корректировку; отсутствие комплексной отладки благодаря  сквозному контролю позволяет сэкономить до 30% общего времени разработки программ;

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

5.Жизненный цикл  информационных систем: каскадная  и спиральная модели.

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

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

1) постановка задачи,

2) проектирование услуг, 

3) разработка и развертывание, 

4) гарантированное предоставление  услуг, 

5) модернизация или ликвидация  услуги.

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

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

1) анализ требований,

2) проектирование,

3) кодирование (программирование),

4) тестирование и отладка, 

5) эксплуатация и сопровождение. 

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

6.Методологии проектирования  ПО. CASE-технологии, их содержание и классификации

При конструировании программ, в зависимости от предъявляемых  требований к программному продукту используются следующие методологии  программирования: 1. Структурное программирование – это процесс программирования на алгоритмическом языке с использованием ограниченного набора базовых конструкций: линейной, ветвящейся и циклической. 2. Модульное программирование –  это программирование, при котором  программа представляется в виде совокупности логически связанных  модулей. 3. Объектно-ориентированное  программирование – это программирование, при котором основой программы  является объект, для которого определены совокупности данных и методы их обработки, при этом на основании одного объекта  может быть создана иерархия объектов. Термин CASE (Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ЭИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Большинство существующих CASE-систем ориентировано на автоматизацию проектирования программного обеспечения и основано на методологиях структурного (в основном) или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. В последнее время стали появляться CASE-системы, уделяющие основное внимание проблемам спецификации и моделирования технических средств. CASE - технология в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. Современные CASE-системы классифицируются по следующим признакам:

по  поддерживаемым методологиям проектирования: функционально (структурно) - ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

по  поддерживаемым графическим нотациям построения диаграмм: с фиксированной  нотацией, с отдельными нотациями  и наиболее распространенными нотациями;

  по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

по  типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные  на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

по  режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального  времени разработки проекта, ориентированные  на режим объединения подпроектов;

по  типу операционной системы: работающие под управлением WINDOWS; работающие под  управлением UNIX и работающие под  управлением различных ОС.

7.CASE-средства: функции,  назначение, классификация.

CASE-средства — набор  инструментов и методов программной  инженерии для проектирования  программного обеспечения, который  помогает обеспечить высокое  качество программ, отсутствие ошибок  и простоту в обслуживании  программных продуктов.

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

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

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

• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие  основные типы:

• средства анализа предназначенные для построения и анализа моделей предметной области (BPwin);
• средства анализа и проектирования, поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Designer/2000, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, DataBase Designer.
• средства разработки приложений. К ним относятся средства PowerBuilder, Developer/2000, Delphi
• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Designer/2000, ERwin. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).

Вспомогательные типы включают:

• средства планирования и управления проектом (Microsoft Project);
• средства конфигурационного управления (PVCS);
• средства тестирования (Quality Works);
• средства документирования (SoDA).

На сегодняшний день Российский рынок программного обеспечения  располагает следующими наиболее развитыми CASE-средствами:

• Vantage Team Builder;
• Designer/2000;
• Silverrun;
• ERwin+BPwin;
• S-Designor;
• CаSE.Аналитик.

8.Технологии хранения  данных. Язык SQL. Архитектура реляционной БД. Нормальные формы РБД. СУБД, примеры, области применения

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

Понизить  избыточность данных;

Повысить  их надежность.

Требования к БД:

Удовлетворять всем требованиям пользователей  к содержимому базы данных.

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

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

Удовлетворять требованиям  пользователей к производительности базы данных. При больших объемах  информации вопросы сохранения производительности начинают играть главную роль, сразу  показывая все недочеты проектирования. SQL –язык структурированных запросов – универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.  В язык SQL в качестве составных частей входят:

Язык  манипулирования данными (Data Manipulation Language, DML) в таблицах баз данных. Состоит из 4 основных команд:

SELECT (выбрать)INSERT (вставить) UPDATE (обновить) DELETE (удалить)

Язык определения данных

CREATE – cоздать ALTER – модифицировать DROP – удалить

Язык  управления данными: GRANT (дать права)

REVOKE (забрать права).

База данных – организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ и постоянного применения.

Реляционные базы данных состоят из таблиц. Основные свойства таблиц в реляционных БД:

В таблице не может быть двух одинаковых строк. Столбцы располагаются  в определенном порядке, который  создается при создании таблицы. У каждого столбца есть уникальное имя (в пределах таблицы), и все  значения в одном столбце имеют  один тип (число, текст, дата...). На пересечении  каждого столбца и строки может  находиться только атомарное значение. Первичный ключ (primary key) – поле или комбинация полей, значения которого во всех строках различны. Суррогатный ключ – дополнительное поле в базе данных. Как правило, это порядковый номер записи. Внешний ключ – это столбец или сочетание столбцов, которое применяется для принудительного установления связи между данными в двух таблицах. Нормальная форма – требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц). Первая нормальная форма (1NF):

Все строки должны быть различными.

Все элементы внутри ячеек  должны быть атомарными (не списками). Вторая нормальная форма (2NF):

Таблица должна находиться в  первой нормальной форме.

Любое её поле, не входящее в  состав первичного ключа, функционально  полно зависит от первичного ключа. Третья нормальная форма (3NF)

Таблица находится во второй нормальной форме.

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

Иерархические;СетевыеРеляционные;Объектно-ориентированные;  Объектно-реляционные.

Классификация СУБД по степени распределённости:

Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

Распределённые  СУБД (части СУБД могут размещаться  на двух и более компьютерах).

Классификация СУБД по способу доступа к БД: файл-серверные, клиент-серверные, встраеваемые.

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

Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности.

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

В теории проектирования информационных систем предметную область принято  рассматривать в виде трех представлений:

представление предметной области  в том виде, как она реально  существует

как ее воспринимает человек (имеется в виду проектировщик  базы данных)

как она может быть описана  с помощью символов.

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

Отсюда вытекают основные этапы, на которые разбивается процесс  проектирования базы данных информационной системы:

Концептуальное  (инфологическое) проектирование- построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции, такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. По окончании данного этапа получаем концептуальную модель, которая служит истончником информации для фазы логического проектирования. Часто она представляется в виде модели "сущность-связь" (ER-диаграммы).

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

Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.; создание схемы базы данных для конкретной СУБД.

10.Проектирование  методом «сущность-связь». Нормализация отношений.

“Сущность-связь” – это модель предметной области, которая позволяет моделировать объекты ПО и их взаимоотношения.

В основе модели лежит три  конструктивных элемента:

-Сущность;

-Атрибут;

-Связь;

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

Атрибут – это характеристика сущности, описание свойств сущности.

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

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

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

В любой таблице имеется  один или несколько ключевых столбцов, от которых зависят все остальные  столбцы. Ключ служит для поиска данных в таблице и не может иметь  значение “не определено”. В рассмотренном  выше примере ключом является столбец  “Табельный номер”. Если ключ таблицы  состоит из нескольких столбцов, необходимо провести проверку на наличие неполных функциональных зависимостей. При неполной функциональной зависимости значение в неключевом столбце определяется не всем ключом, а его частью. Увеличение количества таблиц усложняет систему и, в ряде случаев, ведет к увеличению времени ответа на запрос. Решение о том, что важнее: безызбыточность, однозначность представления данных, отсутствие аномалий удаления и включения или простота организации базы данных и высокая скорость выборки всей совокупности данных принимает разработчик, исходя из приоритетов предметной области.

11.Объектно-ориентированный  подход при проектировании ИС. Унифицированный язык моделирования  UML.

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

Объектно-ориентированная  технология проектирования ИС включает в себя следующие компоненты:

• технологию конструирования  концептуальной объектно-ориентированной  модели предметной области;

• инструментальные средства спецификации проектных решений;

• библиотеки типовых компонент  модели предметной области;

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

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

UML — язык графического описания для объектного моделирования в области разработки программного обеспечения. Гради Буч и Джеймс Рамбо в 1994 году начали его разработку.

Главными в разработке UML были следующие цели:

– предоставить пользователям  готовый к использованию выразительный  язык визуального моделирования, позволяющий  разрабатывать осмысленные модели и обмениваться ими;

– предусмотреть механизмы  расширяемости и специализации  для расширения базовых концепций;

– обеспечить независимость  от конкретных языков программирования и процессов разработки;

– обеспечить формальную основу для понимания этого языка  моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

– стимулировать рост рынка  объектно-ориентированных инструментальных средств;

– интегрировать лучший практический опыт.

Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др.

Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями).

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

Теоретически диаграммы  могут содержать любые комбинации сущностей и отношений. В UML выделяют следующие типы диаграмм:

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

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

12.Концептуальная  модель UML, строительные блоки UML, правила языка UML, общие механизмы  языка UML, архитектура, жизненный  цикл разработки ПО.

Для понимания UML необходимо усвоить его концептуальную модель, которая включает в себя три составные  части:

– основные строительные блоки  языка;

– правила их сочетания;

– некоторые общие для  всего языка механизмы.

Словарь языка UML включает три  вида строительных блоков:

Сущности – это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммыгруппируют представляющие интерес совокупности сущностей.

В UML имеется четыре типа сущностей:

– структурные;

– поведенческие;

– группирующие;

– аннотационные.

Структурные сущности – это имена существительные в моделях на языке UML. Класс (Class) – это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Графически класс изображается в виде прямоугольника. Интерфейс (Interface) – это совокупность операций, которые определяют сервис (набор услуг), предоставляемый классом или компонентом. Таким образом, интерфейс описывает видимое извне поведение элемента. Графически интерфейс изображается в виде круга. Кооперация (Collaboration) определяет взаимодействие; она представляет собой совокупность ролей и других элементов, которые, работая совместно, производят некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. Графически кооперация изображается в виде эллипса, ограниченного пунктирной линией. Прецедент (Usecase) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (Actor). Прецедент применяется для структурирования поведенческих сущностей модели. Прецеденты реализуются посредством кооперации. Графически прецедент изображается в виде ограниченного непрерывной линией эллипса. (Component) – это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. Графически компонент изображается в виде прямоугольника с вкладками. Эти базовые элементы – классы, интерфейсы, кооперации, прецеденты и компоненты – являются основными структурными сущностями, которые могут быть включены в модель UML  Существуют также разновидности этих сущностей: актеры, сигналы, утилиты(виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).

Поведенческие сущности (Behavioralthings) являются динамическими составляющими модели UML. Взаимодействие (Interaction) – это поведение, суть которого заключается в обмене сообщениями (Messages) между объектами в рамках конкретного контекста для достижения определенной цели. Графически сообщения изображаются в виде стрелки. Автомат (Statemachine) – это алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. Графически состояние изображается в виде прямоугольника с закругленными углами. Пакеты (Packages) представляют собой универсальный механизм организации элементов в группы. Изображается пакет в виде папки с закладкой. Аннотационные сущности – пояснительные части модели UML. В языке UML определены четыре типа отношений:

– зависимость;

– ассоциация;

– обобщение;

– реализация. Жизненный цикл – период создания и использования ИС, охватывающий ее различные состояния, начиная с момента возникновения необходимости в данной автоматизированной информационной системе и заканчивая моментом ее полного выхода из употребления у пользователей. Суть жизненного цикла разработки ИС в различных подходах одинакова и сводится к выполнению следующих этапов:  1. Планирование и анализ требований (предпроектная стадия) ─ системный анализ. 2. Проектирование. 3. Реализация. 4. Внедрение. 5. Эксплуатация ИС.