Технологии и методы проектирования

 

Технология и методы проектирования.

Основные стадии и этапы технологической схемы проектирования ИС.

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

Разработка бизнес-плана создания ИС.

Разработка, согласование и утверждение технического задания.

Проектирование функциональной части ИС.

Использование функционального подхода к проектированию состава и структуры ИС.

Использование теории бизнес - процессов и бизнес - правил.

 

 

       2.1 Концепция проектирования ИС.

Система.

Декомпозиция, принципы иерархии.

Внешняя среда.

Методологические принципы проектирования ИС:

- концептуальное проектирование;

- логическое проектирование;

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

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

       1.Заданной последовательности выполнения технологических операций проектирования.

       2.Критерии и правила используемых для оценки результатов выполнения технологических операции.

       3.Графические и текстовые средства, используемые для описания проектируемой системы.

 

 

       2.2 Задачи

.

Разработка бизнес-плана создания ИС.

 

Разработка, согласование и утверждение технического задания.

Знакомство с проектной деятельностью предприятий.

 

 

       2.3 Определение

.

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

Существую три основных свойства бизнес-функции:

- Нормируеммость (формальные единицы измерения или система координат);

-Исчисляемость (Масштабируемость);

 

- Возможность количественной оценки.

В пункте 3.1.2 МУ к курсовому проектированию - пример описания деятельности ВКГТУ (фрагмент устава университета).

 

 

       2.4 Бизнес-процесс

.

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

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

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

 

       2.5 Вопрос.

Какие модели проходили в специальных дисциплинах?

 

 

       2.6 Бизнес - правила

.

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

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

       Идеология архитектуры «клиент-сервер» требует переноса максимально возможного числа БП на сервер.

 

       2.7 Преимущества

.

К преимуществам такого подхода относятся:

- гарантия целостности БД, поскольку БП сосредоточены в едином месте (в базе данных);

- автоматическое применение БП, определенных на сервере БД, для любых приложений;

- отсутствие различных реализаций БП в разнотипных клиентских приложениях, работающих с БД;

- быстрое срабатывание БП, поскольку они реализуются на сервере и, следовательно, нет необходимости посылать данные клиенту, увеличивая при этом сетевой трафик;

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

 

       2.8 Недостатки

.

К недостаткам хранения бизнес - правил на сервере можно отнести:

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

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

       На практике в клиентских приложениях реализуют лишь такие бизнес - правила, которые трудно или невозможно реализовать с применением средств сервера. Все остальные БП переносятся на сервер.

 

 

       2.9 Примеры

.

Примеры реализации в МУ к лабораторной работе.

 

В первую очередь бизнес - правила реализуют следующие ограничения БД:

- задание допустимого диапазона значений;

- задание значения по умолчанию;

- требование уникальности значения

- запрет пустого значения

- ограничение ссылочной целостности.

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

На программном уровне бизнес - правила можно реализовать в сервере и в приложении.

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

 

       2.10 Вопрос

.

Зачем производится декомпозиция сложных функций?

 

       2.11 Декомпозиция БФ

.

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

           

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

- каждая подсистема должна реализовывать единственную функцию системы, атомарную с точки зрения пользователя;

 

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

 

- связь между подсистемами должна вводиться только при наличии связи между соответствующими функциями системы;

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

 

       2.12 Иерархия процессов

.

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

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

       Человек при создании сложных систем также подражает природе. Любая организация имеет директора, заместителей по направлениям, иерархию руководителей подразделений, рядовых служащих (организационно – штатная структура предприятия).

 

       2.13 Графические нотации

.

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

Известно, что “одна картинка стоит тысячи слов”.

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

- воздействия, инициирующие каждый шаг бизнес - процесса;

 

- исполнители каждого шага (это могут быть как люди, так и программы и механизмы);

 

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

 

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

 

 

       2.14 Пример

.

 

 

           

Анализ.

Частота издания телефонного справочника предприятия.

Его объем и себестоимость.

Количество исправлений – изменений за определенный срок.

Количество устанавливаемых, например, ежедневно контактов.

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

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

       Решение: разработать электронный справочник включающий:

- серверную БД;

- клиентскую часть, включая локальную БД;

- подсистему автоматического обновления;

- подсистему администрирования;

- подсистему подготовки печатного издания;

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

- web – интерфейс доступа.

Согласно методологии структурного проектирования необходимо:

- провести декомпозицию, необходимое количество уровней;

- построить иерархическую структуру процессов;

- определить взаимодействие процессов;

- определить пользователя и входные/выходные данные каждого процесса.

 

       2.15 Стандарты

.

SPC (Software Productivity Consortium) выделяет тот минимум стандартов на процессы проектирования, который рекомендуется взять за основу. В их число включены ISO/IEC 12207, ISO/IEC 15288 CD2, ISO 15504 (SPICE), EIA/ANSI 632, EIA/IS 731 (SECM), TickIT.

Назначение следующих нормативных документов (НД):

- ISO/IEC 12207, Information technology - Software life cycle processes. 1995.

- ISO/IEC TR 15271, Information technology - Guide for ISO/IEC 12207. 1998. (Стандарт ISO/IEC 12207 оказал революционизирующее влияние на многие другие НД, в том числе на стандарты моделей системного проектирования: процессы жизненного цикла систем, модель зрелости процессов.)

- EIA/ANSI 632, Processes for Engineering a System. 1999. (Этот стандарт не только заменил ряд популярных более старых американских стандартов, но был использован как вклад американской группы в создание ISO/IEC 15288.)

- EIA/IS-731, System Engineering Capability Model (SECM). 1999. Part 1, SECM Model. Part 2, SECM Appraisal Method. (В области стандартов на уровни зрелости процессов аналогично тому, как модель SW CMM переросла в модель и стандарт SPICE, модель SE CMM переросла в модель и стандарт SECM.)

- ISO/IEC 15288 CD2, Life Cycle Management - System Life Cycle Processes. 2000.

 

       Для обеспечения преемственности полезно добавить в эту группу стандарты ГОСТ 34 (не гармонизированные с новыми, но применимые и полезные из-за совместимости по многим базовым понятиям, по сути многих работ, по опыту применения и др.).

       Существенно, что два «потока» стандартов - на SE (system engineering) и на SW (software engineering), развивавшихся параллельно, четко стыкованы посредством указанных документов.

И дело не только в том, что указанные документы хорошо согласованы друг с другом по основным понятиям и принципам. Очень важно, что такие, казалось бы, «чисто технические» области, как создание ПО (SW-процессы), регламентированы стандартами, прямо требующими их совместного применения со стандартами на процессы системного проектирования (SE-процессы).

 

       2.16 Методологические принципы проектирования ИС

.

(11 номер КП за 2001г.)

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

Логическое моделирование - для описания деятельности предприятия CASE-средствами.

Физическое моделирование - для формализации деятельности предприятия средствами ERP-системы (то есть для создания нормативной модели предприятия).

Концептуальная модель является отраслевой моделью и, как правило, разрабатывается для предприятия внешним консультантом (обычно на основе эталонных моделей, предлагаемых поставщиками ERP-систем). В ней определяются основные направления развития предприятия через графическое представление передовой мировой практики (заключенной в стандарты ISO и ERP) и через определение несоответствий деятельности предприятия данной практике (на основе проведения сопоставительного анализа - benchmarking). Концептуальная модель подразумевает унификацию основных процессов предприятия в соответствии со стандартами ISO 9001:2000 и ERP.

 

 

       2.17 Концептуальная модель

.

 

 

Эталонная модель с использованием ISO 9000 переводится в IDEF0-модель, отображающую:

- декомпозицию процессов предприятия - верхний уровень иерархии процессов соответствует элементам и подэлементам стандарта ISO 9001:2000, а нижние уровни раскрываются с использованием ERP-стандарта;

- проектирование графического «скелета» документации системы менеджмента качества (СМК) предприятия;

- определение ключевых пользователей процессов и бизнес - функций;

- определение на базе ERP-системы основных модулей информационной системы предприятия, обеспечивающих выполнение процессов;

- определение связей процессов по входам/выходам.

 

       2.18 Логическая модель

.

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

Цель логического моделирования - построить интегрированную модель деятельности предприятия, являющейся связующим звеном между бизнес - методиками и ERP-системой.

 

Логическая модель описывает деятельность предприятия, посредством объектно-ориентированного проектирования (опираясь на методологию бизнес - моделирования RUP9 и нотации UML10) или структурногопроектирования.

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

Модель помогает детально ответить на следующие вопросы:

- кто и где исполняет бизнес - функции (организационный аспект деятельности);

- что перемещается в материальных и в связанных с ними информационных потоках (элементный аспект деятельности предприятия);

- как предприятие выполняет бизнес - функции (функциональный аспект);

- когда предприятие осуществляет бизнес - функции (динамический аспект);

- какая информационная платформа (какие инструменты) необходима для поддержания бизнес - функций на предприятии.

 

       2.19 Взаимодействие

.

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

 

 

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

- иерархическая структура процессов;

- взаимодействие процессов (реализация процессного подхода).

Процессы на предприятии определяются наличием конечного продукта (не обязательно материального), у которого есть потребитель и поставщик. Отношения «поставщик - потребитель» рассматриваются не только с внешними контрагентами, но и внутри предприятия.

В рамках организационного аспекта описываются:

- организационная структура предприятия, включающая в себя иерархию подразделений, отделов, участков, должностей, рабочих мест;

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

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

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

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

       Для описания элементного аспекта предприятия предлагается использовать диаграмму классов (Class), а для отражения возможных состояний элементов - диаграмму состояний (State).

       В рамках динамического аспекта реализуется ситуационный подход:

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

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

- определяется документооборот (или товарооборот) между организационными единицами. Документооборот описывается для каждого способа выполнения процесса. Для описания взаимодействия документов и исполнителей предлагается использовать диаграммы кооперации (Collaborations).

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

 

       2.20 Методология SADT

.

       Методология функционального моделирования SADT (Structured Analysis and Design Technique) - одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Дугласом Россом (Ross).

На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition).

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

Правила SADT включают:

- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

- связность диаграмм (номера блоков);

- уникальность меток и наименований (отсутствие повторяющихся имен);

- синтаксические правила для графики (блоков и дуг);

- разделение входов и управлений (правило определения роли данных).

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

       В настоящее время успешно используются практически все известные методологии структурного анализа и проектирования, однако наибольшее распространение получили методологии SADT (Structured Analysis and Design Technique), структурного системного анализа Гейна-Сарсона (Gane-Sarson), структурного анализа и проектирования Йодана/Де Марко (Yourdon/De Marko), развития систем Джексона (Jackson), развития структурных систем Варнье-Орра (Warnier-Orr), анализа и проектирования систем реального времени Уорда-Меллора (Ward-Mellor) и Хатли (Hatley), информационного моделирования Мартина (Martin).

Диаграмма примера создана в «Visio 2000».

 

 

       2.21 BРwin

.

Использование BРwin в консалтинговых проектах.

КомпьютерПресс 1'2002, Максим Сычевский.

 

 

 

 

           

           

 

2.22 Декомпозиция

.

 

 

 

       2.23 Диаграмма потоков данных

.

Диаграмма потоков данных (DFD).

 

 

 

       2.24 Иерархическая структура

 

.

       2.25 Сравнительный анализ SADT-моделей и потоковых моделей

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

- диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - для этой цели чаще всего используются DFD или SADT (IDEF0);

- диаграммы, моделирующие данные и их взаимосвязи (ERD);

- диаграммы, моделирующие поведение системы (STD).

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

       Соотношение применения этих двух разновидностей структурного анализа в существующих CASE-средствах составляет по материалам CASE Consulting Group 90% для DFD и 10% для SADT. По данным автора, основанным на анализе 127 существующих CASE-пакетов, это соотношение выглядит как 94% к 3%, соответственно. Оставшиеся 3% CASE-средств используют методологии, не относящиеся ни к одной из перечисленных разновидностей. Представляется очевидным, что соотношение такого же порядка справедливо и для цифр распространенности рассматриваемых методологий на практике.

 

       2.26 Модели процессов проектирования.

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

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

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

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

Участие системотехников, программистов на всех этапах анализа, залог успешной реализации проекта информатизации бизнес – процессов.

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

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

 

       2.27 Основные этапы.

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

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

- проектирование,

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

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

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

 

       2.28 Модели проектирования.

Классические модели проектирования информационных систем:

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

Поэтапная модель «Водопад», с промежуточным контролем. Разработка ПО ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют уменьшить трудоемкость процесса разработки по сравнению с каскадной моделью. Время жизни каждого из этапов растягивается на весь период разработки.

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

 

       2.29 «Водопад».

 

 

       2.30 Этапы.

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

Проектирование – модель данных, экранные формы, выбор среды, архитектура, структура и разработка тестов…

Тестирование – контроль соответствия поставленной задачи и достижения целей.

 

       2.31 Организация проектной деятельности.

Стандарты уровня предприятия и проекта. В стандартах явно предусмотрены работы по постановке проектной деятельности и управлению ею. В ISO/IEC 15288 такими являются:

1. Процесс «Управление предприятием» (внедрение стандарта на основе стратегии предприятия);

2. Процесс «Управление процессами ЖЦС»;

3. Процесс «Управление ресурсами для 1 и 2».

Для процесса «Управление предприятием» предусмотрены следующие цель и результаты.

       Цель процесса:

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

       Результаты процесса:

1. Стратегические и тактические планы и цели [предприятия], которые определяют формирование правил и процедур для внедрения требований данного Международного Стандарта;

2. Правила и процедуры для «управления ЖЦС», включая управление качеством, гарантии и контроль, в соответствии с ISO 9001;

3. Роли, ответственность и права (власть), способствующие эффективному управлению ЖЦС.

 

       2.32 Задачи стандартов.

Стандарты определяют процессы, которые должны в практике работы предприятия отвечать, в частности, на такие вопросы:

- откуда берутся (должны браться) проекты и проектные программы?

- как получить стандарты, регламенты, инструкции, которые рационально использовать именно на данном предприятии (стандарты предприятия)?

- как управлять процессами проектирования на предприятии?

- как получить набор стандартов конкретного проекта?

- как обеспечить стыковку различных подпроектов?

- что является определяющим критерием для проверки правильности выполнения проекта?

Узнать про используемые стандарты предприятия, можно, поинтересовавшись о последних результатах внедрения ИС.

 

Новый объем процессов ЖЦ системы определяется стандартом EIA 632.

 

 

Объем процессов ЖЦ системы по новому стандарту EIA 632 («От старого к новому, от системного проектирования к полному проектированию систем»)

 

       2.33 Заключение

.

Итак:

1. Модель бизнеса (предприятия), с использованием математических моделей …

2. Модель проектирования, как процесса.

3. Модели процессов, например, линейное планирование, …

4. Модели данных (иерархическая, файловая, реляционная, объектная, объектно-реляционная, …).

5. Архитектура системы …

 

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

Например, по спиральной модели проектирования.

 

       2.34 Вопросы по 1 лабораторной.

Определение и основные свойства бизнес - функции.

Методологии проектирования информационных систем.

Определение бизнес – процесса, примеры бизнес - процессов.

Принципы декомпозиции сложных систем.

Что является источником бизнес – процессов?

Ограничения ссылочной целостности SQL – сервера.

Ограничения значений полей таблицы.

Почему каждая таблица обязана иметь первичный ключ?

Особенности реализации ограничений в ИС с различной архитектурой.

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

Типы данных, используемых в SQL – сервере InterBase.

 

       2.35 Задания СРСП.

1. Входной контроль по дисциплинам «Программирование», «Базы данных»;

2. Защита модели выбранного бизнес – процесса;

3. Защита разработанных бизнес – правил;

4. Ответить на контрольные вопросы первого модуля [1];

5. Провести проверку SQL – кода создания БД;

6. Защитить отчет по первой лабораторной работе;

7. Защитить отчет по разделу 3.1 курсовой работы [2];

8. Разработать пример вопроса тестового задания по теме раздела.

 

       2.36 Задания СРС.

1. Изучить методические указания к первой лабораторной работе [1];

2. Ответить на примеры тестовых заданий к первому модулю [1];

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

4. Выбор предметной области курсового проекта;

5. Установка на персональном компьютере SQL – сервера InterBase;

6. Проверка работоспособности среды управления сервером;

7. Изучить SQL - код создания учебной БД (FONEBOOK.GDB);

8. Проектирование и использование ограничений;

9. Изучение функции среды управления: CREATE DATABASE, DROP DATABASE, REGISTER DATABASE, CONNECT, DISCONNECT;

10. Изучить конспект 1,2 лекций [3];

 

       2.37 Демонстрация.

Инсталляция учебного примера.

Подключение и регистрация сервера.

Работа со справочным материалом.

Бизнес правила учебного примера.

Ограничения ссылочной целостности.

 

 

2.38 Тренировочный тест, 10 вопросов.

 

Ответы

1	2	3	4	5	6	7	8	9	10