# Qualified

• UML: Basic Diagram Types

• UML: Use Case Diagram (Essentials)

• UML: Class Diagram (Essentials)

• Entity Relationship Diagrams

• Data Flow Diagrams

---

# UML: Basic Diagram Types

Structure Diagrams

• Class Diagram
• Component Diagram
• Deployment Diagram
• Object Diagram
• Package Diagram
• Profile Diagram
• Composite Structure Diagram

Behavioral Diagrams

• Use Case Diagram
• Activity Diagram
• State Machine Diagram
• Sequence Diagram
• Communication Diagram
• Interaction Overview Diagram
• Timing Diagram

---

# UML: Use Case Diagram (Essentials)

Use cases are a technique for capturing the functional requirements of a system. Use cases work by describing the typical interactions between the users of a system and the system itself, providing a narrative of how a system is used.

A use case is a set of scenarios tied together by a common user goal.

In use case–speak, the users are referred to as actors. An actor is a role that a user plays with respect to the system. Actors might include customer, customer service rep, sales manager, and product analyst

---

# UML: Class Diagram (Essentials)

ERD shows logical structure of database.

The boxes in the diagram are classes, which are divided into three compartments: the name of the class (in bold), its attributes, and its operations. also shows two kinds of relationships between classes: associations and generalizations.

More specifically, each class has 3 fields: the class name at the top, the class attributes right below the name, the class operations/behaviors at the bottom.

• Properties: represent structural features of a class. As a first approximation, you can think of properties as corresponding to fields in a class.

• Attributes: the attribute notation describes a property as a line of text within the class box itself.

  • visibility name: type multiplicity = default {property-string}
  • example: - name: String [1] = "Untitled" {readOnly}
    • this visibility marker indicates whether the attribute is public (+) or private (-)
    • the name of the attribute—how the class refers to the attribute — roughly corresponds to the name of a field in a programming language.
    • the type of the attribute indicates a restriction on what kind of object may be placed in the attribute. You can think of this as the type of a field in a programming language.
    • the default value is the value for a newly created object if the attribute isn't specified during creation
    • the {property-string} allows you to indicate additional properties for the attribute. In the example, I used {readOnly} to indicate that clients may not modify the property.

• Associations

  • The other way to notate a property is as an association. Much of the same information that you can show on an attribute appears on an association. This is the same properties represented in the two different notations.

  

  • an association is a solid line between two classes, directed from the source class to the target class. The name of the property goes at the target end of the association, together with its multiplicity. The target end of the association links to the class that is the type of the property.

---

# Entity Relationship Diagrams

An entity relationship diagram (ERD) shows the relationships of entity sets stored in a database. An entity in this context is an object, a component of data. An entity set is a collection of similar entities. These entities can have attributes that define its properties. 
By defining the entities, their attributes, and showing the relationships between them, an ER diagram illustrates the logical structure of databases.

ER diagrams are used to sketch out the design of a database.

• Entities, which are represented by rectangles.
• Weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone (rectangle with double border)
• Actions, which are represented by diamond shapes, show how two entities share information in the database.
• Attributes, which are represented by ovals. A key attribute is the unique, distinguishing characteristic of the entity.
• Connecting lines, solid lines that connect attributes to show the relationships of entities in the diagram.
• Cardinality specifies how many instances of an entity relate to one instance of another entity. Ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.

---

# Data Flow Diagrams

There are essentially two different types of notations for data flow diagrams (Yourdon & Coad or Gane & Sarson) defining different visual representations for processes, data stores, data flow and external entities.

Yourdon and Coad type data flow diagrams are usually used for system analysis and design, while Gane and Sarson type DFDs are more common for visualizing information systems.

Visually, the biggest difference between the two ways of drawing data flow diagrams is how processes look. In the Yourdon and Coad way, processes are depicted as circles, while in the Gane and Sarson diagram the processes are squares with rounded corners.

Process Notations. A process transforms incoming data flow into outgoing data flow.

Datastore Notations. Datastores are repositories of data in the system. They are sometimes also referred to as files.

Dataflow Notations. Dataflows are pipelines through which packets of information flow. Label the arrows with the name of the data that moves through it.

External Entity Notations. External entities are objects outside the system, with which the system communicates. External entities are sources and destinations of the system's inputs and outputs.

---

# Data Flow Diagram Levels

• Context Diagram. A context diagram is a top level (also known as "Level 0") data flow diagram. It only contains one process node ("Process 0") that generalizes the function of the entire system in relationship to external entities.

• DFD Layers. Draw data flow diagrams can be made in several nested layers. A single process node on a high level diagram can be expanded to show a more detailed data flow diagram. Draw the context diagram first, followed by various layers of data flow diagrams.

• DFD Levels. The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until you reach pseudo code.