System Models, Patterns and Software Architectures 14 February

System Models, Patterns and Software Architectures

14 February

USER INTERFACES JUST YESTERDAY…

What Would You Enter?

Please enter the serial number from the box

7FD-XXX-XXX-XXX-XXX

On the box is 7FD-123-234-345-456

SYSTEM MODELS

Modeling Based on abstraction

Looking only at relevant information Hiding details

Create multiple views As orthogonal as possible

Each view has information that is unique Each view has information that appears in

other views Common information is consistent

How many views?

Modeling an airplane

Exercise: Modeling a House

What views would you model? Do they meet the criteria?

Example of a System Model

Three views Functional: what is done Data: entity relationships Dynamic: state transitions

Why these three? Duplicative? Missing?

Models and Diagrams

Modeling Languages and Processes

Language: syntax, usually graphical, used to express design

Process: steps to take to create a design Many processes, not a lot of agreement General consensus has built around

UML as a language We’ll look at UML later in the semester

Unified Process built around UML

Functional Models:Software Architecture

Patterns

Do you know the source and history?

Briefly look at the context

What is a Pattern?

A solution to a problem in a context A structured way of representing

design information in prose and diagrams

A way of communicating design information from an expert to a novice

Requirement: shows when and how to apply

Origin of Patterns Came from architecture

Christopher Alexander, late 70s The Timeless Way of Building

Describes Common architectural motifs How they come together to form a cohesive,

livable environment Patterns from town planning to decorative

detail

Architectural Example: Door Placement

If room has two doors and people move through it, keep both doors at one end of the room

Alexander’s PatternsEntries have five parts: Name: A short familiar, descriptive name or phrase,

usually more indicative of the solution than of the problem or context.

Example: One or more pictures, diagrams, and/or descriptions that illustrate prototypical application.

Context: Delineation of situations under which the pattern applies.

Problem: A description of the relevant forces and constraints, and how they interact.

Solution: Static relationships and dynamic rules describing how to construct artifacts in accord with the pattern, often listing several variants.

What do you need to change for software?

Properties of Patterns Independent, specific, and formulated precisely enough

to make clear when they apply (encapsulation) Describes how to build a realization (generativity) Identifies a solution space containing an invariant that

minimizes conflict among constraints (equilibrium) Represent abstractions of empirical experience and

everyday knowledge (abstraction) May be extended down to arbitrarily fine levels of detail.

Like fractals, patterns have no top or bottom (openness) Hierarchically related. Coarse grained patterns are

layered on top of, relate, and constrain fine grained ones (composibility)

What do you need to change for software?

Design Patterns All the same benefits are true in software

Cunningham and Beck recognized in late 80s Community formed in early 90s

The Book: Gamma, Helm, Johnson and Vlissides, Design

Patterns: Elements of Reusable Object-Oriented Software

Define 23 patterns Three categories:

Structural – ways to represent ensembles of information

Creational – creating complex objects Behavioral – capturing the behavior of object

Patterns at All Levels:Look at them at the Highest

Level

Progression

Machine code Assemblers High Level Languages Abstract Data Types (queues, stacks) Objects Patterns Software Architectures

Software Architecture

What is an architecture? External view What does that mean for software? The highest level design Often treated as top level of

system design not consistent

Software Architecture Goals

Extensibility: adding new features Tradeoff of generality and time How might it be extended?

Changeability: requirements changes

Simplicity: ease of understanding and implementing

Efficiency: speed and size

Key Characteristics

Cohesion degree to which communication takes

place within the module Coupling

degree to which communication takes place between modules

Min-max problem: minimize coupling while maximizing cohesion

Examples Role-playing game

Decompose into 4 modules: environment, game control, participants and artifacts

High cohesion and coupling When two characters meet, all 4 modules are involved

Personal finance application Decompose into user activities: accounts, bill

playing, loans, investments Low cohesion and high coupling

Accounts are pretty independent Loan payment would involve the first 3 modules

Categorizing Software Architectures(Shaw and Garlan) Model-View Controller Data flows

Viewed as data flowing among processes Independent components

Components operating in parallel and communicating occasionally

Virtual machines Treats an application as a program written in a special-

purpose language Repository

Application built around data Layered architectures

Packages of function with a strong hierarchical uses relationship

Why Categorize?

Recognize patterns Reuse designs Learn from other similar

applications Reuse classes Simplify communication

Examples of Use (real quotes) … is based on the client-server model and uses

remote procedure calls ... Abstraction layering and system decomposition

provide the appearance of system uniformity to clients …

The architecture encourages a client server model …

We have chosen a distributed, object-oriented approach

The easiest way … is to pipeline the execution …

SOME WELL-KNOWN ARCHITECTURES

Model-View-Controller

Originally designed for SmallTalk Early OO language

(1970’s) Steve Burbeck,

1987 First paper

Data Flow Design

Data flowing among processes Two categories:

Pipes and filters Filters: processes Pipes: input streams

Batch sequential Pipe and filter where input streams are

batches of data

Pipe and Filter

filterfilter

filter

filter filter

filter

pipe

pipe

Filters: processesPipes: input streams

Example of Batch Sequential

Collectmortgage funds

Accountbalances

Mortgagepool

Unsecuredpool

Collectunsecured funds

Pipe: batch input

Processes

Pipe and filter where input streams are batches of data

Independent Components Components operating in parallel and communicating

occasionally Three types

Client-server Browser-web server most familiar example Separate systems with narrow interface Sometimes expanded to three tiers (why?) Façade pattern (single unified interface)

Parallel communicating processes Several processes executing at the same time Typically modeled with sequence diagrams Observer pattern (one-to-many dependencies)

Event systems Set of components waiting for input Example: word processor waiting for user input State transition diagrams State pattern (alter behavior depending on state)

Client-Server and Facade

«not exposed»

P

«not exposed»

Façade«exposed»

Client1

2

«not exposed» «not exposed»

«not exposed»

«not exposed»

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Key concept: limit exposed interface

Browser-web server most familiar example:Separate systems with narrow interface

Parallel Communicating Processes


Customer:customer n

withdraw

Customer:customer n+1

Session:session k

Session:session m

deposit

create

Account:customer n+1 saving

Account:customer nchecking

create retrieve

retrieve

3 types of processes, 2 instances of each

Duration of process

processes

actions

sequence diagram

Observer Design Pattern

Gamma et al

Sourcenotify()

Observerupdate()

ConcreteSubjectstate

ConcreteObserverobserverState

update()

Client of thissystem

1

2

3

1..nRequest others be notified

Notify all observers

Determines if change needed

Single source of data with a Single source of data with a number of clients that need to number of clients that need to be updatedbe updated

Event Systems and State Transition Diagrams

Set of components waiting for input

Virtual machines

Treats an application as a program written in a special language

Payoff is that the interpreter code is the basis for multiple applications

Two types Interpreters Rule-based systems

Repository

A system built around data Two types

Databases Hypertext systems

A Typical Repository System

Database

DBMS

GUI

Analysisprocess

1

Analysisprocess

n…...…...

Control


Iterator pattern

void setToFirst(); points to first element

void increment(); causes the iterator to

point to its next element

C getcurrentElement(); return the

element pointed to by the iterator

boolean isDone(); true if all elements

processed

Hypertext: Basis of the Web

Motivated by Vannevar Bush in 1945 “As We May Think” (Atlantic Monthly) Theoretical machine, "memex," to

enhance human memory by allowing the user to store and retrieve documents linked by associations

Invented by Ted Nelson in the 1960s Popularized with HTML (Tim Berners-

Lee)

Ted Nelson "If computers are the wave of the

future, displays are the surfboards." Xanadu: 1974

"give you a screen in your home from which you can see into the world's hypertext libraries... offer high-performance computer graphics and text services at a price anyone can afford... allow you to send and receive written messages... [and] make you a part of a new electronic literature and art, where you can get all your questions answered...“

Computer Lib/Dream Machines

Layered Architecture

Role-playing game layer

Characters LayoutRolePlayingGame

EncounterCharacters

EncounterEnvironment

Encounter Game

Application layer

3D engine layer

«uses»

«uses»


Coherent collection of software artifacts, typically a package of classes

Recap Model-View-Controller Data flow systems

Pipes and filters Batch sequential

Independent components Client-server Parallel communicating processes Event systems

Virtual machines Interpreters Rule-based systems

Repositories Databases Hypertext systems

Layered architectures

Documents

System Models, Patterns and Software Architectures 14 February