Эффективная подготовка к государственным междисциплинарным экзаменам для студентов технических специальностей (стр. 16 )

Последующие релизы UML включали версии 1.3, 1.4 и 1.5, опубликованные, соответственно в июне 1999, сентябре 2001 и марте 2003 года.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD (англ.).

UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

Преимущества UML

UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;

UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;

UML расширяем и позволяет вводить собственные текстовые и графические стереотипы, что позволяет применять не только в сфере программной инженерии;

UML получил широкое распространение и динамично развивается.

n  Семантика языка UML. Она представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.

n  Нотация языка UML. Она представляет собой графическую нотацию для визуального представления семантики языка UML.

Основные сущности UML:

n  Структурные

·  Класс (class),

·  Объект (Object),

·  Интерфейс (interface),

·  Компонент (component),

·  Действующее лицо (actor),

·  Вариант использования (use case),

·  Кооперация(collaboration),

·  Узел (node)

n  Поведенческие

·  Состояние (state)

·  Деятельность (activity)

·  Действие (action)

n  Группирующие

·  Пакет (Package)

n  Аннотационные

·  Примечание (Note)

Канонические диаграммы UML:

·  Классов (class diagram)

·  Объектов (object diagram)

·  Использования (use case diagram)

·  Последовательности (sequencediagram)

·  Кооперации (collaboration diagram)

·  Состояний (state chart diagram)

·  Деятельности (activity diagram)

·  Компонентов (component diagram)

·  Размещения (deployment diagram)

Это язык для специфицирования (создания спецификации), конструирования, визуализирования и документирования артифактов программных систем.

Артифактами, в контексте проектирования на UML, можно называть сделанные в процессе анализа и проектирования решения, которые определенным образом визуализированы с помощью различных диаграмм, условных обозначений на диаграммах и различных связей между этими обозначениями.

UML не привязан к какому-либо конкретному языку программирования, просто существуют инструменты моделирования поддерживающих UML, которые позволяют на основе описанной модели проверить ее "на корректность" и сгенерировать "скелет" системы или ее части.

Например, в терминах С++ для определенного класса это выражается в генерации - файла заголовка *.h и файла реализации *.cpp, со сделанным вами полным описанием атрибутов, методов класса, комментариями и пустой реализацией этих методов. Например, наиболее известный продукт Rational Rose предоставляет возможность выполнять подобное взаимодействие со многими объектно-ориентированными языками, некоторыми СУБД и умеет интегрироваться с некоторыми средами програмирования - С++, Java - различные версии JDK, VB 5.0 - 6.0, VC++ 6.0, COM, CORBA, Oracle.

Сама реализация, кодирование вашей программы (программной системы, проекта) выполняется уже в среде программирования, где можно выполнять компиляцию и сборку программы.

Простое генерирование файлов - это слишком упрощенное описание возможностей среды моделирования, но с другой стороны... Заложенные в таких системах возможности, как создание модели из исходного кода - обратное преобразование (Reverse Engineering), так и возможность затем выполнять обновление кода из модели (Update Code) и модели из кода (Update Model) приводит к стандартному процессу любой разработки ПО - последовательно-итеративному проектированию (Round-Trip Engineering).

·  Первое и основное, Unified Modelling Language вобрал в себя концепции Booch, OMT и OOSE. В результате мы имеем один, общий и широко используемый язык моделирования для пользователей этих и других методов.

·  UML как бы "снимает обертку" с того что может быть сделано с помощью существующих методов. В качестве примера, авторы UML воспользовались им при моделировании конкурентной, распределенной системы, для того чтобы убедиться, что он компетентно адресован и этой предметной области.

·  Третье, UML фокусируется на стандартизации языка моделирования, а не на стандартизации процесса моделирования. Хотя UML должен применяться в контексте этого процесса. Различные организации и различные предметные/проблемные области требуют различных процессов. Авторы UML предлагают процесс разработки, который: основан на сценариях, сфокусирован на архитектуре системы, является итеративным и поступательным.

·  Кроме этого UML может найти применение в самых различных областях человеческой жизнедеятельности, где требуется анализ и оптимизация функционирования систем любой природы.

UML специфицирует язык, который объединяет базовые концепции общепринятые в объектно-ориентированном сообществе. Он также позволяет выражать "отклонения" с помощью механизма расширения.

7. Экстремальное программирование: основные концепции, достоинства

Экстремальное программирование (дальше XP) – методология создания ПО, позволяет сделать этот процесс более прогнозируемым, гибким и быстрым, в соответствии с требованиями современного бизнеса. XP основывается на идее адаптации изменений в программном проекте вместе с отказом от детального планирования. XP отходит от традиционного процесса создания программной системы и вместо единоразового планирования, анализа и проектирования с расчетом на долгосрочную перспективу при XP все эти операции реализуются постепенно в ходе разработки, добиваясь тем самым значительного сокращения времени разработки и стоимости изменений в программе. Возникло в первой половине 90-х годов. Автор термина XP Кент Бек – пришел к выводу, что разработку любого программного проекта можно сделать более эффективной, если приложить усилия в четырех основных направлениях: усовершенствовать взаимосвязь разработчиков, упростить проектные решения, усилить обратную связь с заказчиком и проявлять больше активности. Эти четыре направления и стали приоритетными в XP. Основные концепции Экстремального Программирования:

Планирование:

·  Пишутся User Stories. Через которые заказчик рассказывает какую программу он хочет получить.

·  Собственно план создается в результате Планирования Релиза - определяет даты релизов и формулировки заказчика, которые будут воплощены в каждом из них.

·  Выпускать частые небольшие Релизы – Заказчик всегда имеет работающую версию программы с последними реализованными фичами.

·  Измеряется Скорость проекта – позволяет понять все ли мы делаем правильно и укладываемся ли в срок.

·  Проект делится на Итерации – это позволяет получать отдачу от заказчика и корректировать программу.

·  Каждая итерация начинается с собрания по планированию.

·  Люди постоянно меняются задачами – знания по проекту распространяются в команде.

·  Каждый день начинается с утреннего Собрания стоя.

·  XP правила корректируются, если что-то не так – это добавляет гибкость методологии.

Дизайн:

·  Простота. Все фичи реализуются максимально простым способом.

·  Писать Пробные решения для уменьшения риска.

·  Не добавлять никаких функций раньше времени. Добавлять только ту функциональность которая действительно требуется в данный момент.

·  Рефакторить безжалостно - Упрощать написанный код.

Кодирование:

·  Заказчик всегда рядом. Заказчик является членом команды и отвечает на вопросы разработчиков.

·  Весь код должен соответствовать принятому стандарту.

·  Любая строчка программы написана 2 программистами.

·  Частая интеграция кода – избавляет от трудностей интеграции модулей.

·  Оставлять оптимизацию на потом.

Тестирование:

·  Любой код должен иметь Unit Test. Тесты пишутся до написания кода.

·  ВСЕ Unit тесты должны проходить перед отдачей.

·  Если найден баг то тесты корректируются или создаются.

·  Функциональные тесты периодически выполняются и их результаты публикуются.

Плюсы:

·  XP строится на том, что создавать простую и понятную программу выгоднее, чем сложную и запутанную.

·  В XP тестированию уделяется особое внимание. Тесты разрабатываются до того, как начнется написание программы, во время работы и после того, как кодирование завершено.

·  Готовность программистов к постоянным изменениям в проекте. За счет постоянной обратной связи с заказчиком ЭП позволяет вносить изменения именно на той стадии, когда это действительно эффективно.

Минусы:

·  Невозможно использовать XP на гигантских проектах — оно подходит для небольших групп программистов (от 2 до 10 человек).

·  Не подходит для распределенных команд, связанных между собой с помощью Интернета.

Ключевые концепции XP

Ценности это то, что отличает набор индивидуалов от команды. Кент Бек в своей книге "Extreme Programming Explained: Embrace Change" выделил основные ценности XP:

Общение. Довольно часто в проектах возникают проблемы, если кто-то не сказал кому-то что-то с некоторой точки зрения важное. XP делает практически невозможным не общаться.

Простота. XP предлагает в процессе написания кода всегда делать самую простую вещь, которая смогла бы работать. Бек описывает это так: "XP делает ставку на то, что лучше сегодня сделать простую вещь... чем более сложную, но которая все равно никогда не будет использоваться".

Обратная связь. Постоянная обратная связь с заказчиком, группой или реальными конечными пользователями дает Вам больше возможностей регулировать вашу работу. Обратная связь позволяет Вам придерживаться правильного пути.