Seldom does a software project of any size get built by only one person. Most often many different people, with different skills work together to build the solution. It is not uncommon to have the technology not be the most challenging part of the project, but rather it is often the lack of clear communication between the project team members. The Unified Modeling Language (UML) helps the team members to communicate clearly and precisely. The UML includes several diagrams and models that support the design of different aspects of the solution. If each member of the team is able to understand those models that are useful to them they are more likely to understand each other, and the challenges and risks of different understandings and views of the solution are minimized. In this course we review the need for this clear communication. We discuss several of the common diagrams that teams use to model a software solution and identify some of the team members that most commonly use the diagram. The UML is very large and there is much that can be done with it beyond what is covered in this introductory course. But having this basic understanding of the common models can reduce many of the challenges faced by project teams.
Mike is a developer, architect and trainer and has worked with many different tools and technologies for over 20 years. When not working on, learning or sharing something to do with technology he enjoys spending time with his family, especially camping and traveling.
History, Need and Tools Hi, this is Mike Erickson with Pluralsight. Welcome to my course, Introduction to UML. There are four modules in this course; the first module is an introduction. In the introduction we'll talk a little bit about the history of UML, some of the tools that are used, and why having UML, having a common language, is so important. In the second module we'll look at some of the basics of UML. We'll talk about the classifications of models, structural and behavioral modeling. We'll talk about some the basic constricts that are used to cross many of the models and prepare ourselves to move into module 3 where we'll focus on structural modeling. In the structural modeling module, we will look at some of the diagrams that are commonly used and then discuss how to create them and how to read them and how they are important and useful in designing software. Finally in module four, we'll do the same kind of thing with behavioral modeling. We'll look at a few of the models that are commonly used and understand why they're important, how to read them, how to create them. So in module 1 here, we'll start with a brief look at the history of UML, we'll talk about the importance of having a common language that everybody on the team can understand and allows us to communicate clearly with each other. Finally, we'll take a real quick look at some of the options you have with tools and what you can use to create these models.
UML Basics Hi, this is Mike Erickson with Pluralsight. Welcome to the second module in my Introduction to UML course. In this module we're going to talk about some of The Basics of UML. We're going to start off by talking about two types of modeling that we do - structural modeling and behavioral modeling. We'll then move on and talk about some of the basic building blocks of UML, some of the common elements that are found in many of the different diagrams that we build with UML. Having an understanding of these common elements will help us as we move into the next two modules, where we're going to be focusing on diagrams themselves, we'll be able to better understand how to read diagrams, and how to put them together, how to build our own diagrams. Next we'll talk about some common extensions, things that are a little beyond the basics of the building blocks, things that can help make our diagrams both easier for us to explain what we want to do and others to understand what it is our diagrams are saying. We'll end this module by talking about some key considerations that we should keep in mind, especially as we create UML diagrams, to help make them as useful and understandable to people that will be consuming the documents we create.
Structural Diagrams Hi, this is Mike Erickson with Pluralsight. Welcome to module 3 of my course, Introduction to UML. This module will focus on Structural Diagrams within the UML. So the first thing we will talk about is what are Structural Diagrams, why are they important, what do they do as far as our modeling of the system? Then we'll look at four specific Structural Diagrams that are commonly used when modeling systems. First, we'll look at Class Diagrams, then Component Diagrams, then we'll move on and talk about Package Diagrams, and we'll finish this module by talking about Deployment Diagrams. Structural Diagrams help us define the overall structure or architecture of our system, much like a blueprint defines what a house looks like. The Structural Diagrams model or define what our system will look like architecturally. They help us define the vocabulary of the system, ensure that the different project stakeholders understand each other in talking about things within the system. They identify different relationships between parts of the system and they help us define the entire architecture of the system. Sometimes people refer to Architectural Diagrams. I have combined them together into this module, Structural Diagrams in particular our final discussion, Deployment Diagrams, you might hear some people talk about those as Architectural Diagrams. We will define them and group them into the Structural Diagrams in this course.
Behavioral Diagrams Hi this is Mike Erickson with Pluralsight. Welcome to this fourth and final module in my Introduction to UML course. In this module, we'll be discussing Behavioral Diagrams. The first thing we will talk about in this module is, what are Behavioral Diagrams. In general, what do they do for us and why are they important and useful? Then we'll start talking about some specific Behavioral Diagrams. First, we'll talk about Use Case Diagrams. Use Case Diagrams help us to document the functionality that is required by our system. Then we'll talk about Sequence Diagrams. Sequence Diagrams help us document how the features that are identified are implemented, specifically in a time ordering sequence of interactions. Then we'll talk about State Diagrams. State Diagrams help us to identify the transitions that are possible and the states that are allowed in our objects within our system. Finally, we'll talk about Activity Diagrams. Activity Diagrams also help us map out the flow of operations in our system, very much like flowcharts have done for years, but Activity Diagrams do have some enhancements beyond flowcharts. So let's start by just talking a little bit about Behavioral Diagrams. We talked in the last module about Structural Diagrams and we know that Structural Diagrams identify the things that make up our system. Behavioral Diagrams identify how those things interact with each other to give us the features and the functionality that our system requires. So we're going to be looking more at operations, more at verbs, more at actions than at nouns, entities, and things.