Диссертация. Диссертация Беляшов А.Н. Факультет итс
 Скачать 1.84 Mb.
|
|
Методология BAAN – методология описания деятельности, разработанная компанией разработчиком информационных систем BAAN, содержит бизнес-модели, описание которых приведено в таблице 2.2 [46]. Таблица 2.2. Модели методологии BAAN
С помощью данных бизнес-моделей последовательно описываются функции, бизнес-процессы, организационная и информационная структура предприятия. Методология OSA (Object-Oriented System Analysis – Объектно-ориентированный системный анализ) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки [43]. Методология OSA сосредоточена только на проблемах анализа, предлагая ряд интересных соображений, связанных с объектно-ориентированным анализом систем и специально исключая из рассмотрения особенности, характерные для разработки. Предлагая удобные и тонкие методы анализа систем, методология OSA обеспечивает интерпретацию моделей на компьютере на самых ранних этапах анализа системы. Методология OSA, как и другие методологии, поддерживает три взаимно-ортогональных представления проектируемой системы: модель зависимостей между объектами; модель поведения объектов; модель взаимодействия объектов. Методология OMT (Object Modeling Technique – Технология объектного моделирования) поддерживает две первые стадии разработки программных систем [43]. Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы. Методология UML (Unified Modelling Language – Унифицированный язык моделирования) – результат довольно длинной и еще не завершившейся эволюции методологий моделирования и дизайна [43]. Данная методология преследует три основные цели: моделирование системы, начиная с концепции и заканчивая исполняемым модулем, с применением объектно-ориентированных методик; разрешение проблем масштабирования в сложных системах; создание языка моделирования, используемого и человеком, и компьютером. В настоящее время методология UML поддерживает более 10 основных видов моделей для описания бизнес-процессов предприятия. Диаграммы, описывающие поведение системы: Диаграммы состояний (State diagrams): включает в себя состояния, переходы, события и виды действий. Диаграммы прецедентов: описание бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты как системы, так и предметной области и задачи, ими выполняемые. Диаграммы деятельностей (Activity diagrams): частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы классов: позволяют создавать логическое представление системы, на основе которого создается исходный код описанных классов. Диаграммы взаимодействия (Collaboration diagrams): связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы последовательностей (Sequence diagrams): частный случай диаграммы взаимодействия, отражают временную упорядоченность сообщений. Диаграммы, описывающие физическую реализацию системы: Диаграммы компонент (Component diagrams): организация совокупности компонентов и существующие между ними зависимости; Диаграммы развертывания (Deployment diagrams): конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Можно выделить основные этапы разработки системы с использованием средств UML: описание задания в общих чертах на естественном языке; выделение прецедентов и актеров бедующей системы; определение объектов и взаимодействий между ними; детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента; группировка объектов, переход от объектов и сущностей к компонентам; ревизия результатов предыдущих этапов; детальная проработка реализации компонентов, разделение компонентов по участникам коллектива разработчиков; Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД; размещение компонентов системы; кодирование. Каждый этап поддерживается соответствующими UML-диаграммами. 2.2. Методы анализа и проектирования систем управления Каждая из методологий включает в себя набор методов графического моделирования аспектов предметной области (видов моделей, диаграмм, нотаций). Метод – способ достижения какой-либо цели, решения конкретной задачи; совокупность приёмов или операций практического или теоретического освоения (познания) действительности [3]. Метод SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) (рис. 2.2) – это метод, разработанный специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности [43]. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка – сама диаграмма SADT. Графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык организует естественный язык определенным и однозначным образом, за счет чего возможно описывать системы, которые до недавнего времени не поддавались адекватному представлению. SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы руководят созданием модели и направляют его, т. е. сама модель должна дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то говорят, что модель не достигла своей цели. Определяя модель таким образом, SADT закладывает основы практического моделирования.  Рис. 2.2. Модель SADT Модель имеет единственный субъект. Субъектом моделирования служит сама система. Она всегда связана с окружающей средой. Причем часто трудно сказать, где кончается система и начинается среда. В методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект. То есть модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов. У модели может быть только одна точка зрения. Определение модели тесно связано с позицией, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. Точку зрения лучше всего представлять как место (позицию) человека или объекта, на которое надо встать, чтобы увидеть систему в действии. Метод IDEF0 (Function Modeling – метод функционального моделирования) (рис. 2.3) предназначен для формализации и описания бизнес-процессов [45]. Отличительной особенностью IDEF0 является его акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами. Метод основан на следующих положениях. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На диаграмме IDEF0, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.  Рис. 2.3. Модель IDEF0 Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества метода в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру [42]. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования. Метод DFD (Data Flow Diagrams – диаграммы потоков данных) (рис. 2.4) представляет собой иерархию функциональных процессов, связанных потоками данных [7]. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.  Рис. 2.4. Модель DFD Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сарсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла. Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями: Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса. Не загромождать диаграммы несущественными на данном уровне деталями. Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой. Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры. Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Метод WFD (Work Flow Diagram - диаграмма потоков работ) (рис. 2.5). Этот метод включает в себя дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки [46]. С помощью логических операторов, которые еще называют блоками принятия решений, показывают альтернативы, которые происходят в процессе, показывается в каких случаях процесс протекает по одной технологии, а в каких случаях по другой. Например, с помощью данных элементов можно описать ситуацию, когда договор, стоимость которого меньше определенной суммы согласуется одной группой сотрудников, а договор с большей стоимостью согласуется по более сложной технологии, в цепочки которой участвуют большее количество сотрудников. С помощью событий начала и окончания процесса показывается, когда процесс начинается и когда заканчивается. Для жестко формализованных бизнес-процессов, например, таких, как бюджетирование, в качестве событий может выступать время. В случаях, когда описание бизнес-процесса проводится с целью его дальнейшей временной оптимизации, используют элементы задержки времени, которые показывают места, в которых между последовательно выполняемыми работами имеется временной разрыв. В данном случае последующая работа начинается только через некоторое время после завершения предшествующей. В классическом подходе WFD на данной схеме не показывают документы, так эти схемы используются для описания процессов нижнего уровня, которые содержат детальные работы, и по названию которых понятно, что является входом и что является выходом.  Рис. 2.5. Модель WFD Отличительной особенностью WFD-диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ. | ||||||||||||||||||||||||||||||