A modeling language for describing software structures and behavior. A class diagram records types and relationships; a sequence diagram records ordered interactions; a state diagram records states and event-triggered transitions.
Describe the possible states of a system and transitions triggered by events, optionally constrained by guards and accompanied by actions. The diagram emphasizes a component's lifecycle and permitted reactions. It can describe many interaction traces, while a sequence diagram focuses on the temporal ordering of messages in an interaction.
Describe an interaction through participant lifelines and ordered messages. Time usually proceeds downward. Calls, replies and execution intervals show how participants cooperate in one scenario, with optional fragments for alternatives or repetition. The diagram emphasizes message ordering across participants.
A structural diagram showing software classes or object interfaces, their attributes and operations, and relationships such as class inheritance and associations. A hollow triangle points toward a more general classifier; a dashed realization line distinguishes implementation of an interface. A plain association does not assert exclusive lifetime ownership of the referenced object.
A strong whole-part relationship in a UML class diagram, conventionally marked by a filled diamond at the whole. It expresses exclusive composite ownership and associated lifetime constraints. A stored reference or observer-registration association alone does not establish composition: the same observer may be registered with several subjects unless the design forbids it.
The organization of a software system's major components, their responsibilities and their interactions. A software architecture constrains which components own state and which may request or observe changes. Model-view-controller is one example for interactive applications.
Separate an application's domain state and rules into a model, its presentation into a view, and interpretation of user actions into a controller. The controller requests model operations; the view renders coherent model state. A playlist model, for example, owns song order independently of whether a menu, button or keyboard action requests a move. The Observer pattern often carries model-change notifications to views, but model-view-controller defines responsibilities rather than requiring a particular notification mechanism. This supports separation of concerns and testing domain logic independently of a graphical interface.
Assign distinct responsibilities to components with explicit interfaces, so one responsibility can change without requiring unrelated changes elsewhere. For example, a model-view-controller application separates domain state, presentation and input interpretation. The Observer pattern can communicate a coherent state change to several views while keeping concrete display details out of the model. The separation should follow actual responsibilities; multiplying classes without a clear boundary does not establish it.
