Вопросы и ответы (старое, есть ошибки), страница 6

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

Виды декомпозиции:

• алгоритмическая (разбиение на подпрограммы)

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

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

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

На этапе декомпозиции, обеспечивающем общее представление о решаемой проблеме, осуществляются:

• определение и декомпозиция общей цели исследования;

• выделение проблемы из среды, определение её ближнего и дальнего окружения;

описание воздействующих факторов.

Наиболее часто декомпозиция проводится путём построения дерева целей и дерева функций. Основной проблемой при этом является соблюдение двух противоречивых принципов:

• полноты — проблема должна быть рассмотрена максимально всесторонне и подробно;

• простоты — всё дерево должно быть максимально компактным «вширь» и «вглубь».

Принципиально можно выделить 2 вида разбиения предметной области на составляющие элементы:

• Алгоритмическая декомпозиция (основные элементы программы - строительные блоки - алгоритмы).

• Объектная декомпозиция (основные элементы программы - виды абстракций (классы) и представители этих классов (объекты)).

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

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

На сегодняшний день объектный подход и его основы - объектная модель и объектная декомпозиция - поддерживаются современными объектно-ориентированными языками программирования (Object Pascal, C++, Java, C#,…).

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

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

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

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

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

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

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

Алгоритмическая Декомпозиция

Объектнаяя Декомпозиция

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

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

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

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

Основное про абстракцию – см. вопрос 2, стр.3

Пример абстракции

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

Одна из ключевых абстракций в такой задаче - датчик. Известно несколько разновидностей датчиков. Все, что влияет на урожай, должно быть измерено, так что мы должны иметь датчики температуры воды и воздуха, влажности, рН, освещения и концентрации питательных веществ. С внешней точки зрения датчик температуры - это объект, который способен измерять температуру там, где он расположен. Что такое температура? Это числовой параметр, имеющий ограниченный диапазон значений и определенную точность, означающий число градусов по Фаренгейту, Цельсию или Кельвину. Что такое местоположение датчика? Это некоторое идентифицируемое место в теплице, температуру в котором нам необходимо знать; таких мест, вероятно, немного. Для датчика температуры существенно не столько само местоположение, сколько тот факт, что данный датчик расположен именно в данном месте и это отличает его от других датчиков. Теперь можно задать вопрос о том, каковы обязанности датчика температуры? Мы решаем, что датчик должен знать температуру в своем местонахождении и сообщать ее по запросу. Какие же действия может выполнять по отношению к датчику клиент? Мы принимаем решение о том, что клиент может калибровать датчик и получать от него значение текущей температуры.

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

РЕАЛИЗАЦИЯ

• Выбор языка программирования

• Выбор стандартов программирования

• Выбор инструментария программирования

• Проектирование диалогового взаимодействия

• Уровни квалификации. Главный программист

• Компоновка программ

• Контроль версий системы

Какой язык программирования использовать? На этот вопрос можно ответить, например, так: "Я всегда пишу программы на ФОРГОЛе, потому что знаю его лучше всего." В некоторых обстоятельствах это действительно разумное решение. Но если предположить, что Вы знаете более одного языка, что различные языки имеют сильные и слабые стороны, что, зная один язык, относительно легко изучить другой, вопрос выбора языка становится более содержательным. При выборе языка можно попытаться ответить на следующие вопросы:

• Какова природа задачи, которую Вы программируете?

• Предстоит ли реализовать сложный алгоритм, или же нужно написать простую процедуру из нескольких строк?

• Имеет ли задача много независимых частей?

• Можно ли поделить программу на несколько раздельно компилируемых функций, или это будет один модуль?

• Как скоро программа должна быть готова?

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

• Какова область применения программы?

• Будет ли программа использоваться только ее автором, или она будет широко распространяться?

• Будет ли программа переноситься на другие системы?

• Как долго будет эксплуатироваться программа?

• Будет ли она использована всего несколько раз, или планируется ее применение в течение нескольких лет?

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

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

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

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

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

• Проектирование в большей степени связано с искусством

• Программа наследует все проблемы реальной системы

• При проектировании делается обоснование как ПО так и ТС

• Проектирование - итерационный процесс

• Проектированием может заниматься не каждый

Принипы:

• Этап проектирования не прекращается никогда

• Уточнение требований продолжается в течение всего времени проектирования

• Программная система наследует проблемы реальной системы

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

• Разбиение на уровни абстракций

• На каждом уровне абстракции – 7 или менее элементов

• Ограниченный контекст, только важные элементы

• Должны определяться как данные, так и операции над ними

УРОВНИ ПРОЕКТИРОВАНИЯ

• Верхний уровень – разделение на подсистемы, модули. Определение взаимодействия. Реализация замкнутости подсистем.

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

• Нижний уровень – кодирование программ. Технологии кодирования. Структурное программирование.

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

Задачи:

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

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

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