Object Oriented Software

Engineering

System Design Activities

Atique Zafar
An Overview of System Design Activities
 Design goals guide the decisions to be made by the
developers especially when trade-offs are needed.
 Developers divide the system into manageable pieces to
deal with complexity:
 Each subsystem is assigned to a team and realized
independently.
 In order for this to be possible, though, developers need to
address system-wide issues when decomposing the system.

2 Object Oriented Software Engineering

Hardware/software mapping
 What is the hardware configuration of the system?
 Which node is responsible for which functionality?
 How is communication between nodes realized?
 Which services are realized using existing software
components?
 How are these components encapsulated?

3 Object Oriented Software Engineering

Hardware/software mapping
 Addressing hardware/software mapping issues often leads to
the definition of additional subsystems dedicated to moving data
from one node to another, dealing with concurrency, and
reliability issues.

 Off-the-shelf components enable developers to realize

complex services more economically.

 User interface packages and database management systems are

prime examples of off-the shelf components.

 Components, however, should be encapsulated to minimize

dependency on a particular component; a competing vendor
may offer a better product in the future, and you want the
option to switch.
4 Object Oriented Software Engineering
Data management
 Which data should be persistent?
 Where should persistent data be stored?
 How are they accessed?

5 Object Oriented Software Engineering

Data management
 Persistent data represents a bottleneck in the system on
many different fronts:
 most functionality in system is concerned with creating or
manipulating persistent data.
 For this reason, access to the data should be fast and reliable.
 If retrieving data is slow, the whole system will be slow.
 If data corruption is likely, complete system failure is likely.

 Often, this leads to the selection of a database

management system and of an additional subsystem
dedicated to the management of persistent data.

6 Object Oriented Software Engineering

Access control
 Who can access which data?
 Can access control change dynamically?
 How is access control specified and realized?
 Access control and security are system-wide issues.
 The access control must be consistent across the system;
in other words, the policy used to specify who can and
cannot access certain data should be the same across all
subsystems.

7 Object Oriented Software Engineering

Control flow
 How does the system sequence operations?
 Is the system event driven?
 Can it handle more than one user interaction at a time?
 The choice of control flow has an impact on the
interfaces of subsystems.
 If an event-driven control flow is selected, subsystems will
provide event handlers.
 If threads are selected, subsystems must guarantee mutual
exclusion in critical sections.

8 Object Oriented Software Engineering

Boundary conditions
 How is the system initialized and shut down?
 How are exceptional cases handled?
 System initialization and shutdown often represent much
of the complexity of a system, especially in a distributed
environment.
 Initialization, shutdown, and exception handling have an
impact on the interface of all subsystems.

9 Object Oriented Software Engineering

Concepts: UML Deployment Diagrams
 UML deployment diagrams are used to represent the
relationship among run-time components and nodes.
 Components are self-contained entities that provide services
to other components or actors.
 A Web server, for example, is a component that provides
services to Web browsers.
 A Web browser such as Safari is a component that provides
services to a user.
 A node is a physical device or an execution environment in
which components are executed.
 A system is composed of interacting run-time components
that can be distributed among several nodes.
 Furthermore a node can contain another node, for example, a
device can contain an execution environment.

10 Object Oriented Software Engineering

UML deployment diagram

 A UML deployment diagram representing the allocation

of components to different nodes.
 Web browsers on PCs and Macs can access a WebServer
that provides information from a Database.

11 Object Oriented Software Engineering

Refined view of the WebServer component

 Components can be refined to include information about

the interfaces they provide and the classes they contain.
 Figure illustrates the WebServer component and its
containing classes.
 WebServer provides an http interface and requires a jdbc
interface.
 The http interface is realized by the HttpService class.
12 Object Oriented Software Engineering
System Design Activities: Addressing
Design Goals
 Mapping Subsystems to Processors and Components
 Identifying and Storing Persistent Data
 Providing Access Control
 Designing the Global Control Flow
 Identifying Boundary Conditions
 Reviewing the System Design Model

13 Object Oriented Software Engineering

Mapping Subsystems to Processors and
Components
 Selecting a hardware configuration and a platform
 Many systems run on more than one computer and depend on
access to an intranet or to the Internet.
 The use of multiple computers can address high-performance
needs and interconnect multiple distributed users.
 Consequently, we need to examine carefully the allocation of
subsystems to computers and the design of the infrastructure
for supporting communication between subsystems.
 These computers are modeled as nodes in UML deployment
diagrams.
 Because the hardware mapping activity has significant impact
on the performance and complexity of the system, we perform
it early in system design

14 Object Oriented Software Engineering

Selecting a virtual machine
 Selecting a hardware configuration also includes selecting a
virtual machine onto which the system should be built.
 The virtual machine includes
 the operating system and
 any software components that are needed, such as a database
management system or a communication package.
 The more functionality the components provide, the less
development work is involved.
 The selection of the virtual machine, however, may be
constrained by a client who acquires hardware before the
start of the project.
 The selection of a virtual machine may also be constrained by
cost considerations: it can be difficult to estimate whether
building a component costs more than buying it.

15 Object Oriented Software Engineering

My Trip Example
Allocation of MyTrip
subsystems to devices and
execution environments
(UML deployment
diagram).
• RoutingSubsystem runs on the
OnBoardComputer;
• PlanningSubsystem runs on an
Apacheserver.

 In MyTrip, we assume from the requirements that

PlanningSubsystem and RoutingSubsystem run on two different
nodes:
 Figure illustrates the hardware allocation for MyTrip with two devices
called :OnBoardComputer and :WebHost, and an execution
environment called :Apache.
 We select a Unix machine as the virtual machine for the :WebServer,
and the Web browsers Safari and Internet Explorer as the virtual
machines for the :OnBoardComputer.

16 Object Oriented Software Engineering

Allocating objects and subsystems to
nodes
 Once the hardware configuration has been defined and the
virtual machines selected, objects and subsystems are assigned
to nodes.
 This often triggers the identification of new objects and
subsystems for transporting data among the nodes.
 In the MyTrip system, both RoutingSubsystem and
PlanningSubsystem share the objects Trip, Destination,
Crossing, Segment, and Direction.
 Instances of these classes need to communicate via a wireless
modem using some communication protocol.
 We create a new subsystem to support this communication:
CommunicationSubsystem, a subsystem located on both nodes
for managing the communication between them.

17 Object Oriented Software Engineering

 We also notice that only segments creating the planned trip
are stored in RoutingSubsystem.
 Adjacent segments not part of the trip are stored only in the
PlanningSubsystem.
 To take this into account, we need objects in the
RoutingSubsystem that can act as alternates to Segments and
Trips in the PlanningSubsystem.
 An object that acts on the behalf of another one is called a
“proxy.” We therefore create two new classes, SegmentProxy
and TripProxy, and make them part of the RoutingSubsystem.
 These proxies are examples of the Proxy design pattern
(see Appendix A.8 and [Gamma et al., 1994]).

18 Object Oriented Software Engineering

Revised design model for MyTrip

 In case of replanning by the driver, this class will transparently request the
CommunicationSubsystem to retrieve the information associated with its
corresponding Segments on the PlanningSubsystem.
 Finally, the CommunicationSubsystem is used for transferring a complete
trip from PlanningSubsystem to RouteAssistant.
 The revised design model and the additional class descriptions are depicted
in Figure.

19 Object Oriented Software Engineering

Revised design model for MyTrip

 CommunicationSubsystem The CommunicationSubsystem is responsible for

transporting objects from the PlanningSubsystem to the RoutingSubsystem.
 Connection A Connection represents an active link between the Planning–
Subsystem and the RoutingSubsystem.
 A Connection object handles exceptional cases associated with loss of network
services.
 Message A Message represents a Trip and its related Destinations, Segments,
Crossings, and Directions, encoded for transport

20 Object Oriented Software Engineering

Identifying and Storing Persistent Data
 Persistent data outlive a single execution of the system.
 For example, at the end of the day, an author saves his work
into a file on a word processor.
 The file can then be reopened later.
 The word processor need not run for the file to exist.
 Similarly, information related to employees, their employment
status, and their paychecks live in a database management
system.
 This allows all the programs that operate on employee data to
do so consistently.
 Moreover, storing data in a database enables the system to
perform complex queries on a large data set (e.g., the records
of several thousand employees).

21 Object Oriented Software Engineering

 Where and how data is stored in the system affects
system decomposition.
 In some cases, for example, in a repository architectural
style ,
 a subsystem can be completely dedicated to the storage of
data.
 The selection of a specific database management system can
also have effects on the overall control strategy and
concurrency management.

22 Object Oriented Software Engineering

 For example, in MyTrip, we decide to store the current Trip in a file
on a removable disk to allow the recovery of the Trip in case the
driver shuts off the car before reaching the finalDestination.
 Using a file is the simplest and most efficient solution in this case,
given that the RoutingSubsystem will only store complete Trips to
the file before shutdown and load the file at start-up.
 In the PlanningSubsystem, however, the Trips will be stored in a
database.
 This subsystem can then be used to manage all Trips for many
drivers, as well as the maps needed to generate the Trips.
 Using a database for this subsystem allows us to perform complex
queries on these data.
 We add the TripFileStoreSubsystem and the MapDBStoreSubsystem
subsystems to MyTrip to reflect these decisions, as illustrated in
Figure 7-6.

23 Object Oriented Software Engineering

Subsystem decomposition of MyTrip after
deciding on the issue of data stores

24 Object Oriented Software Engineering

Identifying persistent objects
 First, we identify which data must be persistent.
 The entity objects identified during analysis are obvious
candidates for persistency.
 In MyTrip, Trips and their related classes (Crossing,
Destination, PlanningService, and Segment) must be
stored.

25 Object Oriented Software Engineering

Identifying persistent objects
 Note that not all entity objects must be persistent.
 For example,
 Location and Direction are constantly recomputed as the car
moves. Persistent objects are not limited to entity objects,
however.
 In a multi-user system,
 information related to users (e.g., Drivers) is persistent,
 as well as some attributes of the boundary objects (e.g.,
window positions, user interface preferences, state of long-
running control objects).
 In general, we can identify persistent objects by examining
all the classes that must survive system shutdown, either
in case of a controlled shutdown or an unexpected crash.
26 Object Oriented Software Engineering
Selecting a storage management strategy
 Once all persistent objects are identified, we need to decide
how these objects should be stored.
 The decision for storage management is more complex and is
usually dictated by nonfunctional requirements:
 Should the objects be retrieved quickly?
 Must the system perform complex queries to retrieve these objects?
 Do objects require a lot of memory or disk space?
 In general, there are currently three options for storage
management:
 Flat Files
 Rational Database
 Object Oriented Database

27 Object Oriented Software Engineering

Flat files
 Files are the storage abstractions provided by operating
systems.
 The application stores its data as a sequence of bytes and
defines how and when data should be retrieved.
 The file abstraction is relatively low level and enables the
application to perform a variety of size and speed
optimizations.
 Files, however, require the application to take care of
many issues, such as concurrent access and loss of data in
case of system crash.

28 Object Oriented Software Engineering

Relational database
 A relational database provides data abstraction at a higher level than
flat files.
 Data are stored in tables that comply with a predefined type called a
schema.
 Each column in the table represents an attribute.
 Each row represents a data item as a tuple of attribute values.
 Several tuples in different tables are used to represent the attributes
of an individual object.
 Relational databases also provide services for concurrency
management, access control, and crash recovery.
 Although scalable and ideal for large data sets, they are relatively
slow for small data sets and for unstructured data (e.g., images,
natural language text).

29 Object Oriented Software Engineering

Object-oriented database
 An object-oriented database provides services similar to
a relational database.
 Unlike a relational database, it stores data as objects and
associations.
 In addition to providing a higher level of abstraction (and
thus reducing the need to translate between objects and
storage entities), object-oriented databases provide
developers with inheritance and abstract data types.
 Object-oriented databases significantly reduce the time
for the initial development of the storage subsystem.
 However, they are slower than relational databases for
typical queries and are more difficult to tune.

30 Object Oriented Software Engineering

Trade-off between flat files, relational
databases, and object-oriented databases

31 Object Oriented Software Engineering

Providing Access Control
 In multi-user systems, different actors have access to different
functionality and data.
 For example,
 an everyday actor may only access the data it creates,
 whereas a system administrator actor may have unlimited access to
system data and to other users’ data.
 During analysis, we modeled these distinctions by associating
different use cases to different actors.
 During system design, we model access by determining which
objects are shared among actors, and by defining how actors
can control access.
 Depending on the security requirements of the system, we
also define how actors are authenticated to the system
 (i.e., how actors prove to the system who they are) and how
selected data in the system should be encrypted.

32 Object Oriented Software Engineering

Example
 For example, in MyTrip, storing maps and Trips for many
drivers in the same database introduces security issues.
 We must ensure that Trips are sent only to the driver who
created them.
 This is consistent with the security design goal we defined for
MyTrip.
 Consequently, we model a driver with the Driver class and
associate it with the Trip class.
 The PlanningSubsystem also becomes responsible for
authenticating Drivers before sending Trips.
 Finally, we decide to encrypt the communication traffic
between the RoutingSubsystem and the PlanningSubsystem.
 This will be done by the CommunicationSubsystem.

33 Object Oriented Software Engineering

Revisions to the design model stemming from the decision to
authenticate Drivers and encrypt communication traffic

34 Object Oriented Software Engineering

Designing the Global Control Flow
 Control flow is the sequencing of actions in a system.
 In object-oriented systems, sequencing actions includes
deciding which operations should be executed and in
which order.
 These decisions are based on external events generated
by an actor or on the passage of time.
 There are three possible control flow mechanisms
 Procedure-driven control
 Event-driven control
 Threads

35 Object Oriented Software Engineering

Procedure-driven control
 Operations wait for input whenever they need data from
an actor.
 This kind of control flow is mostly used in legacy systems
and systems written in procedural languages.
 It introduces difficulties when used with object-oriented
 languages.
 As the sequencing of operations is distributed among a
large set of objects, it becomes increasingly difficult to
determine the order of inputs by looking at the code

36 Object Oriented Software Engineering

Example
Stream in, out;
String userid, passwd;
/* Initialization omitted */
out.println(“Login:”);
in.readln(userid);
out.println(“Password:”);
in.readln(passwd);
if (!security.check(userid, passwd)) {
out.println(“Login failed.”);
system.exit(-1);
}
/* ...*/
 An example of procedure driven control (Java). The code
prints out messages and waits for input from the user.

37 Object Oriented Software Engineering

Event-driven control
 A main loop waits for an external event.
 Whenever an event becomes available, it is dispatched to
the appropriate object, based on information associated
with the event.
 This kind of control flow has the advantage of leading to a
simpler structure and to centralizing all input in the main
loop.
 However, it makes the implementation of multi-step
sequences more difficult to implement.

38 Object Oriented Software Engineering

Example
Iterator subscribers, eventStream;
Subscriber subscriber;
Event event;
EventStream eventStream;
/* ... */
while (eventStream.hasNext()) {
event = eventStream.next();
subscribers = dispatchInfo.getSubscribers(event);
while (subscribers.hasNext()) {
subscriber = subscribers.next()) {
subscriber.process(event);
}
}
/* ... */

39 Object Oriented Software Engineering

Threads
 Threads are the concurrent variation of procedure-driven control:
 The system can create an arbitrary number of threads, each responding to
a different event.
 If a thread needs additional data, it waits for input from a specific actor.
 Thread thread;
Event event;
EventHandler eventHandler;
boolean done;
/* ...*/
while (!done) {
event = eventStream.getNextEvent();
eventHandler = new EventHandler(event)
thread = new Thread(eventHandler);
thread.start();
}
/* ...*/

40 Object Oriented Software Engineering

Summery
 Once a control flow mechanism is selected, we can
realize it with a set of one or more control objects.
 The role of control objects is to record external events,
store temporary states about them, and issue the right
sequence of operation calls on the boundary and entity
objects associated with the external event.
 Localizing control flow decisions for a use case in a single
object not only results in more understandable code, but
it also makes the system more strong to changes in
control flow implementation.

41 Object Oriented Software Engineering