chapter 14 architectures and frameworks. process phases discussed in this chapter requirements...

Chapter 14Architectures and Frameworks

Process Phases Discussed in This ChapterRequirementsAnalysis

Design

Implementation

ArchitectureFramework Detailed Design

xKey: = secondary emphasisx = main emphasis

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Learning Goals for This Chapter

… the goals of software architecture

… the meaning of “frameworks”

… express a software architecture

… show a full class model

… show a full state model

… show a component model

… build frameworks

… complete a detailed design

Be able to …

Understand …


An Architecture for a Video Store Application

Rentals

Customers

Videos


A Sequence for Obtaining The Class Model

1. Create domain classes

-- from requirements analysis

3. Create remaining design classes

-- to complete the class model-- possibly use framework

Moregeneral2. Create architecture

-- typically use framework

0. Framework (some or all pre-existing)


TargetApplication

Class model“with objects of these classes ...”

e.g., with Engagement … classes

State model“reacting to these events ...”

e.g., when foreign character enters

Use-case model“Do this ...”

e.g.*, engage foreign character

Data Flow model“in this way ...”

e.g., character scores flow

from … to …

To express requirements, architecture & detailed designModels

* Video game exampleAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

TargetApplication Class model

State model

Use-case model:

Data flow model

Use case

Scenarios

Business use case

elaborated by ...

Sequencediagram

Role of Use Case

Models

TargetApplication

Class model

State model

Use-case model

Data flow model

class

methods

packageConsists

of ...

Jacobson et al

Role of Class Models

Role of Component Model

TargetApplication

Class model

State model

Use-case model

Data Flow model

Processing element

Sub-processing element

Data type

organizedby ...

Jacobson et al

1

Data store

Data Flow Diagram: Explanation of Symbols

Account #& deposit

balancequery

User

accountdatabase

accountdata

Get deposit

Create account

summary

Validatedeposit

Printer

Input

Output

Processingelement

Data typeDirectionof data flow

Data store

…...


Partial Data Flow Diagram for ATM

Application

account #& deposit

balancequery

account #& deposit

account #

User

Makeinquiry

accountdatabase

deposittransaction

accountdata

Get deposit

Get inquiry

Validateinquiry

Do deposit

transaction

Create account

summary

Validate deposit

errorerror

Printer

memberbanks

bank name

Display account

account #

accountdata

accountdisplay


screentemplate

Detailed Data Flow Diagram for a Banking Application

Account.getPass-word()Account.

verifyPass-word()

Expand details……..

Pass-word

Customer

balance

unacceptableATM users

Deposit-screen.

display()

Account.getDeposit()

status

locallog

balance

User

Customer.getDetails()

Customer


Partial Encounter Video Game State Model

Setting up Preparing

Waiting

Complete setup

Foreign character

enters area

Engaging

Player clicks

qualities menu


Player moves to adjacent

area

[foreign character absent]

[foreign character present]

Using Conditions in State-Transition Diagrams

Engaging

Waiting

event

condition

condition

state

state


Player moves to adjacent

area

Settingqualities

Encounter State-Transition Diagram

Setting up

Engaging

Waiting

Player completes

setup

Player dismisses

report window

Reporting

Encounter completed

Player dismisses

set qualities widow

Player requests

status

Player requests to set qualities

Foreign character

enters area

[foreign character absent]

[foreign character present]

Player quits

Foreign character

enters area


Role of State Models

TargetApplication

Class model

State model: “reacting to these events”

Use-case model

Component model

States

Transitions

Substatesdecomposeinto ...

Jacobson et al


Design Goal At Work: Correctness/Modularity

We want to decompose designs into modules, each well-knit, and depending on few others.


Cohesion and Coupling

1

2 3 4

5 6High cohesion Low coupling

High coupling

Bridge

component

component

component

Steeltruss


Architecture and Modularization of Encounter Video Game

EncounterCharacters

EncounterGame

EncounterCast«facade»

EncounterGame«facade»

EncounterEnvironment

EncounterEnvironment«facade»


1. Develop a mental model of the application.o as if it were a small application

e.g., personal finance application ...

… “works by receiving money or paying out money, in any order, controlled through a user interface”.

2. Decompose into the required components.o look for high cohesion & low coupling

e.g., personal finance application ...

… decomposes into Assets, Sources, Suppliers, & Interface.

3. Repeat this process for the components.

4. Consider using Façade for each package.

To Begin Selecting a Basic Architecture


Key Concept: Modules Must …

… each have high cohesion, but be loosely coupled.


A Classification of Software Architectures

Data Flow o Data flowing between functional elements

Independent Components o -- executing in parallel, occasionally communicating

Virtual Machineso Interpreter + program in special-purpose language

Repositorieso Primarily built around large data collection

Layeredo Subsystems, each depending one-way on another

subsystem

Garlan & Shaw


Design Goal At Work: Reusability

We classify architectures so as to use them for several applications.


bank address

account dataaccount data

Bank

Maintain wired financial transactions.

Bankdata

A Class model:

Requirement:

record Logtransaction

analyze

deposit

deposit data

withdrawal data

transactionresult

transaction

Architecture(data flow)

Accountwithdraw()deposit()

account data

Comm

account data

*1

Transactionanalyze()record()

Example of Data Flow Architecture and

Corresponding Class Model

transactionresult

withdraw


Repository Architecture

database

App 1

App 2

App 3

Applications mostly storage,retrievals, and querying.


Role-playing game layer

Layered Architecture

Characters LayoutRolePlayingGame

EncounterCharacters

EncounterEnvironment Encounter Game

Application layer

3D engine layer

«uses»

«uses»

. . . .

. . . .


Layered Architecture Example Using Aggregation

Class model: (relationships within packages and Vendor-supplied layer not shown)

AjaxLogo AjaxDisclaimer Regulations

Ajax bank common libraryAccounts

Account Customer

Ajax bank printing

Printer Page Formatter

Vendor-supplied LayerAccounts Layer Ajax bank common library Layer

Ajax bank printing Layer

Requirement: Print monthly statements

“uses”

Architecture:


Coad-Yourdon Use of Packages

Problem domain package

Interface package

Data management package

Task management package


Key Concept: A Software Architectures is Essentially ...

… a Data Flow, a set of Independent Components, a Virtual Machine, a Repository, or Layers.



We create frameworks because we want to reuse groups of classes and algorithms among them.


Domain classes

Design classes

Class Model vs. Architecture and Detailed Design Framework classes

Detailed design

Architecture

Class Model for this application

DPDP

DP

DP

DP

DP

DP = design pattern


Selected Framework Goals

Persistence Service o Store instances between executions

Identity Service o Identify objects sufficiently to

retrieve them across executions Pooling

o - of objects: Reusing objects at runtime to save time and space

o - of threadso - of database connections

Security Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept: We Use Frameworks …

… to reuse classes, relationships among classes, or pre-programmed control.


Seeking Generalization: Bottom-up

1. Start with classes in class model2. Look for generalizations

Procedure

WinProblem

Problem

WinProcedure


Seeking Generalization: Top-down

1. Start with libraries (e.g., MFC)

2. Look for opportunities to use

ListIteratorList

ScheduledEvents

library


«application package»

RPG Video Game Layering

«framework package»

RPGCharacters

PlayerCharacter

EncounterCharacter

ForeignCharacter

EncounterCharacters

PlayerQualityWindow

«uses»

Framework layer

Application layer


FrameWork For Encounter Video Game

RPGCharacters RPGEnvironment RolePlayingGame

«uses»

«uses»

«uses»

Encounter video game layer

EncounterGame


Role-playing game layer (framework)

EncounterCharacters






RPGCharacters RolePlayingGame

RPGEnvironment

EncounterEnvironmentPlayerCharacter

EncounterCharacter


ForeignCharacter

EncounterCharacters «application package»

EncounterGame Engagement

EngagementDisplay

EncounterGame

Area

PlayerQualityWindow

EncounterAreaConnection

Framework layer

Application layer

Role-Playing Game, and Encounter Packages -- showing domain

classes

ConnectionHyperlink

«uses»


EncounterEnvironment Package

EncounterEnvironment «application package»

EncounterArea«facade»


EncounterAreaConnection

Hyperlink

ThumbnailMap 1


EncounterEnvironment Package

RPGEnvironment «framework package»

GameCharacterGameArea

EncounterEnvironment «application package»

«facade»


GameAreaConnection

EncounterAreaConnectionThumbnailMap

2

1

EncounterArea Hyperlink


Detailed Design of EncounterCharacters Package

«facade»

EncounterCast

PlayerCharacter

ForeignCharacter

RPGCharacters«framework package»

RPGCharacter

EncounterCharacters«application package»

EncounterCharacter


EncounterGameDisplays

Detailed Design of EncounterGameDisplays Sub-

package

EngagementDisplay

PreparinghandleEvent()

ReportinghandleEvent()

SetQualityDisplay

EncounterDisplayItem

QualListDispl

QualValueDispl

SetQualValueDispl

EncounterCast

EncounterDisplay

MouseListener


RolePlayingGame

EncounterGame

Detailed Design of EncounterGame Package

RPGamehandleEvent()

GameStatehandleEvent()

state

{ state.handleEvent(); }

Domain classKey:

RPGMouseEventListenernotifyOfEvent()


RolePlayingGame

EncounterGame

EngaginghandleEvent()

Detailed Design of EncounterGame Package

RPGamehandleEvent()


Engagement

Domain classKey:

WaitinghandleEvent()

PreparinghandleEvent()

EncounterGame<<singleton>>

RPGMouseEventListenernotifyOfEvent()

EncounterGameDisplays sub-package

ReportinghandleEvent()

CharacterMovement

SettingQualitieshandleEvent()


Detailed Design of RolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()state



Detailed Design of RolePlayingGame Package

RPGamehandleEvent()

GameStatehandleEvent()state


RPGMouseEventListenermouseEnter()

MouseListener

{ rPGame.handleEvent(); }

rPGame


RPG Framework for Role-Playing Video Games

CharactersRolePlayingGame

RPGamehandleEvent()


state


GameCharacter

Artifacts

GameArea

RPGEvent

GameAreaConnection

2GameLayout

0..n

GameEnvironment

For future releases


Design Goal At Work: Correctness

We want to avoid re-implementing common server-side processes.


What Are EJB’s? 1

Server-side component architecture

Part of Java Enterprise Edition Reusable, portable business components

o no system-type code

“Inherently transactional, distributed,

portable, multi-tier, scalable and secure”

(http://web2.java.sun.com/products/ejb/faq.html)

What Are EJB’s? 2

Customized at deployment time

Supports

o transactional behavior

o security features

o life-cycle features

o state management of client sessions

o persistence, etc.

Any protocol can be utilized:

o IIOP, JRMP, HTTP, DCOM, etc

Summary adapted from http://web2.java.sun.com/products/ejb/faq.html

Benefits of EJB’s

Portable across any EJB servers and

Operating Systems

“Declarative” rather than algorithmic

o Goal: customize, don’t create from scratch

Middleware-independento independent of structure used between client

and server


CONTAINER:• Registers self with JNDI* • Controls EJB …

… life cycle … transactions … security

EJB Architecture

EJB container

legacyapplication

clientcallback

1

2

4?

3?

* Java Naming and Directory Interface

EJBean

EJBean


Deployment Descriptor(expressed in XML) type:entityclass:CustomerBeanhome: CustomerHomeremote:Customer….

EJB Access

client

CustomerBeanmyMethod()…

JNDI

Entity Bean: business logic methods for the component

Java naming and directory

service

CustomerHomecreate()…

CustomermyMethod()…

Remote Interface

1 Home Interface: methods for creating a CustomerBean instance …

CustomerHomeImpl

CustomerImpl

4

2

37

5

6

8

EJB container

EJBHome

EJBObjectAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Context initialContext = new InitialContext( properties ); // (1.)

CustomerHome customerHome = // (2.)

javax.rmi.PortableRemoteObject.narrow // “casting”

( initialContext.lookup( “applications/bank/customer” ),

CustomerHome.class

);

Finding & Connecting to a Specific EJB

1. Embody location etc. of JNDI in a Properties object.

2. Look up the class implementing the bean’s home interface by name using JNDI.

Use methods of the home interface to acquire access to an instance of the class implementing the remote interface.

Properties of JNDI

Know: path to the containerand name of the home class


Instantiating and Using an EJB

Context initialContext = new InitialContext( properties );

CustomerHome customerHome =

javax.rmi.PortableRemoteObject.narrow ( initialContext.lookup

( “applications/bank/customer” ), CustomerHome.class );

// Create bean instance and return proxy for it (3.)

Customer johnDoe = customerHome.create( “John Doe” ); johnDoe.deposit( 2395 ); // use the bean instance

. . . .


The Parts of the EJB Architecture (partial)

Entity Beans

EntityBeanejbLoad()ejbStore()

Session Beans

SessionBeanejbActivate()ejbPassivate()ejbRemove()

setSessionContext()

EJB Container

Server

EJBObjectejbCreate()ejbRemove()


EntityBean

• specific data such as record in a relational database • persistent

SessionBean(stateful or stateless)

• perform sequence of tasks within the context of a transaction• logical extension of client program • running processes on client's behalf remotely on server

MessageBean

(not covered in this book)

- or -

- or -

Types of EJ Beans 1


The Types of EJBs 2

EJB container

«Session Bean»client

«Entity Bean»

«Entity Bean»


Key Concept: Enterprise Java Beans

-- server-side Bean framework handling multiple client sessions, database access, persistence, etc. through control protocols.


Relating Use Cases, Architecture, & Detailed Design

1. Use case (part of requirements)

“Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.”

3. Architecure2. Domainclasses

Auto

Road

Auto

Road

4. DetailedDesign

Cable

Cable

Pylon

Pylon

(not specifically required)

added for detailed design

GuardrailRoadbed

*

**

* Use cases used toobtain domain classes. ** Use cases used to verify and test design.


Completing Detailed Design

Design the control of the application,

Design for database access

Design interaction with outside world.

Audit relationships among classeso eliminate unnecessary connections,

o adding requried detail classes

o clarify all classes

Ensure all required methods implemented


Architecture Options for Application Control

Internally driven Externally driven

o == “event-driven”

o Does nothing until an even occurs

o e.g., mouse actions

o Each event causes a method to execute

event

Application

class

event

eventAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

1. create

2. create; display

4. create3. enter characteristics

Internal Control

ProblemMenu

WinProcedureDisplay WinProcedure

WinHelp

WinProblem

Display

5. create; displayAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Internal WinHelp Control

main()

:WinHelp :WinProblem

1. create

:ProblemMenu

2. create; display

3.1 enter characteristics

3.1 set values

:WinProcedure

4. create

:WinProcedureDisplay

5. create; display

User

3.2 match


External Control

ProblemMenu

WinHelp

WinProblem

Display 2. mouse event 3. create

1. create


Sequence Diagram for External WinHelp Control

main()

:WinHelp :ProblemMenu

1. create; display

2. enter characteristics

User

3. create

3.1 set values Etc.

:WinProblem


Example For Local Control

Design a retirement information system to handle typical transactions … o e.g., open, withdraw, deposit

… on several types of accountso e.g., passbook, savings, money-market funds


Solutions (after Jacobson)

Now modify: Add CD account Add reporting

Dep Bond FundDep Mutual Fund Dep Fixed Interest

WithdrawDepositOpen

Transact

MutualFund BondFundFixedInterest

Functional Solution

OO Solution

Account

Functional module

dependencies.

Class model.


New Account Type: Impact on Functional Decomposition

Dep Bond Fund

Withd. CDOpen CD Dep CD

(impacted byadditional

requirement)

Dep Mutual Fund Dep Fixed Interest

WithdrawDepositOpen

key:

Transact

Functional module dependencies.


New Account Type: Impact on OO Decomposition

CD MutualFund BondFundFixedInterest

Account (impacted byadditional

requirement)

key:


Report Bond FundReport Fixed InterestReport MMF

Deposit

Reporting FunctionImpact on Functional Decomposition

Report

Transact

WithdrawOpen

(impacted byadditional

requirement)

key:


Account

report( )

Reporting Function: Impact on OO Approach

object references

MutualFund BondFundFixedInterest

report( ) report( ) report( )

special to this application

Client


ClienttheAccReport.report ( theAccount )

Stay with OO: Use Control Classes

Account

BondFundFixedInterestMutualFundIF Account type is ...

THEN ...

AccountReportreport()

Entity class

Control class


Key Concept: Control Applications …

… Globally: Event-driven (externally) or internally.

… Locally: May collect control in its own class.


Styles of Object-Oriented Design for Application Interface

Internally-driven Interface Design o Class by class process

Externally-driven Interface Design o by use case -- or --o by screen -- or --o by user


WinHelp Internally-Driven Interface Design

WinHelp

WinProblem

ExampleWinProblem

Needs external data

Supplies external data

visible invisible

1

23

45 ExampleMenu

ProblemMenu

«creates»

«creates»


GUI Fragment for Setting WinProblem


Java Graphic-based UI for WinProblem

WinProblem

Button

Label

Frame

BorderLayoutDialog

ApplicationDialog

DesktopDialog

WinProblemDialog

etc.

WinHelpgetProblem()

suggestSolutions()

callbackscallbacksAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Externally-Driven Design For Interfacing

manager

comptroller

foreman

class

model

managerIF

foremanIF

comptrollerIF

Graphics courtesy of Corel.Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

A Vending Machine Interface

Select

$0.55

Return

75c

CoolCola

(Add cash)

A GUI group

A GUI group


1..n 1..2

InfoSelectContainer

AddCashReturnContainer

TextComponent

ContainersetLayout()

show()

Vending Machine Interface Object

Model

Command

Button


Domain classes

rroobboottss

ssyysstteemm

operatorsoperatorsNon-Human Users

Robot interface System interface

Operator interface


UI Example: Supermarket Counter

$32

spend

put back

Counter amountSpentincrement()decrement()

. . . . .

Physical interface Domain class

Menu items

prompt execUserSelection()

TextComponentdisplayValue()

CounterText

CounterMenu execUserSelection()

CounteramountSpentincrement()decrement()

UI Domain

UI Example: Supermarket Aid ctd.

create

create

Key Concept: Design For Interfaces …

… Per use case (externally) – or –

… Per class (internally).


Data Access Issues

1. Ensure class model supports collection

2. Choose centralized or distributed storage architecture

3. Store data in relational or object-oriented database


Ensure Object Model Allows Data Capture

Mediator for data captureTransaction

Account

Customer Teller


Trial Data Access Example : Gymnastics

4

1

Team

Contestname *

Eventapparatus * gender * junior/senior * Gymnast

Judgescore *

1

1

* Keep raw data with originator

1..n

Club


Data AccessExample :

Gymnastics

4

1

Seasonyear

Club

Team

Contestname

Eventapparatusgenderjunior/senior

Gymnast Performancerecord()

Meet

League

Judgescore

1..n1

*

*

1

1

databaseAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Data Management Architectures

Distributed : objects store themselves

Central : use specialized storage classes

o to create instances

o to destroy instances

o to make efficient use of space

o e.g. garbage collection


Distributed Data Storage

Transaction float timeCustomer* custCheckAccount* chAccSavingsAccount* svgAcc

store()

cassie: Customer“3 Main”: addr

edward: Teller54321: empNum

Objects store themselves

cAcc16: CheckAccount100: lastWithdrawal

sAcc12: SavingsAccount3003: balance

trans129:Transaction

time: 0932


Objects send their contents to a storage utility class or module

attribute values

Centralized Data Storage

Storagestore(...)

transaction123: Transactiontime: 0932

Object…:Class…

Object…:Class…

Data Storage Package


Using Relational Databases with OO

Transaction

time

customer

account

DBMSDBMSDBMSDBMS

Objects re-assembled in memory by application and database.

Data, not objects stored.

tables


OO Databases

OODBMSOODBMSOODBMSOODBMS

Objects delivered to memory for re-use.

Objects, not data, stored.

objects

Transaction

time

customer

account


Customer: cassie

addr: 3 Main

Check Account: cAcc16

lastWithdr: $100

Savings Account: sAcc12

lastWithdr: $300

Teller: edward

empNum: 543210

Transaction: trans129

time: 0932

Customer: cassie

addr: 3 Main

Check Account: cAcc16

lastWithdr: $100

Savings Account: sAcc12

lastWithdr: $300

Teller: edward

empNum: 543210

Transaction: trans129

time: 0932

OO Databases: Relationships Maintained


Relational DBMS vs. OO DBMS

RDBMS based on a data model

o tables of rows & columns

ODBMS based on a programming technology

(the OO method)

o data model defined by the program


Completing the Design

Replace ambiguous associations,

Expose all dependencies

Split selected classes for improved design.



We reduce dependencies among classes to promote their reuse in other applications.


Examining Associations: Many-To-Many ...

... may uncover a required class: an "event-

remembered" or mediator (Registration in this

case).

1..n 1.. n

11 1..n

e.g. wedding gift registration system:

Store Couple

Store Couple1..n

Registration


Examining Associations: Class-to-Itself ...

Business

Business JointVenture

... may uncover a required class: frequently an "event-remembered"

Business Merger

2...n

2...n


Examining Aggregations for Short Circuits

Item1..n

Shelf1..n

------ But not every item is on a shelf -----

0..nAdd:

Supermarket

Item1..n

Shelf1..n

Supermarket

looseItem


Consider Splitting Classes

Envision system growth Leverage inheritance

properly

WinProcedureHelp

Help

WinProcedure


Completing Operations

Class

Operations

1. Required by…

1.1 Use-case model (sequence diagrams)

1.2 State Model (event handlers; functionality on entering states)

2. Design the algorithm for each operation (activity diagrams? pseudocode?)

1.4 Design Patterns (chapters xx-xx)

1.3 Component model (see section xx)


WinHelp

getProblem()

match()WinProblem

getCategory()

getVisible()

savePrimaryParameters()

showCategoryOptions()

WinProcedure

describe()

getCategory()

showCategoryOptions()

demoExample()

WinProcedureExample

demoExample()

CompletingWinHelp Operations

u

c

u

u

u

s

Partial Component

Model

c

ckey: from...u: use case s: from state model c: from component model

categoryString


Summary

1. Determine the architecture (modularization)o Consider standard ones

2. Use and contribute to framework3. Apply design patterns 4. Design for data capture 5. Design control 6. Design interfaces7. Exploit abstraction 8. Reduce many-to-many associations9. Finalize design of associations10. Obtain all functions from use case-, state-,

and component models11. Design individual functions


chapter 14 architectures and frameworks. process phases discussed in this chapter requirements...

Documents

deposit account

account data account

software design

display account account

data store slide

account summary

engagement classes state

goals of software architecture