Процедурноориентированный и объектноориентированный подходы к разработке по процедурное программирование

Скачать 435.96 Kb. Название Процедурноориентированный и объектноориентированный подходы к разработке по процедурное программирование Анкор Otvety_na_ekzamen.docx Дата 26.04.2017 Размер 435.96 Kb. Формат файла Имя файла Otvety_na_ekzamen.docx Тип Документы #3578 страница 1 из 3

1   2   3 Процедурно-ориентированный и объектно-ориентированный подходы к разработке ПО Процедурное программирование как методика разработки программного обеспечения разделяет программу на данные и процедуры, обрабатывающие эти данные. Преимущества, которыми обладает процедурное программирование по сравнению с неструктурным программированиемПроцедурное программирование задает общую структуру программы: 1) данные 2) и процедуры. Использование процедур помогает разрабатывать программу, предназначенную для решения конкретной задачи. Вместо написания одного большого блока обработки данных в ходе разработки программа все время разбивается на процедуры и более мелкие подпрограммы. Кроме того, процедуры можно использовать повторно. Можно даже создавать библиотеки многократно используемых процедур. Объектно-ориентированное программирование - метод разработки программного обеспечения, позволяющий при моделировании программы использовать названия объектов реального мира. Оно разбивает программу на набор взаимодействующих объектов. Объектно-ориентированное программирование является развитием модульного программирования, так как поддерживает инкапсуляцию. По сравнению с модульным программированием, в нем введена поддержка таких свойств объектов, как наследование (для расширения возможности многократного использования) и полиморфизм (для повышения гибкости в работе с типами данных). Основная цель ООП - связать вместе данные (в виде переменных) с кодом, который работает с этими данными. Свойства: естественность, надежность, возможность повторного использования, удобство сопровождения (легкость исправления ошибок), способность совершенствоваться (Расширяемость), удобство периодического выпуска новых версий. Этапы жизненного цикла разработки и развития ПС. Особенности Наиболее часто говорят о следующих моделях жизненного цикла: Каскадная (водопадная) или последовательная Данная модель предполагает строго последовательное (во времени) и однократное выполнение всех фаз проекта с жестким (детальным) предварительным планированием в контексте предопределенных или однажды и целиком определенных требований к программной системе. Итеративная и инкрементальная – эволюционная (гибридная, смешанная) Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации,продукт развивается инкрементально. Таким образом, Значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски. Спиральная (spiral) или модель Боэма Главное достижение спиральной модели состоит в том, что она предлагает спектр возможностей адаптации удачных аспектов существующих моделей процессов жизненного цикла. В то же время, ориентированный на риски подход позволяет избежать многих сложностей, присутствующих в этих моделях. В определенных ситуациях спиральная модель становится эквивалентной одной из существующих моделей. В других случаях она обеспечивает возможность наилучшего соединения существующих подходов в контексте данного проекта. Системный анализ и системное проектирование ПС. Программа как система Технология разработки ПС RUP. Особенности Rational Unified Process – это методология создания программного обеспечения, оформленная в виде размещаемой на Web базы знаний, которая снабжена поисковой системой. Продукт Rational Unified Process (RUP) разработан и поддерживается Rational Software. Он регулярно обновляется с целью учета передового опыта и улучшается за счет проверенных на практике результатов. Rational Unified Process поддерживает объектно-ориентированную технологию. Моделирование по методологии RUP является объектно-ориентированным и базируется на понятиях объектов, классов и зависимостей между ними. моделирование бизнес-процессов; управление требованиями; анализ и проектирование; реализация; тестирование; развертывание; конфигурационное управление и управление изменениями; управление проектом; управление средой. Моделирование бизнес-процессов применяется с тем, чтобы разобраться в структуре исследуемой предметной области, обеспечить единство понимания основных автоматизируемых процессов среди всех участников проекта и определить высокоуровневые требования, которые должны быть реализованы в ходе проекта. Управление требованиями позволяет прийти к соглашению с заказчиками и конечными пользователями, определить, что должна уметь делать создаваемая система, предоставить более четкие инструкции участникам проекта о возможностях системы, создать базу для успешного планирования работ в проекте и оценки его статуса в любой момент жизненного цикла. Анализ и проектирование служат для последовательного преобразования выявленных требований к системе в спецификации особого вида, которые описывают, как следует конкретно реализовать конечный продукт. Следует при этом делать различия между анализом и проектированием. Основное из них состоит в том, что спецификации анализа не зависят от конкретной платформы и технологии, для которой осуществляется создание ИС. А спецификации проектирования являются точным представлением проектируемой системы, часто позволяя автоматизировать процесс генерации на их основе программного кода. Реализация необходима для выявления порядка организации программного кода в терминах отдельных подсистем, преобразования исходного кода в выполняемые компоненты, тестирования созданных компонентов и интеграции отдельных компонентов в подсистемы и системы. Тестирование позволяет определять и контролировать качество создаваемых продуктов, следить за тем, насколько качественно осуществлена интеграция компонентов и подсистем, все ли требования к системе реализованы и все ли выявленные ошибки устранены до того, как система будет развернута на оборудовании конечного пользователя. Развертывание является процессом, в ходе которого осуществляется доставка разрабатываемого продукта к конечному пользователю. В ходе данного процесса производится новый выпуск системы, распространение ПО, его установка на стороне конечного пользователя, обучение последнего навыкам эффективной работы с поставленным ПО, предоставление услуг по технической поддержке, бета-тестирование и т. п. Конфигурационное управление и управление изменениями позволяет организовать эффективную работу с артефактами проекта, контролировать и управлять доступом к ним, вести историю изменений, обеспечить эффективное взаимодействие участников проекта, как в простых командах, так и в распределенных, находящихся на большом удалении друг от друга. Управление проектом включает в себя непосредственное формирование условий для эффективного хода всего проекта, определение руководств и руководящих принципов для планирования, формирования команды и мониторинга проекта, выявление и управление рисками, организацию работы участников проекта, формирование бюджета, планирование фаз и итераций. Управление средой позволяет осуществить поддержку всех участников проекта. В эту поддержку входят выбор инструментария и его приобретение, настройка и установка, конфигурирование процесса, доработка и адаптация методологии, используемой для ведения проекта, обучение Язык UML. Назначение. Возможности Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML является достаточно строгим и мощным средством моделирования, которое может быть эффективно использовано для построения концептуальных, логических и графических моделей сложных систем различного целевого назначения. Этот язык вобрал в себя наилучшие качества и опыт методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем. UML представляет собой объектно-ориентированный язык моделирования, обладающий следующими основными характеристиками: является языком визуального моделирования, который обеспечивает разработку репрезентативных моделей для организации взаимодействия заказчика и разработчика ИС, различных групп разработчиков ИС; содержит механизмы расширения и специализации базовых концепций языка. Пользователям языка предоставлены возможности: строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений; добавлять при необходимости новые элементы и условные обозначения, если они не входят в ядро, или специализировать компоненты, систему условных обозначений (нотацию) и ограничения для конкретных предметных областей. UML. Диаграмма классов. Выделение классов предметной области и выявление отношений между ними. Этапы построения объектной модели и формальные признаки ее усовершенствования Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними. На диаграмме классов (Class Diagram) показывают классы, интерфейсы, объекты и кооперации, а также их отношения. Между классами возможны различные отношения: зависимости, которые описывают существующие между классами отношения использования; обобщения используется, чтобы показать связь между классом-родителем и классом-потомком; ассоциации, структурное отношение, описывающее совокупность связей; связь - это соединение между объектами. агрегация – это когда класс в своей структуре использует часть другого класса; композиция. При композиции класс является целиком частью другого класса. Этапы построения объектной модели: определение объектов и классов; подготовка словаря данных; определение зависимостей между объектами; определение атрибутов объектов и связей; организация и упрощение классов при использовании наследования; Для дальнейшего улучшения ищутся: Признаки пропущенного объекта (класса): несимметричности связей и обобщений (наследований); для исправления ошибки необходимо добавить пропущенные классы; несоответствие атрибутов и операций у класса; для исправления ошибки необходимо расщепить класс на несколько других классов, так чтобы атрибуты и операции новых классов соответствовали друг другу; обнаружена операция, не имеющая удовлетворительного целевого класса; для исправления ошибки необходимо добавить пропущенный целевой класс; обнаружено несколько зависимостей с одинаковыми именами и назначением; для исправления ошибки необходимо сделать обобщение и добавить пропущенный суперкласс. Признаки ненужного (лишнего) класса: нехватка атрибутов, операций и зависимостей у некоторого класса; для исправления ошибки необходимо подумать, не следует ли исключить такой класс. Признаки пропущенных зависимостей: отсутствуют пути доступа к операциям; для исправления ошибки необходимо добавить новые зависимости, обеспечивающие возможности обслуживания соответствующих запросов. Признаки ненужных (лишних) зависимостей: избыточная информация в зависимостях; для исправления ошибки необходимо исключить зависимости, не добавляющие новой информации, или пометить их как производные зависимости; не хватает операций, пересекающих зависимость; для исправления ошибки необходимо подумать, не следует ли исключить такую зависимость. Признаки неправильного размещения зависимостей: имена ролей слишком широки или слишком узки для их классов; для исправления ошибки необходимо переместить зависимость вверх или вниз по иерархии классов. Признаки неправильного размещения атрибутов: нет необходимости доступа к объекту по значениям одного из его атрибутов; для исправления ошибки необходимо рассмотреть нужно ли ввести квалифицированную зависимость. Классы и отношения между классами. Реализация отношений между классами средствами C# Класс (Class) - это описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Класс реализует один или несколько интерфейсов. На диаграмме классов (Class Diagram) показывают классы, интерфейсы, объекты и кооперации, а также их отношения. Между классами возможны различные отношения: зависимости, которые описывают существующие между классами отношения использования; обобщения используется, чтобы показать связь между классом-родителем и классом-потомком; public class Employee : Man ассоциации, структурное отношение, описывающее совокупность связей; связь - это соединение между объектами. public class Employee : Man{ private String position; private IdCard iCard; public void setIdCard(IdCard c){ iCard = c; } public IdCard getIdCard(){ return iCard; } } public class IdCard{ private Date dateExpire; private int number; public IdCard(int n){ number = n; } } агрегация – это когда класс в своей структуре использует часть другого класса; public class Department{ } class other{ private Department department; public void setDepartment(Department d){ department = d; } public Department getDepartment(){ return department; } } композиция. При композиции класс является целиком частью другого класса. public class Department{ } class other{ private Department department; public void setDepartment(Department d){ department = d; } public Department getDepartment(){ return department; } } class Main { private List<> pastPosition = new HashSet(); ... public void setPastPosition(PastPosition p){ pastPosition.add(p); } public Set getPastPosition(){ return pastPosition; } public void deletePastPosition(PastPosition p){ pastPosition.remove(p); } } UML. Диаграммы состояний объекта и последовательностей. Особенности синтеза Диаграммы состояний (Statechart diagram). Отражает внутренние состояния объекта в течение его жизненного цикла от момента создания объекта до его разрушения. Изображается в виде графа. Каждый объект рассматривается как сущность, которая контактирует с окружающим миром при помощи обмена сообщениями. Состояния объекта связаны с некоторыми событиями. Определение состояния объекта зависит от самого объекта и от уровня моделирования. Диаграммы состояний используются для моделирования динамики поведения класса, поэтому ее целесообразно создавать только для объектов, имеющих несколько состояний. Этой диаграмме не ставится в соответствие программный код. Состояние (State) описывает период времени в течение жизни объекта некоторого класса. Оно может быть описано тремя дополняющими друг друга способами: изменение значений переменных объекта; как время ожидания объектом некоторого события или времени, когда это событие произойдет; или же как период времени, в течение которого объект совершает некоторое продолжающееся действие. Событие (Event) – заслуживающий внимания случай, который произошел в данное время в данном месте. Оно не имеет длительности, то есть рассматривается как мгновенно произошедшее. Событие может иметь некоторый набор параметров, которые характеризуют его и бывает исхо дящим и входящим. Переход (Transition) объекта из одного состояния в другое отображается направленной стрелкой. Переход характеризуется входными событиями, ограничивающими условиями, аргументами, действиями и посылаемыми событиями. История (History) – свойство объекта запоминать предыдущие состояния, которое отображается на диаграмме специальным значком, размещаемым внутри элемента «Состояние». Этот элемент не может использоваться без связи с состоянием, к которому относится история. Начальное состояние – это состояние объекта, в котором он создается. Конечное состояние – состояние, из которого объект не может вернуться в активное состояние.   1   2   3