16 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 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 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.