Множинність точок зору
При розробці архітектури ПЗ важливим виявляється поєднання безлічі точок зору. ПЗ виявляється настільки складним, що його архітектуру не побудувати як єдину модель – безліч окремих аспектів мають бути представлені в архітектурі, їх зв'язки складні і погано виражаються в явному вигляді. Корисніше виявляється створення безлічі моделей, створених з різних точок зору.
Причина множинності точок зору при розробці ПЗ. Вміння розглядати предмет з різних точок зору є найважливішою філософією успішної практики при роботі з великими об'ємами різнорідної і складної інформації. Поглянемо на розробку ПЗ і те, чому там є потреба в різних поглядах на процес, систему і так далі.
Далее, в разработку/использование ПО вовлечено большое количество очень разных специалистов: программисты, инженеры, тестеры, технические писатели, менеджеры, заказчик, пользователи, продавцы-маркетологи и т. д. (см. рис. 4.1). Для всех этих специалистов нужна разная информация о программной системе. Представьте, что произойдет, если, например, продавцу или заказчику-непрограммисту в ответ на просьбу получше ознакомиться с ПО вы дадите почитать программные коды…
Рис. 4.1. Разные специалисты – разные взгляды на систему
Множественность точек зрения происходит также от того, что нет единых стандартов и норм разработки ПО. То есть разработка ПО во многом "state of art". Часто приходится изобретать новую точку зрения моделирования прямо по ситуации – чтобы именно этот эксперт тебя понял, чтобы именно эти особенности системы были отражены. Часто здесь – как в лотерее: создается несколько описаний системы с разных точек зрения, какое-то оказывается удачным и его все используют в дальнейшем.
Точка зору (viewpoint) — це певний погляд на систему, який здійснюється для виконання якогось певного завдання ким-небудь з учасників проекту. Точку зору потрібно ясно усвідомлювати при створенні візуальних моделей, наприклад, варіанти використання. Важливо розуміти, що вона може бути у кожному конкретному випадку своя. Найважливішими характеристиками точки зору моделювання є мета (навіщо створюється модель) і цільова аудиторія (тобто, для кого вона призначається).
Важно понимать, что цель модели — это не какая-то гипотетическая задача типа "описания архитектуры, потому что так нужно, так правильно", а целевая аудитория — это не абстракция типа "люди, желающие познакомиться с ПО". И то и другое — что-то очень конкретное, реально существующее в проекте или рядом с ним. Ведь разработчики ПО не могут позволить себе за деньги заказчика создавать нечто на все века и для всех народов. И цель моделирования, и аудитория, которая будет работать с диаграммами, всегда существуют, важно лишь ясно понимать, какие они…
Мова uml
Часто поняття архітектури сильно звужують, розуміючи під ним лише опис основних, важливих аспектів ПЗ, створюваних, наприклад, архітектором при розробці дизайну системи. Для цих цілей використовується мова моделювання UML (Unified Modeling Language).
Этот язык является итогом развития средств схематического описания программных систем, которые развивались с блок-схем, предложенных еще фон Нейманом в конце 40-х годов. Он предполагал, что эти схемы станут высокоуровневым языком ввода алгоритмов в вычислительные машины, но эволюция языков программирования пошла по пути текстовых языков. Тем не менее блок-схемы получили распространение при спецификации и документировании ПО, были стандартизованы, однако широкого практического применения не получили. В конце 60-х годов, в связи с поиском новых средств разработки ПО, рождением программной инженерии и общими следованиями в области проектирования и разработки искусственных систем появился термин структурный анализ (structured analysis) систем. Термин был введен ученым из MIT, Дугласом Россом, который также предложил диаграммный метод анализа и проектирования больших искусственных систем. Метод назывался SADT (Structured Analisys and Design Technique), стал основой серии военных стандартов США серии IDEF и широко распространился в индустрии. Однако диаграммный язык в SADT был очень скромным – набор блоков и связей между ними, с поддержкой декомпозиции блоков. В 70-х годах, в связи с массовым выходом ПО на свободный рынок (то есть программные системы стали создаваться не только в военной области, для крупного бизнеса, но также для среднего и малого бизнеса) структурный анализ стал бурно эволюционизировать – набор диаграмм обогатился диаграммами состояний и переходов, сущность-связь, потоков данных и т.д. С развитием объектно-ориентированных средств разработки (конец 80-х – середина 90-х) структурный анализ превратился в объектно-ориентированный анализ и проектирование. Появилось большое количество методологий, и постепенно сложился единый язык моделирования, который и был закреплен в стандарте UML. Произошло это в 1997 году.
С тех пор вышло несколько версий стандарта UML. Текущая версия UML 2.1.