Введение в Программную Инженерию Отчет о хаосе The Standish Group International, “CHAOS Report” Что влияет на успешность программного проекта ? В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ. Путем выхода из кризиса ПО стало создание программной инженерии (software engineering). Инженерия ПО (software engineering) – совокупность инженерных методов и средств создания ПО. Фундаментальная идея программной инженерии: проектирование ПО является формальным процессом, который можно изучать и совершенствовать. Software Engineering ( SE ) 1968 год Конференции НАТО Этапы становления и развития SE: Повторное использование кода (модульное программирование) Рост сложности программ … 70-е и 80-е годы – систематизация и стандартизация процессов создания ПО (структурный подход) 90-е годы – начало перехода к сборочному, индустриальному способу создания ПО (объектно-ориентированный подход). software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. - некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем. Все виды деятельности, выполняемые в процессе промышленного программирования и необходимые для успешного выполнения заказов называют программной инженерией (software engineering) Получается, что так мы обозначаем, во-первых, некоторую практическую деятельность, а во-вторых, специальную область знания. Или другими словами, научную дисциплину. Установление и использование правильных инженерных принципов (методов) для экономичного получения надежного и работающего на реальных машинах программного обеспечения [Bauer 1972]. Программная инженерия является такой формой инженерии, которая применяет принципы информатики (computer science) и математики для получения рентабельных решений в области программного обеспечения [CMU/SEI-90-TR-003]. Наука о принципах и методологиях, применяемых при разработке и сопровождении программных систем. Она изучает применение систематического, упорядоченного и исчисляемого подхода к разработке, эксплуатации и сопровождению программного обеспечения (ПО), применение принципов инженерии по отношению к процессу разработки ПО [IEEE Std 610.12-1990] ТАКИМ ОБРАЗОМ программная инженерия посвящена систематическим, управляемым и эффективным методам создания высококачественного программного обеспечения. Основные цели программной инженерии: Системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения. Качество ПО должно быть высоким. Разработка ПО должна быть осуществлена в рамках выделенного бюджета. Системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющимся ПО. Системы должны быть легко сопровождаемыми и масштабируемыми. «КАЧЕЛИ» - КАК ПРОЕКТИРУЮТСЯ ПРОГРАММЫ ( 1975 ! ) Проблемы при создании ПО Проблемы при создании ПО (2) Международные стандарты В 1972 году IEEE выпустил первый номер Transactions on Software Engineering – труды по программной инженерии. Первый целостный взгляд на эту область профессиональной деятельности появился 1979 году, когда компьютерное общество IEEE подготовило стандарт IEEE Std 730 по качеству программного обеспечения. В 1995 году – выпустили первую версию международного стандарта ISO/IEC 12207 Software Lifecycle Processes. Этот стандарт стал первым опытом создания единого общего взгляда на программную инженерию. Издан соответствующий национальный стандарт России – ГОСТ Р ИСО/МЭК 12207-99. В свою очередь, IEEE и ACM, начав совместные работы еще в 1993 году с кодекса этики и профессиональной практики в данной области (ACM/IEEE-CS Software Engineering Code of Ethics and Professional Practice), к 2004 году сформулировали два ключевых описания того, что сегодня мы и называем основами программной инженерии – Software Engineering: Guide to the Software Engineering Body of Knowledge (SWEBOK), IEEE 2004 Version -Руководство к Своду Знаний по Программной Инженерии; Software Engineering 2004. CurriculumGuidelines for UndergraduateDegree Programsin Software Engineering – Учебный план для преподавания программной инженерии в высших учебных заведениях. SWEBOK Книга представляет собой систематизированное и структурированное изложение основных понятий, связанных с разработкой ПО, объединяющее определения, концепции, методы из множества источников, среди которых стандарты занимают одно из центральных мест. Сам по себе SWEBOK не является ни стандартом, ни методикой, ни моделью. Это просто развернутый справочник, который состоит из десяти разделов, соответствующих десяти основным видам деятельности при разработке ПО. В каждом из разделов даются ссылки на стандарты, полностью или частично описывающие соответствующие процессы. Согласно SWEBOK (Software Engineering Body of Knowledge ) программная инженерия включает в себя 10 основных и 7 дополнительных областей знаний, на которых базируются процессы разработки ПО. К основным областям знаний относятся следующие области: 1. Software requirements — программные требования. 2. Software design — дизайн (архитектура). 3. Software construction — конструирование программного обеспечения. 4. Software testing — тестирование. 5. Software maintenance — эксплуатация (поддержка) программного обеспечения. 6. Software configuration management — конфигурационное управление. 7. Software engineering management — управление в программной инженерии. 8. Software engineering process — процессы программной инженерии. 9. Software engineering tools and methods — инструменты и методы. 10. Software quality — качество программного обеспечения. Дополнительные области знаний включают в себя: 1. 2. 3. 4. 5. 6. 7. Computer engineering — разработка компьютеров. Computer science — информатика. Management — общий менеджмент. Mathematics — математика. Project management — управление проектами. Quality management — управление качеством. Systems engineering — системное проектирование. Опр: Программное обеспечение Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207). Жизненный цикл ПО Одним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса. Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы. Основной нормативный документ, регламентирующий ЖЦ ПО – стандарт ISO/IEC 12207 “Information Technology – Software Life Cycle Processes” (ГОСТ Р ИСО/МЭК 12207-99). Процесс стандартизации ведётся довольно интенсивно. Стандарт ISO/IEC 12207 имеет несколько редакций с 1995 по 2008. Программный процесс — это набор действий и связанных с ними результатов, приводящих к созданию программного продукта. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать) Разработка проекта программы (результат – описание того, как программа будет работать) Кодирование (результат – исходный код и файлы конфигурации) Тестирование программы (результат - контроль соответствия программы требованиям) Документирование (результат – документация к программе) ЭТАПЫ ЖИЗНЕННОГО ЦИКЛА ПО Нет «Православного» деления на этапы разработки ПО: 1 Постановка задачи Постановка задачи – это процессопределения набора сервисов, которые должна предоставлять система, а также определения ограничений, в рамках которых система будет разрабатываться и исполняться. ФАЗЫ ПОСТАНОВКИ ЗАДАЧИ 1. Технико-экономическое обоснование 2. Выявление и анализ требований 3. Спецификация требований 4. Валидация требований 1 ПРОЦЕСС ПОСТАНОВКИ ЗАДАЧИ 2 ПРОЦЕСС РАЗРАБОТКИ ПО Процесс разработки ПО состоит из двух действий: Проектирование – описание структуры ПО, моделей данных, интерфейсов, компонентов, алгоритмов; Реализация – преобразование спецификации разрабатываемой системы в готовый программный продукт. 2 МОДЕЛЬ ПРОЦЕССА ПРОЕКТИРОВАНИЯ 2 РЕАЛИЗАЦИЯ Процесс программирования – это индивидуальная деятельность, которая не может быть описана определенным процессом. Не смотря на это, в компании могут быть выработаны стандарты кодирования: именование переменных и форматирование Методы комментирования и документирования; процесс версиямии исходного управления методов кода; т.п. 3 ПРОЦЕСС ВАЛИДАЦИИ Процесс валидации (верификации и валидации) должен показать, что разработанная система соответствует спецификации и желаниям пользователей системы. Основной объем затрат в процессе валидации приходится на тестирование системы. Но, прежде всего, приведем два главных закона теории тестирования программных продуктов: Невозможно отыскать абсолютно все ошибки в программном продукте. Ошибки остаются всегда. Построение исчерпывающего входного теста невозможно. 3 ТЕСТИРОВАНИЕ Тестирование – это процесс выполнения системы или компонента, при определенных тестировщиком условиях, для наблюдения и для оценки некоторых аспектов работы системы либо компонента. В процессе тестирования производится анализ ПО для выявления несоответствия между существующими особенностями выполнения ПО и требованиями к ПО(выявления дефектов). Тестовый случай – это набор входных данных, условий выполнения системы и ожидаемых результатов, разработанных для определенной цели, как то для оценки определенного пути выполнения приложения или для проверки соответствия определенному требованию. 3 ПРОЦЕСС ТЕСТИРОВАНИЯ Компонентное тестирование (юнит-тестирование): тестируются отдельные компоненты системы для определения корректности их работы. Каждый компонент тестируется независимо от других. Компонентамимогут быть отдельные функции, классы, библиотеки. Системное тестирование (интеграционное тестирование): компоненты объединяются в общую систему и она тестируется как единое целое. В результате выявляются ошибки взаимодействия компонентов и проблемы определения интерфейсов. Приемочное тестирование: финальная стадия процесса тестирования. Система тестируется на данных, предоставленных пользователем (покупателем). Могут выявиться ошибки интерпретации данных и требований к системе, т.к. система может вести себя по-другому на реальных данных. 3 ВНЕДРЕНИЕ ТЕСТИРОВАНИЯ В ПРОЦЕСС РАЗРАБОТКИ ПО 4 РАЗВИТИЕ И ПОДДЕРЖКА ПО Важное отличие ПО от аппаратных платформ и других объектов реального мира– относительная простота изменения и развития. В связи с этим, процент «абсолютно новых» программных систем очень невысок. Большинство – развитие предыдущих, уже вышедших программных решений. Модель ЖЦ ПО это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модель задается в виде практических этапов, необходимых для создания ПО. Модель ЖЦ ПО – это не всеобъемлющее описание процесса разработки ПО. Это абстракция, которая позволяет описать различные подходы к процессу разработки. Можно выделить 3 класса моделей разработки ПО : Водопадная модель Модели поэтапной разработки (итерационные) Компонентно-ориентированная модели ВОДОПАДНАЯ МОДЕЛЬ Модели поэтапной разработки (итерационные) Поэтапная (итерационная) разработка Разработка на основе прототипов: постепенно создаются прототипы разрабатываемой системы, для того чтобы понять конкретные требования заказчика. Поэтапная (итерационная) разработка тесная работа с клиентом, для выяснения требований и постепенное создание финальной версии. В начале – те части, которые понятно как делать. Развитие системы: добавление новых возможностей, предлагаемых клиентом. Модели поэтапной разработки (итерационные) Модели поэтапной разработки (итерационные) ПРИМЕНЕНИЕ ПОЭТАПНОЙ РАЗРАБОТКИ Поэтапная разработка более гибкая, чем водопадная модель, позволяет легче подстраиваться под изменяющиеся требования заказчика Хорошо подходит для небольших и средних по размерам проектов (порядка 500 000 строк кода) ИТЕРАЦИИ ПОЗВОЛЯЮТ контролировать и корректировать ход выполнения проекта эффективнее работать с изменяющимися требованиями; эффективнее работать с рисками на ранних этапах оценивать потенциальные характеристики системы ПРОБЛЕМЫ ПОЭТАПНОЙ РАЗРАБОТКИ Ради скорости разработки в жертву приносится формальность: практически отсутствует документация, производимая на каждом этапе водопадной модели Системы часто слабоструктурированны Постоянные изменения приводят к повреждению структуры ПО. Поддержка и дальнейшее изменение становится дорогой и сложной процедурой. РИСКИ Основное отличие спиральной разработки от других методов разработки ПО – это явная оценка рисков. Риск – это вероятность того, что что-то может пойти не так как хотелось бы. Словарь терминов программной инженерии Каскадная модель — модель жизненного цикла, допускающая (предусматривающая) однократный крупный провал (см. также: спиральная модель). Спиральная модель — модель жизненного цикла, допускающая повторение небольших провалов несколько раз подряде рамках одного проекта (см. также: каскадная модель). Переход к новой технологии — оказание содействия коллективу разработчиков в замене старых бесполезных процессов, методов и средств на новые бесполезные процессы, методы и средства. Пошаговая реализация — поставка нескольких отдельных программных продуктов по стоимости полной системы за каждый продукт. - Гибкая (Agile) методология разработки это концептуальный каркас, в рамках которого выполняется разработка ПО. Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини -прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки. Agile -методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и заказчиков» (product owner- заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другимиметодам Гибкая (Agile) методология разработки - «принимают и схватывают изменения в ходе процесса разработки и отвергают детальное планирование» (Desaulniers and Anderson, 2002): Адаптивная разработка программного обеспечения (Adaptive Software Development, ASD): определяемая миссией, основанная на компонентах, подразумевает итеративные циклы и циклы с известной длительностью, определяемые степенью риска, допускающая изменения. Экстремальное программирование (Extreme Programming, XP): команды разработчиков, менеджеров и пользователей, программирование выполняется парами, итеративный характер процесса, коллективное владение кодами программ. SCRUM: подобен приведенным выше адаптивным жизненным циклам, выполняется на итеративной основе, итерации носят название "спринтов", имеют длительность порядка 30 дней (типовое значение); каждый "спринт" должен дать на выходе определенную степень функциональности продукта; активная роль руководства в течение всего жизненного цикла. Компонентноориентированная модель Компонентно-ориентированная разработка основывается на формальном закреплении повторного использования кода. Программный компонент – это автономный элемент программного обеспечения, предназначенный для многократного использования, который может распространяться для использования в других программах в виде скомпилированного кода. Компонентно-ориентированный подход – Развитие объектно-ориентированного. Создан для проектирования и реализации крупных и распределенных программных систем (корпоративных приложений) С точки зрения КОП программная система – это набор компонентов с четко определенным интерфейсом. Изменения в систему вносятся путем создания новых компонентов или изменения старых. ДОСТОИНСТВА И НЕДОСТАТКИ КОМПОНЕНТНООРИЕНТИРОВАННОЙ РАЗРАБОТКИ Достоинства Уменьшается объем ПО, которое необходимо разработать => уменьшается цена и риски. Уменьшается время разработки Недостатки Компромиссы при выработке требований могут привести к тому, что реальные требования пользователей не будут учтены. Контроль над системой может быть потерян при появлении новых версий используемых компонентов Артефакты - это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом (файлы, документы, шаблоны, коды … СКОЛЬКО ФОРМАЛИЗМА НЕОБХОДИМО? ФАКТОРЫ, ВЛИЯЮЩИЕ НА ОПТИМАЛЬНЫЙ УРОВЕНЬ ФОРМАЛИЗМА Масштаб проекта Новизна проекта Требования заказчика Ожидаемая долговечность проекта Распределение участников А теперь время для ….. Вопросы (Продолжение на след слайде) 1. Процесс разработки ПО (ЖЦ ПО) это… 2. Идеальный процесс разработки ПО это…. 3. По любым, запомнившимся Вам, 2 моделям разработки ПО напишите Название, достоинства, Недостатки 4. Какую модель разработки Вы выберете для каждой системы и почему: Игрушка для Iphone Корпоративное приложение для работы с кадрами ПО для управления рентгеновским аппаратом Вопросы (окончание) 5. 6. Назовите хотя бы один стандарт регламентирующий состав процессов жизненного цикла программных средств. Перечислите организационные процессы ЖЦ ПО в соответствии с базовым международным стандартом ISO/IEC 12207 Методы программной инженерии Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу – окончательную модель решаемой задачи. Так, на этапе спецификаций создается модель – описание требований, которая далее преобразуется в модель проекта ПО, проект – в программный код. При этом важно, чтобы модели метода представлялись графически с помощью некоторого языка представления моделей. Методы должны включать в себя следующие компоненты: Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.) Правила и ограничения, которые надо выполнять при разработке моделей (например, каждый объект должен иметь одинаковое имя) Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов) Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированны до определения операций, связанных с этим объектом) Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: Метод структурного анализа и проектирования Том ДеМарко (1978), Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991). Метод сущность-связь проектирования информационных систем Чен (1976) UML Unified Modeling Language блок-схемы (40г) структурный анализ (60 г SADT, 70 г сущность-связь, потоков данных) Объектно-ориентированный подход стандарт UML(1997 г.) С тех пор вышло несколько версий стандарта UML. Текущая версия UML 2.4.1 Виды диаграмм Каждый вид диаграмм является типом моделей, реализующим определенную точку зрения на программную систему. Виды диаграмм не являются строго обязательными в UML – их можно перемешивать, создавать свои собственные виды диаграмм. Структурные диаграммы диаграммы классов (class diagrams) предназначены для моделирования структуры объектноориентированных приложений классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом; диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов; диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов; диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей – коопераций, композитных компонент и т.д.; диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует); Поведенческие диаграммы диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов; диаграммы случаев использования (use case diagrams) предназначены для «вытягивания» требований из пользователей, заказчика и экспертов предметной области; диаграммы конечных автоматов (state machine diagram) применяются для задания поведения систем; диаграммы взаимодействий (interaction diagram): диаграммы последовательностей (sequence diagram) используются для моделирования временных аспектов внутренних и внешних протоколов ПО; диаграммы схем взаимодействия (interaction overview diagram) служат для организации иерархии диаграмм последовательностей; диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере); временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы. Диаграммы Use Case = диаграммы вариантов использования = диаграммы прецедентов 1. Диаграммы вариантов спользования (Use Case) описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. С помощью вариантов использования (use case) моделируются и документируются функциональные требования к системе . Концепция моделей use case впервые была применена для разработки ПО Айваром Якобсоном в качестве составной части его объектно- ориентированного подхода к программной инженерии. Успех модели оказался столь значительным, что со временем произошла интеграция элементов use case практически во все основные методы объектноориентированного анализа и проектирования Бизнес ВИ и Системные ВИ На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнессущности (и их свойства) и взаимосвязи между ними. Системная диаграмма ВИ На Системной Диаграмме ВИ (СВИ) отображается, как взаимодействуют ваши внутренние Пользователи с вашей автоматизированной Системой, т.е. отображаются пользовательские функциональные требования к ПО. Данная диаграмма используется на этапе Системного Анализа и формализации требований к ПО. Процесс моделирования прецедентов (use case): 1. Установить границы системы 2. Выявить актеров 3. Выявить прецеденты 4. Повторить, пока не стабилизируются Диаграмма вариантов использования (Use Case) Состоит из 4-х компонент: 1. Граница системы – прямоугольник, очерчивающий прецеденты для обозначения границы моделируемой системы 2. Актеры – роли, выполняемые людьми или сущностями, использующими систему 3. Прецеденты - то, что актеры могут делать с системой 4. Отношения – отношения между актерами и прецедентами пример Границы системы отделяет систему от всего остального мира. Контекст изображается в виде прямоугольника с именем системы. Актеры размещаются вне границ блока, а прецеденты – внутри Следует сказать, что рамки системы на диаграммах прецедентов изображают довольно редко, т. к. они неявно подразумеваются самой диаграммой. По сути, этот элемент не привносит в диаграмму какой-либо дополнительной значимой информации, так что его использование дело вкуса аналитика. Появление рамок системы на диаграмме прецедентов чаще всего диктуется особенностями персонального стиля проектирования. Суть диаграммы use case Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. Актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования=прецедент (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами. Актеры Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актер может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Примерами актеров могут быть: клиент банка, банковский служащий, продавец магазина, менеджер отдела продаж, пассажир авиарейса, водитель автомобиля, администратор гостиницы, сотовый телефон и другие сущности, имеющие отношение к концептуальной модели соответствующей предметной области. ИДЕНТИФИКАЦИЯ АКТЕРОВ Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля. Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы. Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей. У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя. ИДЕНТИФИКАЦИЯ АКТЕРОВ Чтобы выявить актеров, спросите: «Кто или что использует или взаимодействует с системой?» (например: Кто устанавливает систему? Кто или что запускает и выключает систему? Кто обслуживает систему? Какие системы взаимодействуют с данной системой? Кто или что получает и предоставляет информацию системе? Происходит ли что-нибудь в точно установленное время?) Стандартные элементы Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого или рядом с ним содержится его краткое название или имя в форме глагола с пояснительными словами. Проверить состояние текущего счета Цель варианта использования заключается в том, чтобы определить фрагмент поведения некоторой сущности без раскрытия внутренней структуры этой сущности. Каждый вариант использования определяет способ применения сущности, который инициализируется по запросу пользователя, представляет собой законченную последовательность действий. • • Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы. Примерами вариантов использования могут являться следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия. ИДЕНТИФИКАЦИЯ ПРЕЦЕДЕНТОВ Чтобы найти прецедент, надо спросить: «Как каждый из актеров использует систему?» и «Что система делает для каждого актера?» Каждому прецеденту должно быть присвоено короткое описательное имя, представляющее собой глагольную группу (в конце концов, прецедент означает «выполнить» что-нибудь!). Во время идентификации прецедентов могут обнаружиться некоторые новые актеры. Это нормально. Иногда приходится очень тщательно анализировать функциональность системы, чтобы выявить всех актеров, причем правильно выявить. Примечания Примечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов использования примечание может носить самую общую информацию, относящуюся к общему контексту системы. Отношения на диаграмме вариантов использования Между компонентами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних актеров и вариантов использования с экземплярами других актеров и вариантов. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования. Рассмотрим: • Отношение ассоциации (association relationship) • Отношение обобщения (generalization relationship) • Отношение включения (include relationship) Кратность характеризует общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Здесь кратность "*" означает, что каждый отдельный клиент банка может оформить для себя несколько кредитов, при этом их общее число заранее неизвестно и ничем не ограничивается. Отношение обобщения (актеров) Обобщение актеров выносит поведение, общее для двух или более актеров, в актера-родителя. Актер-потомок может использоваться везде, где ожидается актер- предок. (Purchaser – покупатель) Отношение обобщения (прецедентов) ОБОБЩЕНИЕ ПРЕЦЕДЕНТОВ Обобщение прецедентов выносит поведение, общее для одного или более прецедентов, в родительский прецедент. В обобщении прецедентов дочерние прецеденты представляют более специализированные формы их родителей. Дочерний прецедент автоматически наследует все возможности своего родителя. Потомки могут: наследовать возможности родительского прецедента; вводить новые возможности; переопределять (менять) унаследованные возможности Отношение включения Отношение «include» выносит шаги, общие для нескольких прецедентов, в отдельный прецедент, который потом включается в остальные. Включающий прецедент мы называем базовым, а тот прецедент, который включается, включаемым. Включаемый прецедент предоставляет поведение своему базовому прецеденту. Включаемые прецеденты могут быть как полными, так и неполными. Если включаемый прецедент неполный, он просто содержит часть потока событий, которая имеет смысл только тогда, когда включена в соответствующий базовый прецедент Пример диаграммы вариантов использования В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу, которая может быть использована при создании соответствующих информационных систем. В качестве актеров данной системы могут выступать два субъекта, один из которых является продавцом, а другой — покупателем. Каждый из этих актеров взаимодействует с рассматриваемой системой продажи товаров по каталогу и является ее пользователем, т. е. они оба обращаются к соответствующему сервису "Оформить заказ на покупку товара". Первоначальная структура диаграммы может включать в себя только двух указанных актеров и единственный вариант использования На следующем этапе разработки данной диаграммы вариант использования "Оформить заказ на покупку товара" может быть уточнен на основе введения в рассмотрение четырех дополнительных вариантов использования. Это следует из более детального анализа процесса продажи товаров, что позволяет выделить в качестве отдельных сервисов такие действия, как обеспечить покупателя информацией о товаре, согласовать условия оплаты товара и заказать товар со склада. С другой стороны, продажа товаров по каталогу предполагает наличие самостоятельного информационного объекта — каталога товаров, который в некотором смысле не зависит от реализации сервиса по обслуживанию покупателей. В нашем случае, каталог товаров может запрашиваться покупателем или продавцом при необходимости выбора товара и уточнения деталей его продажи. Вполне резонно представить сервис "Запросить каталог товаров" в качестве самостоятельного варианта использования. Приведенная диаграмма вариантов использования, в свою очередь, может быть детализирована далее с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. Еще один пример…. Пример диаграммы вариантов использования на БИЗНЕС уровне Пример диаграммы вариантов использования на БИЗНЕС уровне Еще примеры…. ДЕТАЛИЗАЦИЯ ПРЕЦЕДЕНТА Детализация прецедента – это точное определение каждого прецедента. Детализацию всех прецедентов можно производить параллельно, постепенно повышая уровень детализации. Итог: прецедент с спецификацией Спецификация варианта использования Существуют различные шаблоны описания вариантов использования. Например: § Свободный формат, § Полный формат (предложенный А. Коберном), § Таблица в две колонки, § Таблица в три колонки, § Стиль RUP. 1) свободный Свободный формат Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле, например: «Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов». Свободный стиль допускает использование конструкций «Если то». «Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела». 2) Коберн Формат описания варианта использования (по Коберну): Формат описания варианта использования (по Коберну): Название <краткая фраза в виде глагола в неопределённой форме совершенного вида, отражающая цель> Контекст использования <уточнение цели, при необходимости – условия её нормального завершения>. Область действия <ссылка на рамки проекта>. Например – подсистема бухгалтерского учёта. Уровень <один из трёх: обобщённый, цели пользователя, подфункции>. Автор задаёт предопределённую трёхуровневую классификацию требований, в целом соответствующую классификации требований на бизнес-требования, требования пользователей и функциональные требования. Основное действующее лицо <имя роли основного актора или его описание>. Формат описания варианта использования (по Коберну) продолжение: Участники и интересы <список других акторов-участников прецедента с указанием их интересов>. Предусловие <то, что ожидается, уже имеет место>. Минимальные гарантии <что гарантируется акторам-участникам>. Например – в случае неудавшейся транзакции все данные, имевшиеся в системе до её начала, сохраняются неизменными. Формат описания варианта использования (по Коберну) продолжение: Основной сценарий <здесь перечисляются шаги основного сценария, начиная от триггера и вплоть до достижения гарантии успеха>. Формат описания: <Номер шага> <Описание действия> Расширения <здесь последовательно описываются все альтернативные сценарии>. Каждая из альтернатив привязана к шагу основного сценария. Формат описания: <Номер шага.Номер расширения> <Условие>:<Действие или ссылка на подчинённый вариант использования>. Любой из шагов основного сценария может иметь 1 или более ветвлений. Каждое ветвление оформляется в виде расширения. В блоке «Расширения» все расширения описываются последовательно. Формат описания варианта использования (по Коберну) продолжение: Список изменений в технологии и данных <что гарантируется акторам-участникам>. Например – в случае неудавшейся транзакции все данные, имевшиеся в системе до её начала, сохраняются неизменными. Вспомогательная информация <дополнительная информация, полезная при описании варианта использования>. 3) Табличный Диаграмма деятельности При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных операций. При этом отдельные операции могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому. Ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста Процедуру вычисления корней квадратного уравнения можно представить в виде диаграммы деятельности с тремя состояниями действия и ветвлением В языке UML для распараллеливания операций используется специальный символ для разделения (рис. а) и слияния (рис. б) параллельных потоков. Диаграммы деятельности в моделировании бизнес-процессов Для моделирования Б-ПР в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). Имеется в виду визуальная аналогия с плавательными дорожками в бассейне, если смотреть на соответствующую диаграмму. При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый результат этих действий. Для графического представления объектов используются прямоугольник где имя объекта подчеркивается. Далее после имени может указываться характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой. Соответствующая зависимость определяет состояние конкретного объекта после выполнения предшествующего действия. Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Графически состояние действия изображается прямоугольником с закругленными углами Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Переход как элемент языка UML переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой. Поток объектов. Объекты, которые являются входными или выходными данными для какого-либо действия, можно изображать в виде символовобъектов. Такой символ представляет собой объект, который в данный момент может служить входными данными для вычислений или же только что стал выходными данными какого-либо вычисления. Как правило, объект одновременно является и тем и другим. На диаграмме это изображается с помощью пунктирной стрелки, которая идет от исходящего перехода состояния деятельности к символу потока объектов и затем от потока объектов к входящему переходу в деятельность, для которой этот поток объектов служит входными данными. Обычно один и тот же объект является выходными данными для одной деятельности и входными - для другой. Пример фрагмент диаграммы деятельности торговой компании, обслуживающей клиентов по телефону. Подразделениями компании являются отдел приема и оформления заказов, отдел продаж и склад. Этим подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая из которых специфицирует зону ответственности подразделения Центральным объектом процесса продажи является заказ или вернее состояние его выполнения. Вначале до звонка от клиента заказ как объект отсутствует и возникает лишь после такого звонка. Однако этот заказ еще не заполнен до конца, поскольку требуется еще подобрать конкретный товар в отделе продаж. После его подготовки он передается на склад, где вместе с отпуском товара заказ окончательно дооформляется. Наконец, после получения подтверждения об оплате товара эта информация заносится в заказ, и он считается выполненным и закрытым. Упражнение Построить UML Диаграммы ПО, автоматизирующего процесс покупки товара в книжном магазине. Диаграмма ВИ (системный уровень) Диаграмма последовательности для одного из вариантов использования Исходные данные На данный момент книжный магазин «Букварь» не имеет никакой информационной системы. Потребность в ней появилась в связи с увеличением торгового зала и ассортимента книг. На сегодняшний день имеется зал со стеллажами. Книги по жанрам разделены на отделы, такие как «Детективы», «Классическая литература», «Кулинария», «Книги для детей» и т.д., в каждой отделе находится консультант, который помогает клиентам найти интересующую книгу, полагаясь только на свою память. Клиент, получая книгу, следует к кассе. Кассир узнает стоимость товара по «стикеру» наклеенному на книгу. Оплата производится только наличными. Проблемы Консультант может забыть о наличии какой-либо книги. Он должен быть в курсе всех новых поступлений и местонахождении книг, что при наличии большого ассортимента очень тяжело. «Стикеры» нужно наклеить на каждую книгу перед тем как выставить на стеллаж. Это занимает определенное время. Так же может сыграть роль человеческий фактор и некоторые книги останутся без «стикера» или с ошибочным «стикером» (неверная цена). Существует вероятность того что недобросовестные покупатели могут переклеить «стикер» с более дешевой книги на нужную им книгу. В следствии чего книжный магазин потерпит убытки. Оплата производится наличными, что доставляет трудности некоторым покупателям магазина. Решения Книжный магазин «Букварь» имеет потребность в информационной системе, которая бы выполняла следующие функции: Слежение за количеством товара; Формирование каталога; Формирование чека; Запись и хранение данных о продаже; Авторизация платежа. Каждая книга будет иметь свой идентификационный номер, который равен штрих-коду. Кассир будет сканировать сканером штрих-код, на экране появится номер книги, автор, цена согласно каталогу книг. Система сама сформирует чек, а так же запишет данные о продаже. Оплата будет возможна как наличным так и безналичным платежом. Так же в зале будут располагаться терминалы, которыми будут пользоваться консультанты. Вход будет запаролен. С помощью этого терминала консультанты смогут просматривать полный каталог книг, выполнять поиск и фильтрацию по разным критериям. В этом каталоге книги будут «разбиты» по жанрам, аналогично отделам. В каталоге будет храниться полная характеристика каждой книги (Издательство, год и т.д.), номер стеллажа и полки, а так же количество оставшегося товара. Цель Совершенствование бизнеса. Улучшение качества обслуживания клиентов. Сокращение времени расчета с покупателем. Минимизация ошибок вызванных человеческим фактором. Использовать данную систему будут консультанты и кассиры магазина. Система включает в себя компьютер, устройство считывания штрих-кода, программное обеспечение. подсказка - Кассир - Покупатель - Консультант - Банк (который принимает платеж по карточке) Строим диаграмму……. Требования к ПО. Определение ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ – ОСНОВА ПРОЕКТИРОВАНИЯ СИСТЕМЫ Большая часть работы с требованиями проводится в начале проекта, в фазах Начало и Уточнение. До начала работы над анализом и проектированием уже необходимо иметь представление о том, что должно получиться в результате. Выработка требований – это переговорный процесс, поскольку часто выдвигаются противоречивые требования, которые должны быть согласованы. Требования к ПО. Определение определения понятия «требование» - на основе работ Вигерса и стандарта IEEE 610.12 Standard Glossary of Software Engineering Terminology Условие или возможность, требуемая пользователем для решения задач или достижения целей. Условие или возможность, которые должны удовлетворяться системой или которыми система должна обладать для обеспечения условий контракта, стандартов, спецификаций или др. регулирующих документов. Требования к ПО. Определение. Выводы Что ? Требование - это условие (ограничение или возможность), которому должна соответствовать система. Зачем ? Добиться одинакового понимания с заказчиками и пользователями того, что должна делать система. Дать разработчикам полное понимание требований к системе. Определить границы системы. Обеспечить базу для оценки стоимости и времени на разработку системы. Определить пользовательский интерфейс, базируясь на потребностях и целях пользователей. Виды требований Функциональные требования – требования являются описанием поведения и сервисов системы, ее функционала; Они определяют то, что система должна делать Нефункциональные требования – особое свойство или ограничение, накладываемое на систему Прецеденты могут отражать только функциональные требования, которые являются описанием того, что будет делать система. Но существуют требования которые не относятся к функциональности, но являются ограничениями, накладываемыми на систему (производительность, надежность) Уровни требований Булуй Ю.И. Классификация требований к ПО и ее представление в стандартах. Виды и уровни требований (по Вигерсу) Виды деятельности по разработке и управлению требованиями (SWEBOK) Фиксация требований Требования как таковые – это некоторая абстракция. В реальной практике они всегда существуют в виде какого-то представления – документа, модели, формальной спецификации, списка и т.д. Формализация требований в проекте может быть очень разной – это зависит от его величины, принятого процесса разработки, используемых инструментальных средств, а также тех задач, которые решают формализованные требования. Более того, может существовать параллельно несколько формализаций, решающих различные задачи: Структурированный естественный язык … Языки описания программ … Графические нотации (ex. UML Use Case) Документирование требований Документы Обзор продукта. Внешнее описание системы. (1) документ, составленный на основании пожеланий заказчика, достаточно точно определяющий задачи разработчиков ПС (2) постановка задачи, решение которой должно обеспечить разрабатываемое ПС Системные модели диаграммы прецедентов, деятельности, user story Техническое задание включает в себя введение, основание для разработки, назначение разработки, требования к программе, требования к программной документации, технико-экономические показатели, стадии и этапы разработки, порядок контроля и приема ТРАДИЦИОННОЕ ОПИСАНИЕ ТРЕБОВАНИЙ ПРИМЕРЫ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ ПРИМЕРЫ НЕФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ АТРИБУТЫ ТРЕБОВАНИЙ Набор критериев важности «MoSCoW» Управление требованиями область знаний, касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований. /SWEBOK/ Управление требованиями - это систематический подход к обнаружению, организации, документированию и сопровождению изменяющихся требований к системе. Управление требованиями Выполняемые работы ПОИСК ТРЕБОВАНИЙ непосредственные пользователи системы другие заинтересованные стороны (например, руководители, специалисты обслуживания, установщики) другие системы, с которыми взаимодействует данная система аппаратные устройства, с которыми взаимодействует данная система правовые и регулирующие ограничения технические ограничения ПОИСК ТРЕБОВАНИЙ Интервьюирование. Получение информации от пользователя «не равно» получению требований. Информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является «входом» в процессы сбора требований, а сами требования – «выходом» этих процессов. Сценарии. Люди предпочитают работать с примерами из реальной жизни, а не с абстрактными описаниями. С их помощью можно дополнять описание деталями. ПОИСК ТРЕБОВАНИЙ (2) Этнография. Системный аналитик внедряется в будущее окружение системы и наблюдает повседневную работу. Общая задача - понять социальное и организационное окружение; часто удается выявить неявные требования к системе, отражающие реальные, а не формальные процессы в системе. Выявление требований на основе опорных точек зрения (viewpoint-oriented elicitation). Основано на том, что в каждой системе существует целый ряд сторон и участников процесса, и для полноценного описания системы необходимо учесть все точки зрения. ИНТЕРВЬЮ Escape-словарь терминов программной инженерии Анализ требований – предварительное определение того, что не удастся реализовать, перед тем как реализация провалится. Оценка требований – доступное и умелое разъяснение заказчикам тех требований, которые не будут реализованы, с использованием терминологии и жаргона, которых они не понимают. Управление требованиями — умелое убеждение заказчика в том, что он хочет именно то, что вам, по-видимому, удастся реализовать. Системный аналитик – программист-неудачник, которого для обеспечения целостности системы убирают подальше от любой клавиатуры. ВЕРНЕМСЯ НА СЛАЙД 32 !!!! Архитектура ПО 214 Архитектура ПО внутренняя структура продукта (компоненты и их связи), основы пользовательского интерфейса продукта, а также квинтесенция знаний и решений, являющихся инструментом разработки и управления проектом. 215 То есть архитектура – это сквозная концепция или набор таковых для преодоления энтропии и хаоса, стремящихся «проглотить» разработку в виду сложности, нематериальности, согласовываемости и изменчивости ПО. 216 При разработке архитектуры ПО важным оказывается совмещение множества точек зрения. ПО оказывается настолько сложным, что его архитектуру не построить как единую модель – множество отдельных аспектов должны быть представлены в архитектуре, их связи сложны и плохо выразимы в явном виде. Полезнее оказывается создание множества моделей, созданных с разных точек зрения. 217 Причина множественности точек зрения при разработке ПО 218 Это происходит, прежде всего, из-за разных видов деятельности процесса разработки ПО (см. рис. Сл.слайд). При составлении функциональных требований к ПО обращают внимание на то, какая именно функциональность должна быть реализована, но при этом опускаются принципы и детали реализации. При проектировании, наоборот, на первое место выходят принципы реализации ПО. А при тестировании детали реализации снова неважны — на ПО смотрят как на черный ящик, реализующий (не важно каким способом) некоторый набор пользовательской функциональности. При развертке у заказчика на ПО смотрят как на набор файлов, хранилищ данных и т. д. 219 Разные виды деятельности – разные взгляды на систему 220 Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (см. рис. на след слайде). Для всех эти специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды… 221 Разные специалисты – разные взгляды на систему 222 Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО. То есть разработка ПО во многом «state of art». Часто приходится изобретать новую точку моделирования зрения прямо по ситуации – чтобы именно этот эксперт тебя понял, чтобы именно эти особенности системы были отражены. Итак, разные виды деятельности при разработке ПО, разные категории специалистов, задействованные в программном проекте, и уникальность каждой конкретной ситуации при разработке — все это приводит к созданию и использованию различных моделей, выполненных с разных точек зрения. 223 Точка зрения (viewpoint) — это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта. Важнейшими характеристиками точки зрения моделирования является цель (зачем создается модель) и целевая аудитория (то есть, для кого она предназначается). 224 Часто понятие архитектуры сильно сужают, понимая под ним лишь описание основных, важных аспектов ПО, создаваемых, например, архитектором при разработке дизайна системы. Для этих целей используется язык моделирования UML (Unified Modeling Language). 225 UML 226 Диаграмма классов 227 Пример диаграмм размещений 228 Пример диаграмм компонент 229 Проектирование пользовательского интерфейса Принципы проектирования пользовательского интерфейса структура, простота, видимость, обратная связь, толерантность повторное использование Структурный принцип Организация пользовательского интерфейса должна быть целесообразной, осмысленной и удобной. Она должна базироваться на четких, целостных моделях, очевидных и распознаваемых пользователями. При этом родственные понятии должны быть связаны, а независимые – разделены. Непохожие элементы должны дифференцироваться, а похожие – выглядеть похоже. Принцип простоты Следует максимально упрощать управление наиболее распростра- ненными операциями. При этом общение с пользователем должно вестись на понятном для него языке. Должны предоставляться ссылки, логичным образом указывающие на более сложные процедуры. Принцип видимости Все функции и данные, необходимые для выполнения данной задачи, должны быть видны, чтобы пользователь не отвлекался на дополнительную и избыточную информацию. Принцип обратной связи Сообщайте пользователям о действиях системы, ее реакциях, изменениях состояния или ситуации, об ошибках и исключениях, которые важны для них. Сообщения должны быть четкими, краткими, однозначными и написанными на языке, понятном пользователю. Принцип толерантности Интерфейс должен быть гибким и толерантным. Ущерб, наносимый ошибками пользователи, необходимо снижать за счет возможности отмены и повтора действий и за счет предотвращения появлений этих ошибок путем анализа различных форматов ввода и разумной интерпретации любых разумных действий. Принцип повторного использования Следует многократно использовать внутренние и внешние компоненты и принципы поведения системы, поддерживая устойчивость осмыслен- но, а не просто за счет избыточности. Это способствует уменьшению объема информации, которую пользователям приходится запоминать и о которой приходится думать каждый раз заново. Ошибки (??) «Пузатость». Кнопки одной смысловой группы разного размера «Частокол». Длина кнопок подогнана по длине текста надписи «Воздух». Излишнее удлинение кнопки мешает читать текст «Разнокалиберные». Шрифты разного размера
