Файл: Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (ТЕОРЕТИЧЕСКИЙ ОБЗОР ОСНОВНЫХ ПОНЯТИЙ И МЕТОДОВ ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ).pdf

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

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

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

1.2 Обзор методов проектирования программного обеспечения

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

- Те, что отражают возможности, которые должна обеспечить система,

назвали функциональными требованиями (functional requirement)

- Те, что отражают ограничения, связанные с функционированием системы, назвали нефункциональными требованиями (notfunctional requirement).

Первая из приведенных категорий дает ответ на вопрос: «Что делает

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

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

---

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

- Требования конфиденциальности;

- Отказоустойчивость;

- Число клиентов, которые одновременно имеют доступ к системе;

- Требования безопасности;

- Время ожидания ответа на обращение к системе;

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

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

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

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

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

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

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

---

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

Функционально - ориентированные (структурные) методы базируются на структурном анализе, структурных картах, диаграммах потоков данных и др. Они ориентированы на идентификацию функций и их уточнения сверху - вниз, после чего проводится разработка диаграмм потоков данных (DFD) и описание процессов. Примеры методов структурного проектирования приведены в работах Иордана и Константина[4, 5], Майерса [6].

В качестве средств структурного анализа и проектирования, наиболее распространенные такие нотации:

SADT (Structured Analysis and Design Technique). Для новых систем SADT (IDEF 0) применяется для определения требований (функций) для разработки системы, реализующего отдельные функции. Для уже существующих - IDEF 0 может быть использована для анализа функций, выполняемых системой. Модель в нотации IDEF 0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Вершина этой древовидной структуры представляет собой общее описание системы. После описания системы в целом проводится разбиение ее на крупные фрагменты (функциональная декомпозиция).

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

В свою очередь в MDE относятся такие подходы к проектированию ПО как RUP (Rational Unified Process - «Рациональный унифицированный процесс») и MDA (Model-driven architecture - «Мо дельно - ориентированная архитектура»).

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

---

Концентрация на выполнении требований заказчиков к ПО (анализ и построение модели прецедентов (вариантов использования).

Ожидания изменений в требованиях, проектных решениях и реализации в процессе разработки.

Компонентная архитектура, реализованная и тестируемая на р анних стадиях проекта.

Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

Работа над проектом командой разработчиков, ключевая роль в которой принадлежит архитекторам.

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

В отличие от RUP, MDA характеризуется следующими преимуществами:

возможность переноса приложения, ее повторное использование, уменьшение стоимости и сложности разработки и упр ния приложением;

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

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

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

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

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

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

Согласно концепции модельно - ориентированного подхода, модель создаваемого программного обеспечения рассматривается с трех точек зрения:

Вычислительная независимая модель (CIM - Computation Independent Model)

- Описание потоков задач, которое включает:

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

---

независимые от программной реализации аспекты структуры ПО и вычислений;

CIM базируется на среде функционирования системы, на требованиях к системы, тогда как структура и функционирования системы НЕ детализированные или даже неопределенные.

Независимая от платформы модель (PIM - Platform Independent Model) - HLA (высокоуровневый архитектура ПО ЧП, описание потоков задач, ориентированных на вычисления), которая включает:

определение формальной спецификации и функциональности программного обеспечения;

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

Модель, ориентированная на платформу (PSM - Platform Specific Model) - LLA (низкоуровневая архитектура ПО ЧП), которая включает платформо - специфические особенности реализации услуги на конкретной платформе (подсистемы OSS / BSS).

На рис. 1. изображен принцип реализации MDA. Основная идея MDA заключается в том, что преобразования с PIM в PSM, а также генерации я кода с PSM может осуществляться автоматически. Преобразование проводятся за помощью инструментов преобразования (transformation tools), которые, в свою очередь, используют правила преобразования. Эти правила пользователя на языке, который описана стандартом QVT (Queries, V iews, Transformations). преобразование могут быть параметризованные, что позволит их подстраивать под потребности конкретных проектов.

Рис.1. Преобразование моделей MDA: PIM в PSM

Пример реализации MDA архитектуры

Пример реализации MDA архитектуры показано на рис. 2

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

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

---