Методические указания по выполнению лабораторных занятий
жүктеу/скачать 3,94 Mb.
|
Технология проектирования программных систем
- Бұл бет үшін навигация:
- Лекция № 6. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ 6.1. Основы функционального анализа и проектирования систем 6.2. Назначение и состав методологии SADT (IDEF0)
- 6.3. Элементы графической нотации IDEF0 6.4. Типы связей между работами 6.5. Правила и рекомендации построения диаграмм IDEF0
- 6.9. Элементы графической нотации DFD 6.10. Правила и рекомендации построения DFD 6.11. Пример построения модели DFD для системы определения допускаемых скоростей
- 6.12. Расширения DFD для систем реального времени 6.1. Основы функционального анализа и проектирования систем
- 6.2. Назначение и состав методологии SADT (IDEF0)
| Вопросы для самопроверки
1. Дайте определение понятиям «CASE-технология» и «CASE-система». 2. Перечислите основные возможности (функции) CASE-средств. 3. Назовите две главные цели использования CASE-технологий. 4. В чем заключается отличие структурного подхода к анализу и проектированию информационных систем от объектно-ориентированного? 5. В чем заключается сущность структурного подхода к анализу и проектированию информационных систем? 6. Перечислите основные методологии структурного подхода. Лекция № 6. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ 6.1. Основы функционального анализа и проектирования систем 6.2. Назначение и состав методологии SADT (IDEF0) 6.3. Элементы графической нотации IDEF0 6.4. Типы связей между работами 6.5. Правила и рекомендации построения диаграмм IDEF0 6.6. Пример построения модели IDEF0 для системы определения допускаемых скоростей 6.7. ICOM-коды 6.8. Назначение и состав DFD 6.9. Элементы графической нотации DFD 6.10. Правила и рекомендации построения DFD 6.11. Пример построения модели DFD для системы определения допускаемых скоростей 6.12. Расширения DFD для систем реального времени 6.1. Основы функционального анализа и проектирования систем Перед разработкой системы (лекцию 4) заказчик и разработчик должны ясно представлять, какие функциональные возможности будут заложены в систему и как будет организовано функциональное взаимодействие внутри системы. При разработке функциональной модели (определении функциональных требований) может возникнуть множество проблем: заказчик не может точно выразить, решение каких задач возлагается на информационную систему. Зачастую заказчик даже не знает, что такое требование и как его формулировать; представители заказчика (начальники разных уровней, эксперты-технологи, рядовые пользователи) по-своему видят работу будущей системы и часто их требования к системе носят взаимоисключающий характер. Особенно характерна такая ситуация, когда разрабатываемая система будет внедряться на нескольких объектах автоматизации; заказчик зачастую не знает возможностей современных вычислительных систем и стремится рассматривать процесс автоматизации как простой перенос элементарных видов деятельности, выполняемых вручную, на компьютеры. При этом он не задумывается об оптимизации бизнес-процессов внутри организации с приходом новых технологий; заказчик не верит в возможность выполнения некоторых функций «бездушными» машинами. Построение функциональной модели должно решить большую часть этих проблем. Наиболее подробно этот процесс рассмотрен в [18, 19]. При ее разработке сначала строится модель существующей организации работы AS-IS (как есть) на основе должностных инструкций, приказов, отчетов, нормативной документации и т. д. Она позволяет выяснить, «что мы делаем сегодня» перед тем, как «перепрыгнуть» на то, «что мы будем делать завтра» [18, 19]. Анализ модели позволяет понять, где находятся слабые места, в чем будут состоять преимущества новых процессов и насколько глубоким изменениям подвергнется существующая организация деятельности предприятия (компании, отдела). Признаками неэффективной организации деятельности могут быть: бесполезные, неуправляемые и дублирующие работы; работы без результата; неэффективный документооборот (нужный документ не оказывается в нужное время в нужном месте) и т. д. Найденные в модели недостатки исправляются при создании модели TO-BE (как будет) – модели новой организации работы предприятия. Модель TO-BE нужна для анализа альтернативных путей решения задачи и выбора наилучшего из них. Следует указать на распространенную ошибку при создании модели TO-BE – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD-BE (как должно было быть). Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу «все оставить как есть, только чтобы компьютеры стояли», т. е. система будет автоматизировать несовершенные бизнес-процессы и дублировать, а не заменять существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и их сопровождение. Построение системы на основе модели SHOULD-BE приводит к тому, что такая система просто не будет использоваться. Таким образом, наиболее эффективная технология построения функциональной модели заключается в разработке модели TO-BE на основе предварительно построенных моделей AS-IS и SHOULD-BE. В настоящее время двумя наиболее популярными методологиями построения функциональных моделей являются SADT и DFD. 6.2. Назначение и состав методологии SADT (IDEF0) Методология SADT (Structured Analysis and Design Technique – методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы. Начало разработки данной методологии было положено Дугласом Россом (США) в середине 60-х гг. ХХ в. С тех пор системные аналитики компании SofTech, Inc. улучшили SADT и использовали ее в решении широкого круга проблем. Программное обеспечение телефонных сетей, диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, обучение персонала, управление финансами и материально-техническим снабжением – вот некоторые из областей эффективного применения SADT. Широкий спектр областей указывает на универсальность и мощь методологии SADT. В программе «Интеграции компьютерных и промышленных технологий» (Integrated Computer Aided Manufacturing, ICAM) Министерства обороны США была признана полезность SADT. Это привело к публикации ее части в 1981 г., называемой IDEF0 (Icam DEFinition), в качестве федерального стандарта на разработку программного обеспечения. Под этим названием SADT стала применяться тысячами специалистов в военных и промышленных организациях [15]. Последняя редакция стандарта IDEF0 была выпущена в декабре 1993 г. Национальным институтом по стандартам и технологиям США (National Institute Standards and Technology, NIST). Стоит отметить, что IDEF0 рекомендована для использования Госстандартом РФ и активно применяется в отечественных госструктурах (например, в Государственной налоговой инспекции РФ). Данная методология при описании функционального аспекта информационной системы конкурирует с методами, ориентированными на потоки данных (DFD). В отличие от них IDEF0 позволяет: описывать любые системы, а не только информационные (DFD предназначена для описания программного обеспечения); создать описание системы и ее внешнего окружения до определения окончательных требований к ней. Иными словами, с помощью данной методологии можно постепенно выстраивать и анализировать систему даже тогда, когда трудно еще представить ее воплощение. Таким образом, IDEF0 может применяться на ранних этапах создания широкого круга систем. В то же время она может быть использована для анализа функций существующих систем и выработки решений по их улучшению. Основу методологии IDEF0 составляет графический язык описания процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Модель (AS-IS, TO-BE или SHOULD-BE) может содержать 4 типа диаграмм [14, 15, 18, 19]: контекстную диаграмму; диаграммы декомпозиции; диаграммы дерева узлов; диаграммы только для экспозиции (for exposition only, FEO). Контекстная диаграмма (диаграмма верхнего уровня), являясь вершиной древовидной структуры диаграмм, показывает назначение системы (основную функцию) и ее взаимодействие с внешней средой. В каждой модели может быть только одна контекстная диаграмма. После описания основной функции выполняется функциональная декомпозиция, т. е. определяются функции, из которых состоит основная. Далее функции делятся на подфункции и так до достижения требуемого уровня детализации исследуемой системы. Диаграммы, которые описывают каждый такой фрагмент системы, называются диаграммами декомпозиции. После каждого сеанса декомпозиции проводятся сеансы экспертизы – эксперты предметной области указывают на соответствие реальных процессов созданным диаграммам. Найденные несоответствия устраняются, после чего приступают к дальнейшей детализации процессов. Диаграмма дерева узлов показывает иерархическую зависимость функций (работ), но не связи между ними. Их может быть сколько угодно, поскольку дерево можно построить на произвольную глубину и с произвольного узла. Диаграммы для экспозиции строятся для иллюстрации отдельных фрагментов модели с целью отображения альтернативной точки зрения на происходящие в системе процессы (например, с точки зрения руководства организации). жүктеу/скачать 3,94 Mb. Достарыңызбен бөлісу:
|