Lecture 4: Problem Solving 1

1
Lecture 4 Problem Solving (1) General (and
not-so-general) Purpose Techniques

• Need to be able to recognise how each of the
  following concepts can be used to solve problems,
  and via modern (an not-so-modern) notation-
  techniques
• - Grammars
• - Stepwise refinement
• - Separation of abstract concrete syntax
• - Separation of interface implementation

2
Problem Solving (2) Grammars

• Grammars initially (and still) used to specify
  concrete syntax, e.g. of a programming language,
  a design notation - any formal languages syntax.
• Grammar rules enable translation to be automated,
  e.g. by a parser.
• Historically, grammars and language translation
  has been central to Computer Science (as in
  the study of algorithmic processes).
• Historically, SE has involved a variety of
  specification notations, design notations and
  programming languages.
• Modern process-oriented SE emphasises the need
  for formality in design notations, e.g. UML, XML.
• In MDA (see later lecture), PIMs are represented
  in UML.
• XML 1is a simple, flexible text format derived
  from SGML (ISO 8879), originally designed to meet
  the challenges of large-scale electronic
  publishing.
• XML now used to exchange data (with differing
  structure), e.g. via WWW.
• 1 http//www.w3.org/XML/

3
Problem Solving (3) UML (Class-Based) OO
Modelling

• UML is a formalised graphical modelling notation
  intended for OO descriptions (c.f. conventional
  engineering blueprint)
• n.b. implementations built from UML designs are
  assumed to be written in Class-based OO
  programming languages
• Earliest version was amalgamation of Booch1,
  OOSE2 and OMT3
• Comprises three main grammar elements things,
  relationships and diagrams.
• Things are Structural (class, interface,
  collaboration, use case, active class, component,
  node), Behavioural (interaction, state machine),
  Grouping (package) and Annotational (note).
• Relationships dependency, generalisation,
  association (name, role, multiplicity,
  aggregation), realisation.
• Diagrams Class, object, use case, sequence,
  collaboration, state chart, activity, component,
  deployment.
• Class/object diagrams used for describing
  structures in database or program
• 1 http//en.wikipedia.org/wiki/Booch_method
• 2 http//en.wikipedia.org/wiki/Object-oriented_s
  oftware_engineering
• 3 http//en.wikipedia.org/wiki/Object-modeling_t
  echnique

4
Problem Solving (4)

• UML1 can be used to model flow of control and
  activity within an (OO) program via
  interactions between classes.
• An interaction is a behaviour
• - Behaviour comprises a set of messages
  exchanged among a set of objects within a context
  to accomplish a purpose.
• A message specifies a communication (between
  objects) that conveys information and causes (or
  is intended to cause) an activity.
• Properly constructed interactions are
  equivalent to algorithms2.
• 1 Martin Fowler, UML distilled a brief guide
  to the standard object modeling language. 3rd
  edition. AW 2004.
• 2 Algorithms abstract over computations that
  take place under their (i.e. the algorithms)
  control.

5
Problem Solving (5)

• A UML class diagram corresponds to a type
  diagram, i.e. from a type-oriented perspective
  each box denotes a type.
• This is a useful perspective BECAUSE types are
  the basis for type checking, i.e. automated type
  checking
• From an implementation viewpoint, e.g. in Java,
  types are defined using either classes or
  interfaces.

6
Problem Solving (6)

• The diagram above can be implemented is Java as-

public class Base  public String
m1()      return "Base.m1()"  
public class Derived  extends Base  implements
IType  public String m1()      return
"Derived.m1()"  
public String m4()      return
"Derived2.m4()"  
 public class Separate  implements
IType  public String m1()      return
"Separate.m1()"  
 public String m2( String s )      return
"Base.m2( " s " )"  
    
public String m3()      return
"Derived.m3()"  
 public String m2( String s )      return
"Separate.m2( " s " )"    public String
m3()      return "Separate.m3()"  
interface IType  String m2( String s
)  String m3()
public class Derived2  extends
Derived  public String m2( String s
)      return "Derived2.m2( " s " )"  
7
Problem Solving (7)

• As you are no doubt aware, using these type
  declarations and class definitions, we can
  declare an explicitly typed reference variable,
  derived2, and attach that reference to a newly
  created Derived2 class object.

Derived2 derived2 new Derived2()
The Derived2 object maps m1() to implementation
code defined in the class Derived.
Furthermore, that implementation code overrides
the m1() method in class Base.
A Derived2 reference variable cannot access the
overridden m1() implementation in the class
Base.
However, the actual implementation code in class
Derived can also use the Base class
implementation via super.m1().
8
Problem Solving (8)

• A Derived2 object can be referenced with any
  variable that conforms to type Derived2.
• The UML type hierarchy indicates that Derived,
  Base, and IType are all supertypes of Derived2.

Thus, a Base reference can be attached to the
object Base base derived2
The underlying Derived2 object and all of the
operation mappings remain unchanged, but the
methods m3() and m4() are no longer accessible
through the Base reference.
9
Problem Solving (9)

• Calling m1() or m2(String) using either variable
• derived2 or base results in execution of the
  same code

• String tmp
• // Derived2 reference tmp derived2.m1()       
        // tmp is "Derived.m1()"tmp derived2.m2(
  "Hello" )    // tmp is "Derived2.m2( Hello )"

• // Base reference tmp base.m1()              
     // tmp is "Derived.m1()"tmp base.m2(
  "Hello" )        // tmp is "Derived2.m2( Hello )"

• Realising identical behaviour through both
  references is consistent
• because the Derived2 object does not know what
  calls each method.
• The object only knows that when called upon, it
  follows the rules
• defined by the implementation hierarchy.
• Those rules stipulate that for method m1(), the
  Derived2 object executes
• the code in class Derived, and for method
  m2(String), it executes the
• code in class Derived2.
• The action performed by the underlying object
  does not depend on the
• reference variable's type.

10
Problem Solving (10)

• However, use of the reference variable derived2
  and base differs.
• A Base type reference can only see the Base type
  operations of the underlying object.
• Thus, although Derived2 has mappings for methods
  m3() and m4(), the variable base cannot access
  those methods

• String tmp
• // Derived2 reference tmp derived2.m3()       
        // tmp is "Derived.m3()"tmp
  derived2.m4()             // tmp is
  "Derived2.m4()"// Base reference tmp
  base.m3()                 // Compile-time
  errortmp base.m4()                 //
  Compile-time error

• Finally, the runtime Derived2 object still
  accepts either an m3() or an m4()
• method call.
• The type restrictions that disallow those
  attempted calls through the Base reference
• actually occur at compile time.
• Thus, compile-time type checking ensures that
  runtime objects interact
• only through explicitly declared type
  operations, i.e. types define the boundaries of
• interaction between objects.

11
Problem Solving (11) XML

• XML is a (proper, strict) sublanguage of SGML.
• Grammar of XML has been defined in EBNF1.
• Design Goals1
• - XML shall be straightforwardly usable over the
  Internet.
• - XML shall support a wide variety of
  applications.
• - XML shall be compatible with SGML.
• - It shall be easy to write programs which
  process XML documents.
• - The number of optional features in XML is to
  be kept to the absolute minimum, ideally zero.
• - XML documents should be human-legible and
  reasonably clear.
• - The XML design should be prepared quickly.
• - The design of XML shall be formal and concise.
• - XML documents shall be easy to create.
• - Terseness in XML markup is of minimal
  importance.
• 1 http//www.w3.org/TR/REC-xml/sec-notation

12
Problem Solving (12)

• IF only well-formedness is required of an XML
  document THEN XML is a
• generic framework for storing a) any amount of
  text or b) any data,
• both of whose structure can be represented as a
  tree.
• A syntactically correct XML document has a root
  element (or document element) enclosing text
  between a root opening tag and a (corresponding)
• closing tag.
• Example (http//en.wikipedia.org/wiki/XMLWell-for
  med_and_valid_XML_documents)

13
Problem Solving (13) Grammars and Stepwise
Refinement

• In its simplest guise SR (aka functional
  decomposition) can be shown to underpin the
  effective use of simple formal notations, e.g.
  when defining grammars.
• Example
• - Little (useful) SR
• ltcalculatorgt
• On (ltoperandgt ltoperatorgt sto rcl) Off
• - More (effective) SR
• ltcalculatorgt On ltcalculationsgt Off
• ltcalculationsgt ltcalculationgt ltcalculationsgt
  ltcalculationgt
• ltcalculationgt

14
Problem Solving (14)

• Any (all) useful formal and semi-formal notations
  are only effective because they embody (ideally
  enforce) the notion of stepwise refinement
• Grammar notations
• Programming languages (data and/or operations)
• Design notations
• Formal Methods (of software specification, e.g. Z
  schema hierarchy)
• In modern SE notations, SR is used to
  systematically develop descriptions of
  requirements, designs and implementations
• What has changed since early SE is the
  notations used
• - Still use SR to systematically derive a
  description (of data, an operation, a
  relationship, a class, an interaction, etc) by
  incrementally adding additional information to an
  existing (and systematically produced
  description) in a manner that excludes the
  introduction of ambiguity and is hence
  repeatable.(my italics)

15
Problem Solving (15) Separation of abstract /
concrete syntax

• In early SE, concrete and abstract syntax were
  preserve of designers of formal languages (c.f.
  languages are algebras1).
• Classical language specifications
• - Start from a concrete syntactic construct (in
  modern SE, e.g. a notational element in UML)
  which is
• - (2) mapped into an abstract syntactic
  construct that, in turn, is
• - (3) mapped onto a semantic element.
• - Syntactic constructs should have a unique
  semantic correspondence (to remove any ambiguity
  potential for confusion)
• - The opposite is not necessarily true, since
  designed languages usually have many semantic
  elements (dynamic semantics) that don't have a
  syntactic correspondence.
• - It is common language design practice to map
  every unique syntactic construct to a unique
  semantic element.
• 1 Goguen, J. A. (et al), Initial Algebra
  Semantics and Continuous Algebras, JACM 241
  (1977), pp68-95.

16
Problem Solving (16)

• As SE developed, same separation of concerns
  (i.e. concerns that can usefully be separated)
  was basis of systematic software development
  techniques e.g. data structure design
  techniques (c.f. program design by recursive
  descent, JSD-JSP).
• In modern SE same separation of concerns has
  been used, e.g.
• - When defining formalisms/notations UML
  concrete syntax, abstract syntax (via a
  meta-model) and semantics (by mapping symbol
  combinations to other notations).
• - To underpin design/development techniques MVC
  (originally a SmallTalk notion), abstract syntax
  is the reference format, i.e. the Model in MVC,
  unparsing into a concrete syntax is a View in
  MVC.

17
Problem Solving (17) Separation of interface /
implementation

• Originally supported by pre-OO programming
  languages, e.g. Modula-2 and Ada. (c.f. Abstract
  Data Types ADTs).
• Such languages enforced a clean syntactic
  separation of interfaces/definitions and
  implementations by the "principle of information
  hiding".
• In modern SE (i.e. modern programming
  languages) the same strict separation of
  interfaces and implementations (and a distinction
  between state and value objects) is vital if a
  language is both object-oriented and
  component-oriented
• - Components can then be pre-fabricated,
  dynamically loadable software entities written in
  any language, and can communicate with other
  components via standardised function-call
  interfaces, e.g. CORBA or COM components.

18
Problem Solving (18) Example - A module (in a
Modula-2-like language) can be used to
encapsulate the state of an "object
MODULE memory INTERFACE USES words
PROCEDURE read_memory(address word VAR value
word) PROCEDURE write_memory(address word
value word) IMPLEMENTATION USES
word_operations CONST max_address 2047
TYPE address 0..max_address VAR
store ARRAYaddress OF word
PROCEDURE read_memory( address word VAR
value word ) VAR index integer
BEGIN indexword_to_integer(address)
IF index IN 0..max_address THEN
valuestoreindex ELSE valueinteger_to_w
ord(0) END PROCEDURE write_memory(
address word value word ) VAR
index integer BEGIN
indexword_to_integer(address) IF index
IN 0..max_address THEN storeindexvalue
END END.
Only accessible via operations in interface
Variable in implementation
19
Problem Solving (19)

• Widely used OO programming languages do not
  support the same strict separation of interface
  and implementation as modular pre-OO languages
• - The distinction between public, private and
  protected members of a class does not support a
  strict syntactic separation.
• - The distinction in Java between "interfaces"
  and "classes does not support a strict syntactic
  separation. A Java interface is a collection of
  functions (not possible to specify member data in
  a Java interface). Java interface is a purely
  behavioural view of a class that implements the
  interface
• - Ideally an interface is only the public
  (implementation-independent) part of a class.
• - Java interfaces can be ignored and classes
  used instead (as in C) to specify the public
  (interface) as well as the private
  (implementation) features of objects.
• - Can also use "abstract classes" as a
  substitute for interfaces with data members.
• - Thus, there is no clear separation of the
  roles of interfaces and classes in Java.

20
Problem Solving (20) Questions and Exercises

• How have grammars been exploited in early SE
  and in more recent process oriented approaches to
  SE?
• Explain the main grammar elements of UML.
• What are an interaction and a message in the
  context of UML?
• How is XML defined?
• Explain the role of stepwise refinement in
  developing descriptions, e.g. descriptions of
  grammars, requirements, designs, etc.
• Why is it important to separate the notions of
  concrete and abstract syntax?
• Why is it important to separate interfaces from
  implementations and how can this be achieved in
  a modern class-base OO programming language, e.g.
  Java?