1. Начало (Inception)
В фазе Начало:
*Формируются видение и границы проекта.
*Создается экономическое обоснование (business case).
*Определяются основные требования, ограничения и ключевая функциональность продукта.
*Создается базовая версия модели прецедентов.
*Оцениваются риски.
При завершении начальной фазы оценивается достижение вехи целей жизненного цикла (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.
2. Уточнение (Elaboration)
В фазе уточнение производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
*Документирование требований (включая детальное описание для большинства прецедентов).
*Спроектированную, реализованную и оттестированную исполняемую архитектуру.
*Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
*Сниженные основные риски.
Успешное выполнение фазы разработки означает достижение вехи архитектуры жизненного цикла (англ. Lifecycle Architecture Milestone).
3. Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
4. Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.
Основные артефакты на этапах разработки
Артефакт - это общее название для любых видов информации, создаваемой, изменяемой или используемой сотрудниками при создании системы. Примерами артефактов могут служить диаграммы Унифицированного языка моделирования и связанный с ними текст, наброски и прототипы пользовательских интерфейсов, компоненты, планы тестирования и тестовые примеры.
Варианты использования и спецификации потоков событий.
Вариант использования - это часть функциональности системы, необходимая для получения пользователем значимого для него, ощутимого и измеримого результата. Варианты использования обеспечивают функциональные требования. Сумма всех вариантов использования составляет модель вариантов использования, которая описывает полную функциональность системы. Однако варианты использования - это не только средство описания требований к системе. Они также направляют ее проектирование, реализацию и тестирование, то есть они направляют процесс разработки. Основываясь на модели вариантов использования, разработчики создают серию моделей проектирования и реализации, которые осуществляют варианты использования. Тестеры тестируют реализацию для того, чтобы гарантировать, что компоненты модели реализации правильно выполняют варианты использования. Таким образом, варианты использования не только инициируют процесс разработки, но и служат для связи отдельных его частей. Управляемый вариантами использования означает, что процесс разработки проходит серии рабочих процессов, порожденных вариантами использования.
Существуют различные шаблоны описания вариантов использования. Так, в монографии [8.2] рассматриваются следующие основные стили описания:
Свободный формат,
Полный формат (предложенный А. Коберном),
Таблица в две колонки,
Таблица в три колонки,
Стиль RUP.
Кроме того, иногда целесообразно использовать:
Псевдокод,
Диаграмму активности UML (см. лекцию 9),
Другие графические модели.
Основной и альтернативные потоки как средство повышения надежности ПП.
Основной поток:
"Идеальный" ход развития событий.
Все идет, как ожидается и хочется
Нет ошибок, отклонений, прерываний или ответвлений
Альтернативный поток:
Возможные отклонения.
Шаблон варианта использования RUP
Ниже приведен краткий обзор его разделов.
1)Наименования и краткое описание. В этом разделе указывается: наименование варианта использования, акторы варианта использования, краткое (в один абзац) описание варианта использования.
2)Поток событий
2.1. Основной поток событий
Так же, как в "Основной сценарий".
2.2. Альтернативные потоки событий
Каждый из альтернативных сценариев описывается в отдельном параграфе, в том же стиле, что и основной поток событий. Альтернативные сценарии описывают поведение системы при любых отклонениях от основного сценария, а также поведение в исключительных ситуациях.
3)Специальные требования
Здесь перечисляются нефункциональные требования, имеющие непосредственное отношение именно к этому варианту использования.
4)Предусловия
События, описываемые предусловиями или постусловиями, должны быть состояниями, которые пользователь может наблюдать [8.3]. Предусловие описывает состояние, в котором система должна находиться до начала исполнения прецедента.
5)Постусловия
Постусловие RUP по сути описывает то же, что и минимальная гарантия у Коберна. Л.Новиков [8.3] акцентирует внимание на том, что корректно сформулированное постусловие должно быть истинным при любом возможном сценарии прецедента, а не описанном в основном потоке.
6)Точки расширения
Данный параграф определяет положение точек, расширяющих поток событий.
Клиент-серверная архитектура, проблема обратных вызовов со стороны сервера. Основные языки, IDE и технологии программирования: HTML и XML, Java Script, C#, ASP.NET и ADO.NET, Java, Ruby, PHP+Apachy+MySQL, технология AJAX. Программирование Web-приложений по технологии Model-View-Controller (модель-представление-контроллер): Ruby on Rails.
Клиент-сервер (англ. Client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и заказчиками услуг, называемыми клиентами. Нередко клиенты и серверы взаимодействуют через компьютерную сеть и могут быть как различными физическими устройствами, так и программным обеспечением.
Преимущества
Делает возможным, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети. Это позволяет упростить обслуживание вычислительной системы. В частности, замена, ремонт, модернизация или перемещение сервера, не затрагивают клиентов.
Все данные хранятся на сервере, который, как правило, защищён гораздо лучше большинства клиентов. На сервере проще обеспечить контроль полномочий, чтобы разрешать доступ к данным только клиентам с соответствующими правами доступа.
Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т.п.
Недостатки
Неработоспособность сервера может сделать неработоспособной всю вычислительную сеть.
Поддержка работы данной системы требует отдельного специалиста - системного администратора.
Высокая стоимость оборудования.
Проблема обратных вызовов
Проблема обратных вызовов заключается в том, что клиент знает про сервер, а сервер про него нет, в том смысле, что клиент отсылает запрос, получает ответ. Просто так ответ (запрос или еще, какие данные) сервер отправить клиенту не может (причина — стандарт http)
Языки программирования
Язык программирования — формальная знаковая система, предназначенная для записи компьютерных программ. Язык программирования определяет набор лексических, синтаксических и семантических правил, задающих внешний вид программы и действия, которые выполнит исполнитель (компьютер) под ее управлением.
HTML — стандартный язык разметки документов в Интернет. Большинство веб-страниц создаются при помощи языка HTML (или XHTML). Язык HTML интерпретируется браузером и отображается в виде документа, в удобной для человека форме.
HTML является приложением («частным случаем») SGML (стандартного обобщённого языка разметки) и соответствует международному стандарту ISO 8879. XHTML же является приложением XML.
XML (англ. eXtensible Markup Language — расширяемый язык разметки; произносится [икс-эм-э́ль]) — рекомендованный Консорциумом Всемирной паутины язык разметки, фактически представляющий собой свод общих синтаксических правил. XML — текстовый формат, предназначенный для хранения структурированных данных (взамен существующих файлов баз данных), для обмена информацией между программами, а также для создания на его основе более специализированных языков разметки (например, XHTML). XML является упрощённым подмножеством языка SGML.
JavaScript — объектно-ориентированный скриптовый язык программирования. Является диалектом языка ECMAScript.
JavaScript обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.
Основные архитектурные черты: динамическая типизация, слабая типизация, автоматическое управление памятью, прототипное программирование, функции как объекты первого класса.
C# — объектно-ориентированный язык программирования. Разработан в 1998—2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET и впоследствии был стандартизирован как ECMA-334 и ISO/IEC 23270. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нём можно создавать и компилировать даже без инструментальных средств, вроде Visual Studio.
C# относится к семье языков с C-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов (в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщённые типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.
Переняв многое от своих предшественников — языков C++, Java, Delphi, Модула и Smalltalk — С#, опираясь на практику их использования, исключает некоторые модели, зарекомендовавшие себя как проблематичные при разработке программных систем: так, C# не поддерживает множественное наследование классов (в отличие от C++).
ASP.NET — технология создания веб-приложений и веб-сервисов от компании Майкрософт. Она является составной частью платформы Microsoft .NET и развитием более старой технологии Microsoft ASP. На данный момент последней версией этой технологии является ASP.NET 4.0[1].
ASP.NET внешне во многом сохраняет схожесть с более старой технологией ASP, что позволяет разработчикам относительно легко перейти на ASP.NET. В то же время внутреннее устройство ASP.NET существенно отличается от ASP, поскольку она основана на платформе .NET и, следовательно, использует все новые возможности, предоставляемые этой платформой.
ADO.NET (ActiveX Data Objects .NET) — основная модель доступа к данным для приложений, основанных на Microsoft .NET. Не является развитием более ранней технологии ADO. Скорее представляет собой совершенно самостоятельную технологию. Компоненты ADO.NET входят в поставку оболочки .NET Framework; таким образом, ADO.NET является одной из главных составных частей .NET.
Java — объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems. Приложения Java обычно компилируются в специальный байт-код, поэтому они могут работать на любой виртуальной Java-машине (JVM) независимо от компьютерной архитектуры. Дата официального выпуска — 23 мая 1995 года.
Ruby — динамический, рефлективный, интерпретируемый высокоуровневый язык программирования для быстрого и удобного[1][2] объектно-ориентированного программирования. Язык обладает независимой от операционной системы реализацией многопоточности, строгой динамической типизацией, сборщиком мусора и многими другими возможностями. Ruby близок по особенностям синтаксиса к языкам Perl и Eiffel, по объектно-ориентированному подходу — к Smalltalk. Также некоторые черты языка взяты из Python, Лисп, Dylan и CLU.
Кроссплатформенная реализация интерпретатора языка является полностью свободной.
PHP — скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.
Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом. Проект распространяется под собственной лицензией, несовместимой с GNU GPL.
Apache HTTP-сервер — свободный веб-сервер.
Apache является кроссплатформенным ПО, поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.
Основными достоинствами Apache считаются надёжность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPv6.
MySQL — свободная система управления базами данных (СУБД). MySQL является собственностью компании Oracle Corporation, получившей её вместе с поглощённой Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License или под собственной коммерческой лицензией. Помимо этого разработчики создают функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.
AJAX — подход к построению интерактивных пользовательских интерфейсов веб-приложений, заключающийся в «фоновом» обмене данными браузера с веб-сервером. В результате, при обновлении данных, веб-страница не перезагружается полностью и веб-приложения становятся более быстрыми и удобными.
По-английски AJAX произносится как эй-джэкс, по-русски довольно распространено ая?кс.
AJAX — не самостоятельная технология, а концепция использования нескольких смежных технологий. AJAX базируется на двух основных принципах:
использование технологии динамического обращения к серверу «на лету», без перезагрузки всей страницы полностью, например:
с использованием XMLHttpRequest (основной объект);
через динамическое создание дочерних фреймов[1];
через динамическое создание тега <script>[2].
использование DHTML для динамического изменения содержания страницы;
В качестве формата передачи данных обычно используются JSON или XML.
MVC
Model-view-controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») — архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные.
Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента
Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя своё состояние.
Представление (View). Отвечает за отображение информации (пользовательский интерфейс).
Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.
Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.
Впервые данный шаблон проектирования был предложен для языка Smalltalk.
Ruby on Rails — программный каркас, написанный на языке программирования Ruby. Ruby on Rails предоставляет архитектурный образец Model-View-Controller (модель-представление-контроллер) для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером базы данных.
Ruby on Rails является открытым программным обеспечением и распространяется под лицензией MIT.
Командная разработка небольших программных проектов. Экстремальное программирование, agile-методы. Эффективные техники программирования: парное программирование, рефакторинг, работа с унаследованным кодом.
+52
Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.
Основные приёмы XP
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
• Короткий цикл обратной связи (Fine scale feedback)
• Разработка через тестирование (Test driven development)
• Игра в планирование (Planning game)
• Заказчик всегда рядом (Whole team, Onsite customer)
• Парное программирование (Pair programming)
• Непрерывный, а не пакетный процесс
• Непрерывная интеграция (Continuous Integration)
• Рефакторинг (Design Improvement, Refactor)
• Частые небольшие релизы (Small Releases)
• Понимание, разделяемое всеми
• Простота (Simple design)
• Метафора системы (System metaphor)
• Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
• Стандарт кодирования (Coding standard or Coding conventions)
• Социальная защищенность программиста (Programmer welfare):
• 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Рефакторинг
Рефакторинг(refactoring) — это методика улучшения кода, без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга, в связи с боязнью поломать систему, что приводит к постепенной деградации кода.
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming.[2] Agile Manifesto cодержит 4 основные идеи и 12 принципов. Примечательно что, Agile Manifesto не содержит практических советов.
Эффективная работа с унаследованным кодом
• Представление о механизмах внесения изменений в программное обеспечение, включая ввод новых свойств, устранение программных ошибок, улучшение структуры кода, оптимизацию производительности.
• Перенос унаследованного кода в средства тестирования.
• Написание тестов, препятствующих внесению новых ошибок в код.
• Применение методов, подходящих для любого языка или платформы, с примерами кода на Java, C++, C и C#.
• Точное выявление мест в коде, где требуется внести изменения.
• Работа с унаследованным кодом, который не является объектно-ориентированным.
• Обращение с приложениями, у которых, на первый взгляд, нет вообще никакой структуры.
Командная разработка небольших программных проектов. Инструментальные средства: UML и Rational Rose, средства управления конфигурацией и контроля версий (Subversion, Mercurial, TprtoiseSVN). Настройка среды разработки.
+52
UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
Использование
Использование UML не ограничивается моделированием программного обеспечения. Его также используют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение, и больше сконцентрироваться на проектировании и архитектуре.
Диаграммы
В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):
• Structure Diagrams:
• Class diagram
• Component diagram
• Composite structure diagram
• Collaboration (UML2.0)
• Deployment diagram
• Object diagram
• Package diagram
• Profile diagram (UML2.2)
• Behavior Diagrams:
• Activity diagram
• State Machine diagram
• Use case diagram
• Interaction Diagrams:
• Communication diagram (UML2.0) / Collaboration (UML1.x)
• Interaction overview diagram (UML2.0)
• Sequence diagram
• Timing diagram (UML2.0)
• Структурные диаграммы:
• Диаграмма классов
• Диаграмма компонентов
• Композитной/составной структуры
• Диаграмма кооперации (UML2.0)
• Диаграмма развёртывания
• Диаграмма объектов
• Диаграмма пакетов
• Диаграмма профилей (UML2.2)
• Диаграммы поведения:
• Диаграмма деятельности
• Диаграмма состояний
• Диаграмма прецедентов
• Диаграммы взаимодействия:
• Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)
• Диаграмма обзора взаимодействия (UML2.0)
• Диаграмма последовательности
• Диаграмма синхронизации (UML2.0)
Преимущества UML
UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.
Критика
Несмотря на то, что UML достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:
Избыточность языка. UML часто критикуется, как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.
Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков.
Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.
Rational Rose - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [21]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML - Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.
Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое.
Такие системы наиболее широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы. Однако, они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов, в частности, они применяются в САПР, обычно, в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (Software Configuration Management Tools).
Программное обеспечение Википедии ведёт историю изменений для всех её статей, используя методы, аналогичные тем, которые применяются в системах управления версиями.
Общие сведения
Ситуация, когда электронный документ за время своего существования претерпевает ряд изменений, достаточно типична. При этом часто бывает важно иметь не только последнюю версию, но и несколько предыдущих. В простейшем случае, можно просто хранить несколько вариантов документа, соответствующим образом их нумеруя. Но такой способ неэффективен (приходится хранить несколько практически идентичных копий), требует повышенного внимания и дисциплины и часто ведёт к ошибкам. Поэтому были разработаны средства для автоматизации этой работы.
Традиционные системы управления версиями используют централизованную модель, когда имеется единое хранилище документов, управляемое специальным сервером, который и выполняет бо́льшую часть функций по управлению версиями. Пользователь, работающий с документами, должен сначала получить нужную ему версию документа из хранилища; обычно создаётся локальная копия документа, т. н. «рабочая копия». Может быть получена последняя версия или любая из предыдущих, которая может быть выбрана по номеру версии или дате создания, иногда и по другим признакам. После того, как в документ внесены нужные изменения, новая версия помещается в хранилище. В отличие от простого сохранения файла, предыдущая версия не стирается, а тоже остаётся в хранилище и может быть оттуда получена в любое время. Сервер может использовать т. н. дельта-компрессию — такой способ хранения документов, при котором сохраняются только изменения между последовательными версиями, что позволяет уменьшить объём хранимых данных.
Иногда создание новой версии выполняется незаметно для пользователя (прозрачно), либо прикладной программой, имеющей встроенную поддержку такой функции, либо за счёт использования специальной файловой системы. В этом случае пользователь просто работает с файлом, как обычно, и при сохранении файла автоматически создаётся новая версия.
Часто бывает, что над одним проектом одновременно работают несколько человек. Если два человека изменяют один и тот же файл, то один из них может случайно отменить изменения, сделанные другим. Системы управления версиями отслеживают такие конфликты и предлагают средства их решения. Большинство систем может автоматически объединить (слить) изменения, сделанные разными разработчиками. Однако такое автоматическое объединение изменений, обычно, возможно только для текстовых файлов и при условии, что изменялись разные (непересекающиеся) части этого файла. Такое ограничение связано с тем, что большинство систем управления версиями ориентированы на поддержку процесса разработки программного обеспечения, а исходные коды программ хранятся в текстовых файлах. Если автоматическое объединение выполнить не удалось, система может предложить решить проблему вручную.
Часто выполнить слияние невозможно ни в автоматическом, ни в ручном режиме, например, если формат файла неизвестен или слишком сложен. Некоторые системы управления версиями дают возможность заблокировать файл в хранилище. Блокировка не позволяет другим пользователям получить рабочую копию или препятствует изменению рабочей копии файла (например, средствами файловой системы) и обеспечивает, таким образом, исключительный доступ только тому пользователю, который работает с документом.
Многие системы управления версиями предоставляют ряд других возможностей:
Позволяют создавать разные варианты одного документа, т. н. ветки, с общей историей изменений до точки ветвления и с разными — после неё.
Дают возможность узнать, кто и когда добавил или изменил конкретный набор строк в файле.
Ведут журнал изменений, в который пользователи могут записывать пояснения о том, что и почему они изменили в данной версии.
Контролируют права доступа пользователей, разрешая или запрещая чтение или изменение данных, в зависимости от того, кто запрашивает это действие.
Subversion (SVN) — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.
Цель проекта — заменить собой распространенную на тот момент систему Concurrent Versions System (CVS), которая ныне считается устаревшей. Subversion реализует все основные функции CVS и свободна от ряда недостатков последней.
В настоящее время Subversion используется многими сообществами разработчиков открытого программного обеспечения (в том числе сообществами, ранее использовавшими CVS). В их числе такие известные проекты, как Apache, GCC, Free Pascal, Python, Ruby, FreeBSD, AROS, Blender, Boost, Tor, OGRE. Subversion также широко используется в закрытых проектах и корпоративной сфере. Хостинг Subversion, в том числе для проектов с открытым кодом, также предоставляют популярные хостинг-проекты SourceForge.net, Tigris.org, Google Code и BountySource.
Mercurial, он же Hg — кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода. В первую очередь она является консольной программой. Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве модулей-расширений на C. Mercurial первоначально была написана для Linux, позже портирована под Windows, Mac OS X и большинство Unix-систем. Репозитории Mercurial управляются при помощи утилиты командной строки hg, но есть и GUI–интерфейсы.
Наряду с традиционными возможностями систем контроля версий, Mercurial поддерживает полностью децентрализованную работу (отсутствует понятие основного хранилища кода), ветвление (возможно вести несколько веток одного проекта и копировать изменения между ветками), слияние репозиториев (чем и достигается «распределённость» работы). Поддерживается обмен данными между репозиториями через HTTP/HTTPS, SSH и вручную при помощи упакованных наборов изменений.
Утилита hg обладает компактным интерфейсом, и Mercurial считается более простой в освоении системой, чем, например, git.
TortoiseSVN — это бесплатный клиент для системы контроля версий Subversion, выполненный как расширение оболочки Windows и распространяемый под лицензией GPL.
Будучи клиентом Subversion, TortoiseSVN позволяет управлять файлами и папками во времени. Файлы хранятся в центральном хранилище, в котором запоминается каждое изменение, сделанное в хранимых файлах и папках. Это даёт возможность восстанавливать старые версии файлов и изучать историю их изменения. Поэтому Subversion и другие системы контроля версий часто называют «машинами времени» для файловой системы.
Распределённые системы управления версиями
Также известны как англ. Distributed Version Control System, DVCS. Такие системы используют распределённую модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.
Когда пользователь такой системы выполняет обычные действия, такие как извлечение определённой версии документа, создание новой версии и тому подобное, он работает со своей локальной копией хранилища. По мере внесения изменений, хранилища, принадлежащие разным разработчикам, начинают различаться, и возникает необходимость в их синхронизации. Такая синхронизация может осуществляться с помощью обмена патчами или так называемыми наборами изменений (англ. change sets) между пользователями.
Описанная модель аналогична созданию отдельной ветки для каждого разработчика в классической системе управления версиями (в некоторых распределённых системах перед началом работы с локальным хранилищем нужно создать новую ветвь). Пока разработчик изменяет только свою ветвь, его работа не влияет на других участников проекта и наоборот. По завершении обособленной части работы, внесённые в ветви изменения сливают с основной (общей) ветвью. Как при слиянии таких ветвей, так и при синхронизации разных хранилищ, возможны конфликты версий. На этот случай во всех системах предусмотрены те или иные методы обнаружения и разрешения конфликтов слияния.
Основное преимущество распределённых систем заключается в их гибкости. Каждый разработчик может вести работу независимо, так, как ему удобно, сохраняя промежуточные варианты документов и передавая результаты другим участникам, когда посчитает нужным. При этом обмен наборами изменений может осуществляться по различным схемам. В небольших коллективах участники работы могут обмениваться изменениями по принципу «каждый с каждым», за счет чего отпадает необходимость в создании выделенного сервера. Крупное сообщество, наоборот, может использовать централизованный сервер, с которым синхронизируются копии всех его участников. Возможны и более сложные варианты — например, с созданием групп для работы по отдельным направлениям внутри более крупного проекта.
Рабочая среда настраивается.
Методы получения и анализа требований к системному программному продукту. Дизайн и юзабилити. Инструментальные средства управления требованиями. Принципы разработки стабильного ядра архитектуры системного программного продукта.
Методы получения и анализа требований:
1) Заказчик хочет получить "желаемый продукт"
2) "Желаемый продукт" - вещь абстрактная, что собственно означает, что сам заказчик особо то не знает что он хочет. Единственное что он может - поделится знаниями о предметной области, о тех бизнесс-процессах которые у него происходят (или свести с теми людьми, кто этими тайными знаниями обладает) + по уже готовому продукту/прототипу дать обратную связь, что так, что не так.
3) Что важно: человек, который общается с заказчиком (или его представителем) должен:
* уметь разговаривать
* быть адекватным
* Иметь опыт как в разработке ПО/бизнес-анализе, так и в предметной области заказчика. Т.е он должен быть неким "мостиком" между конторой заказчика и вашей.
4) Касательно анализа требований: здесь важно адекватно понимать что будет стоять за каждым требованием у вас в продукте. нужно отобрать те 20%, которые покрывают 80% и реализовать именно их. Т.е правильно расставит приоритеты в задачах.
4) Инструментальные средства:
а) Записи: +: быстро, удобно, дешево -: теряются, сложно ранжировать, вычитывать суть.
б) текстовые редакторы.
+: интеграция, расширяемость и оцифрованность, дешево,
-: не позовляет быстро и удобно делать хитрые группировки, выборки и т.д., и не хранит версионность.
в) CRM — созданная внутри компании разработчиков, для разработчиков:
+: гибкость, стоимость = человеко-часа затраченным на разработку
-: сложность реализации, при отсутствии необходимого специалиста, ТП и обслуживание
Итог: если команда крута и слажена то они и на коленке все правильно учтут и сделают, быстренько сдадут и получат плюшки. Первичны люди и процессы, инструменты вторичны и не всегда необходимы.
5) Дизайн и юзабилити. Мы для себя пришли к следующим категориям разделения дизайнаи юзабилити:
а) Внутренности. Самый нижний уровень. Можно сказать первородный источник. Процессы или данные. С архитектурной точки зраения - это может быть поставщик данных (БД, сервис, граббер, датчики), драйвер управления (API других программ, контроллеры, мониторы и т.д то чем по сути мы управляем)
б) Механика. Это понимание того ЗАЧЕМ мы связываем пользователя и внутренности. (Общий пример с интернет магазином: мы связываем базу товаров с пользователем, чтобы продать ему этот товар)
г) Юзабилити. Это понимание того что при этом первично вторично третично для пользователя. Предоставления ему удобных элементов мониторинга, управелния и т.д
д) Дизайн. Всякие фентифлющки узорчики картинки. Особо важное место занимает при острой конкуренции и в товарах массового потребления.
6) Принципы разработки стабильного ядра архитектуры системного программного продукта
а) Брать профессионалов в команду
б) Итерационно строить архитектуру-скелет продукта, аккуратно покрывая ее "кусками мяса" и тестировать на адекватность
в) Тестировать эти самые куски
г) Тестировать все, по-разному много-много раз.
д) Тестировать тестировать тестировать
е) Постпенно внедрять (если это возможно, при невозможности см. пункты в-д) продукт на предприятие, ждать багов и фидбека.