3. Introduction to Modeling 1. Plan for Today's Class 2 ... - Courses

3. Introduction to Modeling
Page 1 of 12
1. Plan for Today's Class
• Models and modeling
3. Introduction to Modeling
Bob Glushko (glushko@sims.berkeley.edu)
Document Engineering (IS 243) - 26 January 2005
◦ The classical modeling approach
◦ Modeling for analysis
◦ Modeling for design
◦ Implementing models
• Modeling Methodology: Processes, Meta-models, Artifacts, Notations, Tools
2. What is a Model?
• 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
3. An Everyday Model: The Recipe
• A recipe describes both objects and structures (ingredients) and the processes (instructions) for
creating a food dish
• The model is not the dish itself – you don't eat the recipe
• You can communicate a recipe to someone else who can then create the same dish
• You can use the recipe as a guide for experimentation with the objects or the processes in the
recipe to create alternative dishes
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 2 of 12
A set of recipes may contain common or re-usable objects (e.g. flaky pastry) or processes (stir-fry)
4. Methodologies – Disciplines for Modeling [1]
• 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
• The choice of methodology reflects a personal or philosophical approach to analysis, design, and
implementation and can be highly contentious in a project
• So modeling is neither pure intellect nor pure technology – instead, it is best to see it as a craft or
skill.
• There is rarely an obvious point at which a model is complete or finished or perfect; it is always a
matter of judgment and must always be based on sometimes arbitrary boundaries about
requirements and scope
5. Methodologies – Disciplines for Modeling [2]
• A methodology can contain or define:
◦ Meta-models
◦ Processes / Activities / Steps
◦ Notations
◦ Tools
• and how these are applied or fit together to produce:
◦ Artifacts
6. The Classical Modeling Approach
• We start with the EXTERNAL view of actual instances, observations, or artifacts
• We then develop a PHYSICAL model that describes the structures and characteristics of the
artifacts as they exist
• From this PHYSICAL model we create a CONCEPTUAL model that abstracts an implementationindependent
view to capture the more fundamental structures, characteristics, or relationships on
which the artifacts are based
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 3 of 12
• From this CONCEPTUAL model we can create PHYSICAL models that re-implement the
(presumably more rational, robust) model
7. Modeling for Analysis
• 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"
• 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
8. Adapting the Classical Approach to XML and Document
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 4 of 12
Engineering [1]
• In "Document Engineering" we can look at artifacts in the world like printed documents or other
things that are tangible
• But what we really care about is the information or intangible content about things in the world
that documents contain
• In Document Engineering the instances or implementations on which physical models are based
include printed documents and forms, electronic documents and forms, databases, APIs, and other
actual descriptions of information sources
9. Document Instances are External Views
• So we treat document instances as External views in the classical modeling framework
Moby Dick
Herman Melville
0804900337
Airmont
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 5 of 12
10. Schemas are Physical Views
• Document Implementation Models or Document Schemas are what we call Physical views
11. Modeling for Design or Re-Design
• 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
12. Modeling for Design or Re-Design – Conceptual Models
• Models of things as they could be are Conceptual or To-Be models
• In Document Engineering the goal of design is to create "core components" that describe the
information used in a set of documents, databases, forms, APIs in a way that can be used by any
of them
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 6 of 12
13. Adapting the Classical Approach in Document Engineering:
Document Component Models
• Document Component Models describe the complete set of semantic components in a domain,
including their structure and potential relationships with each other
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 7 of 12
14. Adapting the Classical Approach in Document Engineering:
Document Assembly Models
• Document Assembly Models describe how some some selection or arrangement of components in
a hierarchical model of a document type
One Assembly of Previous Component Model
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 8 of 12
Another Assembly of Previous Component Model
15. Manipulating Design Models
• 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
16. The Modeling Gaps
• 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
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 9 of 12
• 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
17. Meta-models
• 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
• Examples of meta-models:
◦ template for a presentation
◦ the "business transaction" meta-model that defines business processes in terms of pairwise
exchanges of sets of business information organized as "business documents"
18. Notations
• 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 notation is neither the model nor the thing being modeled – a recipe (the model) can be
presented in a cookbook or demonstrated on a TV show but the food is still the same food
• For any notation, it is essential to be explicit about what the boxes and arrows mean, because even
when people use the same "notational vocabulary" they might be using the same symbols to mean
different things
19. There Are No Modeling Shortcuts
• Some people (but no one taking Document Engineering) think that "modeling" with XML means
"writing a schema given a set of instances" or "inferring a schema from a single instance," like
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 10 of 12
XML Spy tries to do.
• 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; expectation is that the
schemas are sufficient
20. Implementing a Conceptual Model as a Physical One
• A model is purely theoretical until it is encoded in a technology that lets it operate in the real
world again.
• This is 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
21. Tools
• 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
22. Artifacts
• 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
23. The Modeling Artifacts of Document Engineering
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 11 of 12
• 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
24. UML as a Modeling Notation
• 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
25. XML as a Modeling Notation
• XML has rapidly emerged as a preferred format for creating models that are vendor and notationneutral
• 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
• But as we've seen in lectures and assignments XML schema languages impose constraints on the
models they are used to create and they may be too low-level in many respects
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005

3. Introduction to Modeling
Page 12 of 12
26. To Summarize: The Good News About Models
• 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
27. And the Bad News About Models
• 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
28. For Next Lecture: Business Patterns and Reuse
• remainder of DE Chapter 3
• Assignment 1: Pattern Scavenger Hunt
file://C:\Documents%20and%20Settings\glushko\My%20Documents\SIMS%20Courses\le...
1/26/2005