Software

Software consists of instructions and associated data used by a computer. A spreadsheet is software that stores spreadsheet cells and evaluates their spreadsheet formulas.

A modeling language for describing software structures and behavior. A class diagram records types and relationships; a sequence diagram records ordered interactions; a state diagram records states and event-triggered transitions.

Describe the possible states of a system and transitions triggered by events, optionally constrained by guards and accompanied by actions. The diagram emphasizes a component's lifecycle and permitted reactions. It can describe many interaction traces, while a sequence diagram focuses on the temporal ordering of messages in an interaction.

Describe an interaction through participant lifelines and ordered messages. Time usually proceeds downward. Calls, replies and execution intervals show how participants cooperate in one scenario, with optional fragments for alternatives or repetition. The diagram emphasizes message ordering across participants.

A structural diagram showing software classes or object interfaces, their attributes and operations, and relationships such as class inheritance and associations. A hollow triangle points toward a more general classifier; a dashed realization line distinguishes implementation of an interface. A plain association does not assert exclusive lifetime ownership of the referenced object.

A strong whole-part relationship in a UML class diagram, conventionally marked by a filled diamond at the whole. It expresses exclusive composite ownership and associated lifetime constraints. A stored reference or observer-registration association alone does not establish composition: the same observer may be registered with several subjects unless the design forbids it.

The organization of a software system's major components, their responsibilities and their interactions. A software architecture constrains which components own state and which may request or observe changes. Model-view-controller is one example for interactive applications.

Separate an application's domain state and rules into a model, its presentation into a view, and interpretation of user actions into a controller. The controller requests model operations; the view renders coherent model state. A playlist model, for example, owns song order independently of whether a menu, button or keyboard action requests a move. The Observer pattern often carries model-change notifications to views, but model-view-controller defines responsibilities rather than requiring a particular notification mechanism. This supports separation of concerns and testing domain logic independently of a graphical interface.

Assign distinct responsibilities to components with explicit interfaces, so one responsibility can change without requiring unrelated changes elsewhere. For example, a model-view-controller application separates domain state, presentation and input interpretation. The Observer pattern can communicate a coherent state change to several views while keeping concrete display details out of the model. The separation should follow actual responsibilities; multiplying classes without a clear boundary does not establish it.

Change internal software structure while preserving its specified observable behavior. Extracting a coherent operation into a named method or moving a responsibility behind an interface can improve clarity without changing results. Regression tests provide evidence of preservation, while contracts and invariants supply stronger reasoning about the changed structure.

An observable feature of source code suggesting a possible underlying design problem. It prompts investigation rather than proving a defect. Duplicate code, feature envy and a long method suggest potential transformations, and context can justify leaving an apparent smell unchanged.^[ref]

An operation depends heavily on another object's data or responsibilities. Moving the operation, or the relevant coherent part, to that object's abstraction can reduce exposed internals and misplaced coupling. The appropriate home follows responsibility and behavior, not merely the number of field references.^[ref]

A method whose size or mixture of responsibilities makes its purpose and structure difficult to follow. Extract meaningful steps with clear interfaces, preserving behavior. A fixed line-count threshold is not a proof of poor design; the useful question is whether the method hides coherent separable responsibilities.

Multiple fragments may encode the same decision or responsibility, increasing the risk that a later correction reaches only one copy. A shared operation or component can consolidate genuinely shared knowledge. Independent concepts that merely look similar should not be forced into a common abstraction prematurely.

A packaged execution environment that reduces differences in software dependencies. It does not establish that the packaged analysis is scientifically correct.

Recording and identifying changes to files so that a particular computational analysis can be linked to the code that produced it.

An implementation defect that makes a program behave contrary to its intended specification. A faithfully implemented but inappropriate scientific model is a different kind of error.

Test a conversion together with its intended inverse. Equality of representations may need normalization, while equality of numerical values can be limited by floating-point rounding or truncation. Distinct strings can encode the same value, so a value round trip and a character-for-character round trip are different properties.

An independent oracle is still needed: the wrong functions $f(x)=x+1$ and $g(y)=y-1$ satisfy both composition identities on integers, although neither implements an intended identity conversion. Thus passing inverse-consistency tests does not alone establish the specification of either conversion.

Select tests by dividing an input domain into classes expected to exercise the same relevant behavior, then choosing representatives, including boundaries. Integer-only and point-containing inputs can exercise different paths in a positional-number parser. The classes are part of the test design, not a proof that one representative detects every possible defect in its class. Invalid-format classes need an explicit validation contract before an expected rejection can be asserted.

Choose tests using knowledge of internal structure, such as branches, paths or representation cases. Covering all branches is still not generally a proof of correctness for every input. This selection criterion can be combined with specification-based tests within test-driven development.

Choose tests from externally specified input/output behaviour without using the implementation's internal control structure as the selection criterion. Boundary cases can be black-box tests when the boundary comes from the contract. Test authorship by the implementer does not alone determine this classification.

A development cycle that starts with a small expected-to-fail behavioural test, adds implementation until it passes, and refactors while preserving the tests. Its workflow is distinct from the source of test cases: public-contract tests are black-box tests, while implementation-informed branch cases can be white-box tests. The practice does not by itself prove completeness of the test suite.

Automatically checking changes in a shared software project, commonly by running tests in a recorded environment.

Testing relations between outputs for related inputs when an exact reference answer is unavailable. The expected relation must be valid for the scientific problem.

Generating cases and checking general properties such as conservation, symmetry or bounds rather than only selected input-output pairs.

Checking whether a software change alters previously established behavior. A reference output must first be justified rather than merely copied from old software.

Testing interactions between software components, including data formats, units and ordering.

Testing a small software component against a specified expected behavior.

A software engineer and author writing about refactoring and software design. His short essay Code Smell by Martin Fowler explains the distinction between noticing a symptom and establishing the design problem behind it.

A software engineer.^[ref]