Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
1. Методология процедурно-ориентированного программирования.
Основой данной методологии разработки ПО является процедурная или алгоритмическая ориентация структуры программного кода. Это было естественно для вычислительных задач, которые превалировали на ранних этапах развития ВТ. Исходным понятием этой методологии является понятие «алгоритма», а языки программирования назвали алгоритмами.
Первое графическое средство документирования программ получило название «блок-схема алгоритма» (ГОСТ 19.701-90). Однако потребности практики не всегда требовали установления вычислимости конкретных функций или разрешимости отдельных задач.
В языках программирования возникло и закрепилось новое понятие «процедуры», которое конкретизировало общие понятия алгоритма применительно к решению задач на компьютерах. Так же как и алгоритм процедура представляет собой законченную последовательность действий или операций, направленных на решение отдельной задачи. В языках программирования появилась специальная синтаксическая конструкция, которая получила название процедуры, а языки стали называть процедурно-ориентированными.
Со временем разработка больших программ превратилась в серьезную проблему и потребовала их разбиения на более мелкие фрагменты с тем, чтобы можно было ее разрабатывать коллективом разработчиков. Основой для такого разбиения стала процедурная декомпозиция, при которой отдельные части программы или модули представляют собой совокупность процедур для решения некоторой совокупности задач.
Главная особенность процедурного программирования заключается в том, что программа всегда имеет начало и окончание (начальную и конечную процедуры). При этом вся программа может быть представлена визуально в виде направленной последовательности примитивов или блоков.
Все эти идеи способствовали становлению системы взглядов на процесс разработки программ и написание программных кодов, которая получила название методологии структурного программирования.
Основой данной методологии является процедурная декомпозиция и организация отдельных модулей в виде совокупности выполненных процедур.
В рамках методологии получило развитие нисходящее проектирование ПО и программирование «сверху вниз».
Период наибольшей популярности структурного программирования приходится на конец 70-х –начала 80-х гг. В этот период основным показателем сложности разрабатываемых программ стал ее размер –количество строк, а трудоемкость оценивали в человекомесяцах.
2. Методология ООП.
В 80-е гг. в связи с широким распространением ЭВМ и усложнением разрабатываемых программных систем стало очевидным, что традиционные методы процедурного программирования не способны справиться с возникшими проблемами. Нужна была новая методология, которая решила бы проблемы сложности и надежности –методология ООП.
Фундаментальным понятием в ней является понятие класса и объекта. Класс –абстрактная совокупность объектов, которые имеют общий набор свойств и одинаковое поведение. Каждый объект в этом случае рассматривается как экземпляр соответствующего класса.
Важнейшей особенностью классов является возможность их организации в виде некоторой иерархической структуры, которая по внешнему виду напоминает схему классификаций понятий формальной логики в соответствии с их объемом и содержанием.
Такая иерархия классов обеспечивает наследование кодов (предков). Экономия времени разработки и повышение надежности, а также возможность дальнейшего развития (и наследования). Это достигается механизмами наследования и полиморфизма. Надежность программного кода поддерживается механизмом инкапсуляции.
Появились языки программирования, которые обеспечивают поддержку новой методологии (С++, Паскаль…). На базе этих языков были созданы визуальные ОО среды программирования с библиотеками классов (MFC или VCL).
Широкое распространение методологии ООП оказало влияние на процесс разработки программ. Процедурно-ориентированная декомпозиция программ уступила место ОО декомпозиции, при которой отдельными структурными единицами стали классы и объекты со свойствами и методами. В следствии, программа перестала быть последовательностью предопределенных на этапе кодирования действий, а стала событийно-управляемой.
Наиболее существенным обстоятельством в развитии ООП явилось осмысление того факта, что процесс написания программного кода может быть отделен от процесса проектирования структуры программы.
В самом деле до того как начать программирование классов, их свойств и методов необходимо определить чем является классы, сколько их в программе, каковы их свойства и методы. Эта совокупность задач не столько связана с написанием кода, сколько с общим анализом требований к будущей программе и также с анализом конкретной предметной области, для которой разрабатывается ПО.
Все эти обстоятельства привели к появлению новой методологии программирования –ОО анализ и проектирование.
3. Методология объектно-ориентированного анализа и проектирования.
Современное разделение процесса разработки программных приложений на отдельные этапы способствовало становлению адекватной концепции жизненного цикла программ. Под «жизненным циклом» программы понимается совокупность взаимосвязанные и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее исполнения.
ISO/IFC 12207 описывает структуру жизненного цикла. В настоящее время выделяют следующие этапы:
Технология ООАП автоматизирует 1 и 2 этап ЖЦ. Исторически был сначала автоматизирован второй этап плюс использование CASE средств.
В настоящее время созданы также средства на базе UML (Unified Modeling Language), которые представляют пользователям мощную формализацию, графическую нотацию –язык представления знаний.
UML предназначен для: 1. описания ОО систем и
. визуализации бизнесс-процессов.
. документирования
Язык UML основан на некотором числе базовых понятий, которые могут быть изучены и применены большинством программистов, желающих эффективно внедрять методы ООАП. При этом базовые понятия могут расширятся, чтобы разрабатывать модели сложных систем в различных областях приложений.
6. Разработка UML-моделей.
UML –унифицированный язык моделирования для описания визуализации и документирования ОО-систем в процессе их разработки.
Основные принципы построения моделей сложных систем, которые используются в ООАП и реализованы в языке UML:
Для диаграмм языка UML существует три типа визуальных обозначений, которые важны с точки зрения заключенной в них информации:
В UML используют четыре вида графических обозначений:
При графическом построении диаграмм следует учесть:
Диаграмма вариантов использования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе её проектирования и разработки. Суть диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей и актёров, взаимодействующих с системой с помощью так называемых вариантов использования. Актёр (действующее лицо) - любая сущность, взаимодействующая с системой извне. Каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с действующим лицом.
Диаграмма классов - разработка логической модели системы. На диаграмме изображаются классы, объекты и отношения между ними.
Диаграмма состояний. Описывает возможные последовательности состояний и переходов, которые характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.
Диаграмма последовательности –диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.
Диаграмма деятельности -отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности.
Диаграмма кооперации. Понятие кооперации служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель кооперации -специфицировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.
Диаграмма компонентов и Диаграмма развертывания –представляют собой диаграмму реализации, которая описывает физическое представление системы, позволяет определить архитектуру разрабатываемой системы, установить зависимость между программными компонентами.
10. Динамически загружаемые библиотеки как средство автоматизации проектирования приложений.
Физическими компонентами приложения Windows являются:
Известно, что исполняемый файл содержит код приложения и описание ресурсов в двоичном виде. Динамически подключаемые библиотеки содержат также данные, коды функций и процедур, ресурсы. Если исполняемый файл загружается автоматически после запуска приложения, то динамически подключаемая библиотека загружается либо после исполнения специальной функции загрузки библиотеки, либо автоматически при вызове функции, находящейся в библиотеке. При этом для вызываемой функции или процедуры в программе должны быть указаны имя соответствующей библиотеки и имя (или индекс) библиотечной функции, т.к. имя библиотечной функции может не совпадать с программным именем. Основное назначение динамически подключаемых библиотек –реализация использования их из нескольких приложений или процессов. Когда библиотека используется несколькими приложениями, то загружается лишь один экземпляр библиотеки тем процессом, который к ней обращается первым. При каждом обращении к библиотеке другим процессом будет увеличиваться на 1 специальный счетчик обращений к библиотеке. При завершении использования процессом библиотеки счетчик уменьшается на единицу, и когда он становится равным 0, библиотека закрывается.
В среде Visual C имеется два режима подключения библиотечных функций:
Рассмотрим процесс создания библиотеки в среде Delphe. Для создания библиотеки необходимо построить проект из одного файла *.dpr, используя команды fill/new/dll/OK
Создав проект его нужно сохранить и откомпилировать. В результате получается основа DLL, в которую можно добавлять модули, ресурсы, данные. Обязательно наличие в теле проекта вызова специальных процедур, которые обеспечивают инициализацию библиотеки, ее нормальное завершение и т.п. Этот вызов называется точкой входа DLL.
Записывая DLL на диск, компановщик записывает также имена всех экспортируемых программ с их смещением в образе файла. Затем загрузчик находит внутри образа DLL загружающего процесса имена и адреса всех этих подпрограмм. К экпортируемым подпрограммам можно обращаться из ОС, приложений или других DLL. Они могут служить интерфейсом для объектов внутри DLL.
Чтобы воспользоваться DLL ее надо отобразить в адресное пространство процесса явно с помощью функции LoadLibrary, LoadEx. Если явная загрузка библиотеки не используется, тогда библиотека загружается автаматически при исполнении функции библиотеки.