Ivan Marsic • Rutgers
University 92
try { CommPortIdentifier cpi =
CommPortIdentifier.getPortIdentifierportName; if cpi.getPortType == CommPortIdentifier.PORT_SERIAL {
ctrlPort = SerialPort cpi.open; new HomeAccessControlSystemks, ctrlPort;
} catch NoSuchPortException e { System.err.printlnUsage: ... ... port_name;
} try {
ctrlPort.setSerialPortParams 9600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1,
SerialPort.PARITY_NONE ;
} catch UnsupportedCommOperationException e { e.printStackTrace;
} }
Thread method; does nothing, just waits to be interrupted by input from the serial port.
public void run { while true {
try { Thread.sleep100; } catch InterruptedException e { do nothing }
} }
Serial port event handler Assume that the characters are sent one by one, as typed in.
public void serialEventSerialPortEvent evt { if evt.getEventType == SerialPortEvent.DATA_AVAILABLE {
byte[] readBuffer = new byte[5]; just in case, 5 chars try {
while inputStream_.available 0 { int numBytes = inputStream_.readreadBuffer;
could check if numBytes == 1 ... }
} catch IOException e { e.printStackTrace; } append the new char to the user key
key_.appendnew StringreadBuffer; if key_.length = keyCodeLen_ { got whole key?
pass on to the Controller contrl_.enterKeykey_.toString;
get a fresh buffer for a new user key key_ = new StringBuffer;
} }
} }
Chapter 2 • Object-Oriented Software Engineering
93
The class
HomeAccessControlSystem
is a thread that runs forever and accepts the input from the serial port. This is necessary to keep the program alive, since the main thread just sets up
everything and then terminates, while the new thread continues to live. Threads are described in Section 5.3 below.
Next shown is an example implementation of the core system, as designed in Figure 2-11 above. The coding of the system is directly driven by the interaction diagrams.
Listing 2-2: Implementation Java code of the classes Controller, KeyChecker, and LockCtrl.
import javax.comm.; public class Controller {
protected KeyChecker checker_; protected LockCtrl lockCtrl_;
protected LightCtrl lightCtrl_; protected PhotoObsrv sensor_;
protected AlarmCtrl alarmCtrl_; public static final long maxNumOfTrials_ = 3;
public static final long trialPeriod_ = 600000; msec [= 10 min] protected long numOfTrials_ = 0;
public Controller KeyChecker kc, LockCtrl lkc, LightCtrl lic,
PhotoObsrv sns, AlarmCtrl ac {
checker_ = kc; lockCtrl_ = lkc; alarmCtrl_ = ac;
lightCtrl_ = lic; sensor_ = sns; }
public enterKeyString key_code { Key user_key = new Keykey_code
if checker_.checkKeyuser_key { lockCtrl_.setOpentrue;
if sensor_.isDaylight { lightCtrl_.setLittrue; } numOfTrials_ = 0;
} else { we need to check the trial period as well, but ...
if ++numOfTrials_ = maxNumOfTrials_ { alarmCtrl_.soundAlarm;
numOfTrials_ = 0; reset for the next user }
} }
} import java.util.Iterator;
public class KeyChecker { protected KeyStorage validKeys_;
public KeyCheckerKeyStorage ks { validKeys_ = ks; }
Ivan Marsic • Rutgers
University 94
public boolean checkKeyKey user_key { for Iterator e = validKeys_.iterator; e.hasNext; {
if compareKeye.next, user_key { return true; } }
return false; }
protected boolean compareKey key1, Key key2 { }
} import javax.comm.;
public class LockCtrl { protected boolean open_ = false;
public LockCtrlSerialPort ctrlPort { }
}
In the above I assume that KeyStorage is implemented as a list,
java.util.ArrayList
. If the keys are simple objects, e.g., numbers, then another option is to use a hash table,
java.util.HashMap
. Given a key, KeyStorage returns a value of a valid key. If the return value is
null
, the key is invalid. The keys must be stored in a persistent storage, such as relational database or a plain file and loaded into the KeyStorage at the system startup time,
which is not shown in the above code. The reader who followed carefully the stepwise progression from the requirements from the code
may notice that, regardless of the programming language, the code contains many details that usually obscure the high-level design choices and abstractions. Due to the need for being precise
about every detail and unavoidable language-specific idiosyncrasies, it is difficult to understand and reason about software structure from code only. I hope that at this point the reader
appreciates the usefulness of stepwise progression and diagrammatic representations.
2.7 Summary and Bibliographical Notes
This chapter presents iterative approach to software design and gradually introduces software engineering techniques using a running example, which is designed and then improved
“refactored” by remedying the perceived deficiencies. Key phases of the process are summarized in Figure 2-17. Notice that package diagram, which is a structural description, is
not shown for the lack of space. The reader should not mistake this figure to indicate that software lifecycle progresses unidirectionally as in the waterfall method. Rather, in practice there
is significant intertwining and backtracking between the steps. Plus, this represents only a single iteration of a multiphase process. In general, the sequential presentation of the material does not
Chapter 2 • Object-Oriented Software Engineering
95
imply how the actual development is carried out: teaching the tool use should not be equated with its actual use.
A general understanding of the problem domain is inadequate for success; you need a very detailed understanding of what is expected from the system. A detailed understanding is best
developed iteratively.
Key points: •
Object orientation allows creation of software in solution objects which are directly correlated to the objects physical objects or abstract concepts in the problem to be
solved. The key advantage of the object-oriented approach is in the localization of responsibilities—if the system does not work as intended, it is easier to pinpoint the
culprit in an object-oriented system.
• The development must progress systematically, so that the artifacts created in the
previous phase are always being carried over into the next phase, where they serve as the foundation to build upon.
• Requirements elicitation is usually done through use case analysis. Use cases describe
scenarios for using the system under discussion in order to help the users accomplish their goals. The use cases precisely represent the way the software system interacts with
its environment and what information must pass the system boundary in the course of interaction.
• The analysis models are input to the design process, which produces another set of
models describing how the system is structured and how the system’s behavior is realized in terms of that structure. The structure is represented as a set of classes class diagram,
S ystem De
s c
riptio n
B eha
v io
r
St ru
ct ure
Use Cases System Sequence
Diagrams
Communicator Key
LockOperator lockStatus
KeyChecker numOfTrials
maxNumOfTrials c
o nv
ey s
R eque
s ts
obtains
notifiesKeyValidity ve
rifi es
Communicator Key
LockOperator lockStatus
KeyChecker numOfTrials
maxNumOfTrials c
o nv
ey s
R eque
s ts
obtains
notifiesKeyValidity ve
rifi es
Domain Model
checkKey sk := getNext
addElement setOpentrue
: Communicator : Checker
: KeyStorage : LockCtrl
val == null : setLittrue
alt val = null
[else]
Interaction Diagrams
Class Diagram
Lock Unlock
Tenant Landlord
Lock Unlock
Tenant Landlord
Implementation Program
import javax.com import java.io.I
import java.io.I import java.util
public class Hom implemen
protected Co protected In
protected St public stati
public HomeA KeyStora
{ try {
inpu } catch
LockCtrl LightCtr
PhotoObs
selectFunction“unlock
: System User
«primary actor» prompt for the key
enterKey signal: valid key, lock open
open the lock, turn on the light
selectFunction“unlock
: System User
«primary actor» prompt for the key
enterKey signal: valid key, lock open
open the lock, turn on the light
KeyChecker + checkKey : boolean
Key code_ : long
+ getCode : long PhotoSObsrv
+ isDaylight : boolean Controller
numOfTrials_ : long maxNumOfTrials_ : long
+ enterKeyk : Key 1
1 1
sensor 1
checker
alarmCtrl lockCtrl
1..
AlarmCtrl + soundAlarm
LockCtrl open_ : boolean
+ isOpen : boolean + setOpenv : boolean
KeyChecker + checkKey : boolean
Key code_ : long
+ getCode : long PhotoSObsrv
+ isDaylight : boolean Controller
numOfTrials_ : long maxNumOfTrials_ : long
+ enterKeyk : Key 1
1 1
sensor 1
checker
alarmCtrl lockCtrl
1..
AlarmCtrl + soundAlarm
LockCtrl open_ : boolean
+ isOpen : boolean + setOpenv : boolean
Figure 2-17: Summary of a single iteration of the software development lifecycle. The activity alternates between elaborating the system’s behavior vs. structure.
Ivan Marsic • Rutgers
University 96
and the desired behavior is characterized by patterns of messages flowing between instances of these classes interaction diagrams.
• Finally, the classes and methods identified during design are implemented in an object-
oriented programming language. This completes a single iteration. After experimenting with the preliminary implementation, the developer iterates back and reexamines the
requirements. The process is repeated until a satisfactory solution is developed.
The reader should be aware of the capabilities and limitations of software engineering methods. The techniques presented in this chapter help you to find a solution once you have the problem
properly framed, as is the case with example projects in Section 1.5. But, use case analysis will not help you with framing the problem; rather, it is intended to lead you towards a solution once
the problem is defined. To define the problem, you should consider ethnography methods or, as an engineer you may prefer Jackson’s “problem frames” [Jackson, 2001], described in the next
chapter.
A short and informative introduction to UML is provided by [Fowler, 2004]. The fact that I adopt UML is not an endorsement, but merely recognition that many designers presently use it and
probably it is the best methodology currently available. The reader should not feel obliged to follow it rigidly, particularly if heshe feels that the concept can be better illustrated or message
conveyed by other methods.
Section 2.2: Use Cases An excellent source on methodology for writing use cases is [Cockburn, 2001].
System sequence diagrams were introduced by [Coleman et al., 1994; Malan et al., 1996] as part of their Fusion Method.
Section 2.3 Domain Model The approach to domain model construction presented in Section 2.3 is different from, e.g., the
approach in [Larman, 2005]. Larman’s approach can be summarized as making an inventory of the problem domain concepts. Things, terminology, and abstract concepts already in use in the
problem domain are catalogued and incorporated in the domain model diagram. A more inclusive and complex model of the business is called Business Object Model BOM and it is also part of
the Unified Process.
Section 2.4 Design Design with responsibilities Responsibility-Driven Design:
[Wirfs-Brock McKean, 2003; Larman, 2005] Coupling and cohesion as characteristics of software design quality introduced in [Constantine et
al., 1974; Yourdon Constantine, 1979]. More on coupling and cohesion in Chapter 4 below. See also: http:c2.comcgiwiki?CouplingAndCohesion
J. F. Maranzano, S. A. Rozsypal, G. H. Zimmerman, G. W. Warnken, P. E. Wirth, and D. M. Weiss, “Architecture reviews: Practice and experience,” IEEE Software, vol. 22, no. 2, pp. 34-43,
March-April 2005.
