Zusammenfassung Software Architecture

Aus VISki
Wechseln zu: Navigation, Suche

Hauptziele von Software Architecture

Itʼs all about finding the right data abstractions

  • Reliability
  • Extendibility
  • Reusability
  • Maintainability

The O-O designerʼs motto

Ask not first WHAT the system does: Ask WHAT it does it to!


Modularität beinhaltet und begünstigt folgende Eigenschaften/Prinzipien:

  • Decomposability (Slide 2.5)
    • "The method helps decompose complex problems into subproblems"
    • COROLLARY: Division of labor.
    • Example: Top-down design method.
    • Counter-example: General initialization module.
  • Composability (Slide 2.8)
    • "The method favors the production of software elements that may be freely combined with each other to produce new software"
    • Example: Unix shell conventions - Program1 | Program2 | Program3
  • Continuity
    • "The method ensures that small changes in secifications yield small changes in architecture"
    • Beispiel: Principle of Uniform Access
    • Gegenbeispiel: Programme, deren Struktur aus der physikalischen Implementation der Datenstrukturen folgt.

Folgende Prinzipien haben erfahrungsgemäss einen positiven Einfluss auf die Modularität:

  • Few interfaces principle
    • "Every module communicates with as few others as possible"
  • Small interfaces principle
    • "If two modules communicate, they exchange as little information as possible"
  • Explicit interfaces principle
    • "Whenever two modules communicate, this is clear from the text of one or both of them"
  • Uniform access principle
    • "It doesn‘t matter to the client whether you look up or compute"
    • Facilities managed by a module are accessible to its clients in the same way whether implemented by computation or by storage.
  • Information hiding principle
    • "The designer of every module must select a subset of the module’s properties as the official information about the module, to be made available to authors of client modules"
    • Main justifications are Continuity and Decomposability
  • Open-closed principle
    • "Modules should be open and closed"
    • Open module: May be extended. The developer wants a module to be open (extendable) because one frequently overlooks aspects of the problem.
    • Closed module: Usable by clients. May be approved, baselined and (if program unit) compiled. The manager wants a module to be closed because the client needs it now.
  • Single choice principle
    • "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list."
    • Example 1 - Editor: set of commands (insert, delete etc.)
    • Example 2 - Graphics system: set of figure types (rectangle, circle etc.)
    • Example 3 - Compiler: set of language constructs (instruction, loop, expression etc.)
  • Single product principle (siehe DbC-Slides)
    • "The only product is the software which should document itself, not needing a documentation."

Hierarchy of Reuse



A formal way of describing data structures benefits:

  • Modular, precise description of a wide range of problems
  • Enables proofs
  • Basis for object technology
  • Basis for object-oriented requirements

Components of an ADT

  • Type Declarations (All types that are used as arguments)
  • Function Declarations (Total and Partial Functions)
    • Creators
    • Queries
    • Commands
  • Preconditions
  • Axioms


Definition: Creator

A creator of an ADT of type T has result type T and the arguments do NOT use type T


  • new: T
  • new_with_value: V -> T (where V isn't equal to T)

Definition: Command

A command of an ADT of type T has result type T and the arguments use type T


  • put: T x INTEGER x STRING -> T
  • remove: T x INTEGER -> T

Definition: Query

A query of an ADT of type T has result type NOT EQUAL to T and the arguments use type T


  • item: T x INTEGER -> STRING
  • has_key: T X INTEGER -> BOOLEAN

Definition: Correctness

A well-formed expression e involving one or more functions on a certain ADT is correct iff

  • the values of the subexpressions satisfy the preconditions of e, if any
  • all subexpressions of e are recursively correct


  • Correct
    • item(put(new_stack,3)) = 2 (Although 3 is not equal to 2!)
  • Incorrect
    • item(new_stack) for the given precondition item(s: STACK[G] require not empty(s)

Definition: Consistency (soundness)

An ADT ist consistent (sound), if it is not possible to derive a contradiction: (A = B) and (A ≠ B)

Definition: Sufficently complete

An ADT is sufficently complete iff every correct term where the outermost function is a query of the ADT can be reduced, using the axioms of the ADT, into a term not using any function of the ADT

Proving Sufficient Completeness:

  • Prove that you can reduce for all Queries and all Creators .
  • Assume that t is an ADT where you can reduce all Queries to t. Prove that you can reduce all Queries to , where is any Command.
  • This has to be proven by structural induction: See prove sufficent completeness


This proving section could get improved!
Alle momentan zu editierenden Einträge werden hier gesammelt.

Prove sufficent completeness

Zeige, dass jede Expression wo die äusserste Prozedur eine Query ist entweder

  1. Induction base (n = 0): auf eine Expression reduziert werden kann, welche keine Funktion des ADT enthält
    • Bsp: item(write(array, value, index1), index1) = value
  2. Induction step ( n → n+1 ): auf eine Expression reduziert werden kann, welche kürzer ist
    • Bsp: item(write(array, value, index1), index2) = item(array, index2)

Prove the ADT

Structural Induction

  1. Induction base (n = 0)
    • We prove the property over all terms produced by creators
  2. Induction step ( n → n+1 )
    • We prove the property over all terms produced by commands, assuming the property holds for the subterms


Stack, Bank_Account oder Table Example einfügen
Alle momentan zu editierenden Einträge werden hier gesammelt.

Design Patterns


Pattern-description taken from "Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software"

Behavioral patterns

Behavioral patterns answer the question: How to do something? e.g. How do we traverse a Data Structure? How do we publish changes? How do we communicate with an other object? ...

Hint: You may remember the behavioral patterns easier by remembering the first letters of them: SV COCIS or SISCO CV

Pattern Example Often used with Up-to-date library support favoring modularity
Observer Different Views of a Data Source, MVC Singleton(as update manager) no: use agents instead
Visitor Different Actions on a Abstract Syntax Tree Visitors often act on a Composite Structure yes: Single choice principle
Strategy Sorting algorithms Flyweight yes
Chain of responsibility Help System, Event-handling Composite  ?
State Drawing-tool with different tools (=states) Flyweight, State as singleton yes
Command Undo-redo mechanism, GUI-Toolkit Composite(Macro Commands) no: use agents instead
Iterator Lists Composite, Factory Methode

"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."'


"Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates."


"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."


Chain of responsability
"Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it"


Event Passing: Datei:Chain2.gif

"Allow an object to alter its behavior when its internal state changes. The object will appear to change its class."


"Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations."


"Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation."


Creational patterns

Creational patterns answer the question: How to create an object or an object composition?

Hint: You may remember the creational patterns easier by remembering the first letters of them: FABS

Pattern Example Often used with Up-to-date library support favoring modularity
Factory method Creation of application specific documents in a framework Abstract factory yes
Abstract factory GUI Toolkit Singleton yes
  • yes: Single choice principle
  • yes/no: Open-closed principle:
    • Open to extension of concrete factories (Supported GUI platforms)
    • Closed for new methods (supported widgets)
Builder Text Converter Composite yes
Singleton Database Manager Abstract Factory yes

Factory method
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses."


Abstract factory
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes."


"Separate the construction of a complex object from its representation so that the same construction process can create different representations."


"Ensure a class only has one instance, and provide a global point of access to it."


Structural patterns

Structural patterns answer the question: How do objects interact with each other?

Hint: You may remember the structural patterns easier by remembering the first letters of them: FCB PDF

Pattern Example Often used with Up-to-date library support favoring modularity
Bridge Different platform dependent implementations for a GUI Window Toolkit Abstract factory yes yes: Open-closed principle
Composite File System Chain of responsibility, decorator, flyweight, iterator, visitor yes no: Single choice principle (if has computational routines implemented)
Decorator Adding a scrollbar to a textfield
Facade Easy Interface to a Compiling System yes: Few interface principle
Proxy Image in a text document accessed through a proxy
Flyweight Single character as object in a texteditor

"Decouple an abstraction from its implementation so that the two can vary independently."


"Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly."


"Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality."


"Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use."


"Provide a surrogate or placeholder for another object to control access to it."


Proxy Access: Datei:Proxy2.gif

"Use sharing to support large numbers of fine-grained objects efficiently."


Flyweight Sharing: Datei:Flyweight2.gif


Definition: Separate call

A separate call is a qualified call whereby the target object is separate

Example: x.foo(...) where x is separate

Sentences you should know

  • The target of a separate call must be an argument of the enclosing routine
  • A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine
  • A call with separate arguments waits until:
    • The corresponding objects are all available
    • Preconditions hold