Section 3.5. Variations on Package Diagrams


3.5. Variations on Package Diagrams

This section presents two applications of class package diagrams and one application of use case packages. Although layering and simplification always motivate packaging, the term "simplification" means different things to different people. Simplification can mean:

  • Easier to build and test

  • Better tracking and project transparency

  • Working at a stable overview without the noise of low-level churn

  • Less conflict between distributed teams

  • Easy refactoring and extension

Simplification likely means more apparent complexity to some constituency. Unless your packaging balances these diverse needs, you are likely to receive complaints of unnecessary complexity, no matter how noble your motives are.

3.5.1. Structuring a Project with Package Diagrams

Class packages organize a logical system during construction. They provide the terms for management and external stakeholders, as well as structure to contain all classes and code to be built. Class package diagrams are the UML equivalent of block diagrams.

Different parties think of a project according to their different needs. Programmers think in terms of language and tactical design. Architects think in terms of dependencies, risk, technology, building, testing, and OO principles. Project managers think in terms of risk, tracking, resources, need, ownership, required skills, and delivery. Although all issues are important, and good packaging recognizes its responsibility to all needs, architects tend to identify top-level packaging with an eye on the control functions of project management. For example, a project manager might draw a package diagram for a web application such as that shown in Figure 3-8.

Figure 3-8. Top-level packages defining a web application


The diagram in Figure 3-8 carries very little meaning by itself. It must be accompanied by an auxiliary, textual document that describes the basis for the packaging. Such a document might, for example, contain a list as follows:


web

Requires special skills: HTML, CSS, and Struts, a presentation technology; most dependencies.


database

Requires database management and modeling skills; most independent/fewest dependencies.


user

To be built off-site by a remote team.


search

Requires familiarity with search engine technology and techniques; self-contained subsystem.


editing

Comprises the basic editing features to be delivered in the first release; different skills and different team.


rtf-editing

Comprises those editing features scheduled for release 2.


x-editing

Comprises editing features requested by a specific client. These features to be withdrawn or delayed depending on that client. Risk is independent of the other features.

Figure 3-8 doesn't show the complete set of packages in the system. It is merely enough for management to track and control the project. Programmers create lower-level packages as needed for correct code design. Managers, however, allocate resources and track progress on the relatively large grains of the project shown in Figure 3-8 without getting disturbed by the addition or refactoring of internal packages and contents.

3.5.2. Use Case Packages

Use case packages organize the functional behavior of a system during analysis. Figure 3-9 shows the major functional areas of a content management system. The packages provide understandable terms for team members outside the analyst team. Managers can discuss the project at an appropriate level of detail without getting bogged down in details.

The CMS system shown in Figure 3-9 comprises packages created for the following reasons:

  • The complex editing packages separate the preliminary delivery and the advanced delivery from the client-based delivery.

  • The simple interactions, view and feedback, contain basic, low-risk functions.

  • The reporting has more sophisticated functions.

  • The search and the user management separate complex functions.

Just as with the class packages in Figure 3-8, you manage the use case packages to manage the project. Remember that tracking use case packages tracks customer value.

3.5.3. Directed Dependency Graphs

Directed dependency graphs of the packages in a system reveal nonfunctional issues related to buildability, testability, and robustness; they provide a guide for several roles in software development.

Figure 3-9. A set of functional major use case packages


When all the dependencies flow in one direction, as in Figure 3-10, without any loops or cycles, the graph is acyclic. Acyclic graphs show a project in good health.

Directed dependency graphs can help you avoid problems with build scripts and project testing. Looking at Figure 3-10, you can see that refactoring timer will invalidate testing and potentially break the build of visualizers, threads, controllers, and top; you should thus change the timer package with caution.

Directed dependency graphs can also help you divide project work among different staff members. For example, Figure 3-10 shows no dependencies between threads and visualizers. Thus, different groups of people can work on those two packages without destabilizing each other.

Figure 3-10. Dependency graph of modified JMeter with no cycle


Through time, projects evolve, and new dependencies creep in because of misunderstanding or expediency. Figure 3-11 shows such a case; three bidirectional dependencies ruin the desirable, acyclic nature of the graph:

  • utils now depends on threads.

  • threads now depends on controllers.

  • samplers now depends on tHReads.

The problem here is that the reverse of each dependency already existed in Figure 3-10. The result is the tangle of bidirectional arrows in level 1 of Figure 3-11, which contrasts with the clear flow of arrows in Figure 3-10. The further result is pain, for the developers, testers, and likely, managers and users. Changes in threads will confound the team responsible for controllers and utils, and vice versa because fixes in one require fixes in the code or unit tests of the others. It may take several iterations until all packages stabilize.[*]

[*] For more theory and metrics regarding packages and their dependencies, see John Lakos' Large-Scale C++ Software Design. Also see Robert C. Martin's http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign.

Figure 3-11. Dependency graph of modified JMeter with three cycles





UML 2.0 in a Nutshell
UML 2.0 in a Nutshell (In a Nutshell (OReilly))
ISBN: 0596007957
EAN: 2147483647
Year: 2005
Pages: 132

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net