Дипломная работа 50% (2023) (1). Задача данного проекта Процесс создание и разработки программ
 Скачать 1.38 Mb.
|
|
Глава 5. Объектное моделирование и программирование В начальный период развития компьютерной техники, когда мощность компьютеров была недостаточно высокой, к исследованию модельного мира применялись естественные подходы к разработке программных систем, которые имели реляционный (процедурный, функциональный и другие) характер. Их сущность состоит в систематическом использовании декомпозиции функций или процессов для описания и построения структурных моделей. При этом сами моделируемые объекты представлялись фрагментарно в том объеме, который необходим для выполнения этих функций, и в форме, удобной для реализации этих функций. Это обеспечивает эффективную реализация требуемых функций, однако не создает цельного и адекватного представления моделируемого пространства. В конечном счете и пользователю, и разработчику ПО необходимо наблюдение за изменением состояний объектов модельного мира в результате их взаимодействий, что требует использования комплексных информационных моделей таких объектов и создания программных средств, предоставляющих пользователю доступ к ним как на уровне свойств, так и на уровне поведения. При объектно-ориентированном подходе структурный анализ требований к системе сводится к разработке ее модели, т. е. формальному описанию, в котором выделены основные объекты, составляющие систему, и отношения между ними. 5.1 Объективный подход и объектная декомпозиция Объектный подход ориентирован на описание объектов автоматизации с построением их комплексных информационно-поведенческих моделей. При этом многие процессы разработки ПС приобретают специфические объектные черты, такие как: − использование новой системы понятий, позволяющих описывать объекты и их классы − декомпозиция объектов, являющаяся основным средством упрощения программной системы − использование внепрограммных абстракций для упрощения процессов разработки; − предпочтение (приоритет) разработки структуры данных перед реализацией функций. В объектной модели отношение между объектами обобщается в отношения между этими классами. В самом общем смысле объект – это сущность, идентифицирующая реальный предмет моделирования, а класс представляет собой описание множества однотипных объектов. При этом каждый объект обладает: − идентичностью, т. е. его можно поименовать и отличать от иных объектов; − состоянием, характеризуемым некоторой совокупностью данных; − поведением, показывающим, что с ним можно делать или что он сам может делать с другими объектами. 5.2 Язык объектного моделирование UML Язык UML представляет собой универсальный язык визуального моделирования, разработанный для спецификации, визуализации, системного проектирования и документирования отдельных компонент ПО и программных систем на основе объектного подхода. Он эффективен при построении концептуальных и логических визуальных моделей сложных программных систем разного назначения. Поддержкой языка как открытого стандарта занимается консорциум OMG. Последней версией, опубликованной в июне 2015 года, является UML 2.5. В нем реализованы основные базовые принципы, которые могут быть применены большинством программистов и разработчиков, использующих методы объектно-ориентированного анализа и программирования. Эти базовые понятия могут комбинироваться и расширяться для того, что разработчики объектных моделей имели возможность самостоятельно разрабатывать модели сложных программных систем. Эффективное использование языка UML базируется на понимании общих принципов моделирования сложных систем и использовании специфики проведения объектно-ориентированного анализа и программирования. В частности, одним из базовых принципов объектного моделирования систем является принцип абстрагирования. Он предусматривает включение в создаваемую модель только те аспекты программной системы, которые имеют непосредственное отношение к выполнению системой своего назначения и состава выполняемых функций. Второстепенные детали при этом не учитываются для того, чтобы не усложнять процесс исследования формируемой модели. В объектном моделировании на языке UML используется и такой важный принцип прикладного системного анализа, как принцип иерар60 хичности формирования моделей сложных систем. Данный принцип предусматривает представление процесса моделирования на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. Исходная модель при этом имеет наиболее общее мета представление, которое формируется в начале этапа проектирования и не содержит несущественных деталей и аспектов моделируемой системы. UML-диаграмма – это специализированный язык графического описания, предназначенный для объектного моделирования в сфере разработки различного программного обеспечения. Данный язык имеет широкий 61 профиль и представляет собой открытый стандарт, в котором используются различные графические обозначения, чтобы создать абстрактную модель системы. UML создавался для того, чтобы обеспечить определение, визуализацию, документирование, а также проектирование всевозможных программных систем. Всего в языке UML определены девять типов диаграмм. Диаграммы классов (class diagram), которые предназначены для отображения классов, интерфейсов, объектов и их коопераций, связанных различными отношениями. При моделировании систем на основе объектно-ориентированного подхода этот тип диаграмм применяется наиболее часто. Он соответствует статическому представлению системы с точки зрения проектирования. Диаграммы объектов (object diagram) используются для отображения объектов и связей между ними. Объекты представляют собой статические копии экземпляров сущностей, показываемых на диаграммах классов. Так же как и диаграммы классов диаграммы объектов относятся к статическому отображению системы с точки зрения проектирования или процессов, но рассчитаны на программную или макетную реализацию. Диаграммы прецедентов (use case diagram) представляют прецеденты (варианты использования) и актеров, участвующих в их выполнении, также связанных между собой отношениями. Этот тип диаграмм относится к статическому виду системы и дает точку зрения вариантов ее использования или процессов. Диаграммы прецедентов особенно важны при концептуальном моделировании системы. Диаграммы взаимодействия предназначены для представления способов и характера информационного взаимодействия между объектами и показывают, в частности, сообщения, с помощью которых объекты обмениваются данными. Используются два частных случая этих диаграмм: диаграммы последовательностей (sequence diagram), отражающие временной порядок обмена сообщениями, и диаграммы кооперации (collaboration diagram), на которых отображается структурная модель объектов, обменивающихся сообщениями. Эти типы диаграмм являются изоморфными, т. е. они могут свободно трансформироваться друг в друга. Диаграммы состояний (statechart diagram) отображают автомат, включающий в свою структуру состояния, переходы, события и виды опе62 раций. Эти диаграммы относятся к динамическому представлению программной системы, особенно они необходимы при моделировании изменения состояний интерфейсов, классов или коопераций. Поведение объекта в диаграмме состояний определяется последовательностью событий, что важно для моделирования реактивных систем. Диаграммы деятельности (activity diagram) являются частным случаем диаграмм состояний. На них представляется поток управления путем переходов от одной деятельности к другой. Этот вид диаграмм относится к динамическим видам системы и является незаменимым при моделировании процессов ее функционирования, так как описывает поток управления между объектами. Диаграммы компонентов (component diagram) используются для представления организации связанной совокупности программных компонентов. Они относятся к статистическому представлению системы с точки зрения реализации, могут быть связаны с диаграммами классов в силу следующего обстоятельства: один компонент обычно включает реализацию одного или нескольких классов, интерфейсов или коопераций. Диаграммы развертывания (deployment diagram) представляют конфигурацию узлов программной системы с указанием размещенных в них компонентов. Эти диаграммы относятся к статическому представлению системы и представляют точку зрения развертывания. Они тесно связаны с диаграммами компонентов, так как на узле размещается один или несколько компонентов. 5.3 Объектно-ориентированное программирование Объектно-ориентированное программирование (ООП) представляет собой метод программирования, основанный на использовании объектов в качестве основных элементов программ. В объектно-ориентированных языках программирования понятие объекта реализовано в виде интегрированной совокупности свойств (данных, характеризующих данный объект), операций по их обработке (функций изменения свойств), а также событий, на которые данный объект может реагировать. Основным фундаментальным понятием ООП является класс, который представляет собой типизированный шаблон, на основе которого может быть создан конкретный исполняемый экземпляр программного объекта. Класс объединяет свойства и методы, определяя сущность и поведение объектов. Объединение данных и процедур обработки в одном объекте с использованием элементов защиты от внешнего использования получило название инкапсуляции и является одним из основополагающих принципов ООП. Кроме того, к важнейшим принципами ООП относятся наследование, полиморфизм и модульность. Под наследованием понимают такой способ организации классов, при котором новый класс может быть создан на базе существующих, причем класс-потомок сохраняет (наследует) все свойства базового класса – родителя. Полиморфизм – это свойство, которое означает, что наследуемые объекты содержат информацию о том, какие методы они должны использовать в случае их программного вызова в ситуации неизменности имен элементов класса при наследовании. Иными словами, это концепция, реализующая «множество методов в одном интерфейсе» в зависимости от того, в каком месте дерева иерархии классов они находятся К основным современным языкам объектно-ориентированного программирования относятся С++, C#, Object Pascal, Java, Ruby, Python и др. С середины 90-х годов прошлого века объектно-ориентированные языки включаются в системы визуального программирования с применением технологии RAD. В такой системе разработки приложений интерфейсная часть программы создается в диалоговом режиме, практически без непосредственного написания программных операторов. К наиболее распространенным и популярным инструментальным системам визуального проектирования относятся: − Embarcadero RAD Studio – среда быстрой разработки приложений для Microsoft Windows компании Embarcadero Technologies., которая объединяет популярные системы программирования Delphi и C++ Builder в единую интегрированную среду. − Microsoft Visual Studio – среда разработки для всех платформ, поддерживаемых Windows: Windows Mobile, Windows CE, Xbox, .NET Framework, Windows Phone .NET Compact Framework и Silverlight, включающая такие компоненты поддержки различных языков, как Visual Basic.NET, Visual C++, Visual C#, Visual F#, Microsoft SQL Server − Eclipse – свободная интегрированная среда разработки модульных кросс-платформенных приложений на языке программирования Java производства компании Eclipse Foundation, которая включает в настоящее время и расширения для поддержки других языков, таких как C/C++, Fortran, Perl, PHP, Python, Ruby, 1C V8. Глава 6. Обеспечение качества программных продуктов Качество программных систем – это совокупность его черт и характеристик, которые влияют на их способность удовлетворять заданные потребности пользователя. Это не значит, что программные средства можно однозначно оценить некоторым фиксированным набором свойств с высокими значениями показателей качества. Во-первых, потому что показатели качества являются противоречивыми, т. е. улучшение одних показателей качества может приводить к ухудшению других. А во-вторых, ПО можно считать качественным тогда, когда гарантируется успешное его использование в течение заданного срока эксплуатации, т. е. качество необходимо оценивать комплексно, хотя отдельные показатели могут считаться неудовлетворительными. Системный подход в процессах управления качеством поддержан рядом специализированных инструментальных средств, ориентированных на управление производством программной продукции. Применение этого комплекса может служить основой для систем обеспечения качества программных средств, однако требуется корректировка, адаптация или исключение некоторых положений стандартов применительно к принципиальным особенностям технологий и характеристик этого вида продукции. Кроме того, при реализации систем качества ПО необходимо привлечение ряда стандартов, формально не относящихся к этой серии и регламентирующих показатели качества, жизненный цикл, верификацию и тестирование, испытания, документирование и другие особенности жизненного цикла программ. Для управления качеством необходим постоянный контроль качества разрабатываемого ПО через метрики качества, такие как плотность дефектов, размер переделок, среднее время между отказами и др., а также контроль качества отдельных стадий процессов проектирования, составляющих целостный процесс создания программной системы У каждого программного проекта есть своя специфика, требующая и различного набора методов обеспечения качества. 6.1 Проблемы надежности и качества программных систем В настоящее время ни разработчики программных продуктов, ни пользователи не могут абсолютно обоснованно сравнивать качество существующих программных продуктов по экономическим критериям и оценивать, насколько один программный продукт эффективнее другого в эксплуатационных расходах, производительности, затратах живого труда и машинного времени. Можно выделить следующие существующие проблемы в разработке программного обеспечения: − существующее в ряде случаев несоответствие процессов разработки ПО международным стандартам; − наличие ошибок в CASE-инструментах, используемых для разработки программных продуктов; − сжатые сроки выполнения проекта; − недостаточно опытные разработчики; − плохая организация процессов разработки ПО; − недопонимание той функциональности программы, которую желает видеть заказчик. Известно большое количество показателей, используемых для характеристики качества программных систем, а также сравнительной оценки их потребительской ценности. функциональная полнота − завершенность разработки − быстродействие как затраты времени на решение задачи пользователя − уровень требований к комплексу технических средств (занимаемый объем памяти, быстродействие процессора, свободное пространство на диске − степень и простота настройки на техническую среду, сетевые и периферийные устройства − стоимость установки, обучения и обслуживания; − комплексность решения задачи; − возможность перенастройки на новые условия применения, например, в связи с изменением законодательства, реструктуризацией фирмы и т. д.; − возможность работы в сети; − качество помощи пользователю в процессе работы, например наличие ситуативной, контекстно-зависимой и гипертекстовой помощи с оглавлением; − требования к уровню квалификации пользователя; − трудоемкость освоения и внедрения; − качество пользовательского интерфейса. 6.2 Тестирование и рефакторинг программного кода Тестирование кода позволяет на протяжении всего жизненного цикла программной системы гарантировать соответствие всех атрибутов программных проектов заданным параметрам качества. Основная цель тестирования состоит в определении отклонений при реализации функциональных требований, степени их значимости, обнаружении ошибок в ходе выполнения программ и своевременном их исправлении. На протяжении всего процесса разработки ПО необходимо применять комплексные методы проверки качества кода, включающие различные типы тестирования. При этом нужно гарантировать соответствие заданным показателям качества всех промежуточных версий проектируемой системы. Применяются как автоматические, так и ручные тесты. Основными видами тестирования ПО являются следующие. 1. Модульное тестирование (тестирование программных модулей) используется для проверки правильности функционирования функций, подпрограмм и методов классов ПО. Модульные тесты создаются и реализуются проектировщиками непосредственно в процессе написания кода. Как правило, модульное тестирование применяется как для проверки самого кода приложения, так и для проверки функционирования БД. 2.Исследовательское тестирование предназначается для проверки качества кода в случае, когда тестировщик пытается интуитивно исследовать возможности программной системы и обнаружить, и зафиксировать неизвестные ошибки, не имея заранее определенных тестовых сценариев. 3. Интеграционное тестирование применяется для проверки правильности совместного взаимодействия компонентов программного продукта. 4.Функциональное тестирование предназначено для проверки конкретных функциональных требований к ПО и осуществляется в случае добавления к системе новых функций. 5. Нагрузочное тестирование используется для проверки работоспособности программной системы при максимальной (предельной) входной нагрузке. 6. Регрессионное тестирование применяется в случае внесения изменений в ПО для того, чтобы проверить корректность работы тех компо69 нентов системы, которые потенциально могут взаимодействовать с измененным компонентом. 7. Комплексное тестирование используется для проверки полноты всех функциональных и нефункциональных требований программной системы. 8. Приемочное тестирование является завершающим функциональным испытанием, которое должны подтвердить, что созданная программная система соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся независимыми специалистами по контролю качества и тестировщиками. Современные инструментальные среды разработки приложений, такие как MS VisualStudio последних версий, предоставляют разработчикам программного обеспечения возможности создавать модульные и нагрузочные тесты, а также тесты для проверки пользовательского интерфейса. Для этого используются шаблоны тестовых проектов, к которым можно отнести следующие: − макет модульного теста, который позволяет создавать тесты проверки модулей в процессе проектирования; − макет с WEB-тестами производительности и нагрузочными тестами; − макет с кодированными тестами пользовательского интерфейса. 6.3 Качество программного обеспечение ISO 9126 Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств . Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Стандарт ISO 9126 состоит из четырех частей, в которых излагаются следующие категории: − модель качества; − внешние метрики; − внутренние метрики; − метрики качества в использовании. Модель качества классифицирует качество ПО с шестью структурными наборами характеристик – показателей качества ПО. Эти показатели, в свою очередь, детализируются атрибутами (субхарактеристиками), как показано на рис. 8.  Критерии качества программного обеспечения корректность устойчивость расширяемость повторное использование совместимость, эффективность переносимость простота использования Функциональность |