Fundamentals of Software Engineering

Chapter 4. Modeling

All models are wrong, but some are useful.

George E.P. Box, British statistician (attributed)

By now, it should be clear that communication is a central focus of your work as a software engineer, especially communication between you and other developers. While the computer cares only about syntactically correct code, communicating with other humans takes much more. Your code should be well-documented and organized so it can be understood by other people (see Chapter 3 for more on writing code), but sometimes you’ll want more. Throughout a project, you will use software models or box and line diagrams to express your technical intent.

Much like good code, good software models are clear and easy for your stakeholders to understand. If your models aren’t clear, those consuming your models won’t understand your technical intent. There is no shortage of consumers for your models: users, testers, other developers, security, the people writing the checks, project managers, and architects. Yourself. Sometimes, the only consumer of a diagram will be you. That said, you can’t expect to draw some pictures and expect everyone to understand them. A diagram that’s perfect for a developer might not work so well for the vice president of engineering. And vice versa. Your challenge is to know what diagram to create and when to create it.

What Is Software Modeling and Why Do We Do It?

Software is a relatively young industry, and as such, has borrowed concepts and approaches ...