Reposted with permission from the original author
Ezequiel Cuellar of CrossLogic Corporation http://www.crosslogic.com

Section 3 - Architecture.

Package.

• A UML package is shown as a tabbed folder.
• When you show the package contents you put the name of the package in the tab and the contents inside the main box. The contents can be a list of classes, another package diagram, a class diagram or collaboration. If the contents of the package are not shown then the name of it is centered within the folder itself.
• Elements in one package that are referenced by elements in another package should by named using the pathname format PackageName::ElementName.
• A package dependency indicates that elements of the dependent package in some way know about or are coupled to elements in the target package.
• A note can be used to indicate the package that certain elements are member of when is inconvenient to draw a package diagram.
• To organize the classes in a domain model within packages apply the following rules.
  • Are in the same subject area-closely related by concept or purpose.
  • Are in a class hierarchy together, (related by generalization-specialization).
  • Participate in the same use cases.
  • Are strongly associated.
• Two approaches to showing packages structure is using UML path names or a circle-cross symbol.
• A dependency exists between two elements if changes to the definition of one element may cause changes to the other. Ideally only changes to a class interface should affect any other class.
• A dependency between two packages exists if any dependency exists between any two classes in the packages.
• With packages the dependencies are not transitive. For example we have A,B and C packages, there is dependency A and B and between B and C. If C changes A does not have to change. A changes only and only if B changes. This behaviour is the classic purpose of a layered architecture. For example:
  • A depends on B, B depends on C
  • If C is changed, A does not have to change
• Classes within packages can be public, private or protected. If you alter a private method or a public method in a private class none of the classes in the dependent package must change.
• A useful technique is to reduce the interface of the package by exporting only a small subset of operations associated with the package's public classes. This is possible by giving all classes private visibility so that they can be seen only by other classes in the same package, and by adding extra public classes for the public behaviour. These extra classes are called Facades, and then delegate public operations to their shyer companions in the package.
• To draw a dependency to a package that contains sub-packages means that the dependency summarizes a lower-level dependency. That is there is some dependency to some element within the higher-level package, but a more detailed diagram is needed to see the details.
• A package that other packages have dependency to is marked as <<global>>.
• Generalization can be used with packages. This means that the specific package must conform to the interface of the general package.
• Generalization implies a dependency from the subtype to the supertype.
• Putting abstract classes in a supertype package is a good way of breaking cycles in the dependency structure.
• Use packages whenever a class diagram that encompasses the whole system is no longer legible.
• Packages are vital tool for large projects.

Package Organization Guidelines.

• Package functionality cohesive vertical and horizontal slices. Types must be grouped together that are strongly related in terms of their participation in a common purpose, service, collaborations, policy and function.
• Package a family of interfaces. Place a family of functionally related interfaces in a separate package. This is not primarily for the case of one or two related interfaces but rather when there is a family.
• Package by work and by clusters of unstable classes. If a package A has 20 classes and 10 of them are unstable or suffer of frequently releases, then package them out and developers that have dependencies to A will not be affected anymore by changes in A. Reduce widespread dependency on unstable packages.
• More responsible are most stable. If the most responsible packages (depended-on) are unstable there is a greater chance of widespread change dependency impact.
• There are different ways to increase stability in a package:
  • It contains only or mostly interfaces and abstract classes.
  • It has no dependencies on other packages (it is independent) or it depends on other very stable packages or it encapsulates its dependencies such that dependents are not affected.
  • It contains relatively stable code because it was well exercised and refined before release.
  • It is mandated to have a slow change schedule.
  • -Factor out independent types. O
• Organize types that can be used independently or in different contexts into separate packages.
• Use Factories to reduce dependency on concrete packages. When creating instances of types that reside in a different package the coupling is increased. By changing the reference to a Factory object instead that creates the instances reduces the coupling.
• No cycles in packages. If a group of packages have cyclic dependency then they may need to be treated as one larger package in terms of a release unit. There are two solutions to this:
  • Factor out the types participating in the cycle into a new smaller package.
  • Break the cycle with an interface:
    • Redefine the depended-on classes in one of the packages to implement new interfaces.
    • Define the new interfaces in a new package.
    • Redefine the dependent types to depend on the interfaces in the new package, rather that the original class.

Collaborations.

• A collaboration is a name given to the interaction among two or more classes. Typically this is an interaction as described in an interaction diagram.
• A collaboration may show the implementation of an operation or the realization of a use case.
• A parameterized collaboration is used when the basic way the classes work is the same but classes and operations are named differently.
• The UML uses the term pattern as a synonym for parameterized collaboration.

Layers pattern.

• Solution: Organize the large-scale logical structure of a system into discrete layers of distinct related responsibilities with a clean cohesive separation of concerns such that the lower layers are low-level and general services and the higher layers are more application specific.
• Collaboration and coupling is from higher to lower layers; lower-to-higher layer coupling is avoided.
• Presentation: Gui, reports, speech interface.
• Application: Handles presentation layer requests, workflow, session state, window/page transitions, consolidation/transformation of disparate data for presentation.
• Domain: Handles application layer requests, implementation of domain rules, domain services.
• Business Infrastructure: Very general low-level business services used in many business domains.
• Technical Services: High-level technical services and frameworks, Persistence, Security.
• Foundation: Low level technical services, utilities and frameworks, Data structures, threads, math, file, DB, and network I/O.
• A subsystem is a discrete entity that has behavior and interfaces and can be identified with the stereotype <<subsystem>>.
• For packages that represent subsystems the most common pattern of access is Façade (GoF).
• If the application has only a small number of system operations then it is common for the Application or Domain layer to expose only one object to an upper layer.
• When an application has many system operations and supports many use cases it is common to have more than one object mediating between the Presentation and Domain layers.
• As the system grows to handle many use cases and system operations, is not uncommon to intruduce an Application layer of objects that maintain session state for the operations of a use case where each session instance represents a session with one client. These are called Session Facades.
• The GRASP Controller pattern describes common choices in client-side handlers for system operation requests emitting from the Presentation Layer.
• The Facade pattern is commonly used for "downward" collaboration from a higher to lower layer.
• When the lower Application or Domain layer needs to communicate upward with the Presentation Layer it is usually via the Observer pattern. The lower layer objects are directly sending messages to the upper layer UI objects but the coupling is only to the objects viewed as things that implement an interface such as Listener, not viewed as specific GUI windows.
• The architecture follows a "relaxed layered" or "transparent layered" architecture in which elements of a layer collaborate with or are coupled to several other layers.
• All higher layers have dependencies on the Technical Services and Foundation Layers.
• It is primarily the Domain layer that has dependency on the Business Infrastructure layer.
• The Presentation layer makes calls on the Application Layer which makes service calls on the Domain Layer. The Presentation Layer does not call on the Domain.
• Lower layers contain reusable functions.
• Development by teams is aided because of the logical segmentation.
• It is recommended within an iteration to have a developer specialize within one layer or one service.
• The layers of an architecture are said to represent the vertical slices while partitions represent a horizontal division of relatively parallel subsystems of a layer.
• The model-view separation states that the domain objects should not have direct knowledge of view; therefore they should not directly send a message to the GUI window object.
• The model-view separation benefits are:
  • Support cohesive model definitions that focus on the domain processes rather that on user interfaces.
  • To allow separate development of the model and user interface layers.
  • To minimize the impact of requirements changes in the interface upon the domain.
  • To allow new views to be easily connected to an existing domain without affecting it.
  • To allow multiple simultaneous views on the same model object.
  • To allow execution of the model layer independent of the GUI layer.
  • To allow easy porting of the model layer to another GUI framework.

• GUI can obtain information using the pull-from-above model in which GUI objects perform queries for information on the domain and the push-from-below model in which the domain notifies the GUI that has changed, in this case the Observer and the Facade patterns are helpful.
• Basic Architectural Design principles are low coupling, high cohesion and protected variation.
• Thin clients are not restricted to GUI parts. The command line is a thin client as well.

Deployment Diagram.

• A deployment diagram shows the physical relationships among software and hardware components in the delivered system.
• Each node on a deployment diagram represents some kind of computational unit in most cases a piece of hardware.
• Connections among nodes show the communication paths over which the system will interact.

Component Diagram.

• A component diagram shows the various components in a system and their dependencies.
• A component represents a physical module of code. A component is often the same as package.
• The dependencies among the components show how changes to one component may cause other components to change.
• A component may have more than one interface.

Contributors:

• Ezequiel Cuellar - prime
• cfw
• SZ