|
етоды и концепции.Метод аппликативности заключается в том, что программа есть выражение, поставленное из применения функций к аргументам. Программа состоит из совокупности определений функций, представляющих собой вызовы других функций и вложенных друг в друга. Метод поддерживается концепцией функции.Метод рекурсивного поведения заключается в самоповторяющемся поведении, возвращающемся к самому себе. Метод поддерживается концепцией рекурсии.Метод настраиваемости заключается в том, что можно легко порождать новые программные объекты по образцу, как значения соответствующих выражений (применение порождающей функции к параметрам образца). Этому способствует то, что не только программа, но и любой программный объект (в идеале) является выражением.Методология логического программирования - подход, согласно которому программа содержит описание проблемы в терминах фактов и логических формул, а решение проблемы система выполняет с помощью механизмов логического вывода. Логическое программирование начинает свой отсчет времени с конца 60-х годов XX века, когда Корделл Грин предложил использовать резолюцию как основу логического программирования. Алан Колмеро создал язык логического программирования Prolog в 1971 году. Логическое программирование пережило пик популярности в середине 80-х годов XX века, когда оно было положено в основу проекта разработки программного и аппаратного обеспечения вычислительных систем пятого поколения.Методы и концепции.Метод единообразия заключается в одинаковом применении механизма логического доказательства ко всей программе.Метод унификации - это механизм сопоставления с образцом для создания и декомпозиции структур данных.Методология программирования в ограничениях - это подход, при котором в программе определяется тип данных решения, предметная область решение и ограничения на значение искомого решения. Решение находится системой. Методология предлагает двухуровневую архитектуру, интегрирующую компонент ограничения и программный компонент. Компонент ограничений обеспечивает основные операции и состоит из системы выводов на фундаментальных свойствах системы ограничений. Операции, окружающие компонент ограничений, реализуются программно-языковым компонентом. Методология возникла в начале 80-х годов XX века как перспективная область исследований на стыке символьных вычислений, искусственного интеллекта, исследования операций и интервальной арифметики.Методы и концепции.Метод описательной модели вычислений заключается в том, что программа на языке программирования содержит описание понятий и задач. Метод поддерживается концепцией модели.Классификация по топологической специфике методологийТопологическая специфика (топология) методологий определяется как способ выбора методов для получения уточненного ядра методологии. Критерием качества топологий является количество общих затрат на разработку программного обеспечения. Затраты определяются совокупностью многочисленных факторов, в том числе связанных с абстракциями данных, управления и модульности. Например, к хорошей топологии приводит отказ от использования глобальных данных и оператора безусловного перехода (за исключением особого ряда случаев), сильная связность модулей и их слабое сцепление.Методология структурного императивного программирования - подход, заключающийся в задании хорошей топологии императивных программ, ориентированной на сокращение количества общих затрат на разработку программного обеспечения. Сокращение будет иметь место и в результате того, что и проектные модели, и программный код будут иметь хорошую структурированность, позволяющую избежать многих ошибок. В случае данной методологии хорошую топологию задают отказ от использования глобальных данных и, в большинстве случаев, оператора безусловного перехода, разработка модулей с сильной связностью и обеспечение их независимости от других модулей. Подход базируется на двух основные принципах построения: последовательная декомпозиция алгоритма решения задачи сверху вниз; использование структурного кодирования. Данная методология является важнейшим развитием императивной методологии. Создателем структурного подхода считается Эдсгер Дейкстра. Ему также принадлежит попытка соединить структурное программирование с методами доказательства программ.Методы и концепции.Метод алгоритмической декомпозиции сверху вниз заключается в пошаговой детализации постановки задачи, начиная с наиболее общей задачи. Данный метод обеспечивает хорошую структурированность и поддерживается концепцией алгоритма.Метод модульной организации частей программы заключается в разбиении программы на специальные компоненты, называемые модулями. Метод поддерживается концепцией модуляМетод структурного кодирования заключается в использовании при кодировании трех основных управляющих конструкций. Метод поддерживается концепцией управления.Классификация по реализационной специфике методологийКаждое из ядер методологий имеет определенную специфику, определяющую некоторую организацию аппаратной поддержки данной методологии. На данный момент наиболее известными организациями являются две: централизованная и параллельная.Ядра методологий изначально продумывались для централизованных архитектур. Позже появились параллельные аппаратные реализации, к которым стали адаптировать уже существовавшие методологии. Примером параллельной методологии является методология императивного параллельного программирования - подход, в котором предлагается использование явных конструкций для параллельного исполнения выбранных фрагментов программ. Считается, что параллельное программирование возникло с изобретением каналов - независимых аппаратных контроллеров, позволявших центральному процессору выполнять новую прикладную программу одновременно с операциями ввода-вывода других программ. Первоначально с параллельным программированием имели дело лишь разработчики операционных систем.К методам данной методологии можно отнести метод синхронизации исполняемого кода, который заключается в использовании специальных атомических операций для осуществления взаимодействия между одновременно исполняемыми фрагментами кода. Этот метод поддерживается концепцией примитивов синхронизации.Смешанные методологии.Смешанные методологии включают объединение методов нескольких методологий. Наиболее часто объединяются методологии функционального и логического программирования. Существуют исследовательские работы в области объединения объектно-ориентированного и логического программирования. Ряд исследований посвящен вопросам унификации методологий программирования.Петров В.Н. в своей книге "Технологии разработки программного обеспечения" приводит еще одну методологию - RAD (Rapid Application Development). Методология быстрой разработки приложений RAD.На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию целого направления в области программного обеспечения - инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке программного обеспечения средств автоматизации практически всех этапов жизненного цикла информационных систем. Эти средства приобрели название методологии быстрой разработки приложений RAD (Rapid Application Development).RAD - это комплекс специальных инструментальных средств быстрой проектировки прикладных информационных систем, позволяющих оперировать с определенным набором графических объектов, функционально отображающих информационные компоненты приложений.Под методологией быстрой разработки приложений обычно понимается разработки информационных систем, основанный на трех основных элементах: небольшой команде программистов (обычно от 2 до 10 человек); тщательно проработанный производственный график работ, рассчитанных сравнительно короткий срок разработки (от 2 до 6 мес); итерационная модель разработки, основанная на тесном взаимодействии с заказчиком - по мере выполнения проекта разработчики уточняют и реализацию в продукте требований, выдвигаемых заказчиком.Основные принципы: используется итерационная (спиральная) модель разработки; полное завершение работ на каждом из этапов жизненного цикла не обязательно; в процессе разработки информационной системы необходимо тесное действие с заказчиком и будущими пользователями; необходимо применение CASE-средств и средств быстрой разработки, средств управления конфигурацией, внесение изменений в проект и сопровождение готовой системы, использование прототипов, позволяющее полнее выяснить и реализовать потребности конечного пользователя; тестирование и развитие проекта осуществляются одновременно с разработкой; разработка ведется немногочисленной и хорошо управляемой командой профессионалов; необходимы грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.Средства RAD дали возможность реализовывать совершенно иную по сравнению с традиционной технологию создания приложений: информационные объекты формируются как некие действующие модели (прототипы), чье функционирование согласовывается с пользователем, а затем разработчик может переходить непосредственно к формированию законченных приложений, не теряя из виду общей картины проектирования системы.Методологии, технологии и инструментальные средства проектирования составляют основу проекта любой информационной системы. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.2.2 Методологии разработки информационных систем в зарубежной литературеФормально методологии можно разделить на два типа - классические (монументальные, предсказуемые, где все этапы детально проектируется заранее и не допускается отклонение от первоначального плана) и их противоположность - адаптивные (гибкие, где в процессе работы допустимо и даже типично перепроектирование). В зависимости от начальных условий и характера поставленной задачи, может применяться как классическая, так и адаптивная методология (Рис.4). Классическая (монументальная) методология применяется, если: У заказчика есть четкое мнение по поводу функциональности и дизайна будущей программы, то есть ему абсолютно и в деталях ясно, что он хочет получить на выходе. Задача, решаемая программой, четко формализуется и может быть документирована, то есть, возможно, создать подробное техническое задание. Такое техническое задание должно полностью документировать каждое элементарное состояние работы программы, содержать полное описание специальных алгоритмов (если таковые используются), быть однозначно понимаемым во всех пунктах, описывать все детали дизайна пользовательского интерфейса. Техническое задание может быть разработано специалистами или заказчиком самостоятельно. Требования к программе стабильны, и заказчик не будет ставить дополнительных условий по изменению функциональности программы во время ее разработки в рамках текущего контракта. Как следствие этого объем работ строго фиксирован, также как фиксирована и стоимость контакта. Итерационный процесс на данном этапе смещен в область анализа, проектирования и разработки технического задания, процесс разработки строго документирован и линеен. Срок создания технического задания составляет около 60% времени от всего процесса разработки. Адаптивная (agile - гибкая или lightweight - легкая) методология применяется, если: Не ясны или изменяются требования к системе. Заказчик представляет себе разрабатываемое ПО только в общих чертах и предполагает вносить изменения в функциональность или дизайн разрабатываемой программы во время разработки ("не понравилось - поменяйте"). Необходимо как можно быстрее получить первые версии работающей программы. Решаемая программой задача трудно поддается документированию. На реализацию всех требований есть достаточный запас времени. При применении такой методологии разработка программы представляет собой последовательность большого количества итераций, каждая из которых занимает по времени от недели до месяца. По результатам каждой итерации требования к программе уточняются, и, при необходимости, итерация повторяется. Процесс разработки при такой методологии ведения проекта менее бюрократичен, основные акценты смещены в область практической реализации, а не на создание полной и описывающей "все и вся" документации. Для заказчика есть возможность практическим путем нащупать нужное решение, удовлетворяющее не только изначальным требованиям, но и в том числе тем, которые появятся по мере разработки продукта (а редкий проект обходится без появления таких требований). Заказчик в этом случае более плотно взаимодействует с разработчиками, находится постоянно в курсе текущего положения дел, участвует в проектировании очередного этапа и анализирует результаты выполненного. В независимости от используемой методологии, рабочий процесс, подчиняется следующим простым, но важным правилам: Используется система контроля версий. Оформление кода стандартизировано. Первоочередное исправления ошибок перед внесением любых других изменений. Выполняется регулярное резервное копирование всех проектных данных. Используются инструментальные средства автоматизации документирования исходного кода и ведения списков ошибок.
Страницы: 1, 2, 3, 4, 5
|
