Проектная модель

Один из важных вопросов: как аналитическая модель превращается в проектную.

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

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

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

Уточнение аналитических ассоциаций до ассоциаций уровня проектирования включает несколько процедур:

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

• реализацию ассоциаций один-ко-многим;

• реализацию ассоциаций многие-к-одному;

• реализацию ассоциаций многие-ко-многим;

• реализацию двунаправленных ассоциаций;

• реализацию классов-ассоциаций.

Все ассоциации уровня проектирования должны обладать:

• возможностью навигации;

• кратностью на обоих концах.

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

Уровни архитектуры

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

Другие уровни обычно в значительной мере зависят от платформы или от реализации. Например, чтобы изучить вопросы объектно-ориентированного проектирования Web-интерфейса или интерфейса пользователя на Java, необходимо детально разобраться с теми или иными каркасами (например, Struts, Swing или Spring). Если же в качестве платформы разработки выбрана .NET или Python, базовые знания должны быть совершенно другими.

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

Логическая архитектура

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

Логическая архитектура (logical architecture) описывает систему в терминах ее принципиальной организации в виде уровней, пакетов (или пространств имен), программных классов и подсистем. Она называется логической, поскольку не определяет способы развертывания этих элементов в различных операционных системах или на физических компьютерах в сети (это относится к архитектуре развертывания (deployment architecture)).

Уровень (layer) — это крупномасштабная группа классов, пакетов или подсистем, имеющих сходные обязанности для большинства аспектов системы.

Уровни организуются в группы (например, уровень интерфейса пользователя).

К типичным уровням объектно-ориентированной системы относятся следующие:

• Интерфейс пользователя (user interface).

• Уровень приложения или объектов предметной области (application logic and domain objects). К этому уровню относятся программные объекты, представляющие понятия предметной области (например, программный класс Sale) и обеспечивающие выполнение требований к системе (например, вычисление общей стоимости покупки)

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

Программная архитектура системы

Приведем одно из определений программной архитектуры системы (software architecture).

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

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

Архитектурный анализ

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

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

• Снижение риска отсутствия важных элементов в проектном решении системы

• Снижение трудозатрат на реализацию низкоприоритетных моментов

• Обеспечение конкурентоспособности программного продукта

Архитектурный анализ (architectural analysis) связан с определением и удовлетворением нефункциональных (например, качественных) требований к системе в контексте функциональных требований. В контексте UP этот термин охватывает как исследование архитектуры (определение), так и архитектурное проектирование (удовлетворение требований).

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

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

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

В Унифицированном Процессе рабочий поток реализации – основной поток фазы Построения.

Реализация заключается в преобразовании проектной модели в исполняемый код.

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