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

- принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных;

- принцип непротиворечивости - обоснованность и согласованность элементов системы;

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

Практически во всех методологиях структурного анализа используются три группы средств моделирования (нотаций):

- диаграммы, иллюстрирующие функции, которые должна выполнять система, и связи между этими функциями - для этой цели чаще всего используются нотации SADT и DFD;

- диаграммы, моделирующие данные и их взаимосвязи (диаграммы сущность-связь - ERD);

- диаграммы, моделирующие поведение системы (диаграммы переходов состояний - STD).

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

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

- мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности;

- интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

- использование специальным образом организованного хранилища проектных метаданных (репозитория).

Наиболее распространены: CASE.Аналитик, Bpwin и ERwin, EasyCASE, Designer/2000 и другие. Как правило, один отдельно взятый пакет поддерживает лишь часть видов проектной деятельности, поэтому фактически требуется сформировать своеобразную CASE-среду, т.е. комплекс CASE-средств, покрывающий весь жизненный цикл ПО.

Для выполнения данной дипломной работы в качестве инструмента был выбран программный продукт BPwin от фирмы Platinum technology/Logic Works. Он позиционируется для использования проектировщиками, аналитиками, разработчиками. Bpwin - это CASE-средство визуального проектирования информационных систем, позволяющее моделировать бизнес-процессы, реализующее метод IDEF0. Текущая версия BPwin поддерживает также диаграммы потоков данных и потоков работ.

На этапе моделирования подсистемы используются нотации SADT (Structured Analysis and Design Technique) и DFD (Data Flow Diagrams), поскольку они позволяют наиболее адекватно отобразить логику предметной области и легко воспринимаются для анализа. Диаграммы потоков данных и диаграммы "сущность-связь" -- наиболее часто используемые в CASE-средствах виды моделей. На стадии формирования требований к разрабатываемой подсистеме SADT-модели и DFD используются для построения модели "AS-1S" и модели "ТО-ВЕ", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов спортивного клуба и взаимодействие между ними.

Результатом применения метода SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы -- главные компоненты модели, все функции организации и интерфейсы на них представлены как блоки и дуги соответственно. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 2.1).

Механизм

Рисунок 2.1 - Функциональный блок и интерфейсные дуги

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

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

Для спортивного клуба «Т-Фитнес» простейшим компонентом является блок «Осуществление физкультурно-оздоровительной деятельности» с интерфейсными дугами «Посетители», «Постоянные клиенты», «Посетители, отказавшиеся от постоянных услуг», «Фитнес-директор», «Тренеры», «Администратор», «Потребности в оборудовании, товарах, услугах», «Стандарты, нормативные документы».

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

Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из диаграммы предыдущего уровня. На каждом шаге декомпозиции диаграмма предыдущего уровня называется родительской для более детальной диаграммы.

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

На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Например, на диаграмме А0 «Осуществление физкультурно-оздоровительной деятельности» обратная связь по управлению «Товары и оборудование» (См. приложение А1).

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

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

Для того чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок А21 на диаграмме А2. (рисунок 2.2)

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

Рисунок 2.2 - Детализация диаграмм

Различают по крайней мере связи семи типов (в порядке возрастания их относительной значимости):

- случайная;

- логическая;

- временная;

- процедурная;

- коммуникационная;

- последовательная;

- функциональная.

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

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

Временная связь -- представляет функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно.

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

Коммуникационная связь -- функции группируются благодаря тому, что они используют одни и те же входные данные и/или производят одни и те же выходные данные.

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

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

На основе анализа деятельности спортивного клуба «Т-Фитнес» построена функциональная модель, описывающая существующую организацию работы. Все диаграммы модели в стандарте IDEF0 показаны в Приложении А. Они отображают производимые объектом действия и связи между этими действиями.

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

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

Функциональная модель TO-BE строится на основе модели AS-IS после оценки эффективности выполняемых действий и выявления слабых сторон системы. В результате изучения функциональной структуры, а также из интервью с директором клуба были выявлены следующие недостатки в организации работы:

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

Страницы: 1, 2, 3, 4