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

До этого момента в бизнесе господствовала идея функционального разделения труда. Эту идею в конце 18-го века впервые сформулировал Адам Смит, на ее основе были созданы мануфактуры, которые в 19-м веке вытеснили ремесленные цеха и кустарное производство товаров. В начале 20-го века Генри Форд усовершенствовал эту идею и создал сборочный конвейер на своих автомобильных заводах, что позволило сильно увеличить производительность труда. Сейчас такие конвейеры существуют во многих отраслях промышленности. После этого Альфред Стоун, руководитель компании «Дженерал моторс», применил идею разделения труда к управлению крупным производством.

В начале 90-х годов Майкл Хаммер и Джеймс Чампли предложили иную форму организации бизнеса, ориентированную на процессы (бизнес-процессы). Бизнес-процесс - это цепочка действий от поступления заказа до полного завершения его обработки. Такой подход позволяет управлять и контролировать бизнес как деятельность, нацеленную на конечный результат. Иначе заказы и сервисы оказываются «размазанными» по функциональным отделам компании, у каждого из которых нет заинтересованности в конечном результате. В итоге падает качество сервисов, заказы обрабатываются не оптимально, с большими издержками.

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

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

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

3. формализованные бизнес-процессы легче изменять и модернизировать;

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

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

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

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

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

Процессный подход может использовать любые из перечисленных выше средств моделирования. Однако, в настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS - Architecture of Integrated Information System, разработанный германской фирмой IDS Scheer [7].

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

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

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

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования - ERM, UML, OMT и др.

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

Модели в ARIS представляют собой диаграммы, элементами которых являются разнообразные объекты - «функция», «событие», «структурное подразделение», «документ» и т. п. Между объектами устанавливаются разнообразные связи. Каждому объекту соответствует определенный набор атрибутов, которые позволяют ввести дополнительную информацию о конкретном объекте. Значения атрибутов могут использоваться при имитационном моделировании или для проведения стоимостного анализа.

Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой.

Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.

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

Среди таких методов наиболее известными являются метод Ericsson-Penker и метод, реализованный в технологии Rational Unified Process (RUP).

Метод Ericsson-Penker [23] представляет интерес прежде всего в связи с попыткой применения UML в рамках процессного подхода к моделированию бизнес-процессов. Авторы метода создали свой профиль UML для моделирования бизнес-процессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации. Метод использует четыре основные категории бизнес-модели:

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

Процессы - виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.

Цели - назначение бизнес-процессов Цели могут быть разбиты на подцели и соотнесены с отдельными процессами.

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

Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Метод Eriksson-Penker представляет процесс в виде деятельности со стереотипом «process» (основой данного представления является расширение метода IDEF0). Полная бизнес-модель включает множество представлений, подобных представлениям архитектуры программного обеспечения. Каждое представление выражено в одной или более диаграммах UML. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод использует четыре различных представления бизнес-модели:

концептуальное представление - структура целей и проблем;

представление процессов - взаимодействие между процессами и ресурсами (в виде набора диаграмм деятельности) ;

структурное представление - структура организации и ресурсов (в виде диаграмм классов) ;

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

Методика моделирования RUP [13] предусматривает построение двух моделей:

модели бизнес-процессов (Business Use Case Model) ;

модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов - Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования). Business Actor (действующее лицо бизнес-процессов) - это некоторая роль, внешняя по отношению к бизнес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.

Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом «goal», а дерево целей изображается в виде диаграммы классов.

Для каждого Business Use Case строится модель бизнес-анализа - объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов - Business Object), принадлежащих к двум классам - Business Worker и Business Entity. Business Worker (исполнитель) - класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. Business Entity (сущность) является объектом различных действий со стороны исполнителей.

Кроме диаграммы данных классов, модель бизнес-анализа может включать:

Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций.

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

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

Методика моделирования Rational Unified Process обладает следующими достоинствами:

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

моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков.

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

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

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

2.5 Методы анализа и проектирования программного обеспечения

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

Все современные технологии создания программного обеспечения реализуют ту или иную методику анализа и проектирования программного обеспечения. Одна из типичных методик ООП реализована в технологии RUP. Согласно этой методике, объектно-ориентированный анализ включает два вида деятельности: архитектурный анализ и анализ вариантов использования. Архитектурный анализ выполняется архитектором системы и включает в себя:

утверждение общих стандартов (соглашений) моделирования и документирования системы;

предварительное выявление архитектурных механизмов (надежности, безопасности и т. д.) ;

формирование набора основных абстракций предметной области (классов анализа) ;

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

распределение поведения, реализуемого вариантом использования, между классами (определение обязанностей классов) ;

определение атрибутов и ассоциаций классов.

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

адекватность средств решаемым задачам;

согласованность с другими средствами структурного анализа;

интеграция с другими процессами жизненного цикла программного обспечения (прежде всего с процессом проектирования).

Адекватность средств решаемым задачам. Модели SADT (IDEF0) традиционно используются для моделирования организационных систем (бизнес-процессов). С другой стороны, не существует никаких принципиальных ограничений на использовании DFD в качестве средства моделирования бизнес-процессов. Следует отметить, что метод SADT успешно работает только при описании хорошо специфицированных и стандартизованных бизнес-процессов в зарубежных корпорациях, поэтому он и принят в CШA в качестве типового. Достоинствами применения моделей SADT для описания бизнес-процессов являются:

полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи) ;

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

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

соответствие подхода к описанию процессов стандартам ISO 9000.

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

сложность восприятия (большое количество стрелок) ;

большое количество уровней декомпозиции;

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

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

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

Наличие в DFD спецификаций процессов нижнего уровня позволяет преодолеть логическую незавершенность SADT (а именно, обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной) и построить полную функциональную спецификацию разрабатываемой системы.

Жесткие ограничения SADT, запрещающие использовать более 6-7 блоков на диафрагме, в ряде случаев вынуждают искусственно детализировать процесс, что затрудняет понимание модели заказчиком, резко увеличивает ее объем и, как следствие, ведет к неадекватности модели реальной предметной области. В качестве примера достаточно рассмотреть модель операции по снятию денег с вклада физического лица в банке. В настоящий момент существуют более тридцати типов таких вкладов. Для моделирования соответствующих операций целесообразно использовать единственную DFD, поскольку все без исключения операции имеют одни и те же входы (сберегательная книжка и расходный ордер) и выходы (сберегательная книжка и наличные деньги) и различаются лишь механизмами начисления процентов. Если же попытаться структурировать эти операции путем группирования по какому-либо признаку (срочные, пенсионные, размеры процентов и т. п.) в соответствии с ограничениями SADT, то получится как минимум 6 диаграмм (верхний уровень и округленная в большую сторону дробь 30/7), сложность каждой из которых не меньше сложности единственной диаграммы, моделирующей все операции.

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

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

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

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

В потоках событий варианта использования выявляются классы трех типов:

Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).

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

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

Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области. Совокупность классов анализа представляет собой начальную концептуальную модель системы

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

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

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

Объектно-ориентированное проектирование включает два вида деятельности:

проектирование архитектуры системы;

проектирование элементов системы.

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;

анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

формирование архитектурных уровней;

проектирование конфигурации системы.

Проектирование элементов системы включает в себя:

проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами) ;

проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД - объектной или реляционной).

3. Структурное и объектно-ориентированное программирование в проектировании программного обеспечения распределенных информационных систем

3.1 Проектирование программного обеспечения распределенных информационных систем

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

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

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

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

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

функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

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

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

Состав и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится большим (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.

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

Предпроектные исследования, или анализ;

Проектирование и подготовка спецификаций;

Программирование, или кодирование;

Отладка;

Тестирование.

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

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

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

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

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

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

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

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

3.2 Структурный подход к проектированию информационных систем

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

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

повышение производительности труда программистов при написании и контроле программ;

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

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

окончание создания программ в заданный срок.

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

Все наиболее распространенные методологии структурного подхода [9, 11, 12, 13] базируются на ряде общих принципов [3]. В качестве двух базовых используются следующие принципы:

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

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

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

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

принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

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

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».

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

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

Структурное проектирование позволяет одновременно сосредотачиваться на меньшем количестве деталей.

Нисходящее проектирование хорошо работает, когда проблема имеет ясно выраженный иерархический характер.

3.3 Проектирование информационных систем на основе объектно-ориентированного подхода

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

функциональную точку зрения трудно развивать;

реальные системы трудно охарактеризовать функционально;

фокусирование на функциональности теряет из виду данные;

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

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

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

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

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

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

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

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

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

Объектно-ориентированное проектирование - это конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных.

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

Преимущества объектно-ориентированного метода:

- работают на более высоком уровне абстракции;

- нет «прыжков» между фазами;

- поддерживают данные, которые имеют тенденцию, к большей стабильности, чем функции;

- поощряют и поддерживают классические достоинства хорошего программирования и проектирования;

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

Объектно-ориентированный подход имеет два аспекта:

объектно-ориентированная разработка программного обеспечения;

объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. К объектно-ориентированной разработке относятся:

- объектно-ориентированные технологии разработки программных систем;

- инструментальные средства, поддерживающие эти технологии.

Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.

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

Можно выделить следующие объектно-ориентированные методологии разработки программного обеспечения:

- RUP (Rational Unified Process) ;

- OMT (Object Modeling Technique) ;

- SA/SD (Structured Analysis/Structured Design) ;

- JSD (Jackson Structured Development) ;

- OSA (Object-Oriented System Analysis)

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

Среди свойств объектов в объектно-ориентированном подходе можно отметить:

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

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

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

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

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

Модель проектирования информационных систем на основе объектно-ориентированного подхода представлена в приложении (Приложение Д)

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

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

3.4 Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов

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

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

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

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

объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию;

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

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

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

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

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

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

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

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

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

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

...