Software Engineering and Architecture

• 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

• 1968: First conference on Software engineering, organized by the NATO Science Committee, with the goal to establish sound engineering principles in order to obtain reliable, efficient and economically viable software.
• 1970: Royce proposes the waterfall life-cycle process for software development. Mantenance is seen as the final phase of the software lifecycle ( with only bug fixes and minor adjustments). did not account for the need to add funcionality due to new and changed requirements. The model had a strong and long influence on the industrial practice of software development.
• Late 1970's: First atempt toward a more evolutionary process model. Identification of new activitiesm, such as impact analysis and change propagatino. In the sam eperiod, formulation of "Laws of software evolution" by Lehman
• 1990's: General acceptance evolution, formalization and development of evolutionary processes (Gilb's evolutionary development, boehm's spiral model, Bennet and Rajichs' staged model, agile approaches).

Software evolution is a crucial ingredient of agile software development (iterative and incremental development, embracing change!)

• What and Why? Software evolution as a scientific discipline which studies the nature of the sotware evolution phenomenon to understand its driving factors. Keiy interests include the formulation and refinement of fundamental theories and laws of software evolution.
• How? Software evolution as an engineering discipline which studies more pragmatic aspects that aid software developers and project managers in their day-tp-day tasks. Key interests include the development and validation of tools and techniques to guide, implement and control software evolution.

- Reverse Engineering

- Re-engineering

Activity needed when trying to understand the architecture of behavior of a large software system, when the only reliable information is the source code.

Aims at building higher-level, more abstract, software models from the source code.

Activity needed when trying to re-structure a legacy system. In other words, systems that are still valuable, but are difficult to maintain.

Aims at producing a new system that is more evolvable.

• Corrective - errors need to be fixed
• Preventive - prevent problems in the future
• Adaptive - something has changed in the future (fix design issues)
• Adaptive - something has changed in the environment
• Perfective - improve system qualities e.g. performance

"Programs, like people, get old. We can't prevent aging, but we can understand its causes, take steps to limit its effescts, temprarily reverse some of the damage it has caused, and prepare for the day then the software is no longer viable."

Thus changing software is inevitable!

• Lack of movement
  • Caused by the failure of the product's owners to modify it to meet changing needs
  • Unless software is frequently updated, its users will become dissatisfied and they will change to a new product as soon as the benefits outweigh the costs of retraining and converting
• Ignorant Surgery
  • Caused by the changes that are made to software
  • Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade
  • Software that has been repeatedly modified in this way becomes very expensive to update

The symptoms of software aging mirror those of human aging:

• Owners of aging software find it incresingliy hard to keep up with the market and lose customers to newer products
• Aging software often degrades in its performance as a result of a gradually deteriorating structure
• Aging software often becomes 'buggy' becuase of errors introduced when changes are made

• Preventive medicine
  • What can we do to delay the decay and limit its effects?
  • Design for change
  • Code for change
  • Keep reors - documentation
  • Second opinion - reviews
• Software geriatrics
  • What can we do to treat software aging that has already occurred?
  • Stopping the deterioration (Verschlechterung)
  • Retroactive (rückwirkende) documentation
  • Retroactive invremental modularization
  • Amputation
  • Major surgery - restructuring