UML

Запрос «Язык моделирования»[d] перенаправляется сюда. На эту тему нужно создать отдельную статью.

UML

Создатель |  Object Management Group
Создан |  1995
Официальный сайт |  uml.org (англ.)
Медиафайлы на Викискладе

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

## Содержание

* 1 Описание
* 2 Использование
* 3 История
* 3.1 До UML 1.x
* 3.2 UML 1.x
* 3.3 UML 2.x
* 4 Диаграммы
* 4.1 Диаграмма классов
* 4.2 Диаграмма компонентов
* 4.3 Диаграмма композитной/составной структуры
* 4.4 Диаграмма развёртывания
* 4.5 Диаграмма объектов
* 4.6 Диаграмма пакетов
* 4.7 Диаграмма деятельности
* 4.8 Диаграмма автомата
* 4.9 Диаграмма прецедентов (Диаграмма вариантов использования)
* 4.10 Диаграммы коммуникации и последовательности
* 4.11 Диаграмма обзора взаимодействия
* 4.12 Диаграмма синхронизации
* 5 Преимущества UML
* 6 Критика
* 7 См. также
* 8 Примечания
* 9 Литература
* 10 Ссылки

## Описание

[править | править код]

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

## Использование

[править | править код]

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (англ. generalization), агрегация (англ. aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

## История

[править | править код]

История объектно-ориентированных методов и нотации.

Предпосылки появления языка моделирования UML обозначились в связи с бурным развитием во второй половине XX века объектно-ориентированных языков программирования (Simula 67, Smalltalk, Objective C, C++ и др). Вследствие непрекращающегося усложнения создаваемых программных продуктов возникла нужда в учёте всё новых и новых возможностей языков и средств разработки при анализе, формулировании требований и в процессе проектирования программных приложений. Например, в короткий промежуток времени с 1989 года по 1994 год количество объектно-ориентированных инструментов выросло с десятка до более чем полусотни. Однако многие разработчики затруднялись подобрать язык моделирования, который бы полностью отвечал всем их потребностям. В результате выделилось новое поколение методов разработки, среди которого особую популярность приобрели метод Буча, созданный Якобсоном Object-Oriented Software Engineering (OOSE) и разработанный Рамбо Object Modeling Technique (OMT). Помимо них существовали и другие завершённые технологии, например Fusion, Shlaer-Mellor и Coad-Yourdon, однако всем из них были присущи не только преимущества, но и существенные недостатки[1].

### До UML 1.x

[править | править код]

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования Object-Modeling Technique и Booch. OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон («три амиго»), выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

### UML 1.x

[править | править код]

Версия | Дата принятия

|

1.1 | ноябрь 1997[2]
1.3 | март 2000[3]
1.4 | сентябрь 2001[4]
1.4.2 | июль 2004[3]
1.5 | март 2003[5]
2.0 | июль 2005[6]
2.1 | формально не была принята[3]
2.1.1 | август 2007[7]
2.1.2 | ноябрь 2007[8]
2.2 | февраль 2009[9]
2.3 | май 2010[10]
2.4 beta 2 | март 2011[11]
2.5 | июнь 2015[12]
2.5.1  | декабрь 2017[13]

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.

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

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

### UML 2.x

[править | править код]

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

UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2[12].

## Диаграммы

[править | править код]

В UML используются следующие виды диаграмм (для исключения неоднозначности приведены также обозначения на английском языке):

Structure Diagrams:

* Class diagram
* Component diagram
* Composite structure diagram
* Collaboration (UML2.0)
* Deployment diagram
* Object diagram
* Package 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 2.3 можно представить на диаграмме классов UML:

### Диаграмма классов

[править | править код]

Диаграмма классов (Class diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:

* концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
* точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
* точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

### Диаграмма компонентов

[править | править код]

Диаграмма компонентов (Component diagram) — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.

### Диаграмма композитной/составной структуры

[править | править код]

Шаблон проектирования Декоратор на диаграмме кооперации

Диаграмма композитной/составной структуры (Composite structure diagram) — статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации (Collaboration diagram, введены в UML 2.0), которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

Диаграммы композитной структуры могут использоваться совместно с диаграммами классов.

### Диаграмма развёртывания

[править | править код]

Диаграмма развёртывания (Deployment diagram, диаграмма размещения) — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

### Диаграмма объектов

[править | править код]

Диаграмма объектов (Object diagram) — демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.

### Диаграмма пакетов

[править | править код]

Диаграмма пакетов (Package diagram) — структурная диаграмма, основным содержанием которой являются пакеты и отношения между ними. Жёсткого разделения между разными структурными диаграммами не проводится, поэтому данное название предлагается исключительно для удобства и не имеет семантического значения (пакеты и диаграммы пакетов могут присутствовать на других структурных диаграммах). Диаграммы пакетов служат, в первую очередь, для организации элементов в группы по какому-либо признаку с целью упрощения структуры и организации работы с моделью системы.

### Диаграмма деятельности

[править | править код]

Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

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

Аналогом диаграмм деятельности являются схемы алгоритмов по ГОСТ 19.701—90[14] и дракон-схемы.

### Диаграмма автомата

[править | править код]

Диаграмма автомата (State Machine diagram, диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями.

Конечный автомат (англ. State machine) — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

Аналогом диаграмм автомата (диаграмм состояний) являются дракон-схемы.

### Диаграмма прецедентов (Диаграмма вариантов использования)

[править | править код]

Диаграмма прецедентов или диаграмма вариантов использования (Use case diagram) — диаграмма, на которой отражены отношения, существующие между акторами и вариантами использования.

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

### Диаграммы коммуникации и последовательности

[править | править код]

Диаграммы коммуникации и последовательности транзитивны, выражают взаимодействие, но показывают его различными способами и с достаточной степенью точности могут быть преобразованы одна в другую.

Диаграмма коммуникации (Communication diagram, в UML 1.x — диаграмма кооперации, collaboration diagram) — диаграмма, на которой изображаются взаимодействия между частями композитной структуры или ролями кооперации. В отличие от диаграммы последовательности, на диаграмме коммуникации явно указываются отношения между элементами (объектами), а время как отдельное измерение не используется (применяются порядковые номера вызовов).

Диаграмма последовательности (Sequence diagram) — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления. В частности, на ней изображаются участвующие во взаимодействии объекты и последовательность сообщений, которыми они обмениваются.

Диаграмма сотрудничества — Этот тип диаграмм позволяет описать взаимодействия объектов, абстрагируясь от последовательности передачи сообщений. На этом типе диаграмм в компактном виде отражаются все принимаемые и передаваемые сообщения конкретного объекта и типы этих сообщений.

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

### Диаграмма обзора взаимодействия

[править | править код]

Диаграмма обзора взаимодействия — разновидность диаграммы деятельности, включающая фрагменты диаграммы последовательности и конструкции потока управления.

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

### Диаграмма синхронизации

[править | править код]

Диаграмма синхронизации (Timing diagram) — альтернативное представление диаграммы последовательности, явным образом показывающее изменения состояния на линии жизни с заданной шкалой времени. Может быть полезна в приложениях реального времени.

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

[править | править код]

* UML объектно-ориентированный, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
* UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
* Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
* UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
* UML получил широкое распространение и динамично развивается.

## Критика

[править | править код]

Несмотря на то, что UML — достаточно широко распространённый и используемый стандарт, его часто критикуют из-за следующих недостатков:

* Избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов.
* Неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.
* Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно заставляет использовать UML инженеров при отсутствии у них предварительных навыков[15].
* Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»)[16][17]. В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода. Однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент.
* Кумулятивная нагрузка/Рассогласование нагрузки (Cumulative Impedance/Impedance mismatch). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).
* Пытается быть всем для всех. UML — это язык моделирования общего назначения, который пытается достигнуть совместимости со всеми возможными языками разработки. В контексте конкретного проекта, для достижения командой проектировщиков определённой цели, должны быть выбраны применимые возможности UML. Кроме того, пути ограничения области применения UML в конкретной области проходят через формализм, который не полностью сформулирован, и который сам является объектом критики.

## См. также

[править | править код]

* SysML
* IDEF
* DFD
* ДРАКОН

## Примечания

[править | править код]

1. ↑ Г. Буч, Д. Рамбо, И. Якобсон. Краткая история UML // Язык UML. Руководство пользователя = The Unified Modeling Language Usere Guide. — 2-е. — М.: ДМК Пресс, 2006. — С. 14. — 496 с. — ISBN 5-94074-334-X.
2. ↑ UML Specification version 1.1 (OMG document ad/97-08-11) Архивная копия от 18 ноября 2018 на Wayback Machine (англ.)
3. ↑ 1 2 3 OMG Formally Released Versions of UML Архивная копия от 31 июля 2010 на Wayback Machine (англ.)
4. ↑ Documents associated with UML Version 1.4 Архивная копия от 10 мая 2011 на Wayback Machine (англ.)
5. ↑ Documents associated with UML Version 1.5 Архивная копия от 10 мая 2011 на Wayback Machine (англ.)
6. ↑ Documents associated with UML Version 2.0 Архивная копия от 9 января 2010 на Wayback Machine (англ.)
7. ↑ Documents associated with UML Version 2.1.1 Архивная копия от 7 мая 2011 на Wayback Machine (англ.)
8. ↑ Documents associated with UML Version 2.1.2 Архивная копия от 6 июня 2011 на Wayback Machine (англ.)
9. ↑ Documents associated with UML Version 2.2 Архивная копия от 17 апреля 2021 на Wayback Machine (англ.)
10. ↑ Documents associated with UML Version 2.3 Архивная копия от 7 июня 2011 на Wayback Machine (англ.)
11. ↑ Documents associated with UML Version 2.4 — Beta 2 Архивная копия от 9 июня 2011 на Wayback Machine (англ.)
12. ↑ 1 2 3 UML  (неопр.). Дата обращения: 26 июня 2010. Архивировано 31 июля 2010 года.
13. ↑ About the Unified Modeling Language Specification Version 2.5.1  (неопр.). www.omg.org. Дата обращения: 10 сентября 2019. Архивировано 3 июля 2019 года.
14. ↑ ГОСТ 19.701—90 (ИСО 5807—85) «Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения»
15. ↑ http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130 Архивная копия от 7 декабря 2008 на Wayback Machine ACM
16. ↑ Slashdot | The Code Is The Design  (неопр.). Дата обращения: 21 мая 2022. Архивировано 22 апреля 2009 года.
17. ↑ Code as Design: Three Essays by Jack W. Reeves by Jack W. Reeves — developer.*, Developer Dot Star  (неопр.). Дата обращения: 13 февраля 2007. Архивировано 13 февраля 2007 года.

## Литература

[править | править код]

* Крэг Ларман. Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development. — 3-е изд. — М.: Вильямс, 2006. — 736 с. — ISBN 0-13-148906-2.
* Джозеф Шмуллер. Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. — М.: Вильямс, 2005. — 416 с. — ISBN 0-672-32640-X.
* Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя = The Unified Modeling Language user guide. — 2-е изд. — М., СПб.: ДМК Пресс, Питер, 2004. — 432 с. — ISBN 5-94074-260-2.
* Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS / С. Орлов. — 2-е изд.. — СПб.: Питер, 2006. — 736 с. — ISBN 5-46900-599-2.
* Леоненков А. В. Самоучитель UML 2. — СПб.: БХВ-Петербург, 2007. — 576 с.: ил.ISBN 978-5-94157-878-8

## Ссылки

[править | править код]

* Спецификация текущей версии UML
* Сайт ресурсов UML (англ.), поддерживаемый Object Management Group
* UML Resource Center (англ.) IBM
* Unified Modeling Language, версия 2.0 IBM / developerWorks
* UML 2.2 — заготовки и шаблоны для MS Visio
* Простые UML диаграммы для вставки на веб-страницы

Unified Modeling Language

| Акторы|

* Организации: Object Management Group
* UML Partners
* Люди: Гради Буч
* Джеймс Рамбо
* Ивар Якобсон

|

Прочее|

* Rational Unified Process
* Systems Modeling Language
* UML-цвета
* XMI
* Словарь терминов UML

Концепции

| Структура|

* Актор
* Артефакт
* Атрибут
* Интерфейс
* Класс
* Классификатор
* Компонент
* Объект
* Пакет
* Узел

|

Поведение|

* Деятельность
* Метод
* Прецедент
* Событие
* Сообщения
* Состояние

Отношения|

* Composition
* Агрегирование
* Ассоциация
* Наследование
* Обобщение понятий
* Связанность

Растяжимость|

* Профиль
* Стереотип
* Другие понятия: Мощность отношений

Диаграммы

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

* Классов
* Композитной структуры
* Компонентов
* Объектов
* Пакетов
* Развёртывания

|

Поведения|

* Деятельности
* Прецедентов
* Состояний

Взаимодействия|

* Коммуникации
* Обзора взаимодействия
* Последовательности
* Синхронизации

Разработка программного обеспечения

Процесс|

* Стадии разработки
* Анализ требований
* Проектирование
* Программирование
* Тестирование
* Документирование

Высокоуровневые
концепции|

* Архитектура ПО
* Парадигма
* Методология
* Процесс разработки
* Качество

Направления|

* Программирование (Аспектно-ориентированное
* Объектно-ориентированное
* Предметно-ориентированное)

Методологии
разработки|

* Agile
* Cleanroom
* CASE
* UP
* RUP
* OpenUP
* RAD
* Scrum
* SAFe
* Модель Spotify
* MSF
* XP
* DSDM

Модели|

* Итеративная
* Каскадная
* Спиральная
* V-Model
* Dual Vee Model
* CMM
* CMMI
* Данных
* Function model[англ.]
* IDEF
* Информационная
* Метамодель
* Object model[англ.]
* View model[англ.]
* UML

Известные
деятели|

* Кент Бек
* Гради Буч
* Фред Брукс
* Уорд Каннингем
* Оле-Йохан Даль
* Том Демарко
* Эдсгер Дейкстра
* Дональд Кнут
* Алан Кэй
* Мартин Фаулер
* Энтони Хоар
* Ивар Якобсон
* Бертран Мейер
* Никлаус Вирт
* Эдвард Йордан
* Стив Макконнелл
* Джеймс Рамбо
* Барри Боэм
* Уоттс Хамфри[англ.]
* Майкл А. Джексон[англ.]
* Крэг Ларман
* Роберт Мартин
* Джеймс Мартин[англ.]
* Дэвид Парнас[англ.]
* Уинстон Ройс

Стандарты ISO

* Категории:  Категория:Стандарты ISO
* Категория:Протоколы OSI

9999|

* 1
* 2
* 3
* 4
* 6
* 7
* 9
* 16
* 31
* -0
* -1
* -2
* -3
* -4
* -5
* -6
* -7
* -8
* -9
* -10
* -11
* -12
* -13
* 128
* 216
* 217
* 226
* 228
* 233
* 259
* 269
* 296
* 302
* 306
* 428
* 639
* -1
* 646
* 668
* 690
* 732
* 764
* 796
* 843
* 898
* 1000
* 1004
* 1007
* 1073-1
* 1413
* 1538
* 1745
* 2014
* 2015
* 2022
* 2108
* 2145
* 2146
* 2281
* 2709
* 2711
* 2788
* 3029
* 3103
* 3166
* -1
* -2
* -3
* 3297
* 3307
* 3602
* 3864
* 3901
* 3977
* 4031
* 4157
* 4217
* 5218
* 5775
* 5776
* 5964
* 6166
* 6344
* 6346
* 6425
* 6429
* 6438
* 6523
* 6709
* 7001
* 7002
* 7098
* 7185
* 7388
* 7498
* 7736
* 7810
* 7811
* 7812
* 7813
* 7816
* 8000
* 8217
* 8571
* 8583
* 8601
* 8632
* 8652
* 8691
* 8807
* 8820-5
* 8859
* -1
* -2
* -3
* -4
* -5
* -6
* -7
* -8
* -9
* -10
* -11
* -12
* -13
* -14
* -15
* -16)
* 8879
* 9000
* 9075
* 9126
* 9241
* 9362
* 9407
* 9506
* 9529
* 9564
* 9594
* 9660
* 9897
* 9945
* 9984
* 9985
* 9995

10000

19999|

* 10006
* 10118-3
* 10160
* 10161
* 10165
* 10179
* 10206
* 10303
* 10303-11
* 10303-21
* 10303-22
* 10303-238
* 10303-28
* 10383
* 10487
* 10585
* 10589
* 10646
* 10664
* 10746
* 10861
* 10957
* 10962
* 10967
* 11073
* 11170
* 11179
* 11404
* 11544
* 11783
* 11784
* 11785
* 11801
* 11898
* 11940
* 11941
* 11941 (TR)
* 11992
* 12006
* 12164
* 12182:1998
* 12207:1995
* 12207:2008
* 12234-2
* 13211
* -1
* -2
* 13216
* 13250
* 13399
* 13406-2
* 13407
* 13450
* 13485
* 13490
* 13567
* 13568
* 13584
* 13616
* 14000
* 14031
* 14396
* 14443
* 14496-10
* 14496-14
* ISO 14575
* 14644
* -1
* -2
* -3
* -4
* -5
* -6
* -7
* -8
* -9
* 14649
* 14651
* 14698
* 14698-2
* 14750
* 14882
* 14971
* 15022
* 15189
* 15288
* 15291
* 15292
* 15408
* 15444
* 15445
* 15438
* 15504
* 15511
* 15686
* 15693
* 15706
* 15706-2
* 15707
* 15897
* 15919
* 15924
* 15926
* 15926 WIP
* 15930
* 16023
* 16262
* 16750
* 17024
* 17025
* 17369
* 17799
* 17987
* 18000
* 18004
* 18014
* 18245
* 18629
* 18916
* 19005
* 19011
* 19092-1
* 19092-2
* 19114
* 19115
* 19439
* 19501:2005
* 19752
* 19757
* 19770
* 19775-1
* 19794-5

20000+|

* 20000
* 20022
* 20121
* 21000
* 21047
* 21500
* 21827:2002
* 22000
* 23008-2
* 23270
* 23360
* 24613
* 24707
* 25964-1
* 25178
* 26000
* 26300
* 26324
* 27000 series
* 27000
* 27001
* 27002
* 27003
* 27004
* 27005
* 27006
* 27007
* 27729
* 27799
* 29199-2
* 29500
* 31000
* 32000
* 38500
* 42010
* 50001
* 80000

См. также: Список статей, названия которых начинаются с «ISO»
*[М.]: Москва
*[СПб.]: Санкт-Петербург