Difference between revisions of "ORM"
Jump to navigation
Jump to search
(Conceptual schema design) |
(→Conceptual schema design: added notes from draft message) |
||
Line 33: | Line 33: | ||
#Add value, set comparison and subtyping constraints. | #Add value, set comparison and subtyping constraints. | ||
#Add other constraints and perform final checks. | #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: | |||
#Collect samples of: | |||
#*use case processes; | |||
#*reports; | |||
#*input forms; and | |||
#*queries | |||
#To create the domain model from the data use case | |||
##Verbalize the data in natural language. | |||
##Populate the model with positive and negative examples. | |||
##Rephrase this as unambiguous, elementary facts. | |||
##Add and validate the business rules constraining the data. | |||
==Agile Modelling== | ==Agile Modelling== |
Revision as of 15:10, 18 April 2012
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.
- 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.
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:
- Collect samples of:
- use case processes;
- reports;
- input forms; and
- queries
- To create the domain model from the data use case
- Verbalize the data in natural language.
- Populate the model with positive and negative examples.
- Rephrase this as unambiguous, elementary facts.
- 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
- Define Product Vision
- Define and describe Roles
- Write scenarios for roles (a day in the life of, kruip in de huid van)
- Highlight all nouns (== entities or objects in ORM) and verbs (actions users perform on objects).
- Distill user stories, each user story has one or more objects and at least one verb. Stories with two objects denote relationships.