Что такое постановка задачи в программировании

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

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

Все диаграммы используют единую графическую нотацию.

В диаграммах используется три типа графических элементов, имеющих различное назначение:

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

Нотация языка UML определяет использование следующих основных видов диаграмм:

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

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

Любая модель должна содержать только те элементы, которые определены в нотации языка UML. Каждый элемент может быть использован только в соответствии с назначением и по правилам, определенным в языке.

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

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

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

Каждая модель конкретной программной системы может содержать все или только некоторые типы диаграмм.

Тема 13. Постановка задачи и спецификация программы

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

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

Характеристики Хорошей Постановки Задачи:

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

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

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

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

Стандартная форма постановки задачи.

Рассмотрим следующую постановку задачи: «Ввести три числа и вывести числа в порядке».

Такая постановка не удовлетворяет приведенным выше требованиям: она не является ни точной, ни полной, ни понятной. Действительно, должны ли числа вводиться по одному на строке или все числа на одной строке? Означает ли выражение «в порядке» упорядочение от большего к меньшему, от меньшего к большему или тот же порядок, в каком они были введены.

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

наименование задачи (схематическое определение);

общее описание (краткое изложение задачи);

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

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

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

Метод нисходящей разработки заключается в следующем. Как и в предыдущем методе сначала строится модульная структура программы в виде дерева. Затем поочередно программируются модули программы, начиная с модуля самого верхнего уровня (головного), переходя к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается. После того, как все модули программы запрограммированы, производится их поочередное тестирование и отладка в таком же (нисходящем) порядке. При таком порядке разработки программы вся необходимая глобальная информация формируется своевременно, т.е. ликвидируется весьма неприятный источник просчетов при программировании модулей. Существенно облегчается и тестирование модулей, производимое при нисходящем тестировании программы. Первым тестируется головной модуль программы, который представляет всю тестируемую программу и поэтому тестируется при «естественном» состоянии информационной среды, при котором начинает выполняться эта программа. При этом все модули, к которым может обращаться головной модуль, заменяются их имитаторами (так называемые заглушки [5]). Каждый имитатор модуля представляется весьма простым программным фрагментом, сигнализирующим, в основном, о самом факте обращения к имитируемому модулю с необходимой для правильной работы программы обработкой значений его входных параметров (иногда с их распечаткой) и с выдачей, если это необходимо, заранее запасенного подходящего результата. После завершения тестирования и отладки головного и любого последующего модуля производится переход к тестированию одного из модулей, которые в данный момент представлены имитаторами, если таковые имеются. Для этого имитатор выбранного для тестирования модуля заменяется на сам этот модуль и добавляются имитаторы тех модулей, к которым может обращаться выбранный для тестирования модуль. При этом каждый такой модуль будет тестироваться при «естественных» состояниях информационной среды, возникающих к моменту обращения к этому модулю при выполнении тестируемой программы. Таким образом, большой объем «отладочного» программирования заменяется программированием достаточно простых имитаторов используемых в программе модулей. Кроме того, имитаторы удобно использовать для подыгрывания процессу подбора тестов путем задания нужных результатов, выдаваемых имитаторами.

Лекция 8

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:

Как решить любую задачу: пособие для разработчика

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

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

Оба ответа неправильные.

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

О «требованиях»

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

В конечном счете наша цель как разработчиков – решать проблемы. Каким бы способом вы ни получили задачу, чтобы решить ее, вы должны ее понять.

О шагах

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

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

Первый шаг: анализ задачи

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

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

Классифицируйте задачу

Определите, к какому типу относится работа, которую вам нужно выполнить. Это может быть:

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

Это не все возможные типы задач, но теперь вы понимаете, о чем идет речь.

Основная цель на этом этапе – определить вид работы. Это очень важно, поскольку будет напрямую влиять на ваши дальнейшие действия.

Особую важность имеет первый шаг в том случае, если требования составлены нечетко, вроде «нам нужен способ очистить кэш клиентов после обновления веб-сайта». Это можно интерпретировать по-разному:

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

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

Сформулируйте задачу в паре простых фраз

Обобщите требования в одном или двух предложениях. Возможно, это будет не очень просто, но у вас обязательно получится.

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

Хороший пример обобщения: «при обновлении мы добавляем файлам уникальный идентификатор, чтобы браузер знал, что нужно использовать самый свежий код». Тест на простоту пройден, задача не нуждается в делении.

А пример плохой постановки задачи. «При обновлении мы добавляем файлам уникальный идентификатор, чтобы браузер знал, что нужно использовать самый свежий код. Также мы должны отправить сообщение об обновлении в CDN. Также следует обновить приложение в app store. Также…».

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

Выделите основные части

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

Помните, что сейчас вы все еще анализируете задачу, а не решаете ее.

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

Наметим основные части:

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

Теперь этот список можно использовать для быстрого обсуждения с командой или руководителем, после которого могут быть внесены новые пункты, например:

• Нужно добавить для пользователя возможность сообщить о том, что он больше не хочет видеть конкретные объявления.Вы же не хотите раздражать ваших любимых клиентов!

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

Возможно, вы считаете, что вся эта работа должна быть выполнена еще до того, как разработчик получит требования – и это на 100% верно!

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

Определите проблему, которую вы пытаетесь решить

Определитесь, какую существующую или предполагаемую проблему реального мира вы пытаетесь решить.

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

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

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

Второй шаг: разбор и оценка требований

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

Уточните все термины, связанные с задачей

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

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

Возможно, вы знаете, что значит создать доступ к агрегированным данным о пользователе, а как насчет ее добавления в DAO? А имеете ли вы представление о том, что такое MADF в форматировании рекламных данных?

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

Определите, как должна быть выполнена задача

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

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

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

Определите, решены ли проблемы

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

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

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

Третий шаг: критическое мышление

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

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

Сформулируем некоторые основные правила о разногласиях.

Когда не соглашаться

• Не возражайте, пока не поймете полностью.

Вы хорошо понимаете, с чем именно несогласны? Если у вас нет всех необходимых данных, самое время вернуться к предыдущим шагам.

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

«Мне не нравится» – это субъективно. “Большое количество операций плохо повлияет на производительность» – это объективно.

• Подготовьте аргументированное объяснение вашего несогласия.

Вы не способны объяснить, почему это неправильно? А вы уверены, что это действительно неправильно?

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

Как не соглашаться

Чтобы ваше несогласие было объективным, оно должно ясно демонстрировать, что принятое решение:

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

Подведем итоги

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

Вот упрощенный список шагов:

Шаг 1. Анализ

• Классификация задачи;
• Резюме в паре предложений;
• Выделение основных частей;
• Определение проблемы.

Шаг 2. Разбор и оценка

• Уточнение терминов;
• Составление общего плана реализации;
• Проверка, решает ли этот план проблему.

Шаг 3. Критическое мышление

• Знайте, когда не соглашаться;
• Знайте, как не соглашаться.

Используете ли вы эти приемы? А может быть, у вас есть своя система для понимания сложных задач? Расскажите о ней в комментариях.