IDEF0 - стандарт и методология функционального моделирования

[править]Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной  разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. названиеэволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью^[4].

Модель IID предполагает разбиение  жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение —инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения^[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень  долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать  часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет  переделать и улучшить позже»^[3].

Различные варианты итерационного  подхода реализованы в большинстве  современных методологий разработки (RUP, MSF, XP).

[править]Спиральная модель

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

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

На каждой итерации оцениваются:

• риск превышения сроков и стоимости проекта;
• необходимость выполнения ещё одной итерации;
• степень полноты и точности понимания требований к системе;
• целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным  вариантом. К сожалению, нередко  спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают  как совершенно самостоятельную  модель наряду с IID^[3].

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

1. Дефицит специалистов.
2. Нереалистичные сроки и бюджет.
3. Реализация несоответствующей функциональности.
4. Разработка неправильного пользовательского интерфейса.
5. Перфекционизм, ненужная оптимизация и оттачивание деталей.
6. Непрекращающийся поток изменений.
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9. Недостаточная производительность получаемой системы.
10. Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий  набор контрольных точек^[5]:

1. Concept of Operations (COO) — концепция (использования) системы;
2. Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;
3. Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
4. Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;
5. Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

 

 

КУРСОР

 

USE AdventureWorks2008R2;

GO

SET NOCOUNT ON;

 

DECLARE @vendor_id int, @vendor_name nvarchar(50),

    @message varchar(80), @product nvarchar(50);

 

PRINT '-------- Vendor Products Report --------';

 

DECLARE vendor_cursor CURSOR FOR

SELECT BusinessEntityID, Name

FROM Purchasing.Vendor

WHERE PreferredVendorStatus = 1

ORDER BY BusinessEntityID;

 

OPEN vendor_cursor;

 

FETCH NEXT FROM vendor_cursor

INTO @vendor_id, @vendor_name;

 

WHILE @@FETCH_STATUS = 0

BEGIN

    PRINT ' ';

    SELECT @message = '----- Products From Vendor: ' +

        @vendor_name;

 

    PRINT @message;

 

    -- Declare an inner cursor based  

    -- on vendor_id from the outer cursor.

 

    DECLARE product_cursor CURSOR FOR

    SELECT v.Name

    FROM Purchasing.ProductVendor AS pv

    INNER JOIN Production.Product AS v

        ON pv.ProductID = v.ProductID AND

           pv.BusinessEntityID = @vendor_id;  -- Variable value from the outer cursor

 

    OPEN product_cursor;

    FETCH NEXT FROM product_cursor INTO @product;

 

    IF @@FETCH_STATUS <> 0

        PRINT '         <<None>>' ;   

 

    WHILE @@FETCH_STATUS = 0

    BEGIN

 

        SELECT @message = '         ' + @product

        PRINT @message

        FETCH NEXT FROM product_cursor INTO @product;

        END;

 

    CLOSE product_cursor;

    DEALLOCATE product_cursor;

        -- Get the next vendor.

    FETCH NEXT FROM vendor_cursor

    INTO @vendor_id, @vendor_name;

END

CLOSE vendor_cursor;

DEALLOCATE vendor_cursor;

 

 

 

 

 

CREATE TRIGGER (Transact-SQL)

Создает триггер языка  обработки данных, DDL или входа. Триггер  — это особая разновидность хранимой процедуры, выполняемая автоматически  при возникновении события на сервере базы данных. Триггеры языка  обработки данных выполняются по событиям, вызванным попыткой пользователя изменить данные с помощью языка  обработки данных. Событиями DML являются процедуры INSERT, UPDATE или DELETE, применяемые  к таблице или представлению. Эти триггеры срабатывают при  запуске любого допустимого события  независимо от того, влияет ли оно на какие-либо строки таблицы.

Триггеры DDL срабатывают  в ответ на ряд событий языка  определения данных (DDL). Эти события прежде всего соответствуют инструкциям Transact-SQL CREATE, ALTER, DROP и некоторым системным хранимым процедурам, которые выполняют схожие с DDL операции. Триггеры входа могут срабатывать в ответ на событие LOGON, возникающее при установке пользовательских сеансов. Триггеры могут быть созданы непосредственно из инструкций Transact-SQL или из методов сборок, созданных в среде выполнения CLR платформы Microsoft.NET Framework, и переданы экземпляру SQL Server. SQL Server допускает создание нескольких триггеров для любой указанной инструкции.

 

Trigger on an INSERT, UPDATE, or DELETE statement to a table or view (DML Trigger)

CREATE TRIGGER [ schema_name . ]trigger_name

ON { table | view }

[ WITH <dml_trigger_option> [ ,...n ] ]

{ FOR | AFTER | INSTEAD OF }

{ [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] }

[ WITH APPEND ]

[ NOT FOR REPLICATION ]

AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME <method specifier [ ; ] > }

 

<dml_trigger_option> ::=

    [ ENCRYPTION ]

    [ EXECUTE AS Clause ]

 

<method_specifier> ::=

    assembly_name.class_name.method_name

 

Trigger on a CREATE, ALTER, DROP, GRANT, DENY, REVOKE, or UPDATE STATISTICS statement (DDL Trigger)

CREATE TRIGGER trigger_name

ON { ALL SERVER | DATABASE }

[ WITH <ddl_trigger_option> [ ,...n ] ]

{ FOR | AFTER } { event_type | event_group } [ ,...n ]

AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier >  [ ; ] }

 

<ddl_trigger_option> ::=

    [ ENCRYPTION ]

    [ EXECUTE AS Clause ]

 

<method_specifier> ::=

    assembly_name.class_name.method_name

 

Trigger on a LOGON event (Logon Trigger)

CREATE TRIGGER trigger_name

ON ALL SERVER

[ WITH <logon_trigger_option> [ ,...n ] ]

{ FOR| AFTER } LOGON 

AS { sql_statement  [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier >  [ ; ] }

 

<logon_trigger_option> ::=

    [ ENCRYPTION ]

    [ EXECUTE AS Clause ]

 

<method_specifier> ::=

    assembly_name.class_name.method_name

 

 

ПРИМЕРЫ

1. Использование триггера DML с предупреждающим сообщением

 

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

 

USE AdventureWorks2008R2;

GO

IF OBJECT_ID ('Sales.reminder1', 'TR') IS NOT NULL

   DROP TRIGGER Sales.reminder1;

GO

CREATE TRIGGER reminder1

ON Sales.Customer

AFTER INSERT, UPDATE

AS RAISERROR ('Notify Customer Relations', 16, 10);

GO

 

 

 

2. Использование триггера DML с предупреждающим сообщением, отправляемым по электронной почте

 

В следующем примере указанному пользователю (MaryM) по электронной почте отправляется сообщение при изменении таблицы Customer.

USE AdventureWorks2008R2;

GO

IF OBJECT_ID ('Sales.reminder2','TR') IS NOT NULL

    DROP TRIGGER Sales.reminder2;

GO

CREATE TRIGGER reminder2

ON Sales.Customer

AFTER INSERT, UPDATE, DELETE

AS

   EXEC msdb.dbo.sp_send_dbmail

        @profile_name = 'AdventureWorks2008R2 Administrator',

        @recipients = 'danw@Adventure-Works.com',

        @body = 'Don''t forget to print a report for the sales force.',

        @subject = 'Reminder';

GO