Разработка модели Структуры библиотеки с помощью CASE средства BPWIN

«Разработка модели Структуры библиотеки с помощью

 

CASE средства BPWIN»

Оглавление

 

1)Цель работы

 

2) Введение

 

3)Описание предметной области

 

4)Описание используемой методологии

 

5)Описание процесса построения  модели

 

6)Вывод

 

1)Цель работы

 

1)   Освоение методологии case средством BpWin.

 

2)   Построение модели библиотечной  системы .

 

2)Введение

 

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

 

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

 

Библиотека — это определенным образом организованный коллектив  со своей внутренней структурой и  порядком управления.

 

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

 

3)Описание предметной области

 

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

 

Модель — образ или прообраз какого-либо объекта или системы  объектов, используемый при определённых условиях в качестве их «заместителя» или «представителя».

 

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

 

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

 

Для достижения эффективности разрабатываемых  систем требуется поддержка гибкости и настраиваемости, которые позволят в случае изменения структуры управления безболезненно перестроиться в нужную конфигурацию. Корректировка системы может производиться с использованием модели, созданной в процессе проектирования. Это существенно упрощает внесение изменений, так как можно промоделировать различные сценарии. Стандартизация моделей повышает удобочитаемость, понятность и способность разбираться в диаграммах не только разработчикам, но и специалистам предметной области. В методическом материале будут представлены три методологии моделирования: IDEF0, DFD и IDEF3.

 

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

 

В соответствии с поставленной целью  решаются следующие задачи дисциплины:

 

Ø  изучение методов и методологий  моделирования;

 

Ø  изучение современных инструментариев;

 

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

 

Ø  применение динамических, имитационных средств и технологий;

 

Ø  изучение методов предпроектного обследования;

 

Ø  изучение принципов реинжениринга;

 

Ø  изучение методов имитации деятельности предприятия.

 

 Существует несколько видов  моделирования:

 

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

 

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

 

Информационное моделирование - описание информационной структуры объектов (сущностей, атрибутов, ключей) с идентификацией отношений между ними (например, построение модели по методологии IDEF1).

 

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

 

 

CASE-средства

 

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

 

За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE - технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

 

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

 

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

 

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

 

4)Описание используемой методологии

 Методология IDEF0

 Графическое  изображение.

 

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

 

Наиболее  удобным языком моделирования бизнес-процессов  является IDEFO, предложенный более 20 лет  назад Дугласом Россом (SoftTech, Inc.) и  называвшийся первоначально SADT - Structured Analysis and Desifi Technique. (Подробно методология SADT излагается в книге Дэви А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа проектирования SADT" М.:Метатехнология, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEFO.

 

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

 

Под моделью  в IDEFO понимают описание системы (текстовое  и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

 

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

 

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

 

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

 Методология DFD

 

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

 

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

 

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson). Далее при построении примеров будет использоваться нотация Йодана, все исключения будут предварительно оговариваться.

 

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

 

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