Новые абстракции программы добавленные в алгоритмическое проектирование это

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

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

Таким образом, при декомпозиции задачи мы разбиваем ее на ряд подзадач так, что 1)каждая подзадача имеет один и тот же уровень рас­смотрения; 2)каждая задача может быть решена независимо и 3)полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

C++. Паттерн проектирования программ «Абстрактная фабрика (Abstract Factory)».

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

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

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

Абстракция и декомпозиция. Их взаимодействие при проектировании программ.

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

1.6 MVC, архитектура, проектирование и абстракции. | Курс «Паттерны и практики написания кода»

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

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

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

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

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

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

При декомпозиции задачи мы разбиваем ее на ряд подзадач так, что

1. каждая подзадача имеет один и тот же уровень рас­смотрения;
2. каждая задача может быть решена независимо;
3. полученные решения могут быть объединены вместе, позволяя решить исходную проблему.

Источник: studfile.net

Уровни абстракций — ключ к пониманию архитектурных изысков ПО

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

Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования.

Модель объекта и ступень приближения

Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.

Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:

«Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Помнится, видал я такие щёчки у моей ненаглядной Лизоньки, когда мы впервые с ней встретились, и она угощала меня яблочными пирогами, состряпанными на последние деньги, которые она выручила от продажи дедовских коллекционных монет 1819 года, выпущенных при императоре таком-то…» И т.д, и т.п.

Если вы осилили текст курсивом, то вы очевидно заметили, что он имеет весьма посредственное отношение к тому, что нам нужно. Собственно, к тому, как же печь эти чертовы пироги из яблок, не правда ли?

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

А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if…

А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).

Построение структуры

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

Абстракция и Реализация

Есть ещё один момент, о котором я хочу упомянуть: путешествие между слоями логик. Красиво изолированный уровень абстракции достаточно прост для понимания: у нас есть ряд объектов, очевидным образом взаимодействующих между собой, уровни вложенности маленькие (если они вообще есть — как в рецепте пирога). Однако, как нам уже стало понятно, самым трудозатратным для понимания является перемещение между уровнями абстракций.

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

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

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

Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.

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

Источник: techrocks.ru

Лекции в виде ответов на вопросы, страница 4

Документ из архива «Лекции в виде ответов на вопросы», который расположен в категории » «. Всё это находится в предмете «проектирование программных систем» из 9 семестр (1 семестр магистратуры), которые можно найти в файловом архиве МГТУ им. Н.Э.Баумана. Не смотря на прямую связь этого архива с МГТУ им. Н.Э.Баумана, его также можно найти и в других разделах. Архив можно найти в разделе «лекции и семинары», в предмете «проектирование программных систем» в общих файлах.

Онлайн просмотр документа «Лекции в виде ответов на вопросы»

Текст 4 страницы из документа «Лекции в виде ответов на вопросы»

ВОПРОСЫ ПО ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

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

• Этап проектирования не прекращается никогда
• Уточнение требований продолжается в течение всего времени проектирования
• Программная система наследует проблемы реальной системы

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

2. Проблема сложности при проектировании программного обеспечения. Различные виды сложности при проектировании программного обеспечения.

1. Сложность проблемы.

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

1. Сложность управления процессом разработки.

• Большой объем программ и сложная логика функционирования программной системы
• Большой коллектив программистов
• Необходимость согласования технических решений
• Координация работ различных групп программистов
• Поддержание единства и целостности разработки
• Создание документации на программную систему
• Обеспечение временных и финансовых ограничений на разработку

1. Сложность обеспечения гибкости сопровождения конечного продукта.

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

1. Сложность описания поведения отдельных подсистем.

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

3. Основные характерные особенности больших программных систем.

ПРЕДМЕТНАЯ ОБЛАСТЬ – промышленные программные продукты

• Различные области применения
• Сложные в логической организации
• Большие по объему кода
• Имеют много пользователей
• Долгое время жизни (использования)
• Требуют модернизации и сопровождения
• Должны сопровождаться документацией
• Разрабатываются коллективом программистов
• Требуют больших финансовых ресурсов

4. Определение требований к проектируемому программному обеспечению. Управление требованиями.

1. Постановка задачи.

• Нужно понять, что нужно сделать
• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью
• Нельзя ориентироваться только на требования одного, но влиятельного лица. Система обрекается на недолговечность. Должен быть найден и вовлечен в дело действительный пользователь, а не его заменитель
• Разные пользователи дают противоречивые требования
• Представитель заказчика должен иметь полномочия принимать решения

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью
• Язык формулировок требований должен быть понятен пользователю и проектировщику
• Нужно документировать требования
• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

3. Управление требованиями.

• Предусмотреть изменения в проекте .
• Самое первое требование к проектированию больших систем – предусмотреть возможность будущих изменений
• Требования разработчики и заказчики понимают по-разному
• Требованиями надо управлять .

5. Документирование процесса проектирования. Назначение документирования. Требование к документированию.

• Если отсутствует документация доступная для всех – проект обречен на неудачу
• Дональд Дуглас – «когда вес документов достигает веса самолета, самолет начнет летать»
• Документация создается на всех уровнях проектирования
• Использовать методы документирования (HIPO, SADT, IA, UML)
• Самая трудная задача – организовать ведение документации

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью
• Язык формулировок требований должен быть понятен пользователю и проектировщику
• Нужно документировать требования
• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

6. Использование декомпозиции при проектировании больших программных систем. Декомпозиция при алгоритмическом подходе. Декомпозиция при объектно-ориентированном подходе.

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

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

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

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

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

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

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

перед алгоритмической декомпозицией:

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

7. Требования к программным модулям при проведении декомпозиции.

• Функциональная прочность
• Информационная прочность
• Сцепление по данным
• Сцепление по общей области
• Сцепление по управлению
• Размер модуля

Хороший программный модуль

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

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

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

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

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

8. Роль абстракции в процессе проектирования. Барьер абстракции. Абстракции сущности и абстракции поведения.

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

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

∙ Абстракция сущности

Объект представляет собой полезную модель некой сущности в предметной области

∙ Абстракция поведения

Объект состоит из обобщенного множества операций

∙ Абстракция виртуальной машины

Объект группирует операции, которые либо вместе используются более высоким уровнем управления, либо сами используют некоторый набор операций более низкого уровня

∙ Произвольная абстракция

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

9. Уровень реализации. Критерии выбора языка программирования и стандартов программирования.

• Выбор языка программирования
• Выбор стандартов программирования
• Выбор инструментария программирования
• Проектирование диалогового взаимодействия
• Уровни квалификации. Главный программист
• Компоновка программ
• Контроль версий системы

• Какова природа задачи, которую Вы программируете?
• Предстоит ли реализовать сложный алгоритм, или же нужно написать простую процедуру из нескольких строк?
• Имеет ли задача много независимых частей?
• Можно ли поделить программу на несколько раздельно компилируемых функций, или это будет один модуль?
• Как скоро программа должна быть готова?
• Нужно ли написать программу быстро, не заботясь об ее эффективности, или имеется достаточно времени для разработки наиболее эффективной программы?
• Какова область применения программы?
• Будет ли программа использоваться только ее автором, или она будет широко распространяться?
• Будет ли программа переноситься на другие системы?
• Как долго будет эксплуатироваться программа?
• Будет ли она использована всего несколько раз, или планируется ее применение в течение нескольких лет?

10. Проектирование программных систем. Главный программист, его задачи и функции.

• Проектирование в большей степени связано с искусством
• Программа наследует все проблемы реальной системы
• При проектировании делается обоснование как ПО так и ТС
• Проектирование — итерационный процесс
• Проектированием может заниматься не каждый

• Этап проектирования не прекращается никогда
• Уточнение требований продолжается в течение всего времени проектирования
• Программная система наследует проблемы реальной системы

• Разбиение на уровни абстракций
• На каждом уровне абстракции – 7 или менее элементов
• Ограниченный контекст, только важные элементы
• Должны определяться как данные, так и операции над ними

• Верхний уровень – разделение на подсистемы, модули. Определение взаимодействия. Реализация замкнутости подсистем.
• Средний уровень – реализация технических решений. Выделение макрослоев. Проектирование модулей. Определение потоков данных.
• Нижний уровень – кодирование программ. Технологии кодирования. Структурное программирование.

Главный Программист

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

Источник: studizba.com