You can use sequence diagrams to represent a process of baking an apple pie, the interactions of the whole kitchen staff, the logistics network supplying the ingredients, or the software programs enabling this flow. They are based on very simple principles, where parallel entities and their actions, and the message exchanges triggering these actions are very generic. Sequence diagrams are not only useful for software design. I base all my project work, work breakdown structures, backlogs on a design achieved through the exercise of creating sequence diagrams for all the components, and all the entities in the complex systems I create. It is much closer to what Erlang has today. Just look at the Smalltalk object orientation. What Alan Kay (and those before him) was describing so many years ago was a micro-service oriented way of designing systems. It was never about objects or references, it was rather about asynchrony, by-value messages, requests and locality. Modern object oriented programming is a direct violation of the model originally proposed by Alan Kay. This way of describing and visualising components of a system is very close to the original idea of objects introduced by Alan Kay. Sequence diagrams visualise interactions between independent entities, executing their functionality in parallel, and asynchronously exchanging information. ✅ Understanding sequence diagrams and using them for work breakdown will give you superpowers and turn your team into laser falcon tiger dragons!Īnd here are my additional thoughts which cannot fit in a single post. Done! Now you can implement the flows, test them, package and deploy them independently. ✅ Oh and here's the kicker - when you are working on an agile team and want to prepare a good breakdown of work "how to deliver a software product", focus on creating sequence diagrams for all features, and translate the sequence diagrams into user stories in a backlog. Value stream mapping is just a specialised version of a sequence diagram! You can use them to visualise entire manufacturing operations and supply chains. They can be used to visualise any set of asynchronously dependent entities exchanging any information, data, documents, physical artifacts. ✅ And don't think for a second that sequence diagrams are only for parallel software services talking with messages. with a sequence diagram, that means you have it figured out pretty well. The inverse is also true - if you CAN represent your feature, architecture, organisation. ![]() ![]() ⚠ If you cannot represent a feature with a sequence diagram, you just don't understand it enough yet. ⚠ I said it once, I'll say it again and I'll never stop □ - Sequence diagrams are the single most important tool to visualise your software, your dependencies between teams and departments, the collaboration within your organisation, dependencies between software packages, your production and manufacturing flow etc.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |