Atomic Goal

A term from both logic solvers such as PrologLanguage, and UseCase theory.

An "AtomicGoal" cannot divide into smaller things that are goals. "Take money from an ATM" is a non-Atomic UseCase, but "authenticate my ATM card" is. There is no subset of "authentication" that makes sense to perform alone.

From the OTUG mailing list:

I am an OO fanatic and the words "top-down functional decomposition" make my toes curl :-) -- SergeBeaumont

Then you are too much of a fanatic. TopDown FunctionalDecomposition is precisely what we do when creating use cases. Use cases represent a functional decomposition of the ProblemDomain. Fortunately, we do not use this structure as the architecture for the software. We only use it to serve as a description of the problem. -- RobertCecilMartin

Interesting topic. I once told someone that use-cases are "top functional decomposition" rather than "top-down functional decomposition." Use cases are concerned with intention at the SystemBorder?s and they reflect the realization that all systems must interact with their environment to be useful. In a very loose sense, they are the SequenceDiagrams of a DomainModel in which the system and the actors are objects. -- MichaelFeathers

I'd agree: the UseCase point of view is more like the programming-in-the-small point of view that enshrined the StepwiseRefinement ideas of Wirth and Dykstra: identify a more or less AtomicGoal you want to achieve, and then break out the steps required to accomplish it, until the steps pretty much correspond to the abstraction level of your implementation technology.

This approach is only remotely related to the early notions of large scale system-level HierarchicFunctionalDecomposition?, as used in HIPO, StructuredAnalysis?, InformationEngineering, and many other methodologies. This point of view proved to be of limited use and led to adoption of essential analysis, sometimes called an "OutsideIn?" approach. Use case modeling recapitulates EssentialAnalysis? in most respects.

-- BobBinder

I'd categorize InformationEngineering as bottom-up, rather than top-down. InformationEngineering, as I understand the approach, is about defining coherent contexts within which lowest level data operations occur. Typically, this involves defining coherent states for entities, identifying legitimate transitions between those states with the events that trigger those transitions, and defining the process for achieving each transition. A consequence of this approach is that dependencies between entities need to be taken into account, so "processes" become increasingly transactional in nature, with events being linked in hierarchies to higher level "real-world" events. An initial event hierarchy might be prepared top-down, beginning with "real-world" events that impinge upon the system. And initial entity modelling might also be top-down. But these are just ways of identifying the subject-matter of the bottom-up InformationEngineering itself.

Then again, I'd argue that UseCases are more outside-in than top-down. You do not have high-level UseCases composed of lower level UseCases, in the way that true FunctionalDecomposition delivers lower level functions within higher level functions (for good or ill). UseCases are fundamentally flat, whereas FunctionalDecompositions, whether top-down, bottom-up or middle-up-and-down, are fundamentally layered, each layer providing a complete abstraction of the one below.

The above thread discusses using UseCases as a way to ratify a design. The AGs within a UC drive the process of reviewing designs.