Классификация case методологий

Исторически информационная система может быть представлена как БД и СУБД тогда имеются средства описания БД и СУБД.

Для описания системы управления используются методологии функционального моделирования (часть методологий структурного системного анализа ССА) к ним относят диаграммы потоков данных и подгруппы методологий.

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

В случае объектного представления и унифицированный язык моделирования. Дальнейшее описание case методологий осуществляется idef представляет собой группу методологий из 14 слабо связанных между собой составляющих и предназначенную для описания различных аспектов системы. Сведем в таблицу

Таблица

IDEF	Function modeling
Idef1 Idef2 Idef1x Idef3 Idef4 Idef5 Idef6 Idef7 Idef8 Idef9 Idef10 Idef11 Idef12 Idef13 Idef14	Information modeling Simulation modeling Data modeling Process description modeling Object –oriented design Ontology description capture Design rationale captupe Information system audi t method User interface modeling Scenario – driven info sys design spec Implementation architecture modeling Information artifact modeling Organization modeling Three schema mapping design Network design	Информационное моделирование Иннтотационное моделирование Моделирование данных Описание процесса проектирование Объектно ориентированное проектир. Антология описания проекта Разработка логического обоснования Метод проверки информационных систем Моделирование интерфейса пользователя Управляемая сценарием информация Моделирование архитектуры выполнения Моделирование экспоната информации Моделирование организации Тройная схема отображения проекта Проектирование сетей

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

Bmp – модель бизнес процесса

Spm – модель процесса систем

Ipm – модель представления интерфейса

Pds – структура первичных данных

Isa – архитектура ИС

Ism – модель спецификации интерфейса

Cdm – концептуальная модель данных

Adm – модель данных приложений

Рисунок

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

Эти технологии обеспечены инструментальными средствами моделирования бизнес процессов. Технология data ram основывается на структурном анализе. Структурный анализ это метод исследования системы, начинается с общего обзора и затем детализируется приобретая иерархическую структуру со все большим числом уровней. Технология rub основывается на объектно ориентированном моделировании. Оно подразумевает описание статической структуры системы в терминах объектов и связей между ними, о поведении системы описывается в терминах обмена сообщениями между объектами. Каждый объект обладает своим собственным поведением моделирующим поведение объекта реального мира. Существует aris это управляемые событиями модели.

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

1)иллюстрирующих функций которые должна выполнять система

2)иллюстрирующая отношение между данными.

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

DFD (data flow diagram)

ERD (eating relution diagram)

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

Рисунок

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

Case методологии ориентированные на описание процессов

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

DFD являются основным средством моделирования функциональных требований проектируемой системы, эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети связанной потоками данных. Главная цель таких средств продемонстрировать как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между процессами. Для изображения DFD традиционно используются 2 нотации:

1)Gane Sarson

2)Yourdan

В примерах будем использовать нотацию Gane Sarson.

Модель системы

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

1)почему этот процесс должен быть смоделирован

2)что должна показывать модель

3)что может получить читатель

Точка зрения view point это взгляд человека который видит систему, в нужном для моделирования аспекте (описание системы с точки зрения технолога и финансиста резко различаются.

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

Чтобы документировать альтернативные точки зрения, используются диаграммы FEO.

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

Основные символы

Потоки данных – являются механизмами для моделирования передачи информации (или физических компонентов) из одной части системы в другую. Ориентация стрелки указывают направление движения информации. Если процесс двунаправленный то используются либо две стрелки разноправленные, либо однно направленные. Назначение процесса состоит в продуцирование выходных потоков из входных, в соответствие с действием задаваемым именем процесса. Это имя должно содержать глагол в неопределенной форме с последующем дополнением (сдать зачет о ОПАИС). Кроме того каждый процесс должен иметь уникальный номер для ссылок на него, внутри диаграммы, этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных позволяет на определенных участках определять данные которые будут сохраняться в памяти между процессами. Фактически хранилище представляет срезы потоков данных во времени. Информация которую они содержат может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно было идентифицировать его содержимое и быть существительным. В случае когда поток данных входит или выходит из хранилища и его структура соответствует структуре хранилища, он должен иметь тоже имя которое не отражают на диаграмме. Внешняя сущность (терминатор) представляет сущность вне контекста системы, являющуюся источником или приемником системных данных. Ее имя должно содержать существительное, например, склад сотовых телефонов. Предполагается что объекты представленные такими узлами не должны участвовать ни в какой обработке.