Парадигмы CASE-технологии. Жизненный цикл ИС.

Прадигмы:

 

Методолгоия.

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

 

Метод.

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

 

Нотация.

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

 

Средства.

Инструментарий для поддержки и усиления методов.

 

Жизненный цикл ИС:

 

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

CASE-средство – программное средство, поддерживающее процессы ЖЦ ПО, определенные в стандарте ISO/IEC 12207:1995.

Традиционно выделяются следующие основные этапы ЖЦ ПО:

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

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

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

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

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

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

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

Проектирование

Кодирование

Тестирование

Эксплуатация

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

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

 

Процессы: основные, вспомогательные, организационные. Модели реализации ИС.

 

Процессы:

 

Приобретение (Заказ)

Поставка

Разработка

Эксплуатация

Сопровождение

 

Модели реализации ЖЦ ИС:

 

Каскадная модели:

 

Анализ требований (сбор требований к продукту) => проектирование (описание внутренней структуры, диаграммы, тексты) => реализация (программирование, интеграция) => тестирование => внедрение => сопровождение.

 

Спиральная модель:

 

Анализ => проектирование => реализация и тестирование => выполнять более одного раза.

 

Положительные стороны каскадного подхода:

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

 

Спиральные и инкрементные процессы:

Барии Боен.

Необходимость предупреждения рисков.

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

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

Минусы:

Требуется более искусное управление.

Необходимость поддержки целостности документации в конце каждой версии.

Трудность в определении момента перехода на следующий этап.

Переход осуществляется в соответствии с планом, даже если не все работы выполнены.

 

Типичный проект – это, трудоемкость которого оценивается в 3 человека месяца. Затраты на проведение большого числа шагов могут превысить выгоду от дополнительных итераций.

 

Структурный и объектно-ориентированный подход к разработке ИС: достоинства и недостатки. Принципы структурного подхода (СП).

 

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

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

 

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

Методологии СП. 3 группы моделей.

 

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

 функции, которые система должна выполнять (функциональное моделирование);

 отношения между данными (информационное моделирование);

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм):

 Функциональное моделирование: DFD (Data Flow Diagrams) – диаграммы потоков данных, IDEF0 (Integrated DEFinition) – функциональная модель;

 Информационное моделирование: ERD (Entity Relationship Diagrams) – диаграммы “сущность - связь”;

 Динамическое моделирование: STD (State Transition Diagrams) – диаграммы переходов состояний, IDEF3 (Work Flow Diagrams), IDEF0 PN (Petri Network) – сети Петри.

В рамках данного цикла рассмотрим IDEF0, DFD, IDEF3 –модели и возможность получения ERD-модели по DFD или IDEF0-модели.

 

DFD-моделирование. Основные компоненты. Примеры DFD-модели.

 

Диаграммы потоков данных (DFD, Data Flow Diagrams) являются основным средством моделирования функциональных требований проектируемой системы. C их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.

Для изображения DFD традиционно используется две различные нотации: Йордана и Гейна-Сарсона. Далее при построении будет использоваться нотация Гейна-Сарсона.

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

Методология структурного анализа и проектирования базируется на интеграции следующих средств:

Ø DFD-диаграмм потоков данных, которые являются графическими иерархическими спецификациями (описаниями) систем с позиций потоков данных. Основные символы DFD в нотации Гейна-Сарсона приведены в таблице 1.

Таблица 1. Нотация Гейна-Сарсона.

Компонент	Графическое представление	Назначение
Поток данных (Arrow)		Потоки данных описывают движение объектов из одной части системы в другую.
Процесс (Activity)		Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.
Хранилище (Data Store)		Хранилище данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами.
Внешняя сущность (External Reference)		Внешняя сущность представляет сущность вне контекста системы, являющуюся источником или приемником данных системы. Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.

 

Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те в свою очередь преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, хранилищам данных (ХД) или внешним сущностям - потребителям информации. Потоки могут подходить и выходить из любой грани прямоугольника работы и могут быть двунаправленными для описания взаимодействия типа “запрос-ответ” (рис.2.2).

Рис.2.2. Взаимодействие типа “запрос-ответ ”.

Ø Словарей данных (репозиториев), использующихся для хранения метаданных (структуры потоков данных, ХД), описания их компонентов. Для определения статей словаря данных используется специальный язык Бэкуса-Наура.

Ø Спецификаций процессов, использующихся для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью DFD. Фактически спецификации процессов представляют собой алгоритмы описания задач, выполняемых процессами: множество всех спецификаций является полной спецификацией системы. Для описания тела процесса будем использовать структурированный естественный язык (СЕЯ).

 

IDEF-технология проектирования ИС. IDEF0, IDEF3-модели. Примеры.

 

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

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

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

Диаграмма является основной единицей описания в IDEF3-модели.

Единицы работы – Unit of Work (UOW), также называемые работами, являются центральными компонентами модели. Изображаются прямоугольниками и имеют имя и номер (рис.2.4).

 

 

Номер родительской работы

Номер работы

 

Рис.2.4.Изображение работы в диаграмме IDEF3.

Связи показывают взаимоотношения работ. Все связи в IDEF3 являются однонаправленными.

Таблица 2. Типы связей.

Тип связи	Графическое представление	Назначение
Временное предшествование (Temporal Precedence).		Соединяет последовательно выполняемые работы.
Нечеткое отношение (Relationship).		Используется для изображения связей между единицами работ, а также между единицами работ и объектами ссылок.
Объектный поток (Object Flow).		Применяется для описания использования объекта в двух или более единицах работы.

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

Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) потоков. Перекресток не может быть использован одновременно для слияния и разветвления.

 

Таблица 3. Типы перекрестков.

Наименование	Обозначение	Смысл в случае слияния потоков	Смысл в случае разветвления потоков
Asynchronous AND		Все предшествующие процессы должны быть завершены.	Все следующие процессы должны быть запущены.
Synchronous AND		Все предшествующие процессы должны быть завершены одновременно.	Все следующие процессы запускаются одновременно.
Asynchronous OR		Один или несколько предшествующих процессов должны быть завершены.	Один или несколько следующих процессов должны быть запущены.
Synchronous OR		Один или несколько предшествующих процессов должны быть завершены одновременно.	Один или несколько следующих процессов запускаются одновременно.
XOR (Exclusive OR)		Только один предшествующий процесс завершен.	Только один следующий процесс запускается.

 

Объекты-ссылки являются специальными символами, которые ссылаются на внешние части процесса. Они добавляются на диаграмму для того, чтобы обратить внимание на что-либо важное, что невозможно связать со стрелкой, работой или перекрестком. Официальная спецификация IDEF3 различает три стиля объектов-ссылок – безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты-ссылки. При внесении объектов-ссылок необходимо указать их тип.

 

Таблица 4. Типы объектов-ссылок.

Тип объекта-ссылки	Цель описания
OBJECT	Описывает участие важного объекта в работе.
GOTO	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток.
UOB (Unit of behavior)	Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ.
NOTE	Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму.
ELAB (Elaboration)	Используется для усовершенствования графиков или более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках.

 

Объекты-ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями.

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

Рис.2.5. Использование объекта-ссылки на диаграмме.