Автор работы: Пользователь скрыл имя, 10 Октября 2014 в 07:00, дипломная работа
Цель исследования состоит в изучении взаимосвязи структурного и объектно-ориентированного подходов к проектированию программного обеспечения распределенных информационных систем.
Для достижения цели определены следующие задачи исследования:
1. Проведение анализа научно-технической литературы в аспекте структуры и содержания курсов, ориентированных на изучение объектно-ориентированного и структурного программирования.
2. Изучение теоретических основ структурного и объектно-ориентированного подходов, технологии создания программного обеспечения.
Введение
1 Технологии создания программного обеспечения
1.1 Технология структурного программирования
1.2 Технология объектно-ориентированного программирования
1.3 Технология Rational Unified Process (IBM Rational Software)
1.4 Технология Oracle
1.5 Технология Borland
2 Методические основы технологий создания программного обеспечения
2.1 Визуальное моделирование
2.2 Методы структурного анализа и проектирования программного обеспечения
2.3 Методы объектно-ориентированного анализа и проектирования программного обеспечения
2.4 Методы моделирования бизнес-процессов и спецификации требований
2.5 Методы анализа и проектирования программного обеспечения
3 Структурное и объектно-ориентированное программирование в проектировании программного обеспечения распределенных информационных систем
3.1 Проектирование программного обеспечения распределенных информационных систем
3.2 Структурный подход к проектированию информационных систем
3.3 Проектирование информационных систем на основе объектно-ориентированного подхода
3.4 Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
3.5 Проблемы преподавания структурного и объектно-ориентированного программирования
Заключение
Глоссарий
Список использованных источников
Литература
Наиболее важной частью объектно-ориентированного анализа является распределение обязанностей между классами (в виде операций классов). Оно выполняется с помощью диаграмм взаимодействия. При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов [14].
Атрибуты классов анализа определяются, исходя из знаний о предметной области и требований к системе. Связи между классами (ассоциации) определяются на основе анализа кооперативных диаграмм, затем анализируются и уточняются.
Целью объектно-ориентированного проектирования является адаптация предварительного системного проекта (набора классов «анализа»), составляющего стабильную основу архитектуры системы, к среде реализации с учетом всех нефункциональных требований.
Объектно-ориентированное проектирование включает два вида деятельности:
проектирование архитектуры системы;
проектирование элементов системы.
Проектирование архитектуры системы выполняется архитектором системы и включает в себя:
идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;
анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;
формирование архитектурных уровней;
проектирование конфигурации системы.
Проектирование элементов системы включает в себя:
проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);
проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД - объектной или реляционной).
3.1 Проектирование программного
обеспечения распределенных
Проектирование программного обеспечения информационных систем требует большой и трудоемкой работы. Современные крупные проекты информационных систем характеризуются, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов, элементов данных и сложные взаимосвязи между ними), требующая тщательного моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и сложившимся традициям использования тех или иных инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков, и, с другой стороны, масштабами организации-заказчика и различной степенью готовности отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования должен быть прежде всего адекватно описан, должны быть построены полные и непротиворечивые функциональные и информационные модели информационной системы. Однако до недавнего времени проектирование информационных систем выполнялось в основном на интуитивном уровне с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных проверках качества функционирования информационных систем. Кроме того, в процессе создания и функционирования информационных систем информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
Перечисленные факторы способствовали развитию исследований в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, языков проектирования и средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т.д.
Для целенаправленного выполнения проекта должен быть выполнен ряд работ, различных как по своему назначению, так и по квалификационным требованиям, предъявляемым к разработчикам. Иными словами, в ходе развития проекта командой разработчиков выполняются те или иные функции.
Функции, выполняемые разработчиками, — понятие неформализованное. В разных проектах оно может обретать свое содержание. Тем не менее типовые функции, которые предполагают практически все программные проекты, можно перечислить. Так, в любом программном проекте есть функции кодирования, т.е. записи программы на алгоритмическом языке по имеющимся спецификациям, анализа требований, т.е. выявления истинной потребности в создаваемой программе, тестирования и отладки. В рамках деятельности менеджера любого проекта необходимо организовать распределение функций проекта между исполнителями. Вполне естественно считать эти действия одной из функций менеджера. В результате ее выполнения члены команды, выполняющей проект, начинают играть соответствующие роли.
Состав и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится большим (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.
Разработка современного программного комплекса представляет собой сложный и длительный процесс, который состоит из следующих этапов:
Предпроектные исследования, или анализ;
Проектирование и подготовка спецификаций;
Программирование, или кодирование;
Отладка;
Тестирование.
Во время предпроектного исследования собирается информация о предметной области, подбираются исходные данные и определяются функциональные требования к системе. Изучаются необходимые потребительские характеристики разрабатываемого программного обеспечения.
На этапе проектирования широко используется литература, стандарты и нормативные документы. Рассматриваются различные варианты реализации тех или иных функций и выбираются оптимальные. Здесь же разрабатывается архитектура, программный комплекс разбивается на подсистемы, определяются способы их взаимодействия. Результатом этого этапа является документация, с которой можно приступать к программированию, а именно: блок-схемы, SDL-диаграммы, функциональные схемы, описания алгоритмов.
На стадии программирования, или кодирования, происходит воплощение всех наработок, сделанных на предыдущем этапе в работающую систему. Все действия фиксируются как на уровне комментариев в исходных кодах программ, так и в проектной документации. Необходимо организовать процесс таким образом, чтобы в любой момент времени был возможен откат на несколько шагов назад.
Отладка тесно связана с программированием, эти этапы разделяются весьма условно. Отладка может производиться либо непосредственно на оборудовании, для которого предназначено разрабатываемое программное обеспечение, либо на различных эмуляторах. После программирования и отладки должна быть получена законченная рабочая система.
Тестирование представляет собой проверку всех функциональных возможностей разработанного программного обеспечения на том оборудовании, для которого оно разрабатывалось и в условиях, максимально приближенных к реальным. Важным моментом, обеспечивающим объективность, является необходимость проведения тестирования людьми, не участвовавшими в программировании.
На каждом этапе применяются специализированные средства разработки: во время разработки алгоритмов и архитектуры в основном используются различные редакторы; при программировании применяются компиляторы и линковщики, при отладке – отладчики, при тестировании может использоваться специальное тестовое оборудование. В самом простом случае, без какой-либо автоматизации, все перечисленные средства являются автономными и никак не связанны между собой.
Кроме чисто технических задач процесс разработки программного обеспечения, включает также функции планирования и управления, а в условиях распределённого проектирования эти функции становятся особенно актуальными. В рамках планирования производится определение временных параметров проектирования, распределение подсистем между коллективами разработчиков. Кроме того, в течение всего процесса разработки необходимо отслеживать текущее состояние проекта для осуществления контроля и оперативного управления, а также для обеспечения синхронизации проектных процедур.
Исходя из вышесказанного, схема процесса создания программного комплекса будет выглядеть следующим образом (Приложение Г).
3.2 Структурный подход к проектированию информационных систем
Сущность структурного подхода к разработке информационных систем заключается в ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимосвязаны. При разработке системы «снизу-вверх» от отдельных задач ко всей системе целостность теряется, возникают проблемы при информационной стыковке отдельных компонентов.
Структурный подход к программированию представляет собой методологию создания программ. Его внедрение обеспечивает:
повышение производительности труда программистов при написании и контроле программ;
получение программ, которые более пригодны для сопровождения, так как состоят из отдельных модулей;
создание программ коллективом разработчиков;
окончание создания программ в заданный срок.
В структурированных программах обычно легко прослеживается основной алгоритм, они удобнее в отладке и менее чувствительны к ошибкам программирования. Эти свойства являются следствием важной особенности подпрограмм, каждая из которых представляет собой во многом самостоятельный фрагмент программы, связанный с основной программой лишь с помощью нескольких параметров. Такая самостоятельность подпрограмм позволяет локализовать в них все детали программной реализации того или иного алгоритмического действия, и поэтому изменение этих деталей, например в процессе отладки, обычно не приводит к изменениям основной программы.
Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых используются следующие принципы:
1. принцип «разделяй и властвуй» - принцип решения сложных проблем путем их разбиения на множество меньших независимых задач, легких для понимания и решения;
2. принцип иерархического упорядочивания - принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.
Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из них являются следующие принципы:
принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных аспектов;
принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;
принцип непротиворечивости - заключается в обоснованности и согласованности элементов;
принцип структурирования данных - заключается в том, что данные должны быть структурированы и иерархически организованы.
В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых, являются следующие:
SADT (Structured Analysis and Design Technique) модели
и соответствующие
DFD (Data Flow Diagrams) диаграммы потоков данных;
ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».
На стадии проектирования информационной системы модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру программного обеспечения, структурные схемы программ и диаграммы экранных форм.
Перечисленные модели в совокупности дают полное описание информационных систем независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.
Структурное проектирование позволяет одновременно сосредотачиваться на меньшем количестве деталей.
Нисходящее проектирование хорошо работает , когда проблема имеет ясно выраженный иерархический характер.
3.3 Проектирование информационных систем на основе объектно-ориентированного подхода