Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы».pdf

необходимость учитывать фактор времени.

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

Два подхода к проектированию

Можно выделить два основных подхода к проектированию систем управления предприятием и информационных систем их поддержки: структурный и процессный.

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

Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. О важности и структуре Системного проекта авторы уже писали в статье “Реорганизация АСУ промышленных предприятий” (КомпьютерПресс № 7’97) и в статье “Методологический подход проектирования корпоративной информационной системы предприятия” (материалы конференции “Корпоративные системы’96”, компания “СофтСервис”). Хорошо, если на предприятии есть обученные специалисты, способные быстро и качественно актуализировать этот документ. Но это только начало! Ведь актуализировать надо также и саму информационную систему! Как правило, это достаточно трудоемкий, длительный и утомительный процесс.

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

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

широкое делегирование полномочий и ответственности исполнителям;

---

сокращение количества уровней принятия решения;

сочетание принципа целевого управления с групповой организацией труда;

повышенное внимание к вопросам обеспечения качества продукции или услуг, а также работы предприятия в целом;

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

Далее мы рассмотрим, каким образом процессный подход был применен при проектировании информационной системы одного из предприятий пищевой промышленности (далее “Компании”).

Применение процессного подхода. Цели проекта

Основными целями проектирования интегрированной системы Компании являлись:

проведение системного анализа бизнес-процессов и моделирование рациональных технологий работы Компании;

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

разработка положения по организации управления Компании (центрального офиса и филиала);

разработка системного проекта интегрированной информационной системы Компании (центрального офиса и филиала).

1.2 Сущность объектно-ориентированного подхода

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

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

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

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

---

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

На основе декомпозиции системы:

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

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

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

Под распределённой обработкой данных понимают обработку приложений несколькими территориально разделёнными ЭВМ. При этом в приложениях, связанных с обработкой базы данных, собственно управление базой данных может выполняться централизованно

№5 Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта. По данным исследования, проведенного IBM в области IT, 60% затрат времени организации-разработчики программного обеспечения несут в результате неэффективного подхода к управлению требованиями. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. При правильном определении требований и управлении ими перерасходы по проекту можно снизить на 20% благодаря сокращению числа неточных, неполных и упущенных требований.

---

1.3 Базовые составляющие объектно-ориентированного подхода

Базовыми составляющими объектно-ориентированного подхода являются:

- Унифицированный процесс;

- Унифицированный язык моделирования;

- шаблоны проектирования.

Унифицированный процесс – это процесс разработки программного обеспечения (ПО), который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации-разработчике [29, 30]. Унифицированный процесс охватывает весь жизненный цикл ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем.

Неотъемлемой частью Унифицированного процесса является UML – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. Следует отметить, что Унифицированный процесс и UML разрабатывались совместно.

На стадиях анализа и проектирования часто используются так называемые шаблоны (паттерны) проектирования. Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, кооперации и/или последовательности), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов может резко сократить затраты и повысить качество разработки ПО.

Глава 2: Объектно-ориентированный анализ и проектирование системы

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

---

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

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

Объектно-ориентированный анализ и проектирование (ООАП, Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов .

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided SoftwareEngineering, CASE). К первым CASE-средствам отнеслись с определенной настороженностью. Со временем появились как восторженные отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над системой управления базами данных (СУБД). Визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, тем не менее, она не решает проблем создания приложений других типов.

---