Date post: | 24-Dec-2015 |
Category: |
Documents |
Upload: | nancy-foster |
View: | 233 times |
Download: | 5 times |
The Unified Modeling Language (UML)
Class Diagrams
Unified Modeling Language
• A standardized modeling language for the conceptualization and design of software systems
• Two types of diagrams: structure diagram and behavior diagram
• There are a lot of diagram types in the UML (14 types!) but we will focus only on a few in this class
Common Structure Diagrams
• Class Diagram– Illustrates classes, with attributes and methods, along with their
relationships– We will focus primarily on class diagrams, since they are by far the
most commonly used• Component Diagram
– Illustrates how components (each with an API or similar connecting interface) interfaces with other components
• Object Diagram– Illustrates the objects instantiated in a system at a single point in time
• Package Diagram– Illustrates the packages in a system and their dependencies
Common Behavior Diagrams
• Activity Diagram– A “flow chart” of sorts
• Interaction Diagram– The message sequence chart is one type of
interaction diagram• Use Case Diagram– Represents dependencies among use cases
• State Machine Diagram– Displays states and transitions
UML Diagrams are related
• Each diagram is a different view of a system
These classes belong to those packages.
A Class
Class/Object Name
Attributes
Methods/Operations
• A class name should be descriptive (Italic if abstract)• The attributes of a class defines its properties, what data the
class stores• The methods/operations of a class specify what the class does
Visibility of Attributes and Methods
Associations
Specific Associations: Aggregate
• Aggregations – “has a” relationships– A class is a container of other classes– Does not imply ownership, (ie. when the “parent”
gets destroyed, the aggregates do not)– Ex: A magazine has articles, but if the magazine
goes out of business, the articles don’t necessarily disappear (they may live on as part of another publication)
Specific Associations: Composite• Composition – combining simple objects into
a more complex whole– Can have multiple objects composed into one– Implies an “owns a” relationship– If the parent is destroyed, all its composites are
typically destroyed– Ex: If we delete the article we no longer care
about Facebook comments on the article
Difference between Composition and Aggregation
• Composition:– Composed of multiple parts– Parts have no independent existence– The structured whole makes the object
• Aggregation:– Does not imply ownership– Parts have independent existence– May be called a composition if the distinction is
not important
Generalization/Specialization
Generalization:“a parent”
Specialization:“a child”, inherits from a general class
Realization (Implementation)
• Relationship where one class (the client) implements another (the supplier)
• Represented with a dashed line from the implemented class to the implementation
Dependencies• A “using” relationship specifying that a change in the
specification of one thing may affect another thing that uses it
• Common when the client class:– Uses a supplier class that has global scope– Uses a supplier class as a parameter– Uses a supplier class as a local variable– Sends a message to the supplier
UML Examples
• This level of detail is usually reserved for the Design and Implementation phases– Deliverable 3: design– Deliverable 4: implementation
• You will not need to add all of these details in your Deliverables 2 or 3
Source: bigelow.ch
Combinations of UML Diagrams
• A class might have behavior attached to it• Behavior specified usually through a UML
activity diagram or a UML state diagram