Основные принципы системного подхода

Сущность системного анализа

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

Классификация проблем

Согласно классификации, все проблемы подразделяются на три класса:

· хорошо структурированные (well-structured), или количественно сформулированные проблемы, в которых существенные зависимости выяснены очень хорошо;

· неструктурированные (unstructured), или качественно выраженные проблемы, содержащие лишь описание важнейших ресурсов, признаков и характеристик, количественные зависимости между которыми совершенно неизвестны;

· слабо структурированные (ill-structured), или смешанные проблемы, которые содержат как качественные элементы, так и малоизвестные, неопределенные стороны, которые имеют тенденцию доминировать.

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

· абстрагирование и конкретизация

· анализ и синтез, индукция и дедукция

· формализация и конкретизация

· композиция и декомпозиция

· линеаризация и выделение нелинейных составляющих

· структурирование и ре структурирование

· макетирование

· ре инженеринг

· алгоритмизация

· моделирование и эксперимент

· программное управление и регулирование

· распознавание и идентификация

· кластеризация и классификация

· экспертное оценивание и тестирование

· верификация

· и другие методы и процедуры.

Процедура принятия решений включает следующие основные этапы:

· формулировка проблемной ситуации;

· определение целей;

· определение критериев достижения целей;

· построение моделей для обоснования решений;

· поиск оптимального (допустимого) варианта решения;

· согласование решения;

· подготовка решения к реализации;

· утверждение решения;

· управление ходом реализации решения;

· проверка эффективности решения.

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

Основные принципы системного подхода

Целостность, Иерархичность, Структуризация, Множественность, Системность.

Аспекты системного подхода

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

· системно-элементного или системно-комплексного, состоящего в выявлении элементов, составляющих данную систему.

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

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

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

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

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

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

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

3. Проектирование сложных объектов основные принципы проектирования.

 

4. Аспекты и стадии проектирования

При проектировании сложных систем выделятся следующие стадии.

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

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

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

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

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

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

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

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

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

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

Следует отметить, что понятие аспекта уровня проектирования относится к структурированию представлений о проектируемом объекте, а понятие этапа - к структурированию процесса проектирования.

По характеру и степени участия человека и использования ЭВМ различают несколько режимов проектирования.

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

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

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

 

5. Нисходящее и восходящее проектирование и программирование

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

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

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

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

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

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

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

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

Основные достоинства нисходящего проектирования:

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

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

одновременная параллельная работа нескольких программистов может оказаться эффективной.

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

 

 

6. Развитие парадигмы программирования (Операциональное программирование, нисходящая технология конструирования программ.Структурное, модульное, объектное и объектно-ориентированное программирование)

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

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

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

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

Структурное программирование

Некоторые представители: Fortran, Pascal, C.

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

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

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

Объектно-ориентированное программирование

Представители объектно-ориентированных языков: С++, Java, Python.

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

ООП призвано решать более сложные и объемные задачи по сравнению с директивным программированием.

В основе ООП лежат такие понятия как наследование, полиморфизм и инкапсуляция.

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

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

Операциональное программирование (языки программирования типа ассемблеров, Бейсика, Фортрана). Программа «собирается» из мелких деталей, отдельных операций и имеет достаточно простую структуру: область глобальных данных и подпрограммы. Уровень абстрагирования - отдельное действие, принципы декомпозиции задачи отсутствуют, во всяком случае, о них не говорят.

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

формализованное и строгое описание программистом входов функций и выходов всех модулей программы и системы;

согласованная разработка структур данных и алгоритмов;

ограничение на размер модулей.

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

Модульное программиро вание. Достаточно независимые фрагменты задачи оформляются как модули. Создаются библиотеки модулей, разрабатывается механизм включения модулей в разрабатываемую программу. Модуль должен иметь строго определенный интерфейс и скрытую часть, одну точку входа и одну точку выхода. Из фольклора computerscience - «модульность в программировании подобна честности в политике: каждый утверждает, что она - одно из его достоинств, но кажется, никто не знает, что она собой представляет, как ее привить, обрести или добиться». Очередной этап развития принципа декомпозиции задачи и абстрагирования.

 

 

7. Суть и метод структурного анализа. Основные этапы структурного анализа.

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

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

Проведение структурного анализа организации предполагает нескольких этапов:

построение иерархии целей оптимизации деятельности организации;

выбор методологии;

выбор моделей;

анализ деятельности организации;

• разработка моделей в соответствии с

иерархией целей;

оптимизация моделей;

реорганизация деятельности.

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

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

 

8. Программные системы и их жизненный цикл.

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

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

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

 

9. Анализ целевых и разработка требований к программным системам.

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

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

Анализ требований включает три типа деятельности:

 Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.

 Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.

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

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

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

Функциональная спецификация состоит из трех частей:

1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение.

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

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

Общие требования к программным системам:

 Максимум удобств пользователя

 Адаптируемость ПО

 Гибкость

 Мобильность

 Масштабируемость, расширяемость и модифицируемость.

 Эффективность работы.

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

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

Системные требования – описывают требования, выдвигаемые информационной системой среде своего функционирования (системной, аппаратной).

 

10. Функциональное моделирование. Стандарты IDEF0, IDEF3.

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

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

ПаттернMediator (посредник)

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

Структура

Mediator посредник:- определяет интерфейс для обмена информацией с объектами С;

ConcreteMediator конкретный посредник: - реализует кооперативное поведение, координируя действия объектов C;

Классы C, A, B. Каждый из таких классов "знает" о своем объекте Mediator; - все объекты этих классов обмениваются информацией только с посредником, так как при его отсутствии им пришлось бы общаться между собой напрямую

У паттерна посредник есть следующие достоинства и недостатки:

устраняет связанность между подклассами С. Изменять классы C и Mediator можно независимо друг от друга;

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

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

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

ПаттернObserver (наблюдатель). Dependents (подчиненные), Publish-Subscribe (издатель-подписчик).

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

Структура и участники

Subject - субъект: располагает информацией о своих наблюдателях. За субъектом может «следить» любое число наблюдателей; так же субъект предоставляет интерфейс для присоединения и отделения наблюдателей;

Observer- наблюдатель: определяет интерфейс обновления для объектов, которые должны быть уведомлены об изменении субъекта;

ConcreteSubject - конкретный субъект: сохраняет состояние, представляющее интерес для конкретного наблюдателя ConcreteObserver; посылает информацию своим наблюдателям, когда происходит изменение;

ConcreteObserver - конкретный наблюдатель; Хранит ссылку на конкретного субъекта для получения доступа к состоянию последнего.

ПаттернState (состояние)

Позволяет объекту варьировать свое поведение в зависимости от внутреннего состояния. Извне создается впечатление, что изменился класс объекта.

ПаттернStrategy (стратегия). Policy (политика).

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

ПаттернTemplateMethod (шаблонный метод).

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

 

 

39. Разработка программной архитектуры и кодирование приложений на основе лучших типовых решений.Методы качественной разработки и усовершенствования программного кода. Понятия эффективности и качества программного обеспечения (ПО).

Чтобы понять, как проектировать конкретное программное решение, очень важно знать, как связаны между собой каркасы и шаблоны. Стандартное определение каркасов — наборы взаимосвязанных классов для многократно используемого проектирования определенного класса программного обеспечения [Гамма и др., 1995 г.]. Рабочий термин в определении — «класс программного обеспечения». Под этим подразумевается, что он выполняет определенную функцию в рамках программного решения. Каркасы часто основываются на шаблонах — универсальных решениях задачи с программной реализацией в определенном контексте. Основное различие между каркасами и шаблонами заключается в том, что каркасы являются реализацией программных конструкций, а шаблоны задают определение того, как решить ту или иную задачу с программной реализацией.

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

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

План исполнения

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

1. Определил границы системы

2. Определил структуру решения

3. Определил каркасы

4. Сопоставил функциональные требования с каркасами

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

· Какую задачу мне нужно решить?

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

· Как такая задача была решена в прошлом?

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

· Как может это решение расширяться в будущем?

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

 

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

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

Цель рефакторинга — сделать код программы более легким для понимания.

Рефакторинг нужно применять постоянно при разработке кода.

Можно выделить наиболее очевидные причины, когда код нужно подвергнуть рефакторингу:

· Дублирование кода

· Длинный метод

· Большой класс

· Длинный список параметров и др.

В программировании термин рефакторинг означает изменение исходного кода программы без и