Что заменило SADT?
Прежде чем все стало "предприятием", было время, когда все было "структурировано". Около 20 лет назад структурный анализ и структурное проектирование (SADT) вместе с инструментами CASE обещали спасение многим ИТ-специалистам.
В то время как шумиха тогда - как и любая другая шумиха - приходила и уходила, я поражен тем, что больше не вижу следов SADT. И на самом деле я считаю, что не так уж и плохо заслужить такую участь. Что мне особенно нравится, так это то, что в нем подчеркиваются функциональные аспекты системы, т.е. вы получите четкое представление о том, что производит система (вы не можете указать системы только для записи с SADT), парадигму, которая также повсеместна в функциональном программировании.
Мои вопросы:
- каков современный эквивалент SADT?
- Существует ли стиль рисования UML (кроме контекстной диаграммы), предлагающий подобный уровень абстракции и сопоставимые возможности уточнения.
- Знаете ли вы, почему мир покинул SADT?
- Известны ли вам какие-либо инструменты CASE, которые позволяют выполнять SADT, и которые выходят за рамки простых инструментов рисования и, например, допускают иерархические диаграммы с проверкой согласованности
2 ответа
"Больше не вижу следов SADT": ключевое слово "практически". Наши "современные" концепции, такие как "сплоченность" и "связь", в основном исходят от SADT [Эдвард Вашдон-Ларри Л.Контантин] . Есть даже интересные ссылки из современной литературы по программному обеспечению на старую литературу по SADT. Например, Кент Бек в разделе "Библиография" книги " Реализация " говорит:
Эдвард Тидан и Ларри Константин, Структурный дизайн,...,1979 .
Эта книга представляет собой эквивалент законов физики для проектирования программного обеспечения и обосновывает обсуждение экономики развития.[Кент Бек, Образцы реализации]
В этих книгах Тидан и Константин говорят, что:
Структурированный дизайн - это искусство проектирования компонентов системы и взаимодействия между этими компонентами наилучшим образом.
И Мейлир Пейдж-Джонс говорит, что:
- Структурированный дизайн использует инструменты, особенно графические, чтобы сделать системы понятными.[Мейлир Пейдж-Джонс - Практическое руководство по проектированию структурированных систем]
И сегодня в разработке программного обеспечения наша цель все та же...:-)
Почему мир отказался от SADT?
Ну, у нас больше изменений, чем в индустрии моды:-).
Системы, которые мы строим сегодня, и ограничения отличаются от тех, что были двадцать или более лет назад. Я думаю, что когда мы начинаем разрабатывать более "ориентированные на данные" системы, где функциональная сложность менее важна, методы SADT, такие как структурные диаграммы и диаграммы потоков данных, "утратили" свою эффективность для некоторых систем. Затем объектно-ориентированный стиль имеет свой собственный методологии и представления.
Но диаграммы Entity-Relationship(ER) и концепция словаря данных все еще живы.
Для интересной точки зрения Yourdon проверьте его блог: Смотря "проворный"...
Интересно, что Yourdon до сих пор обновляет материалы по структурированному дизайну. Проверить по адресу: Современный структурированный анализ
Что заменило SADT?
Ну что ж... Для объектно-ориентированных систем..
Предположим, у нас есть дизайн, основанный на ответственности (в котором сплоченность и связь все еще важны) для поиска лучших компонентов и их взаимосвязей в наших системах. А UML обычно дает нам хороший инструмент визуального мышления для поиска этих компонентов и взаимосвязей.
И теперь мы понимаем, что разработка программного обеспечения - экспериментальная деятельность. Мы должны делать итеративную и инкрементальную разработку с эволюционными требованиями.
Кажется, нет волшебного "метода", в котором можно следовать, как "квитанция" за успех.
Моделирование в целом:
Диаграммы-модели - это просто инструменты мышления.
Нереально спроектировать всю систему на бумаге с использованием UML или других обозначений. На самом деле наши реальные модели - это "исходный код", который можно выполнить и протестировать.
Есть несколько попыток, таких как MDA(Model Driven Architecture), которые пытаются автоматически генерировать исполняемый код из моделей: так что нам просто нужно смоделировать систему, тогда все будет создано автоматически. Но мы поняли, что это тоже нереально. Пока это просто мечта, которую продают некоторые поставщики инструментов. Теперь мы больше ориентируемся на предметно-ориентированные языки, которые более практичны и реалистичны.
Я работал с SADT для нового метеорологического спутника, использующего C++. Я нашел его описание функциональных аспектов (как было указано в вопросе) алгоритма очень ценным. Попробуйте найти поисковый запрос: "GOES-R SADT": http://www.goes-r.gov/downloads/GUC-7/poster-sessions/4-06_Ivan_Pathfinder.pdf и https://ams.confex.com/ams/91Annual/webprogram/Manuscript/Paper184496/SADT-UML-Extended-Abstract%28Submitted-20110223%29.pdf