The main reason for modeling is to organize and visualize the structure and components of software intensive systems. With models, you capture requirements, identify and specify subsystems, and visualize and document logical and physical elements, and structural and behavioral patterns.
In the UML User Guide, Booch et al cite a number of activities involved in modeling a system's architecture. These activities may be summarized as:
Identify different architectural viewpoints, i.e., use case, design, process, implementation, and deployment views
Identify the system context and the actors involved
Decompose a large, complex system into it's most granular subsystems.
In addition, the authors outline a number of activities that apply to both the overall system and each of the subsystems:
Use Case view: model use cases describing system behavior as seen by analysts, end users, and testers. Use Use Case diagrams for the static aspects, and appropriate combinations of Activity, Collaboration, Sequence, and State diagrams to show dynamic aspects.
Design view: model a design view specifying classes, interfaces, and collaborations. These provide a working vocabulary for the system in terms of both problem and solution. Create Class diagrams (including Objects as necessary) to model static aspects, and again, appropriate combinations of Activity, Collaboration, Sequence, and State diagrams to show dynamic aspects.
Process view: model a process view to describe threads and processes of various synchronization and concurrency mechanisms. Same diagrams as above are recommended, except focusing on active classes and objects representing threads and processes.
Implementation view: model the components used to build and release the system. Use Component diagrams for the static aspects, and again, appropriate combinations of Activity, Collaboration, Sequence, and State diagrams to show dynamic aspects.
Deployment view: model the nodes, components, and interfaces forming the hardware topology for the runtime system. Use Deployment diagrams for static aspects, and appropriate combinations of Activity, Collaboration, Sequence, and State diagrams to show the dynamic aspects.
Patterns: model the architectural and design patterns of each of these models with appropriate diagrams to show collaborations.
The authors go on to point out that creating of a system architecture isn't a single event; rather it is a process of successive refinement, in a manner that is "use case-driven, architecture centric, and iterative and incremental."*
Choosing the right set of models is important. There are no hard and fast rules, but the wrong models give you an inaccurate view of the system and jeopardize the overall success of a project. A few points to remember about good models are:
Good models are a simplification of reality from a specific point of view
Good models can stand alone semantically
Good models are loosely coupled to other models
Good models in aggregate provide a complete blueprint for a system.