Difference between revisions of "ORM"

From Pearl Language
Jump to navigation Jump to search
(Writing User Stories)
(Conceptual schema design)
Line 17: Line 17:
*http://www.orm.net/pdf/orm-emm98.pdf
*http://www.orm.net/pdf/orm-emm98.pdf
*http://www.orm.net/pdf/orm-emm99.pdf
*http://www.orm.net/pdf/orm-emm99.pdf
==Conceptual schema design==
The information systems life cycle typically involves several stages: feasibility study; requirements analysis; conceptual design of data and operations; logical design; external design; prototyping; internal design and implementation; testing and validation; and maintenance. ORM's conceptual schema design procedure focuses on the analysis and design of data.
The conceptual schema specifies the information structure of the application:
*types of fact that are of interest;
*constraints on these; and perhaps
*derivation rules for deriving some facts from others.
#Transform familiar information examples into elementary facts, and apply quality checks.
#Draw the fact types, and apply a population check.
#Check for entity types that should be combined, and note any arithmetic derivations.
#Add uniqueness constraints, and check arity of fact types.
#Add mandatory role constraints, and check for logical derivations.
#Add value, set comparison and subtyping constraints.
#Add other constraints and perform final checks.


==Agile Modelling==
==Agile Modelling==

Revision as of 08:02, 23 March 2012

Sources

Terry Halpin is very active on the topic of ORM and NIAM.

Conceptual schema design

The information systems life cycle typically involves several stages: feasibility study; requirements analysis; conceptual design of data and operations; logical design; external design; prototyping; internal design and implementation; testing and validation; and maintenance. ORM's conceptual schema design procedure focuses on the analysis and design of data.

The conceptual schema specifies the information structure of the application:

  • types of fact that are of interest;
  • constraints on these; and perhaps
  • derivation rules for deriving some facts from others.
  1. Transform familiar information examples into elementary facts, and apply quality checks.
  2. Draw the fact types, and apply a population check.
  3. Check for entity types that should be combined, and note any arithmetic derivations.
  4. Add uniqueness constraints, and check arity of fact types.
  5. Add mandatory role constraints, and check for logical derivations.
  6. Add value, set comparison and subtyping constraints.
  7. Add other constraints and perform final checks.

Agile Modelling

User Stories

User Story

  • must comply with zero or more business rules
  • list business rule
  • ask business rules to show synopsis in US (a bit like in Logo?)

Business Rule or Policy

  • is implemented by one or more User Stories
  • ask compliant user stories to list their title

Writing User Stories

  1. Define Product Vision
  2. Define and describe Roles
  3. Write scenarios for roles (a day in the life of, kruip in de huid van)
  4. Highlight all nouns (== entities or objects in ORM) and verbs (actions users perform on objects).
  5. Distill user stories, each user story has one or more objects and at least one verb. Stories with two objects denote relationships.