iterative-software-design-skills

Improves internal code and design through risk-calibrated, verified transformations without intentionally changing observable behavior. Use when removing duplication, shortening or clarifying code, improving names, cohesion, coupling, responsibilities, or dependency structure behind adequate tests and other mechanical checks.

Applies object design patterns judiciously. Use when creation, adaptation, algorithm variation, part-whole structure, event notification, or family-of-products variation creates design pressure.

Builds conceptual domain models from requirements. Use when discovering business concepts, associations, attributes, vocabulary, and domain rules before software class or database design.

Assigns object responsibilities with GRASP. Use when deciding which object should create, know, coordinate, vary, mediate, or protect behavior in an object-oriented design.

Guides the Unified Process inception phase. Use when establishing a project's high-level vision, feasibility, business case, basic scope, key risks, and defining iteration plans to transition to elaboration.

Guides iterative Unified Process-style analysis and design. Use when planning requirements-to-design work across inception, elaboration, construction, risks, durable artifacts, repository layouts, and incremental refinement.

Specifies system operation effects. Use when a system operation has non-trivial state changes, business rules, created objects, associations, or postconditions that use-case text does not capture precisely.

Adapts GRASP responsibilities, use-case realizations, design patterns, and UML to idiomatic Rust, Python, TypeScript, C#, or C++. Use when implementation-facing design must be mapped to one of these languages.

Creates system sequence diagrams from use-case scenarios. Use when identifying system events, system operations, actor-system boundaries, or operation names before object design.

Implements scoped behavior through risk-calibrated, test-first verification. Use when adding or changing production behavior from use cases, operation contracts, use-case realizations, design classes, acceptance examples, or bug reports and executable examples, properties, invariants, or other mechanical checks can anchor the implementation.

Produces UML design class diagrams from object design work. Use when summarizing software classes, methods, attributes, associations, visibility, packages, and navigability after use-case realization.

Guides black-box use-case modeling for requirements discovery. Use when identifying actors, user goals, functional requirements, system scope, or scenario flows before design or implementation.

Designs object collaborations for use-case scenarios. Use when translating SSD operations and contracts into sequence or communication diagrams with controllers, domain objects, and services.