правильно изготовлен «чёрный ящик», приёмки – это насколько использование целевой системы позволяет пользователю добиться целевого поведения от using system. Test driven development – это когда разработка системы начинается с того, что требования разрабатываются сразу в виде тестов (исполняемых!). Увы, качество разработки по TDD получается примерно такое же, как и при любых других видах разработки – что не снижает популярности этого подхода.

Требования как правило разрабатываются с помощью сценариев (use cases), в которых рассказывается, что делает система в ответ на последовательности действий (сценарии) с участием разных стейкхолдеров. Более простая форма – user story, в которых рассказывается, что делают стейкхолдеры с системой (а не что делает система!).

Самая простая форма моделеориентированности – это использовать user story в

формулировках по шаблону (Mike Cohn, 2008, Advantages of the “As a user, I want” user story template, blog post, http://www.mountaingoatsoftware.com/blog/advantages-of-the-as-a-user-i-want-user- story-template): Я как __стейкхолдер__ хочу, чтобы система ___формулировка требования___, для того чтобы ___хотелка-для-using-system___.

Архитектура

Системная архитектура — эта альфа, пожалуй, важнейшая среди подальф определения системы. Она была сформулирована по мотивам строительной архитектуры относительно недавно (лет эдак двадцать назад) и имеет множество определений:

●Из ISO 42010: Архитектура (системы) – основные понятия или свойства системы в её среде, заключающиеся в её элементах, их отношениях и принципах её проектирования и развития (Architecture (of a system) – fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution).

●Из книги Garlan et al.: Архитектура системы это набор структур, необходимых для рассуждений о системе, каковые структуры состоят из элементов, отношений и свойств этих элементов и отношений (The architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both).

●Набор из более чем 150 других определений архитектуры, которые предлагались профессионалами системной и программной инженерии: http://www.sei.cmu.edu/architecture/start/glossary/community.cfm

После одной из затяжных интернет-дискуссий по архитектуре в программной инженерии Ralf Johnson выдал альтернативное определение: “Архитектура — это обо всём важном. Что бы это ни было”. А что можно считать важным в инженерной системе? Если представить архитектуру как набор инженерных решений, принимаемых для определения структуры системы, то “важные решения” — это при изменении которых приходится в существенной мере изменять множество других решений, в существенной мере перепроектировать систему. Если вместо двигателя внутреннего сгорания на автомобиль поставить электромоторы, то автомобиль придётся перепроектировать практически заново (хотя что-то из неархитектурных решений может и остаться: оплётка руля, стекло на дверцах, фары). Следовательно, выбор между двигателем внутреннего сгорания и электродвигателем в ходе создания автомобиля — это архитектурное решение.

Книга Paul Clements, et al. “Documenting Software Architectures” упоминается в литературе к стандарту архитектурных описаний ISO 42010. Она предлагает метафору для понимания того, что такое архитектурное описание и почему его так трудно сделать: как документировать крыло птицы для того, кто не знает, что это такое? Там ведь огромное количество разноуровневых структур, повторения с вариациями, критические для полёта качества элементов и свойства крыла, невыводимые из свойств отдельных его частей. Как записать все эти структуры, в которых каждое перо неповторяемо в его даже самых маленьких деталях, есть множество особенностей костей и мышц, но все они в совокупности дают функцию полёта?

Архитектура — это основные описания “прозрачного ящика”, которые показывают, из каких основных частей (компонент, модулей, размещений и т.д.) состоит система, и как эти описания “прозрачного ящика” обеспечивают функцию “чёрного ящика”.

Итого: важно, какие типы структур системы документируются (например — структуры компонент/принципиальные схемы, модули и их интерфейсы, размещения и т.д.), какие принципы проектирования/конструирования и развития документируются.

Кем и для чего используются архитектурные описания, подготавливаемые практикой инженерии системной архитектуры? Прежде всего — командой проекта для обсуждений системы. Архитектурные описания для инженеров как шахматная доска для игроков в шахматы — это гроссмейстеры могут играть “в уме”, а простые люди предпочитают вести сложные рассуждения не в кортексе (коре головного мозга), а с использованием экзокортекса, тем более при командной работе. Команда поможет также убрать ошибки: эти ошибки трудно заметить, если обсуждаемые важные инженерные решения не задокументированы, если отсутствуют архитектурные описания, а решения только проговариваются вслух (а иногда ведь решения даже не проговариваются — их принимает кто-то один, а другие о принятии этих решений и их важности и не догадываются!).

Особенно полезна архитектура для рассуждений по «требованиям качества» («- ости»: надёжность, ремонтопригодность, безопасность и т.д.). Именно в ходе

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

Архитектурные инженерные решения ясно выражают ограничения для для проектантов/конструкторов (команды проекта), поэтому они стабилизируют разработку.

Архитектурные описания также помогают разъяснять принимаемые по поводу целевой системы инженерные решения для внешних по отношению к команде стейкхолдеров («шахматная доска для зрителей и судей»).

Архитектурную работу можно делать плохо, а можно хорошо (но делается она в любом случае). Чтобы её делать хорошо, нужно её обсуждать специально, знать лучшие архитектурные практики!

Инженерия системной архитектуры

Практика создания системной архитектуры получила название “инженерия системной архитектуры”. Конечно, у этой практики есть и множество других названий: architecturing (архитектурирование — но так по-русски говорят редко), эскизное проектирование (conceptual design). Инженерия системной архитектуры представляет собой часть в архитектурном проектировании (architecturing design), хотя в это проектирование входит создание всего проекта (design), в том числе и неархитектурной его части.

Создание системной архитектуры подразумевает синтез самых разных описаний целевой системы и прямой инженерный творческий процесс (в отличие от реверсинжиниринга, т.е. “обратной инженерии” использующей системы в инженерии требований. Реверс-инжиниринг считается главным образом аналитической практикой — т.е. практикой не придумывания, а выявления/discovery описаний, в чём-то сродного научной работе, а не инженерной).

Как и любое определение системы, архитектура у системы есть всегда, но не всегда при разработке тщательно делаются архитектурные описания. Часто это «устная архитектурная традиция» — и тогда архитектуру называют “заделы”, “опыт”, “наработки” (обычно при произнесении этих слов как раз и имеются ввиду важные инженерные решения, каковы бы они ни были). Часто архитектурные решения передаются из уст в уста, как «народный эпос».

Более того, раньше при наличии требований и существовании этого “народного эпоса” часто переходили непосредственно к проектированию и конструированию, не документируя принятых важнейших решений — особенно, когда эти решения принимались методом “проб и ошибок”. Архитектурное знание не накапливалось, и не обсуждалось, ибо не было документировано. Сейчас же принято документирование архитектурного знания, поэтому “проектирование” всё чаще называют “архитектурным проектированием” (например, в стандарте ISO 15288 практик жизненного цикла системной инженерии нет практики “проектирования”, а есть именно практика “архитектурного проектирования”).

Системная архитектура разрабатывается системными архитекторами, специализация на системной архитектуре одна из основных специализаций для системных инженеров. Часто “системный инженер-архитектор” сокращают до просто “архитектор”, но нужно учитывать возможную путаницу со строительными архитекторами.

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

Практики архитектурного проектирования

Их множество (см. обзор в первой главе книги М.Левина «Технология поддержки решений для модульных систем»: http://www.mslevin.iitp.ru/Levin-bk-Nov2013- 071.pdf). У всех них один «недостаток»: хорошему инженеру эти методы помогают, плохому инженеру они помочь не могут.

Наиболее известен ТРИЗ

(http://ru.wikibooks.org/wiki/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B _%D0%A2%D0%A0%D0%98%D0%97, можно начинать с проглядывания трёх текстов: АРИЗ-85В http://www.triz-ri.ru/triz/triz02.asp, типовых приёмов разрешения противоречий http://www.triz-ri.ru/triz/triz04.asp и стандартных решений изобретательских задач) как метод совмещения логической и физической архитектур.

DSM (http://www.dsmweb.org/) чаще всего используется как метод разбиения системы на модули.

ТРИЗ и DSM практикуются во многих центрах разработки. Но есть огромное число методов, практикующихся в рамках одного-двух университетских или промышленных исследовательских центров/лабораторий (реже – центров разработки).

Все более и более распространены архитектурные расчёты, в которых принципиальная схема “живая” и по ней можно вести мультифизические расчёты. Вот пример такой архитектурной модели привода на акаузальном языке мультифизического моделирования Modelica (https://modelica.org/ — там тонны материала, разберитесь! Бесплатный софт для Modelica —