ORM

Correct, Consistent, Complete, Clear

Goal of the conceptual model is to be Correct, Consistent, Complete, Clear:

• Correct—because errors are eliminated by means of the structured protocol and the validation steps, as well as the quality checks by the use of concrete business examples
• Consistent—because inconsistencies are eliminated through the structured and integrated protocol.
• Complete—processes, data, business rules and semantics are at all times in sync because by using the protocol, the business analyst discovers all the relevant knowledge in the selected knowledge domain.
• Clear—because for communication with the business, (structured) natural language and real life examples are used and stakeholder-dependent languages for the different stakeholders are derived

Sources

• http://www.orm.net/pdf/orm-jcm4.pdf
• http://www.orm.net/pdf/orm-jcm5.pdf
• http://www.orm.net/pdf/orm-jcm6.pdf
• http://www.orm.net/pdf/orm-jcm7.pdf
• http://www.orm.net/pdf/orm-jcm8.pdf
• http://www.orm.net/pdf/orm-jcm9.pdf

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

• See Martien's copy of ORM_Presentation_by_Terry_Halpin.pdf Object-Role Modeling An Overview including Temporal Aspects, Terry Halpin.
• Business Rule Modality
• Business Rule Verbalization
• Temporal Modeling and ORM
• http://starlab.vub.ac.be/website/files/Infosys%20Ch1.pdf
• http://www.orm.net/pdf/springer.pdf
• http://www.orm.net/pdf/orm-emm98.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.

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.

For existing application:

• reverse engineer the existing models into a conceptual model; and
• refine the model to fit business needs.

To create a domain model:

1. Collect samples of:
   • use case processes;
   • reports;
   • input forms; and
   • queries
2. To create the domain model from the data use case
   1. Verbalize the data in natural language.
   2. Populate the model with positive and negative examples.
   3. Rephrase this as unambiguous, elementary facts.
   4. Add and validate the business rules constraining the data.

Agile Modelling

• http://www.agilemodeling.com/artifacts/ormDiagram.htm
• http://www.flexiblesoftwaresolutions.co.uk/content/capturing-software-requirements-user-stories-user-interface-and-entities-agile-approach

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.