20 skills.
Use when asked to model a workflow or business process as a UML activity diagram — activities, transitions, decisions, and swimlanes — as distinct from a state diagram (see state-diagram), which models one object's states rather than a flow of actions. See plantuml for the text-based syntax to actually draw one.
Use when asked to run a root-cause analysis session using a fishbone/Ishikawa-style diagram — the 6M cause categories (Manpower, Methods, Machines, Materials, Measurements, Mother Nature) — the same technique also called fishbone-diagram or ishikawa-diagram under alternate names.
Use when asked to model a system's static structure as a UML class diagram — classes, attributes, methods, and association/aggregation/composition relationships — as the type-level counterpart to an object diagram's instance snapshot (see object-diagram). See plantuml for the text-based syntax to actually draw one.
Use when asked to model a system's software architecture as interacting components — dependency, association, aggregation, composition between components — as distinct from a deployment diagram's runtime hardware/node view (see deployment-diagram), which shows where components run rather than how they relate to each other.
Use when asked to model the physical/runtime architecture of a distributed system — nodes, components, artifacts — as the runtime-placement counterpart to a component diagram's logical software relationships (see component-diagram). See plantuml for the text-based syntax to actually draw one.
Use when asked to model a database's data structure as an entity-relationship diagram (ERD) — entities, attributes, and one-to-one/one-to-many/many-to-many relationships — as the data-modeling counterpart to a class diagram's object-oriented structure (see class-diagram).
Use when asked about a "fishbone diagram" for root-cause analysis — the same technique as a cause-and-effect diagram (see cause-and-effect-diagram), named for its fish-skeleton shape, also called an Ishikawa diagram (see ishikawa-diagram).
Use when asked to build a Gantt chart — a horizontal bar chart showing a project's tasks against a timeline, with dependencies and overlap — for a project with real sequencing between tasks, as distinct from a kanban board (see below), which tracks work status rather than a fixed timeline.
Use when asked about an "Ishikawa diagram" for root-cause analysis — the same technique as a cause-and-effect diagram (see cause-and-effect-diagram), named after its creator Kaoru Ishikawa, also called a fishbone diagram (see fishbone-diagram).
Use when asked to write Mermaid.js diagram syntax — flowcharts, sequence diagrams, Gantt charts, class diagrams, state diagrams, pie charts — a browser-based, Markdown-like alternative to plantuml-diagram, and natively supported inside Markdown on many platforms (GitHub, GitLab, and this environment's own Artifacts).
Use when asked to model a snapshot of specific object instances and their relationships at one point in time — association, aggregation, composition — as the instance-level counterpart to a class diagram's type-level structure (see class-diagram). See plantuml for the text-based syntax to actually draw one.
Use when asked to model the high-level organization of a system into packages/modules and their dependencies — as the highest-abstraction structural UML diagram, sitting above class diagrams (see class-diagram) rather than showing individual classes. See plantuml for the text-based syntax to actually draw one.
Use when asked to write PlantUML diagram source — sequence, class, ERD, activity, state, Gantt, C4, ArchiMate, mind map, WBS, or JSON/YAML visualization diagrams — grounded in joelparkerhenderson/plantuml-examples.
Use when asked to model interactions between objects/components over time as a UML sequence diagram — lifelines, messages, activation bars, combined fragments — as distinct from a use case diagram's user-perspective functionality view (see use-case-diagram). See plantuml for the text-based syntax to actually draw one.
Use when asked to model an object's or system's states and transitions over time — states, events, actions, guards — as distinct from an activity diagram's sequence-of-actions view (see activity-diagram), which models a workflow rather than one object's possible states.
Use when asked to build a swimlane diagram (also called a cross-functional flowchart) — a process-flow diagram that groups steps into lanes by who or what performs them — as distinct from a plain activity-diagram or flowchart (see below), which shows the sequence of steps without making the responsible party or the handoffs between them explicit.
Use when asked to visualize the timing and duration of signals or events over time — horizontal time axis, per-signal lanes — common in digital electronics, communication protocols, and concurrent software behavior, as distinct from a sequence diagram's message-order-without-precise-timing view (see sequence-diagram).
Use when asked to model system functionality from a user's perspective as a UML use case diagram — actors, use cases, association/extend/include relationships — as distinct from a sequence diagram's message-level interaction view (see sequence-diagram). See plantuml for the text-based syntax to actually draw one.
Use when asked to build a value stream map — a lean process-analysis diagram tracing material and information flow through a process, distinguishing value-adding steps from waste and quantifying time — as distinct from a plain swimlane-diagram (see below), which shows who does what without that waste analysis.
Use when asked to build a Wardley map — a strategy map plotting a value chain's components against their evolution from genesis through custom-built and product to commodity — as distinct from a business-model-canvas (see below), which is a static snapshot rather than a map of how components change position over time.