A good design model has the following characteristics:

It satisfies the system requirements. It is resistant to changes in the implementation environment. It is easy to maintain in relation to other possible object models and to system implementation. It is clear how to implement. It does not include information that is best documented in program code. It is easily adapted to changes in requirements.

Use Case

A use case defines a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor.

preconditionsA textual description that defines a constraint on the system when the use case may start.postconditionsA textual description that defines a constraint on the system when the use cases have terminated.Extension pointsA list of locations within the flow of events of the use case at which additional behavior can be inserted using the extend-relationship.RelationshipsThe relationships, such as communicates-associations, include-, generalization-, and extend-relationships, in which the use case participates.Purpose

The following people will use the use cases:

Customers will use the use cases to understand the system's behavior, and, since they must approve the use case's flow of events, customer will also use the use cases to approve the result of use-case modeling.

Potential users will use the use case to understand the system's behavior. Software Architects will use the use cases to identify architecturally significant functionality. People who analyze, design, and implement the system will use the use case to understand the

required system behavior and to refine the system. Use-case designers will use the use cases' flows of events to find classes. (These are the most

important artifacts for use-case designers.) Testers will use the use cases as a base for identifying test cases. Managers will use the use cases to plan and follow up the use-case modeling. Documentation writers will use the use cases to understand what sequence of use should be

described in the documentation (such as the system user guide).

Responsibility

A requirements specifier is responsible for the integrity of the use case, which ensures that:

the use case fulfills its requirements (that is, it correctly describes the functionality that is relevant to the use case, and only this functionality)

the flow of events is readable and suit its purpose the use-case relationships originating from the use case are justified and kept consistent the role of the use case where it is involved in communicates-associations is clear and intuitive the diagrams describing the use case and its relationships are readable and suit their purpose the special requirements are readable and suit their purpose the preconditions are readable and suit their purpose the postconditions are readable and suit their purpose

Collaboration Diagram

A collaboration diagram describes a pattern of interaction among objects; it shows the objects participating in the interaction by their links to each other and the messages that they send to each other.

Collaboration diagrams are used to show how objects interact to perform the behavior of a particular use case, or a part of a use case. Along with sequence diagrams, collaborations are used by designers to define and clarify the roles of the objects that perform a particular flow of events of a use case. They are the primary source of information used to determining class responsibilities and interfaces.

Unlike a sequence diagram, a collaboration diagram shows the relationships among the objects. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. Collaboration diagrams show the relationships among objects and are better for understanding all the effects on a given object and for procedural design.

Because of the format of the collaboration diagram, they tend to better suited for analysis activities (see Activity: Use-Case Analysis). Specifically, they tend to be better suited to depicting simpler interactions of smaller numbers of objects. As the number of objects and messages grows, the diagram becomes increasingly hard to read. In addition, it is difficult to show additional descriptive information such as timing, decision points, or other unstructured information that can be easily added to the notes in a sequence diagram.

You can have objects and actor instances in collaboration diagrams, together with links and messages describing how they are related and how they interact. The diagram describes what takes place in the participating objects, in terms of how the objects communicate by sending messages to one another. You can make a collaboration diagram for each variant of a use case's flow of events.

Objects

An object is represented by an object symbol showing the name of the object and its class underlined, separated by a colon:

objectname : classname

You can use objects in collaboration diagrams in the following ways:

An object's class can be unspecified. Normally you create a collaboration diagram with objects first and specify their classes later.

The objects can be unnamed, but you should name them if you want to discriminate different objects of the same class.

An object's class can itself be represented in a collaboration diagram, if it actively participates in the collaboration.

Actors

Normally an actor instance occurs in the collaboration diagram, as the invoker of the interaction. If you have several actor instances in the same diagram, try keeping them in the periphery of the diagram.

Links

A link is a relationship among objects across which messages can be sent. In collaboration diagrams, a link is shown as a solid line between two objects.

An object interacts with, or navigates to, other objects through its links to these objects. A link can be an instance of an association, or it can be anonymous, meaning that its association

is unspecified. Message flows are attached to links, see Messages

Messages

A message is a communication between objects that conveys information with the expectation that activity will ensue. In collaboration diagrams, a message is shown as a labeled arrow placed near a link. This means that the link is used to transport, or otherwise implement the delivery of the message to the target object. The arrow points along the link in the direction of the target object (the one that receives the message). The arrow is labeled with the name of the message, and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often used in collaboration diagrams, because they are the only way of describing the relative sequencing of messages.

A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message. You can later assign the message by specifying the operation of the message's destination object. The specified operation will then replace the name of the message.

Sequence Diagram

A sequence diagram describes a pattern of interaction among objects, arranged in a chronological order; it shows the objects participating in the interaction by their "lifelines" and the messages that they send to each other.

In most cases, we use a sequence diagram to illustrate use-case realizations (see Artifact: Use-Case Realizations), i.e. to show how objects interact to perform the behavior of all or part of a use case. One or more sequence diagrams may illustrate the object interactions which enact a use case. A typical organization is to have one sequence diagram for the main flow of events and one sequence diagram for each independent sub-flow of the use case.

Sequence diagrams are particularly important to designers because they clarify the roles of objects in a flow and thus provide basic input for determining class responsibilities and interfaces.

Unlike a collaboration diagram, a sequence diagram includes chronological sequences, but does not include object relationships. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. Sequence diagrams show the explicit sequence of messages and are better when it is important to visualize the time ordering of messages. When you are interested in the structural relationships among the instances in an interaction, use a collaboration diagram.

Contents of Sequence Diagrams

You can have objects and actor instances in sequence diagrams, together with messages describing how they interact. The diagram describes what takes place in the participating objects, in terms of activations, and how the objects communicate by sending messages to one another. You can make a sequence diagram for each variant of a use case's flow of events.

Objects

An object is shown as a vertical dashed line called the "lifeline". The lifeline represents the existence of the object at a particular time. An object symbol is drawn at the head of the lifeline, and shows the name of the object and its class underlined, and separated by a colon:

objectname : classname

You can use objects in sequence diagrams in the following ways:

A lifeline can represent an object or its class. Thus, you can use a lifeline to model both class and object behavior. Usually, however, a lifeline represents all the objects of a certain class.

An object's class can be unspecified. Normally you create a sequence diagram with objects first, and specify their classes later.

The objects can be unnamed, but you should name them if you want to discriminate different objects of the same class.

Several lifelines in the same diagram can represent different objects of the same class; but, as stated previously, the objects should be named that so you can discriminate between the two objects.

A lifeline that represents a class can exist in parallel with lifelines that represent objects of that class. The object name of the lifeline that represents the class can be set to the name of the class.

Actors

Normally an actor instance is represented by the first (left-most) lifeline in the sequence diagram, as the invoker of the interaction. If you have several actor instances in the same diagram, try keeping them either at the left-most, or the right-most lifelines.

Messages

A message is a communication between objects that conveys information with the expectation that activity will ensue; in sequence diagrams, a message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object. In the case of a message from an object to itself, the arrow may start and finish on the same lifeline. The arrow is labeled with the name of the message, and its parameters. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. Sequence numbers are often omitted in sequence diagrams, in which the physical location of the arrow shows the relative sequence.

A message can be unassigned, meaning that its name is a temporary string that describes the overall meaning of the message and is not the name of an operation of the receiving object. You can later assign the message by specifying the operation of the message's destination object. The specified operation will then replace the name of the message.

Scripts

Scripts describe the flow of events textually in a sequence diagram.

You should position the scripts to the left of the lifelines so that you can read the complete flow from top to bottom (see figure above). You can attach scripts to a certain message, thus ensuring that the script moves with the message.

Distributing Control Flow in Sequence Diagrams

Centralized control of a flow of events or part of the flow of events means that a few objects steer the flow by sending messages to, and receiving messages from other objects. These controlling objects decide the order in which other objects will be activated in the use case. Interaction among the rest of the objects is very minor or does not exist.

Example

In the Recycling-Machine System, the use case Print Daily Report keeps track of - among other things - the number and type of returned objects, and writes the tally on a receipt. The Report Generator control object decides the order in which the sums will be extracted and written.

This is an example of centralized behavior. The control structure is centralized primarily because the different sub-event phases of the flow of events are not dependent on each other. The main advantage of this approach is that each object does not have to keep track of the next object's tally. To change the order of the sub-event phases, you merely make the change in the control object. You can also easily add still another sub-event phase if, for example, a new type of return item is included. Another advantage to this structure is that you can easily reuse the various sub-event phases in other use cases because the order of behavior is not built into the objects.

The behavior structure of the use case Print Daily Report is centralized in the Report Generator control object.

Decentralized control arises when the participating objects communicate directly with one another, not through one or more controlling objects.

Example

In the use case Send Letter someone mails a letter to another country through a post office. The letter is first sent to the country of the addressee. In the country, the letter is sent to a specific city. The city, in turn, sends the letter to the home of the addressee.

The use case behavior is a decentralized flow of events. The sub-event phases belong together. The sender of the letter speaks of "sending a letter to someone." He neither needs nor wants to know the details of how letters are forwarded in countries or cities. (Probably, if someone were mailing a letter within the same country, not all these actions would occur.)

The type of control used depends on the application. In general, you should try to achieve independent objects, that is, to delegate various tasks to the objects most naturally suited to perform them.

A flow of events with centralized control will have a "fork-shaped" sequence diagram. On the other hand, a "stairway-shaped" sequence diagram illustrates that the control-structure is decentralized for the participating objects.

The behavior structure of the use case Send Letter is decentralized.

The behavior structure of a use-case realization most often consists of a mix of centralized and decentralized behavior.

A decentralized structure is appropriate:

If the sub-event phases are tightly coupled. This will be the case if the participating objects: o Form a part-of or consists-of hierarchy, such as Country - State - City;o Form an information hierarchy, such as CEO - Division Manager - Section Manager;o Represent a fixed chronological progression (the sequence of sub-event phases will always

be performed in the same order), such as Advertisement - Order - Invoice -Delivery - Payment; or

o Form a conceptual inheritance hierarchy, such as Animal - Mammal - Cat.

If you want to encapsulate, and thereby make abstractions of, functionality. This is good for someone who always wants to use the whole functionality, because the functionality can become unnecessarily hard to grasp if the behavior structure is centralized.

A centralized structure is appropriate:

If the order in which the sub-event phases will be performed is likely to change. If you expect to insert new sub-event phases. If you want to keep parts of the functionality reusable as separate pieces.

Statechart Diagram

A statechart diagram shows a state machine, which specifies the sequences of states that an object can be in, the events and conditions which cause the object to reach those states, and the actions which take place when those states are reached.

State machines are used to model the dynamic behavior of a model element, and more specifically, the event-driven aspects of the system's behavior (see Concepts: Events and Signals). State machines are specifically used to define state-dependent behavior, or behavior that varies depending on the state in which the model element is in. Model elements whose behavior does not vary with its state of the element do not require state machines to describe their behavior (these elements are typically passive classes whose primary responsible is to manage data). In particular, state machines must be used to model the behavior of active classes that use call events and signal events to implement their operations (as transitions in the class's state machine).

A state machine consists of states, linked by transitions. A state is a condition of an object in which it performs some activity or waits for an event. A transition is a relationship between two states which is triggered by some event, which performs certain actions or evaluations, and which results in a specific end-state.

States

A state is a condition of an object in which it performs some activity or waits for an event. An object may remain in a state for a finite amount of time. A state has several properties:

Name A textual string which distinguishes the state from other states; a state may also be anonymous, meaning that it has no name.

Entry/exit actions Actions executed on entering and exiting the state.Internal transitions Transitions that are handled without causing a change in state.Substates The nested structure of a state, involving disjoint (sequentially active) or

concurrent (concurrently active) substates.Deferred events A list of events that are not handled in that state but are postponed and queued

for handling by the object in another state.

The initial state indicates the default starting place for the state machine or substate. An initial state is depicted as a filled black circle. The final state indicates the completion of the execution of the state machine or that the enclosing state has been completed. A final state is represented as a filled black circle surrounded by an unfilled circle. Initial and final states are really pseudostates. Neither may have the usual parts of a normal state, except for a name. A transition from an initial state to a final state may have the full complement of features, including a guard condition and an action, but may not have a trigger event.

Transitions

A transition is a relationship between two states indicating that an object in the first state will perform certain actions and enter a second state when a specified event occurs and specified conditions are satisfied. On such a change of state, the transition is said to 'fire'. Until the transition fires, the object is said to be in the 'source' state; after it fires, it is said to be in the 'target' state. A transition has several properties:

Source state The state affected by the transition; if an object is in the source state, an outgoing transition may fire when the object receives the trigger event of the transition and if the guard condition, if any, is satisfied.

Event trigger

The event that makes the transition eligible to fire (providing its guard condition is satisfied) when received by the object in the source state.

Guard condition

A boolean expression that is evaluated when the transition is triggered by the reception of the event trigger; if the expression evaluates True, the transition is eligible to fire; if the expression evaluates to False, the transition does not fire. If there is no other transition that could be triggered by the same event, the event is lost.

Action An executable atomic computation that may directly act upon the object that owns the state machine, and indirectly on other objects that are visible to the object.

Target state The state that is active after the completion of the transition.

A transition may have multiple sources, in which case it represents a join from multiple concurrent states, as well as multiple targets, in which case it represents a fork to multiple concurrent states.

Event Triggers

In the context of the state machine, an event is an occurrence of a stimulus that can trigger a state transition. Events may include signal events, call events, the passing of time, or a change in state. A signal or call may have parameters whose values are available to the transition, including expressions for the guard conditions and action. It is also possible to have a triggerless transition, represented by a transition with no event trigger. These transitions, also called completion transitions, is triggered implicitly when its source state has completed its activity.

Guard Conditions

A guard condition is evaluated after the trigger event for the transition occurs. It is possible to have multiple transitions from the same source state and with the same event trigger, as long as the guard

conditions don't overlap. A guard condition is evaluated just once for the transition at the time the event occurs. The boolean expression may reference the state of the object.

Actions

An action is an executable atomic computation, meaning that it cannot be interrupted by an event and therefore runs to completion. This is in contrast to an activity, which may be interrupted by other events. Actions may include operation calls (to the owner of the state machine as well as other visible objects), the creation or destruction of another object, or the sending of a signal to another object. In the case of sending a signal, the signal name is prefixed with the keyword 'send'.

Entry and Exit Actions

Entry and exit actions allow the same action to be dispatched every time the state is entered or left, respectively. Entry and exit actions enable this to be done cleanly, without having to explicitly put the actions on every incoming or outgoing transition explicitly. Entry and exit actions may not have arguments or guard conditions. The entry actions at the top-level of a state machine for a model element may have parameters representing the arguments that the machine receives when the element is created.

Internal Transitions

Internal transitions allow events to be handled within the state without leaving the state, thereby avoiding triggering entry or exit actions. Internal transitions may have events with parameters and guard conditions, and essentially represent interrupt-handlers.

Deferred Events

Deferred events are those whose handling is postponed until a state in which the event is not deferred becomes active. When this state becomes active, the event occurrence is triggered and may cause transitions as if it had just occurred. The implementation of deferred events requires the presence of an internal queue of events. If an event occurs but is listed as deferred, it is queued. Events are taken off this queue as soon as the object enters a state that does not defer these events.

Substates

A simple state is one which has no substructure. A state which has substates (nested states) is called a composite state. Substates may be nested to any level. A nested state machine may have at most one initial state and one final state. Substates are used to simplify complex flat state machines by showing that some states are only possible within a particular context (the enclosing state).

From a source outside an enclosing composite state, a transition may target the composite state or it may target a substate. If its target is the composite state, the nested state machine must include an initial state, to which control passes after entering the composite state and after dispatching its entry

action (if any). If its target is the nested state, control passes to the nested state after dispatching the entry action of the composite state (if any), and then the entry action of the nested state (if any).

A transition leading out of a composite state may have as its source the composite state or a substate. In either case, control first leaves the nested state (and its exit action, if any, is dispatched), then it leaves the composite state (and its exit action, if any, is dispatched). A transition whose source is the composite state essentially interrupts the activity of the nested state machine.

Common Modeling Techniques

State machines are used most commonly to model the behavior of an object across its lifetime. They are particularly needed when objects have state-dependent behavior. Objects which may have state machines include classes, subsystems, use cases and interfaces (to assert states which must be satisfied by an object which realizes the interface).

In the case of real-time systems, state machines are also used for capsules and protocols (to assert states which must be satisfied by an object which realizes the protocol).

Not all objects require state machines. If an object's behavior is simple, such that it simply store or retrieves data, the behavior of the object is state-invariant and its state machine is of little interest.

Modeling the lifetime of an object involves three things: specifying the events to which the object can respond, the response to those events, and the impact of the past on current behavior. Modeling the lifetime of an object also involves deciding the order in which the object can meaningfully respond to events, starting at the time of the object's creation and continuing until its destruction.

Class Diagram

A class diagram shows a collection of declarative (static) model elements, such as classes, packages, and their contents and relationships.

Class diagrams show the static structure of the model, in particular, the things that exist such as classes, their internal structure, and their relationships to other classes. Class diagrams do not show temporal information.

A class diagram is presented as a collection of (static) declarative model elements, such as classes, packages, and their relationships, connected as a graph to each other and to their contents. Class diagrams may be organized into (and owned by) packages, showing only what is relevant within a particular package.

Use

The following class structures are suitable for illustration in class diagrams, but you will not use all of them in all situations. Each class structure should have its own class diagram.

The most important classes and their relationships. Diagrams of this type can function as an object model summary and are of great help in reviewing the model. These diagrams are likely to be included in the logical view of the architecture.

Functionally related or coherent classes. Classes that belong to the same package. Important aggregation hierarchies. Important structures of entity objects, including class structures with association, aggregation

and generalization relationships. If possible you should create a class diagram that contains all the classes of the long-lived objects and their relationships. This kind of diagram is especially useful in reviewing what is stored in the system, and the storage structures.

Packages and their dependencies, possibly illustrating their layering. Classes that participate in a specific use-case realization. A single class, its attributes, operations, and relationships with other classes.

You should present each class in at least one diagram. Sometimes you can better understand the model if a class appears several times in the same view, for example, if you want to discriminate between different objects of the class.

Deployment Model

The Deployment Model shows the configuration of processing nodes at run-time, the communication links between them, and the component instances and objects that reside on them.

Purpose

The purpose of the Deployment Model is to capture the configuration of processing elements, and the connections between processing elements, in the system. The Deployment Model consists of one or more nodes (processing elements with at least one processor, memory, and possibly other devices), devices (stereotyped nodes with no processing capability at the modeled level of abstraction), and connectors, between nodes, and between nodes and devices. The Deployment Model also maps processes on to these processing elements, allowing the distribution of behavior across nodes to be represented. The following roles use the Deployment Model:

The software architect, to capture and understand the physical execution environment of the system, and to understand distribution issues.

The designers (including software and database designers), to understand the distribution of processing and data in the system.

The system manager, to understand the physical environment in which the system executes. The project manager, in estimating costs, for the Business Case, and for acquisition, installation

and maintenance planning.

Property Name Brief Description UML RepresentationIntroduction A textual description that serves as a brief

introduction to the model.Tagged value, of type "short text".

Nodes Processing elements in the system. Nodes may have the following properties:

Name A description, providing information about

the processor, storage capacity, memory capacity, or any other information about the capabilities of the device.

A list of the processes and threads that execute on the processor. This list may also enumerate the software components that execute within each process.

A list of the deployment units that will be installed on the node.

node

Devices Physical devices, having no processing capability (at the modeled level of abstraction), that support the processor nodes. Devices may have the following properties:

Name A description, providing information about

the capabilities of the device.Connectors Connections between nodes, and between nodes and

devices. Connectors may have associated information regarding the capacity or bandwidth of the connector.

association, possibly stereotyped, to model different kinds of connectors, for example.

Diagrams The diagrams in the model, owned by the packages

Timing

Inception Phase

In the inception phase, the model will be produced at a conceptual level - if the deployment environment does not already exist - as part of architectural synthesis, when the software architect is trying to identify at least one viable architecture that will meet requirements - particularly non-functional requirements. The Project Manager will also use the Deployment Model in estimating costs for the Business Case.

However, if the system will be deployed into an environment that exists already, that environment will be documented. The key elements to captured are:

The types of nodes in the system (there is no need to document the entire topology of the system; a characterization will do)

o Information about the capacity and performance of the nodeso Information about the software already running on these nodes

The configuration of the network connecting the nodes o The capacity of the connectionso The reliability of the connections

Elaboration Phase

In the elaboration phase, the Deployment Model will be refined to a specification level, allowing the software architect to predict performance with confidence, before finally taking the model to the physical level, where it specifies the actual hardware and model numbers to be used, and becomes a plan for the acquisition, installation and maintenance of the system.

If the deployment environment already exists, it will be examined to determine whether it is capable of supporting the new capabilities of the system being developed. If changes are needed to the deployment environment, these are identified in this phase.

If the deployment environment does not yet exist, the numbers, types and configurations of nodes and the connection between nodes needed to support the architecture will be defined. Key deployment aspects of the architecture are examined and addressed, including:

reliability and availability distribution of processing, capacity and performance cost ease of support and administration.

Construction Phase

The allocation of components to nodes, or deployment units to nodes, is updated if or when the components change.

If the deployment environment does not yet exist, there is typically a hardware procurement and installation effort running in parallel to the software development effort. It is recommended that commitment to final hardware purchase be delayed as long as possible, to mitigate the performance risk (that the deployed software does demonstrate acceptable capacity, response time or throughput characteristics), and to take advantage of technology and price/performance improvements. If performance issues arise during construction, the software architect ideally should have the freedom to modify the Deployment Model as well as the architecture of the software itself, when addressing these issues.

Transition Phase

The deployment environment is readied for the system to be installed. One or more test/trial deployments occur as the software undergoes one or more beta tests. The software is eventually transitioned into the deployment environment.

Associations

An association models a bi-directional semantic connection among instances

Associations represent structural relationships between objects of different classes; they represent connections between instances of two or more classes that exist for some duration. Contrast this with transient links that, for example, exist only for the duration of an operation. These latter situations can instead be modeled using collaborations, in which the links exist only in particular limited contexts.

You can use associations to show that objects know about another objects. Sometimes, objects must hold references to each other to be able to interact, for example send messages to each other; thus, in some cases associations may follow from interaction patterns in sequence diagrams or collaboration diagrams.

Aggregation

An aggregation is a special form of association that models a whole-part relationship between an aggregate (the whole) and its parts.

Aggregation is used to model a compositional relationship between model elements. There are many examples of compositional relationships: a Library contains Books, within a company Departments are made-up of Employees, a Computer is composed of a number of Devices. To model this, the aggregate (Department) has an aggregation association to the its constituent parts (Employee).

A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole)

to indicate aggregation.

Generalization

A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element, and contains

additional information. An instance of the more specific element may be used where the more general element is allowed.

Many things in real life have common properties. Both dogs and cats are animals, for example. Objects can have common properties as well, which you can clarify using a generalization between their classes. By extracting common properties into classes of their own, you will be able to change and maintain the system more easily in the future.

A generalization shows that one class inherits from another. The inheriting class is called a descendant. The class inherited from is called the ancestor. Inheritance means that the definition of the ancestor - including any properties such as attributes, relationships, or operations on its objects - is also valid for objects of the descendant. The generalization is drawn from the descendant class to its ancestor class.

Generalization can take place in several stages, which lets you model complex, multilevel inheritance hierarchies. General properties are placed in the upper part of the inheritance hierarchy, and special properties lower down. In other words, you can use generalization to model specializations of a more general

Because class stereotypes have different purposes, inheritance from one class stereotype to another does not make sense. Letting a boundary class inherit an entity class, for example, would make the boundary class into some kind of hybrid. Therefore, you should use generalizations only between classes of the same stereotype.

You can use generalization to express two relationships between classes:

Subtyping, specifying that the descendant is a subtype of the ancestor. Subtyping means that the descendant inherits the structure and behavior of the ancestor, and that the descendant is a type of the ancestor (that is, the descendant is a subtype that can fill in for all its ancestors in any situation).

Subclassing, specifying that the descendant is a subclass (but not a subtype) of the ancestor. Subclassing means that the descendant inherits the structure and behavior of the ancestor, and that the descendant is not a type of the ancestor.

Component diagram

The component diagram's main purpose is to show the structural relationships between the components of a system. In UML 2, components are considered autonomous, encapsulated units within a system or subsystem that provide one or more interfaces. Although the UML 2 specification does not strictly state it, components are larger design units that represent things that will typically be implemented using replaceable" modules. But, unlike UML 1.x, components are now strictly logical, design-time constructs. The idea is that you can easily reuse and/or substitute a different component implementation in your designs because a component encapsulates behavior and implements specified interfaces.

In component-based development (CBD), component diagrams offer architects a natural format to begin modeling a solution. Component diagrams allow an architect to verify that a system's required functionality is being implemented by components, thus ensuring that the eventual system will be acceptable.

In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. While component diagrams are generally geared towards a system's implementation staff, component diagrams can generally put stakeholders at ease because the diagram presents an early understanding of the overall system that is being built.

Developers find the component diagram useful because it provides them with a high-level, architectural view of the system that they will be building, which helps developers begin formalizing a roadmap for the implementation, and make decisions about task assignments and/or needed skill enhancements. System administrators find component diagrams useful because they get an early view of the logical software components that will be running on their systems. Although system administrators will not be able to identify the physical machines or the physical executables from the diagram, a component diagram will nevertheless be welcomed because it provides early information about the components and their relationships (which allows sys-admins to loosely plan ahead).

The notation

The component diagram notation set now makes it one of the easiest UML diagrams to draw. Figure 1 shows a simple component diagram using the former UML 1.4 notation; the example shows a relationship between two components: an Order System component that uses the Inventory System component.

Swimlane Activity diagram

A swim lane (or swimlane) is a visual element used in process flow diagrams, or flowcharts, that visually distinguishes responsibilities for sub-processes of a business process. Swim lanes may be arranged either horizontally or vertically. In the accompanying example, the swimlanes are named Customer, Sales, Contracts, Legal, and Fulfillment, and are arranged vertically.

The swim lane flowchart differs from other flowcharts in that processes and decisions are grouped visually by placing them in lanes. Parallel lines divide the chart into lanes, with one lane for each person, group or subprocess. Lanes are labelled to show how the chart is organized.

In the accompanying example, the vertical direction represents the sequence of events in the overall process, while the horizontal divisions depict what subprocess is performing that step. Arrows between the lanes represent how information or material is passed between the subprocesses.

Optionally, the flow can be rotated so that the sequence reads horizontally from left to right, with the roles involved being shown at the left edge. This can be easier to read and design, since computer screens are typically wider than they are tall, which gives an improved view of the flow. Additionally, Microsoft Visio typically displays activities horizontally from left to right.

Use of standard symbols enables clear linkage to be shown between related flow charts when charting flows with complex relationships: use of hyperlinks makes movement between activities on different sheets easy.

Swimlanes can be used in manufacturing-related applications to help clarify the overall layout of the processes and help optimize floor capacity and efficiency.

When used to diagram a business process that involves more than one department, the use of swimlanes can clarify not only the steps and who is responsible for each one, but also how delays, mistakes or cheating are most likely to occur.

Many process modeling methodologies utilize the concept of swimlanes as a mechanism to organize activities into separate visual categories in order to illustrate different functional capabilities or responsibilities. Swimlanes are used in Business Process Modeling Notation (BPMN) and Unified Modeling Language Activity diagram modeling methodologies.