Copyright 2006 Robert J. Glushko
Models and modeling
The classical modeling approach
Modeling for analysis
Modeling for design
Implementing models
Modeling Methodology: Processes, Meta-models, Artifacts, Notations, Tools
Models are simplified descriptions of a subject that abstract from its complexity to emphasize some features or characteristics while intentionally de-emphasizing others
Models enable us to describe and communicate systems regardless of the specific domain or discipline that they represent
A model can represent a human activity, a natural system, or a designed system
We can model structures – objects, their characteristics, their static relationships with each other like hierarchy, and reference
We can model functions, processes, behaviors – dynamic activities that create and affect structures
A recipe describes both objects and structures (ingredients) and the processes (instructions) for creating a food dish
Important characteristics and uses of the recipe model are:
...
When we create a model we follow – implicitly or explicitly – some steps or techniques for analysis, design, and implementation
This is called the modeling methodology
Methodologies can be formal, prescriptive, step-by-step, documented and auditable or they can be the opposite: informal, ad hoc, "seat of the pants" with no trace other than the model artifact itself
A methodology can contain or define:
Meta-models
Processes / Activities / Steps
Notations
Tools
and how these are applied or fit together to produce:
Artifacts
A methodology's process describes the work to be done and the order in which it is to be done (the modeling workflow)
Many methodologies prescribe a Sequential process -- the "waterfall" model
Other methodologies are more iterative or recursive -- like the "spiral" model of progressive refinement or "agile" modeling
Other methodologies are looser about the modeling activities but emphasize the results that must be obtained at each step or phase
The primary purpose of modeling is to better understand some existing system or environment and its artifacts ("the things implemented in it") and to describe this understanding so it can be communicated
This modeling activity is usually called "systems analysis" or simply "analysis"
A basic task of modeling for analysis is capturing the languages and practices of the people who work with the instances and artifacts in the "real world"
We do this using a mixture of "anthropology" and "archeology"
Any system (especially business ones) has groups of stakeholders who do not fully understand the "big picture" – an analysis model can be used to prevent or repair misunderstandings LIKE THESE
An analysis model can synthesize different views or observations into a more complete or generic perspective that accurately accounts for all of them
So we treat document instances as External views in the classical modeling framework
<?xml version="1.0" encoding="UTF-8"?> <Book> <Title>Moby Dick</Title> <Author>Herman Melville</Author> <ISBN>0804900337</ISBN> <Publisher>Airmont</Publisher> </Book>
Document Implementation Models or Document Schemas are what we call Physical views
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Book">
<xs:complexType>
<xs:sequence>
<xs:element name="Title" type="xs:string"/>
<xs:element name="Author" type="xs:string"/>
<xs:element name="ISBN" type="xs:string"/>
<xs:element name="Publisher" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The next purpose of modeling is to assist in the design or re-design of a system
This modeling activity is usually called "systems design" or simply "design"
Design abstracts away or generalizes from the technology and implementation details in the physical model
A model that is implementation-independent is often easier to talk about than one that is encoded in a specific technology context
Document Component Models describe the complete set of semantic components in a domain
Document Assembly Models describe some selection or arrangement of components in a hierarchical model of a document type
Design models can be manipulated as conceptual objects without impacting the real world that they describe, or in ways that are impossible in the real world
"What if" simulation under boundary or stress conditions, novel scenarios
Simplifying, reorganizing, or "normalizing" structures
Removing process inefficiencies
Other kinds of prototyping and conceptual experimentation
There is an essential difference or gap between the real world being modeled and the conceptual world of the model, or else the model would serve no purpose
Likewise, there is always a gap between an analysis model and a design model, because an analysis model is often most useful when it isn't tied to specific or feasible implementations or technologies
But this means we can sometimes see what the current world looks like and what we would like it to be without being able to see how to get from one to the other
This is why some software developers don't like software architects
Put a different way, this means that models can be designed that are impossible to implement
A meta-model is an abstract model that specifies the type of information to be collected during the modeling activity
This is another layer on top of the model itself -- think of it as a model for the model
Rigorous or highly-formal methodologies generally have a meta-model with prescriptive processes for "populating" it
Meta-models enable models to be compared or to interoperate
A notation is needed to depict or represent the objects and processes in your model
At its simplest, a notation is a set of graphical elements (usually boxes) and lines that connect two or more of them to indicate a relationship
Notations can be as simple and informal as "box diagrams" on the back of a napkin
Or as complex and formal as the "activity diagrams" defined in the Unified Modeling Language(UML)
There is no single "lingua franca" model notation suitable for all users and purposes
The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing and documenting the structure and behavior of (software) systems
UML is the synthesis of a variety of object-oriented modeling concepts and notations and is now endorsed by the Object Management Group. It is a language in that it can be used to define different types of models
UML has a number of standard notations or diagram types that all are based on the same underlying meta-model (and it can also be used to define additional notations)
Put another way... one UML description of a model can be used to produce numerous artifacts that use different notations, each of which highlights a different aspect of the model
We will use just enough UML in this course to help us analyze and design models for documents and business processes
XML has rapidly emerged as a preferred format for creating models that are vendor and notation-neutral
XML's key benefits from this perspective are the ease with which XML instances can be transformed and the use of models expressed as XML schemas to guide code generation by serving as templates for program objects
Using the concepts introduced in this lecture, XML is a meta-modeling language or maybe even a meta-meta-modeling language; each XML schema language is a meta-language for creating models that are expressed as DTDs or as instances of other schema language types
Some people think that "modeling" with XML means "writing a schema given a set of instances" or "inferring a schema from a single instance"
But schemas developed without a stage of conceptual design are rarely very useful because they are too closely tied to the particular instances used, which may not be representative.
Sometimes schemas went through a stage of conceptual design but once the schemas are implemented the conceptual information isn't available to schema users
A model is purely theoretical until it is encoded in a technology that lets it operate in the real world again.
This is often a two-stage process: encoding conceptual models as physical ones, and then applying formatting or style transformations to create instances with desired properties
When instances implemented in different technologies are generated or re-generated from models, they can more readily interoperate because of their common conceptual components
Tools can be as simple and informal (pencil and paper) or complex and formal (CAD and CASE software)
There is no single tool suitable for all users and purposes
Tools can be general purpose, not tied to specific methodologies (word processors, spreadsheet, presentation packages)
General purpose tools can use templates to support specific notations or processes
Tools can be dedicated to particular notations or processes
Artifacts are the things that a methodology produces that communicate the results of the modeling activity
Models are often communicated as prose documents with some mixture of graphics and text
Models can be most useful when they are communicated using artifacts that are "notation-neutral" or that are capable of being transformed into other forms or syntaxes
A focus on artifacts is a key principle of Document Engineering
Analyzing the Context -- UML use case diagrams
Analyzing/Designing Business Processes -- Worksheets, UML Activity and Sequence Diagrams
Applying Patterns to Business Processes -- Document Checklist
Analyzing Documents -- Document Inventory
Analyzing Document Components -- Consolidated Table of Content Components
Assembling Document Components -- UML Class Diagram
Assembling Document Models -- UML Class Diagram or Spreadsheet
Implementing Models -- XML Schemas
System development methodologies have been around for about 50 years
The ad hoc ones come and go, but the more formal ones often achieve a high profile
With almost religious overtones, some methodologies have their "prophets," "high priests," "disciples," "Bibles," and "heretics"
Methodology wars are fought over process (quantity and format of documentation), notation (sizes and shapes for arrows and boxes), tools (merits of different software packages), and artifacts (what is an "object")
Stay neutral in these wars by remembering:
Modeling is a means NOT an end in itself
Modeling can be guided by one or more methodologies
A methodology doesn't have to be formal or prescriptive to be useful
Models describe a common understanding
Models help define requirements, identify design weaknesses and design improvements
Models can facilitate prototyping, reduce development and maintenance costs
Models can identify reusable patterns and artifacts
The intellectual challenges of working with abstractions and models and meta-models can become addictive
As a result, analysts and designers can engage in endless debates about modeling techniques and the means of modeling too often become ends in themselves
Furthermore, many modeling techniques come with either an explicit or implied methodology for its application that may be limiting for some kinds of models – and so we find ourselves restricting our designs to suit the modeling technique
Likewise, since approaches to modeling reflect personal and philosophical approaches to understanding and solving problems the preference for a particular modeling technique may lead it to be applied indiscriminately and inappropriately
Remainder of DE Chapter 3 (86-100)
Do Some Business Models Perform Better than Others? - Weill, Malone, D'Urso, Herman, and Woerner (http://ccs.mit.edu/papers/pdf/wp226.pdf)
E-Gov: Federal Enterprise Architecture (http://www.whitehouse.gov/omb/egov/a-1-fea.html)
FEA Consolidated Reference Model Document (http://www.whitehouse.gov/omb/egov/documents/CRM.PDF), pages 1-6, 21-23