Software Architecture

Required Reading

Dan Berry's Inevitable Pain paper
Architectural Styles, from a book by Shaw and Garlan
Nice resources for on-your-own reading are at
- http://www.sei.cmu.edu/architecture/essays.html
- http://www.serc.nl/people/florijn/interests/arch.html
Another nice resource page is http://www.rspa.com/spi/design-architecture.html.
This group http://www.wwisa.org/ does not have much influence but it's there!

Requirements

All software development boils down to trying to build a system that meets some requirements.

Functional vs. non-functional

Abstract vs. concrete

Let us now spend a few minutes with Dr. Dan Berry, one of the luminaries of Requirements Analysis.

"The real problem of software engineering is dealing with ever-changing requirements."
quoting Fred Brooks on "essence vs. accidents" - requirements are the essence of what software does, accidents are coincidences of how it does it or how it was developed (language, tools, methods):
The hardest single part of building a software system is deciding precisely what to build.
syntax errors are "fuzz" compared with conceptual errors in most systems
every time a new "silver bullet" comes along and improves the accidental parts of software development, as soon as the method has to deal with the "essence" part, one part of the method becomes so painful that that part of the method gets postponed, avoided, and skipped.
Two things about requirements you need to know (from Michael Jackson): (a) requirements will change, and (b) requirements will be misunderstood.
Belady-Lehman graph:
as programs undergo continual change, their structure decays; inevitable and exponential.
new improved methods' purpose: "tame" the Belady-Lehman upswing

Now, what does all this have to do with Software Architecture? And what is software architecture, for that matter? Broadly, some architectural aspects follow directly from requirements, some architectural choices have an inherent "pain" level, and architectural mismatch with requirements likely may cause project failure. Happy thought! What other things are likely to cause project failure?

Now, let's get back to software architecture.

Relations

A fuzzy triangle of thought is formed by architecture, design patterns, and component-based software engineering.

You'll hear many similar concepts when talking about each.

Q: Do they (or any two) mean the same thing?

Q: If not, can they stand on their own?

Perhaps granularity is where these differ. Clint proposes: "There are big coarse-grained (machines, processes), medium-grained (objects with both external interfaces and internal relationships within a process), and fine-grained (atoms, data structures with limited visibility) aspects of software design -- to which ones do architecture, CBSE, and design patterns apply? [Can we] claim that the terms are used with different frequencies at the different granularities of software design. Your triangle elements might also differ in their degree of top-downness versus bottom-upness, and the relative persistence or lifespan of the elements being designed."

Many meanings

Architecture is the high-level design.

Architecture is the pattern of the design.

Architecture is the implementation framework.

Others?

Uses of architecture

Explanation of proposed system to stakeholders (does this mean it will stand?)

Blueprint for design/implementation

Education of new development team members

Constraint on what is allowed

Q: What sort of requirements are important to the architecture? (21.3 in reading calls these "architectural drivers")

Architecture as high-level design

Boxes and arrows

UML diagrams (top-level?)

Architecture as the pattern of the design

Architectural styles

Domain-specific architectures

Product-line architectures

Can we list known styles?

Note that these styles and categories are not mutually exclusive and may in some cases be redundant.

Distributed systems
- Client-server (stateless client?, stateless server?)
- N-Tier
- Peer-to-peer
- Distributed objects (different?)
- Proxy
Independent Components
- Communicating processes
- Event systems
- Message passing
Call-and-return systems
- main program and subroutine
- classic OO systems
- Hierarchical layers
Dataflow Systems
- Pipe and filter
- Batch sequential
Data-centered systems (repositories)
- Shared repository
- Databases
- Transactional DB
- Blackboard (AI)
- Hypertext systems
Bus
Event dispatcher
Implicit invocation
MVC?
Real-time task scheduler
Forking processes
Worker threads
Thread pool
Virtual machine
- interpreters
- rule-based systems
- Layered abstract machines
Extension Systems
- Plugin
- Callback
- Event-listeners

This dissertation has an interesting chapter on styles: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm (some of the elements above are taken from this work). An interesting article on "industrial" use of styles and design patterns is at http://www.stsc.hill.af.mil/crosstalk/2003/10/0310Petersson.html.

Architecture as an implementation framework

http://www.w3.org/TR/2003/WD-ws-arch-20030808/ http://www-106.ibm.com/developerworks/webservices/library/w-ovr/

CORBA, EJB, and many others as well

Using architecture

Conforming to in forward design/implementation

Recovering from existing system

Controlling maintenance changes

Architectural drift

2nd Law of Thermodynamics (entropy)

"Clean" design tends to degrade over time

Must work to keep system in line with architecture

Architectural mismatch

Q: Can you combine any two (or N) systems?

FQ: How hard will it be?

Describing architectures

Non-formal (anything) vs Formal (ADLs -- architecture description languages)

Views: Philippe Kruchten 4+1 model (IEEE Software, 12(6) Nov 1995):

logical view: structure/behavior of system
process view: threads of execution in system
development view: organization of system in development environment
physical view: deployment structure
plus one view: use cases and scenarios

Architecture Description Languages

Formal languages for describing architectures

http://www.sei.cmu.edu/architecture/adl.html has a list of SOME ADLs. Check these out as part of your investigation this week for HW #1. Q: would any of these be useful in whatever project you propose (or in our default, collaborative UML editor project)?

This group in England http://www-dse.doc.ic.ac.uk/Research/architecture.html has done significant s/w architecture research, including the Darwin language http://www.doc.ic.ac.uk/~dg1/tracta/papers/wicsa1.pdf

Components, connectors, configurations

Components and connectors are defined by their interface(s)

Rules for composition

Syntax and semantics

Connectors are first-class objects

Is a connector a component?

Q: Can anyone really use these ADLs on real-world projects?

Now for a Bit More on Requirements

Material from "Use Cases: Requirements in Context" (Kulak, Guiney)

Requirements are the effects that the computer is to exert in the problem domain, by virtue of the computer's programming. - Ben Kovitz

Requirements Engineering commonly includes Requirements Gathering/Elicitation, Requirements Specification, and Requirements Validation. Last lecture we talked briefly about some reasons why requirements can be "hard" to do well.

Example functional requirement: the program must be able to export HTML. Example non-functional requirement: the program must be high quality.

Now for a trivial aside (Capers Jones):

Function Points Probability of Failure
100 6%
1,000 17%
10,000 45%
100,000 80%
Advice:

Function Points	Probability of Failure
100	6%
1,000	17%
10,000	45%
100,000	80%

Remove/resolve conflicting requirements
Remove redundancy
Remove design assumptions
Find commonality among requirements, and abstract them
Separate functional and non-functional requirements

Our silver bullet for the next HW will be: Use Cases.

Now it is time to discuss project topics.