A Typical Repository Architecture

1
A Typical Repository Architecture
GUI
Analysis process 1
Analysis process n
Control
...
...
DBMS
Database
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
2
Trelagsmodellen
3
Layered Architecture
3D engine layer



Role-playing game layer
uses
Layout
RolePlayingGame
Characters
uses
Application layer
Encounter Characters
Encounter Environment
Encounter Game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
4
Layered Architecture Example Using Aggregation
Print monthly statements.
Requirement
Architecture
uses
Ajax bank printing Layer
Ajax bank common library Layer
Accounts Layer
Vendor-supplied Layer
Class model (relationships within packages not
shown)
Ajax bank printing
Printer
Page
Formatter
Accounts
Vendor-supplied layer not shown
Account
Customer
Ajax bank common library
AjaxLogo
AjaxDisclaimer
Regulations
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
5

• 1. Decompose into self-contained modules.
• 2. Compare with a standard architecture (e.g.,
  Garlan and Shaws classification). Improve
  decomposition.
• Data flowing in batches between processing
  stations?
• batch sequential dataflow
• Processing stations waiting for data, then
  executing?
• pipe-and-filter dataflow
• Processes executing in parallel?
• parallel communicating processors
• A process supplying the needs of user processes?
• client-server
• A process only reacting to events occurring upon
  it?
• event systems
• Each execution the interpretation of a script?
• interpreters
• An application centered on a data store?
• repository
• Arranged in layers?
• layered
• Try to develop at least two alternative
  architectures.

One way to ...
Select an Architecture 1
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
6
Select an Architecture 2
One way to ...

• 2. Select among the alternatives identified.
• 3. Add classes to those from requirements
  analysis, to accommodate the architecture
  selected
• e.g., data flow to control flow among the
  elements
• e.g., event systems to control transitions
  among states
• 4. Apply an existing framework and/or design
  pattern.
• if a helpful one can be identified
• 5. Partition the collection of classes into
  packages
• ideally, 4-8 (nest packages for larger
  applications)
• each package should make sense in the language of
  the application (e.g., videos OK big classes
  not OK)
• 6. Verify high cohesion within parts low
  coupling among parts -- otherwise, adjust choice.
• 7. Consider introducing a Façade class/object to
  control the interface to each package

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
IEEE 1016-1987 SDD Example Table of Contents
(Reaffirmed 1993)
1. Introduction 1.1. Purpose 1.2. Scope
1.3. Definitions, acronyms
abbreviations 2. References 3. Decomposition
description 3.1. Module decomposition
3.1.1 Module 1 description 3.1.1 Module 2
description 3.2 Concurrent process
decomposition
3.2.1 Process 1 description 3.2.2 Process
2 description 3.3 Data decomposition
3.3.1 Data entry 1 description 3.3.2
Data entry 2 description
4. Dependency description 4.1 Intermodule
dependencies 4.2 Interprocess dependencies
4.3 Data dependencies 5. Interface
description 5.1 Module interface
5.1.1 Module 1 description 5.1.2 Module 2
description 5.2 Process interface
5.2.1 Process 1 description 5.2.2 Process
2 description 6. Detailed design 6.1 Module
detailed design 6.1.1 Module 1 detail
6.2.2 Module 2 detail 6.2 Data detailed
design 6.2.1 Data entity 1 detail
6.2.2 Data entity 2 detail
Architecture
8
Table 5.2 Fuzzy method for comparing
architectures
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
Architecture Metrics (IEEE 982.1)

• Number of entries and exits per module (package)
• If Façade used, number of entries number of
  public methods in Façade object.
• e.g., class EncounterGame has public methods
  getEncounterGame(), execute(), reportState(), and
  showResult(). exit points is number of public
  functions that return quantities to the caller or
  make changes in the environment external to them.
  

10
Cyclomatic complexity

• Cyclomatic complexity (CC) E - N 2
• E the number of edges of the graph
• N the number of nodes of the graph

11
Cyclomatic Complexity Risk

• 1-10 a simple program, without much risk
• 11-20 more complex, moderate risk
• 21-50 complex, high risk
• 50- .. untestable program (very high risk)

12
Architecture for a Simulation
SimItems
SimEvents
SimConfiguration
SimItem
SimEvent
QueueForTeller
Simulation execute() initialize() time()
SimDriver
SimConfiguration setUp()
Random
ScheduledEvents addEvent() removeEarliest()
serviceDuration
Teller
Number
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
13
Notes on Architecture Inspections

• Inspected against requirements.
• Architecture lots of room for the creativity
• appears to be difficult to inspect,
• Payoff for defect detection is highest at the
  early stages
• Metrics provide an anchor

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
State Design Pattern Applied to Role-Playing Game
RolePlayingGame
state
RPGame handleEvent()
GameState handleEvent()
state.handleEvent()
EncounterGame
EncounterGame
Waiting handleEvent()
Setting Qualities handleEvent()
Reporting handleEvent()
Engaging handleEvent()
SettingUp handleEvent()
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Architecture Alternative 2 for Encounter
ActionListener
AreaConnector area1 area2 transition()
2
Area display()

ForeignCharacter
PlayerCharacterWindow set( Quality, float ) exit()
PlayerCharacter
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Table 5.3 Table-Driven State-Transition Event
Handling
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
17
Table 5.4 Fuzzy method for comparing
architectures
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Monitor - actuator
19
Sanity check
20
Watchdog