|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Функционально-ориентированные, объектно-ориентированные методологии
При выборе рассматривают степень динамичности. Для более регламентированных задач больше подходят функциональные модели, для более адаптивных бизнес-процессов (управления рабочими потоками, реализации динамических запросов к информационным хранилищам) — объектно-ориентированные модели. Однако в рамках одной и той же ИС для различных классов задач могут требоваться различные виды моделей, описывающих одну и ту же проблемную область. В таком случае должны использоваться комбинированные модели предметной области. Функциональная методика IDEF0 Как стандарт IDEF0 разработан в 1981, последняя редакция в 1993. Цель – построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы. В основе лежат 4 компоненты: 1) функциональный блок: конкретная функция. По стандарту название функционального блока должно быть в глагольном наклонении (н-р: производить услуги). На диаграмме изображается прямоугольником. Каждая сторона имеет свое значение (роль). 2) Интерфейсная дуга: отображает элемент, который обрабатывается функц.блоком или оказывает иное влияние на функцию (дуги называют потоками, стрелками). Это элементы реального мира (детали, вагоны..) и потоки данных и информации (документы, инструкции..). Дуги бывают: входящие, исходящие, управляющие. По стандарту любой функц.блок должен иметь хотя бы 1 управляющую (правило) и 1 исходящую дугу(результат). 3) Декомпозиция: применяется при разбиении сложного процесса на составляющие функции. Позволяет представить модель в виде иерархической структуры для легкого усвоения. 4) Глоссарий: набор определений для каждого компонента, которые характеризуют объект, отраженный данным элементом. Контекстная диаграмма – модель с 1 функц.блоком. В пояснительном тексте должна быть указана цель (важнейшие области диаграммы) и зафиксирована точка зрения (направление развития модели и уровни детализации). В процессе декомпозиции функц.блок детализируется. Диаграмма 2ого уровня – дочерняя по отношению к функц.блоку контекстной диаграммы(родительский блок). При декомпозиции функц.блока все интерфейсные дуги, входящие и выходящие из него фиксируются на дочерней, т.о. достигается структурная целостность. Туннелирование: когда нет смысла продолжать интерфейсные дуги в дочерней диаграмме. Обозначается () в начале дуги – не унаследована от родительского блока; в конце дуги – значит в дочерней рассматриваться не будет. Ограничение сложности: представлять на диаграмме 3-6 функц.блоков, кол-во входящих дуг к 1 блоку не больше 4х. Этапы разработки: - создание моделей группами специалистов из разной сферы деятельности (авторами). Сбор сведений о функциях, ответственности функций, результате – т.о. создается черновик модели. - распространение черновика для согласований, комментариев. Этап продолжается до тех пор, пока авторы и читатели не придут к единому мнению. - официальное утверждение модели. Окончательная модель представляет собой согласованное представление о системе с заданной точки зрения и для заданной цели. Функциональная методика потоков данных(Data Flow Diagram — DFD). Цель методики – построение диаграммы в виде потоков данных, обеспечивающей правильное описание выходов при заданном воздействии на вход системы. В основе 4 понятия: 1) Потоки данных: абстракции для моделирования передачи информации из 1ой части системы в другую. На диаграмме – именованные стрелки, ориентация указывает движение информации. 2) Процессы(работы) преобразования входных данных в выходные: продуцирование выходных потоков из входных. Имя процесса – глагол в НФ с дополнением (н-р: получить документы по отгрузке продукции). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы. 3) Внешние сущности: материальный объект вне системы, являющийся источником или приемником системных данных. Имя является существительным(н-р склад товаров) 4) Накопители данных(хранилища): позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Имя хранилища должно определять его содержимое и быть существительным. Кроме этих понятий входят еще словари данных(каталог всех элементов) и миниспецификации (описание процессов нижнего уровня). Процесс построения DFD начинается с создания основной диаграммы типа «звезда»-включает моделируемый процесс и все внешние уровни, с которыми он взаимодействует. Этап заключается в выборе глагола, определяющий как внешняя сущность использует основной процесс(н-р: процесс-учет обращений граждан; внешняя сущность: граждане; описание взаимодействия: подает заявление и получает ответы). Для всех внешних сущностей строится таблица событий(взаимодействие с основным потоком). Следующий этап-выделение потоков данных, которыми обмениваются процессы и их сущности. Простейший способ – анализ таблицы событий. После построения входных и выходных потоков, строятся внутренние: для этого выделяются поставщики и потребители информации. Если они представляют процесс сохранения или запроса информации – образуется хранилище. После этого диаграмма проверяется на полноту(нет «повисших процессов») и непротиворечивость (нет потока, связывающего 2 внешние сущности; ни 1 сущность не может непосредственно передавать информацию в хранилище данных и получать; 2 хранилища не могут передавать друг другу информацию) Преимущества DFD: -возможность однозначно определить внешние сущности -возможность проектирования сверху вниз -наличие спецификаций процессов нижнего уровня (преодоление незавершенности модели) Недостатки: -необходимость искусственного ввода управляющих процессов -отсутствие понятия времени Объектно-ориентированная методика Этот подход использует объектную декомпозицию: статическая структура описывается в терминах объектов связей между ними, а поведение системы – в терминах обмена сообщениями между объектами. Цель – построение бизнес-модели организации, позволяющей перейти от моделей сценариев использования к модели, определяющей отдельные объекты, участвующие в реализации бизнес-функций. Объектная модель строится с учетов принципов: абстрагирование; инкапсуляция; модульность; иерархия; типизация; параллелизм; устойчивость. Основные понятия: 1) Объект: предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. 2) Класс: это множество объектов, связанных общностью структуры и поведения. 3) Полиморфизм: способность классу принадлежать к более чем 1 типу. 4) Наследование: построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Большинство существующих методов объектно-ориентированного подхода включают язык моделирования и описание процесса моделирования. Процесс–это описание шагов, которые необходимо выполнить при разработке проекта. В качестве языка моделирования объектного подхода используется унифицированный язык моделирования UML, который содержит стандартный набор диаграмм для моделирования. Чаще всего диаграмма изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями) и представляет собой некоторую проекцию системы. Плюсы: -возможность создавать модели меньшего размера, унификация разработки, возможность вторичного использования -объектная декомпозиция избегает сложных моделей, т.к. на базе подсистем -модель естественна, т.к. ориентирована на человеческое восприятие Минусы: -высокие начальные затраты -диаграммы менее наглядны -подход не дает немедленной отдачи 3. Синтетическая методика Наилучшим способом преодоления недостатков рассмотренных методик является формирование синергетической методики, объединяющей различные этапы отдельных методик. Рассмотрим на примере(построение административных регламентов): - определение границ системы (при помощи анализа потоков данных выделяют внешние сущности и собственно моделируемую систему) - Выделение сценариев использования (при помощи критерия полезности строят для каждой внешней сущности набор сценариев) - Добавление системных сценариев использования (определяют сценарии, необходимые для реализации целей системы, отличных от целей пользователей) - Построение диаграммы активностей по сценариям использования (строят набор действий системы, приводящих к реализации сценариев использования) - Функциональная декомпозиция диаграмм активностей как контекстных диаграмм методики IDEF0 - Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций).
Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.027 сек.) |