Software Engineering and Architecture

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks iin which each group of subtasks is at a particular level of abstraction.

Look at the slides from week 6 as well!!!

• Benefits:
  • Reuse of layers
  • Dependencies kept local
  • Echangeability: Layer implementation can be replaced by another, semantically equivalent implementation
• Liabilites
  • cascades of changing behavior: e.g. lower layer doubles speed
  • Buffering of data
  • Unnecessary work: e.g. calculation checksums, encryption, decryption, ...
  • Difficulty to find correct granularity

• Structure for systems that process a stream of data
• Each step is encapsulated in a filter
• Data is passe dthrough pipes (connectors) between adjacent filters
  • Buffering
  • Synchronisation

• Client-Server
  • Local Applications (Clients), today also Webclients
  • Used Services are centrally available on a server
  • Communication is usually a simple request-respnse scheme
• Peer-to-Peer
  • Distributed application
  • Partitioning of tasks or work load among different peers
  • Peers are equally priviliged
  • Peers can be both clients and servers

• Originally an idea from Artificial Intelligence
• Idea
  • Blackboard as common exchange of information
  • subsystems that process the available information and produce (and publish) new ones
  • control component that erchestrates the subsystems
• Use Case: Image preprocessing for tracking

• File Transfer
  • Applicatoins generate files for commonly use data, which are echanged
• Shared database
  • Applications read and write into a shared DB
• Remote Procedure Invocation
  • Applicatoins offer interfaces that can be called
• Messaging
  • Applications use a shared messaging system for exchanging data

• All desing patterns are inherently good
  • Counter-example: Singleton
• "I invented that pattern"
  • Rule of three-known-uses
• Design patterns are blueprints
  • with cop-paste code examples -> NO!
• Let you turn-off your brain
  • They give you better means to think about design!
• Are for experts only
  • good OO programming without knowing design patterns is impossible today

• Too much flexibility
  • Think about YAGNI (You ain't gonna need it) and simple code!
• Too many patterns in adesign
  • use where you really have the problem and can live with the drawbacks!
• separate patterns split into separate classes
  • typical beginners' mistake!
  • class explosion
• Over-engineering
• Misunderstanding the example/diagram for the pattern

• There are more than 23 Software architectural patterns
• Pattern names give us a common vocabulary to discuss design efficiently
  • Alternatives
  • Higher-level abstractions of object interactions
  • architectures
• A pattern names a recurring successful solution concept
• Hoest pattern descriptions tell drawbacks and alternatives
• Patterns are targets for refactoring!
• Beware of YAGNI (You ain't gonna need it)! Create simple code

The Model-View-Contoller architectural pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and contollers together comprise the user interface. A change propagation mechanism ensures consistency between the user interface and the model.

• Benefits
  • multiple views for the same model
  • synchronized views
  • "pluggable" views and contollers
  • exchange of "look and feel"
  • Framework potential
• Liabilites
  • increased complexity
  • Potential excessive number of updates
  • priivate, intimate coupling between view and contoller
  • close coupling of views and cotrollers to a model

The Publisher-Subscriber pattern helps to keep the state of cooperating components synchrinzed. To chieve this it enables one-way propagation of changes: one publisher notifies any number of subscribers about changes to its state.

• Benefits
  • Decoupliing of subscribers from publishers
  • Publishers, subscribers can come and go
  • Publisher may go off-line for a while
  • If implemented accordingly, event service can deliver old events for subscribers which were off-line for a while
• Liabilites
  • Event service may need to store event. Ho long?
  • Authenticity of events: How can a subscriber assume authenticiry of an event (if it does not know the subscriber)?
    • The subscriber must trust the event service
    • The event service tzrusts it publishers

• A pattern sonsists of more than the solution (diagram) but is a description of a prove engineering pxperience that applies in a given context and solves a problem generically with stating benefits and liabilities
• There are more patterns to know about than the 23 design patterns
• some patterns are obsolete (Singleton)
• Good pattern descriptions are honest about the consequences and clear about the problem and its forces driving the solution

• The notion of quality is central in software architecting: a software architecture is devised to gain insight in the qualities of a system at the earliest possible stage.
• Some qualities are observable via execution: performance, security, availability, functionality, usability
• And some are not observable via execution: modifiability, portability, reusability, testability

• Beside functional and business requirements you consider also quality requirements
• From the quality requirements (quality attributes) you choose among different sets of tactics
• The selection of tactitcs helps you finding the architecture

Quality Attributes like 

• System qualities
  • Availabitlity, modifiability, performance, security, testability, usability
• Business qualities
  • Time-to-market, etc.

• Quality attribute scenarios are a means to characterize quality attributes
• Definition: Aquality attribute scenario is a quality-attribute-specific requirement. It consists of six parts:

1. Source of Stimulus
   - A human, another computer, another acuator
2. Stimulus
   - a sort of an event such as: a crash, an unexpected message, change request
3. Environment (or Context)
   - operating condition of the system such as "normal mode", "overloaded"
4. Artifact
   - the "thing" that is stumulated (the system, a process, a component, ...)
5. Respnse
   - an activity undertaken after arrival of the stimulus
6. Response measure
   - something measurable upon completion of the response activity (down time, ...)

• General quality attribute scenarios
  • system independent
  • can potentially be relevant for any system
• Concrete quality attribute scenarios
  • specific to a particular system under consideration

The software architectural tactics:

• Availabilty tactics
• modifiability tactics
• performance tactics
• security tactics
• testability tactics
• usability tactics

Tactics detemine architectural patterns or styles.

A tactic is a design desicion that influences the control of a quality attribute respnse.

• tactitcs ca refine other tactics
  • Example: redundancy (primary tactic) can be refined into
    • redundancy of data (in a database)
    • redundancy oin a computation (in an embedded system)
• Patterns can encapsulate several tactics
  • A pattern that supports availabilty will also support a redundancy tactic and a synchronization tactic

The architecture style/pattern for a starting point for finden the architecture.

A software system's architecture is the set of principal design decisions about the system.

• Result of a consistent set of principles and techniques, applied consistently through all phases of a project
• Resilient in the face of (inevitable) changes
• Source of guidance throughout the product lifetime
• Consists of a few key geatures and rules for combining them

An architectural (style/) pattern expresses a fundamental structural schema for a software system. it provids a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships beween them

• subsystems: element types
  - databases, objects, abstract data types
• structural schema: topological layout
• responsibilites: semantic constraints
  - signatures, pre/post conditions
• rules: interaction mechanisms
  - procedure calls, pipes, event broadcast

An architectural style/pattern typically implements several tactics.

• Choose module to decompose
• Refine this module:
  • choose "achitectural drivers"
    • achitectural drivers: set of functionality, quality, ...
  • choose style or pattern that satisfies drivers -> child modules
    • for each quality there are identifiable tactics, and for many tactics there are more architectural styles/patterns
  • allocate funcionality to child modules from use cases
  • define interfaces for child modules
  • verify use cases and quality scenatios to be constraints
• Repeat steps