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


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

Сегодня процесс создания сложных программных приложений невозможно представить без разделения на этапы жизненного цикла. Под жизненным циклом программы будем понимать совокупность этапов: Остановимся детально на процессе проектирования. В ходе проектирования архитектором или опытным программистом создается проектная документация, включающая текстовые описания, диаграммы, модели будущей программы. В этом нелегком деле нам поможет язык UML. UML — является графическим языком для визуализации, описания параметров, конструирования и документирования различных систем (программ в частности). Диаграммы создаются с помощью специальных CASE средств, например Rational Rose (http://www-01.ibm.com/software/rational/) и Enterprise Architect (http://www.sparxsystems.com.au/). На основе технологии UML строится единая информационная модель. Приведенные выше CASE средства способны генерировать код на различных объектно-ориентированных языках, а так же обладают очень полезной функцией реверсивного инжиниринга. (Реверсивный инжиниринг позволяет создать графическую модель из имеющегося программного кода и комментариев к нему.)

Рассмотрим типы диаграмм для визуализации модели (это must have, хотя типов гораздо больше):

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

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

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

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

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

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

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

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

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

habrahabr.ru

Проектирование программ | Планета информатики

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

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

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

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

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

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

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

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

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

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

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

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

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

www.inf1.info

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

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

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

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

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

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

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

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

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

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

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

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

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

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

www.inf1.info

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

Новые рефераты:

referatwork.ru

С чего начать проектирование программы? Часть 1

С чего начать проектирование программы? Классический объектно-ориентированный подход даёт нам однозначный ответ на этот вопрос: с выявления ключевых абстракций и построения объектной модели предметной области.

Джеймс Рамбо, один из создателей языка UML и Rational Unified Process'а, в своей книге "UML 2.0. Объектно-ориентированное моделирование и разработка" предлагает нам такой алгоритм проектирования:

  1. Изучить предметную область и выделить классы предметной области.
  2. Удалить лишние классы (несущественные или избыточные).
  3. Связать классы ассоциациями.
  4. Выделить в классах атрибуты.
  5. Реструктуризовать классы при помощи наследования.
  6. Добавить классы приложения.
  7. Добавить операции.
Дж. Рамбо, М. Блаха. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2007, стр. 218 – 285.

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

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

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

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

Вернёмся к вопросу, вынесенному в заголовок. С чего начать проектирование программы?

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

Проектирование любой программы должно начинаться:

1)      с составления списка полезных функций, которые должна выполнять программа;

2)      с проектирования технологии реализации каждой полезной функции.

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

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

Его можно описать в текстовом виде при помощи вариантов использования (см.:  Коберн, Алистер. Современные методы описания функциональных требований к системам/Пер. с англ. – М.: Издательство «Лори», 2002 г. – 263 с.: ил.) и в виде диаграммы (например, блок-схемы, flowchart'а).

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

Требования к метеорологической станции Система должна обеспечивать автоматический мониторинг следующих первичных погодных параметров: Система также должна вычислять некоторые производные параметры, в число которых входят: В системе должна быть предусмотрена возможность определения текущего времени и даты, которые будут использоваться при генерации сообщении о максимальных и минимальных значениях первичных параметров за последние 24 часа. Система должна обеспечивать постоянный вывод на дисплей текущих значений всех восьми первичных и производных параметров, а также текущее время и дату. Пользователь должен иметь возможность увидеть максимальные и минимальные значения любого из первичных параметров за 24 часа, сопровождаемые информацией о времени произведения соответствующего замера.Система должна позволять пользователю проводить калибровку датчиков по известным опорным значениям, а также устанавливать текущие время и дату. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер с англ. – М.: "Издательство Бином", СПб: "Невский диалект", 1998 г., стр. 284, или: http://www.helloworld.ru/texts/comp/other/oop/ch08.htm

Начнём проектирование системы с описания процесса измерения и отображения температуры.

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

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

Внесём в диаграмму изменения:

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

Внесём соответствующие изменения:

Сообщение от датчика температуры, скорее всего, закодировано в определённом формате (например, в формате json или в специализированном XML). Соответственно, потребуется парсер, который понимает этот формат:

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

Отобразим этап преобразования градусов на диаграмме:

Наконец, температуру нужно показать в определённом месте экрана (или в определённом окне).

Внесём изменения в схему:

Получилось достаточно подробное описание процесса измерения и отображения температуры.

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

В этом случае, диаграмма процесса будет выглядеть так:

Наряду с такими компонентами, как:

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

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

Приведём список классов и операций:

Читает данные, пришедшие на порт.

Читает данные с порта по определённому протоколу.

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

Разбирает сообщение от датчика температуры.

Barometric Pressure Parser

Разбирает сообщение от датчика атмосферного давления.

Преобразует температуру из одних единиц в другие.

Barometric Pressure Converter

Преобразует атмосферное давление из одних единиц в другие.

Отображает температуру в специальном окне.

Barometric Pressure Window

Отображает атмосферное давление в специальном окне.

Отображает окна на экране.

ЛИТЕРАТУРА:

1.      Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2-е изд./Пер с англ. – М.: "Издательство Бином", СПб: "Невский диалект", 1998 г. Или: http://www.helloworld.ru/texts/comp/other/oop/index.htm 4.      Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд./Пер. с англ. – СПб.: Питер, 2007. – 544 с.: ил.

askofen.blogspot.ru

Тема 13. Методы проектирования программ

ТЕМА 13. МЕТОДЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ.

13.1 Метод пошаговой детализации.

Термин проекта применительно к научно-тех­ни­че­с­ким приложениям обозначает план, прообраз какого-либо объекта.

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

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

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

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

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

Рис.9. Схема стадий пошаговой детализации методом ие­ра­р­хи­че­с­кой декомпозиции на функциональные элементы с 5-ю уровнями при проектировании программы.

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

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

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

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

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

Другим важным составным элементом современной те­х­но­ло­гии проектирования программ является нисходящее про­е­к­ти­ро­ва­ние на основе структурного программирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В руководстве оператора дается вся необходимая информация для обеспечения процедуры общения (взаимодействия) оператора с ЭВМ в процессе выполнения программы.

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

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

lib2.podelise.ru

Рекомендуемые программы для проектирования и моделирования САПР для Windows CAD, CAM, CAE

Solid Edge Solid Edge с синхронной технологией - поэлементная 2D/3D САПР без истории построения. CadStd Lite Специализированный графический редактор для создания проектов в области машиностроения, строительства, а также чертежей, схем и диаграмм. nanoCAD Первая отечественная свободно распространяемая базовая САПР-платформа для различных отраслей Volo View Express Продукт для отображения и вывода на печать файлов основных чертежных форматов. TurboCAD Deluxe Программное приложение для 2D и 3D проектирования и черчения. IntelliCAD 2000 IntelliCAD - САПР, предназначенная для архитекторов, инженеров, проектировщиков и других разработчиков. IntelliCAD обеспечивает полную совместимость с Autodesk AutoCAD, совместим с сотнями решений для AutoCAD от третьих лиц. NormCAD Выполняет расчеты строительных конструкций по СНиП и готовит проектную документацию для представления заказчику и в органы экспертизы. Kompas-3D LT Свободно распространяемой, для некоммерческого использования, версией CAD-системы российской компании ASCON. Lite вариант позволяет свободное использование в школах, техникумах и институтах. Так же вы можете свободно делать копии этого дистрибутива для своих студентов. CoCreate Приложение 3D CAD, в основу которого лег принцип динамического моделирования. Программа позволяет создавать объекты, собранные из множества (вплоть до шестидесяти) частей. CoCreate OneSpace Modeling PE 1.0 не похожа на прочие CAD приложения, разработчики обещают простоту и продуктивность, сравнимую разве что с приложениями Office. DipTrace Free Edition Отечественная программа для проектирования печатных плат. В состав программы входят 4 редактора, которые позволят спроектировать схему, создать схемные элементы в символьном виде и привязать их к корпусам, которые тоже можно создать самостоятельно. JustCAD Простое приложение, позволяющее выполнять простейшие основные операции с примитивами. Благодаря своему малому размеру и низкими системным требованиям данным приложением может воспользоваться любой желающий. На сайте разработчика можно скачать дополнительные библиотеки и элементы программы. Имеет почти все нужные иснтрументы для черчения: геометрические объекты, слои, привязки, текст и многое другое. В бесплатной версии отсутствует поддержка формата DXF и штриховки. OCTREE САПР для 3D архитектурного моделирования, черчения и визуализации Project StudioCS Электрика Программа Project StudioCS Электрика предназначена для автоматизации проектирования системы электроснабжения (СЭС) объектов гражданского и промышленного строительства в строгом соответствии с действующими стандартами. ExpressSCH Программа для рисования схем электрических принципиальных плат. Project Studio CS Водоснабжение Project StudioCS Водоснабжение – программа для проектирования внутренних систем водопровода и канализации в среде AutoCAD.Системы холодного и горячего водоснабжения, канализации, водяного пожаротушения. AllyCAD Профессиональный CAD пакет с продвинутыми функциональными возможностями и интегрированными наборами инструментов. AllyCAD является быстрой, мощной и очень простой в использовании программой для создания 2D-чертежей. Она предназначена для использования в таких областях как строительная механика, гражданское строительство, архитектура и геодезия и пр. Solid Edge Мощная комбинированная система проектирования в 2D и 3D, технология моделирования без дерева построения, ориентация на потребности определенной отрасли промышленности и полностью интегрированное управление разработками позволяет выполнять проекты в срок . DWG TrueView Одна из немногих бесплатных утилит для просмотра и, что более важно, печати чертежей созданных в Автокаде. Из основных недостатков стоит назвать разве что пугающий размер дистрибутива - две сотни мегобайт для программы просмотра и печати. Free DWG viewer Утилита для просмотра файлов Автокада, гораздо более компактная чем просмотрщик от Автодеска, однако, увы, не поддерживающая печать файлов DWG. Программный комплекс «ЛИРА» Программный комплекс ЛИРА является современным инструментом для численного исследования прочности и устойчивости конструкций и их автоматизированного проектирования. nanoCAD СКС Программный продукт nanoCAD СКС предназначен для автоматизированного проектирования структурированных кабельных систем (СКС) зданий и сооружений различного назначения, кабеленесущих систем и телефонии. nanoTDMS Корадо Автоматизированное средство информационной поддержки создания, коллективной разработки, хранения и повторного использования документов. Корадо – это первое приложение, реализованное на платформе nanoTDMS. BtoCAD Стабильная и доступная система автоматизированного проектирования. Это надёжная и удачная альтернатива AutoCAD Полноценная поддержка формата DWG и DXF. Revit Architecture 2009 Специализированная САПР для архитектурно-строительного проектирования с применением технологии информационного моделирования зданий и сооружений в промышленном и гражданском строительстве. Гемма - 3D Система ГеММа-3D, современное технологическое инструментальное средство программирования обработки для станков с ЧПУ. nanoCAD Планировка Решение, предназначенное для различных организаций и подразделений, работающих с поэтажными планами и решающих вопросы управления собственностью. При разработке программного обеспечения учтены российские стандарты и особенности учета и инвентаризации недвижимости. nanoCAD Планировка может использоваться как графический компонент систем управления и эксплуатации школ, больниц, гостиниц, офисных и административных зданий, производственных помещений. MSC.Patran Интерактивный программный продукт с открытой архитектурой, обеспечивающий интеграцию автоматизированных систем проектирования, моделирования, анализа и оценки результатов вычислений. Использование MSC.Patran в сочетании с другими программными продуктами компании MSC.Software позволяет достичь наибольшей эффективности и оптимальности конструкций изделий ещё на этапе разработки, до того, как начнётся изготовление и испытание опытного образца. MSC.Nastran Программа конечно-элементного анализа. MSC.Nastran обеспечивает полный набор расчетов, включая расчет напряженно - деформированного состояния, собственных частот и форм колебаний, анализ устойчивости, решение задач теплопередачи, исследование установившихся и неустановившихся процессов, акустических явлений, нелинейных статических процессов, нелинейных динамических переходных процессов, расчет критических частот и вибраций роторных машин, анализ частотных характеристик при воздействии случайных нагрузок, спектральный анализ и исследование аэроупругости. LVMFlow Компьютерная система моделирования тепловых и гидродинамических процессов литья, созданная в лаборатории математического моделирования УдГУ (Ижевск). LVMFlow позволяет автоматизировать рабочее место технолога-литейщика и снизить затраты времени и средств на подготовку новых изделий. MSC.ADAMS Программная система, предназначенная для виртуального моделирования сложных машин и механизмов. АРМ WinMachine Инструментально-экспертная система APM WinMachine представляет собой комплексное программное обеспечение для автоматизированного расчета и проектирования в машиностроении и строительстве. APM WinMachine - своего рода энциклопедия по машиностроению, включающая инструменты и программы для автоматизированного расчета и проектирования деталей машин, механизмов, элементов конструкций и узлов. APM Civil Engineering CAD/CAE система автоматизированного проектирования строительных объектов гражданского и промышленного назначения. Эта система в полном объеме учитывает требования государственных стандартов и строительных норм и правил, относящиеся как к оформлению конструкторской документации, так и к расчетным алгоритмам. ADEM Российская интегрированная CAD/CAM/CAPP система предназначена автоматизации конструкторско-технологической подготовки производства (КТПП). A9CAD Программа автоматизированного проектирования и создания чертежей. Поддерживает промышленный стандарт DWG/DXF. Позволяет создавать такие элементы чертежей, как: линия, прямоугольник, круг, ломаная линия, текст; выполнять такие операции над рисунком, как: перемещение, масштабирование, вращение, подрезание, зеркальное отражение; позволяет редактировать цвет, выравнивать ширину рисунка и т.д. nanoCAD СПДС Представляет собой универсальную двумерную графическую систему автоматизированного проектирования, предназначенную для выполнения чертежей и оформления рабочей документации в архитектурно-строительном проектировании и смежных отраслях. МВТУ Предназначена для детального исследования и анализа нестационарных процессов в системах автоматического управления, в ядерных и тепловых энергоустановках, в следящих приводах и роботах, в любых технических системах, описание динамики которых может быть реализовано методами структурного моделировани. Является альтернативой продуктам SIMULINK, VisSim, MATRIXx и др. nanoCAD Механика Универсальная двумерная графическая система nanoCAD Механика проектирования систем гидропневмоэлементов, зубчатых зацеплений, валов, расчета размерных цепей, создания пользовательских библиотек, оформления чертежей в соответствии с ЕСКД. Bricscad Система автоматического проектирования, созданной на основе IntelliCAD Универсальный механизм Программный комплекс "Универсальный механизм" (UM) предназначен для моделирования динамики и кинематики плоских и пространственных механических систем. Universal Mechanism Lite Набор инструментов для создания динамического объекта - системы тел - и последующего анализа его динамических, кинематических и статических свойств. Allplan САПР для архитектурно-строительного проектирования которая предлагает комплексный подход к строительному проектированию в целом. EULER Программный комплекс для инженерного анализа динамики механических систем. SCAD Office Программый комплекс нового поколения, позволяющий провести расчет и проектирование стальных и железобетонных конструкций. NI Developer Suite Комплект программного обеспечения, для создания виртуальных измерительных комплексов. LabView Представляет собой высокоэффективную среду графического программирования, в которой можно создавать гибкие и масштабируемые приложения измерений, управления и тестирования с минимальными временными и денежными затратами. QCad Приложение для двумерного черчения. С помощью QCad можно создавать технические чертежи, такие как планы зданий и интерьеров, чертежи механических деталей и схемы. SprutCAD Открытая среда конструкторского проектирования. T-FLEX CAD Полнофункциональная система автоматизированного проектирования, обладающая средствами автоматизации проектирования при разработке проектов любой сложности. Программа объединяет параметрические возможности трехмерного моделирования со средствами создания и оформления конструкторской документации. GEOTEC Office Package Пакет для геотехники и инженерного проектирования. eMachineShop Бесплатная программа 3D CAD TinyCAD Программа для проектирования электронных схем с большим набором готовых элементов. DraftSight Открытое двухмерное решение САПР профессионального уровня для тех, кто хочет оптимизировать чтение, запись и обмен файлами DWG. DraftSight отличается особой простотой в использовании. Профессиональные пользователи САПР, студенты и преподаватели могут загрузить программу бесплатно VizUp Удобный инструмент для уменьшения и оптимизации 3D-моделей. RING Программа для расчета и моделирования арочных мостов FRAME3DD Бесплатное свободное программное обеспечение для статического и динамического структурного анализа 2-ых и трехмерных каркасов

pro-spo.ru


Смотрите также