Файл: Анализ методов современного программирования.pdf

Инструменты. Система АПРОП [23 - 24] воплотила метод сборки разноязыковых модулей. В дальнейшем в качестве готовых элементов ПС стали использовать любые порции формализованных знаний (объекты, компоненты, программы, каркасы и др.), полученные при реализации отдельных программ и систем. Возникли новые проблемы их использования, например перенос на другую платформу или другую среду функционирования, т.е. проблема интероперабельности. Стандартным механизмом решения этой проблемы на данный момент является обеспечение связи Java- и C/C++- компонентов с помощью интерфейса JNI (Java Native Interface). Обращение Java-классов к функциям и библиотекам на других ЯП включает: анализ Java-классов для поиска прототипов обращений к функциям на C/C++; генерацию заглавных файлов при компиляции в C/C++; обращение из Java-классов к COM-компонентам [25]. Для платформы .Net интероперабельность реализована средствами языка CLR (Common Language Runtime), в который транслируются объекты в ЯП (C#, Visual Basic, C++, Jscript), используется библиотека стандартных классов независимо от ЯП и стандартные средства генерации в представление .Net-компонента. Особенности ОС и архитектур компьютеров учитывает также среда CORBA. Стандарт ДСТУ [26] обеспечивает независимо от ЯП спецификацию типов данных разноязыковых компонентов средствами специального языка, механизмов их агрегации и преобразования. Язык этого стандарта - альтернатива IDL, API, RPC.

2.2 Структурное программирование

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

Метод структурного программирования базируется на двух общих принципах:

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

Приведенные принципы дополнены такими механизмами:

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

Сформировался ряд моделей этого метода программирования, главными из которых являются:

• SADT (Structured Analysis and Design Technique) - структурный анализ и техника проектирования;
• SSADM (Structured Systems Analysis and Design Method) - метод структурного анализа и проектирования и др.

На стадии проектирования эти модели дополняются структурными схемами и диаграммами.

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

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

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

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

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

• определения функций;
• моделирования взаимосвязей событий и сущностей;
• логического проектирования данных;
• проектирования диалога;
• логического проектирования БД;
• физического проектирования.

Наиболее распространенным средством моделирования данных являются диаграммы "сущность-связь" (ERD), с помощью которых определяются объекты (сущности) ПрО, их свойства (атрибуты) и отношения (связи) [24]. Сущность (Entity) - реальный либо воображаемый объект, существенный для ПрО. Каждая сущность и ее экземпляр имеют уникальные имена. Сущность обладает свойствами:

• имеет один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь (Relationship);
• каждая сущность может обладать любым количеством связей с другими сущностями модели.

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

Инструменты. Основным инструментом является комплекс инструментальных, методических и организационных средств системы SSADM. Она принята государственными органами Англии в качестве основного системного средства и используется многими организациями как внутри страны, так и за ее пределами. На основе идеологии структурного программирования создан ряд CASE-средств (SilverRun, Oracle Disigner, Erwin для прямой и обратной связи с Rational Rose и др.).

2.3 Объектно-ориентированное проектирование (ООП)

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

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

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

• Анализ ОО. Создание ОО модели предметной области, в которой объекты отражают реальные ее сущности и операции, выполняемые ими;
• Проектирование ОО. Уточнение ОО модели с учетом требований для реализации конкретных задач системы;
• Программирование ОО. Реализация ОО модели средствами С++, Java и др.

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

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

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

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

Инструменты. Одной из инструментальной поддержки метода ООП является RUP - неофициальный стандарт разработки одиночных ПС из элементов Use Case, отвечающих требованиям конечных пользователей. Варианты использования - главные элементы этого процесса включают группы сценариев, описывающих применение ПС и интеграцию на этапах разработки с измерением времени выполнения этапов и измерения компонентов процесса на качество. При измерении времени выполнения этапов используются контрольные точки ПС. Компоненты процессов RUP описываются в категориях действий, рабочих потоков и исполнителей, которые измеряются и оцениваются. Основным недостатком ООП является отсутствие возможности задавать такие аспекты, как синхронизация выполнения объектов, удаленное взаимодействие в распределенной среде, защита данных, устойчивость и т.д. Этот недостаток относится и к компонентным технологиям ActiveX и JavaBeans и получит развитие в генерирующем программировании.

2.4 Метод моделирования UML

Метод UML (United Modeling Language - унифицированный язык моделирования) широко используется программными организациями как метод моделирования ПС исходя из таких базовых понятий:

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

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

Стереотип - это средство метаклассификации элемента, который представлен в диаграмме с описанием назначения (например, <<треугольник>>,<<точка>>). Он может расширяться и адаптироваться к конкретным областям применения.

ПС описывается с помощью рассматриваемых ниже диаграмм.

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

• рцЬИе (общий) - операция класса, вызываемая из любой части программы любым объектом ПС;
• protected (защищенный) - операция, вызываемая объектом того класса, в котором она определена или наследована;
• private (частный ) означает операцию, вызванную только объектом того класса, в котором она определена.

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

Классы могут находиться в следующих отношениях.

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

Зависимость между классами, при которой класс использует определенную операцию другого класса.

Экземпляризация - зависимость между параметризированным абстрактным классом-шаблоном (template) и реальным классом, который инициирует параметры шаблона (например, контейнерные классы языка С++).