Схема Захмана: представление архитектуры информационной системы

Автор работы: Пользователь скрыл имя, 24 Марта 2011 в 13:55, курсовая работа

Описание работы

Проект по созданию сложной ИС не возможно реализовать в одиночку. Коллективная работа существенно отличается от индивидуальной, поэтому при реализации крупных проектов необходимо иметь средства координации и управления коллективом разработчиков.

Содержание работы

Введение………………………………………………………………..………..…..5
Глава 1. Экономические информационные системы…………………………6
1.1 Понятие и классификация ЭИС…………………………………………….6
1.2 Жизненный цикл ЭИС……………………………………………..……....13
Глава 2. Схема Захмана представление архитектуры ИС………….………...22
1.1Точки зрения…………………………………………………..……......….23
1.2 Аспекты…................................................................................................25
1.3 Названия строк и столбцов………………………………………………25
1.4 Характеристика взгляда……………………………………………….….27
1.5 Дополнение схемы………………………………………………………...28
1.6 Замечания о полноте…………………………………………………......29
1.7 Интеграция схемы Захмана с методами моделирования бизнеса...........30
Глава 3. Разработка модели бизнес-процессов организации в среде BPWin.32
3.1 Построение модели бизнес-процесса в нотации IDEF0………………....33
3.2 Построение диаграммы узлов и FEO диаграммы………………………..38
3.3 Построение IDEF3 диаграммы…………………………………………….40
3.4 Построение DFD-диаграммы……………………………………………...41
3.5 Стоимостной анализ………………………………………………………..41
3.6 Реинжиниринг бизнес-процесса(модедь TO-BE)………………………...43
Глава 4. Разработка информационной модели организации в среде ERWin………………………………………………………………………………..45
4.1 Проектирование логической модели базы данных…………....………………45
Заключение………………..……………………………………….………………..48
Список использованной литературы………………………………..…………..49

Файлы: 1 файл

Курсач2.doc

— 1.92 Мб (Скачать файл)

Спиральная  модель. Используется подход к организации  проектирования ЭИС «сверху-вниз», когда сначала определяется состав функциональных подсистем, а затем постановка отдельных задач. Соответственно сначала разрабатываются такие общесистемные вопросы, как организация интегрированной базы данных, технология сбора, передачи и накопления информации, а затем технология решения конкретных задач. В рамках комплексов задач программирование осуществляется по направлению от головных программных модулей к исполняющим отдельные функции модулям. При этом на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с базой данных, а на второй план - реализация алгоритмов.

    В основе спиральной модели жизненного цикла лежит применение прототипной технологии или КАО-технологии (rapid application development - технологии быстрой разработки приложений) - J. Martin. rapid application development. New York: Macmillan, 1991. Согласно этой технологии ЭИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при прототипной технологии сокращается число итераций и меньше возникает ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование ЭИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ЭИС все большее значение придается ведению общесистемного репозитория и использованию САSЕ-технологий (см. гл. 13).

    Жизненный цикл при использовании КАО-технологии предполагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает четыре основные стадии информационного инжиниринга:

    •  анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области;

    •  проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков;

    •  конструирование. Специалисты-разработчики проектируют рабочую версию ЭИС с использованием языков 4-го поколения;

    •  внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ЭИС. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Глава 2. Схема Захмана представление архитектуры ИС 

В 1987 году Джон Захман опубликовал полезную схему  развития архитектуры информационной системы. Захмановская схема создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видят систему ее заказчик, проектировщик и разработчик, причем в разрезе трех выбранных аспектов. Эти три аспекта: данные, функции и сетевая структура. В схеме Захмана строке соответствует точка зрения какого-либо участника проекта по созданию системы. Аспекты представлены в схеме колонками.

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

Захман  определяет архитектуру как представление  конечного продукта (в данном случае информационной системы) с точки  зрения одного из заинтересованных лиц. Таким образом, существует не одна архитектура, а некое множество архитектур. В зависимости от того, кем вы являетесь и на каком аспекте фокусируете внимание, вы видите архитектуру системы по-разному. В следующих пяти разделах приводится более развернутое описание подхода Захмана. Изложение сделано на основе (П7). 
 
 
 
 

    1. Точки зрения

Точки зрения отражают значение и области  ответственности заинтересованных лиц в процессе создания системы. Заказчик видит систему с точки  зрения общих стратегических и тактических аспектов. Эти аспекты могут лежать в очень широкой области (бизнес в целом или, напротив, его часть) и не всегда могут быть определены точно. Архитектурные представления, соответствующие точке зрения заказчика, находятся в двух верхних строках таблицы. Начальное планирование бизнеса и анализ обычно определяют первые уровни детализации для этих архитектурных представлений. Определенно установленные цели бизнеса и его требования к системе полностью детализируют каждое из представлений.

Представления проектировщика, несмотря на то, что  рассматривается одна и та же система, существенно отличаются от представлений  заказчика, причем не только дополнительными  деталями. Представления проектировщика - это проект системы, обеспечивающей удовлетворение требований, которые, в свою очередь, описываются представлениями заказчика. Во многом представление проектировщика добавляет точность, необходимую для тех, кто будет реализовывать систему, но представления проектировщика и заказчика остаются независимыми от технологий, которые будут использоваться при реализации. Структурный анализ, информационное моделирование и некоторые виды прототипирования являются методами, которые могут быть использованы для формирования архитектурного представления проектировщика. Точке зрения проектировщика соответствует третья строка в схеме Захмана.

Проекты, связанные с созданием систем, наиболее успешны, когда компоненты каждого из технологически независимых  взглядов, соответствующие данным, функциям и сетевой структуре (три верхних строки) разрабатываются одновременно командой, хорошо понимающей бизнес и имеющей опыт в разработке приложений и сетей, а также в администрировании данных. Хотя каждый участник может представлять свою точку зрения (заказчик или проектировщик) или фокусироваться на своих аспектах (данные, функции или сети), каждый вносит свой набор знаний. Эти наборы знаний в совокупности дают хорошую общую картину требуемой системы. В достаточной степени проектировщики должны понимать точку зрения заказчика и наоборот. Заказчик и проектировщик не могут развивать свои взгляды независимо. Физическое воплощение логических требований зависит от характеристик аппаратно-програмной базы, выбранной для реализации системы. В отличие от желаемых логических связей, реальные связи зависят от физических ограничений. Таким образом, необходимо знать, что мы хотим, перед тем, как делать вывод о невозможности чего-либо. Технология ограничивает решения задач, а не их условия.

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

Существует  еще одна отдельная точка зрения оператора системы. Деятельность оператора - это, с одной стороны, ежедневная поддержка работоспособности системы и ее мониторинг, с другой - повседневное использование системы в бизнесе. Точка зрения оператора представлена последней строкой схемы.

Важно помнить, что строки схемы представляют разные точки зрения, а не разные уровни детальности представления. Для каждой ячейки таблицы может быть сделано многоуровневое описание. Необходимо понимать, что могут быть ситуации, в которых важно понятие взгляда, то есть совокупности архитектурных представлений, находящихся в пределах одной строки. Разным строкам соответствует разное понимание предмета. Чтобы сформировать взгляд, отражающий другую точку зрения, необходим некий переход.

1.2 Аспекты

Три аспекта, рассмотренных в схеме, приводят к различным архитектурным представлениям каждой из точек зрения. Аспекты соответствуют вопросам "что", "как" и "где", относящимся к конечному продукту (информационной системе). Каждому аспекту соответствуют разные методы формирования представления.

Колонка данных соответствует вопросу "что". В строительной промышленности, например, она соответствует списку материалов и частей, используемых при строительстве  здания, и взаимосвязям между этими  частями. Внимание концентрируется  на том, из чего строится здание, а не как и где оно строится. Для информационных систем вопрос "что" относится к сущностям данных и их связям.

Колонка функций соответствует вопросу "как". Она описывает, как работают отдельные  части системы. В информационных системах функции обычно определяются входами (элементы данных), процессами (преобразования) и выходами (элементы данных). Внимание уделяется не столько отдельным частям и их связям, сколько тому, как эти части взаимодействуют при выполнении общей задачи.

Колонка сетевой структуры соответствует вопросу "где". Архитектурные представления в этой колонке описывают местоположение элементов системы и механизмы их взаимодействия.  

1.3 Названия строк и столбцов

Схема Захмана является простым, но достаточно мощным средством. Эта мощность особенно хорошо видна при попытке ее расширения. В этом разделе приведены краткие дополнительные соображения о схеме, а также некоторые моменты, о которых следует помнить при ее использовании.

Важно понимать, что схема Захмана не является каким-либо алгоритмом действий, она лишь направляет наши соображения по нужному пути. Благодаря своей простоте, схема позволяет понять, как должна быть спроектирована и разработана информационная система, не только в терминах методов проектирования и разработки, но и в терминах набора элементов системы.

При использовании  схемы Захмана требуется четко  представлять, что означают строки и столбцы в таблице. В каждой ячейке представлен вид конечного продукта (архитектурное представление) с точки зрения некоторой группы лиц, участвующих в разработке системы. Строки представляют их точки зрения, и хотя процесс разработки системы является последовательным выполнением действий, характерных для каждой из этих групп (от заказчика к проектировщику, от проектировщика к разработчику), Захман выступает против рассмотрения строк как уровней детальности представления.

Важное  замечание по поводу архитектурных представлений состоит в том, что все они имеют различную природу. Это не просто набор представлений, уровень детальности которых увеличивается с прохождением каждого нового этапа. Уровень детальности - это независимая переменная, меняющаяся внутри каждого архитектурного представления.

Здесь используются следующие термины  описания строк. Строка является точкой зрения. Точка зрения отражает область  интереса или ответственности группы заинтересованных лиц. Все точки  зрения относятся к одному и тому же продукту. Они согласуются с понятием взгляда заказчика, проектировщика и разработчика. Таким образом, точки зрения разных участников проектной группы различаются. Взгляд охватывает часть ячейки, всю ячейку или несколько ячеек в пределах одной строки. Взгляд может быть порожден любой точкой зрения (хотя он может быть шире или уже по размеру предметной области) и может быть представлен на любом подходящем уровне детальности. Взгляд отражает интересы конкретного участника проекта, ограниченные рамками выбранных аспектов.  
 
 

1.4 Характеристика взгляда состоит из двух частей:

Описание  взгляда, включающее:

  • Точку зрения (статус человека, имеющего данный взгляд);
  • Что показывает взгляд (аспект);
  • Техника или язык, описывающий данный взгляд (например, IDEF1X для аспекта данных, IDEF0 или диаграмма потока данных для функционального аспекта);
  • Уровень детальности (высокий или низкий);
  • Предметную область (узкая или широкая);
  • Предполагаемое использование (как будет использоваться взгляд);
  • Пользователя (кто будет использовать взгляд);
  • Граничные предположения (предположения по поводу интеграции этого взгляда с другими).
 

Управляющая информация о взгляде:

  • Как был разработан взгляд;
  • С кем контактировать для управления изменениями;
  • Статус (насколько взгляд полон и насколько определен);
  • Составные части (например, диаграммы, глоссарии, тенденции, критические для успеха факторы).

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

Информация о работе Схема Захмана: представление архитектуры информационной системы