Автор работы: Пользователь скрыл имя, 10 Ноября 2014 в 02:32, шпаргалка
Методология процедурно-ориентированного программирования.
Методология объектно-ориентированного программирования.
Методология объектно-ориентированного анализа и проектирования.
Итак, перечислим цели, преследуемые при разработке диаграммы развертывания:
Узел (node) представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической памяти и/или процессора. В последней версии языка UML понятие узла расширено и может включать в себя не только вычислительные устройства (процессоры), но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы.
Графически на диаграмме развертывания узел изображается в форме трехмерного куба (строго говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов, так и в качестве экземпляров.
Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением.
Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости между узлом и развернутыми на нем компонентами. Подобный способ является альтернативой вложенному изображению компонентов внутри символа узла, что не всегда удобно, поскольку делает этот символ излишне объемным. Поэтому при большом количестве развернутых на, узле компонентов соответствующую информацию можно представить в форме отношения зависимости.
При генерации кода учитываются свойства проектов в целом, а так же свойства уровней классов, ролей, атрибутов и операций. К свойствам, регламентирующим характеристики проекта, как такового относятся: имя файла проекта, то под каким именем он появится на диске, название контейнерных классов, используемых по умолчанию и местоположение генерируемого кода. При генерации кода предоставляется возможность создания любого количества набора слов, отвечающих существу проекта, то есть для каждого класса на диаграмме классов генерируется 2 файла: файл заголовка с расширением h, файл спецификации, с расширением *.cpp.
При работе над типичным проектом обязанности по формированию наборов свойств возлагаются на разработчика системы, на практике, как правило, эти обязанности распределяются между участниками группы проекта.
Участвуют конструкторы и деструкторы, взаимодействие структур данных с методами которые их обрабатывают, модификаторы видимости, потоки ввода вывода.
Любая среда визуального моделирования генерирует код, принимая во внимание номенклатуру созданных компонентов в совокупности с их стереотипами. Для каждого компонента без стереотипа система генерирует заголовочный файл, содержащий информацию объявления и определения соответствующего класса. Если package компонент снабжен стереотипом, то генерируется заголовочный файл с объявлением класса в случае, если к данному компоненту привязан компонент со спецификацией package body, то генерируется файл спецификации.
Для компонентов выделяется отдельная подсистема component specification, где устанавливаются все эти свойства.
Помимо двух спецификаций указываются:
После того, как определено, на каком языке программирования будет разрабатываться компонент, необходимо каждому компоненту сопоставить конкретные классы модели, при этом каждый элемент модели (класс, атрибут, роль или операция) анализируется системой с целью выявления установленных свойств, которыми должен обладать генерируемый код. При несовпадении или несовместимости выбранных свойств система предлагает изменить свойства для правильной генерации кода.
На данном шаге, код может быть сгенерирован как для системы в целом, так и для отдельного компонента или группы взаимосвязанных компонентов (при этом структуры данных генерируются в любом случае для выбранных компонентов)
При возникновении ошибок информация о них выводится в виде предупреждающих ошибок.
Все выполняющиеся действия при генерации кода записываются в единый протокол в той последовательности, в которой их выполняет система. Помимо шагов пишутся все предупреждения и ошибки, которые генерирует система.
Следует помнить, что любая система выводит тип ошибки, а не ее содержание. Для того, чтобы исправить ошибку, по протоколу ищется предыдущий шаг и смотрится на какой операции генерации кода данная ошибка возникла.
Целью программирования является описание процессов обработки данных (в дальнейшем - просто процессов). Данные - это представление фактов и идей в формализованном виде, пригодном для передачи и переработке в некоем процессе, а информация - это смысл, который придается данным при их представлении. Обработка данных - это выполнение систематической последовательности действий с данными. Данные представляются и хранятся на т.н. носителях данных. Совокупность носителей данных, используемых при какой-либо обработке данных, будем называть информационной средой. Набор данных, содержащихся в какой-либо момент в информационной среде, будем называть состоянием этой информационной среды. Процесс можно определить как последовательность сменяющих друг друга состояний некоторой информационной среды.
Описать процесс - значит определить последовательность состояний заданной информационной среды. Если мы хотим, чтобы по заданному описанию требуемый процесс порождался автоматически на каком-либо компьютере, необходимо, чтобы это описание было формализованным. Такое описание называется программой. С другой стороны, программа должна быть понятной и человеку, так как и при разработке программ, и при их использовании часто приходится выяснять, какой именно процесс она порождает. Поэтому программа составляется на удобном для человека формализованном языке программирования, с которого она автоматически переводится на язык соответствующего компьютера с помощью другой программы, называемой транслятором. Человеку (программисту), прежде чем составить программу на удобном для него языке программирования, приходится проделывать большую подготовительную работу по уточнению постановки задачи, выбору метода ее решения, выяснению специфики применения требуемой программы, прояснению общей организации разрабатываемой программы и многое другое. Использование этой информации может существенно упростить задачу понимания программы человеком, поэтому весьма полезно ее как-то фиксировать в виде отдельных документов (часто не формализованных, рассчитанных только для восприятия человеком).
Обычно программы разрабатываются в расчете на то, чтобы ими могли пользоваться люди, не участвующие в их разработке (их называют пользователями). Для освоения программы пользователем помимо ее текста требуется определенная дополнительная документация. Программа или логически связанная совокупность программ на носителях данных, снабженная программной документацией, называется программным средством (ПС). Программа позволяет осуществлять некоторую автоматическую обработку данных на компьютере. Программная документация позволяет понять, какие функции выполняет та или иная программа ПС, как подготовить исходные данные и запустить требуемую программу в процесс ее выполнения, а также: что означают получаемые результаты (или каков эффект выполнения этой программы). Кроме того, программная документация помогает разобраться в самой программе, что необходимо, например, при ее модификации.
Под технологией программирования будем понимать совокупность производственных процессов, приводящую к созданию требуемого ПС, а также описание этой совокупности процессов. Другими словами, технологию программирования мы будем понимать здесь в широком смысле как технологию разработки программных средств, включая в нее все процессы, начиная с момента зарождения идеи этого средства, и, в частности, связанные с созданием необходимой программной документации. Каждый процесс этой совокупности базируется на использовании каких-либо методов и средств, например, компьютер (в этом случае будем говорить об компьютерной технологии программирования).
Имея в виду, что надежность является неотъемлемым атрибутом ПС, мы будем обсуждать технологию программирования как технологию разработки надежных ПС. Это означает, во-первых, что мы будем обсуждать все процессы разработки ПС, начиная с момента возникновения замысла ПС, во-вторых, нас будут интересовать не только вопросы построения программных конструкций, но и вопросы описания функций и принимаемых решений с точки зрения их человеческого (неформального) восприятия, и, наконец, в качестве продукта технологии мы будем принимать надежную (а не правильную) ПС. Все это будет существенно влиять на выбор методов и инструментальных средств в процессах разработки ПС.
При разработке и использовании ПС мы многократно имеем дело с преобразованием (переводом) информации из одной формы в другую. Заказчик формулирует свои потребности в ПС в виде некоторых требований. Исходя из этих требований, разработчик создает внешнее описание ПС, используя при этом спецификацию (описание) заданной аппаратуры и, возможно, спецификацию базового программного обеспечения. На основании внешнего описания и спецификации языка программирования создаются тексты программ ПС на этом языке. По внешнему описанию ПС разрабатывается также и пользовательская документация. Текст каждой программы является исходной информацией при любом ее преобразовании, в частности, при исправлении в ней ошибки. Пользователь на основании документации выполняет ряд действий для применения ПС и осуществляет интерпретацию получаемых результатов. Везде здесь, а также в ряде других процессах разработки ПС, имеет место указанный перевод информации.
На каждом из этих этапов перевод информации может быть осуществлен неправильно, например, из-за неправильного понимания исходного представления информации. Возникнув на одном из этапов, ошибка в представлении информации распространяется на последующие этапы разработки и, в конечном счете, окажется в самом ПС.
Чтобы понять природу ошибок при переводе рассмотрим модель. На ней человек осуществляет перевод информации из представления A в представление B. При этом он совершает четыре основных шага перевода:
На каждом из этих шагов человек может совершить ошибку разной природы. На первом шаге способность человека "читать между строк" (способность, позволяющая ему понимать текст, содержащий неточности или даже ошибки) может стать причиной ошибки в ПС. Ошибка возникает в том случае, когда при чтении документа A человек, пытаясь восстановить недостающую информацию, видит то, что он ожидает, а не то, что имел в виду автор документа A. В этом случае лучше было бы обратиться к автору документа за разъяснениями. При запоминании информации человек осуществляет ее осмысливание (здесь важен его уровень подготовки и знание предметной области, к которой относится документ A). И, если он поверхностно или неправильно поймет, то информация будет запомнена в искаженном виде. На третьем этапе забывчивость человека может привести к тому, что он может выбрать из своей памяти не всю преобразуемую информацию или не все правила перевода, в результате чего перевод будет осуществлен неверно. Это обычно происходит при большом объеме плохо организованной информации. И, наконец, на последнем этапе стремление человека побыстрее зафиксировать информацию часто приводит к тому, что представление этой информации оказывается неточным, создавая ситуацию для последующей неоднозначной ее интерпретации.
Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:
Информация о работе Шпаргалка по "Программированию и компьютерам"