Проектирование программного обеспечения

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

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

Архитектура ПО - совокупность базовых концепций при построении программного обеспечения и связей между его компонентами.

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

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

Ниже перечислены отдельные этапы процесса проектирования:

– Архитектурное проектирование - определяются и документируются подсистемы и взаимосвязи между ними.

– Обобщенная спецификация - для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения.

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

– Компонентное проектирование - проводится распределение системных функций (сер­висов) по различным компонентам и их интерфейсам.

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

– Проектирование алгоритмов - детально разрабатываются алгоритмы, предназна­ченные для реализации системных сервисов.

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

Нисходящее и восходящие проектирование и разработка

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

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

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

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

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

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

В основе этих принципов лежат операции:

– абстрагирования, т.е. выделения существенных аспектов системы и отвлечения от несущественных;

– формализации, т.е строгое методологическое решение проблемы;

– непротиворечивости, состоящей в обосновании и согласовании элементов системы;

– структуризации данных (т.е. данные должны быть структурированы и иерархически организованы).

При структурном анализе применяются в основном три вида наиболее распространённых моделей проектирования ПО:

– SADT (Structured Analysis and Design Technique) модель и соответствующие функциональные диаграммы;

– SSADM (Structured Systems Analysis and Design Method) – метод структурного анализа и проектирования;

– IDEF0 (Integrated Definition Functions) метод создания функциональной модели;

– IDEF1 – информационной модели, IDEF2 – динамической модели и др.

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

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

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

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

1. Объектно–ориентированный анализ. Создание объектно–ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты–сущности и операции, выполняемые этими объектами.
2. Объектно–ориентированное проектирование. Разработка объектно–ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи.
3. Объектно–ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно–ориентированного языка программирования (С++, Java) для определения объектов и средств определения классов объектов.

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

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

Существует два типа моделей архитектуры ПО:

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

– динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия между объектами системы (но не классами объектов).

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

Язык моделирования UML(United Modeling Language – унифицированный язык моделирования) поддерживает большое количество всевозможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей. Модель последовательностей – одна из наиболее полезных и наглядных моделей, которая в каждом узле взаимодействия документирует последовательность происходящих взаимодействий между объектами.

В UML используются следующие виды диаграмм:

Структурные диаграммы:

– Диаграмма классов (Class diagram)

– Диаграмма компонентов (Component diagram)

– Композитной/составной структуры(Composite structure diagram)

– Диаграмма кооперации (Collaboration) (UML2.0)

– Диаграмма развёртывания (Deployment diagram)

– Диаграмма объектов (Object diagram)

– Диаграмма пакетов (Package diagram)

– Диаграмма профилей (Profile diagram)(UML2.2)

Диаграммы поведения:

– Диаграмма деятельности (Activity diagram)

– Диаграмма состояний (State Machine diagram)

– Диаграмма прецедентов (Use case diagram)

– Диаграммы взаимодействия:

• Диаграмма коммуникации(Communication diagram) (UML2.0) / Диаграмма кооперации (Collaboration) (UML1.x)
• Диаграмма обзора взаимодействия (Interaction overview diagram) (UML2.0)
• Диаграмма последовательности (Sequence diagram)
• Диаграмма синхронизации (Timing diagram) (UML2.0)

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

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

– точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

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

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

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования. Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

Диаграмма развёртывания (Deployment diagram) — служит для моделирования работающих узлов (аппаратных средств,англ. node) и артефактов, развёрнутых на них. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

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

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

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого. Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

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

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) — диаграмма, на которой изображено упорядоченное во времени взаимодействие объектов. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

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

Диаграмма обзора взаимодействия (Interaction overview diagram) — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления. Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

Агентно-ориентированный подход (АОП) к программированию — разновидность представления программ, или парадигма программирования, в которой основополагающими концепциями являются понятия агента и его ментальное поведение, которое зависит от среды, в которой он находится.

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

Агент может обладать такими свойствами:

– автономность – это способность действовать без внешнего управляющего воздействия;

– реактивность – это способность реагировать на изменения данных и среды, и воспринимать их;

– активность – это способность ставить цели и выполнять заданные действия для достижения этой цели;

– социальность – это способность к взаимодействию с другими агентами (или людьми).

В задачи программного агента входят:

– самостоятельная работа и контроль своих действий;

– взаимодействие с другими агентами;

– изменение поведения в зависимости от состояния внешней среды;

– выдача достоверной информации о выполнении заданной функции и т.п.

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

Компонентный подход к проектированию

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

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

Информационная часть представляет собой информацию о компоненте: назначение, дата изготовления, условия применения (ОС, среда, платформа и т.п.); уровень повторного использования; контекст или окружение; способ взаимодействия между собою компонентов.

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

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

– способ интеграции (композиции) компонентов;

– нефункциональные сведения (безопасность, аутентификация, надежность и др.);

– технология проектирования (например, объектно–ориентированная среда и т.п.) и повторное использования компонентов.

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

Как правило, компоненты наследуются в виде классов. Управление компонентами проводится на трех уровнях: архитектурном, компонентном и на уровне инфраструктуры интерфейса.

Внутренняя часть компонента состоит из: интерфейса (interfaces), реализации (implementation), схемы развертки (deployment).

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

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

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

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

Повторноиспользуемые компоненты (ПИК) – элементы знаний о минувшем опыте разработки систем, которые могут использовать не только их разработчиками, но и путём адаптации к новым условиям. ПИК упрощает и сокращает сроки разработки новых программных систем. Высокий уровень стандартизации и распространение электронных коммуникаций (сети Интернет) обеспечивает довольно простое получение и широкое использование готовых компонентов в разных проектах за счет:

– отражения фундаментальных понятий приложения;

– скрытия способа представления и предоставления операций обновления и получения доступа;

– обработки исключительных операций в приложении.

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

– выбора готовых компонентов с подобными функциями, пригодными для практического применения;

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

Методические рекомендации

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

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

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: