Advanced Systems Design with Java UML and MDA

1st Edition Kevin Lano download

https://ebookgate.com/product/advanced-systems-design-with-java-
uml-and-mda-1st-edition-kevin-lano/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

 Get Your Digital Files Instantly: PDF, ePub, MOBI and More
Quick Digital Downloads: PDF, ePub, MOBI and Other Formats

Systems Analysis and Design with UML International

edition Alan Dennis

https://ebookgate.com/product/systems-analysis-and-design-with-
uml-international-edition-alan-dennis/

Developing Applications with Java TM and UML 1st

Edition Paul R. Reed

https://ebookgate.com/product/developing-applications-with-java-
tm-and-uml-1st-edition-paul-r-reed/

Applying UML Advanced Applications 1st Edition Rob

Pooley

https://ebookgate.com/product/applying-uml-advanced-
applications-1st-edition-rob-pooley/

Uml for Database Design First Edition Naiburg

https://ebookgate.com/product/uml-for-database-design-first-
edition-naiburg/
Object oriented Analysis And Design Understanding
System Development With UML 2 0 First Edition Mike
O'Docherty

https://ebookgate.com/product/object-oriented-analysis-and-
design-understanding-system-development-with-uml-2-0-first-
edition-mike-odocherty/

Software Evolution with UML and XML Hongji Yang

https://ebookgate.com/product/software-evolution-with-uml-and-
xml-hongji-yang/

Software Modeling and Design UML Use Cases Patterns and

Software Architectures 1st Edition Hassan Gomaa

https://ebookgate.com/product/software-modeling-and-design-uml-
use-cases-patterns-and-software-architectures-1st-edition-hassan-
gomaa/

OpenCV with Python blueprints design and develop

advanced computer vision projects using OpenCV with
Python 1st Edition Michael Beyeler

https://ebookgate.com/product/opencv-with-python-blueprints-
design-and-develop-advanced-computer-vision-projects-using-
opencv-with-python-1st-edition-michael-beyeler/

UML for Systems Engineering watching the wheels 2nd

Edition John Holt

https://ebookgate.com/product/uml-for-systems-engineering-
watching-the-wheels-2nd-edition-john-holt/
Preface

The world of software development is experiencing dramatic growth and di-

versification, with a multitude of new languages and technologies continually
being introduced and elaborated: XML, .Net, web services, mobile computing,
etc. It therefore becomes increasingly difficult to keep up to date with even the
technologies in one particular area.
At the same time, important steps towards unification and standardisation
of notations and methods are taking place - the new UML 2.0 standard is the
prime example of these, and provides a common notation and set of concepts
which can be used in any object-oriented development for any kind of system.
The MDA 1 (Model-driven Architecture) likewise provides a general strategy for
separating platform-independent specifications of systems from their platform-
specific implementations.
In this book we cover the key languages and techniques for object-oriented
software design of a wide range of systems:

9 UML 2.0: we introduce the core concepts and notations of UML, and
show how they can be used in practice.
9 MDA: we describe the key elements of this approach, and transformations
of models using UML Profiles, XSLT, JMI and REI.
9 Internet system design: how to use JavaScript, Flash, XHTML, JSP
and Servlets to produce modular, usable, portable and accessable web
systems.
9 Web Services: including technologies such as J2EE, JavaMail, .Net, SOAP,
WSDL and streaming.
9 E-commerce: including the Semantic Web, FTP, WML and Bluetooth.

A catalogue of UML model transformations is also provided. The supporting

website contains the UML-RSDS tool to support the MDA process, and the
UML2Web tool for the synthesis of web applications from UML descriptions.
Examples of the use of these techniques are given throughout the book,
with three large case studies being used:
1MDA is a registered trademark of the OMG.

vii
viii Preface

9 A system to play Scrabble.

9 An internet jukebox using data streaming.
9 An online estate-agent system.

Acknowledgements
Kelly Androutsopoulos, David Clark and Pauline Kan contributed to the pro-
gram synthesis concepts used in the book. Runa Jesmin contributed the ma-
terial on usability design of web systems. The internet jukebox case study is
due to Ruth O'Dowd, Taherah Ansari contributed the case study of XSLT and
REI transformations, and numerous other students at King's College have also
helped in providing feedback on courses in which the material presented here
has been taught.
Chapter 1

The Challenges of Software Design

This chapter surveys current issues in software construction, the problems

caused by the pace of technological change, and the need for improved main-
tainability and portability of software. In particular we consider the need
for software development to focus more resources on construction of platform-
independent models to reduce the effort in recreating a system for a new plat-
form or technology.

1.1 Softwaredevelopment
The purpose of software I remains the same today as it was at the beginning of
computing in the 1940s: to automate the solution of complex problems, using
computers. However the nature of the problems to be solved has changed
dramatically, and so have the programming techniques employed: the first
computers were used for highly critical and specialised tasks such as decryption,
and 'programming' them meant reconfiguring the hardware (vacuum tubes or
'valves') of these huge and massively expensive devices.
Today, the variety of tasks for which computational power is used spans the
whole range of business, social and creative endeavours. Increasingly, instead of
performing some isolated computation, software systems form active or passive
elements in a communicating network of services and agents, each new system
depending essentially on existing capabilities of previously developed systems,
whose services it uses.
Programming techniques have also advanced in the decades that followed
the 1940s, through the use of languages of increasing power and abstraction:
Assembly languages, FORTRAN, C, C + + , and now Java and C #. Instead of
manipulating instructions at the level of the hardware, programmers specify
data and algorithms in terms of the problem domain. The rise of object-
orientation as a language for problem description and solution is the prime
1The name 'software' for computer programs seems to have been used for the first time
by John Tukey in the January 1958 edition of the American Mathematical Monthly journal
[5O].
 Chapter 1. The Challenges of Software Design

present-day example of this progression. Object-oriented languages have be-

come the dominant trend in software development, and even archaic languages
such as FORTRAN, BASIC and COBOL have been extended with object-
oriented facilities.
The software development activities undertaken by companies today have
also changed. Instead of building new stand-alone systems, software develop-
ment is often used to enhance a company's enterprise information capabilities
by building new functions into an already existing infrastructure, or by gluing
together existing systems to carry out new services. In general, the emphasis
in software development is increasingly on systems as components in larger
systems, components which interact and combine with each other, perhaps in
ways that were not envisaged by their original developers.
For example, in the jukebox audio streaming case study of Chapter 8, ex-
isting web services specialised for streaming audio data need to be combined
with a playlist database, control unit and a device for playing the downloaded
data.
Another factor has arisen, of profound significance for the software industry,
which is the pace of change and introduction of new technologies. Although the
rate of progress in the computer industry has always been rapid compared to
other fields, since the advent of the internet, the dissemination and uptake of
new languages and techniques has reached a level that seems to put any system
more than a year old in danger of obsolescence, and requires continual revision
in education and training of developers.
For example, it took over a decade for object-orientation to emerge from
research and niche application areas to become the pervasive feature of modern
programming languages, yet more recently XML [53] has made the same scale
of transition in under five years.
The rapid change and introduction of new software technologies and lan-
guages, whilst obviously bringing benefits in enhanced capabilities, has also
resulted in expense and disruption to companies using software, due to the
need to continually upgrade and migrate applications.
The concept of Model-driven Architecture (MDA) [28] aims to alleviate
this problem by focusing developer effort at higher levels of abstraction, in
the creation of platform-independent models (PIMs) from which versions of
the system appropriate to particular technologies/languages can be generated,
semi-automatically, using platform-specific models (PSMs). This means that
companies can retain the key elements of their software, especially the business
rules or logical decision-making code, in a form that is independent of changes
in technology, and that can be used to generate, at relatively low cost, new
implemented systems for particular technologies.
The MDA approach (Figure 1.1) can be seen as a continuation of the trend
towards greater abstraction in programming languages. In this case, the 'pro-
gramming' is intended to take place at the level of diagrammatic UML models
and constraints on these models. Executable versions of the system are then
generated, as an extension of the compilation process.
This book will describe one approach for making this vision of reusable
1.2. Software development methods 3

Platform Independent
~_~._ Model b

Transformations

PlatformSpecificModel Platform SpecificModel b

(PlatformA) (PlatformB) j

Code Generation

l (PlatformA)
l
~Impl . . . . tedSystem
(PlatformB)

F i g u r e 1.1: The M DA process

software a practical reality. In the remainder of the chapter we survey existing

software development methods and the key concepts of software development
processes, and discuss how these relate to the MDA.

1.2 Software development methods

A software development method is a systematic means of organising the pro-

cess and products of a software construction project. A software development
method typically consists of:

9 Notations or languages to describe the artifacts being produced, for ex-

ample UML [51] can be used to describe requirements, analysis or design
models.
9 A process, defining the sequence of steps taken to construct and validate
artifacts in the method.
9 Tools to support the method.

Some popular development methods are the spiral model, the waterfall model,
the rational unified process, and extreme programming.

1.2.1 The Waterfall model

In the waterfall model [41], the stages of development such as requirements

definition, design and implementation are separated into complete tasks which
must be fully carried out and 'signed off' before the next task can be started
(Figure 1.2). Each stage produces a deliverable (eg, a complete requirements
specification, complete system design) which is intended to not need much
further revision.
 Chapter 1. The Challenges of Software Design

Requirements
Definition

System and
Software Design l

Implementation &
unit testing

'Integration &
Isystem testing

Operation and
Feedback maintenance

F i g u r e 1.2: Waterfall model process

1.2.2 The Spiral model

The spiral model [5] is based on an iteration of incremental development steps

(Figure 1.3). Each iteration (cycle of the spiral) produces a deliverable, such as
an enhanced set of models of a system, or an enhanced prototype of a system.
In each iteration a review stage is carried out to check that the development is
progressing correctly and that the deliverables meet their requirements. Unlike
the waterfall model, the deliverables produced may be partial and incomplete,
and can be refined by further iterations.

1.2.3 The Rational Unified Process (RUP)

The Rational Unified Process [43] defines four phases in the development
process:

1. Inception: definition of project scope, goals of the system, evaluation of

its feasibility and general estimates of project cost and time. A prototype
may be built to assist in checking if the project is viable. The main process
in this phase is requirements definition, producing initial use cases in
agreement with the users.
2. Elaboration: requirements analysis and definition of architectural design.
The use cases are elaborated and structured, forming a starting point for
the design of the overall architecture of the system.
3. Construction: design and implementation through the development of
prototypes, culminating in the delivery of a beta version of the system to
user sites.
4. Transition: testing, correction of defects detected by users, rollout of new
versions until a production version is reached.
 1.2. Software development methods 5

DETERMINE OBJECTIVES, Cumulative cost EVALUATE ALTERNATIVES,

IDENTIFY & R E S O L V E RISKS
ALTERNATIVES, CONSTRAINTS

~,~w ~ [ \,eoAeo~ t:'-~:'-~mu,ations / ....... I I

N
Code ""

I ~eriOcat~_e,=::: \ \ Test
/
lmm~tion , Test \ \ ~ ND~LOE~[~:~I~JDUCT
,AN NEXT PHASES

Progress through steps

F i g u r e 1.3: Spiral model process

The major milestones in development are the progression from one phase to
another: the decision to commit to the project in the Inception --+ Elaboration
progression, an accepted first revision of the requirements document in the
Elaboration --+ Construction progression, and a beta release in the
Construction --+ Transition progression.
The process is use-case driven: each design module should identify what
use cases it implements, and every use case must be implemented by one or
more modules.

1.2.4 Extreme Programming (XP)

Extreme programming tries to minimise the complexity of following a particular

development process [4]. Instead of prescribing a rigid set of development steps
and milestones, it emphasises a number of practices:

9 Realistic planning: customers make the business decisions about a system,

the developers make the technical decisions. Plans are reviewed and
revised as necessary.
9 Small releases: release a useful system quickly, and release updates at
frequent intervals.
9 Metaphor: all programmers should share an understanding of the purpose
and global strategy of the system being developed.
 C h a p t e r 1. The Challenges of Software Design

9 Simplicity: design everything to be as simple as possible instead of pre-

paring for future complexity.
9 Testing: both customers and programmers write tests. The system should
be frequently tested.
9 Refactoring: the system should be restructured whenever necessary to
improve the code and eliminate duplication.
9 Pair programming: put programmers together in pairs, each pair writes
code on the same computer.
9 Collective ownership: all programmers have permission to change any
code as necessary.
9 Continuous integration: whenever a task is completed, build a complete
system containing this part and test it.
9 ~O-hour week: don't work extreme hours to try to compensate for plan-
ning errors.
9 On-site customer, an actual customer of the system should be available
at all times.
9 Coding standards: follow standards for self-documenting code.

XP is a lightweight development approach which aims to avoid the time-

consuming documentation and structures of other methods. Code can be writ-
ten immediately after definition of use cases (together with test plans for each
use case). The code produced can then be refactored and restructured to pro-
duce a more efficient and maintainable implementation.

1.2.5 Which method to choose?

The waterfall model has often been criticised for its rigid progression from one
task to the next, which can lead to a progressive build-up of delays, as one
task cannot begin until its predecessor has completed. On the other hand,
it imposes greater discipline than more evolutionary incremental approaches,
where 'completion' of a task is left open-ended, and indeed, may not end.
The cumulative iterations and reviews of the spiral model can lead to earlier
detections of errors, and therefore lower costs and reduced risks of failure than
monolithic methods such as the waterfall model.
The Rational Unified Process, like the waterfall model, also has an em-
phasis on development phases with milestones as the progressions between
them. Some software engineers believe that, in contrast, an architecture-driven
approach is necessary for object-oriented development, whereby global phases
are replaced as the focus by the modular construction of systems, component
by component and layer by layer. For each layer there are separate specific-
ation, design and implementation activities. XP may be a better fit for this
approach than phase-centred methods.
In principle, any of the above development methods can be used in a MDA
development, although the end product of the process may be a PIM or a
PIM plus PSMs, instead of executable code. With the MDA, the progression
1.3. Software development steps 7

from specification to design, and from design to implementation, may be partly

automated. This enables developer effort to be concentrated on producing high-
quality and correct PIMs. Refactoring transformations and design patterns are
of particular importance in this respect, and we describe how these can be used
for PIM to PIM mapping and PIM to PSM mapping in Chapter 5.

1.3 Software development steps

A number of stages are typically present in any software development project,

regardless of the development model and methods chosen. We will illustrate
these stages for two different projects: (i) a system to play Scrabble against
human players, and (ii) a system to stream music from a server to a home
entertainment system.

1.3.1 Feasibilityanalysis

This stage evaluates the technical options for implementing the system,
determining if it is feasible to implement it, and if so, if there is a cost-effective
implementation. Background research may be needed to investigate similar
systems that already exist, and what services are available to carry out parts
of the required functionality. Trial implementation/prototyping could also be
carried out, or mathematical estimation (eg, of bandwidth or data storage
requirements).
This stage can be carried out as part of the risk analysis phase in the earliest
iteration of the spiral model, or as the first step in the waterfall model. In the
spiral model a developer could recheck the feasibility of the system after each
iteration as part of the review task.
For example, in the case of the Scrabble playing system, this stage would
investigate the rules of Scrabble, existing AI techniques and programs such as
Maven [46] and the feasibility of different memory storage and lookup schemes
for dictionaries.
For the Jukebox project, this stage would involve investigating the state
of available music streaming technologies, for example, streaming servers such
as Helix (http://www.realnetworks.com/) and checking that these support the
required functionality of the system.

1.3.2 Requirementsdefinition

Provided that it has been determined that there is some feasible and cost-
effective way of constructing the system, the development process can advance
to elicit in detail the required functionality of the system.
This stage systematically records the requirements that the customer(s) of
the system have for it, and the constraints imposed on the system by existing
 Chapter 1. The Challenges of Software Design

systems that it is required to operate with, including existing work practices.

For the Scrabble system, the list of requirements could include:

1. The system must enable between one and three human players to play,
together with the computer player.
2. Standard Scrabble rules for moves and the validity of moves should be
enforced.
3. The system should check all words formed in each move, and only accept
the move if all the words appear in its dictionary.
4. The system should keep a history of all valid moves made in a game: the
letters played, the player who moved, and the score of the move.

For the Jukebox, the requirements could include:

1. The server should be capable of storing 100 tracks.

2. The user can add a track to the server from a CD, by inserting the CD
into their computer and following on-screen instructions from the system.
3. The user interface can be on a separate device to the server. The UI
provides an index of tracks, a way to select tracks and playback control
(play, stop, fast forward, rewind).

Use-case models in UML can be drawn for either system, to make clear what
users or external systems are involved in each functional requirement. Figure
1.4 shows some use cases for the Scrabble system, and Figure 1.5 those for the
jukebox.

Human Computer
Player Player

F i g u r e 1.4: Use cases for Scrabble player

 1.3. Software development steps 9

v~edit playlis~
User

F i g u r e 1.5: Use cases for internet jukebox

1.3.3 Analysis

This stage builds precise models of the system, using suitable graphical or
mathematical notations to represent its state and behaviour in an abstract,
platform-independent manner. In a critical system, such as a railway signalling
system, formal validation that the analysis models satisfy required properties
would be carried out.
For the Scrabble system a fragment of the class diagram is shown in Figure
1.6. A fundamental property is that the total number of letters in the game is
always 100, these may be distributed between the player's racks, the bag, or
the board. Hence the annotation in the top corner of the Letter class.
For the Jukebox, the core data model is much simpler (Figure 1.7). There
will also be other web forms associated with the system, for logging in, viewing
and creating playlists, etc.

1.3.4 Design

This stage defines an architecture and structure for the implementation of the
system, typically dividing it into subsystems and modules which have respons-
ibility for carrying out specific parts of its functionality and managing parts of
its data. The activities in design include:

1. Architectural design: define the global architecture of the system, as a set

of major subsystems, and indicate the dependencies between them.
For example, partitioning a system into a GUI, functional core, and data
repository. The G UI depends on the core because it invokes operations
of the core, and the core may depend on the GUI (if it invokes GUI
operations to display the result of computations, for example). The core
depends on the repository. There may be no other connections. Such an
architecture is termed a three tier architecture. Figure 1.8 shows such a
design architecture for the Scrabble system.
10 Chapter 1. The Challenges of Software Design

Board
game [ . Square
Board, placeMove(m: x: 1..15 1 ......
r 1 / Move" I . ~_ I lSOCCuplea[):
l Game ] / 1 ,| y ...... I boardSq . . . . Boolean
/turn. 1 4 I ~ getSquare(i: 1..15J .......
/ " "" I ~ " 1 15" S uar I getLetter~coreu:
|moveNumber: Il J J: "" ): q q Inte,,er
i startGame 0 --|-~
IgameEnded0: [~ ~ /\
I Booleanl ~ ~V
| endMove(m: Move) I ~1, I I
~

/
/1
)
"~
\
gam~e Bag
Bag [/bagSize: 0..100
IisEmpty0: Boolean
I
OrdinarySq . . . . DoubleLetter
I lsq . . . .
I
IlSq
T ripleLetter
....

/ ~ ]giveLetters(x: DoubleWord TripleWord

/ D!. . . . s ~ [ Integer) : Set I [Sq . . . . [ [Sq . . . . I
] fnr~prpdi\ 0..1 ~ squareLetter
/ ,v~ . . . . . . \2..4 ~ hag 0..100 ~ 0..1
Player Letters Letter 100
/ [. . . . . String ] Isymboh char
/ I _{identity} ] rackLetters / ...... Integer
/ I. . . . Integer [ {ordered}A {readOnly}
/ I . . . . I , _ , 0"7// [setSymhol(c:char)
[ I L[~ 1 ~ 1 l ~ a Y . . . . . . /0..1 ' 1
HumanPiayer ' ~'lr Rack I
ackSize: 0..7
I I _ I I | addLetters(h /
] [ C~ I I [ Set) ] /
[ ~ ~ J l . . . . . . Letters(h ] /
* [ history {ordered} J [ Set) |
Move * ~ ~)1/

validateMove( I 1 * x: 1 . . 1 5 l /
n: Integer): I ietterMoves y: 1..15
B o o l e a n ~
calculateScore( ~
b: Board):
Integer

Figure 1.6: Extract from analysis model of Scrabble player

PlayState <<enumeration>>
stopped Player
play setting: Play
rewind 1 Statq
fastForward

PlayForm
requested ~ ! *
Title: String
playTrack0 1
Controller

.~ I ~ descri~i~
~_ Iname: String
String
UploadForm ling
lploadTo:
String
JploadItem: \ Iartist: String
String
Jpload0

Figure 1.7: Analysis model of jukebox

1.3. Software development steps 11

GUI

P l a y e r GUI Administrator
GUI

Functional Core

Move Game -~ Strategy

Management

Data Repository

Move History Dictionary

Data

Figure 1.8: Architecture of Scrabble system

MDA may be applied only to the functional core of a system, which

contains the business rules of the system, or to all tiers, provided suitable
models of these tiers can be defined.
2. Subsystem design: decomposition of these global subsystems into smaller
subsystems which each handle some well-defined subset of its respons-
ibilities. This process continues until clearly identified modules emerge
at the bottom of the subsystem hierarchy. A module typically consists
of a single entity or group of closely related entities, and operations on
instances of these entities.
3. Module design: define each of the modules, in terms of:
(a) the data it encapsulates - eg: a list of attributes and their types or
structures;
(b) the properties (invariants or constraints) it is responsible for main-
taining (ie, for ensuring that they are true whenever an operation is
not in progress);
(c) the operations it provides (external services) - e g : their names, input
and output data, and specifications. This is called the interface of
the module.
4. Detailed design: for each operation of the module, identify the steps of
its processing.

Specialised forms of design include interface design, to plan the appearance

and sequencing of dialogs and other graphical interface elements for user in-
12 Chapter 1. The Challenges of Software Design

teraction, and database design, to define the structure of a database for the
system, and what queries/updates will take place on it.
Pure top-down design, in which a system is hierarchically divided into sub-
systems, and these in turn into further subsystems and modules, is an idealistic
model which can lead to expensive backtracking and rework if applied without
regular review. The structure of the design may need to evolve as experience
with prototypes of the system grows, for example, and the hierarchical struc-
ture may lead to duplication of effort (eg, two teams developing different parts
of the system could create similar modules, which a review may detect and
merge into one module).
For the Scrabble player, design could partition the system into a GUI to
manage the display of the board and racks (bearing in mind the constraint that
only the rack of the current turn player should be visible), a module to check
the correctness of moves, and (the most technically challenging) a module to
generate moves automatically. There will also be data management modules,
to hold dictionary data and game history data (Figure 1.8).
For the jukebox, design will identify the client and server program compon-
ents required: the components to be executed on the client will essentially be
web pages containing forms, the server components will be modules handling
requests from these pages and performing actions on the database of tracks,
and controlling the downloading of tracks. User interface design would sketch
out the appearance and format of the interface, for example, to imitate the
appearance of a real jukebox (Figure 1.9).

Figure 1.9: Interface design of jukebox

 1.4. Summary 13

1.3.5 Implementation

This stage produces an executable version of the system by translating the

design modules into program language code. Implementation may initially be
performed for a small part of the system which acts as a 'template' or 'proof
of concept' for the remainder of the implementation.
For the Scrabble player, implementation of the dictionary could consist of
representing it as a set of word sets a2, a3, ..., a15, b2, ..., z15, where each c~n
is the set of words that contain the letter c~, and that are of length n. This
facilitates lookup of candidate moves for the computer (eg, to find all words
of four letters containing 'b', 'r', 'k' and 'i', the intersection b4 n r4 n k4 N i4
would be constructed and searched).
For the jukebox, a particular streaming server would be adopted, and the
database design implemented in tables in a particular database. The server
processing components could be implemented as Servlets [44] or as JSP [23]
files, etc.

1.4 Summary

In this chapter we have given an overview of the issues currently affecting

software development, and the main processes of software development have
been described. In the following chapter we introduce the UML notation and
show how it may be used throughout development.
Chapter 2

The Unified Modelling Language

In this chapter we introduce the UML as a means of precisely expressing re-

quirements, analysis models and designs, in a platform-independent manner.

2.1 Introduction

The UML [51] is the result of a successful unification of the many object-
oriented analysis and design notations which arose during the 1980s and 1990s.
In 1994 work began on unifying the widely-used OMT [42] and Booch [6] meth-
ods into what became UML, with OOSE [22] also integrated in 1995. From
version 1.1 UML was endorsed by the Object Management Group (OMG), rep-
resenting many companies and organisations, as a standard for object-oriented
analysis and design, and it has now become the primary notation in this field.
A major revision of UML, to version 2.0, was published in 2004. UML consists
of a large number of different modelling notations:

9 Use case diagrams;

9 Class diagrams;
9 Object diagrams;
9 Statecharts;
9 Collaboration diagrams;
9 Sequence diagrams;
9 Activity diagrams;
9 Deployment diagrams.

In addition, there is the Object Constraint Language (OCL) which enables

precise assertions to be made about elements of particular UML models.
All these notations form different views of a software system, which are
intended to be complementary and consistent with each other. Some notations
are much more complex than others, for example the use case notation is used
at the requirements definition stage of development and so does not express
much detail in terms of the internal functioning of the system. In contrast,

14
 2.2. Use case diagrams 15

class diagrams and statecharts may be used at any development stage and are
very expressive languages which can describe a level of detail close to t h a t of
program code.
In this book we will focus on class diagrams and statecharts as the most gen-
erally useful UML notations, especially when enhanced with OCL
assertions.

2.2 Use case diagrams

A use case model [22] describes (1) the system to be constructed, (2) the actors
- representing a role played by a person or other entity t h a t interacts with the
system, and (3) the use cases - families of usage scenarios of the application,
grouped into coherent cases of functionality. A use case is a generalisation of
the scenarios of use of the system: technically, a scenario is an i n s t a n c e of a
use case.

Figure 2.1 shows a generic use case diagram, where actor A participates
in two use cases and actor B in one. The arrows indicate the direction of
interaction - this is not part of official UML use case notation but can be
helpful in indicating the intention of the use case. Figure 2.2 gives the use

Actor A

System

Actor B

Figure 2.1: Simple use case model

cases for a share m a n a g e m e n t system, where price changes are informed to the
system from a stock exchange, and the trader using the system may receive
alerts from it when share price changes pass some preset limits. The trader
can also use the system to sell shares.
Use cases can have additional textual descriptions. A complete textual
description of a use case includes:

1. S u m m a r y - description of the purpose of the use case.

the trigger event: 'the use case begins when e
2. S t a r t o f the use c a s e -
occurs'.
16 Chapter 2. The Unified Modelling Language

Share System

Stock
Exchange
@ ~ Trader

Figure 2.2: Share system use cases

3. End of the use case- the termination event: 'when f occurs the use case
terminates'.
4. Interaction between the use case and the a c t o r s - this identifies what
activities should be inside the system and which outside.
5. Exchanges of i n f o r m a t i o n - what d a t a items are passed between the sys-
tern and the actors.
6. Chronology and origin of i n f o r m a t i o n - identifies when the system re-
quires internal or external information and when it records it.
7. Repetitions of behaviour.
8. Optional s i t u a t i o n s - points where an actor or the system m a y choose
different behaviours within the use case.
9. C a p a c i t y - number of concurrent executions of the use case t h a t the
system may have to handle.

An example from the Scrabble project could be the use case for a h u m a n
player making a move, which has agent HumanPlayer, and the detailed de-
scription:

9 Summary: A complete move by a h u m a n player, involving the letter-by-

letter construction of a new word or words on the board. The move is
checked for validity when it is completed, and the board is p e r m a n e n t l y
u p d a t e d if it is valid, and the player's score incremented.
9 Initiation event: Player presses 'start move' button when it is their turn
and the game has not finished.
9 Termination event: Player presses 'end move' button.
9 Interaction: Player clicks on an enabled letter button in their rack and
then on a vacant square on the board, to move the letter from the rack
to the square. The rack letter button and the square button are disabled
by the system and the letter is shown on the square button.
9 Exchanges of information: The system informs the player if their move
is an error, otherwise it gives the score when the move is completed.
9 Repetitions: Individual letter moves are performed until the whole move
is complete.
2.2. Use case diagrams 17

9 Optional situations: The system may reject a move, if the letter moves
are not co-linear and connected, or if (for the first move) the move does
not include the centre square, or (for later moves) if it does not cover a
square adjacent to a square t h a t was already occupied by a letter before
the move began.
9 Capacity: 1.

Use case diagrams can also express relationships of inclusion and extension
between use cases:

I n c l u d e s Use case ucl includes use case uc2 if doing ucl always involves doing
uc2. This relationship is particularly useful if uc2 is a common subtask
of two or more use cases: an example of factoring out functionality from
several locations and placing it in a single component.
For example, in the jukebox, editing a playlist and viewing a playlist both
involve retrieving it from the playlist database server. In the Scrabble
game, verifying a h u m a n player move and generating a computer player
move both involve looking up a word in the dictionary (Figure 2.3 shows
the notation for inclusion and extension relationships between use cases).
E x t e n d s Use case ucl extends use case uc2 if ucl provides additional func-
tionality t h a t may be used to carry out uc2 in certain cases. For example,
calculating a bonus score in Scrabble could be an extension of a calculate
score use case (Figure 2.3).

User
~ <<include>>

H~y::~ ~ validate
~ move ....<h<....l n c ~i~'<inl
_ _ .>>
_ -~-
~
~ d ~ pClampUter
.
~ate m~'~<<?:e@ate ~bonu

Figure 2.3: Inclusion and extension of use cases

The direction of the arrows in this notation illustrates a common principle t h a t

is used across all the UML notations: an arrow from model element me1 to
model element me2 indicates t h a t fuel depends on me2 in some sense, eg, by
18 Chapter 2. The Unitied Modelling Language

me l invoking operations of me2 or by referring to its data. In the case of

<< include >>, the use case at the source of the arrow depends on the function-
ality of the use case at the target. For << extend >>, the use case at the source
only has a meaning with respect to the use case it extends (the use case at the
target).
A use case may also depend on another, for example by needing a result
produced by another use case before it can operate itself. This type of rela-
tionship could be indicated by an unspecialised dependency arrow (dashed line,
<< use >> stereotype).
One use case may inherit another, if it is a specialised form of the other.
One actor may also inherit from another actor, this means that the specialised
actor can participate in all the use cases of its ancestor, and possibly additional
use cases. Figure 2.4 shows an example of actor inheritance: the Administrator
actor (in an estate agency system) can perform all the use cases that a Staff
can, but in addition can modify Staff data.

Staff

Administrator ~~''~-~

F i g u r e 2.4: Inheritance of use case actors

2.3 Class diagrams

Class diagrams represent the classes (the types of objects) in a system, together
with relationships that exist between them. Class diagrams can be used at
different stages of development:
 2.3. Class diagrams 19

9 Conceptual modelling of the problem domain, possibly including entities

that are external to the final developed system, but that interact with it.
9 Analysis modelling, recording in a precise but implementation-independent
manner the agreed requirements of the system.
9 Design modelling, detailing the design structures of the system, depend-
encies between classes, etc.

Generally more detail is introduced at successive levels. The earlier models

should ideally be declarative, emphasising what the system will do, free from
implementation details of how it will achieve these functionalities.
Figure 2.5 shows a very small extract from the class diagram of the Scrabble
system, in which there are two classes, Letter and Bag, and a relationship
Bag_Letter between them, representing the fact that between 0 to 100 letters
may be contained in the Scrabble bag at any point in time. This simple model

Figure 2.5: Class diagram of letters and bags

has four kinds of element in it1:

9 Classes, represented as rectangles with the name of the class at the top
of the rectangle. For example: Letter.
Class names are normally written in bold face, begin with a capital letter
and are centred in their rectangle.
9 Attributes, represented inside the box of the class to which they belong,
and written as name : type where name is the attribute name, and type
its type. For example: symbol is an attribute of Letter, describing the
printable character of the letter, and so it has type char.
Attribute names should start with a lowercase letter.
9 Relationships, represented as lines between classes. The UML term for
the simple form of relationship shown here is association. Associations
have names, by default we will take this to be C1-C2 where C1 and C2
are the names of the classes at the ends of the association. Each end of
the association can have:
- A multiplicity indication, defining how many objects of the class at
that end of the association can be associated, via the association, at
any one time with a single object of the class at the other end.
1These four elements are the only UML notation needed for purely declarative UML class
diagrams.
20 Chapter 2. The Unified Modelling Language

A role name, or association end name, by which the collection of

objects at this end, associated with a single object at the other, can
be named.
In the example, Bag_Letter is an association, with two ends:
The Bag end has multiplicity 0..1 (for each letter there is either no
bag associated to it - if it is not in a bag - or one - if it is in a bag).
There is no role name at this end.
- The Letter end has multiplicity 0..100 (each bag can contain between
0 and 100 letters) and a role name bagLetters. If b is a Bag,
b.bagLetters refers to the set of letters in the bag.
9 Constraints, written in 'dog-eared' boxes and attached to the elements
they constrain by dashed lines. Constraints give detailed properties that
the model is intended to satisfy.
In the example the constraint on Bag says that the value of bagSize
is always bagLetters.size, the number of letters in the bag. bagSize is
termed a 'derived attribute', because it is defined completely in terms of
the values of other features of the model. Such attributes are prefixed
with / on the diagram.

The easiest way to think about the meaning of a class diagram is in terms
of sets of objects. Figure 2.5 describes some properties of the sets of Letter
and Bag objects in the Scrabble system, and how these objects relate to each
other. Figure 2.6 illustrates one possible arrangement of objects that is allowed
by the class diagram. There are two Bag objects, b l and b2, and ten Letter
objects. Five letters are associated with bl and three with b2. Two letters do
not belong to any bag. The symbol and score of each letter object are written
on it, and the size of a bag is written in it.

Bag

Figure 2.6: Example of letter and bag model

 2.3. Class diagrams 21

An attribute of an object is a property that is permanently attached to it,

and cannot be removed. So each letter object lett will always have a symbol,
written as lett.symbol 'the symbol of lett', and this will be a character. Also,
each letter object will have an integer score: lett.score. The values of these
attributes may change over time (a blank square in Scrabble can be assigned
a symbol of any letter before it is placed on the board, in particular), but each
letter must have some value for each of its attributes. An attribute is rather
like a function in this respect: given an object, obj, obj.att will evaluate to a
particular value, if att has been declared to be an attribute of the class of obj.
This value will be in the declared type of att.

Rule
If att : T is listed in a class diagram as an attribute of class C, and
obj is an object of C, then obj.att is a value of type T.

Attributes may be defined as derived, meaning that their values can be

determined from the values of other features of the class. For example, bagSize
is a derived attribute of Bag, defined to have value bagLetters.size, the number
of letters of the bag. Derived attributes are written with a forward slash /
preceding their name.
Finally, we can give default initial values to attributes. These are written
after the type and an = sign in the attribute declaration, for example

moveNumber :Integer = 1

in Game in Figure 1.6. The value of the attribute is set to the default initial
value on creation of a new object of the class, unless a more specific constructor
operation is used.
At each point in time there will be a set of instances of each class. In Figure
2.6 the set of Bag instances is {bl, b2}, for example. An association is also a
set, a set of pairs or links of objects of the classes at the ends of the association.
In the above example Bag_Letter has the value

{bl ~-~ ll, bl ~-+ 13, bl ~+ 15, bl ~-+ 16,

bl ~ 17, b2 ~ 18, b2 ~ 19, b2 ~ 110}

x ~ y denotes a link between x and y.

This value for the association obeys the multiplicity assertions on the associ-
ation ends: each letter is associated with zero or one bag (no letter is associated
to both bl and b2), and each bag is associated with at most 100 letters (in fact,
no more than five).
Like attributes, role names are also functions, but they can yield, for each
object at the other end of the association, a set of objects at their own end -
the set of all those objects that are associated to the object at the opposite
end. For example

bl.bagLetters = {ll, 13, 15, 16,/7}

b2. bagLetters = { 18, 19,110}
22 Chapter 2. The Unified Modelling Language

The role name describes the role played in the association by the class at its
end.
The concepts of attribute and association end are quite similar, and have
been converged into the concept of a property in UML 2.0.

Rule
If an association between classes C1 and 6'2 is given in a class
diagram, and there is a role r at the C2 end, then for each object
obj of C1, obj.r is a set of C2 objects. If the multiplicity at the (72
end is 1, obj.r is considered to be a single 6'2 object.

C o m m o n m i s t a k e : p u t t i n g t h e m u l t i p l i c i t i e s o n t h e w r o n g e n d of
a n a s s o c i a t i o n . T h e y m u s t go o n t h e e n d n e a r e s t t h e class w h o s e
n u m b e r of i n s t a n c e s in t h e r e l a t i o n are b e i n g c o n s t r a i n e d . A role
n a m e m u s t go on t h e a s s o c i a t i o n e n d opposite to t h e class of w h i c h
it is a p r o p e r t y .
The multiplicity constraints can define any interval of natural numbers (pos-
sibly with no upper bound). The following standard notations are used to
describe these sets (Table 2.1).

UML Notation Meaning

any number of objects allowed (including zero)
1.. ~ at least one object
1 exactly one object
n exactly n objects
a..b at least a and at most b

T a b l e 2.1: Multiplicity annotations

The most common form of association is a many-one association, with a 9

multiplicity at one end and a 1 multiplicity at the other. Such an association
acts like a function of the class at the many end, associating to each instance
of this class exactly one instance of the class at the other. Figure 2.7 shows
another example of a simple class diagram, with two many-one associations.

boss 1
Person
lsubordinates Company
name: String

employees employer

F i g u r e 2.7: Employment class diagram

This model contains a self-association on Person, associating to each person

their boss (and, in the other direction, their set of subordinates). The other
 2.3. Class diagrams 23

association maps each person to the company they work for, and each company
to its set of employees.
Figure 2.8 gives an example of a situation that satisfies this diagram: there
are five persons, of which p5 and p l are their own boss, p2 has boss p l and p3
and p4 have boss p2. p5 works for company c2, the others work for company
c l. The arrows point in the direction of the 1-multiplicity association ends.

Figure 2.8: Example of Person-Companysituation

Associations can also be derived, in this case the role names of the associ-
ation are written with a prefix ' / ' in the class diagram.
Associations can have a navigation direction, indicating the direction in
which the system is expected or intended to navigate. This is indicated by
putting an arrow on the end of the association which will be navigated to
(Figure 2.9). This means that an instance of Board can refer to and call

Board
Square
placeMove(m:
Move) isOccupiedO:
boardSquare Boolean

4
I I I
IOri~176 I I~176
qoare Iqoare
IDoubleWord ITripleWord
Square Square

Figure 2.9: Navigation example

methods on instances of its squares, but that the squares are not expected
to refer to/invoke methods on their board. Arrows can be placed on both
24 Chapter 2. The Unified Modelling Language

ends if bidirectional reference is required (this should usually be avoided as it

complicates system logic). An association without arrows on either end simply
means that no information about navigation is being provided (eg, because it
is not yet known or has not yet been decided). Explicitly forbidding navigation
in a direction can be achieved by placing a diagonal cross on the end to which
navigation is not possible.
If class A can call operations of class B via a navigable association from A
to B, then A is termed a client of B, and B is a supplier of A.

2.3.1 Operations

In addition to attributes, classes may have operations or methods. The attrib-

utes and operations/methods together make up the explicit features of a class.
Operations are used to specify the behaviour of objects of a class, in particular,
how they respond to events or messages directed at them.
Operations are listed in a section of the class rectangle beneath the at-
tributes (Figure 2.10). Operation names are usually written with an initial

Game
turn: Integer
moveNumber: Integer
gameEndedO: Boolean {query}
startGameO
startMoveO
endMove(m : Move)
addPlayer(p: Player)

F i g u r e 2.10: Operation example

lowercase letter. Operations can either be query, if they do not modify the
internal state of the object, or update, if they do. Query operation declarations
can be written with a { query} constraint beside them, on a class diagram. A
query operation usually returns some property of the object state, and is quite
similar to a (derived) attribute in this respect. If g is a Game object in Figure
2.10, then g.gameEnded() is a boolean value, for example.
In contrast, startGame() is an update operation, which changes the state
of the game it operates on, to initiate the game by choosing the first player,
etc, but which does not return a value.
An operation can have input parameters, which supply information to it.
Any number of input parameters can be listed, although it is usually good
practice to try to minimise the number, endMove(m : Move) is an example
of an operation with a parameter, it supplies the move m which has been
constructed during the move, to the game, for evaluation of its validity and to
update the game board and player scores if it is valid.
 2.3. Class diagrams 25

Rules
If op(x : T) : S is a query operation of class C, obj is an object of
C, and e is a value of type T, then obj.op(e) evaluates to a value
of type S.
If op(x : T) is an update operation of class C, obj is an object
of C, and e is a value of type T, then obj.op(e) represents the
invocation of op with parameter e on obj.

The effect of an operation on the internal state of an object is usually

specified by a postcondition constraint, as described in Chapter 3 below.
We will say that an operation is declared in a class if it is written, together
with its parameters and their types, and its result type, if any, in the class box.
It is defined in a class if in addition a specification of its effect is given in that
class. Operations may be declared without being defined, this is particularly
the case for abstract operations, discussed in Section 2.3.3 below.

2.3.2 Enumerations

An enumeration is a simple enumerated type, such as { on, off} for the set of
states of a switch. It is represented as a rectangle in a class diagram, with
stereotype 2 << enumeration >> and with its values listed. Figure 2.11 shows
a basic example. If an enumeration E is defined in a class diagram then it
can be used as the type of an attribute of a class in the diagram, for example
Direction is used as the type of orientation in Word in Figure 2.11.

Direction <<enumeration>>

vertical
horizontal
Word
orientation: Direction

Figure 2.11: Enumeration example

2.3.3 Inheritance

The modelling of inheritance is one of the characteristic aspects of object-

oriented notations, which distinguishes them from earlier modelling languages
such as entity-relationship diagrams. Figure 2.12 shows a simple example of
inheritance: there are two classes, Player and HumanPlayer, linked by an
inheritance relationship. The meaning of this is that every HumanPlayer is

2A stereotype is a m a r k e r which m a y be placed on any model element, to indicate t h a t it

is a specialised kind of t h a t element. Stereotypes are w r i t t e n between double angle brackets.
26 Chapter 2. The Unified Modelling Language

also a Player: inheritance corresponds to an 'is-a' relation between objects,

in contrast to an association, which usually represents a 'has-a' relation. Se-
mantically, the set of objects of HumanPlayer is always a subset of those of
Player.

Player

name" String
score: Integer

HumanPlayer

F i g u r e 2.12: Player and Human Player

Player is called the superclass and HnmanPlayer the subclass in this rela-
tionship, and HnmanPlayer is said to inherit from Player: each feature (at-
tribute, operation or association) of Player is also implicitly a feature, with
the same name and type, of HumanPlayer, and does not have to be repeated
explicitly on the subclass.
C o m m o n m i s t a k e : r e p e a t i n g all f e a t u r e s of s u p e r c l a s s o n a s u b -
class.
Figure 2.13 shows an example of a situation that satisfies Figure 2.12. There
are four Player objects, of which p l, p3 and p4 are also in HumanPlayer.

Player

F i g u r e 2.13: Player and Human Player example

Classes may have several subclasses, for example in Figure 2.14, the class
Square has five subclasses corresponding to the five different types of square on
 2.3. Class diagrams 27

a Scrabble board: ordinary, double letter, triple letter, double word and triple
word. All of these may have a letter on them, so the Letter_Square association
only needs to be written once, on the superclass.

Square
isOccupiedO:
Boolean

I I
OrdinarySquare DoubleLetter TripleLetter
Square Square

DoubleWord TripleWord
Square Square

Figure 2.14: Subclassesof Square

Because every square must be one of these five kinds, the superclass Square
itself has no direct instances (all its instances are actually also instances of
OrdinarySquare or DoubleLetterSquare, etc). Square is termed an abstract
class, and its name is written in italic/slanting font on the class diagram to
indicate this. An abstract class cannot have direct instances created for it (cf,
in Java, new C(...) cannot be executed if C is abstract). Non-abstract classes
are termed concrete.
Like associations, an inheritance is a special kind of relationship, indeed
an inheritance can be thought of as a 0..1 to 1 association (Figure 2.15): for
each instance of the subclass there is (it is) a corresponding instance of the
superclass (cf the 'super' keyword in Java), and each superclass instance may
correspond to (may also be) an instance of the subclass.
Abstract superclasses may have abstract operations, operations for which
a specific definition cannot be given in the superclass, instead the individual
subclasses will give their own definitions. For example, a superclass Person
could have an abstract operation alcoholLimit() : Integer which returns the
weekly alcohol limit of the person in units. In subclasses Male and Female
this operation can be given specific definitions: to return 28 in the first case
and 21 in the second. In such a situation the operation is written both on the
superclass and on the subclass, since the subclass is providing a definition of
the operation. An operation is also written in the class box if it redefines an
ancestor definition. Abstract operations are written with italic font (Figure
2.16).
Cycles of inheritance are disallowed: if A inherits from B, then B cannot
inherit directly or indirectly from A. Multiple inheritance means that a class
may directly inherit from more than one other class, eg, HouseBoat inherits
28 Chapter 2. The Unified Modelling Language

Superclass

0..1
Subclass

Figure 2.15: Subclassing as association

F i g u r e 2.16: Defining methods in subclasses

 2.3. Class diagrams 29

from Residence and WaterCraft. UML permits this, but some languages, such
as Java, restrict inheritance to single inheritance: where each class can only
have at most one immediate superclass.

2.3.4 Ordered and qualified associations

The end of an association may have an annotation {ordered} beside it (see

Figure 2.17), if the multiplicity at the end is not one. The ordered annotation
means t h a t the set of objects at the role end have an ordering on them, ie,
they form a sequence, instead of an unordered set. Duplicates are not normally
allowed in such a sequence, since association links are considered to be uniquely
defined by the pair of objects that they connect.

Rack 1 Letter
IrackSize:Integert rackLetters symbol:
score:
char
Integer
0..1 {ordered}
0..7

Figure 2.17: Ordered association

An ordered association end can be thought of as an array or list: the ele-

ments of the sequence occur in a definite order and can be referred to by their
index in this order. In particular the value of r.rackLetters for a rack r is a se-
quence: the letters occur in some order left-to-right on the rack. Our notation
for accessing the first element of a sequence is r.rackLetters[1], r.rackLetters[2]
for the second, etc.
Associations may also be qualified, which means t h a t they act like maps
from a certain set of feature values, together with an object at one association
end, to identify an object or set of objects at the other end. For example each
square on the board of the Scrabble game has a unique x, y coordinate pair,
so these can be used, given a board object, to specify the square. Figure 2.18
shows the notation for this. Given a board b, and x : 1..15, y : 1..15, the square
with these coordinates is referred to as b.boardSquare[x, y].
If a qualified association role is used without qualifier values, then all ob-
jects associated at the role end are returned, regardless of index value. Thus
b.boardSquare is the set of all squares on the board b. Similarly for ordered
associations.

2.3.5 Aggregation and composition

A normal association represents the concept of 'has' between entities: 'a bag has
between 0 and 100 letters', 'a player has a game', and inheritance represents the
concept of 'is a'- 'a h u m a n player is a player', 'a double word square is a square',
30 Chapter 2. The Unified Modelling Language

Board
Square
placeMove(m: x: 1..15 [ 1
Move) y: 1..15 I boardSquare isOccupied0:
Boolean

4
I I I
[OrdinarySquare I IsD~ iTripleLetter
Square

IDoubleWord TripleWord
Square Square

Figure 2.18: Qualified association

etc. UML also has a variation on associations which represents the concept of
one object being a 'part of' another. For example 'a wheel is part of a car', or
'a square is part of a board'. The distinction between this form of association,
called aggregation or composition and ordinary associations is that it expresses
a binding/ownership between objects of one class and objects of another. The
strong form of aggregation is termed composition and is represented by a filled
diamond at the 'whole' (owner) end. It implies a constraint on the lifetimes of
the linked objects: the parts cannot exist without the whole, and vice-versa.
For example, a Scrabble board and its squares are strongly bound together in
this manner.
UML also has a weaker concept, simple aggregation, represented by an open
diamond at the 'whole' end. The meaning of this relationship is deliberately
left open by the UML definition, so that modellers can use it as required. At
most one end of an association can be an aggregation or composition.
A composition association from A (whole) to B (part) should be:

1. transitive (a part of a part is also a part of the whole)

2. irreflexive (an object can't be a part of itself)
3. one-many (no sharing of parts between different wholes)
4. deletion propagating from A to B: deleting a whole deletes all its parts.

Figure 2.19 shows the distinction between ordinary associations, aggrega-

tion and composition. The difference between (c) and (a) is that in (a) an
object of Cat can only have one owner at any given time, but it may change to
a different owner over the course of its life. In (c) a Square cannot move to a
different board: it only exists while it is part of the board it was created with,
and while that board exists.

2.4 Object diagrams

An object diagram is a variant of a class diagram in which instance specific-
ations are drawn, representing detailed specifications of objects of particular
 2.4. Object diagrams 31

(a) (b) (c)

Person Car Board

Cat
i Wheel Square

Figure 2.19: Association, aggregation and composition

classes. Both instance specifications and classes can be represented together

in the same diagram. Instance specifications usually have a name and a class,
and are represented in the diagram as a class rectangle with the name and
class underlined, for example: g:Game. Inside the rectangle the value of
attributes can be given by equalities. Figure 2.20 shows an example of an ob-
ject diagram, representing the GUI of the Scrabble system, which specifies a
mainframe: Frame object and subordinate panels, buttons and labels linked
to this. A line between instance specifications represents a description of an

boardPaneh I Button , ,I Icon

t ~ _ ~-- Panel i: 1..15 [____~ text: String . II
r l-..... ~ j: 1_15[ boart~ enabled: icon
~ Buttons I Boolean
/ / \ I visible:
/ / ~ l Boolean
/ / ~ ~ press()
~ / ~ r a c k B u t t o n _ ~ s _ __
I I / ]rmle. ~ startMoveButton:
startMoveButton
/ ~ - - - - ~ u t Button
text = "Start Move"
~ esultsPaneh
Panel cancelMoveButton:
Button
text = "Cancel Move"
1//playerLabel
Label endMoveButton:
text: String bagLabel: Label Button
visible: Boolean
text = "Bag size: " + text = "End Move"
g.gameBag.bagSize
visible = true

Figure 2.20: Object diagram of Scrabble GUI

instance of an association, that is, a link, or pair of objects in the association.

Role names are not needed unless there is ambiguity about which association
the link belongs to.
For example, the object specification of startMoveButton defines that this
is an instance of Button, and has the value "Start Move" for its text attribute.
32 Chapter 2. The Unified Modelling Language

This means that in a system that satisfies this diagram, there should be such
an object, and that it should be linked to a rackPanel object. Likewise for the
other object specifications in the model.
There are usually many ways to express a situation in a class/object dia-
gram. For example, we could alternatively model the startMoveButton,
cancelMoveButton and endMoveButton as three associations from the rackPanel
object to Button, with these rolenames on the Button end. This however makes
the expression of button-specific constraints such as text = "End Move" on
endMoveButton less obvious: the constraint would have to be placed on the
association instead of within the endMoveButton rectangle. The benefits and
drawbacks of alternative modelling choices should be considered during review
and analysis steps in a development.
C o m m o n m i s t a k e : c o n f u s i o n b e t w e e n o b j e c t s a n d classes, a n d
o b j e c t d i a g r a m s a n d class d i a g r a m s . O b j e c t d i a g r a m s o n l y d e s c r i b e
one p a r t i c u l a r a r r a n g e m e n t of specific o b j e c t s of classes, each class
d i a g r a m could have a large n u m b e r of o b j e c t d i a g r a m s w h i c h a r e
i n s t a n c e s of it, ie, t h a t d e s c r i b e a r r a n g e m e n t s of o b j e c t s a n d links
t h a t satisfy t h e class d i a g r a m p r o p e r t i e s .
Figures 2.6 and 2.13 can be directly recast as object diagrams that satisfy
the class diagrams 2.5 and 2.12 respectively.

2.5 Creating a platform-independent model

The previous sections have introduced a large amount of notation for modelling
systems - how can this notation be used in practice to create precise, detailed
but platform-independent models of a system such as the Scrabble player?

2.5.1 Defining use cases

The first step is to go through all the information that is available about the
requirements of the system, from documentation or 'stakeholders' (people with
an involvement in the commissioning or use of the system), making this in-
formation systematic by defining a number of coherent and distinct use cases
to describe the required functionalities, and by defining a class diagram to
capture the conceptual entities of the system and their properties.
For the Scrabble system we can use the existing rulebooks for the game
(summarised in Appendix A), together with practical experience of playing it,
to determine that there are only a few basic operations:

A d d p l a y e r Add a new player, up to a total of four, the player must be given

a unique name.
S t a r t g a m e For each player, randomly choose a letter from the bag. The
player with the alphabetically lowest letter (blank being before 'a') is
given the first turn. The selected letters are returned to the bag.
 2.5. Creating a platform-independent model 33

C h o o s e l e t t e r s The turn player is given a set of p random letters (or as many

letters as are in the bag, if the bag has fewer letters than this in it), where
p = 7 - r and r is their current rack size. The selected letters are placed
on the rack.
M a k e m o v e The turn player selects letters from their rack and places them
on the board. The move is checked for validity and committed to the
board if valid, and the player's score is updated.
E n d g a m e Occurs when the bag is empty and one of the players has an empty
rack, or by agreement between the players. The final score of each player
is decreased by the sum of the letters remaining on their r a c k - the player
who has an empty rack gets their score increased by all the letters from
the other players.

Figure 2.21 shows the use cases. We have divided the make move use case into
two, since the behaviour in the human and computer player cases will be quite
different.

player~

Human ~ Computer
Player Player

F i g u r e 2.21: Use cases for Scrabble player

2.5.2 Defining entities and associations

For the data model, the first step is to identify the entities in the system - a
basic way of doing this is to list the nouns in the requirements statement and
discard those that are non-specific to the system. For the Scrabble system the
key nouns appear to be:

player, game, score-keeper, score, turn, score sheet, tile, bag, blank,
rack, board, word, square, line, dictionary, double letter square,
34 Chapter 2. The Unified Modelling Language

centre square, row, column, premium square, triple word square,

double word square.

The software itself will play the role of the score-keeper and score sheet, so
these entities are not explicitly needed. Score and turn are attributes rather
than entities in their own right (each player and played word has a score, for
example). There are many kinds of square mentioned, suggesting already that
inheritance will be useful to describe these.
Having identified the main candidates for entities, we can start to determine
what attributes and properties they have, and what relationships they have
with each other:

B o a r d : Consists of 15 by 15 squares, with certain positions identified as premium

squares of various kinds (Figure 2.22). Therefore there is an association
to the Square entity of multiplicity 225 at the Square end and 1 at the
Board end.
S q u a r e : Several kinds are needed: ordinary, double letter, double word, triple
letter, triple word. Each has a different visual icon (an attribute or as-
sociation of Square) and each may contain a tile (an association from
Square, 0..1 at the Tile end).
Tile: Each is marked with a letter 'a' through to 'z' plus a blank, and with
a score (integer 0..10). These are both attributes of a tile. There are
exactly 100 tiles, with the number of each letter specified (eg, 12 'e's in
English Scrabble).
R a c k : One for each player. A rack may hold up to seven tiles (ie, there is an
association to Tile of multiplicity 0..7 at the Tile end). There must be
an operation to add a set of tiles to a rack.
Bag: Initially contains all 100 tiles. It must have an operation to remove and
output randomly-selected sets of tiles from itself.
G a m e : Has between two to four players, one board and one bag (associations
from Game to these entities). There is a current turn player once the
game has started (an association to Player).
P l a y e r : Has a rack (association) and a score (attribute). Can be either a
human or computer player.
D i c t i o n a r y : Contains a set of words, which is used to decide if a played word
is valid - s o it must have a lookup(w : Word) : Boolean operation.

Putting all these facts together, we can draw an initial class diagram (Figure
2.23).
To refine this model we consider what other information and properties will
be needed in the software system (as opposed to what information is present in
the physical board game). For example, it will be useful for each player to be
given a name, so their score can be displayed on the system GUI. In addition,
one of the requirements specified that a history of moves should be kept, so this
needs to be added as an extra association from Game. Attribute types could
be made more precise, for example the score of a tile must be between 0 and
10, so we could write score : 0..10 in the Tile class. This could be over-specific,
 2.5. Creating a platform-independent model 35

Figure 2 . 2 2 : Scrabble board

Board r
game -- J Square
Boar/~ 1 22-~ x" 1 15
/ 1 - boardSq . . . . ~ 1::15
Game ~ isO~():
moveNumber" 1 Boolean
Integer = 1 ~ / 0"1 IgetTileS.... 0:
1 1 ~ -- [ Integer

I ~1,
] _ ~a~ Bag OrdinarySquare DoubleLetter ITripleLetter
~0..1 \1 Bag [/bagSize: 0..100 [ I [Sq. . . . I [Sq. . . .
\ . _ ~ \~isEmpty0: Boolean I
{subset}: ,.~ IgiveTiles(x: I DoubleWord TripleWord
~.-'" ~ [ Integer): Setl ISq. . . . ] ISq . . . . I
01"9 squareTile
~'layers~'~ 2"'4 bag 0..100~ 0..1
Player_~
Tiles Tile 100 Word
current \ score: I n t e g e r [ [symbol: char *lallWords
Player 1\ / rackTales~ ...... Integer
/ o..7/I~ c--~6
1l ~ a y e r R a c k / / ~ . . 1 [ Dicta. . . . y
[H . . . . PI. . . . I ~ looknp(w--------~"
Word)------~"
I J I . [/rackSaze: @.7 Boolean
I I [addTiles(l: Set)
C~ / . . . . . . Tiles(s:et)

Figure 2 . 2 3 : Initial Scrabble class diagram

36 Chapter 2. The Unified Modelling Language

however, preventing our specification being used for non-English versions of

Scrabble where scores higher than 10 may be possible.
We should examine existing associations to see if their multiplicities are
precise enough, or can be made more specific. In addition, cases where an
association end should be ordered can be identified: the players role has a
natural o r d e r i n g - the order in which players take their turn - so this should be
documented. Having done this we can optimise the currentPlayer association
and replace it with an integer index turn into the players sequence.

Guideline
Simplify the data of a class diagram where possible. In particular
if a class C has an ordered role drl from itself to a class D, and a
1-multiplicity role dr2 to D, with property dr2 : drl, then dr2 can
be replaced by an integer attribute index of C, with the element
drx[index] taking the place of dr2.

Similarly, the linear list of board squares can be rationalised into a double
array structure corresponding to the physical layout of the board. The names
used for classes and class features should also be reviewed, to determine if they
can be improved. In this system we decide to rename Tile to Letter because
'tile' is a technical term specific to the physical version of the board game,
which is not as implementation-independent or as generally comprehensible as
the name 'letter'.
Figure 2.24 shows the class diagram after these rationalisations.

2.6 Exercises

1 Draw a use case diagram and class diagram to represent the following
system.
9 Over the summer holiday, university students can book college hall ac-
commodation online. They must specify their name, student number,
course, year, and identify three college residences as their preferences.
9 The system makes an allocation of students to rooms before the start
of term, trying, where possible, to allocate students to a room in one of
their preferred halls.

2 Is it possible to create an object of class A in Figure 2.25? Give an argument

to justify your answer.

3 In Figure 2.26, what is the maximum number of users that can be given
aliases, given that each user has five aliases, and there are at most 100 user
names available?

Draw a class diagram for a conservatory design system: this system enables
the planning of proposed conservatories in terms of their dimensions (height,
 2.6. Exercises 37

Board ]
game -- [_~ Square
Board/placeMove(m: Ix: 1..15 I 1 ......
/ Mo e~I . .. I lsuccupleo():
Game ] / 1 v ~{y: a.l~ I boardSquare Boolean
turn"9 1""4 [ ~ getSquare(i-
. . . . . • 1""15~ getLetterScore0:
moveNumber: [1// j: t..t3): ~ q u a r ~ Int g
Integer = 1 ~ f / ~ 0..1 eer
startGame0 ],~..
gameEnded0: [l ~ /\
Booleanl ~ ~-~
endMove(m: Move) I ~ 1 I
addPlayer(p: Player) ] ~ , a ~ OrdinarySquare DoubleLetter TripleLetter
/1 ~ Bag ~ ; g S ~ i)..0.~o0~o!ean I I lSq. . . . [ ]Sq. . . .
/ ~ [giveI~etters(x:_ I DouhleWord TripleWord
/ nl. . . . s~ I lntege~)~Set ] ISq. . . . [ ISq. . . . [
/ players ~ 0..1 ~ sq. . . . Letter
/ Io r ~ hag 0..100"~ 0..1
/ ~ Letters Letter 100
/ [. . . . . Str!ng I ]symbol: char
/ I {identity} I rackLetters / score: Integer
/ I...... Integer [ {ordered}~Only}
/ I /~ 1"x 1 [playerRack ~ . . 1 setSymboi(c: char----) * ~ allWords

I I H umanPlayer
I ~ ~~r: rackg
Rack. ,o f17 1 */
] ' _' ] addLetlers(l: / Dicti. . . . y
/ ] ComputerPlayer[[] Set) / lookup(w: Word):
l ~ S [ . . . . . . Letters(l: / Boolean
9 ] history {ordered} ~ I Set) ]
Move I * ~ l 0..1/
...... Integer 1 ~ *~
validateMove( [1 *x ~ /
n-,nteger,- I 'ette~~ r
B~176 r I
calculateScore( [ ] ]
b: Board):
Integer

F i g u r e 2.24: Refined Scrabble class diagram

rl 1
A

r2

F i g u r e 2.25" Self association

User UserName 10
0..1 alias text: String

F i g u r e 2.26" Users and aliases

38 Chapter 2. The Unified Modelling Language

width and depth, all in millimetres), style (Victorian or Contemporary), glass

type (single or double glazed) and number of doors. Each conservatory will be
constructed from a number of modules, which can be either door, window or
wall modules, and which have a fixed height and width, and a style and glass
type (as for conservatories).

5 Draw a class diagram for a conference centre booking system, which allows
customers to book conference rooms for specified time slots (given by a date
and start and end time). A room has an integer capacity and a set of facilities,
such as projectors and PA.

6 Express Figure 2.8 as an object diagram.

7 Express Figure 2.13 as an object diagram.

Define a use case diagram for the following ambulance dispatch system:
9 The system receives notification from the emergency services when a new
incident occurs requiring ambulance attendance.
9 The system then tries to find a free ambulance which is sufficiently near
to the incident and then to a hospital so that the patients can be delivered
to hospital within 30 minutes (15 for a serious emergency).
9 If an ambulance can be found, the one with the shortest distance to the
incident is dispatched.
9 Ambulance crews notify the system when they reach an incident and
complete their journey delivering the patients to hospital, and on return
to their ambulance station.

9 Draw a class diagram for a multi-language translation dictionary, which

represents words in (for example) English, Russian, Spanish, French, etc, and
records which words translate to which others. A word consists of a sequence of
letters, and a letter has a symbol. A word has properties such as the language
to which it belongs, its gender (some languages have two or three 'genders'
for their words), the case of the word (eg, imperative case for words that issue
commands), and the tense of the word (eg, future, past, etc). A translation may
have a hint string, which is supposed to help the user remember the translation.
Eg, the translation of the Russian word 6eao6paaHbr~ into the English 'ugly'
could have the hint 'Beelzebub', which is approximately what the Russian word
sounds like.

10 Draw a class diagram for an estate agents' database, which records details
of properties, their asking price and the minimum price that the vendor will
accept, their location, if they are freehold or not, and the details of their seller.
The size of the property in metres squared and feet squared should also be
given (one square metre is ten square feet).
The contents of the property are described as a set of spaces, which can be
either rooms, hallways, roof terraces, garden areas, outbuildings, etc. Each has
2.6. Exercises 39

a textual description, possibly a photograph, and a size specification (width

and depth in metres and feet).

I1 What are the multiplicities of the role ends (both called spouses) of an
association representing the relationship of marriage (under UK or USA law),
between subclasses Male and Female of Person?
What additional constraint should be added if the association is viewed as
a self-association on Person?
Chapter 3

The Object Constraint Language

In this chapter we describe the UML constraint language, OCL, and a subset,
LOCA, of OCL. OCL is a means to express more complex properties of diagram
elements, and interrelationships between elements. OCL is defined for version
2.0 of the UML [34], and this is the version we will base our own constraint
language, LOCA, on.

3.1 Using OCL and LOCA Constraints

In a class diagram, constraints are used to:

1. Express invariants of classes - properties relating the attributes and role-

names of the class, which are expected to be true for each object of the
class, at all times when the object is not executing a method.
2. Express preconditions of operations of a class - properties of the object re-
sponding to the operation, and of the operation input parameters, which
are required to be true when it starts execution.
3. Express postconditions of operations of a class - properties of the ob-
ject responding to the operation, and of the operation output parameter
result, if present, which are required to be true when the operation com-
pletes execution.

To these we add a further category:

9 Properties which relate the state of several classes, in particular, the

states of objects of these classes which are linked by specific associations
between them.

Full OCL notation is itself a complex language [34] which contains four
different forms of collection: sets, ordered sets (sequences without duplicates),
sequences and bags (multisets), many operations on these and on single valued
data, quantifiers, and the capability for auxiliary and recursive definitions. Here
we will use a simplified subset of OCL which is adequate for most purposes.

40
 3.1. Using OCL and LOCA Constraints 41

Table 3.1 shows the syntax of this subset, which is known as L O C A (Logic
of Objects, Constraints and Associations). A valueseq is a comma-separated

< value > "'= < ident > I < number > I < string > I < boolean >
< objectref > ::= < ident > I
< objectref >. < ident > l
< objectref > I( < expression > )
< arrayref > ::= < objectref >1
< objectref > [< value >]
< factor > "'= < value > I { < values eq > }I
S~qu~.r < v a l ~ q > } l < a~ay~4 >l
< factor > opl < factor >
< expression l > "- < factor > op2 < factor >
< expression > "= < expression l >1 ( < expression > ) I
< expression1 > op3 < expression >
invariant > "= expression >1
expression > => < expression >

T a b l e 3.1" LOCA syntax

sequence of values, an opl is a factor-level operator such as +, - , . , /, ~', / \

or \ / , an op2 is a comparator: =, / - , >, > - , <, < - , :, / :, <: or / <:, an
op3 is &, or.
There are also several built-in constraints for class diagrams, expressed
as keywords written between curly brackets. {ordered} and {query} are two
examples we've already seen. Table 3.2 lists some others, and what model
elements they apply to. To indicate that a class or operation is abstract, its
name is written in italic font. To indicate that an attribute or operation has
class scope (ie, it is static), its name and type are underlined in a class diagram.
An example of the union constraint could be an association from a Letter to
a Container in the Scrabble system (Figure 3.1), where Container generalises
Rack, Bag and Square, and the L e t t e r _ C o n t a i n e r association is the union of the
specific 'containment' associations between letters and their containers. W h a t
this expresses is that each letter can be held in only one of these three locations.
Formally:

holds- rackHolds \ / bagHolds \ / s q u a r e H o l d s

is an invariant of Letter. The notation {subsets holds} expresses the subset

constraint. A union association is analogous to an abstract class: each link
in the union association must actually be a member of one of its subset asso-
ciations (italic font could be used for such 'abstract' roles to emphasise this,
perhaps).
We will also use additional constraints, defined in Table 3.3.
We will use subset as a constraint between association ends at the same
class to indicate that the set of objects at one end is always a subset of those at
the other, and use disjoint on association ends to indicate that two association
42 Chapter 3. The Object Constraint Language

Keyword Constrains Meaning

subset two associations rl, r2 Every link in rl is in r2.
addOnly an association end Objects cannot be removed
from the end.
Union an association Association is union of all
associations that subset it.
query an operation Operation does not
modify object state.
unique a multivalued The value of the feature
attribute (a collection) has no
or role duplicates.
readOnly attribute or role The element cannot be modified
after it is initially set.
UML 1.*: 'frozen'.
abstract class Has no instances of its own.
operation Has no implementation
in this class.
leaf class The class cannot have any subclasses.
operation Operation cannot be overridden
in any subclass.
sequential operation Concurrent executions of
operation should not occur on
a particular object.
class Only one operation of the class should
be executing at any time on any specific
object of the class.
static attribute or operation Feature belongs to class,
not to object. That is,
there is only one copy of it
in the system, not one copy
for each object of the class.
UML 1.*: 'classScope'.

Table 3.2: Built-in constraints

Keyword Constrains Meaning

identity an a t t r i b u t e any two different objects of the
class have different values
of the a t t r i b u t e .
an a t t r i b u t e a t t r i b u t e represents an i n p u t
to system, eg, a sensor reading.
an a t t r i b u t e a t t r i b u t e represents an o u t p u t
of system, eg, an a c t u a t o r setting.

T a b l e 3.3: Additional constraints

Discovering Diverse Content Through
Random Scribd Documents
 On the left of the entrance door,
between it and the window, is a
small square-headed doorway, 2
feet broad, and no doubt intended
to be concealed by tapestry, which
opens into a lobby whence an
ascent of six steps leads by a
passage 10 feet long into a
triangular garderobe chamber, in
the substance of the wall. The
vent discharges by a flush opening
in the face of the outer wall above
the base. This chamber has an
exterior loop.
At the opposite side of the great
chamber to the entrance door from
below, a door similar to it opens
upon a lobby 3 feet 10 inches by 7
feet 6 inches, whence rises a
second staircase of thirty-four
steps, leading to the third floor. The passage is vaulted like that
below, but is only 3 feet 6 inches broad. It also winds with the wall,
crossing over the great window, and terminates in a lobby 3 feet 11
inches broad by 5 feet 5 inches deep, lighted by a loop. The outer
wall of the staircase is 5 feet 5 inches thick, the inner wall something
less, the whole thickness being 12 feet 6 inches. The lobby opens by
a full-centred doorway 3 feet 6 inches broad, into the third floor.
The third or oratory floor, has a set-off of 12 inches for the floor,
and is therefore 27 feet diameter. It is 16 feet 6 inches high. To the
south-west is a window closely resembling that below, also with
steps and side seats. There is also a fireplace above the last, rather
smaller and more delicate in its details, but of the same pattern and
construction. The lintel is composed of seven stones, joggled; it does
not extend from wall to wall, but stops, as is more usual, just clear
of the jambs. The vent runs in front of the lower one, and joins it
above. Above the lower water drain is a second, in a small sort of
piscina recess, round-headed and trefoiled with cusps, but not
chamfered.

A·S·Ellis
THIRD FLOOR PLAN.

The oratory is a very remarkable feature in this floor. It occupies

the south-eastern buttress, opposite to the fireplace. A doorway of 2
feet 6 inches opening, the only flat-topped one on this floor, very
plain, and therefore meant to be concealed, opens into a short,
straight passage leading direct into the oratory. This is in plan a
hexagon, 6 feet 4 inches broad at the west end or entrance, 6 feet
at the east or altar end, and having a length of 13 feet 6 inches
contained between four sides averaging 6 feet. Its centre or
broadest part is 8 feet 8 inches. In each of its four main angles,
flanking the entrances and the altar, is a detached or nook-shaft 6
inches diameter, with a foliated capital. The two central angles are
each occupied by a half-shaft, from which springs a triple cross rib,
of which the laterals are plain rolls, and the central worked in a
chevron pattern. The area is thus divided into a western and an
eastern half, of which the latter is rather the smaller, and may be
taken to represent the chancel. Each division is crossed diagonally
by two ribs, in section plain bold rolls, at the intersections of which
are bosses of which the stones are big enough to form not only the
boss, but about six inches of each of its four ribs, and in one case
the division between the ribs is carved with flowers, with good
effect. The bosses are carved, that to the west with a sort of cross
moline, shown in the drawing, that next the altar with flowers. At
the main angles the ribs spring from the shafts, but the triple cross
ribs spring from a sort of prolongation of the capital and abacus of
the half-shafts. The shafts flanking the altar have capitals more
ornate than the rest. The east window is a mere loop 6 inches broad
and 2 feet 6 inches high, round-headed, and placed in a splayed
recess of which the angles are replaced by a bold roll with foliated
bases. This, again, stands within a second and shallower recess,
flanked with small nook-shafts of which the capitals, delicately
carved, range with those in the flanking angles. The head is cut in
chevron pattern. Right and left are two small lights, quatrefoiled, but
splayed inwards into circular recesses, 2 feet 8 inches diameter.
Outside is a hollow moulding containing knobs or balls scarcely seen
from below. These windows have been called insertions, but, though
no doubt of a somewhat Decorated character, they have every
appearance of being original, and similar openings may be seen in
the west front, and near the summit of the very fine Early English
tower of Old Malton Church. Below each light is a trefoil-headed
piscina of 1 foot 6 inches opening by 11 inches deep, of which that
in the north wall has a minute nailhead moulding. The height to the
crown of the vault is about 14 feet, gained by stilting the arch. The
altar is gone.
CONISBOROUGH CASTLE.—INTERIOR OF THE KEEP.
(From the Window Recess on Second Floor.)

CONISBOROUGH CASTLE.—INTERIOR OF THE

ORATORY OR CHAPEL.
 CAPITALS OF CENTRE ARCH, NORTH SIDE.

On the left, on entering the oratory, a small flat-topped doorway

leads into a mural vestry of irregular form, about 9 feet long by 5
feet broad, with a splayed loop, and in the end wall a trefoil-headed
locker 2 feet broad by 1 foot 6 inches deep. The vestry is very
plainly vaulted, the arch being a lean-to against the wall of the
oratory.
 PLAN AT RAMPART LEVEL.

Between the oratory door and the fireplace, to the north, a

doorway of 3 feet 4 inches opening enters a lobby 3 feet 10 inches
by 7 feet, whence a staircase of twenty-four stairs ascends, winding
with the wall, to the battlements and the fourth story. The staircase
is 4 feet broad, and vaulted with hanging ribs. The two lower
staircases ascend from east to west by the north, this ascends from
west to east, also by the north, and passes over the vestry. In the
lobby is a door 1 foot 9 inches opening, whence a bent passage 3
feet 4 inches broad, leads to a garderobe, the seat of which rests
upon an oblique or squint arch, which springs across the hollow
angle between the tower wall and one of the buttresses, and is
placed, inconveniently enough, over the loop at the head of the first
flight of stairs. Over the seat is a loop. Garderobes so placed, over a
hollow angle, are common in the Decorated period, but there is one
on the outer wall at Kenilworth, probably late Norman.
 The staircase from this stage ends under a sort of hood which
stands in and nearly blocks up the rampart walk, leaving a passage
only 2 feet 3 inches wide between it and the wall of the battlement.
The tower wall at the level of the rampart walk is 12 feet 6 inches
thick, of which the battlement wall occupies 2 feet, the rampart walk
8 feet, and an inner wall 2 feet 6 inches, within which was the upper
or fourth floor. The rampart walk was thus a gallery open above,
having the battlement wall outside, and the wall of the upper floor in
its rear. The vents of the two fireplaces were connected with this
inner wall, and reached its summit by an opening 7 inches by 12
inches, divided by a tile-stone 6 inches thick. This aperture is
contained within the base of a chimney-shaft 3 feet 9 inches by 3
feet. This shaft, like the stair-hood, somewhat reduced the breadth
of the rampart walk. The upper part is gone. The dividing stones end
about 2 feet below the rampart level, above which the vents were
combined.
The six buttresses rose as
turrets above the crest of the
parapet. That to the north-west,
near the chimney-shaft, and its
neighbour westward, contain half-
round recesses, round the curve of
which are short staircases, opening
from the rampart walk, and which
probably ascended to small
parapeted platforms, now gone.
The buttress to the south contains, as at Orford, an oven, circular, 7
feet across, with a segmental arched door 2 feet wide. The two
buttresses to the north and north-east are occupied by two cavities,
probably cisterns, half-hexagons in plan, and 2 feet 6 inches deep
below the rampart wall level. Each would contain about 650 gallons.
The remaining buttress, that above the oratory, contains a half-
hexagonal recess or alcove, the floor of which is 9 inches above the
rampart wall. It is 9 feet broad at the opening, 5 feet broad at the
end, and 8 feet 8 inches deep. It is covered in with a round-headed
vault tapering to fit the plan. The height at the entrance is 7 feet 6
inches, and at the inner end 5 feet 7 inches. There are no loops, but
the walls of this chamber and the adjacent parts of the parapet are
pierced by a number of holes, about 6 inches high by 5 inches
broad. These have been supposed to be intended to carry the floor
spars of a bretasche or wooden gallery, though they are small for
such a purpose, and there are no holes or corbels below for struts.
Moreover, these holes are confined to the buttress over the oratory
and the adjacent walls, and are not straight (see plan). They extend,
it is true, over the main entrance, but had they been intended for its
defence they would probably have been placed with the door
beneath their centre instead of below one end of the line. That is,
they would have been placed in the two flanking buttresses as well
as in the bay between them. It has been suggested that these are
pigeon-holes, and no doubt, during a strict siege a good supply of
these birds might have been found useful. There are certain holes in
the keep at Rochester, that probably were so intended, and that are,
or recently were, so used.
 A·S·Ellis
SUGGESTED ORIGINAL APPEARANCE.

The height of the parapet is 6 feet 6 inches, and the pattern of the
coping may be seen at the junction with the buttress turrets, and
this also shows that the roof was confined to the inner circle, and
did not project over the parapet. There are also traces showing that
the embrasures contained, as at Alnwick, a hanging shutter.
The inner circle, or chamber within the inner walls, was 27 feet
diameter, and its flooring rested upon a range of nineteen plain
corbels. Only the lower part of the wall of this chamber remains, but
the jambs of a doorway show that it was entered from the rampart
walk. The wall, and consequently the chamber, was about 7 feet
high, and upon it was a conical covering, the eaves of which must
have projected somewhat over, and discharged their water into the
rampart walk. This mode of finishing off the summit of a tower, by
placing the uppermost floor within the circuit of the rampart walk
and leaving the battlements free from the roof, is seen in its greatest
completeness at Coucy, and what is there seen illustrates what must
have been the arrangement here, at Pembroke, at Martens Tower,
Chepstow, and in the smaller and later flanking towers of Holyrood
House. It is obvious that unless the roof sprung here from a wall
within the parapets, or unless there was a timber gallery carried
round outside the wall, such a tower as this could not be defended.
Its loops were intended for light and air, not for defence; this could
only have been directed from the battlements. Hence the absurdity
of covering in towers intended for defence, or at any rate to have
the appearance of being defensible, with conical roofs springing from
the outer wall.
Of course the accommodations of such a tower as this of
Conisborough were not such as to suit its lords, still less their ladies,
save under the pressure or in expectation of a siege, a remark which
applies to all, save the largest, keeps. The passive strength of
Conisborough, and its rocky base, secured it against attacks even if
seconded by engineering machinery. No catapult or battering-ram
would be at all likely to shake or break it. The peril to be guarded
against was a blockade, and with this view there was a well within
the tower, and the two lower floors, it is clear, were intended for the
storage of provisions. The first floor would be the ordinary room of
the constable, or lord, and of his family or guests; the men,
probably, also sleeping there. The room above would be the ladies’
room, with the oratory close at hand. The kitchen was above all, and
there, also, at the battlement level, would be the lodging of the
small garrison, probably of not more than ten or a dozen picked
men, with a ready communication with the ramparts.
 The fashion of round keep towers, quite different from the shell
keeps, came in towards the close of the Norman and during the
Early English period of architecture, when frequent communication
with the East had affected men’s military ideas. A few, such as
Brunless, Tretower, Launceston, and Orford, are found in England of
that time, but in France there are many, widely spread, and very
grand examples. Philip Augustus was a great builder of such towers.
That of the Louvre, of which the circular foundations, with the well
and the sewer, were uncovered a few years ago, was his work, and
to the same period, though late in it, 1223–30, belongs the Tower of
Coucy, probably the finest military structure ever built.
Taking a general view of the Castle of Conisborough, and giving
due weight to the value of the evidence afforded by its remains, it is
clear that the excavation of the ditch, both of the hill and the
outwork, and the scarping of the former, were the original and
English works, to which an early, though not the earliest, Norman
lord added the curtain wall of the enceinte, and much of the lower
gatehouse. He certainly also built a hall, kitchen, and lodgings within
the inner area. The next addition of importance, the keep, was
certainly made a century later. The curtain wall was taken down to
make room for a part of it, and not only was there no bond between
the old wall and the new tower, but the junction was carelessly and
clumsily effected, as may be seen from its present condition.
Probably some later alterations were made as regards the hall and
lodgings. The wall near the entrance to the inner ward seems to
have been partially rebuilt, but subsequently to this there does not
seem to have been any addition of importance. The castle was no
doubt rendered untenable during the wars of Charles I., and time
and neglect have since completed the ruin.
It is singular that so strong and so remarkable a fortress should be
but little noticed in the earlier records. Invention, indeed, in the
absence of evidence, has attempted to fasten upon it an early
history. “Conyng” has, by British antiquaries, been converted into a
Breton Conan, and Caer-Conan, thus constructed, has been mixed
up with Aurelius Ambrosius and the Kentish Hengist, who is asserted
to have here fought, been slain and buried. There is, however, no
evidence whatever connecting this place with either the Britons or
Bretons, or the Romans, or Hengist. Everything bearing upon its
origin is Saxon, but Saxon of a much later date than Hengist. Two
tombstones carved in what is generally regarded as a præconquistal
style were long seen in the churchyard, and are now placed for
security in the church—so securely placed, indeed, as to be scarcely
visible. The earliest mention of the place is probably in the
testament of Wulfric Spot, the minister of King Ethelred, and the
founder, in 1004, of the Abbey of Burton-on-Trent. By this document,
printed by Dugdale in his Monasticon [I. 266], Wulfric bequeaths to
Ælfred certain lands and fisheries of Cunuzesbury, so that about a.d.
1000 it belonged to that great Saxon. Mr. Hunter, whose history of
Conisborough leaves nothing to be desired, points out that this
devise was really a very ample one, for the fisheries were not those
of the Don but of a part of the Soke of Hatfield, which were of great
value. In Domesday, the lord of “Coningesboro” had twenty fisheries
at Tudworth, yielding each 1,000 eels, and long afterwards they
were important enough to be specially recorded. It seems therefore
probable that, at least as early as the year 1000, Conisborough was
the head of a large estate or Soke. The name of “Moothill field,”
borne by an enclosure about three-quarters of a mile south-east of
the castle, indicates the place of the court for the liberty or
jurisdiction. The hill has been removed. There is a Moot-hall near the
church.
While the castle has retained something of its ancient name, that
of the ferry over the Don at its foot has undergone translation, and
is known as Kingsferry. Who the king was who gave name to both
has long been unknown; probably he was of Northumbria. The old
Soke, the growth of centuries, received its final consolidation at the
Conquest, when it was granted by William the King to William Earl
Warren. At that time the fee was probably one extensive parish, for
Conisborough seems to have been the mother church of Barthwell,
Hatfield, and Sandal, three churches named in Domesday.
Conisborough as a parish church, therefore, thinks Mr. Hunter, can
scarcely be later than Ælfred, and may be older than even Doncaster
itself. Such is the antiquity of the memories and speculations with
which this very remarkable place is associated.
Immediately before the Conquest it belonged to Harold the Earl.
Earl Warren evidently took it as it stood, and seated himself in the
English “Aula” at Conisborough, having about him the twenty-eight
vills which either wholly or in part were appended to it, and which
included much of the Wapentakes of Strafordes and Siraches. These
were the lands “quæ pertinent ad Coningesberc,” and which formed
the “Socæ pertinens.”
The possessions of Earl Warren in England were extensive, but
were especially valuable in Sussex, Norfolk, and Yorkshire; and what
Lewes was to the former Conisborough was to the latter, and as the
Soke became an Honour the castle was its “caput.” In Earl Warren’s
foundation charter to Lewes Priory in 1078, it is provided that the
monks should find him lodgings as he went and returned from
Yorkshire, so that when he crossed from Normandy he took Lewes
on his way. The connexion between his two lordships he cemented
by giving to Lewes the church of Conisborough. Earl William was
created Earl of Surrey about 1088, and died in 1089, and among his
possessions stand enumerated the Lordship and Soke of
Conisborough, with twenty-eight vills and hamlets.
II. William Earl of Surrey, son and heir, supported Robert Curthose
against Henry II., and with him retired to Normandy. On being
pardoned, and his earldom of Surrey restored, he changed sides and
fought for Henry at Tinchebrai. He gave to Roche Abbey the tythe of
his Hatfield fisheries. He died 1138.
III. William Earl of Surrey, his son and heir, the third earl, joined in
the mixed French, German, and English Crusade in 1145, during
which, in 1148, he fell, leaving a daughter and heiress.
IV. Isabel de Warren, who married, first, William de Blois, a natural
son of King Stephen; and, secondly, Hameline Plantagenet, natural
son of Geoffry Earl of Anjou, and half-brother to Henry II.
 William was Earl of Boulogne and Mortaigne, and, by his wife,
possibly of Surrey. He died childless 1160.
King Henry seems to have taken and held the earldoms for a while
in his own hands, but, in 1163, Isabel married Hameline
Plantagenet, who enjoyed her honours and estates and, 12 Henry
II., paid scutage on sixty knights’ fees. Hameline bore the probably
Norman title of Earl Warren, and was an active soldier in his day, a
faithful servant to Richard I., and much employed in transactions
both of peace and war. Also, though engaged occasionally in
Normandy, he appears to have passed most of his time in England,
and was by no means an unlikely man to have added the keep to his
castle of Conisborough. He died 3 John, 1201, Isabel having died in
1199. Their son succeeded. Earl Hameline founded an endowment
for a priest for the chapel of St. Philip and James within the castle.
This probably stood in the courtyard for the use of the garrison, for,
11 Edward II., the Earl of Lancaster gave timber from the wood of
Conisborough to repair the roof of the chapel within the castle,
which therefore could not be the oratory in the keep, which is
vaulted. King John was here March 12, 1201, probably taking
advantage of the earl’s death to view the castle and possessions.
V. William Plantagenet, or de Warren, son and heir of Hameline
and Isabel, who succeeded as fourth Earl of Surrey, was probably
then of age, as he had livery at the least of some of his lands, 4
John, 1202. He held the earldom for an unusually long time, and
much added to its wealth and consequence. As a Magna Charta
Baron, he behaved with great moderation, and upon John’s death he
swore allegiance to Henry. He married, first, Maud, a daughter of the
Earl of Arundel; and, secondly, Maud, widow of Hugh Bigot, Earl of
Norfolk and Earl Marshal, by a daughter of the great William
Marshal. He died 1240, 24–5 Henry III., leaving a son, John. Maud,
the earl’s widow, had livery, 30 Henry III., of the rod and office of
Earl Marshal, as elder co-heir of her brother. She also held the
custody of the castles of Conisborough and Chepstow until her death
in 1246, 32 Henry III.
 Their son and successor, VI. John, fifth Earl of Surrey, who
succeeded at five years old, married in 1247, being then very young,
Alice le Brun, who died 1290, half-sister of Henry III. In 1254 he
paid an aid upon sixty knights’ fees. He lacked much of the prudence
of his father, and his general character was scarcely in accord with
his famous answer to the “Quo Warranto” of Edward I., to whom,
however, he was a better subject than to his sire. He died 32 Edward
I., 1304, having held the earldom sixty-four years. He was
summoned to Parliament as Earl of Surrey and Sussex.
William his son died 14 Edward I., 1286, and therefore before his
father. His son, and the successor to the earldom, was, VII. John de
Warren or Plantagenet, sixth Earl of Surrey, a posthumous child,
born 1286. When nineteen years of age, he married Joan, daughter
of the Earl of Barr, but had by her no issue. 17 Edward II.
Conisborough Castle was in the king’s hands, and 18 Edward II. he
appointed the Constable. 19 Edward II. the earl recovered his
estates, but had surrendered them to the king and his heirs, taking a
re-grant for his own life. He was also both Earl of Sussex and Earl of
Strathern in Scotland. Joan Countess of Surrey was at her castles at
Sandal and Conisborough in 1314.
Earl John died 1347, and his will is dated from Conisburgh Castle,
and the title of Surrey seems to have gone to Edward Earl of
Arundel, son of Alice, Earl John’s sister. Besides natural daughters,
he left two sons by Maud de Nerford, John and Thomas de Warren,
to whom and their mother he left, with the king’s permission, a very
considerable property, including Conisborough. Thomas Earl of
Lancaster seems to have obtained from Earl John some sort of
forced occupation of Conisborough, which came to an end upon his
attainder, so that Earl John recovered and died seized of it.
About its descent there is some uncertainty, for Henry, the brother
and heir of Earl Thomas of Lancaster, did homage for the castle, 1
Edward III., to which John, Earl Warren, laid claim. Earl John held it
5 Edward III., and agreed to a grant of 65 acres of the waste lands
of the manor by the king to William de Skargill. Similar grants were
made in the five following years by the earl and confirmed by the
king, with a note that the earl’s tenure was for life only.
Probably the children of Maud de Nerford found it to their interest
to allow the Crown to possess the castle, for at Earl John’s death it
was held by Edward III., who granted the castle to Edmund of
Langley, his fifth son, afterwards Duke of York, who died 1402, from
whom it descended to his son Edward, also Duke of York. He fell at
Agincourt, childless, 1415, and was succeeded by Richard, son to his
brother Richard Earl of Cambridge. He became Duke of York, and
was called also Richard of Conisborough, from his birth in the castle.
Richard, who was great-grandson of Edward III. and father of
Edward IV., was slain at Wakefield, 1460. His second wife and
widow, Maud Clifford, held the castle in dower, and lived here. She
died 1464. The decay of the castle probably dates from her death,
for Edward Duke of York, who succeeded, became Edward IV., and
nothing has generally proved more fatal to an independent historic
estate than its absorption by the Crown.
Conisborough remained in the Crown, and, though probably the
buildings were suffered to fall into decay, some of the offices
attached to the castle and domain were kept up. As late as 1522, Sir
H. Wyatt and John Melton were bailiffs and stewards of “the
lordships of Conysborowe,” keepers of the park, &c., and there were
constables and door-wards of the castle. Finally, James II. granted it
to Carey, Earl of Dover, from whose family it passed to that of its
present owner. King, in his “Munimenta,” has given elaborate plans,
and a yet more elaborate history of this castle, but neither can be
depended upon. There is also an excellent paper upon it in the fifth
volume of the Archæological Journal by Mr. Milward, the plans
attached to which seem, however, to be taken from King.
Conisborough Castle deserves a better fate than has of late years
attended it, or than seems likely to attend it. Its position upon one
of the most celebrated of the Yorkshire streams, its grand natural
mount, and the striking character of the earthworks by which it is
defended, are quite enough to attract public attention; but in
addition it has an undoubted though obscure Saxon history, and
from the Norman Conquest it was for three centuries or more the
residence of a very powerful race of barons, the evidences of whose
power and wealth are preserved in the ruins of their fortress. By
whom, or precisely when, the present works in masonry were
executed, is a question not exactly to be decided. William de
Warren, the third and last earl of the old stock, 1138–1148, was a
very likely man to have built in masonry this his most important
northern castle, and it is probable that he built the enceinte wall of
the inner court, and the hall and offices now destroyed. The keep is
certainly later, scarcely much earlier than 1200, and is, therefore,
probably the work of Hameline Plantagenet, who held the earldom
and the castle from about 1163 to 1201. The tower was, no doubt,
added for security only, for, though it contains state apartments and
an oratory, these were dark and inconvenient, only fit to be
inhabited during a siege. The hall and ordinary lodgings were, of
course, more spacious and placed in the court, where are still traces
of their foundations.
At a still later period, possibly under Earl John, who held the
earldom from 1240 to 1304, the Norman curtain seems to have been
repaired and strengthened with round bastion turrets, small and
solid, along the southern and western faces of the inner ward. Then
also the arrangements for crossing the ditch, and defending the
lower entrance, were made more elaborate. The work of this period
is of inferior quality, and much of it has fallen down. Since this no
additions of any importance seem to have been executed.
It is probable that, during the civil war and after the death of King
Charles, the curtain wall, domestic buildings, and lower gate-house
were broken down, and the keep gutted and unroofed, but since
that time, now nearly two centuries and a half, the ruins seem to
have been left untouched save by the hand of time. Such is the
excellence of the workmanship of the keep that for very many years
the walls stood unshaken. During the last quarter of a century,
however, the rains of autumn and the frosts of winter have begun to
tell upon the structure, and the top of the tower is in a shaky
condition. Still, it is not so far gone but that a few pounds judiciously
laid out upon it would save it. The upper two or three feet should be
removed, stone by stone, and replaced with water-lime or cement.
The cost of this would be very trifling indeed; but what should also
be done, and what would not by any means involve a very serious
expense, is the replacement of the roof and floors. All Yorkshire, and
indeed all the Archæological Societies in England, from the Society
of Antiquaries down to the most recent local society, must feel an
interest in this subject. Probably, if it were brought before the owner
of the castle in a proper manner, the necessary repairs would be
undertaken; if not, surely it would not be difficult to provide the
means by private subscription. In any case something should be
done at once, for the top of the keep is in that condition that every
winter tells severely upon it.
The plans and illustrations appended to this notice of the castle
are from actual survey by Mr. A. S. Ellis, and by him presented to the
Yorkshire Archæological Society, by whose permission they are here
reprinted. They will be found as far superior in accuracy as in
completeness of detail to any plans as yet published, and it may be
said of them, and it is no slight praise, that they are worthy of the
important fortress they are intended to illustrate.
 CONWAY CASTLE.
THE castle and town of Conway form together the most complete
and the best preserved example of mediæval military architecture in
Britain. The works are all of one date and design, apparently by one
engineer, at the command of a monarch specially skilled in the art of
war, and whose intention here was to command a very formidable
pass, and to put a curb upon the boldest, most persistent, and most
dangerous of the foes who strove to resist the consolidation of his
kingdom. At Conway are displayed all the arts of defence as
understood in the thirteenth century. The position is naturally strong,
the walls are of unusual thickness, each part of the containing
curtains is flanked by frequent towers, and the castle predominates
over the whole position, commanding and protecting the town, and
forming a citadel within which, as a last resource, a secure shelter
would be afforded.
Conway, the Aber-Conwy of the Welsh, stands on the left or
western bank of the river whence it derives its name, and which is
commemorated by Drayton and Spenser as rich in “precious orient
pearls,” and here is widening into an estuary. The southern front of
the town is further protected by the marshy bed of the Gyffin, which
here joins the Conwy. Town and castle cover a triangular mass of
rock, of which the castle occupies the apex projecting into the water.
The curtain wall which encircles the town is strengthened by twenty-
eight towers, all but two or three of which are half-cylinders in
figure, and open from top to bottom in the rear. They rise one stage
above the curtain, which also is unusually high. Between two of
them there project upon corbels from the curtain at the battlement
level a row of twelve garderobes, showing that sanitary
arrangements were by no means neglected even in the thirteenth
century. There are three gates, each flanked by a pair of towers,
defended by double doors, portcullis, grate, and drawbridge. One of
these, Porth Uchaf, opens landward; a second, Porth-isaf, upon a
quay along the water’s edge; and a third, Porth-y-felin, opens in a
shoulder of the wall upon the river below the castle, and gave a way
to the castle mill. There is, besides, a postern, also below the castle,
and opening upon the sea-shore. Besides these defences a thick
spur wall, defended above by a double battlement, extends from the
sea-front into the sea. Formerly this was carried to low-water mark,
and ended in a small round tower, and thus effectually prevented
any attempt to turn the flank of the defences and attack the town
from the sea-front. The town walls run up to, but their rampart walk
does not communicate with, the castle, which, however, forms a part
of the enceinte, and has one front with its main entrance within and
towards the town.
It is said that the rock occupied by the castle originally extended
some way eastward into the estuary, and was, therefore, a point of
danger on that side. To remove this, the rock was quarried away and
a passage opened, which is now the main channel of the river, and is
spanned by the road and railway-bridges of Telford and Stephenson.
It will be observed that Conway is not, like Gloucester and
Chester, posted on the English side of the river, as if intended for
defence only; like Chepstow, it is placed beyond the stream, and
intended as a tête-du-pont to cover the passage of troops across the
water.
In plan, the castle is somewhat of a parallelogram, 100 yards east
and west, and with a breadth ranging from 35 yards to 40 yards.
The northern front is straight, the southern zigzag, following the
irregularities of the rock. Its general level is several feet above the
nearer parts of the town. There are eight towers, one at each of the
four angles, and two, intermediate, upon each of the long faces.
There is no gatehouse, a very unusual omission in an Edwardian
castle, but one the cause of which is here very obvious. The towers
are cylindrical, about 40 feet in diameter, but somewhat flattened
and irregular on their interior faces, to enable the rampart walk or
allure to be carried on without traversing their interior chambers. To
allow of this, bold corbels, or sometimes a projecting shelf of
masonry are applied to the internal or rearward face of the tower at
the proper level. By this means there is secured an uninterrupted
walk all round the place, communicating with, but not traversing
each tower.
The area is divided by a very thick cross curtain into two wards.
The outer or western is 60 yards long, and contains the great hall,
the chapel, the kitchen, and the water-tank; the eastern or inner
ward, 40 yards long, contains the smaller hall and the state
apartments. At each end the castle is covered by a small platform, at
the level of the courts within, and supported by retaining walls of
considerable height, crowned by two light parapets, each with three
small half-round bastions flanking the curtains. Each of these
platforms protects and covers an entrance. The main entrance is at
the west end and from the town, and is a very curious piece of
engineering skill. A causeway of masonry, a viaduct, about 14 feet
broad and parapeted on each side, ascended with a very steep slope
to a point 13 feet from the gate of the barbican, where it stopped
abruptly, and is still seen rising out of the ditch, and about 20 feet
high. The barbican is a narrow rectangular space, contained
between two walls, ending below in two small round turrets which
flank the outer gate, and above is another gate opening on the end
of the platform under the north-western main tower. A very
ponderous drawbridge, working on trunnions 14 inches in diameter,
dropped from the outer gate upon the pier already mentioned. The
pier was 4 feet lower than the cill of the bridge, so as to preserve
the steepness of the approach. The bridge was balanced by a short
and heavy tailpiece or counterpoise which worked in a quadrant-
shaped pit below it. The gateway had a portcullis and doors, and
within it a staircase in the side wall led to the battlements over the
gate. The upper gateway was closed by a stout door only, but was
protected by the adjacent bastion of the platform, which has a loop
towards it. The entrance thus completed was broad enough to admit
two horsemen abreast, and the steepness gave the defenders a
great advantage over the enemy. The barbican of Conway may
conveniently be illustrated by a reference to that of Brampton Brian,
which contains the same arrangements, though on a larger scale.
The woodcut shows the tower flanking the drawbridge, the outer
and inner gates, and between them the mural staircase leading up
to the ramparts.

The platform, to one end of which the barbican gives entrance, is

about 35 yards long by 10 yards broad, and looked down upon a
formidable ditch. In its centre, between two of the main towers, was
a short lofty curtain, and in it the main gateway. Above, a row of
bold corbels, projecting above 5 feet, included a line of
machicolations, and gave great breadth to the rampart of the curtain
and great vantage to the defenders. The gateway is acutely pointed,
but quite plain, with flat sides. Within, the portal is vaulted and
portcullised, and has a broad space in front of the grate, possibly for
some kind of additional frame. Above the portal was a portcullis
chamber, also in the substance of the wall, and the place where the
grate was suspended is still seen. This chamber was reached by a
steep narrow stair from the rampart of the curtain,—a very rare
arrangement. Entering the gate on the right is a staircase up to the
ramparts, looking like a makeshift, and possibly not original. Beyond,
also on the right, is the great hall. This, though a spacious, could
never have been a handsome chamber, for it is built on a curve, or
rather on an irregular polygon, to suit the southern curtain which
forms one side of it. It is about 105 feet long by 30 feet broad, and
its floor is at the court level. Below was a cellar of about half the
breadth of the hall, the rock here cropping up and blocking one side.
To this the entrance was by a pit or trap, in which was a doorway
opening into a passage by a second doorway in the cellar. This is
lighted by loops in the curtain, and at its east end is continued,
through a partition, below the chapel. The hall is said originally to
have been of smaller size, and to have been enlarged. If this be so,
it must have been at the chapel end.
The hall is lighted by four small square-headed windows towards
the field, and two larger ones towards the court. The latter are
pointed and were of two lights, with quatrefoiled heads, and a
quatrefoil in the head. The door is in the same side near its east
end. There are three fireplaces, all under hoods, with flanking piers
and brackets to receive the thrust of the flat arch. The hall was
crossed by seven large chamfered stone ribs of two members,
placed very irregularly. Two are standing, one having been lately
rebuilt; the other is at the upper end of the hall, and marks its
division from the chapel. A plain corbel below the springing of this
rib shows the partition to have been of timber, no doubt a carved
brattice. The roof was open, and there were timber principals
between the stone ribs. It is difficult at first to believe that this long
irregular space, with its three unsymmetrical fireplaces, could have
been all one room, and at first it appears as though the west end, to
the second rib with one of the fireplaces and three windows, might
have been bratticed off as a withdrawing-room; but it is evident this
was not so. Such a room would have no separate door and no
garderobe. The dais of the hall was evidently at the other end, and
the withdrawing-room was the first floor of the dungeon tower,
which stands at the back of the great fireplace, and is entered by a
small door in the jamb of one of the hall windows. This and the floor
above were readily accessible from the dais.

CONWAY CASTLE.

The chapel, bratticed off at the east end of the hall, had also an
open roof, with one stone rib. It has two windows to the south and
one to the field, and at its east end is a larger, three-light window,
with a round head, and a piscina in the south jamb. The tracery is
broken away. The great kitchen has been pulled down. It was built
against the north curtain, opposite to the hall door. There remains of
it a water-trough occupying the seat of a window, and lined with
cement. Near the kitchen was a large tank quarried in the rock, lined
and cemented, for the storage of water; a culvert brought into it
water from the roofs, and leaden pipes have been traced from an
exterior spring at some distance. It has been opened to a
considerable depth, 14 feet or 15 feet, but was certainly not a well,
though possibly one was intended.
The cross wall separating the two wards is of the same height and
thickness as the exterior curtains. It is pierced near its centre by a
shoulder-headed doorway, closed with a door only, and opening into
the inner ward. This door is covered by a sort of lodge on its
western face, with a loop towards the main gate.
The inner ward, nearly square in plan, has the state rooms on its
south and east sides. These have basement chambers, well lighted
and with fireplaces on the ground floor, level with the court; and
above these, on the first floor, are the state apartments, with open
roofs. First of these, on the right is the smaller hall, 30 feet by 28
feet. It has a door at its west or lower end communicating with a
sort of lobby, and so with a main tower, which probably contained
the kitchen. At the other or east end is also a door, opening into the
withdrawing-room. Towards the court is a central fireplace, between
two handsome windows. These were flat-topped, of two lights, and
the upper half was filled with Decorated tracery, now broken away.
In the remaining side, towards the field, is at one end a small
window, and at the other a door opening into a mural chamber, a
garderobe. The roof was strengthened by two stone ribs, of which
one is perfect, and is not quite so plain as those of the great hall.
The withdrawing-room has a fireplace on the north side, and was
crossed by two ribs, both broken down. This room has a mural
passage in its south wall communicating with a garderobe and large
vaulted chamber, also in the wall, and so opening into the ground
floor of the south-eastern or king’s tower. Another door opens into
the queen’s chamber. This is a large and handsome room, also on
the first floor, occupying the east side of the court. Its roof contained
two ribs, both removed. At its north end are passages into
garderobes, mural chambers, and an oratory, all contained in the
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com