metoda_2013

БАЗЫ ДАННЫХ.

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

Кроме того, триггеры могут быть привязаны не к таблице, а к представлению (VIEW). В этом случае с их помощью реализуется механизм «обновляемого представления». В этом случае ключевые слова BEFORE и AFTER влияют лишь на последовательность вызова триггеров, так как собственно событие (удаление, вставка или обновление) не происходит.

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

Пример (MS SQL ?):

Rem Табличный

CREATE OR REPLACE TRIGGER tr2 AFTER UPDATE ON rayon

BEGIN

insert into info values ('table "rayon" has changed'); END;

Для отличия табличных триггеров от строчных вводится дополнительные ключевые слова при описании строчных триггеров. В MS SQL (?) это словосочетание FOR EACH ROW.

Пример:

Rem Строчный

CREATE OR REPLACE TRIGGER tr1 AFTER UPDATE ON rayon FOR EACH ROW BEGIN

60

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

insert into info values ('one string in table "rayon" has changed');

END;

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

III.ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО

ОБЕСПЕЧЕНИЯ.

1. Технология программирования. Система разработки ПО.

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

указания последовательности выполнения технологических операций;

перечисление условий, при которых выполняется операция;

описание самих операций (исходные данные, результаты, методы оценки);

способ описания проектируемой системы.

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

Две тенденции в области разработки ПО в последние два десятилетия:

1.Быстрый рост количества приложений,

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

Только хорошо организованные коллективы программистов, владеющие методами разработки ПО, способны правильно построить работу над проектом.

Система разработки ПО включает в себя (четыре «п»):

1.Персонал (кто делает)

2.Процесс (способ которым делается)

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

4.Системы принципов разработки – основа профессиональной деятельности разработчиков ПО в 21 веке:

61

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

Индивидуальный процесс разработки(PSP)Хамфри,

Командный(TSP),

Модель зрелости возможностей(CMM Capability

Maturity Model).

5.Хорошо продуманные стандарты документации облегчают создание ПО, направляют процесс его создания.

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

7.Некоторые аспекты проекта:

8. ­ ООП

9.­ Проектирование слоев

10.­ UMLэто не методология это система обозначений.

11.­ Унаследованные системы.

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

o Спецификация требований к ПО;

o Проектная модель;

o Исходный и объектный код;

o Тестовые процедуры и тестовые варианты o Документация

13. Будем называть эти составляющие – артефактами.

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

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

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

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

62

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

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

Вспомним рассмотренные во введении четыре «П» разработки программ. Цель любого программного проекта состоит в производстве некоторого программного продукта (например, текстового редактора). То, как в рамках проекта производится продукт, представляет собой процесс. Поскольку критичным для успеха дела является взаимодействие членов команды, мы включаем в рассмотрение персонал.

В современной практике разработки программного обеспечения существует пять ключевых требований, в основном сформулированных Хэмфри. Первое из них — заранее выбрать свою шкалу измерения качества для проекта и продукта. Например, «500 строк полностью протестированного программного кода, написанного одним человеком за месяц» или «не более трех ошибок на тысячу строк программного кода». Второе требование состоит в сборе информации по всем проектам с целью создания базы для оценки будущих проектов. Третье положение гласит, что все требования, схемы, программные коды и материалы тестирования должны быть легко доступны всем членам команды. Суть четвертого условия состоит в том, что все участники команды должны следовать избранному

63

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

2. Процесс разработки программного обеспечения

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

Хорошие разработчики программного обеспечения избегают повторения ошибок предыдущих проектов за счет документирования и совершенствования своего процесса разработки.

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

♦Автономное:

14.пример — текстовый редактор.

♦Встроенное:

oчасть уникального приложения с привлечением аппаратного обеспечения;

пример — автомобильный контроллер.

♦Реального времени:

64

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

пример — программное обеспечение радиолокатора.

♦Сетевое:

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

Принципы применимы ко всем этим типам. Стандартная последовательность шагов такова:

1. Понять природу и сферу применения продукта. Бизнесмоделирование - описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой системе. Используется SADT, RUP: диаграмма деятельности. Это кажется очевидным, однако для того, чтобы понять, чего хочет заказчик, требуется ощутимое время, особенно если заказчик сам не знает достаточно хорошо, чего он в действительности хочет. Нужно составить представление о масштабах проекта и с этой целью оценить, какими сроками, финансами и персоналом мы располагаем. Если, например, для построения видеоигры нам предоставляется 10 тыс. долларов, один разработчик и один месяц срока, можно говорить разве что о реализации прототипа игры. Если же мы располагаем бюджетом в 5 млн долларов, 20 разработчиками и сроком в 18 месяцев, то речь уже может идти о создании полноценного конкурентоспособного программного продукта и совсем других масштабах производственной деятельности.

2. Анализ требований (Requirements Engineering) — это процесс сбора требований к системе, их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов.

Требование – это потребность или ожидание, которое 1 - установлено в явном виде (например, заказчиком)

2 - наследуется, как обязательное из других систем требований (ГОСТа)

3 - подразумевается (например, выход по ESC) Описание системы 3. Проектирование ПО. Разработка архитектуры.

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

65

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

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

5. Тестирование (частей ПО –> интеграция и тест-е системы в целом) - процесс, позволяющий определить корректность, полноту и качество разработанного ПО; процесс формальной проверки или верификации может доказать, что дефекты отсутствуют, с точки зрения используемого метода.

В зависимости от используемого процесса разработки (модели разработки, см вопрос 1 по трпо) шаги 2 - 5 могут быть выполнены несколько раз.

6. Документирование - это документы, сопровождающие некоторое ПО архитектурная/проектная -обзор программного обеспечения, включающий описание рабочей среды и принципов, которые должны быть использованы при создании ПО; техническая - документация на код, алгоритмы, интерфейсы, API; пользовательская - руководства для конечных пользователей, администраторов системы и другого персонала; маркетинговая

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

8. Сопровождение - процесс улучшения, оптимизации и устранения дефектов (ПО) после передачи в эксплуатацию. Может потребовать до 80 % ресурсов, потребовавшихся на разработку.

3. Проектирование, как составляющая Система разработки ПО

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

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

66

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

Взависимости от создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации — блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты. (см соотв. вопрос по трпо)

Проектированию обычно подлежат:

*Архитектура ПО

*Устройство компонентов ПО

*Пользовательские интерфейсы

Вроссийской практике результат проектирования представляется в виде комплекса документов под названием «Эскизный проект», «Технический проект», в зарубежной —

Software Architecture Document, Software Design Document.

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

Проектирование охватывает три основные области: 1.проектрование объектов данных; 2.проектрование программ, экранных форм, отчетов, которые

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

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

Проектирование всегда начинается с определения цели проекта (в общем виде - решение ряда взаимосвязанных задач,

67

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

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

oтребуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям

функционирования;

o требуемой пропускной способности системы;

o требуемого времени реакции системы на запрос; o безотказной работы системы;

o необходимого уровня безопасности;

o простоты эксплуатации и поддержки системы.

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

Конечными продуктами этапа проектирования являются: схема базы данных (на основании ER-модели, разработанной

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

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

С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: "Программа = Данные + Алгоритмы". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой

68

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

"обрабатывающие центры" (функции), а связи между узлами описывают движение данных.

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

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

4. Основные технологии разработки ПО

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

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

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

1.Главное — удовлетворить заказчика и предоставить ему продукт как можно скорее

2.Новые выпуски продукта должны появляться раз в несколько недель.

3Наиболее эффективный способ передачи знаний участникам разработки и между ними – личное общение

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

итеративную разработку ПО и на минимальную формализацию ДЛЯ КОНКРЕТНОГО ПРОЕКТА процесса (минимально допустимый уровень формализации).

Примеры: eXtreme Programming(XP), Crystal Clear(CC), Feature Driven Development (FDD).

69