Файл: ПРОЕКТИРОВАНИЕ РЕАЛИЗАЦИИ ОПЕРАЦИЙ БИЗНЕС-ПРОЦЕССА «ДВИЖЕНИЕ БИБЛИОТЕЧНОГО ФОНДА» (Аналитическая часть).pdf
Добавлен: 30.03.2023
Просмотров: 142
Скачиваний: 2
Одной из основных проблем, которые приходится решать при создании больших и сложных систем любой природы, в том числе и ПО, является проблема сложности. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы, который выработало человечество за всю свою историю, заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера, и т.д., до тех пор, пока самые небольшие части можно будет строить из имеющегося материала. Этот подход известен под самыми разными названиями, среди них такие, как «разделяй и властвуй» (divide et impera), иерархическая декомпозиция и др. По отношению к проектированию сложной программной системы это означает, что ее необходимо разделить (декомпозировать) на небольшие подсистемы, каждую из которых можно разрабатывать независимо от других. Это позволяет при разработке подсистемы любого уровня иметь дело только с ней, а не со всеми остальными частями системы. Правильная декомпозиция является главным способом преодоления сложности разработки больших систем ПО. Понятие «правильная» по отношению к декомпозиции означает следующее:
· количество связей между отдельными подсистемами должно быть минимальным (принцип «слабой связанности» — Low Coupling);
· связность отдельных частей внутри каждой подсистемы должна быть максимальной (принцип «сильного сцепления» - High Cohesion).
Структура системы должна быть такой, чтобы все взаимодействия между ее подсистемами укладывались в ограниченные, стандартные рамки, т.е.:
· каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);
· каждая подсистема должна иметь четко определенный интерфейс с другими подсистемами.
Инкапсуляция (принцип «черного ящика») позволяет рассматривать структуру каждой подсистемы независимо от других подсистем. Интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя ее внутреннее устройство.
Существуют два основных подхода к декомпозиции систем. Первый подход называют функционально-модульным, он является частью более общего структурного подхода. В его основу положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Второй, объектно-ориентированный подход, использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами.
Стоит подробно рассмотреть структурный метод анализа и проектирования ПО.
Сущность структурного подхода к разработке ИС заключается в её декомпозиции (разбиении) на автоматизируемые функции. Система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны. При разработке системы “снизу-вверх” от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Структурное (функциональное) проектирование – это метод определения подсистем, компонентов и способов их соединения, задающий ограничения, при которых система должна функционировать, выбирающий наиболее эффективное сочетание людей, машин и программного обеспечения для реализации системы.
В качестве примера рассмотрим одну из широко используемых систем такого проектирования – SADT (Structured Analysis and Design Technique – технология структурного анализа и проектирования) – это графические обозначения и подход к описанию систем.
SADT создана для описания системы и её среды до определения требований к программному обеспечению и др. Она облегчает описание и понимание искусственных систем средней сложности. В SADT используется графический язык и набор процедур анализа для понимания системы прежде, чем можно представить себе её воплощение. Она, как правило, применяется на ранних этапах процесса создания системы, который часто называют “жизненным циклом системы”.
SADT-модель – иерархически организованная совокупность диаграмм. Диаграммы обычно состоят из трёх-шести блоков, каждый из которых потенциально может быть детализирован на другой диаграмме. Каждая диаграмма представляет некоторую законченную часть всей модели.
Каждый блок может пониматься как отдельный тщательно определённый объект. Разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией.
Метод SADT реализован в виде стандарта IDEF0.
При проектировании сложной или достаточно объёмной программной системы её, как правило, делят на части, каждую из которых затем рассматривают и разрабатывают отдельно. При этом используется либо функциональное деление системы, либо объектная декомпозиция.
При функциональном делении программной системы её структура может быть описана блок-схемой, узлы которой обозначают выполняемые функции, а связи указывают последовательность их выполнения. Программные модули, реализующие функции, обычно, используются только в составе данной системы.
При объектной декомпозиции система разбивается на объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями. Сообщения описывают или представляют собой некоторые события. Получение объектом сообщения активизирует его и побуждает выполнять предписанные его программным кодом действия. Как следствие, программная система перестает быть последовательностью определенных на этапе кодирования действий, а становится событийно-управляемой. Инициаторами событий могут быть не только объекты системы, но и её внешнее окружение, например, пользователи.
Объекты имеют свойства и методы.
Свойства объекта - это значения, которые устанавливаются для определения его вида и поведения.
Методы объекта – это программные процедуры, обеспечивающие выполнение им определенных действий.
Совокупность объектов, имеющих общий набор свойств и характеризующихся одинаковым поведением, называется классом. Классы могут строится по иерархическому принципу, когда один класс может быть подклассом другого класса. Из определения класса следует, что каждый объект является экземпляром одного определенного класса.
Важной особенностью объекта является его автономность и возможность использования в качестве библиотечного компонента языка программирования. Таким образом, однажды разработанный и отлаженный программный код может многократно применяться в различных программных модулях. Чтобы побудить объект выполнить необходимые действия достаточно установить его свойства и вызвать соответствующий метод. При наличии для используемого языка программирования развитой библиотеки компонентов разработка программ сводится, в большей своей части, к связыванию имеющихся объектов, что существенно облегчает и ускоряет процесс проектирования. Такая технология разработки программных модулей получила название объектно-ориентированного программирования.
Основными принципами объектно-ориентированного программирования являются наследование, инкапсуляция и полиморфизм.
Принцип, в соответствии с которым знание о более общей категории разрешается применять для более узкой категории, называется наследованием. Наследование тесно связано с иерархией классов. При этом, если некоторый родительский класс обладает фиксированным набором свойств и поведением, то производный от него класс должен содержать этот же набор свойств и обладать таким же поведением, а также дополнительными свойствами и видами поведения, которые будут определять уникальность созданного таким образом класса.
Принцип инкапсуляции характеризует сокрытие деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей. То есть, взаимодействующему с классом объекту или пользователю не нужно знать, каким образом реализован тот или иной метод класса, чтобы им воспользоваться.
Полиморфизм в объектно-ориентированном программировании означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов они относятся.
Характеристика существующих бизнес –процессов
Методология в настоящее время более известна как нотация IDEF0, использует формализованный процесс моделирования информационных систем и имеет
следующие стадии: анализ, проектирование, реализация, объединение, тестирование, установка, функционирование. Проектирование информационных систем по стандарту IDEF0 сводится к декомпозиции основных функций организации на отдельные бизнес-процессы, работы или
действия. В результате разрабатывается иерархическая модель анализируемой организации, при этом декомпозицию можно проводить многократно, до четкого и детального описания всех процессов. Диаграммы IDEF0 верхнего уровня принято называть родительскими, а нижнего уровня – дочерними. Пример диаграммы IDEF0 верхнего уровня представлен на рисунке 1
Рисунок 1 Диаграмма IDEF0 верхнего уровня
Анализируемый процесс представляется в виде прямоугольника. Слева изображаются входные данные, справа – выходные, сверху управляющие или регламентирующие воздействия, а снизу объекты управления. В диаграмме IDEF0 описываются первоначально все внешние связи исследуемого процесса. После этого осуществляется декомпозиция этого процесса и происходит описание внутренних подпроцессов с обозначением всех связей. При этом ранее обозначенные стрелочками внешние связи не должны потеряться. Они переносятся на диаграмму декомпозиции в соответствующие подпроцессы. Пример декомпозиции диаграммы IDEF0 (дочерней) представлен на рисунке 2.
Рисунок 2. Дочерняя диаграмма IDEF0
Далее каждый подпроцесс тоже можно декомпозировать и подробно описывать все связи до необходимого предела. Основным достоинством этой методологии являются простота и наглядность. В качестве недостатка – невозможность описать реакцию описываемого процесса на изменяющиеся внешние факторы. Для этих целей служат другие методологии.
В стандарте ISO 9000-2001 процесс определен как «совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы».
Бизнес-процессы разделяют на основные, сопутствующие, вспомогательные, обеспечивающие, процессы управление и процессы развития:
Основные бизнес-процессы генерируют доходы компании. К ним относятся процессы, ориентированные на производство товара или оказание услуги, являющиеся целевыми объектами создания предприятия и обеспечивающие получение дохода. Именно основные бизнес-процессы формируют результат и потребительские качества, за которые внешний клиент готов платить деньги. Так, для деревообрабатывающего завода основным бизнес-процессом может быть производство древесно-стружечной плиты.
Сопутствующие бизнес-процессы — это процессы, ориентированные на производство товара или оказание услуги, являющиеся результатами сопутствующему основному производству производственной деятельности и также обеспечивающие получение дохода. Так, для автотранспортного предприятия процесс ремонта стороннего транспорта на собственной ремонтной базе является сопутствующим процессом.
Вспомогательными бизнес-процессами являются процессы, предназначенные для жизнеобеспечения основных и сопутствующих процессов и ориентированные на поддержку их специфических черт. Например, для ТЭЦ вспомогательным бизнес-процессом является процесс ремонта производственного оборудования. Обеспечивающие процессы поддерживают инфраструктуру компании, предназначены для жизнеобеспечения всех остальных процессов и ориентированы на поддержку их универсальных черт. На предприятиях любой отрасли — это процесс финансового обеспечения, кадрового обеспечения, инженерно-технического обеспечения и т. п.
Бизнес-процессы управления — это процессы, охватывающие весь комплекс функций управления на уровне каждого бизнес-процесса и предприятия в целом. Это процессы стратегического, оперативного и текущего планирования, формирования и осуществления управленческих воздействий. Бизнес-процессами развития являются процессы совершенствования производимого товара или услуги, процессы развития технологий, процессы модификации оборудования, а также инновационные процессы. Например, это проведение научно-исследовательских и опытно-конструкторских работ (НИОКР) в машиностроении, процесс технического перевооружения в электроэнергетике и т. п.
Основные бизнес-процессы определяют доходы компании. Именно они определяют профиль бизнеса, именно они имеют стратегическое значение и их ни в коем случае нельзя отдавать на аутсорсинг. Именно эти процессы конкурентоспособная компания должна уметь выполнять лучше других в своей отрасли. По мере функционирования компании основные бизнес-процессы развиваются или умирают в зависимости от востребованности рынка и стратегии компании.