Use cases are central to gathering requirements and are an obvious focal point for organizing the requirements and analysis model. For example, when you are working on related requirements and use cases, you typically need access to one or more use cases and actors. When detailing a use case, you work on a single use case and detailed views (a set of scenarios) and often either an activity diagram or a statechart (or some other formal specification language). When elaborating a collaboration, you must create a set of classes related to a single use case, as well as refining the scenarios that are bound to that use case. Packages can divide the use cases into coherent sets (such as those related by generalization, «includes» or «Extends» relations, or by associating with a common set of actors). In this case, a package would contain a use case and its actors, activity diagrams, statecharts, and sequence diagrams.
A framework‑based model organization addresses some of the restrictions of the use case‑based approach. It is still targeted at small systems, but it adds a framework package for shared and common elements. The framework package has subpackages for usage points (classes that will be used to provide services for the targeted application environment) and extension points (classes that are grouped into subclasses by classes in the use‑case packages). Note that there are other ways to organize the framework area that also work well. For example, frameworks often consist of sets of coherent patterns; the subpackaging of the framework can be organized around those patterns. While this is apt when constructing small applications within a common framework, the scheme does hamper reuse in some of the same ways as the use case‑based approach.
Another approach is to break up the architecture into the logical (organization of types, classes, and other design‑time model elements) and physical aspects (organization of instances, objects, subsystems, and other run‑time elements). The logical architecture is often organized by domains, whereas the physical architecture revolves around components or subsystems. If you structure the model this way, a domain, subsystem, or component becomes a CI to be assigned to a single worker or team. If the element is large enough, it can be further subdivided into subpackages based on subtopic within a domain, subcomponents, or another criterion such as team organization.
You could also divide the model based on classes. A domain, as defined in the ROPES process, is a subject area with a common vocabulary, such as device I/O, user interface, or alarm management. Each domain contains many classes, and system‑level use case collaborations will contain classes from several different domains. Many domains require rather specialized expertise, such as low‑level device drivers, aircraft navigation and guidance, or communication protocols. From a workflow and logical standpoint, it makes sense to group such elements because a single person or team will develop and manipulate them. Grouping classes by domains and having the domains be CIs might make sense for many projects.
A model can sometimes be organized intuitively by components. A UML component in IBM® Rational® Rhapsody® is a basic building block used to define executables, libraries, and other physical binary deliverables. Each such component is compiled from code generated from model elements. The model elements that compose the component are called the component scope. Using top‑level packages that include all the model elements mapped to a certain component creates a simple and easy‑to‑use structure. This approach interferes with reuse of the same design elements in multiple components. However, efficiency can be achieved by component‑level reuse; that is, assigning the design‑level elements to be reused into a library, then using this library in multiple components.
A simple solution would be to assign one package per team member. Everything that Sam works on is in SamPackage; everything that Julie works on is in JuliePackage. For very small project teams, this solution is a viable model. But again, it presents the question of what Sam should work and what Julie should work on. It can also be problematic if Susan wants to update a few of Sam's classes while Sam is working on others in SamPackage. Further, this scheme adds project team organization dependencies into the model structure, making it more difficult to change the project team (such as assigning team members to another task) and also limits reusability.