ArchitectureArchitecturef Buildings CMPUT 401ÑModule 04ugweb.cs.ualberta.ca/~c401/W07/lectures/04-4up.pdfOO, Process, and UML!Object-oriented analysis!requirements specification activity!create

Architecture

CMPUT 401—Module 04

Department of Computing Science

University of Alberta

Ken Wong, 2007

2

OO, Process, and UML

! Object-oriented analysis

! requirements specification activity

! create UML use cases and class diagrams

! Object-oriented design

! architectural design activity

! refine UML class diagrams

! create UML package and deployment diagrams

! possibly UML sequence, state, and activity diagrams

! detailed design

! …

3

Architecture

! Definition:

! What is software architecture?

! What about the architecture of buildings?

4

Architecture of Buildings

! Ideas:

! overall shape of the physical structure

! how the building fits into its environment

! how the building meets its purpose

! how spaces of the building are integrated

! external facade and living environment

! fixtures, flooring, decorations

! aesthetic and visual impact … art

5

Software Architecture

! One definition:

! the organization of the whole system,including static and dynamic elements,connectors and protocols, overallarchitectural style, and quality constraints

6

Design Levels

! Three design levels:

! architecture (“the big picture”)

! describes components and (inter)connections

! provides rationale for include and excludingpossible design alternatives

! code design

! involves algorithms and data structures

! executable design

! concerns memory allocation, data layout, bitpatterns, etc.

! — Shaw & Garlan (1996)

7

Architecture

idioms(design) patterns

codeboxes and arrows

inside module boundaryoutside module boundary

algorithmic performancesystem-level performance

mostly dynamicmostly static

computational propertiesstructural properties

implementations of partsinteractions among parts

ProgrammingArchitecture

8

Architecture

! Issues:

! list of design goals

! define subsystems and responsibilities

! map subsystems to platform

! manage persistent data

! define access control policies

! define global control flow(event driven? threaded?)

! describe boundary conditions(startup, shutdown,exception handling)

9

Design Goals

Reliability

Low cost Increased ProductivityBackward-CompatibilityTraceability of requirementsRapid developmentFlexibility

Client

End User

(Customer,

PortabilityGood Documentation

RuntimeEfficiency

Sponsor)

Developer/

Maintainer

Minimum # of errorsModifiability, ReadabilityReusability, AdaptabilityWell-defined interfaces

FunctionalityUser-friendlinessEase of UseEase of learningFault tolerantRobustness

10

Design Goals

! Typical tradeoffs:

! functionality versus usability

! cost versus robustness

! efficiency versus portability

! rapid development versus functionality

! cost versus reusability

! backward compatibility versus readability

11

Subsystems

! What:

! manageable piece of the system to assignto a team

! provides a service to other subsystems (arelated set of operations with a commonpurpose)

! provides an interface or API(a set of fully typed related operations)

! modeled using a UML package

! e.g., Notification subsystem12

Subsystems

! Properties (to reduce complexity):

! coupling

! strength of dependencies between subsystems

! want low coupling, narrow interfaces

! cohesion

! strength of dependencies within a subsystem

! want high cohesion

13

UML Package Diagram

14

subtasks

*

assesses

solvableBy

resolvedBy

based-on

* * *

implementedBy

RationaleSubsystem

PlanningSubsystem

Criterion Alternative

Decision

DesignProblem

SubTask

ActionItem Task

15

Facade

Compiler

compile(s)

create()

getToken()

CodeGenerator

create()

generateParseTree()create()

Compiler

Optimizer

Lexer

Parser

ParseNode

16

Architectural Style

! Idea:

! defines a family of architectures in terms ofa pattern of structural organization

17

Architectural Style

! Consists of:

! vocabulary

! types of components and connectors

! constraints

! how components and connectors are combined

! semantics

! specify how to determine the system’s overallproperties from the properties of its parts

18

Architectural Style

! Questions about a style:

! What intuition does it capture?

! What are allowable structures?

! What is the computational model?

! What are the tradeoffs in using the style?

! What are some common examples?

! What are some common specializations?

19

Architectural Style

! An architecture consists of:

! components that define the places forcomputation

! e.g., filters, databases, objects

! connections that define the interactionsbetween components

! e.g., procedure call, data stream, eventnotification

20

Dataflow Architectural Style

! Pipes and filters pattern:

21

Pipes and Filters Pattern

! System model:

! a graph

! nodes are stream-to-streamtransformations

! edges are paths of data transmission

22


! Computational model:

! filters transforming data at inputs to data atoutputs

! pipes transmitting data from a filter outputto a filter input

! running of pipes and filters until no morecomputations are possible

23


! Filters:

! functions from streams to streams

! preserve no state from one instantiation tothe next

! use little local context in processingstreams

! are independent (unawareof other filters)

24


! Stream representation:

! simple and general

! lowest common denominator

! e.g., ASCII sequence

25


! Discussion:

! What are some examples?

26


! System construction:

! by joining filters with pipes

! e.g., Unix shell pipes and filters

! find, grep, xargs, less; command language support

! e.g., compilation stages

! lex, syn, sem, opt, codegen

! e.g., spreadsheets

! cell formulas are filters, dependent on data in othercells

27


! Discussion:

! What are the pros and cons of this pattern?

28


! Pros:

! ease of extension and evolution(just compose new filters)

! ease of reusing or replacing filters

! “component-based” approach

! parallel processing

29


! Cons:

! difficult to handle interactive applications

! forces lowest common denominator onstream format

! parsing and unparsing overhead on stream

! redundancy of preparatory functions infilters

30

Call-and-ReturnArchitectural Style

! Patterns:

! main program/subroutines

! object-oriented systems

! layered hierarchies

31

Object-Oriented SystemsPattern

! System model:

! has objects, each of which

! hides a secret

! manages local state

! preserves the consistency of a representation orresource

! provides an interface to its functionality

32



! objects interact with other objects bymethod invocation or message passing

! objects resemble handlers waiting for anincoming event (call or message)

33


! System construction:

! identify and define classes to describe theinterfaces and behaviors of objects

! relate classes to other classes via

! association

! aggregation

! composition

! inheritance

34


! Discussion:

! What are the pros and cons of this pattern?

35


! Pros (if done right):

! abstraction

! focus on outside, observable view of class/objectseparate from inside implementation view

! modularity

! decompose system into modules, which contain aclass or classes

! reduce the propagation of changes

36


! Pros:

! encapsulation

! restrict access and/or visibility to internalrepresentations

! hierarchy

! combine parts into wholes through compositionand aggregation

! share and reuse behavior through inheritance

37


! Cons:

! objects know about other others(class naming issues, name spaces)

! deep hierarchies

! complex dynamic relationships

38

Layered Hierarchies Pattern

! System model:

! has “layers”, each of which:

! hides part of the lower layer

! provides a well-defined interface

! offers a set of services to the layer(s) above —a virtual machine

! is a client to the layer(s) below

39


! Discussion:

! What are some examples?

40


! Windows 2000:

! layers, run in kernel mode …

! hardware abstraction layer

! device drivers

! kernel

! executive

! layers, run in user mode …

! system support processes

! server processes

! environment subsystems

! user applications

41

Application

Presentation

Session

Transport

Network

DataLink

Physical

Frame

Packet

Bit

Connection

Format

Message

Level of abstr

action

42


! OSI model:

! physical layer

! hardware, cabling

! datalink layer

! transmit data frames without error

! network layer

! transmit and route packets within network

! transport layer

! transmit data reliably end to end

! …

43


! OSI model:

! session layer (middleware)

! initialize and authenticate connection

! presentation layer (middleware)

! data transformations(byte reordering, encryption)

! application layer

44

Application

Presentation

Session

Transport

Network

DataLink

Physical

Socket

CORBA

TCP/IP

Object

Ethernet Wire

45

Xlib

Xt

Motif

Application

46


! Discussion:

! What are some pros and cons?

47


! Pros:

! abstraction

! separation ofmechanisms andpolicies

! Cons:

! performance issuesfrom extracoordination betweenlayers

! conformity typically isnot enforcedautomatically

48

Virtual MachinesArchitectural Style

! Patterns:

! interpreters

! rule-based systems

! services

49

Independent ComponentsArchitectural Style

! Patterns:

! communicating processes

! event systems

50

Event Systems Pattern

! From …

51


! To …

52


53


! System model:

! components that are objects

! connections that are event notification andmethod invocation

54



! objects communicate by triggering events

! e.g., changed event

! objects register for events of interest andassociate methods to these events

! e.g., changed event, update method

! when an event occurs, the correspondingmethods are invoked(which may trigger other events)

55


! Discussion:

! What are some pros and cons?

56


! Pros:

! objects are more independent than withexplicit invocation

! ease of adding and removing objectswithout interfering with existing objects

! ease of adding and registering for newevents

! separates interaction policies from theinteracting objects (like priorities)

57


! Cons:

! needs central management to track eventsand registrations

! overhead from indirection

! ordering of event handling may beimportant

58


! Example message servers:

! Sun ToolTalk

! HP SoftBench Broadcast Message Server

! tool protocols via classes of commands

! encapsulator for existing tools

! messages contain information about theoriginator, command class, command name,context, arguments

59


! Example systems:

! integrated development environments

! PECAN, FIELD

! software bus

! syntax-level views, symbol table view, classhierarchy, execution view of stack, etc.

! incremental compilation, no need for centralrepresentation

! — Reiss (1985, 1995)

60

Repository Architectural Style

! Patterns:

! databases

! hypertext systems

! blackboards

! System model:

! central data structure +components operating on data structure

Subsystem

Repository

createData()setData()getData()searchData()

61

Repository Architectural Style

! Example:

! modern compilers

62

LexicalAnalyzer

SyntacticAnalyzerSemanticAnalyzer

CodeGenerator

Compiler

SyntacticEditor

ParseTree SymbolTable

Repository

SourceLevelDebugger

Optimizer

63

Event System + Repository

! Components:

! tools

! data/message server

! global schema

! object store

! Integration:

! data

! control

64

Architectural Style

! Issues:

! hybrid and heterogeneous systems

! combinations of styles

! problem and architecture

! choice of style commits designer to a particularabstraction of the problem (focus on certaindetails while suppressing others)

! devise “reference” architectures for a domain

65

Reference Architecture

! Integratedenvironments

66

Architectural Style

! Methodologies:

! each style may be supported by anassociated design process (e.g., OO)

! discover the components and connectorsfor the style

! identify critical design decisions

! decide if the architecture is appropriate andhas the right qualities(e.g., reliability, performance, security,maintainability)

67

Documenting Architecture

! 4+1 views:! scenario

! use cases, ties together the other views

! logical! services, functional requirements

! development! package structure

! physical! mapping of software onto hardware

! process! concurrency, distribution, synchronization

! — Kruchten (1995) 68

Services

! UML constraints:

! Object Constraint Language (OCL)

! specify constraints on single or groups ofmodel elements(e.g., attributes, operations, classes)

! depicted as notes and stereotypes attachedto the constrained elements

69

Services

<<invariant>>self.numElements >= 0

HashTable

put(key,entry:Object)get(key):Objectremove(key:Object)containsKey(key:Object):booleansize():int

numElements:int

<<postcondition>>!containsKey(key)

<<postcondition>>get(key) == entry

<<precondition>>containsKey(key)

<<precondition>>!containsKey(key)

<<precondition>>containsKey(key)

70

Services

! Textual OCL:

! precondition

! context Hashtable::put( key, entry ) pre:!containsKey( key )

! postcondition

! context Hashtable::put( key, entry) post:containsKey( key ) and get(key) = entry

! invariant

! context Hashtable inv:numElements >= 0

71

Physical Mapping

! Questions:

! what hardware configuration?

! which node is responsible for whichfunctionality?

! how is communication between nodesrealized?

! what services are realized with existingsoftware components?

! how are these components encapsulated?

72

Physical Mapping

! UML deployment diagrams:

! depict the relationship among softwarecomponents (subsystems) and hardwarenodes

! nodes are represented by boxes, whichcontain components

! edges show run-time dependencies

73

Deployment Diagram

:WebServer

myMac:Mac:UnixHost

:IExplorer

aPC:PC

:Database

:UnixHost

:Netscape

74

Deployment Diagram

RoutingSubsystem PlanningSubsystem

:OnBoardComputer :WebServer

75

Component Diagram

GET

POST

HttpRequest

URL

File

WebServer

DBQuery

DBResult

76

Checklist

! Selected questions:

! is the glossary of entity objectsunderstandable by the user?

! do abstract classes correspond to user-levelconcepts?

! do all entity and boundary objects havemeaningful noun phrases as names?

! do all use cases and control objects havemeaningful verb phrases as names?

! are the startup, shutdown, and adminfunctions of the system described?

77

Checklist

! Completeness:

! for each object

! needed in a use case?

! where created, modified, destroyed?

! for each attribute

! where is it set?

! what is its type?

78

Checklist

! Completeness:

! for each association

! where is it used?

! what multiplicities?

! for each control object

! does it have the necessary associations to do itsjob?

79

Checklist

! Consistency:

! are there things with the same name?

! do things with similar names denote similarphenomena?

! are all things described to the same level ofdetail?

! are there objects with similar attributes andassociations that are not in the samegeneralization hierarchy?

80

Checklist

! Realistic?

! are there any novel features? were anyprototypes or studies done to ensurefeasibility?

! can performance and reliabilityrequirements be met? were theserequirements verified by any prototypes(on the selected hardware)

81

Architecture

! Persistence:

! map data objects defined during analysisinto data structures

! refined attributes and operations on classes

! represent data flow, sources, and sinks

! identify sensors, controls, actuators, and outputs

! create data flow diagram

! design of the database schema82

Architecture

! Other concerns:

! concurrency

! how parallel tasks are managed

! e.g., process management, task scheduler,coordination, semaphores, etc.

! distribution

! how components communicate in a distributedenvironment

! e.g., client/server, brokers, etc.

83

References

! Object-OrientedSoftware Engineering

! B. Bruegge & A. Dutoit

! Prentice-Hall, 2000

! [b5, b6]

ArchitectureArchitecturef Buildings CMPUT 401ÑModule 04ugweb.cs.ualberta.ca/~c401/W07/lectures/04-4up.pdfOO, Process, and UML!Object-oriented analysis!requirements specification activity!create

Documents