UPI Study › Courses › Software Engineering › Free lessons › Lesson 6.5 Free with a free account
Getting Started with UML: A Visual Modeling Language
Software Engineering · Chapter 6: Requirements Engineering and PrototypingSection 6.5 · lesson 42 of 1037 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Software Engineering.
Lesson complete
Earn the 3 college credits for Software Engineering
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Structuring Information: Data Modeling Basics →← Capturing Requirements Through Real-World ScenariosNext lesson: Structuring Information: Data Modeling Basics →
In this lesson
A shared visual language for describing software.
- Explain what UML is, and the problem it solves
- Describe how UML became a single, unified standard
- Distinguish structural from behavioral diagrams
- Recognize notation shared across UML diagrams
Transcript
Everything said in the video, section by section (1,007 words). Read along, or search it.
Requirements Engineering and Prototyping
Getting Started with UML
A diagram is only useful if everyone reads it the same way. This section introduces U M L, the Unified Modeling Language. It covers what U M L is, where it came from, how its diagrams are grouped, and a few notation conventions that most of them share.
The Problem
Boxes, Lines, and 2 Different Stories
A new engineer joins a team, and is handed a diagram someone sketched months ago. Boxes connected by lines, some with arrowheads, and one with a dotted line. Nobody on the team remembers exactly what the author meant by each symbol. Asked to explain it, two engineers describe two different relationships. That is exactly the problem a shared visual language was created to solve. U M L is a standardized set of diagram types and notation, for describing the structure and behavior of software. With it, a diagram means the same thing to whoever reads it, not just to whoever drew it.
What UML Is
A Notation, Not a Process
U M L gives a team a shared vocabulary for describing a system visually. It complements written requirements, because some structures and behaviors are easier to grasp in a picture than in prose. But it is worth being precise about what U M L is not. It is a notation, not a process or a method. It does not tell a team when to draw a diagram, which diagrams a project needs, or what process to follow. It simply gives an agreed way to draw a diagram, once a team has decided to draw one.
A Brief History
3 Notations Become 1
In the early nineteen nineties, several incompatible notations for object-oriented design were in use. Each had its own symbols. A diagram drawn in one was not reliably readable by someone trained in another. In the mid nineteen nineties, three of the most prominent methodologists, Grady Booch, James Rumbaugh, and Ivar Jacobson, began merging their approaches. That is why the result is called the Unified Modeling Language. It was later adopted as an industry standard by the Object Management Group, giving it recognition that no single company's notation could achieve.
Table 1
Structural and Behavioral
U M L's diagram types fall into two broad categories. Structural diagrams show what a system is made of. Its pieces, and how they are arranged, largely independent of time. Think of a building's floor plan. It shows the layout, but says nothing about what happens inside. Behavioral diagrams show what a system does. How its pieces interact, respond to events, and change over time. Think of a recorded walkthrough of someone actually using the building.
Table 2
Common Diagram Types
Here are a handful of common diagram types, by category. On the structural side, a class diagram shows the classes in a system and how they relate. A component diagram shows larger building blocks, and their dependencies. On the behavioral side, a use case diagram shows who uses a system, and for what purpose. A sequence diagram shows the order in which pieces exchange messages. And a state diagram shows how something changes between defined states. Each of these gets its own, in-depth treatment later.
Figure 3
Notation Basics
A few visual conventions recur across most U M L diagrams, and are worth recognizing on sight. A rectangle represents a discrete thing, such as a class, a component, or a participant. It can be divided into compartments, labeled sections holding its name and its details. A plain line shows a general association between two things. An open arrowhead shows the direction of a relationship. And a dashed line shows a weaker, more dependent relationship than a solid line.
Why It Helps
Readable by Strangers
Why does a shared visual language help? Because U M L is standardized, a diagram drawn by one engineer can be read correctly by another who has never spoken to them. That holds on the same team, or a different one, with no ambiguity about what a box or a line means. A diagram is itself a form of communication. A shared notation is what makes that communication reliable, across people who never coordinated on how to draw it.
Table 4
What UML Is, and Isn't
It helps to be clear about what U M L is, and what it is often mistaken for. It is a shared visual notation. It is not a development process or methodology. It communicates structure and behavior visually. It is not a replacement for written, testable requirements. Exact rules and criteria still need to be written down. And it is a family of diagram types to choose from as needed. It is not a checklist requiring every diagram for every project.
Apply It
Every Diagram, for a Small Tool
Let's apply that. A team decides to produce every available U M L diagram type for a small, simple internal tool, before writing any code. Planning time doubles, and none of the diagrams meaningfully helps construction. What went wrong? The team treated U M L as a checklist, when it is a family of diagram types to choose from. The judgment U M L calls for is simple. Pick the few diagrams that actually suit the system at hand.
Key Terms
The Vocabulary of This Section
Let's lock in the key terms. U M L is a standardized visual language, made up of a family of diagram types, for describing software structure and behavior. A structural diagram shows what a system is made of. A behavioral diagram shows what it does, and how it changes over time. Notation is the agreed set of symbols and conventions used to draw a diagram. An association is a general relationship, usually a plain line, and a compartment is a labeled section within a U M L rectangle. And the Object Management Group is the industry body that adopted U M L as a formal standard.
Key Takeaways
What to Carry Forward
To pull this together. U M L is a standardized visual language for software structure and behavior. It is a notation, not a process. It came from unifying three competing notations in the mid nineteen nineties, and the Object Management Group made it a standard. Structural diagrams show what a system is made of. Behavioral diagrams show what it does over time. Rectangles, compartments, lines, and arrowheads recur across most diagram types. And U M L complements written requirements. Teams use only the diagrams that suit their project.
About Software Engineering at UPI Study
Software Engineering (Computer Science 301) is a self-paced online course of 103 video lessons in 15 chapters, from process models and agile to requirements, design, user interfaces, reliability, security and project management. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses Every course with PRO →
Why take it here
Why students take Software Engineering with UPI Study
Where the credit goes
Universities that work with NCCRS
Software Engineering carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Getting Started with UML: A Visual Modeling Language
What is UML used for in software engineering?
Who created UML?
What is the difference between structural and behavioral UML diagrams?
Is UML a software development methodology?
About the Software Engineering course
How many college credits is Software Engineering?
How much does Software Engineering cost and what is included?
Which universities accept UPI Study credits?
How long does Software Engineering take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Software Engineering.
103 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →