13) Лучшие инструменты UML
UML расшифровывается как унифицированный язык моделирования. Это стандарт, который в основном используется для создания объектно-ориентированных, значимых моделей документации для любой программной системы, представленной в реальном мире. Он предлагает богатые модели, которые описывают работу любых программных / аппаратных систем.
На рынке доступно множество инструментов для разработки UML-диаграмм. Ниже приводится список лучших 28 отобранных инструментов UML с популярными функциями и последними ссылками для скачивания. Этот список сравнения содержит как открытый исходный код, так и коммерческие инструменты.
1) StarUML
StarUML – это инструмент моделирования программного обеспечения с открытым исходным кодом. Это обеспечивает одиннадцать типов диаграмм. StartUML 2 совместим с версиями UML 2.x.
Особенности:
- Позволяет создавать диаграммы Obje3ct, Use case, Deployment, Seque3nce, Communication, Activity и профиля.
- Позволяет обнаруживать и устанавливать сторонние расширения.
- Работайте с одним и тем же UX на нескольких платформах, включая macOS, Windows и Linux.
- Нет ограничений для использования этого коммерческого программного обеспечения для оценки.
Ссылка для скачивания: http://staruml.io/
2) Умбрелло:
Umbrello – это инструмент моделирования UML. Работает под KDE и Linux. Инструмент также поддерживает генерацию кода и реверс-инжиниринг для C ++ и Java.
Особенности:
- Позволяет создавать схемы программного обеспечения и другой системы в стандартном формате.
- Это поможет вам проверить скриншот, чтобы увидеть umbrello в действии.
- Предлагает руководство по обучению Umbrello и UML-моделированию.
Ссылка для скачивания: htps: //umbrello.kde.org/
3) Эдро Макс
Edraw Max – это программа для построения UML, которая помогает вам создавать диаграммы с использованием готовых символов и шаблонов. Это позволяет вам импортировать ваши рисунки в форматы файлов, такие как PDF, PPT, Word, HTML и т. Д.
Особенности:
- Вы можете создать блок-схему, интеллектуальную карту, UML, электрические схемы, сетевые диаграммы и т. Д.
- Он предоставляет удобный интерфейс, похожий на MS Word.
- Edraw Max поможет вам поделиться дизайном в любое время и в любом месте.
- Этот инструмент предоставляет более 280 новейших решений для схем и диаграмм.
4) UML дизайнерский инструмент:
Инструмент UML Designer предлагает набор общих диаграмм для работы с моделями UML 2.5. Этот инструмент предоставляет простой способ перехода от UML к предметно-ориентированному моделированию.
Особенности:
- Позволяет пользователю повторно использовать предоставленные представления и работать с полной прозрачностью как на моделях DSL, так и на моделях UML.
- Помогает вам создать диаграмму классов, диаграмму компонентов и составную диаграмму структуры
- Позволяет использовать устаревшие модели UML и начать работу с DSL.
5) Альтова
Altova UModel – это еще один полезный инструмент UML, который делает визуальный дизайн программного обеспечения практичным для любого проекта. Визуально проектируйте модели приложений в UML, которые могут быть сгенерированы с использованием Java, C ++, C # или Visual Basic.
Особенности:
- Интуитивное визуальное моделирование для всех диаграмм UML
- Вспомогательные окна позволяют строить нужные модели.
- Это позволяет добавлять гиперссылки к любому элементу в любой диаграмме UML.
- Вы можете назначить элемент определенному слою, и слои могут быть заблокированы, чтобы предотвратить изменения.
6) Umple
Umple – это модель с открытым исходным кодом для интеграции текстовых конструкций UML в языки программирования, генерации кода или использования простого метода моделирования UML.
Особенности:
- Это позволяет разработчикам встраивать шаблоны концепций моделирования, шаблоны генерации и другие абстракции в традиционный код.
- Инструмент Umple помогает пользователям быстрее изучать UML.
- Инструмент может работать онлайн, как плагин Eclipse, а также автономная командная строка Jar.
7) Визуальная Парадигма
Visual Paradigm – это инструмент разработки программного обеспечения, разработанный специально для программных проектов двигателей. Этот инструмент UML помогает команде разработчиков программного обеспечения моделировать информационную систему бизнеса и процессы разработки.
Особенности:
- Он предлагает поддержку BPMN, UML, ERD, DFD, SysML.
- Он предлагает полный инструмент для анализа процессов, проектирования систем, проектирования баз данных и т. Д.
- Предлагает функцию пользовательских историй для захвата и поддержания потребностей пользователей.
8) WhitestarUML
WhiteStarUML – это еще один важный универсальный инструмент моделирования, который предлагает все функции, которые можно адаптировать к современной среде, например поддержку строк Unicode.
Особенности:
- Поддерживаются версии Windows 7, 8, 10.
- Он обеспечивает лучшие функциональные возможности, ожидаемые от инструмента UML, такие как большой выбор поддерживаемых диаграмм.
- Хорошее удобство использования, дающее общее представление о серьезной среде программирования.
9) Draw.IO
Draw.IO – это бесплатный онлайн UML-инструмент. Это позволяет пользователям легко создавать и управлять чертежами этих инструментов. Многие широкие и ранние акции доступны с этим инструментом.
Особенности:
- Нет ограничений на количество размеров
- Шаблоны присутствуют в самой разработке программного обеспечения.
- Позволяет сохранить модель в выбранном вами месте
Ссылка для скачивания : https://www.draw.io/
10) GenMyModel
GenMyModel начинался как инструмент UML, но сегодня он расширен, чтобы охватить также бизнес-моделирование с поддержкой Archimate и BPMN. Он предлагает централизованное хранилище моделей, которое позволяет легко и одновременно моделировать совместную работу.
Особенности:
- Поделитесь своими знаниями с управлением версиями и правами доступа.
- Полезно для презентаций для руководства и заинтересованных сторон проекта.
- Помогает вам объединить возможности настольных средств моделирования с современным веб-решением.
- Позволяет напрямую импортировать или экспортировать как документы PDF.
11) UMLetino:
Он доступен пользователю как инструмент UML с открытым исходным кодом для разработки диаграмм UML. Он может работать напрямую в вашем браузере и не требует установки.
Особенности:
- Диаграммы могут быть экспортированы как XML или любые другие файлы изображений.
- Позволяет хранить диаграммы с другими товарищами по команде
- Предлагает вам экспортировать диаграммы в формате SVG, Gif или JPEG.
12) Диаграмма:
Diagramo – это бесплатное программное обеспечение для создания блок-схем HTML5 с открытым исходным кодом. Это легко скачать и установить на свой сервер.
Особенности:
- Позволяет сохранять диаграммы как изображения
- Это программное обеспечение, ориентированное на блок-схемы, которое представляет собой только один вид UML-диаграмм.
Ссылка для скачивания: http://diagramo.com/
13) Аста
Astah – это UML-редактор, который интегрирован с функциями отображения Mind. Этот инструмент поможет вам визуализировать суть ваших идей перед тем, как приступить к написанию кода.
Особенности:
- Быстрее создать UML по сравнению с Excel или инструментами рисования, не относящимися к UML.
- Визуализировать требования и функциональные требования, все отношения между ними и другими элементами модели.
- Слияние, эксклюзивный контроль, поддержка копирования и вставки.
Ссылка для скачивания: http://astah.net/
14) Программное обеспечение для визуального моделирования
Microsoft focus – это инструмент визуального моделирования, который позволяет бизнесу и разработке программного обеспечения анализировать и проектировать архитектуру программного обеспечения.
Особенности:
- Эта платформа предлагает вам моделировать корпоративные архитектуры таким образом, чтобы требования, архитектуры и код всегда были синхронизированы
- Предлагает модельно-ориентированную архитектуру и системы моделирования данных
- Функция технологии Livesource позволяет использовать исходный код языка программирования для элементов управления и исключить ненужную работу
15) БУМЛ:
BOUML – это бесплатный инструмент UML2, который включает в себя моделер. Это помогает вам определять и генерировать код на C ++, Java, Php, Python и MySQL.
Особенности:
- Он работает под версиями Windows, Linux и MacOS X.
- это помогает вам программировать одновременно на C ++, Java, Php, Python, MySQL и т. д.
- это очень быстро и не требует много памяти для управления несколькими тысячами классов, см. бенчмарк
16) ConceptDraw
ConceptDraw DIAGRAM предлагает полный спектр решений для бизнес-графической документации. Эти UML-решения предлагают специфичные для бизнеса надстройки, которые предлагают широкий спектр требований к рабочему процессу.
Особенности:
- ConceptDraw DIAGRAM v12 предлагает мощные и всеобъемлющие инструменты рисования.
- Помогает вам расширить ваши коммуникационные процессы и улучшить методы презентации.
- Инструмент является идеальным набором для построения программного обеспечения плана.
- Вы можете использовать очень важные бизнес-метрики и отслеживать с технологией живых объектов.
17) Dia:
Dia – это полнофункциональная программа для создания диаграмм, которая лицензирована под лицензией GPL. Он позволяет вам рисовать различные типы диаграмм и имеет специальные объекты, помогающие рисовать диаграммы ER, диаграммы UML, блок-схемы, сетевые диаграммы и многие другие диаграммы.
- Он предлагает поддержку новых фигур путем написания простых файлов XML и использования подмножества SVG для рисования формы.
- Это позволяет экспортировать диаграммы в различные форматы, включая EPS, SVG, XFIG, WMF и PNG.
Ссылка для скачивания: http://dia-installer.de/
18) Sparxsystems
Система Sparx – это инструмент проектирования диаграмм для моделирования документирования, построения и поддержки объектно-ориентированных функций. Это один из ведущих поставщиков инновационных решений на основе языка унифицированного моделирования.
Особенности:
- Помогает вам в эффективном управлении проектами
- Высокопроизводительный репозиторий моделей
- Предлагает сквозную прослеживаемость
- Мощная генерация документов
Ссылка для скачивания: https://sparxsystems.com/
19) Гиффи
Gliffy – это бесплатный онлайн-инструмент для рисования, который поддерживает рисование UML-диаграмм. Это одно из наиболее широко используемых онлайн-приложений для создания диаграмм.
Особенности:
- Позволяет легко нарисовать диаграмму
- Он предлагает силу визуального общения и совместной работы.
- Быстрая и эффективная интеграция с Jira и Confluence
- Сильная поддержка для моделей процессов BPMP
Ссылка для скачивания: https://www.gliffy.com/
20) Люсидчарт
Lucidchart – это инструмент UML на основе HTML-5, который также предлагает возможности совместной работы в режиме реального времени. Это позволяет создавать простую блок-схему сложных технических диаграмм.
Особенности:
- Работает с вашей командой на любом устройстве на разных платформах
- Позволяет вам соединять текущие данные с вашими диаграммами или импортировать данные для автоматического построения организационных диаграмм.
- Помогает вам повысить безопасность и легко управлять учетными записями пользователей
- Он легко интегрируется с MS Office, G Suite, Atlassian и т. Д.
21) Волшебная ничья:
Волшебная ничья – первая полная версия для профессионального моделирования. Современный дизайн и четкая компоновка делают это настольное приложение особенным, особенно для высоких требований.
Особенности:
- Постоянно добавляются новые функции на основе отзывов пользователей
- Плавающие лицензии помогут вам значительно сэкономить, если у вас есть несколько разработчиков, которым необходимо использовать MagicDraw в течение определенного периода времени.
- После покупки вы можете запускать программное обеспечение в различных приложениях.
- Команда экспертов Magic Draw предлагает 24 часа бесплатной поддержки.
- Обучение простое, а период обучения короткий.
22) Visio
Microsoft Visio – это популярное программное обеспечение для построения графиков и визуализации. Он принадлежит к семейству офисов, поэтому его можно легко интегрировать с другими офисными продуктами Microsoft.
Особенности:
- Visio помогает вам создавать профессиональные диаграммы, создавая блок-схемы, диаграммы, организационные схемы, технические проекты и многое другое.
- Позволяет подключать блок-схемы и диаграммы к данным в реальном времени.
- Это позволяет вам работать вместе над диаграммами из веб-браузера практически из любого места.
23) Модель:
Modelio – это первая среда моделирования. Инструмент сочетает в себе поддержку BPMN и поддержку UML. Он обеспечивает поддержку широкого спектра моделей и диаграмм.
Особенности:
- Modelio предлагает функцию импорта / экспорта XMI, которая позволяет вам обмениваться моделями UML2 между различными инструментами.
- Вы можете расширить modelio для любого языка, методологии или техники моделирования.
- Он предлагает интегрированную поддержку языка сценариев Jython.
Ссылка для скачивания: https://www.modelio.org/
24) Nclass
NClass – это бесплатный инструмент, который используется для создания диаграмм классов UML с полной поддержкой C # и языка Java. Он имеет простой и удобный интерфейс для простой и быстрой разработки.
Особенности:
- Диаграмма помогает пользователям создавать профессионально выглядящие диаграммы
- Предлагает простой, но мощный дизайнер классов, который интуитивно понятен в использовании
- Позволяет строить профессионально выглядящие диаграммы
25) Открытая модель:
Open ModelSphere – полезный инструмент для моделирования данных, процессов и инженерного моделирования. Это независимый от платформы инструмент, поддерживающий пользовательский интерфейс на английском и французском языках.
Особенности:
- Предоставляет пользовательские интерфейсы на английском и французском языках.
- Огромная поддержка со стороны сообщества архитекторов и инженеров программного обеспечения.
- Это помогает системным аналитикам интегрировать создание диаграмм потоков данных и бизнес-процессов.
- Экспертные модули для проверки целостности разработанной архитектуры.
26) Системное проектирование рапсодии
Семейство продуктов IBM Engineering Systems Design Rhapsody предлагает широкий спектр решений для моделирования и проектирования UML. Это помогает вам управлять сложностью, с которой сталкиваются многие организации при разработке продуктов и систем.
Характерная черта:
- Предлагает постоянную проверку
- Позволяет выполнять автоматическую проверку согласованности
- Помогает вам сотрудничать с вашей командой инженеров
- Проанализируйте и разработайте требования вашего проекта
- Автоматизируйте обзоры дизайна и генерируйте документацию
27) Softwareideasmodeler
Software Ideas Modeler – это инструмент проектирования для рисования UML, SysML, ERD, ArchiMate, блок-схем. Это позволяет вам создавать пользовательские истории и предлагает поддержку каркаса.
Особенности:
- Предлагает легкую диаграмму и макет.
- Программный инструмент Ideas Modeler предлагает вам множество предопределенных стилей, которые делают ваши диаграммы более привлекательными.
- Документированное программное обеспечение имеет лучшую ремонтопригодность.
ПРОГРАММНЫЕ СРЕДСТВА, ПОДДЕРЖИВАЮЩИЕ ЯЗЫК UML
В настоящее время фирма Rational Software является безусловным лидером в области объектно-ориентированного анализа и проектирования информационных систем с компонентной архитектурой. Разрабатываемая этой фирмой методология, основанная на использовании унифицированного языка моделирования (UML — Unified Modeling Language в настоящее время принят OMG в качестве стандарта), поддержана целым спектром инструментальных программных средств визуального моделирования, совместной разработки (поддерживаются основные языки программирования C++, Java, Visual Basic, SmallTalk и др., а также популярные среды разработки — MS Visual Studio, Delphi, PowerBuilder), автоматизированного тестирования и документирования, охватывающих жизненный цикл создания программных систем [6].
Помимо Rational Rose, продукта фирмы Rational Software, к числу популярных средств визуального моделирования, поддерживающих стандарты UML, можно отнести Paradigm Plus (программный продукт фирмы PLATINUM Technology), SELECT (SELECT Software), Oracle Designer (Oracle), Together Control Center (Borland), AllFusion Component Modeler (Computer Associates) и Microsoft Visual Modeler (Rational Software&Microsoft Corporation).
Rational Rose. Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Согр. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language). Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес-процессов до кодогенерации на определенном языке программирования. Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое [7].
Rational Rose поддерживает прямое и обратное проектирование на языках: ADA, Java, С, C++, Basic. Поддерживает технологии COM, DDL, XML. Позволяет генерировать схемы Oracle и SQL.
Rational Rose имеет открытый API, позволяющий создавать собственными силами модули для конкретных языков программирования.
Select Yourdon. Эта система разработана фирмой Select Software Tools Ltd. (England). Select Yourdon поддерживает фазы анализа требований и проектирования программной системы, что покрывает полностью начальный период разработки вплоть до кодирования модулей. При этом поддерживаются следующие виды структурных методов (диаграмм) [8]:
- • диаграммы отношения сущностей;
- • диаграммы потоков данных и управления, базирующиеся на нотации Yourdon/Ward & Mellor и Hatley;
- • диаграммы переходов состояний;
- • мини-спецификации процессов;
- • структурные диаграммы Константайна (Constantine);
- • структурные диаграммы Джексона (Jackson).
Первые три вида диаграмм и мини-спецификации процессов могут использоваться для анализа и формулировки требований к ПО, последние два — для проектирования архитектуры ПО и его отдельных модулей. База данных проекта сосредоточена в так называемом словаре данных (Data Dictionary). Система поддерживает как однопользовательскую работу, так и работу в сети коллектива разработчиков.
Oracle Designer. Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения — от моделирования бизнес- процессов до внедрения. Применение единого репозитория делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений [9].
Задачей Oracle Designer является сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы.
Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода, а также индивидуального подхода, выбранного компанией.
Microsoft Visual Modeler. Microsoft Visual Modeler (MSVM) — инструмент визуального моделирования, разработанный Rational Software совместно c Microsoft Corporation, обеспечивает базируемое на UML моделирование для проектирования приложений на основе компонентов. Модели, созданные с использованием MSVM, могут автоматически выполнять генерацию объектного кода для проектов, реализуемых в средах разработки Visual Basic 6.0 и Visual C++ [10].
Microsoft Visual Modeler поддерживает архитектуру Windows-распределенных интернет-приложений (Windows DNA), которая позволяет разработчикам уровня предприятия строить масштабируемые, многоуровневые бизнес-приложения, которые могут быть установлены в любой сети.
Последняя версия Microsoft Visual Modeler предлагает беспрецедентный уровень интеграции между визуальным моделированием и средой разработки Visual Studio, включает обновленные возможности как для разработчиков Visual Basic, так и для поддержки разработки в среде Visual C++.
Windows DNA, Visual Studio и Microsoft Visual Modeler (MSVM) обеспечивают правильную комбинацию инфраструктуры и инструментов проектирования для создания нового поколения п-уровне- вых, создаваемых на основе компонентов приложений.
MSVM упрощает построение сложных, многоуровневых бизнес- приложений, основанных на Windows DNA, позволяя разработчикам наглядно в графическом виде представлять организацию их приложений.
Новые возможности Microsoft Visual Modeler включают интеграцию с Microsoft Visual SourceSafe системой контроля версий; интеграцию с Microsoft Visual Manager (VCM) и улучшенную поддержку Microsoft Repository для разработок на основе Visual Basic. Расширения Visual Modeler для поддержки групповой разработки включают возможность опубликования моделей в репозитории через VCM; в дальнейшем возможен просмотр моделей и их совместное использование членами группы разработчиков. Компоненты могут быть импортированы из репозитория через VCM посредством техники drag-and-drop. Точно так же интерфейсные компоненты СОМ могут быть импортированы из Windows Explorer.
Microsoft Visual Modeler — наиболее простой в освоении инструмент из семейства Rational Rose, мирового лидера среди инструментов визуального моделирования, использует общую кодовую основу и предлагает масштабируемый, интегрированный, полностью совместимый набор решений визуального моделирования для программистов, использующих Visual Basic и/или Visual C++. Visual Modeler поддерживает Унифицированный Язык Моделирования (UML), разработанный таким образом, что даже разработчики, не имеющие опыта в визуальном моделировании, легко его осваивают и успешно создают модели.
Семейство продуктов AllFusion. Component Modeler — базовый компонент комплекта AllFusion Modeling Suite компании Computer Associates. Комплект также включает в себя: Process Modeler (ранее — BPwin), который объединяет моделирование бизнес-процессов, потоков данных и рабочей деятельности в одном простом в использовании инструменте; ERwin Data Modeler (ранее — ERwin), применяемый для моделирования баз данных, и Data Model Validator (ранее — ERwin Examiner) для улучшения согласованности и качества моделей данных. Component Modeler и ERwin Data Modeler работают совместно, что дает возможность разработчикам и аналитикам баз данных приводить информацию в реляционных базах данных к виду, пригодному для использования объектно-ориентированными приложениями. Модели бизнес-процессов Process Modeler могут быть синхронизированы с моделями данных ERwin Data Modeler для обеспечения оптимальной поддержки бизнес-процессов организации [11].
Семейство AllFusion состоит из средств, предназначенных для управления процессами и проектами, моделирования и разработки, публикации знаний и визуализации. ПО семейства AllFusion улучшает способность автоматизировать процессы жизненного цикла критически важных приложений, что соответствует потребностям постоянно усложняющегося и изменчивого мира электронного бизнеса.
Какие программные средства поддерживающие uml вы знаете
Инструментарий, используемый для моделирования архитектуры, функциональности программных продуктов и необходимые для этого типы требований
Думайте сами, решайте сами
Вместо приветствия
Традиционное доброе время суток Вам, уважаемые коллеги!
В прошлый раз мы посвятили наше общение обсуждению темы стандартизации и влиянию стандартов на проектирование и разработку архитектуры программных продуктов. Стандарты, определяющие тренд качественного развития процессов, обеспечивающих процессы жизненного цикла программного продукта, специфицируют виды и типы необходимых требований. Современный виток развития области информационных технологий, возрастающая сложность и комплексность программных продуктов предопределяют важность использования разнообразного инструментария, который должен поддерживать качество создаваемых информационных продуктов на приемлемом, для рынка в целом, качестве.
Именно подобные инструменты мы и обсудим сегодня.
Инструментарий разработки и моделирования требований к процессам и архитектуре программных продуктов
Для перехода от набора требований, порой разрозненных, к стройной и логичной архитектуре программного продукта, нужно использовать специализированный инструментарий. В нашем случае это специальные технологические средства разработки и моделирования процессов, на основе выявленных требований, которые позволят создать единое видение разрабатываемой архитектуры, с учетом определенных правил представления информации, принятой для конкретного проекта по созданию программного продукта или процесса архитектурного проектирования.
Тему правил, методов, методологий, в соответствии с которыми разрабатывается архитектура программных продуктов, мы будем подробно рассматривать далее.
Как было отмечено ранее, архитектурное проектирование информационных систем это область деятельности, которая имеет достаточно общего с архитектурным проектированием в строительстве.
«Строительство» — старший собрат информационных технологий. Поэтому было бы оптимально, для процессов создания программных продуктов, многое, необходимое для развития данной профессиональной области, почерпнуть, поинтересовавшись тем, как в строительстве успешно решались схожие задачи. В гражданском и промышленном строительстве языком описания архитектуры являются архитектурно-строительные чертежи, объемные прототипы и модели, текстовые описания возводимых объектов. Младший собрат поступил правильно и перенял необходимый опыт у старшего. В качестве средств разработки и моделирования характеристик информационных продуктов, в архитектурном проектировании используются различные языки, которые принято называть нотациями, а инструментами, которые поддерживают работу с нотациями CASE средствами.
Из современных нотаций можно выделить следующие:
- Блок-схемы (схемы алгоритмов)
Данный тип схем (графических моделей) визуализирует разрабатываемые алгоритмы или процессы. В описании блок-схем принято отдельные стадии процессов изображать в виде блоков (отсюда и соответствующее название данной нотации). Блоки различаются в зависимости от семантики, содержащейся в представляемой ими форме. Отображаемые блоки соединены между собой линиями, имеющими направление и определенную алгоритмами последовательность.
В широком значении термина «блок-схемы» он является метанотацией. Различные спецификации «блок-схем» получили свое определенное назначение и форму представления необходимой информации, в зависимости от специфики каждой конкретной нотации, но при этом общие правила построения моделей наследуются от правил построения «блок-схем».
- DFD-диаграмма (диаграмма потоков данных)
DFD – это нотация структурного анализа.
В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:
- Источники данных;
- Адресаты данных;
- Логические функции;
- Потоки данных;
- Хранилища данных.
Диаграмма потоков данных — это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.
В основе данной нотации находится методология проектирования и метод построения модели потоков данных проектируемой информационной системы. В соответствии с соответствующей методологией проектирования модель системы идентифицируется как иерархия диаграмм потоков данных, которые представляют собой последовательный процесс преобразования данных, с момента их поступления в систему, до момента представления информации конечному (или псевдоконечному) пользователю.
Диаграммы потоков данных разработаны для определения основных процессов или модулей программного продукта. Далее, в целях комплексного представления разрабатываемой архитектуры, они детализируются диаграммами нижних уровней представления информации (DFD) и процессов (IDEF). Подобный принцип отображения данных продолжается, реализуя многоуровневую иерархию подчиненных и взаимосвязанных диаграмм. В результате будет достигнут нужный уровень декомпозиции, на котором процессы становятся абсолютно понятным и прозрачным.
В современных процессах разработки программного обеспечения подобный подход к проектированию программных продуктов практически не применяется, по причине смещения акцентов создания информационных систем от структурного к объектно-ориентированному подходу.
Данный методология анализа и проектирования на сегодняшний день эффективно используются в бизнес-анализе и соответствующих дисциплинах, по причине его наглядности и понятности для стэйкхолдеров.
- ER-диаграмма (диаграмма сущность-связь)
ER – это тип нотации, задача которой состоит в создании формальной конструкции, описывающей и визуализирующей верхнеуровневое представление бизнес объектов будущей системы, их атрибуты и связь между ними, в виде основных элементов, которые будут использоваться в качестве фундамента для проектирования таблиц будущей базы данных программного продукта. Таким образом, ER-диаграмма представляется как концептуальная модель создаваемой информационной системы, в терминах конкретной предметной области. Данный тип диаграмм помогает выделить ключевые сущности и определить связи между ними. На сегодняшний день существует достаточно мощный инструментарий, который может позволить выполнить преобразование созданной ER-диаграммы в конкретную схему базы данных на основе выбранной модели данных.
- EPC-диаграмма (диаграмма событийной цепочки процессов)
Событийная цепочка процессов – это тип нотации, задача которой заключается в создании моделей бизнес процессов. Она используется для моделирования, анализа и реорганизации бизнес-процессов. Ее отличие, от ранее рассмотренных, состоит в том, что EPC применяют для создания функциональных моделей, имитирующих конкретные процессы, реализуемые в определенном программном продукте.
История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems — Архитектура интегрированных информационных систем.
Диаграмма EPC оформляется в виде упорядоченной последовательности событий и функций. Каждая функция при этом должна определяться начальными и конечными событиями, могут быть указаны участники, исполнители, материальные и информационные потоки, сопровождающие отдельные функции. Дополнительную ценность диаграммам EPC придает тот факт, что она может использоваться для настройки программных продуктов типа ERP, в части создания или улучшения бизнес-процессов.
Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).
EPC, ER, BPMN — это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.
Нотация имеет достаточно понятный инструментарий, позволяющий моделировать как относительно простые, так и сложные бизнес-процессы. Это достигается за счет применения двух групп элементов:
- Первая группа (simple notation) состоит из основных элементов BPMN, которые удовлетворяют требованиям создания простой графической нотации. Подавляющее большинство бизнес-процессов моделируются с использованием элементов данной группы.
- Вторая группа (powerful notation) содержит полный «пакет» элементов BPMN. В него кроме основных блоков входят специфические комплексные модули, представляющие различные типы и виды элементов, необходимых для моделирования самых сложных процессов.
Подобная преемственность инструментария групп BPMN позволяет удовлетворять требованиям комплексной нотации и управлять более сложными ситуациями моделирования.
Оптимально смоделированные диаграммы BPMN могут применяться для настройки, рефакторинга и реинжиниринга бизнес процессов во многих современных информационных системах класса ECM.
UML (Unified Modeling Language) — не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.
UML — это язык широкого профиля, который создан для формирования серии нотаций, поддерживающих полный цикл разработки, как архитектуры, так и функциональности программных продуктов, реализуемых по принципам объектно-ориентируемого программирования.
Широкая распространенность и повсеместное применение данного языка привели к тому, что он стал открытым стандартом, использующим графические обозначения для создания моделей систем, которые принято называть UML-моделями. Специфика UML не предполагает ориентацию на описание архитектуры, так как основное его назначение заключается в определении, визуализации, проектировании, документировании, преимущественно, программных продуктов, бизнес процессов и структур данных.
Язык UML получил популярность за счет жесткой связки с популярной и распространенной методологии разработки и внедрения программных продуктов RUP, в соответствии с которой организована работа многих консалтинговых и производственных компаний отрасли информационных технологий. Не смотря на множество преимуществ, UML не является панацей и абсолютным универсумом в процессах проектирования архитектур и программных продуктов.
Применять и разбираться в диаграммах UML могут только узкоспециализированные специалисты области проектирования программных систем. Вовлечь в обсуждение и согласование разрабатываемой архитектуры информационного продукта, задокументированного на UML, стэйкхолдеров, представителей не направления информационных технологий, будет достаточно сложно.
UML, в отличие от ER и BPMN диаграмм, поддерживает генерацию не просто отдельной функциональности, привязанной к специфичным типам информационных систем, а целостного программного кода на основании сформированных UML-моделей.
Самая специфичная и наименее распространенная нотация из всех рассматриваемых в сегодня.
EIP (Enterprise Integration Patterns) диаграммы — это набор из 65 шаблонов диаграмм, которые предназначены для описания специализированных процессов взаимодействия между программными продуктами. Специфика данной нотации состоит в том, что она разработана для описания конкретных процессов, обеспечивающих интеграционное взаимодействие между приложениями и функциональность программных продуктов, ориентированных на обмен сообщениями между информационными системами.
Шаблоны интеграции приложений и необходимая функциональность, описание которых поддерживают EIP диаграммы, встроены в множество современных специализированных открытых программных продуктов и доступны для применения в специализированных интеграционных процессах.
На сегодняшний день, в силу своей специфичности, данный вид нотации не имеет широкого распространения, но, учитывая темпы роста популярности интеграционных процессов, можно спрогнозировать, что в ближайшее время интерес к EIP-диаграммам вырастет.
- Модели компонентов, программных продуктов и функциональных процессов
Модели, как таковые, не являются нотациями, а представляют собой набор необходимых для реализаций процессов/подпроцессов, представленных в виде нескольких взаимодополняющих друг друга нотаций, с целью моделирования конечного результата. Говоря о модели, со структурной точки зрения, корректно будет сказать, что это «метанотация», включающая в себе несколько основных нотаций, реализация диаграмм которых запланированы для качественной разработки конкретной архитектуры.
Таким образом, модель – это абстракция, которая фокусирует субъекта, работающего с ней на основных, критичных для реализации, характеристиках конечного продукта. Из примеров CASE средств, способных реализовать и представить нотации в виде модели можно выделить ARIS, UML.
Так же возможна схема, когда исполнитель разработает необходимые диаграммы в разных CASE средствах, после чего компилирует модель самостоятельно. В таких случаях дальнейшее сопровождение и развитие модели затруднительно (сложность сопровождения, развития, управления моделью) и целиком и полностью лежит на «плечах» ответственных за это специалистов;
Когда мы говорили о моделях, то отметили, что модель это следующий, качественный шаг вперед к реализации программного обеспечения, по сравнению с диаграммами, реализуемыми нотациями.
После того, как реализованы несколько моделей требований, можно приступать к реализации прототипов, если это предусмотрено и спланировано в проекте разработки программного продукта.
Прототип представляет собой «черновой» вариант конечной реализации программного продукта или его компонента, разработанного с учетом определенных ограничений для демонстрации заинтересованным сторонам на определенной стадии разработки только архитектуры или программного продукта в целом.
Цель разработки прототипа – подтвердить ожидания стэйкхолдеров от реализации конечного продукта и согласовать её функциональность. Прототипы принято реализовывать в специализированном программном коде, поэтому их следует воспринимать как часть процесса разработки, но при этом не рассчитывать на то, что прототип будет являться частью будущей архитектуры или информационной системы.
Прототипы, как правило, разрабатываются достаточно быстро с помощью специализированного инструментария, освоение которого требует гораздо меньше времени и сил, чем освоение определенного языка программирования.
Жизненный цикл прототипа заканчивается в тот момент, когда ожидания стэйкхолдеров подтверждены и разработанный облик (не более) будущего продукта запланирован к реализации;
Работа по созданию интерфейсов — это отдельная область разработки программных продуктов, которая не определяет архитектуры, но в большинстве случаев зависит от неё. Именно поэтому мы решили упомянуть её в конце списка, факультативно.
Эта область требует к себе довольно много внимания и сил. Она определяет многие функциональные характеристики программных продуктов (эргономика, дизайн интерфейсов, воспринимаемость и удобство работы с информацией и т.д.).
Значимость корректных и эффективных интерфейсов все больше и больше растет для разнообразных программных продуктов. Интерфейс представляет собой «верхушку», с помощью которой пользователь будет взаимодействовать с «нутром» программного продукта.
Важно, чтобы уже на ранних стадиях разработки интерфейсов пользователь имел представление о том, с чем и каким образом ему придется работать и постепенно привыкал, при возможности корректируя его или свои ожидания от него.
На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.
Каждый крупный программный продукт или его модуль, который состоит из совокупности компонентов и связей между ними, должен быть детально описан в соответствующий момент процесса архитектурного проектирования. Описание должно быть выполнено по стандартизированным правилам организации или проекта, с использованием необходимых нотаций, для данного конкретного случая.
По принципам программной инженерий и здравой логики, которая находится в основе процессов разработки информационных систем, любая подсистема или компонент в дальнейшем может выступать в качестве составного элемента более масштабной системы. Поэтому, в архитектурном проектировании должно обязательно содержаться подробное описание укрупнённых частей системы, выполненных с помощью CASE средств и нотаций, согласованных друг с другом и обеспечивающих последующую преемственность.
Важно, чтобы выбранная нотация или серия нотаций поддерживали существующий процесс архитектурного проектирования, способствовали его развитию и совершенствованию и были «в силах» поддержать соответствующую фиксацию функциональных, нефункциональных и прочих требований к разрабатываемой архитектуре и программному продукту в целом.
Необходимо осознавать, что нет единой нотации или языка проектирования, который мог бы быть решением всех поставленных задач процесса проектирования. Сегодня существует достаточное количество универсальных инструментов и средств, но ни один из них не может обеспечить весь спектр возникающих задач проектирования.
Для того, чтобы создать достаточно комплексную и взаимосвязанную среду проектирования архитектур, моделей и функциональности программных продуктов нужно использовать инструменты и диаграммы, которые смогут поддержать процессы разработки, в зависимости от специфики конкретной задачи, но при этом должен существовать минимальный набор необходимых диаграмм, который должен присутствовать в каждом проекте по разработке программного продукта не смотря на его масштабы и значимость.
О функциональных и нефункциональных требованиях к архитектуре и функциональности программного обеспечения
Обсуждение различных типов и видов требований мы начали в предыдущей ранее.
В этой статье мы уделим больше внимания рассмотрению функциональных и нефункциональных требований к архитектуре программного обеспечения.
Принято думать, что архитектура формируется под воздействием, прежде всего, нефункциональных требований, которые, в большинстве случаев, отсутствуют в проектируемых функциональных и бизнес моделях систем, но начинают свой жизненный цикл в процессе реализации программных продуктов. Попробуем обосновать, что это не совсем верно.
Многие современные ученые области инженерии требований высказывают мнение о том, что не бывает нефункциональных требований.
Нефункциональные требования — это абсолютно функциональные требования, которые описывают функции системы с точки зрения «каких-то» стэйкхолдеров, о которых забыли в процессе сбора и анализа требований. Вы знаете какое-нибудь программное обеспечение, в процессе разработки которого активно участвовали будущие специалисты групп сопровождения, тестирования, развития его архитектуры и функциональности? Как часто проектируя программные продукты о многих его характеристиках, не значимых на первый взгляд для бизнес стейкхолдеров, но критичных для других пользователей, просто забывают или намеренно игнорируют, считая их не значимыми и второстепенными.
Ранее мы показали, что члены группы поддержки, тестирования, системные администраторы и некоторые другие технические специалисты являются такими же стэйкхолдерами, как и будущие основные бизнес пользователи системы. Игнорирование их требований может привести к тому, что фаза внедрения пройдет достаточно успешно, но вот последующее сопровождение и развитие системы может быть достаточно проблематичным.
Вся проблема заключается в том, что для современного бизнес мира «последующее» значит то, о чем можно забыть сегодня и не вспоминать до тех пор, пока забытое не напомнит о себе. В случае с нефункциональными требованиями такой подход к работе может оказаться слишком дорогостоящим. Как только информационный продукт перейдет в стадию промышленной эксплуатации и над ним начнут работать группы специалистов, которые должны будут поддерживать достаточно высокий уровень сервисной поддержки и развития системы, может оказаться, что его реализация не включает в себя множество разнообразных технических аспектов. Ведь именно от таких аспектов зависит качество продукта, обеспечивающее оптимальность бизнес процессов, моделей и данных. Довольно распространенная ситуация, когда на ранних фазах создания программных продуктов о таких характеристиках как надежность, быстродействие, безопасность многие специалисты и стэйкхолдеры, вовлеченные в процесс проектирования архитектуры и функциональности просто не задумываются, отдавая их на дальнейшую проработку и реализацию разработчикам. Все бы хорошо, но для разработчиков существует множество факторов, в соответствии с которыми, модели программных компонентов, которые не имеет четких требований будут реализованы не так как задумывалось при составлении специализированных документов, а так, как разработчик «сможет». Это «сможет» будет определяться квалификацией, инструментарием и, конечно же тем, количеством времени, которое у него/них будет в наличии, а его, как известно, практически всегда не хватает. Таким образом, получается следующий парадокс – качество продукта будет напрямую зависеть не от стэйкхолдеров, а от специалистов, для которых важность продукта, который они разрабатывают, не очевидна. Стэйкхолдерам важно получить законченную функциональности в сроки согласованных работ, а иногда даже намного, намного ранее и получить дополнительное время на реализацию качественных атрибутов, значимость которых определяется только в процессе разработки не всегда возможно. Именно поэтому многие характеристики разрабатываемого программного продукта и его архитектуры, скрытые от внимательного взора руководства, необходимо обозначать в активностях, предваряющих стадии проектирования и разработки. Многое на этой стадии зависит от опыта и мастерства системного архитектора и его команды, от профессионализма которых будет зависеть стратегический успех информационной системы, разрабатываемой для бизнес необходимостей конкретной организации.
Этим вступлением мы постарались показать то, что требования не бывают второстепенными или незначимыми. Незначимое сегодня окажется жизненнонеобходимым завтра. Рамки работ над требованиями должны быть спланированы и ясно понятны всем стэйкхолдерам, участвующим в проекте.
После того, как мы определились с тем, что для создания качественной архитектуры не должно быть разного отношения к функциональным и не функциональным требованиям. Все требования необходимо рассматривать с точки зрения их критичности по отношению к архитектуре программного продукта.
Высокоуровневое назначение программного продукта — приносить выгоду его владельцу за счет автоматизации труда (интеллектуального, физического, монотонного и т.д. ) человека, а в идеале за счет полной замены человеческого ресурса и фактора, если это возможно.
Здесь будет уместно сравнение с строением человека, в котором есть множество органов, каждый из которых отвечает за определенную функцию и каждый развивается не только как самостоятельная единица, но и как часть целого. В тот момент, когда определенный орган дает сбой и не может поддерживать свою целевую функциональность, при условии что это не отражается на деятельности всего организма, то можно считать, что это не критично, но если весь организм выходит из строя на определенный период, то важно понять в чем состоит источник проблемы и устранить его, а если выразиться более системно, то не допустить подобной возможности. Таким образом те элементы органов, которые влияют на их полную функциональность и взаимосвязаны с другими, являются наиболее приоритетными для исследования и оптимального содержания и развития. Подобными компонентами в программном продукте являются компоненты, наиболее критичные для рассмотрения с точки зрения архитектуры и сбора требования.
Но при разработке определенной информационной системы классификация требований необходима для целей дальнейшей их трассировки и управления ими. Традиционно выделяют 2 основные группы описание которых и более подробную литературу по работе с которыми наши коллеги найдут в соответствующей литературе.
Сначала мы рассмотрим функциональные требования.
Функциональные требования описывают «поведение» системы и информацию, с которой система будет работать. Они описывают возможности системы в терминах поведения или выполняемых операций
Цель использования данной группы требований (как следует из названия) заключается в регламентации возможностей и соответствующем им поведении разрабатываемого программного продукта.
Функциональные требования должны отвечать на вопрос — Каким образом должны быть алгоритмизированы процессы информационного продукта, чтобы взаимодействия между пользователем и системой удовлетворяло потребности стэйкхолдеров?
Именно с помощью функциональных требований, в большинстве случаев, определяются рамки работ по процессам, сопровождающих цикл создания программных продуктов. Данный тип требований устанавливает:
- Цели разрабатываемого функционала;
- Задачи, которые должны быть выполнены для достижения поставленной цели;
- Сервисы, поддерживающие выполнение задач;
- … (и многое другое, касающееся непосредственно функциональных возможностей и особенностей программного продукта).
На сегодняшний день существует множество подходов к разработке и фиксации функциональных требований. Кратко рассмотрим наиболее популярные из них:
- Классический подход
Суть классического подхода состоит в разработке требований с помощью итеративной работы с верхнеуровневыми требованиями стэйкхолдеров, и постепенной детализации до уровня понятного разработчикам. Это наиболее изученный и популярный подход, который подробно описан в современной литературе. Мы можем порекомендовать для изучения книги К. Вигерса, которые уже упоминались нами ранее.
Дополнительно отметим, что в подобном подходе основная тяжесть создания полноценного документа, охватывающего весь программный продукт, ложится на сотрудника, ответственного за сбор, анализ и синтез информации. При современной динамике изменений бизнес процессов, данных, поступающих от внешних и внутренних аспектов бизнеса и непосредственно влияющих на требования стэйкхолдеров, классический подход становится наименее эффективным. Именно поэтому в последнее время водопадные модели разработки программного обеспечения заменяются «гибкими» подходами (agile), цель которых в быстром и эффективном решении возникающих задач, даже если следующая будет противоречить предыдущей.
- Use cases (Варианты использования)
В этом подходе функциональные требования записываются с помощью системы специализированных правил, которые, к примеру, должны фиксироваться следующим образом: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности».
Если определить максимальное количество возможных вариантов использования разрабатываемого программного продукта предполагаемыми целевыми пользователями, то мы получим достаточно полные функциональные требования.
Но, при попытке тотального применения к работе над функциональными требованиями этого подхода существует вероятность того, что отдельные, незначимые для определенных стэйкхолдеров, потребности будут не учтены. В этом случае существует вероятность упустить суть конкретных функциональных требований, которые, как правило, скрыты от постороннего взгляда. Чтобы этого не произошло, важно использовать в обработке зафиксированных use cases классический подход, в рамках которого должен быть проведен анализ, систематизация и синтез информации. Это поможет выявить истинное назначение предполагаемого к реализации функционала и не упустить отдельных деталей.
Нефункциональные требования, в дополнение к функциональным, направленны на обеспечение технической целостности разрабатываемого функционала и поддержку характеристик реализуемого программного обеспечения, которые необходимы для создания оптимальной архитектуры.
Они регламентируют внутренние и внешние условия функционирования программного продукта. Выделяют следующие основные группы нефункциональных требований:
- Атрибуты качества;
- Безопасность;
- Надежность;
- Производительность;
- Скорость и время отклика приложения;
- Пропускная способность workflow;
- Количество необходимой оперативной памяти;
- Платформа реализации архитектуры и программного продукта;
- Тип используемого сервера приложений;
Нефункциональные требования описывают условия, которые не относятся к поведению и функциональности системы но обеспечивают их на уровне компонентов архитектуры программного продукта.
Ранее описанная методология use cases может быть применена для сбора и анализа нефункциональных требований. При взаимодействии с стэйкхолдерами необходимо фиксацию каждого правила подытоживать фиксацией нефункциональных требований, выраженную в виде количественной характеристики определенного параметра: «программный продукт должен обеспечить учетчику возможность формирования акта выдачи бланков строгой отчетности за время не более 0,5 с, после того, как поступила соответствующая команда»
В этой части нашего серии статей мы постарались достаточно подробно рассказать о требованиях, которые оказывают свое влияние на архитектуру и функциональность программных продуктов, в том числе достаточно подробно рассмотрели функциональные и нефункциональные требования. Но предложенный объем является необходимым и достаточным только для того, чтобы у наших коллег сложилось понимание того, какую роль играют требования в процессах проектирования архитектуры и реализации программных продуктов. Более основательное изучение темы инженерии требований изложены в специализированых курсах и литературе, к которым мы и рекомендуем Вам обратиться.
Выводы
Сегодня мы постарались разложить по полочкам существующие виды нотаций и наиболее популярные языки моделирования бизнес процессов, на основе которых происходит разработка требований к программным продуктам, к разговору о которых мы вернемся в следующий раз.
Надеемся статья получилась комплексной и цельной.
3.6. Контрольные вопросы
В предыдущей лекции было рассказано о том, что же такое UML, о его истории, назначении, способах использования языка, структуре его определения, терминологии и нотации. Было отмечено, что модель UML — это набор диаграмм. В этой лекции мы рассмотрим такие вопросы: почему нужно несколько видов диаграмм; виды диаграмм; ООП и последовательность построения диаграмм Прежде чем перейти к обсуждению основного материала этой лекции, давайте поговорим о том, зачем вообще строить какие-то диаграммы. Разработка модели любой системы (не только программной) всегда предшествует ее созданию или обновлению. Это необходимо хотя бы для того, чтобы яснее представить себе решаемую задачу. Продуманные модели очень важны и для взаимодействия внутри команды разработчиков, и для взаимопонимания с заказчиком. В конце концов, это позволяет убедиться в «архитектурной согласованности» проекта до того, как он будет реализован в коде. Мы строим модели сложных систем, потому что не можем описать их полностью, «окинуть одним взглядом». Поэтому мы выделяем лишь существенные для конкретной задачи свойства системы и строим ее модель, отображающую эти свойства. Метод объектно-ориентированного анализа позволяет описывать реальные сложные системы наиболее адекватным образом. Но с увеличением сложности систем возникает потребность в хорошей технологии моделирования. Как мы уже говорили в предыдущей лекции, в качестве такой «стандартной» технологии используется унифицированный язык моделирования (Unified Modeling Language, UML), который является графическим языком для спецификации, визуализации, проектирования и документирования систем. С помощью UML можно разработать подробную модель создаваемой системы, отображающую не только ее концепцию, но и конкретные особенности реализации. В рамках UML-модели все представления о системе фиксируются в виде специальных графических конструкций, получивших название диаграмм. Примечание. Мы рассмотрим не все, а лишь некоторые из видов диаграмм. Например, диаграмма компонентов не рассматривается в этой лекции, которая является лишь кратким обзором видов диаграмм. Количество типов диаграмм для конкретной модели приложения никак не ограничивается. Для простых приложений нет необходимости строить диаграммы всех без исключения типов. Некоторые из них могут просто отсутствовать, и этот факт не будет считаться ошибкой. Важно понимать, что наличие диаграмм определенного вида зависит от специфики конкретного проекта. Информацию о других (не рассмотренных здесь) видах диаграмм можно найти в стандарте UML.
4.1. Почему нужно несколько видов диаграмм
Для начала определимся с терминологией. В предисловии к этой лекции мы неоднократно использовали понятия системы, модели и диаграммы. Каждый из нас интуитивно понимает смысл этих понятий, но, чтобы внести полную ясность, снова заглянем в глоссарий и прочтем следующее: Система — совокупность взаимосвязанных управляемых подсистем, объединенных общей целью функционирования. Да, не слишком информативно. А что же такое тогда подсистема? Чтобы прояснить ситуацию, обратимся к классикам: Системой называют набор подсистем, организованных для достижения определенной цели и описываемых с помощью совокупности моделей, возможно, с различных точек зрения. Что ж, ничего не попишешь, придется искать определение подсистемы. Там же сказано, что подсистема — это совокупность элементов, часть из которых задает спецификацию поведения других элементов. Ян Соммервилл объясняет это понятие таким образом: Подсистема — это система, функционирование которой не зависит от сервисов других подсистем. Программная система структурируется в виде совокупности относительно независимых подсистем. Также определяются взаимодействия между подсистемами. Тоже не слишком понятно, но уже лучше. Говоря «человеческим» языком, система представляется в виде набора более простых сущностей, которые относительно самодостаточны. Это можно сравнить с тем, как в процессе разработки программы мы строим графический интерфейс из стандартных «кубиков» — визуальных компонентов, или как сам текст программы тоже разбивается на модули, которые содержат подпрограммы, объединенные по функциональному признаку, и их можно использовать повторно, в следующих программах. С понятием системы разобрались. В процессе проектирования система рассматривается с разных точек зрения с помощью моделей, различные представления которых предстают в форме диаграмм. Опять-таки у читателя могут возникнуть вопросы о смысле понятий модели и диаграммы. Думаем, красивое, но не слишком понятное определение модели как семантически замкнутой абстракции системы вряд ли прояснит ситуацию, поэтому попробуем объяснить «своими словами». Модель — это некий (материальный или нет) объект, отображающий лишь наиболее значимые для данной задачи характеристики системы. Модели бывают разные — материальные и нематериальные, искусственные и естественные, декоративные и математические. Приведем несколько примеров. Знакомые всем нам пластмассовые игрушечные автомобильчики, которыми мы с таким азартом играли в детстве, это не что иное, как материальная искусственная декоративная модель реального автомобиля. Конечно, в таком «авто» нет двигателя, мы не заполняем его бак бензином, в нем не работает (более того, вообще отсутствует) коробка передач, но как модель эта игрушка свои функции вполне выполняет: она дает ребенку представление об автомобиле, поскольку отображает его характерные черты — наличие четырех колес, кузова, дверей, окон, способность ехать и т. д. В ходе медицинских исследований опыты на животных часто предшествуют клиническим испытаниям медицинских препаратов на людях. В таком случае животное выступает в роли материальной естественной модели человека. Уравнение, изображенное выше — тоже модель, но это модель математическая, и описывает она движение материальной точки под действием силы тяжести. Осталось лишь сказать, что такое диаграмма. Диаграмма — это графическое представление множества элементов. Обычно изображается в виде графа с вершинами (сущностями) и ребрами (отношениями). Примеров диаграмм можно привести множество. Это и знакомая нам всем со школьных лет блок-схема, и схемы монтажа различного оборудования, которые мы можем видеть в руководствах пользователя, и дерево файлов и каталогов на диске, которое мы можем увидеть, выполнив в консоли Windows команду tree, и многое-многое другое. В повседневной жизни диаграммы окружают нас со всех сторон, ведь рисунок воспринимается нами легче, чем текст. Но вернемся к проектированию ПО (и не только). В этой отрасли с помощью диаграмм можно визуализировать систему с различных точек зрения. Одна из диаграмм, например, может описывать взаимодействие пользователя с системой, другая — изменение состояний системы в процессе ее работы, третья — взаимодействие между собой элементов системы и т. д. Сложную систему можно и нужно представить в виде набора небольших и почти независимых моделей-диаграмм, причем ни одна из них не является достаточной для описания системы и получения полного представления о ней, поскольку каждая из них фокусируется на каком-то определенном аспекте функционирования системы и выражает разный уровень абстракции. Другими словами, каждая модель соответствует некоторой определенной, частной точке зрения на проектируемую систему. Несмотря на то что в предыдущем абзаце мы весьма вольготно обошлись с понятием модели, следует понимать, что в контексте приведенных выше определений ни одна отдельная диаграмма не является моделью. Диаграммы — лишь средство визуализации модели, и эти два понятия следует различать. Лишь набор диаграмм составляет модель системы и наиболее полно ее описывает, но не одна диаграмма, вырванная из контекста.