Can you use a state machine diagram in the development view (4+1 Architecture)

Question

I have seen several different diagrams in several different views.

Is is possible to use the state machine diagram in the development view in 4+1 Architecture?

Answer 1

Is it possible? Sure, you can do anything you want. Would I expect it? No, it doesn't really fit the purpose of the development view.

In a previous answer, I wrote about the relationship between the 4+1 architectural views and UML diagram types. In this answer, I described the development view as such:

The development view is primarily for developers who will be building the modules and the subsystems. It should show dependencies and relationships between modules, how modules are organized, reuse, and portability.

I would be more likely to expect a state diagram in the logical or process view. In a logical view, I would expect the state diagram to show the apparent states of the application in a manner that would be seen by an end user. In a process view, I would expect to see internal states that may be of interest to domain experts or system integrators.

However, that doesn't mean that a state machine diagram is not appropriate for the development view.

Each of the views is designed to meet the needs of a particular audience. The logical view represents the perspective of the end users. The process view is primarily for business analysts, systems engineers, system integrators, and developers who are interacting with the system. The physical view is for systems engineers and infrastructure owners. The development view is for the developers of the system.

It is likely that the system developers can use all of the views to understand the system under development. However, the end users probably won't be interested in the physical layout of the system, for example. If you aren't sure where to put a particular piece of information, I would recommend this:

1. Is the information useful to the end user? If so, put it in the logical view.
2. Is the information useful to technical users and support staff? If so, put it in the process view.
3. Is the information useful to infrastructure and deployment staff? If so, put it in the physical view.
4. Is the information useful to the people designing and maintaining the system? If so, put it in the development view.

If you get to the end and it's not useful, you probably don't need the information.