Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Технологии и методы программирования. Учебное пособие-1

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 23 / 143 4 5 6 7 8 9 10 11 12 13 14 > Следующая >>>

Проектное решение – промежуточное или конечное описание объекта проектирования, необходимое и достаточное для рассмотрения и определения дальнейшего направления или окончания проектирования [18].

Проектный документ – документ, выполненный по заданной форме, в котором представлено какое-либо проектное решение, полученное при проектировании [18].

Проект – совокупность проектных документов в соответствии с установленным перечнем, в

которых представлен результат проек-

тирования [18].

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

решений, на основе которых

была осуществлена реализация.

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

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

процессов, определенных в стандарте [8].

Для успешной реализации проекта объект проектирования (программное обеспечение) должен быть прежде всего адекватно описан, т. е. должны быть построены полные и непротиворечивые модели архитектуры ПО. Признак добротности архитектуры – ее концептуальное единство и целостность. По утверждению Брукса, «концептуальная целостность является важнейшей характеристикой системного проекта» [12].

Архитектура (системы) – основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития [19].

Архитектура ПО – совокупность структурных элементов системы и связей между ними, поведение элементов системы в процессе их взаимодействия, а также

иерархия подсистем, объединяющих структурные

элементы [14].

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

Приложение – набор программ или программных компонентов, обеспечивающих непосредственную

поддержку конкретных бизнес-

процессов [20].

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

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

модуль, выполняющие отдельные, относи-

тельно изолированные задачи.

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

1) требования, предъявляемые к приложению – функциональность, безопасность, производительность, возможность параллельной обработки, интернационализация, конфигурация и т. п.;

2) необходимость обеспечить гибкость и и обслуживания в течение всего времени эксплуатации;

3) ментальную модель вателя

;

пользователя и/или сценарии работы пользо-

удобство развертывания

4) влияние возможных стилей архитектуры на приложение в про-

цессе разработки, развертывания и эксплуатации.

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

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

Ментальная модель – основанное на предыдущем опыте осмысление спо-

соба взаимодействия с продуктом.

Пользовательский сценарий – визуализация предполагаемой последова-

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

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

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

Архитектурный стиль (шаблонная архитектура) – абстрактная архитектура, применимая к

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

Стек технологий – набор технологий, на основе которых разраба-

тывается приложение. Формирование такого набора –

основная задача,

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

АРХИТЕКТУРНЫЕ СТИЛИ ПРОГРАММНЫХ ПРИЛОЖЕНИЙ [21–24]

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

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

Наиболее известны и реализуемы следующие

архитектурные стили.

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

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

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

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

при сборке и развертывании, инкапсуляция.

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

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

На уровне программного

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

4. Сервисно-ориентированная архитектура (SОА) характеризуется наличием самостоятельных программных компонентов, называемых сервисами, которые предоставляют прикладным программам функциональные возможности.

Эта архитектура применяется для многократного

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

Взаимодействие приложений или сервисов между собой происходит через интерфейсы. Интерфейс сервиса определяет, как использовать сервис для выполнения действий или обмена данными. Поскольку сервисы, как правило, различаются интерфейсами, интеграция сервисов происходит посредством ESB (Enterprise Service Bus –

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

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

Микросервисы взаимодействуют через API (Application Program-

ming Interface – программный интерфейс приложения), который пред-

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

Знание архитектурных принципов и шаблонов позволяет разработ-

чику и архитектору решения понимать и учитывать в

процессе проектирования важные аспекты, которые могут существенно влиять на успех решения в целом.

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

Модель – полное описание системы ПО с определенной точки зре- ния. Модели представляют собой средство

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

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

В качестве средств разработки и моделирования в архитектурном проектировании используются различные языки, которые принято называть нотациями [26–30].

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

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

 элементы модели (алфавит) – фундаментальные концепции моде- лирования (словарь);

 семантику – значения элементов словаря;

 синтаксис – правила применения элементов словаря в рамках по-

строения тех или иных типов моделей ПО.

5. МЕТОДОЛОГИИ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Методология – совокупность рабочих процедур, методов, методик или правил, используемых в конкретном проекте или исследуемом процессе [31].

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

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

Разнообразие задач, решаемых ПС ных типов ПС (системное программное обеспечение, пакеты прикладных программ, инструментарий технологии программирования) [33, 34], каждый из которых создает свой набор проблем, связанных с проектированием, реализацией и выбором методологии, отсюда вытекает принцип, отмеченный в [35]: «Как только мы пытаемся разобраться,

требований, предъявляемых к ПС, и позво-

, порождает множество различ-

свою очередь, со-

“из чего же состоит методология”, сразу становится понятно, что ме-

тодологий должно быть много. При этом для каждого конкретного проекта “оптимальной” будет одна какая-то методология».

Таким образом, должно существовать и существует множество методов и практик разработки ПС [13, 14, 36, 37], применение которых при проектировании ПС зависит от большого числа различных факторов. Заметим, что значительным фактором, влияющим на выбор методологии и результат ее применения, является человеческий фактор [38].

ОБЩИЕ ТРЕБОВАНИЯ К МЕТОДОЛОГИИ И ТЕХНОЛОГИИ

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

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

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

информации и ее представления в виде проекта (комплекса проектной документации).

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

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

цикла.

Технология проектирования определяется как совокупность трех со-

ставляющих:

 пошаговой процедуры, устанавливающей последовательность

технологических операций проектирования;

 критериев и правил, используемых для оценки результатов вы-

полнения технологических операций;

 нотаций – систем условных обозначений (символов и правил их

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

описания проектиру-

емой системы.

На рис. 6 показано схематичное представление технологической

операции проектирования.

Исходные данные

в стандартном

представлении

(документы, рабочие материалы, результаты предыдущей операции)

Рис. 6. Технологическая операция проектирования

Методические материалы,

инструкции, нормативы

и стандарты, критерии

оценки результатов

Технологическая

операция

Исполнители, программные

и технические средства

Результаты

в стандартном

представлении

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

щими материальными и информационными ресурсами:

 данными, полученными на предыдущей операции (или исход-

ными данными), представленными в стандартном виде;

 методическими материалами, инструкциями, нормативами и стан-

дартами;

 программными и техническими средствами;  исполнителями.

Технологические инструкции, составляющие основное содержание

технологии, должны состоять из описания последовательности

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

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

Технология проектирования, разработки и сопровождения ПС должна удовлетворять следующим требованиям:

 поддерживать полный ЖЦ ПО;

 обеспечивать гарантированное достижение целей разработки ИС

с заданным качеством и в установленное время;

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

каждой группы, которое может возник-

нуть в силу наличия общих данных и функций;

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

 обеспечивать получение работоспособного программного про- дукта в запланированные сроки. Речь идет не только о сроках готовности всего ПС, но и о сроках

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

 предусматривать возможность управления конфигурацией про-

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

 обеспечивать независимость выполняемых проектных решений

от средств реализации ПС (СУБД, операционных

систем, языков и си-

стем программирования);

 поддерживаться комплексом согласованных инструментальных

средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

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

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

Применение стандартов позволяет:

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

сконцентрировать лучшие практики в определенной области дея-



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

 унифицировать терминологию, что облегчает общение в среде специалистов.

Для проекта ПС следует определять [39]:

1) стандарт проектирования;

2) стандарт оформления проектной документации;

3) стандарт пользовательского интерфейса.

Стандарт проектирования устанавливает:

набор необходимых моделей (диаграмм и т. д.) на каждой стадии



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

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

форме и размерам объектов и т. д.;

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

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

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

Стандарт оформления проектной документации устанавливает:

 комплектность, состав и структуру документации на каждой ста-

дии проектирования;

 требования к ее оформлению (включая требования к содержанию

разделов, подразделов, пунктов

, таблиц и т. д.);

<<< < Предыдущая 1 23 / 143 4 5 6 7 8 9 10 11 12 13 14 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]