Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Разработка программного обеспечения (ПО).( Разработка программного обеспечения (ПО).)




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

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

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

· использование процедурного стиля программирования;

· последовательная декомпозиция алгоритма решения задачи сверху вниз.

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

 

 

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

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

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

1. Развитие языков и методов программирования не успевало за все более растущими потребностями в прикладных программах. Единственным реальным способом снизить временные затраты на разработку был метод многократного использования разработанного программного обеспечения, т.е. проектирование новой программной системы на базе разработанных и отлаженных ранее модулей, которые выступают в роли своеобразных «кирпичиков», ложащихся в Фундамент новой разработки.

2. Ускорение разработки программного обеспечения требовало решения проблемы упрощения их сопровождения и модификации.

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

 

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

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

Свойства — это характеристики состояния объекта, а действия над данными объекта называются методами.

 

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

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

Класс и объект — два общепринятых термина. Какова же разница между ними?

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

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

Компонент — это объект, объединяющий состояние и интерфейс (способ взаимодействия). Состояние компонента может быть изменено только с помощью изменения его свойств и вызова методов.

У компонента имеются два типа интерфейсов: интерфейс стадии проектирования и интерфейс стадии выполнения. Компоненты графического интерфейса, управляемые событиями, являются основным «строительным» материалом при разработке приложений средствами графических редакторов. Разработка любого приложения состоит из двух взаимосвязанных этапов:

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

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

 

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

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

С точки зрения внутренней структуры компоненты разбиваются на три группы. На рисунке представлена графическая интерпретация этого разбиения.

 

 

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

· «Оконные» визуальные компоненты (самая многочисленная группа компонентов) — это компоненты, которые могут получать фокус ввода (т.е. становиться активными для взаимодействия с пользователем) и содержать другие визуальные компоненты.

· «Неоконные» (графические) визуальные компоненты не могут получать фокус и содержать другие визуальные компоненты (например, надписи и графические кнопки).

 

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

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

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

Вторые — динамические свойства. Изменением их значений можно управлять только изнутри программного кода (во время выполнения приложения).

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

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

 

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

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

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

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

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

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

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

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

Общесистемные принципы. При создании и развитии ПО рекомендуется применять следующие общесистемные принципы:

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

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

· принцип развития, который предусматривает в ПО возможность его наращивания и совершенствования компонентов и связей между ними;

· принцип комплексности, который заключается в том, что ПО обеспечивает связность обработки информации, как отдельных элементов, так и для всего объема данных в целом на всех стадиях обработки;

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

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

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

 

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

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

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

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

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

Значение спецификаций.

1. Спецификации являются заданием на разработку ПО и их выполнение — закон для разработчика.

2. Спецификации используются для проверки готовности ПО.

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

 

Второй стадией является проектирование ПО. На этом этапе:

1. Формируется структура ПО и разрабатываются алгоритмы, задаваемые спецификациями.

2. Устанавливается состав модулей с разделением их на иерархические уровни на основе изучения схем алгоритмов.

3. Выбирается структура информационных массивов.

4. Фиксируются межмодульные интерфейсы.

 

Третья стадия — программирование. На данном этапе производится программирование модулей. Этап менее сложен по сравнению со всеми остальными. Проектные решения, полученные на предыдущей стадии, реализуются в виде программ. Разрабатываются отдельные блоки и подключаются к создаваемой системе. Одна из задач — обоснованный выбор языков программирования. На этой же стадии решаются все вопросы, связанные с особенностями типа ЭВМ.

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

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

 

Таблица. Затраты по стадиям жизненного цикла ПО (Сведения из разных источников)

 

Стадии жизненного цикла программного обеспечения Гласе Р. Нуазо Р. Энкар- наччо Ж. Боэм Б. Федорчук Чернень- кий Виш- няков Среднее
Определение требований и спецификаций           8,6
Проектирование           10,2
Программирование           8,8
Отладка           16,2
Сопровождение           56,2
Всего           100,0

2. Пакет компиляторов Visual C++.

2.1. Рекомендуемое оборудование.




Поделиться с друзьями:


Дата добавления: 2015-01-03; Просмотров: 1778; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.034 сек.