Analyzing Requirements and Defining Microsoft .NET Solution Architectures VI: Creating the Conceptual Design
The aim of this series of articles is to provide an overview of issues surrounding the architecture of .NET Solutions. In doing so it is following Microsoft’s recommended approach and, in particular, looking at the requirements of the related Microsoft certification exam (70-300), which itself is one of the requirements for the MCSD .NET qualification. The main reference for this series of articles is the Que publication: 'Exam Cram2 .NET Solution Architectures'.
We've looked at the following thus far:
Article II: started on phase 2 (gathering and analysing requirements) focussing on business requirements.
Article III: continued with phase 2, focussing on user requirements and issues surrounding globalisation and localisation of your application.
Article V: phase 3, developing specifications for the proposed system.
In this article we move onto phase 4, creating the conceptual design and introducing the use of Object Role Modelling (ORM) for this purpose. ORM attempts to illustrate a system with graphs and textual descriptions of system 'facts'.
With ORM you are documenting data, procedures and system behaviours. The output of this phase is used in modelling the system in the subsequent phases. Models to be derived from the conceptual model include an ER (Entity Relationship) database model, a hierarchical system model, a network architecture model, an object oriented application model and others.
Many of the specification elements need to be included in the ORM model at this stage. We're still conceptual here – thoughts and notions of what the system should be. You are focusing on the elements of the system, the data these elements use and the relationships between the elements.
Many forms of conceptual modelling are used in the computing industry. Data specialists usually prefer the ER modelling approach, which defines the tables, fields, and relationships found in the data store. The belief is that often you need a looser modelling tool, however, for better expressing the conceptual design elements without the rigors of the rules for data structures.
ORM attempts to make modelling the process as simple as possible, using standard language as a way of expressing data and relationships and is also a diagramming process that can be used to illustrate actual data. This has the major benefit of being able to communicate and validate the model easily with domain experts who do not need to know the detail of the modelling process as the high level result is a specification in natural language. Saying this, some expertise is required as you’ll see shortly.
Using the Conceptual Schema Design Procedure (CSDP) you begin the process by taking information from the problem statement in the form of simple facts and then attempt to show these factual elements as objects within the conceptual model.
You start by drawing up a set of facts from your previous analysis that is as complete as possible. Consider a drug prescription as an example (based on how this works in the UK). On a prescription you might have the following:
from this and related information concerning the problem domain you could derive the following facts:
each of which also has a reverse relationship
Thus you have stated the relationships between the entities.
In this step you take the facts of step 1 and draw them out in an ORM style. After preparing an initial draft you then add samples of actual data to the diagram.
Entities and data elements are represented in the ORM model as ellipses connected by subtype relational lines and predicate rectangles.
With the double ended arrows on the diagram indicating a uniqueness constraint and the dots on the connecting lines indicatory mandatory roles. So, for example, a Prescription is 1:1 with Patient and both are mandatory.
Currently the model depicts entities, values and the interaction between them. You must identify the primitive entity types in the conceptual model. You're looking at entities that should be combined or those that can be derived through the use of arithmetic expressions. For our simple example there are none.
The final four sub-steps in ORM conceptual design all deal with designing model constraints of the following types:
uniqueness: entries connected with these types of constraints in one or more roles occur only once. Uniqueness is accompanied by arity of the fact types. For example taking a typical purchasing example, an order can have many order lines.
mandatory role: what is optional and what is required; also the cardinality of these relationships, e.g. a mandatory 1:1 mapping of entity type to value type. Note that if two or more roles are connected to a circled dot an ‘or’ condition is in force; similarly a circled dot with a cross through it represents an exclusive-OR (XOR). By a combination of uniqueness/ arity and defining what is mandatory (arrows and dots in the diagram) you can model the full range of relationships from 1:1 with both mandatory to M:N with both optional.
At this stage you also check for logical derivations – can represented facts be derived from others? This mechanism is used to extend the model.
More definite constraints are then considered:
value: permitted values for an entity's data.
set-comparison: specifies a subset, an equality or an exclusion applied between compatible roles. This is used to identify subtypes and supertypes within the system
These are simply annotations to the entities of the model.
ring: this last set of constraints complete a final set of validations of your model. Ring constraints in the system are put in place to mandate or prevent cyclical situations. They are not common. Saying that we have one in our system – Doctor's should not prescribe drugs to themselves. They are added with the same diagrammatic tools we have seen so far (though this is complicated/ simplified depending on your point of view in ORM2!). Ring constraints can be reflexive, symmetric, transitive, irreflexive, asymmetric, antisymmetric, and/or intransitive. A doctor cannot prescribe to himself/ herself so the constraint is irreflexive.
A final check is then undertaken comparing the ORM against all known information derived from the case study. You can then proceed to consider the database system that will be used, with the major entities becoming tables. Most constraints will transfer directly to DBMS equivalents. Some will need to be coded in stored procedures /similar.
ORM is used as a method to draw out the data and represent the system to gain a better understanding of interactions between system elements. This has been a whistle stop, fairly superficial tour but see the references if your interest has been piqued!
Exam Cram 2 .NET Solution Architectures Cornish et al. Que
http://msdn.microsoft.com/architecture/
Object Role Modeling (ORM) .NET Show http://msdn.microsoft.com/theshow/Episode025/default.asp
http://www.orm.net See in particular a consideration of UML from the ORM perspective.
http://objectrolemodeling.com
Professional UML with VS.NET Wrox Filev et al.
Building a better data model http://www.tdan.com/i007fe04.htm Scot A. Becker