2 Excellent UML Tutorials
Here are 2 excellent and well written UML Tutorials, one
hosted by Sparxsystems.com.au (UML Tutorial), and the other by
Borland.com (Practical UML: A Hands-On Introduction for Developers).
These will give anyone unfamiliar with the UML a thorough understanding
and kick start to using this modeling language.
UML
Tutorial
The Unified Modeling Language (UML) has quickly become the de-facto standard for building Object-Oriented software. This tutorial provides a technical overview of the 13 UML. diagrams supported by Enterprise Architect.UML 2 semantics are explained in detail in the new UML 2.0 tutorial.
But first... What is UML?
The OMG specification states:
"The
Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a
software-intensive system.
The UML offers a standard way to
write a system's blueprints, including conceptual
things such
as business processes and system functions as well as concrete things
such
as programming language statements, database schemas,
and reusable software
components."
The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process.
UML defines the notation and semantics for the following domains:
| - | The User Interaction or Use Case Model - describes the boundary and interaction between the system and users. Corresponds in some respects to a requirements model. |
| - | The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done. |
| - | The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflow's the system will implement. |
| - | The Logical or Class Model - describes the classes and objects that will make up the system. |
| - | The Physical Component Model - describes the software (and sometimes hardware components) that make up the system. |
| - | The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture. |
The UML also defines extension mechanisms for extending the UML to meet specialized needs (for example Business Process Modeling extensions).
See also Business Process Modeling (pdf) .
If you have any suggestions or comments on the material here, please forward your thoughts to sparks@sparxsystems.com.au.
UML
Tutorial - Continued - Use the UML to Define and Build Systems
We have established in Part 1 that the UML is a language for specifying the artifacts and interactions of a software system. We have also seen that it deals with 6 major domains - from Use Case models, through dynamic and logical models to the final physical deployment model - and that extension mechanisms have been included to allow for specialised additions to the model notation.
So... How do you use the UML?
The UML is typically used as a part of a software development process, with the support of a suitable CASE tool, to define the requirements, the interactions and the elements of the proposed software system. The exact nature of the process depends on the development methodology used. 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. |
Note that the above process is necessarily brief in
description, leaves
much unsaid and may not be how you work or follow the process you have
adopted. It is given as an example of how the UML may be used to
support a software development project.
Practical UML: A Hands-On Introduction for Developers
by Randy MillerAbstract: This tutorial provides a quick introduction to the Unified Modeling Language™
The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML™, which stands for Unified Modeling Language™. The purpose of this course is to present important highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
- Use case diagrams
- Class diagrams
- Object diagrams
- Sequence diagrams
- Collaboration diagrams
- Statechart diagrams
- Activity diagrams
- Component diagrams
- Deployment diagrams
Some of the sections of this course contain links to pages with more detailed information. And every section has short questions. Use them to test your understanding of the section topic.
Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.
Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.
The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model. A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes.
Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state.
Classes
are the "blueprints" for objects. A class wraps attributes (data) and
behaviors (methods or functions) into a single distinct entity. Objects
are instances
of classes.
Technorati Tags: uml, uml tutorial
Popularity: 15% [?]
Related Posts:
Tags for this post>> UML