Wikiquote

Stephen J. Mellor

British computer scientist

Stephen J. Mellor (born 1952) is an American software engineer, and developer of the Shlaer-Mellor method and signatory to the Agile Manifesto.

Quotes

edit
  • I assume that a precisely defined, verifiable, executable, and translatable UML is a Good Thing and leave it to others to make that case... In the summer of 1999, the UML has definitions for the semantics of its components. These definitions address the static structure of UML, but they do not define an execution semantics. They also address (none too precisely) the meaning of each component, but there are "semantic variation points" which allow a component to have several different meanings. Multiple views are defined, but there is no definition of how the views fit together to form a complete model. When alternate views conflict, there is no definition of how to resolve them. There are no defined semantics for actions...
    To determine what requires formalization, the UML must distinguish clearly between essential, derived, auxiliary, and deployment views. An essential view models precisely and completely some portion of the behavior of a subject matter, while a derived view shows some projection of an essential view...
    All we need now is to make the market aware that all this is possible, build tools around the standards defined by the core, executable UML, and make it so...
    • Mellor in Andy Evans et al. (1999) "Advanced methods and tools for a precise UML." UML’99—The Unified Modeling Language. Springer Berlin Heidelberg. p. 709-714.
  • In its current form UML is designed to support a wide variety of different modelling techniques and formalisms. This is evident, for example, in the state machine formalism which allows both Moore and Mealy formalism with hierarchical states including concurrent sub-states and both synchronous and asynchronous calling semantics. The result of this is not only that almost any state modelling style can be supported but also that many combinations of elements have no defined execution semantics. It is now widely recognised within the UML community, however, that considerable benefit can be gained by forming subsets of the UML with well defined execution semantics. Such subsets can form an “executable UML” which would enable the simulation, execution, testing and ultimately translation of UML models into target code. As part of this movement, work is progressing under the auspices of the OMG towards the definition of “profiles” that define such subsets and towards the more detailed definition of the contents of “actions” including a more precise definition of the execution semantics of UML models.
  • I was astonished to be invited to what became the meeting that originated the Agile Manifesto because my work had always been based around building models... The other signatories were kind enough, back in 2001, to write the manifesto using the word “software” (which can include executable models), not “code” (which is more specific.) As such I felt able, in good conscience, to become a signatory to the Manifesto while continuing to promote executable modeling. Ten years on we have a standard action language for agile modeling.

Object-Oriented Systems Analysis: Modeling the World In Data (1988)

edit

Sally Shlaer and Stephen J. Mellor, Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press: Prentice Hall, Englewood Cliffs, New Jersey, 1988.

  • An object in OOA represents a single typical but unspecified instance of something in the real world - any airplane, I don't care which one, as long as it is typical. The object-oriented analyst distinguishes this concept from that of a specified instance: Airplane number N2713A, Air Force One, or The Spirit of St. Louis, for example.
    • p. 12.
  • While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters.
    When partitioning a domain, we divide the information model so that the clusters remain intact... Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem.

Executable Uml: A Foundation for Model-Driven Architecture, 2002

edit

Stephen J. Mellor, Marc J. Balcer (2002) Executable Uml: A Foundation for Model-Driven Architecture

  • Creating a modeling language that is also an executable language has long been a goal of the software community. Many years ago, in 1968 to be exact, while working with software components to successfully develop a telecommunications system, we created a modeling language that was the forerunner to UML. To model components we used sequence diagrams, collaboration diagrams, and state transition diagrams (a combination of state charts and activity diagrams). Our modeling language then seamlessly translated the component models into code. Each code component was in its turn compiled into an executable component that was deployed in our computer system. The computer system was a component management system—thus we had "components all the way down."
    • p. xxiii: Foreword.
  • Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change.
    • p. 5.
  • Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem.
    • p. 10.

MDA Distilled. Principles of Model-Driven Architecture, 2003

edit

S.J. Mellor, K. Scott, A. Uhl (2004) Distilled. Principles of Model-Driven Architecture. Addison-Wesley.

  • We build models to increase productivity, under the justified assumption that it's cheaper to manipulate the model than the real thing. Models then enable cheaper exploration and reasoning about some universe of discourse . One important application of models is to understand a real, abstract, or hypothetical problem domain that a computer system will reflect. This is done by abstraction, classification, and generalization of subject-matter entities into an appropriate set of classes and their behavior.
    • p. 35-36.
  • MDA per se is relaxed about exactly what models it transforms, so long as the modeling language in which the models are expressed can be defined.
    • p. 36.
  • In the bad old days before MDA, (conceptual) models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds.
    • p. 36.
  • What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model.
    • p. 37.

Quotes about Stephen J. Mellor

edit
  • Steve Mellor and I independently came up with a characterization of the three modes in which people use the UML: sketch, blueprint, and programming language. By far the most common of the three, at least to my biased eye, is UML as sketch. In this usage, developers use the UML to help communicate some aspects of a system. As with blueprints, you can use sketches in a forward-engineering or reverse-engineering direction. Forward engineering draws a UML diagram before you write code, while reverse engineering builds a UML diagram from existing code in order to help understand it.
    • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 2.
  • Steve Mellor has long been active in this kind of work and has recently used the term Executable UML [Mellor and Balcer]. Executable UML is similar to MDA but uses slightly different terms. Similarly, you begin with a platform-independent model that is equivalent to MDA's PIM. However, the next step is to use a Model Compiler to turn that UML model into a deployable system in a single step; hence, there's no need for the PSM. As the term compiler suggests, this step is completely automatic.
    • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 4.
  • The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock].
    • Martin Fowler (2004) A Brief Guide to the Standard Object Modeling Language. p. 7.
edit
 
Wikipedia
Wikipedia has an article about:
Retrieved from "https://en.wikiquote.org/w/index.php?title=Stephen_J._Mellor&oldid=3389112"