Download Software Development - Case Studies in Java_0321117832 PDF

TitleSoftware Development - Case Studies in Java_0321117832
File Size10.0 MB
Total Pages653
Document Text Contents
Page 1

032111783


Java Programming/Software Design

www.pearson-books.com
An imprint of

FEATURES

➢ Coverage of the latest
Java-related technologies,
including JDBC, RMI,
Sockets, Applets, Servlets,
JavaScript, XML and
Swing GUI

➢ Problem-centric approach,
which shows you how to
use the most appropriate
object-oriented
techniques for solving
complex software
development problems

➢ Uses the UML notation
throughout

➢ Numerous programming
exercises drawn from the
case studies

Softw
are D

evelopm
ent

Brugali
Torchiano

A FRESH APPROACH TO SOFTWARE
DEVELOPMENT WITH JAVA

This book will give you everything you

need to develop an application, system

or framework from conception to

implementation with Java. Using a

collection of case studies, with each one

building on the one before, the authors

guide you through the entire project life-

cycle emphasizing good design practice

throughout. Software Development will

give you the knowledge to truly

understand the complex problems

associated with software design, and will

provide you with the tools and

techniques to overcome them.

Dr Davide Brugali is an Assistant

Professor at the University of Bergamo,

Italy. Dr Marco Torchiano is an Assistant

Professor at the Politecnico di Torino,

Italy. Both have extensive experience of

teaching object-oriented programming

and software engineering.

0321117832_COVER(Brugali) 15/2/05 12:17 pm Page 1

Page 2

Software Development
Case Studies in Java

Visit the Software Development: Case Studies in Java
Companion Website at www.pearsoned.co.uk/brugali
to find valuable student learning material including:

● Source code for every case study
● Collection of sidebars illustrating techniques and

technologies used in the case studies
● Collection of idioms and patterns demonstrating

good development practice

SOFD_A01 2/2/05 12:32 pm Page i

Page 326

Car parking 303

■ autonomous decision-making capabilities;
■ a series of available services;
■ a pool of controlled resources.

Control modules should be organized into a hierarchy of
control layers, so that higher-level control modules,
playing the role of clients, coordinate the control modules
below them, which play the role of servers.

Force resolution Control modules have a standard communication
interface. They can play both the role of server of higher-
level control modules and the role of client of lower-level
control modules.

Pattern Visibility between control modules

Context Control modules in the hierarchy need to communicate
with one another. Communication requires that some sort
of visibility must exist among components.

Problem In such systems lower-level components are more stable
than higher-level components, which undergo frequent
reconfigurations according to rapidly evolving functional
requirements. How can the right visibility relationships
between the control modules be established?

Forces or tradeoffs Visibility implies dependency with respect to changes, and
hence it has consequences for the entire system’s design.
In hierarchical software architectures it is better to avoid
visibility loops between components at different layers.

Solution This is achieved by offering the components two
communication mechanisms.
The first mechanism, known as caller�–�provider and deeply
rooted in object-oriented programming, is involved when
an object invokes another object’s method. In hierarchical
software architectures, it is convenient that higher-level
components (more volatile) have visibility of lower-level
components (more stable) but not vice versa. A client
requests services from a server by invoking the methods of
its interface.
The second mechanism, the broadcaster�–�listener
mechanism, consists in giving the components the ability
to broadcast and listen to events. The broadcaster does
not know the identity of its listeners, which might change
over time. Conversely, the components that want to be
notified when an event is raised must know the identity of
the component that broadcasts that event. In hierarchical
software architectures it is convenient that lower-level
components communicate with the higher-level ones by
broadcasting events.

SOFD_C11 1/2/05 2:45 pm Page 303

Page 327

11.8 ■ Reference

Aarsten, A., Brugali, D. and Menga, G. (1996) “Designing Concurrent and Distributed
Control Systems”, Communications of the ACM, October.

304 Part II Object Architecture

Force resolution According to the communication mechanism that is used,
visibility and flow of information move in the same
direction and in the opposite direction with respect to the
communicating components.
Using the caller�–�provider mechanism, both visibility and
flow of information move from the client to the server.
Using the broadcaster�–�listener mechanism, visibility and
flow of information move in the opposite direction: the
client knows the server that broadcasts events of interest.

SOFD_C11 1/2/05 2:45 pm Page 304

Page 652

tank controllers prototype 329�–�40
analysis 329�–�30
design 330�–�3
implementation 333�–�9
test 339�–�40

task 16�–�17
representation of 22

telemeter device in mobile robot exploration
235�–�6

template method 276
temporal consistency constraints 17
terminal user interface, reconfiguring 357
text, output containing 144
thematic information, from databases 409
three-tier model 308�–�9, 388, 389�–�90
time plan, representation of 24
tracker

in logical recording prototype 493�–�4
in physical recording prototype 482�–�4

tracking 478
training prototype 73�–�81

analysis 73
design 73�–�5
implementation 75�–�9
testing 79�–�81

ubiquitous email 428�–�68
architecture and planning 431�–�3
assessment 467�–�8
back end mail component 434
domain models 430
extension 466�–�7
HTML pages in 435
mail access prototype 433�–�42
mail notification prototype 458�–�66
specification 428�–�31
test 431
user interface component 434
user profiles prototype 442�–�53
WAP access prototype 453�–�8

UML class diagrams 51
user interaction prototype 35�–�47

analysis 36�–�7
design 37
implementation 37�–�44
testing 44�–�7

user interface prototype 604�–�12
analysis 604�–�5
design 606
implementation 606�–�11

state, keeping 606
test 611�–�12

user profiles prototype 442�–�53
analysis 443
common code, factored in 443
database structure 445
design 443�–�5
implementation 445�–�53
new users in 444
test 453

vectors 86
virtual processes control flow models 159
volatile programs prototype 103�–�11

analysis 103
design 103�–�4
implementation 104�–�8
testing 108�–�11

von Neumann architecture 87, 88

WAP access prototype 453�–�8
analysis 454
design 454�–�5
implementation 455�–�7
interface, integration of 454
test 457�–�8

web browser prototype 416�–�25
analysis 416�–�18
design 419�–�20
implementation 420�–�5
test 425

web communication prototype 526�–�35
analysis 526
design 526�–�8
HTTP-based communication, support for 528
implementation 528�–�32
socket-based communication, support for 526
test 532�–�5

white-box frameworks 473
work cell simulation prototype 319�–�29

analysis 319
design 319�–�24
implementation 324�–�8
test 328�–�9

work cell simulator 215�–�29, 231
analysis 215�–�16
assessment 230�–�2
design 216�–�17
extensions 229�–�30
implementation 217�–�28
test 228�–�9

Index 629

SOFD_Z01 1/2/05 2:56 pm Page 629

Page 653

workflow data, limited access to 614
workflow management system 576�–�621

architecture and planning 581�–�3
assessment 620�–�1
domain models 578�–�81
extension 619�–�20
problem analysis 578�–�81
process data prototype 612�–�19
process definition prototype 583�–�92
process enactment 577

process enactment prototype 592�–�604
process models 576�–�7
specification 576�–�8
test 581
user 578
user interface prototype 604�–�12

workstation booking 539

XML language 238�–�9, 391, 426�–�7

630 Index

SOFD_Z01 1/2/05 2:56 pm Page 630

Similer Documents