Сравнительный анализ подходов к проектированию ИС

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

1. Целей проекта;

2. Требований к информации необходимой для анализа и принятия решений в рамках конкретного проекта;

3. Возможностей подхода с учетом требований;

4. Особенностей разрабатываемой/внедряемой информационной системы.

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

Сравнение подходов должно дать ответы на следующие вопросы:

1. На сколько сам подход и его нотации применимы для того или иного этапа проектирования ИС.

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

Функциональные возможности подходов можно корректно сравнивать только по отношению к определенному кругу задач. В данном исследовании рассматривается задача формирования моделей бизнес-процессов предприятия при анализе и проектировании. Каждый из рассматриваемых подходов имеет свои преимущества и недостатки. В зависимости от решаемых задач эти преимущества могут как усиливаться, так и наоборот, ослабевать. Например, отсутствие четких соглашений по моделированию управляющих воздействий в рамках eEPC ARIS может привести к созданию моделей, не отвечающих на поставленные вопросы, в то время как нотация IDEF0 позволяет решить эту задачу (хотя данная задача решается довольно редко). С другой стороны, процедура, выполняемая одним сотрудником, может быть более адекватно описана при помощи eEPC ARIS, чем при помощи IDEF0 или IDEF3.

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

14. Проектирование программной системы: проектирование архитектуры.

Наиболее полная информация: http://swebok.sorlik.ru/2_software_design.html#_3!!!

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

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

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

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

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

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Примеры видов:

• Функциональный/логический вид
• Вид код/модуль
• Вид разработки (development)/структурный
• Вид параллельности выполнения/процесс/поток
• Физический вид/вид развертывания
• Вид с точки зрения действий пользователя
• Вид с точки зрения данных

Хотя было разработано несколько языков для описания архитектуры программного обеспечения, в настоящий момент нет согласия по поводу того, какой набор видов должен быть принят в качестве эталона. В качестве стандарта «для моделирования программных систем (и не только)» был создан язык UML.

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

Существуют следующие фреймворки (англ. software architecture frameworks), относящихся к области архитектуры ПО:

• 4+1
• RM-ODP (Reference Model of Open Distributed Processing)
• Service-Oriented Modeling Framework (SOMF)

Такие примеры архитектур как фреймворк Захмана (Zachman Framework), DODAF и TOGAF относятся к области архитектуры предприятия (enterprise architectures).