Bill Gibson's Blog : Modeling

Oslo CTP update; Data Modeling Design Patterns in M

Bill Gibson — Thu, 29 Jan 2009 01:59:00 GMT

As modelers, one of the things we're doing all the time is looking for patterns - trying to distinguish what in each model is truly unique to the domain from that which is more broadly applicable, and then either using or adapting existing patterns or harvesting new patterns to put in our back pocket. The January Oslo CTP update (woohoo!!) on the Oslo Dev Center includes an initial set of data modeling design patterns. These patterns, described and illustrated in M, include patterns for modeling enumerations and relationships, including closed type-based enumerations, open extent-based enumerations, and one-to-many, many-to-many and one-to-one relationships.

While this may seem like pretty basic stuff you'll likely find some or all of it useful, particularly if you're new to M and coming at it and repository modeling with an OO rather than relational mindset. The patterns all have code samples so you may find it useful to have the patterns open while you're coding.

We'll add more patterns as our experience grows and the language evolves and is more fully implemented. In the pipeline are patterns for vertical partitioning, including patterns that help when mapping a generalization hierarchy in a conceptual model to a relational design. You can see some early exploration of these kinds of patterns in the domain schemas included in the CTP.

As always, we'd love to get your feedback. If you have any comments on the patterns and the usefulness of this kind of material let us know. And if you have any broadly useful patterns in your back pocket that might map nicely into M they would be great to hear about also.

Domain Modeling

Bill Gibson — Wed, 28 Jan 2009 07:27:00 GMT

My focus within the Olso team is on domain modeling – creating models for specific problem domains using the Oslo modeling platform’s languages and tools. Let me describe why we think of this as more than just data modeling.

At the center of an Oslo domain is a data model authored in M. The primary purpose of this model or schema is to describe repository storage, defined in terms of extents. This domain schema defines data integrity constraints and may also define reusable data definitions or types, as well as computed values that describe interesting ways to retrieve and compute data from the model. The schema is compiled into SQL, resulting in tables, views, constraints and functions which are loaded into a SQL Server database primed with some simple Repository patterns. The result is a simple and easy-to-query and otherwise normal SQL database, which can be queried using any SQL data access API or tools.

Surrounding this data model and considered part of the domain may be any number of domain specific languages, which if developed using Oslo may be textual, authored in MGrammar, or visual, authored with Quadrant. These DSLs define ways in which domain information (instance data) can be created or presented. Any number of textual and visual languages may be defined for the same domain, each customized to provide some specific perspective. A domain can also reference other domains, so models and languages may also reference (and in due course, embed) other models and languages.

Accompanying each DSL may be utilities that map or import/export language 'documents' to and from repository storage. For textual DSLs described in MGrammar simple transformations can be expressed in the grammar itself - more complex transformations need to be described separately. A key Oslo scenario will involve cataloging and potentially creating/editing pre-defined artifacts that might otherwise be created and/or consumed externally by other tools.

Collectively, the domain schema, textual and visual DSLs, and their accompanying import/export tools define what we think of as a domain from an Oslo standpoint and will typically be evolved as a unit. This whole-domain perspective is an important part of the way we think about modeling with Oslo and strongly influences how you can expect the Oslo platform to be developed.

You can see some early examples of domain schemas included with the CTP on the Oslo Dev Center. Take a look if you can.

Next up, data modeling design patterns in M...

Logical vs. Physical Architectural Modeling Concerns

Bill Gibson — Fri, 11 Nov 2005 20:33:00 GMT

We've been having hallway discussions about some of the dimensions of modeling application architectures. SDM adopts a particularly physical perspective, as it focuses on the deployment packaging stack of concerns. Its focus is on resources (things like assemblies, config, XML files etc.) that are composed into independently deployable applications, that are composed into systems, which are then composed into still higher level systems. SDM, does allow you focus on tangible software entities and express their behavior - very CBD-like. But of course there are other perspectives, and particularly troublesome to some is the absence in the current designers of a logical perspective, in which you can define what an application does, independently of describing how it does it or how that implementation is packaged. The discussion turned to the role of namespace in that logical perspective, specifically to the question, are namespaces the primary logical organizing perspective. I wrote some comments in an email on the subject and have elaborated on them here and invite comment.

While namespaces are clearly not a packaging concept as they can cut across assemblies, they are not necessarily the best or only way to organize the elements in a logical architecture. Instead the notion of a cross-cutting and entirely logical organization of function is proposed. The term "module" was suggested some months ago by a colleagure for this notion. Thus a module is an arbitrary collection of function. A module could be a collection of methods, one class, many classes; may be coincident with an assembly, cross assemblies or contain assemblies. Modules can also describe data. Early on in your design, you might think about modules but go no further than giving a name and describing the role. A classic block structure architecture diagram might be used to show the way modules interact, either depicting a specific instance of an architecture or a pattern before any details exist of the behavior of each module.

You might assign namespaces to modules – although the naming of types/classes, while important, is not intriniscally linked to the logical structuring of software. Namespaces might reflect the logical structure and you might be tempted to conflate the two, such that you use namespaces when really you arethinking about modules. At some point in your design process as you refine your module designs and start to define classes, creating namespaces will become important. And at some point in your design packaging considerations will become important, when you will specify applications, frameworks, and systems. With your packaging decisions you harden the partitioning of the functions in your modules and make communication and binding decisions.

Thus there are module, namespace and packaging dimensions, These represent orthogonal but related concerns which inform each other. Different design strategies will have you tackle these aspects: physical structure (systems, applications, frameworks), logical structure (modules) and implementation (classes with namespaces) in different amounts at different times – being able to reason about all three as and when you choose will be the most flexible and should be what we aim for in tools. Associating a namespace with a module or even a package may make good sense when the purpose of the module/package and the goals of the namespace align but the two are not intrinsically linked.

Understanding SDM: Systems and the Four Layer Model

Bill Gibson — Sun, 16 Oct 2005 19:14:00 GMT

The Whitehorse Distributed System Designers are based on SDM - the System Definition Model. SDM offers a simple model for representing computer systems that can help in many parts of the design, deployment and management space. I'll try over an occasional series of posts to introduce some of the key SDM concepts and how they play together. I'll also show how we can extend these to do some neat things in the application architecture modeling space.

At the heart of SDM is the notion of a 'system'. Let's look at a definition of system that I find useful.

A system is a configurable collection of resources that can be independently deployed . If the resources in a system need to access resources of another system they do so by communicating via endpoints on the systems.

A system can be atomic or composite; a composite system is composed of other systems. I'll explore system composition, resources and endpoints further in other posts, this post will focus on the notion of system hosting.

One system is considered to host another system if it provides infrastructural services to the hosted system. Services can be thought of as infrastructural if the services are provided to many systems of the same type. Introducing the hosting relationship allows the model to be layered, so that different concerns can be addressed in different layers. For example, the requirement of an ASP.NET application on the services provided by IIS is an infrastructural hosting relationship. Similarly IIS is hosted on Windows which in turn is hosted on an appropriate physical system. It wouldn't be useful to have to include models of IIS and Windows and all the other systems that exist in those layers every time you wanted to model an application so we model those separately and then host a model at one level on the model of another. This reflects the reality that one tends to think of configuring standard system 'platforms' on which other systems are installed. Most organizations use a small number of standard configurations of hardware systems on which they install standard configurations of OS and networking systems on which they run standard configurations of application hosting systems on which they run standard configurations of their business applications.

We typically think about there being four layers of systems: application systems, application hosting systems (such as IIS, SQL Server), operating and network systems (such as Windows), and hardware systems (such as a Dell or HP server, Cisco router etc.). In reality there are no hard boundaries and there may well be more than four layers of interest, but it is often useful to think about these four general categories of systems, and it certainly helps people 'get' the overall model.

Different roles/people at different stages are interested in defining, deploying and managing each of the layers. Information about one layer can be provided to those involved in defining another layer to assist in validating that systems at one level will successfully deploy on a specific configuration of systems at the next level. The Distributed System Designers, for example, support the definition of models of the application layer and the application hosting layer and enable deployment validation - where the configuration of an application is verified against a configuration of application hosting software with the goal of increasing the likelihood of successfully deploying the application.