Case-технологии и case-средства. Модели as-is и to be
Про CASE-технологии то же самое, что и в предыдущем вопросе.
CASE-средство — программное средство, поддерживающее процессы ЖЦ ПО,
включая анализ требований к системе, проектирование прикладного ПО и баз данных,
генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.
Основные особенности CASE-средств:
■ наличие мощных графических средств для описания и документирования системы, обеспечивающих удобный интерфейс и развивающих творческие возможности разработчика;
■ интеграция отдельных компонентов CASE-средств, обеспечивающая управляемость процессом разработки;
■ использование специальным образом организованного хранилища проектных метаданных (репозитория).
BPwin — позволяет аналитику создавать сложные модели бизнес-процессов и поддерживает три методологии — IDEFO, IDEF3 и DFD. Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работы изображаются в виде прямоугольников (блоков), данные — в виде стрелок (дуг). Erwin — средство концептуального моделирования БД, использующее методологию IDEF1X. Erwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД и реинжиниринг существующей БД.
Модели AS-IS и TO-BE bpwin.
Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет определить:наиболее слабые места преимущества новых бизнес-процессов , глубину изменений, которым подвергнется существующая структура организации бизнеса.
Признаками неэффективной работы деятельности могут быть:бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот, отсутствие обратных связей по управлению, отсутствие обратных связей по входу
Найденные в модели AS-IS недостатки можно исправить при создании модели TO-BE (как будет) - модели новой организации бизнес-процессов. Модель TO-BE нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.
Технология проектирования ИС подразумевает сначала создание модели AS-IS, затем ее анализ и улучшение бизнес-процессов, т.е. создание модели TO-BE. И только на основе модели TO-BE строится модель данных, прототип и затем окончательный вариант ИС.
Основные понятия и классификация case-технологий. Функционально-ориентированное и объектно-ориентированное проектирование ис.
CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимоувязанных средств автоматизации. CASE-технология - это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО.
Достоинства и возможности:
Единый графический язык.
Единая БД проекта.
Поддержка коллективной разработки и управления проектом.
Макетирование.
Генерация документации.
Верификация проекта.
Автоматическая генерация объектного кода.
Сопровождение и реинжиниринг.
При использовании CASE-технологий изменяются все фазы жизненного цикла ИС, причем наибольшие изменения касаются фаз анализа и проектирования.
CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа
средства анализа и проектирования
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных
средства разработки приложений.
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Основными идеями функционально-ориентированной CASE технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем: декомпозиция всей системы на некоторое множество иерархически подчиненных функций;представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически.В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:BFD (Bussiness Function Diagram) - диаграмма бизнес - функций (функциональные спецификации);DFD (Data Flow Diagram) - диаграмма потоков данных;STD (State Transition Diagram) - диаграмма переходов состояний (матрицы перекрестных ссылок);ERD (Entity Relationship Diagram) - ER-модель данных предметной области (информационно-логические модели "сущность-связь");SSD (System Structure Diagram) - диаграмма структуры программного приложения.
Объе́ктно-ориенти́рованное проектирование (ООП) — это часть объектно-ориентированной методологии, которая предоставляет возможность программистам оперировать понятием «объект», нежели понятием «процедура» при разработке своего кода. Объекты содержат инкапсулированные данные и процедуры, сгруппированные вместе, отображая т.о. сущность объекта. «Интерфейс объекта», описывает взаимодействие с объектом, то, как он определен. Программа, полученная при реализации объектно-ориентированного исходного кода, описывает взаимодействие этих объектов.
16. Методология SADT. Функциональное моделирование бизнес-процессов в AllFusion Process Modeler (BPwin).
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
• графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
• строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
• связность диаграмм (номера блоков);
• уникальность меток и наименований (отсутствие повторяющихся имен);
• синтаксические правила для графики (блоков и дуг);
• разделение входов и управлений (правило определения роли данных).
• отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
AllFusion Proces Modeler (Bpwin) – мощный инструмент функционального моделирования для анализа, документирования и понимания сложных бизнес-процессов.
Функциональное моделирование полезно для:
Ясного восприятия деятельности компании;
Устранение избыточных или ненужных функций;
Сокращения затрат деятельности;
Совершенствования работы компании;
Повышения качества продукции и обслуживания клиентов;
Формирования функциональных требований для внедряемых автоматизированных информационных систем
AllFusion Process Modeler поддерживает три методологии из многочисленного семейства IDEF. Речь идет о стандартах:
IDEF0 – функциональное моделирование,
IDEF3 – моделирование потока работ,
DFD – моделирование потока данных (методология, дополняющая IDEF-стандарты).
17.Стандарт структурного функционального моделирования IDEF0.
IDEF0 - методология функционального моделирования. С помощью наглядного графического языка IDEF0, изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков - в терминах IDEF0). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы;
В основе методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении.
Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом(стрелки, которые упираются в прямоугольник):
Верхняя сторона имеет значение “Управление” (Control);
Левая сторона имеет значение “Вход” (Input);
Правая сторона имеет значение “Выход” (Output);
Нижняя сторона имеет значение “Механизм” (Mechanism).
Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе.
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.
18. Моделирование потоков данных в нотации DFD
Диаграммы потоков данных (Data Flow Diagrams, DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого преобразования – продемонстрировать, как каждый процесс преобразует входные данные в выходные, а также выявить отношения между этими процессами.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Внешняя сущность – это материальный объект или физическое лицо, источник или приемник информации (например, заказчики, персонал, поставщики, клиенты, склад). Внешняя сущность находится за пределами границ системы. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входные документов и выпуск отчетов; программа; аппаратно реализованное логическое устройство и т.д. Имя процесса – предложение с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже. Например, «Ввести сведения о налогоплательщиках», «Выдать информацию о текущих расходах», «Проверить поступление денег». Накопитель данных – это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь. Способы помещения и извлечения могут быть любыми. Накопитель данных в общем случае является прообразом будущей базы данных. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами или дискетами, переносимыми с одного компьютера на другой и т.д. Поток данных изображается на диаграмме линией со стрелкой, которая показывает направление потока. Каждый поток данных имеет имя, отражающее его содержание.
