From HaFrWiki
Jump to: navigation, search
Classification of UML 2.5 Diagrams


UML 2 defines thirteen basic diagram types, divided into two general sets:

Structural Modeling Diagrams

Structure diagrams define the static architecture of a model.
They are used to model the 'things' that make up a model - the classes, objects, interfaces and physical components.
In addition, they are used to model the relationships and dependencies between elements.

  • Package diagrams are used to divide the model into logical containers, or 'packages', and describe the interactions between them at a high level.
  • Class or Structural diagrams define the basic building blocks of a model: the types, classes and general materials used to construct a full model.
  • Object diagrams show how instances of structural elements are related and used at run-time.
  • Composite Structure diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships.
  • Component diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface.
  • Deployment diagrams show the physical disposition of significant artifacts within a real-world setting.
  • Profile diagrams provide a visual way of defining light-weight extensions to the UML specification. UML Profiles are often used to define a group of constructs with domain-specific or platform-specific properties and constraints, which extend the underlying UML elements.

Behavioral Modeling Diagrams

Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time; tracking how the system will act in a real-world environment, and observing the effects of an operation or event, including its results.

  • Use Case diagrams are used to model user/system interactions. They define behavior, requirements and constraints in the form of scripts or scenarios.
  • Activity diagrams have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process.
  • State Machine diagrams are essential to understanding the instant to instant condition, or "run state" of a model when it executes.
  • Communication diagrams show the network, and sequence, of messages or communications between objects at run-time, during a collaboration instance.
  • Sequence diagrams are closely related to communication diagrams and show the sequence of messages passed between objects using a vertical timeline.
  • Timing diagrams fuse sequence and state diagrams to provide a view of an object's state over time, and messages which modify that state.
  • Interaction Overview diagrams fuse activity and sequence diagrams to allow interaction fragments to be easily combined with decision points and flows.

How to use UML?

An example process might look something like the following:

  1. Capture a Business Process Model. This will be used to define the high level business activities and processes that occur in an organization and to provide a foundation for the Use Case model. The Business Process Model will typically capture more than a software system will implement (ie. it includes manual and other processes).
  2. Map a Use Case Model to the Business Process Model to define exactly what functionality you are intending to provide from the business user perspective. As each Use Case is added, create a traceable link from the appropriate business processes to the Use Case (ie. a realisation connection). This mapping clearly states what functionality the new system will provide to meet the business requirements outlined in the process model. It also ensures no Use Cases exist without a purpose.
  3. Refine the Use Cases - include requirements, constraints, complexity rating, notes and scenarios. This information unambiguously describes what the Use Case does, how it is executed and the constraints on its execution. Make sure the Use Case still meets the business process requirements. Include the definition of system tests for each use case to define the aceptance criteria for each use case. Also include some user acceptance test scripts to define how the user will test this functionality and what the acceptance criteria are.
  4. From the inputs and outputs of the Business Process Model and the details of the use cases, begin to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models. These describe the 'things' in the new system, the way those things interact and the interface a user will use to execute use case scenarios.
  5. From the domain model, the user interface model and the scenario diagrams create the Class Model. This is a precise specification of the objects in the system, their data or attributes and their behaviour or operations. Domain objects may be abstracted into class hierarchies using inheritance. Scenario diagram messages will typically map to class operations. If an existing framework or design pattern is to be used, it may be possible to import existing model elements for use in the new system. For each class define unit tests and integration tests to thoroughly test i) that the class functions as specified internally and that ii) the class interacts with other related classes and components as expected.
  6. As the Class Model develops it may be broken into discrete packages and components. A component represents a deployable chunk of software that collects the behaviour and data of one or more classes and exposes a strict interface to other consumers of its services. So from the Class Model a Component Model is built to define the logical packaging of classes. For each component define integration tests to confirm that the component's interface meets the specifcation given it in relation to other software elements.
  7. Concurrent with the work you have already done, additional requirements should have been captured and documented. For example - Non Functional requirements, Performance requirements, Security requirements, responsibilities, release plans & etc. Collect these within the model and keep up to date as the model matures.
  8. The Deployment model defines the physical architecture of the system. This work can be begun early to capture the physical deployment characteristics - what hardware, operating systems, network capabilities, interfaces and support software will make up the new system, where it will be deployed and what parameters apply to disaster recovery, reliability, back-ups and support. As the model develops the physical architecture will be updated to reflect the actual system being proposed.
  9. Build the system: Take discrete pieces of the model and assign to one or more developers. In a Use Case driven build this will mean assigning a Use Case to the development team, having them build the screens, business objects, database tables, and related components necessary to execute that Use Case. As each Use Case is built it should be accompanied by completed unit, integration and system tests. A Component driven build may see discrete software components assigned to development teams for construction.
  10. Track defects that emerge in the testing phases against the related model elements - eg. System test defects against Use Cases, Unit Test defects against classes & etc. Track any changes against the related model elements to manage 'scope creep'.
  11. Update and refine the model as work proceeds - always assessing the impact of changes and model refinements on later work. Use an iterative approach to work through the design in discrete chunks, always assessing the current build, the forward requirements and any discoveries that come to light during development.
  12. Deliver the complete and tested software into a test then production environment. If a phased delivery is being undertaken, then this migration of built sofware from test to production may occur several times over the life of the project.

See also