6.0 SYSTEM DESIGN

1
6.0 SYSTEM DESIGN

• System Design Process transforms the analysis
  model into design model
• Process
• 1) Decomposition (guided by design goals)
• 2) Hardware/software platform mapping (deployment
  diagram)
• 3) Persistent data (DB)
• 4) Overall control flow (activity/collaboration
  diagram)
• 5) Access control policy
• 6) Boundary conditions
• Transitional activities from system spec (RAD) to
  final system construction
• A) system design
• B) object design
• C) implementation

2
6.0 SYSTEM DESIGN

• 6.1 Introduction
• Step A System design
• Elicitation of specs focuses on functionality and
  goals
• System design focuses on data structures,
  processes, software, hardware, legacy systems
• The decomposition process entails matching design
  goals against constraints
• (See Fig 6.1 successive changes indicates
  matching constraints against user goals)
• Similarities (House design vs. Software
  Engineering)
• i) Rooms subsystems v) Kitchen layout coding
  complexity/modularity
• ii) Doors interfaces/services vi)
  Re-draw/moving walls redesign of interfaces
• iii)Living area response time/QoS
• iv) No. of rooms use cases

3
Version 1
Version 2
Dining
Study
Study
Bedroom2
Kitchen
Kitchen
Entrancedoor
Entrancedoor
Hallway
Hallway
Master
Dining
Bedroom2
Bath
Bath
Bedroom
Stairs
Entrance door
Study
Bath
Bedroom2
Kitchen
Hallway
Figure 6-1. Example of iterative floor plan
design. Three successive versions show how we
minimize walking distance and take advantage of
sunlight.
Master
Dining
Bedroom
Version 3
4
6.0 SYSTEM DESIGN

• 6.2 Overview
• System design addresses the internal structure
  or software architecture of the system, and how
  the internal functions are impacted by the
  external/operating environment, e.g., OS, DB,
  hardware platform
• Results of system design
• optimized design goals (derived from the
  non-functional requirements)
• the software architecture (guided by several
  issues)

5
6.0 SYSTEM DESIGN

• 6.2 Overview 1
• Issues that guide system decomposition toward
  the software architecture
• i) hardware/software mapping processors,
  communication, data migration, concurrency,
  services using off-the-shelf, DB,
  user-interfaces, compo encapsulation
• ii) data management persistency, storage,
  control, access, security, consistency,
  retrieval, reliability/availability, overall DBMS
• iii) Access Control policy and mechanism,
  extent (system-wide or select components)
• iv) Control Flow sequence of operations (in
  embedded system world software architecture),
  event-driven, interrupt-driven, OS-control
  threads with semaphores/CS
• V) Boundary conditions initialization,
  exception handling (nesting?), e.g., in
  distributed systems, shutdown
• (See Fig 6.2)

6
Figure 6-2. The activities of system design (UML
activity diagram).
7
6.0 SYSTEM DESIGN

• 6.3 SD Concepts System Decomposition
• Properties
• Subsystem a) Application domain is decomposed
  into Classes and organized as Packages and b)
  Solution domain is decomposed into Parts (domain
  Classes and Subsystems
• Interfaces subsystems provide services through
  the interfaces. Services are related operations
  which a subsystem implements to support others.
  (System design focuses on the services
  definition and Object design focuses on the
  operational details for implementing/realizing
  the services.)
• Coupling/Coherence aspects of subsystem
  dependencies (low coupling and high cohesion)
• Layering organizing a system as hierarchy of
  subsystems (lower layers support upper layers)
• Partitioning organizing subsystems into
  peer-to-peer service providers
• All 6 properties define the software architecture
• E.g. (Fig 6-3 decomposition, and Fig 6-4
  decomposition into packages)

8
Figure 6-3. Subsystem decomposition (UML class
diagram).
9
Notification
IncidentManagement
Figure 6-4. Subsystem decomposition for an
accident management system (UML class diagram,
collapsed view). Subsystems are shown as UML
packages. Dashed arrows indicate dependencies
between subsystems.
10
6.0 SYSTEM DESIGN

• 6.3.2 SD Concepts Services and Interfaces
• Service a set of complementary operations
  serving the needs of client subsystems, e.g.,
  notification service ops to snd/recv notices,
  channel alloc, ..
• Interfaces the collection of services
  subsystems provide in an environment (also called
  API) includes the op types, parameters, name of
  ops, constraints access control, return values,
  etc.
• SD focused on defining and designing the
  high-level behaviors in the interfaces (without
  implementation details) and abstraction concept

11
6.0 SYSTEM DESIGN

• 6.3.3 SD Concepts Coupling and Coherence
• Coupling measure of the degree of subsystem
  dependencies highly coupled subsystems are
  highly dependent and changes in one has more
  impact on others
• (See Fig 6-5 and Fig 6-6 a syntax and semantic
  analyzer subsystem sharing a parse-tree common
  interface via attributes vs. via operations.
  Interfacing via operations requires no changes to
  interface, hence the two subsystems wont change)
• Coherence measure of the strength of object
  (inter)dependencies within a subsystem in
  performing complementary tasks. (Low coherence
  is not good!)
• (See Fig 6-7 with low coherence and Fig 6-8
  with reduced complexity and increased coherence
  in 2 subsystems using the 7 /- 2 decomposition
  rule)

12
Binary tree representation
add1OpNode
add2OpNode
aArgNode
cArgNode
bArgNode
Sharing through attributes class OpNode
ArgNode left ArgNode right String
name class ArgNode String name
Sharing through operations class OpNode
Enumeration getArguments() String
getName() class ArgNode String getName()
Figure 6-5. Example of coupling reduction (UML
object diagram and Java declarations). This
figure shows a parse tree for the expression a
b c. The left column shows the interface of
the OpNode class with sharing through attributes.
The right column shows the interface of OpNode
with sharing through operations. Figure 6-6 shows
the changes for each case when a linked list is
selected instead.
13
Linked list representation
Sharing through attributes class OpNode
ArgNode first ArgNode left ArgNode
right String name class ArgNode String
name ArgNode next
Sharing through operations class OpNode
Enumeration getArguments() String
getName() class ArgNode String
getName()
Figure 6-6. Example of coupling reduction (UML
object diagram and Java declarations). This
figure shows the impact of changing the parse
tree representation of Figure 6-5 to a linked
list. In the left column, with sharing through
attributes, four attributes need to change
(changes indicated in italics). In the right
column, with sharing through operations, the
interface remains unchanged.
14
Figure 6-7. Decision tracking system (UML class
diagram). The DecisionSubsystem has a low
coherence The classes Criterion, Alternative,
and DesignProblem have no relationships with
Subtask, ActionItem, and Task.
15
Figure 6-8. Alternative subsystem decomposition
for the decision tracking system of Figure 6-7
(UML class diagram). The coherence of the
RationaleSubsystem and the PlanningSubsystem is
higher than the coherence of the original
DecisionSubsystem. Note also that we also reduced
the complexity by decomposing the system into
smaller subsystems.
16
6.0 SYSTEM DESIGN

• 6.3.4 Layer and Partitions
• One design goal to reduce complexity by problem
  decomposition
• Layers
• Layered architecture in which lower layers
  support upper ones (with abstraction)
• (See Fig 6.9)
• Closed architecture layered but each layer
  depends only on one directly below it (e.g.,
  ISO-OSI protocol stack or Unix OS)
• (See Fig 6.10 in these, the OS provides
  middleware such as CORBA OMG, JavaRMI between
  upper the Application and Transport Layers and
  protocols like TCP/IP as middleware for the lower
  layers)
• (See Fig 6.11)

17
Figure 6-9. Subsystem decomposition of a system
into three layers (UML object diagram). A subset
from a layered decomposition that includes at
least one subsystem from each layer is called a
vertical slice. For example, the subsystems A, B,
and E constitute a vertical slice, whereas the
subsystems D and G do not.
18
Figure 6-10. An example of closed architecture
the OSI model (UML class diagram). The OSI model
decomposes network services into seven layers,
each responsible for a different level of
abstraction.
19
Figure 6-11. An example of closed architecture
(UML class diagram). CORBA enables the access of
objects implemented in different languages on
different hosts. CORBA effectively implements the
Presentation and Session layers of the OSI stack.
20
6.0 SYSTEM DESIGN

• 6.3.4 Layers and Partitions 1
• Open architectures E.g., Motif user interface
  toolkit for X11 (Xlib for a window object, Xt for
  geometricl-object manipulation)
• Users of a window manager in Motif can bypass
  the upper layers and include lower layers like
  Xlib fostering low coupling and integration,
  but limits reuse in case of changes in, e.g.,
  Xlib
• (See Fig 6.12)

21
Application
Motif
Xt
Xlib
Figure 6-12. An example of open architecture the
OSF/Motif library (UML class diagram, packages
collapsed). Xlib provides low-level drawing
facilities. Xt provides basic user interface
widget management. Motif provides a large number
of sophisticated widgets. The Application can
access each of these layers independently.
22
6.0 SYSTEM DESIGN

• 6.3.4 Layers and Partitions 2
• Partitions
• Subsystems at the peer-to-peer level, each
  responsible for a class of services
• E.g., A Car system with partitions ignition
  system, fuel system, navigation system
• General Decomposition First decompose into
  partitions and into layers
• Too many subsystems and detailed decomposition
  adds complexity and overhead in interface
  definition/management

23
6.0 SYSTEM DESIGN

• 6.3.5 Software Architecture
• Definition The overall decomposition process
  which takes into account the spatial relationship
  among the resultant subsystems, interface
  protocols, global control flow, and
  error/exception management policies and
  mechanisms
• Types
• A. Repository subsystems communicate via
  centralized data (using lock for concurrency and
  integrity issues) E.g., a bank DBMS or
  Compilers parse-tree and symbol-table
• Because of the volume of traffic (comm) to the
  repository coupling among subsystems is high and
  modifications of the repository are difficult
• (See Fig 6.13 and Fig 6.14)

24
Figure 6-13. Repository architecture (UML class
diagram). Every subsystem depends only on a
central data structure called the Repository. The
Repository in turn, has no knowledge of the other
Subsystems.
25
Figure 6-14. An instance of the Repository
architecture (UML Class diagram). A modern
Compiler incrementally generates a ParseTree and
a SymbolTable that can be later used by Debuggers
and SyntaxEditors.
26
6.0 SYSEM DESIGN

• 6.3.5 Software Architecture - 1
• B. Model-View-Controller (MVC) architecture has
  three component subsysems
• A) Model subsystem for keeping domain
  knowledge/data
• B) View subsystem for visualizing/viewing the
  domain data
• C) Controller subsystem for managing user
  interactions with the system
• The Model subsystem (like the repository
  architecture) holds the state of objects
• The Controller subsystem holds the
  (user-personified) control objects for processing
  the models the control flow
• The View subsystem holds the boundary objects
  (for user visualization)
• Communication among objects is via
  notify/subscribe protocols
• (See Fig 6.15)

27
Figure 6-15. Model/View/Controller architecture
(UML class diagram). The Controller gathers input
from the user and sends messages to the Model.
The Model maintains the central data structure.
The View(s) display the Model and is notified
(via a subscribe/notify protocol) whenever the
Model is changed.
28
6.0 SYSTEM DESIGN

• 6.3.5 Software Architecture - 2
• E.g., sequence of events in a MVC architecture
• Using a collaboration diagram (Fig 6-16 flow of
  events among the objects)
• And the corresponding effects two views of a
  file-object, named 9DesignPatterns2.ppt (See Fig
  6-17)
• The subscription/notification protocols removes
  interdependencies among the objects in Model and
  View allowing decoupling of their functions due
  to the frequent changes
• A design tool for accomplishing this is the
  Observer Pattern
• MVC architecture is suitable for interactive
  systems and developing visualization tools

29
Figure 6-16. Sequence of events in the
Model/View/Control architecture (UML
collaboration diagram).
30
Figure 6-17. An example of MVC architecture. The
model is the filename 9DesignPatterns2.ppt. One
view is a window titled Comp-Based Software
Engineering, which displays the contents of a
folder containing the file 9DesignPatterns2.ppt.
The other view is window called
9DesignPatterns2.ppt Info, which displays
information related to the file. If the file name
is changed, both views are updated by the
controller.
31
6.0 SYSTEM DESIGN

• 6.3.5 Software Architecture - 4
• C. Client-Server architecture C-S service
  request/response is via RPC (remote procedure
  call protocol)
• Like the Repository model, the C-S server
  implements a process that protects server data
  / programs (sort of localized in the server) and
  provides request service
• E.g., a centralized database for an information
  system
• E.g., a WWW with multiple user browser types and
  request from clients
• C-S architecture is good for distributed systems
  design and modeling
• (See Fig 6-18 and Fig 6.19)

32
Server


Client
requester
provider
service1()
service2()

serviceN()
Figure 6-18. Client/server architecture (UML
class diagram). Clients request services from one
or more Servers. The Server has no knowledge of
the Client. The client/server architecture is a
generalization of the repository architecture.
33
netscapeWebBrowser
www12.in.tum.deWebServer
iexplorerWebBrowser
lynxWebBrowser
www.cs.cmu.eduWebServer
mosaicWebBrowser
Figure 6-19. The World Wide Web as an instance of
the client/server architecture (UML object
diagram).
34
6.0 SYSTEM DESIGN

• 6.3.5 Software Architecture -5
• D. Peer-to-Peer architecture a generalization
  of the C-S architecture clients can become
  servers (from the other side) and servers can
  become clients similarly.
• Useful, but difficult to design as it is
  susceptible to deadlocks and complex control flow
• (See Fig 6-20 and Fig 6-21)

35
requester
Peer


provider
Figure 6-20. Peer-to-peer architecture (UML class
diagram). Peers can request services from and
provide services to other Peers.
36
1. updateData
application1DBUser
databaseDBMS
application2DBUser
2. changeNotification
Figure 6-21. An example of peer-to-peer
architecture (UML collaboration diagram). The
database server can both process requests from
and send notifications to applications.
37
6.0 SYSTEM DESIGN

• 6.3.5 Software Architecture - 6
• E. Pipe and Filter architecture a subsystem
  (serving as a filter) received input set,
  processes it internally and sends output set
  (through a pipe) to a waiting subsystem (on the
  receiving end).
• Concept is Unix OS environment used for
  interprocess communication (automatic
  transformation of input data, automatic piping,
  and synchronized reception without human
  intervention)
• (See Fig 6-22 and Fig 6-23)

38
input
output

1
Pipe
Filter
output
input

1
Figure 6-22. Pipe and filter architecture (UML
class diagram). A Filter can have many inputs and
outputs. A Pipe connects one of the outputs of a
Filter to one of the inputs of another Filter.
39
Figure 6-23. An instance of the pipe and filter
architecture (Unix command and UML activity
diagram).
40
6.0 SYSTEM DESIGN

• 6.3.6 UML Deployment Diagrams
• Used for relating (connecting) component diagrams
  to hardware nodes. The components are
  self-contained run-time entities that provide
  services to other components
• E.g. The Netscape browser (component) servicing
  the user (actor)
• Notation A node in a deployment diagram is a
  box, containing component icons, and interfaces
  between boxes are represented by dashed arrow
• (See Fig 6-24 more high level component nodes,
  revealing nothing about the interfaces used for
  communication or classes they contain)

41
myMacMac
UnixHost
WebServer
UnixHost
aPCPC
Database
IExplorer
Figure 6-24. A UML deployment diagram
representing the allocation of components to
different nodes and the dependencies among
components. Web browsers on PCs and Macs can
access a WebServer that provides information from
a Database.
42
6.0 SYSTEM DESIGN

• 6.3.6 UML Deployment Diagrams 1
• Fig 6-25 Depicts a refined deployment diagram,
  showing the classes (no need to show
  associations/links, etc) and the interfaces/port
  for communication

43
WebServer
GET
URL
POST
DBQuery
HttpRequest
DBResult
File
Figure 6-25. Refined view of the WebServer
component (UML deployment diagram). The WebServer
component provides two interfaces to browsers A
browser can either request the content of a file
referred by a URL (GET) or post the content of a
form (POST). The WebServer component contains
five classes URL, HttpRequest, DBQuery, File,
and DBResult.
44
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• System design entails the transformation of the
  analysis model, together with the non-functional
  requirements and constraints in the RAD, into the
  design model toward the implementation
• Example car driving plan to motivate the
  discussion of 8 main activities
• Consider the input Car Trip Analysis Model
  collection of use cases, class diagram with data
  dictionary, and non-functional requirements
• (See Fig 6-26 and Fig 6-27 and Fig 2-8)
• The non-functional requirements
• - using a wireless modem for reliable connection
  to a PlanningService procider
• - accurate directions are given even on modem
  failure
• - modem connection time must be minimized
• - support replanning of the trip while connection
  is still available
• - PlanningService can support 50 drivers and 1000
  trips

45
Figure 6-28. Analysis model for the MyTrip route
planning and execution.
46
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 1
• A. Identifying design goals
• From the non-functional requirements
  reliability, fault tolerance, connectivity,
  security, number of drivers and trips,
  replanning/modifiability, cost-effectiveness.
• Others connection time or response time,
  performance, maintenance (upkeep of driving
  data), etc., which are gleaned from the RAD or
  application domain
• Criteria and goals may be conflicting requires
  compromises, trade-offs and optimization
• (See Table 6-1 to Table 6-6)

47
6.0 SYSTEM DESIGN

• 6.4 System Design Activities - 2
• B. Identifying Subsystems
• Similar application of Abbotts heuristics to
  identifying objects
• Requires subsystem decomposition, mergers, and
  additions iterative process
• Initial decomposition is from the functional and
  object models (use cases base use cases, shared
  use cases, extended/included use cases) and the
  classes.
• Key grouping use cases and classes into related
  entities as packages of subsystems
• Heuristics for Identifying subsystems
• Assign objects identified in one use case into
  the same subsystem
• Create a dedicated subsystem for data moving
  objects in the system
• Use a fewer number of links/associations crossing
  subsystem boundaries
• Objects in the same subsystem must be
  functionally related

48
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 3
• C. Encapsulating subsystems
• Packages of subsystems reduce complexity or
  minimize dependencies among classes
• Encapsulating subsystems inside a front-end
  package, called a Façade, further hides the
  internals of the classes making the internals
  only accessible by the façade. The outside world
  can get to these classes only via public
  services/interface provided in the façade. This
  design strategy uses the Façade Pattern via
  encapsulation
• E.g., Encapsulating the Compiler subsystem in a
  Façade, by providing an interface service
  routine, compile(s).
• (See Fig 6-30)

49
Compiler
compile(s)
create()
getToken()
generateParseTree()
create()
create()
Figure 6-30. An example of the Facade pattern
(UML class diagram).
50
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 4
• 4. Mapping Subsystems to Processors and
  Components
• Selecting a hardware configuration and a platform
• Allocating/assigning subsystems to different
  processors, and design comm support between
  subsystems
• Underlying processors are modeled as nodes in
  Deployment Diagrams
• Underlying virtual machines (the OSs, the
  DBMSs, Networks), compatible with the
  processors, but the selection could be
  constrained by cost, processor-type, etc.
• E.g., For the MyTrip problem, select two
  processors (nodes) an Internet host and an
  onboard (embedded in the car) processor, the
  Unix-Netscape for the host, and some
  RTOS-Explorer for the onboard
• (See Fig 6-31)

51
OnBoardComputer
WebServer
PlanningSubsystem
RoutingSubsystem
Figure 6-31. Allocation of MyTrip subsystems to
hardware (UML deployment diagram).
RoutingSubsystem runs on the OnBoardComputer
while PlanningSubsystem runs on a WebServer.
52
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 5
• Allocating objects/subsystems to nodes done
  after selecting the operating environ
• Object/subsystem assignment exposes missing
  subsystems, e.g., for data movement
• E.g., in the MyTrip, a CommunicationSubsystem is
  need to support the comm between the wireless
  modem and all other objects/subsystems
• There is the need for surrogate subsystems
  SegmentProxy- one that takes care of info
  pertaining to a segment (of trip) and TripProxy -
  another that helps in planning a trip. These are
  needed inside the RoutingSubsystem to act as
  Proxies on behalf of the two subsystems in the
  PlanningSubsystem. The two proxies communicate
  with the CommicationSubsystem.
• The Proxy Design Pattern is used to create proxy
  subsystems as surrogates of others without
  duplicating full functionality
• (See Fig 6-32)

53
PlanningSubsystem
RoutingSubsystem
RouteAssistant
PlanningService
Trip
Location
Destination
TripProxy
Direction
Crossing
Segment
SegmentProxy
Figure 6-32. Revised design model for MyTrip (UML
Class diagram, associations omitted for clarity).
54
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 6
• Encapsulating Existing/Legacy and Off-the-Shelf
  Components
• Need to incorporate existing systems and reuse of
  off-the-shelf components to reduce
  design/development time and costs
• Encapsulating also hides the internals of the
  existing component, further decoupling the system
  under construction from the existing
• The integrator / glue is called the Adapter
  Pattern or Wrapper
• Wrappers are useful in developing e.g.,
  communication protocol glues for distributed
  applications developed in different languages or
  that use different protocols (e.g., CORBA
  environment)
• (See Fig 6-33 and Fig 6-34)

55
adaptee
Figure 6-33. Adapter pattern (UML class diagram).
The Adapter pattern is used to provide a
different interface (NewInterface) to an existing
component (LegacySystem).
56
6.0 SYSTEM DESIGN

• 6.4 System Design Activities - 7
• 5. Defining Persistent Data Stores preserving
  data values consistently over time
• The kind DB system and its DBMS for
  storage/processing/retrieval impacts system
  decomposition, control strategy, and concurrency
  management
• E.g., in the MyTrip problem, a small file in
  RoutingSubsystem will hold trip-files on
  short-term basis on the onboard computer, while
  the PlanningSubsystem will hold persistent
  trip-files in a DB over time
• Persistent data are kept because it may be costly
  to recalculate, otherwise dont
• Factors to consider in selecting DB type complex
  queries, data size/space, management, use of flat
  files, Relational DB, OO database (see p. 205
  tradeoffs)
• (See Fig 6-35)

57
PlanningSubsystem
MapDBStoreSubsystem
Figure 6-35. Subsystem decomposition of MyTrip
after deciding on the issue of data stores (UML
class diagram, packages collapsed for clarity).
58
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 8
• Encapsulating data stores once a DB is selected
  provide an interface, a bridge to the DB which
  will hide the vendor-specific services and data
  layout. The interface will decouple your
  classes/subsystems from the DB
• The abstract interface available to the client
  (your program) and corresponding abstract
  implementation, which maps requests/queries to
  specific DBMS queries, are need.
• The AbstractInterface and AbstractImplementor
  classes are supported by the Bridge Pattern
  E.g., ODBC and JDBC provide abstractions to
  relational databases
• (See Fig 6-36 and Fig 6-37)

59
imp
Abstraction
Implementor
provides
RefinedAbstraction
Figure 6-36. Bridge pattern (UML class diagram).
60
imp
ODBC
ODBC Implementation
Figure 6-37. Bridge pattern for abstracting
database vendors (UML class diagram). Removing
the dependency from database vendors from the
systems provides more flexibility.
61
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 9
• 6. Defining Access Control
• Multiple actor access to functionality and shared
  data requires protected or restricted access
• Access control is modeled using different use
  cases during the analysis phase
• Access control is modeled by focusing on the
  object model determining which actor accesses
  which objects and creating an authentication
  for access control and encryption to encrypt
  traffic data for security
• (See Table 6-7 expanded to include
  authentication-of-drivers and traffic-encryption
  concerns in the design model)
• General implementation strategy develop an
  access matrix of user/object, where the cells
  indicate the permissible operations, or access
  rights classical in OS, DB, Network
  applications
• (See Table 6-8)

62
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 10
• Access control matrix representations the
  select method can impact performance
• 1) global access control (actor, class,
  operation)-tuple in each cell
• 2) access control list (actor, operation)-pair
  for each class in the list
• 3) capability list (class, operation)-pair for
  each actor in the list
• Subclassing under the access-control-list method
  can discriminate actor access
• Static access control typically implemented as
  access matrix
• Dynamic access control supports dynamically
  assigned roles to actors or objects, and can be
  modeled using the Proxy Pattern
• (See Fig 6-38 dynamic assignment of portfolios
  to brokers)

63
1
Broker

Portfolio
buy()
buy()
sell()
1
1
sell()
estimateYield()
estimateYield()
Figure 6-38. Dynamic access implemented with a
protection Proxy. The Access association class
contains a set of operations that Broker can use
to access a Portfolio. Every operation in the
PortfolioProxy first checks with the
isAccessible() operation if the invoking Broker
has legitimate access. Once access has been
granted, PortfolioProxy delegates the operation
to the actual Portfolio object. One Access
association can be used to control access to many
Portfolios.
64
6.0 SYSTEM DESIGN

• 6.4 System Design Activities 11
• Authentication verifying association between an
  actor/subsystem and the system. Typical
  mechanisms name, ID, password (with encryption),
  smart cards, fingerprints
• Encryption preventing unauthorized access by
  converting plaintext (message) to a ciphertext
  (encrypted). Need a key and an algorithm to
  decipher (decrypt) the ciphertext.
• Encapsulating access control
• If using off-the-shelf or vendor-supplied
  algorithms, policies, and mechanisms be careful
  of Trojan Horse entrapment (no escape hatches
  hidden in the product).
• General solution develop an encapsulation of
  general algorithms, with an abstract interface,
  for several concrete algorithms using the
  Strategy Pattern
• (See Fig 6.40)

65
Strategy class
Message
IDEA
getBlock()
Context class
ConcreteStrategy
classes
IDEA_Vendor_A
IDEA_Vendor_B
Figure 6-40. An example of a Strategy pattern
encapsulating multiple implementation of the IDEA
encryption algorithm (UML class diagram). The
Message and IDEA classes cooperate to realize the
encryption of plain text. The selection of an
implementation can be done dynamically.
66
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• 7. Designing the Global Control Flow
• Which operations to execute and the
  order/sequence of operations
• In OO (UML) methodologies, it is the actors
  initiation or passage of time
• During analysis, objects are assumed to interact
  with each other and timing and processor on which
  they are interacting is not a big issue
• During design, objects behavior and on which
  processors (assigned) they would run and timing
  issues become important

67
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• Mechanisms for implementing Control Flow
• 1) Procedure-driven operations wait on input
  from actor not suitable for OO design since
  control flow is distributed in an object-space
  and the other is not determinable
• 2) Event-driven a main program initiates the
  external event to activate objects in the system
  (which are waiting on that event) centralizes
  control but hard to implement in multi-step
  (nested conditions) sequences
• 3) Threads concurrent version of
  procedure-driven, where several operations
  (threads of execution) wait on different event
  (input arrival) and behavior according they
  respond to input-stimuli from the actor. Hard to
  debug and create repeatable test cases and
  degenerates to non-deterministic control flow
• (See Fig. 6-41, Fig 6-42, and Fig 6-43)

68
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• Issues
• A) procedure-driven is good for unit testing
  (using test-drivers) subsystems
• B) Event-driven (debugging tools) and interface
  support are more matured than threads control
  flow, which currently lacks such tools.
  (Event-driven flow can influence design rationale
  and choices, e.g., in embedded systems.)
• C) Control objects are used to describe the
  control flow (or software architecture) of the
  system. Control objects receive stimuli, store
  state on temporary basis, and issue signals to
  activate other control objects, entity objects,
  and boundary objects
• D) Good idea to allow one control object to start
  up control flow in a use case

69
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• Encapsulating Control Flow
• Control flow is determined by the sequence of
  stimuli/inputs to the various control objects
  waiting on the inputs. The objects request the
  input and to decouple the requesting control
  objects from the service objects (the input
  handlers), the request satisfaction must be
  assigned to separate command objects.
• The decoupling can be achieved by using the
  Command Pattern, which effectively centralizes
  control flow in control objects and not in
  boundary or entity objects
• The Command abstract class defines the order of
  execution of the commands (sequence of operations
  based on order of input arrivals).
• The Command abstract class issues the
  concrete/specific commands using the
  ConcreteCommand class to satisfy the control flow
  (or order)
• (See Fig 6-44 and Fig 6-45)

70
User
invokes
ConcreteCommand1
execute()
Figure 6-44. Command pattern (UML class
diagram).This pattern enables the encapsulation
of control such that user requests can be treated
uniformly, independent of the specific request.
71

Command

MenuItem
Menu
execute()
execute()
Application
Document
CopyCommand
paste()
execute()
copy()
PasteCommand
execute()
Figure 6-45. An example of a Command pattern (UML
class diagram). In this example, menu items and
operations on documents are decoupled. This
enables us to centralize control flow in the
command objects (CopyCommand and PasteCommand)
instead of spreading it across boundary objects
(MenuItem) and entity objects (Document).
72
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• 8. Identifying Boundary Conditions
• Focus is on how the system is initiated/started,
  shutdown/closed, handling exceptions or failures
  (software or hardware)
• E.g., for the MyTrip systems how maps get into
  onboard computer, how to load the software to
  onboard computer, how data (route into,
  schedules, etc.) get into or modified in the
  computer,
• To complete the design, go back to define new use
  cases to include the missing boundary objects
  a set of use cases which constitutes the
  Administrative Subsystem and other ltltincludegtgt
  use cases for common functions
• Modify the MyTrip analysis model to include the
  Administrative Subsystem, and modify the
  MapDBStoreSubsystem use case to reflect
  boundary conditions of shutdown, data
  corruption, data consistency check, etc.
• (See Fig 6-46, Fig 6-47, and Fig 6.48)

73
ManageDrivers
ltltincludegtgt
ManageMaps
StartServer
PlanningService
ltltincludegtgt
Administrator
ManageServer
ShutdownServer
ltltincludegtgt
ConfigureServer
Figure 6-46. Administration use cases for MyTrip
(UML use case diagram). ManageDrivers is invoked
to add, remove, modify, or read data about
drivers (e.g., user name and password, usage log,
encryption key generation). ManageMaps is invoked
to add, remove, or update maps that are used to
generate trips. ManageServer includes all the
functions necessary to start up and shutdown the
server.
74
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• Exceptions and Handling
• Causes a) user error wrong input (range or
  constraint error), b) hardware failure power
  fail, surge, worn-out part, network failure c)
  software error design/programming error
• Exception Handling mechanisms for handling and
  correcting the error without total shutdown

75
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• 9. Anticipating Change
• System decomposition into subsystem foster low
  coupling (minimal impact on changes) and reduces
  complexity
• System decomposition must allow flexible software
  architecture for future changes
• Anticipating changes and design
  techniques/methodologies to deal with them
• 1) new vendor/technology replacements in
  response to growth, performance, dynamics
• 2) new implementation efficiency, performance,
  new non-functional requirements
• 3) new views usability issues and new
  users/perceptions of system
• 4) new complexity of application domain
  deployed systems that generates new goals
• (See Fig 6.49)

76
6.0 SYSTEM DESIGN

• 6.4 System Design Activities
• 10. Reviewing the Design
• Done between project manager and development team
  (without user/client)
• The process may involve peer reviews (e.g.,
  developers from different project)
• Some of the factors to observe during review
• A) traceability/correctness mapping the design
  model to the analysis model
• B) completeness all boundary conditions,
  missing use cases/subsystems, etc.
• C) consistent no contradictions, prioritized
  goals, addressed non-func req, naming
• D) realistic feasibility of supporting
  technologies, reliability/performance achievable
• E) readable subsystem names, relating entity
  names functionality/phenomena

77
6.0 SYSTEM DESIGN

• 6.5 Managing System Design
• 1. The Design Document (SDD) baselined for
  object design step (p.222)
• Include a section on how design communication was
  handled/documented communication modes and
  mechanisms used in the system design process
• 2. Assigning Responsibilities
• an architect
• architecture team
• document editor, configuration manager, reviewer