Ответы к экзамену (Технология программирования). Как пишется хороший код. Способы представления алгоритмов
 Скачать 2.02 Mb.
|
|
ВИЗУАЛЬНОЕ МОДЕЛИРОВАНИЕ – способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в проекте, вне зависимости от уровня подготовки. МОДЕЛЬ - это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной. 1. МОДЕЛЬ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ определяет требования к ПО (что система должна делать) в виде набора вариантов использования. Каждый вариант использования задаёт сценарий взаимодействия системы с актёрами (люди и системы, взаимодействующие с разрабатываемой системой). 15 2. МОДЕЛЬ АНАЛИЗА включает классы, необходимые для реализации выделенных вариантов использования и возможные связи между классами (это набор сущностей, в виде которых система представляется пользователям). Классы делятся на ИНТЕРФЕЙСНЫЕ (boundary classes) – взаимодействуют с внешней средой, УПРАВЛЯЮЩИЕ (control classes) – алгоритмы, управляющие обменом данными и КЛАССЫ ДАННЫХ (entity classes) – описывают однотипные сущности системы. 3. МОДЕЛЬ ПРОЕКТИРОВАНИЯ состоит из классов, но из более определённых, чем классы модели анализа. Они имеют более детальное определение обязанностей и должны быть специализированы для конкретной используемой платформы (ОС вовлечённых машин, интерфейсы и классы конкретных компонентных сред, интерфейсы для управления БД, используемые библиотеки разработки пользовательского интерфейса и пр.). 4. МОДЕЛЬ РЕАЛИЗАЦИИ представляет собой в рамках RUP и UML набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть 16 поставлен отдельно от него. Часто компоненты представляют собой отдельные файлы с исходным кодом. 5. МОДЕЛЬ РАЗВЁРТЫВАНИЯ представляет собой набор узлов системы, являющихся физически отдельными устройствами, которые способны обрабатывать информацию — серверами, рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними, образованными различного рода сетевыми соединениями. 6. МОДЕЛЬ ТЕСТИРОВАНИЯ определяет тестовые примеры (test cases) и тестовые процедуры (test scripts). ТЕСТОВЫЕ ПРИМЕРЫ являются определенными сценариями работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования. Включает, помимо входных данных на каждом шаге, где они могут быть введены, условия выполнения отдельных шагов и корректные ответы системы для всякого шага, на котором ответ системы можно наблюдать. ТЕСТОВАЯ ПРОЦЕДУРА представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок). Это может быть инструкция по ручному выполнению входящих в тестовый вариант действий или программный компонент, автоматизирующий запуск тестов. 7. МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ. Задачи этой деятельности — понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес- операции и бизнес-процессы). Эта модель служит основой модели анализа. 8. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ. Задачи — понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нём. Требования принято фиксировать в виде модели вариантов использования. 17 9. АНАЛИЗ И ПРОЕКТИРОВАНИЕ. Задачи — выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте её будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы её компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развёртывания. 10.РЕАЛИЗАЦИЯ. Задачи — определить структуру исходного кода системы, разработать код её компонентов и протестировать их, интегрировать систему в работающее целое. 11.ТЕСТИРОВАНИЕ. Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценить её качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям. 12.РАЗВЁРТЫВАНИЕ. Задачи — установить систему в её рабочем окружении и оценить её работоспособность на том месте, где она должна будет работать. 13.УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ И ИЗМЕНЕНИЯМИ. Задачи — определение элементов, подлежащих хранению в депозитарии проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. 14.УПРАВЛЕНИЕ ПРОЕКТОМ. Задачи — планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. 15.УПРАВЛЕНИЕ СРЕДОЙ ПРОЕКТА. Задачи — подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. 7. *ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ. ОСНОВНЫЕ ПРИНЦИПЫ 18 ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. Группа Приём Короткий цикл обратной связи Разработка через тестирование Игра в планирование Заказчик всегда рядом Парное программирование Непрерывный, а не пакетный процесс Непрерывная интеграция Рефакторинг Частые небольшие релизы Понимание, разделяемое всеми Простота проектирования Метафора системы Коллективное владение кодом или выбранными шаблонами проектирования Стандарт оформления кода Социальная защищённость программиста 40-часовая рабочая неделя ТЕСТИРОВАНИЕ написание автоматических тестов, особое внимание юнит-тестам модулей и функциональному тестированию); Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы; Подход «разработка через тестирование» (сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл). ИГРА В ПЛАНИРОВАНИЕ Цель - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. 19 ЗАКАЗЧИК ВСЕГДА РЯДОМ Заказчик – это конечный пользователь продукта, который всё время на связи и доступен для вопросов. ПАРНОЕ ПРОГРАММИРОВАНИЕ Весь код создается парами программистов, работающих за одним компьютером. Один человек работает непосредственно с текстом программы, другой просматривает его работу. При необходимости клавиатура свободно передаётся от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление обо всей системе. НЕПРЕРЫВНАЯ ИНТЕГРАЦИЯ Интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают. ЧАСТЫЕ НЕБОЛЬШИЕ РЕЛИЗЫ Релизы продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. ПРОСТОТА ПРОЕКТИРОВАНИЯ Так как в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование выполняется постоянно небольшими этапами в течение всего времени работы над проектом. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи, и менять его по мере того, как условия задачи меняются. МЕТАФОРА СИСТЕМЫ 20 Метафора системы даёт команде представление о том, каким образом система работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять. СТАНДАРТЫ ОФОРМЛЕНИЯ КОДА Все члены команды в ходе работы должны соблюдать требования общих стандартов оформления кода (необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек). КОЛЛЕКТИВНОЕ ВЛАДЕНИЕ Каждый член команды несёт ответственность за весь исходный код. Каждый вправе вносить изменения в любой участок программы. 8. *ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ. ДОСТОИНСТВА И НЕДОСТАТКИ ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие. Следующие преимущества XP имеют смысл, когда команда полноценно использует хотя бы одну из практик XP: заказчик получает именно тот продукт, который ему нужен, даже если в начале разработки сам точно не представляет его конечный вид; команда быстро вносит изменения в код и добавляет новую функциональность за счёт простого дизайна кода, частого планирования и релизов; код всегда работает за счёт постоянного тестирования и непрерывной интеграции; команда легко поддерживает код, т.к. он написан по единому стандарту и постоянно рефакторится; быстрый темп разработки за счёт парного программирования, отсутствия переработок, присутствия заказчика в команде; высокое качество кода; 21 снижаются риски, связанные с разработкой, т.к. ответственность за проект распределяется равномерно и уход/приход члена команды не разрушит процесс; затраты на разработку ниже, т.к. команда ориентирована на код, а не на документацию и собрания. Недостатки XP: успех проекта зависит от вовлеченности заказчика, которой не так просто добиться; трудно предугадать затраты времени на проект, т.к. в начале никто не знает полного списка требований; успех XP сильно зависит от уровня программистов, методология работает только с senior специалистами; менеджмент негативно относится к парному программированию, не понимая, почему он должен оплачивать двух программистов вместо одного; регулярные встречи с программистами дорого обходятся заказчикам; требует слишком сильных культурных изменений; из-за недостатка структуры и документации не подходит для крупных проектов; т.к. гибкие методологии функционально-ориентированные, нефункциональные требования к качеству продукта сложно описать в виде пользовательских историй. 9. *ОСНОВНЫЕ ЭТАПЫ РАЗВИТИЯ ЯЗЫКА UML. ИСТОРИЯ РАЗВИТИЯ ЯЗЫКА UML Октябрь 1994 г. – начало работы Г.Буча и Дж.Рамбо по унификации методов Booch и OMT (объединение достоинств этих методов). Октябрь 1995 г. – проект унифицированного метода (Unified Method) версии 0.8. Октябрь 1995 г. – присоединение А.Якобсона к Г.Бучу и Дж.Рамбо с целью интеграции метода OOSE с Unified Method 0.8. 22 Осень 1995 г. – поддержка разработки UML становится одной из целей консорциума OMG. UML приобрёл статус второго стратегического направления в работе OMG. Июнь 1996 г. – появление первых документов по описанию UML 0.9. Октябрь 1996 г. – появление UML 0.91. Конец 1996 г. Rational Software учредила консорциум партнёром UML, куда входили такие компании, как HP, Microsoft, Oracle и др. Члены консорциума выделили ресурсы для разработки строгого определения версии 1.0 языка UML. Январь 1997 г. – публикация документа с описанием UML 1.0 Ноябрь 1997 г. – принятие в качестве стандарта версии UML 1.1, предложенной RTP (большая ясность семантики по сравнению с UML 1.0). 2009 г. – появление версии UML 1.5, которая позволяла применять UML не только как язык моделирования, но и как язык программирования. Текущей версией UML является 2.5, принятая на консорциуме OMG в июне 2015 г. В настоящее время все вопросы дальнейшей разработки UML ведутся в рамках консорциума OMG. Статус зыка UML определён как открытый для всех предложений по его доработке и совершенствованию. Сам язык не является чьей-либо собственностью и не запатентован. 10. *ВИЗУАЛЬНОЕ ПРОЕКТИРОВАНИЕ. МЕТОДОЛОГИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ (ООАП) ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ (ООАП) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов. 23 ВИЗУАЛЬНЫМ МОДЕЛИРОВАНИЕМ называется способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем. МОДЕЛЬ - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме. Полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные. Принцип иерархического построения моделей сложных систем предписывает рассматривать процесс построения моделей на разных уровнях абстрагирования или детализации в рамках фиксированных представлений АБСТРАГИРОВАНИЕ - одна из основных способностей человека, которая позволяет разбираться в сложных вещах. Для построения сложной системы необходимо сначала разделить ее на несколько абстрактных представлений и построить модели, используя принятые обозначения – НОТАЦИЮ . Затем убедиться, что модели удовлетворяют всем потребностям системы, и постепенно добавлять детали для перехода от моделей к реализации. Нотация является важной составляющей любой модели - она служит связующим звеном между процессами и выполняет три функции: является языком для описания взаимодействий, которые неочевидны или не могут быть получены непосредственно из кода; обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения; 24 предлагает конкретную форму, помогающую человеку рассуждать о предметной области, а средствам моделирования воплощать описанные идеи. Основное требование к модели программной системы - она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес - аналитиков и программистов. Разработка и использование моделей языка UML осуществляется в рамках общей концепции объектно-ориентированного анализа и проектирования, которая, в свою очередь, является обобщением методологии объектно- ориентированного программирования. Методология объектно-ориентированного анализа и проектирования ПРЕДМЕТНАЯ ОБЛАСТЬ - часть реального мира, которая имеет существенное значение или непосредственное отношение к процессу функционирования программы. ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ (ООАП,Object-Oriented Analysis/Design) - технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов. Методология ООП ООП - совокупность принципов, технологий, а также инструментальных средств для создания программных систем на основе архитектуры взаимодействия объектов. Основные принципы ООП: АБСТРАКЦИЯ (характеристика сущности, которая отличает ее от других сущностей); Наследование (концепция ООП, согласно которой абстрактный тип данных может наследовать данные и функциональность некоторого существующего типа, способствуя повторному использованию компонентов ПО); 25 Инкапсуляция (характеризует сокрытие отдельных деталей внутреннего устройства классов от внешних по отношению к нему объектов или пользователей); Полиморфизм (действия, выполняемые одноименными методами, могут различаться в зависимости от того, к какому из классов относится тот или иной метод). КЛАСС - абстракция совокупности реальных объектов, которые имеют общий набор свойств и обладают одинаковым поведением. ОБЪЕКТ - экземпляр класса. 11. *ОСНОВНЫЕ ЭЛЕМЕНТЫ ЯЗЫКА UML. МОДЕЛЬ СЛОЖНОЙ СИСТЕМЫ Достаточно полная модель сложной системы представляет собой определенное число взаимосвязанных представлений (views), каждое из которых адекватно отражает аспект поведения или структуры системы. При этом наиболее общими представлениями сложной системы принято считать статическое и динамическое, которые в свою очередь могут подразделяться на другие более частные. Принцип иерархического построения моделей сложных систем предписывает рассматривать процесс построения моделей на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. |