Аспект  представляется колонкой таблицы. Мы связываем  аспект данных с моделями данных, аспект функций с функциональными моделями и аспект сетей - с сетевыми моделями. Иными словами, мы связываем аспекты разных объектов с соответствующими объектными моделями.

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

Наконец, схема Захмана является контекстом для изучения различных взглядов на одну и ту же систему. Схема поддерживает множество взглядов, отражающих разные аспекты конечного продукта. Эти  взгляды важны для разных людей  и созданы с их точек зрения. Схема представляет всем участникам CASE-проекта контекст для описания информационной системы на понятном и приемлемом для каждого участника языке.  

1.5 Дополнение схемы

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

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

Наилучшим решением было бы использование для  столбцов названий "что", "как", "где", "кто", "когда" и "почему", но даже такая схема не будет универсальной. Потеря универсальности может быть большей или меньшей в зависимости от того, насколько конкретный смысл мы вкладываем в каждый из аспектов.

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

Название  нижней строки таблицы может варьироваться. Если можно определить одну или несколько  точек зрения (например, точку зрения оператора системы), которые будут сильно отличаться от точек зрения проектировщика, разработчика или владельца, то название "функционирование системы" является вполне уместным.

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

1.6 Замечания о полноте.

При использовании схемы в качестве вспомогательного инструмента необходимо понимать, полностью ли покрывает рассматриваемая схема все архитектурные представления системы. Другими словами, требуется четкое понимание того, все ли аспекты системы покрываются множеством аспектов схемы. Если схема полна, добавление столбца должно выразиться в удалении из всех остальных столбцов аспектов системы, затрагиваемых новым столбцом. Например, если мы добавляем столбец "правила", то все, что касается правил, должно быть исключено из других столбцов; другие столбцы должны быть переопределены, чтобы избежать дублирования информации.

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

1.7 Интеграция схемы Захмана с методами моделирования бизнеса.

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

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

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

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

Рис.2. Инструментальные средства.

Каждая  из перечисленных на Рис. 2 методик, кроме последней, имеет программную поддержку. Семейство методологий IDEF является альтернативой использования некоторых средств Oracle CASE*Method. Прочерк в строке, соответствующей методике CM, указывает на отсутствие методологических стандартов. Эта методика используется в различных проектах в зависимости от ситуации. Схема применения методики создается в организации, выполняющей заказ по созданию системы, на основе накопленного опыта работы. Построим теперь схему Захмана, основанную на семи перечисленных аспектах и различных точках зрения (рис. П8 и П9)

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

Глава 3. Разработка модели бизнес-процессов организации в среде BPwin

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

Все это позволяет осуществить CASE-средство BPwin.

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

    Рассматриваемый нами ОКФ осуществляет следующие операции:

1. обслуживание клиентов;
2. гарантийный и платный ремонт;
3. замена товара;

    Каждая  из этих операций является бизнес-процессом  и детализирует основную деятельность ОКФ.

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

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

В качестве управляющего воздействия выступают  нормативные документы по ремонту компьютерной техники и оказанию услуг.

Выходом модели являются выполненные операции.

2.1 Построение модели бизнес-процесса в нотации IDEF0

    Модель  в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм.

Основанием  модели является контекстная диаграмма, абстрактно описывающая диаграмму в целом (рис. 3.1).

    Рис.3 Контекстная диаграмма

Далее я декомпозировал деятельность предприятия на четыре бизнес – процесса, а именно: прием неисправной техники, ведение ремонтных работ,  тестирование и выдача техники клиенту, склад. Графическое изображение представлено на  рис. 3.2.

    Рис. 3.1 Декомпозиция контекстной диаграммы 

 
 

Далее подробно рассматривается декомпозиция работы «Ведение ремонтных работ» (рис. 3.3), остальные диаграммы декомпозиции в приложениях. Данная диаграмма содержит в себе : выявление поломки, ремонт поломки, замена деталей и возврат производителю.

 Рис. 3.2 Декомпозиция работы «Ведение ремонтных работ»

 

 Далее декомпозируем работу «Ремонт техники » (рис. 3.4).

 Рис. 3.3 Диаграмма «Ремонт техники»

 
 
 
 
 
 

Далее подробнее рассмотрим работу «Ремонт  прочих компьютерных устройств» (Рис. 3.5.), т.к. для ремонта используются разное оборудование и технологии. 

 Рис. 3.4 Диаграмма «Ремонт прочих компьютерных устройств» 
 
 
 
 
 
 

2.2 Построение диаграммы узлов и FEO диаграммы