1. Map
Architecture
Frameworks
Design
Patterns

2. Issues
Software systems are complex and are only getting more complex. They encompass a large amount of detail and decisions.
There is a need to do such things as make decisions about software projects early, to divide work among teams, to ensure certain qualities in the software product.

3. Architecture
When starting the plans for a new building, the type of faucets to install on the sinks on the 23rd floor is not a key decision.
Abstraction of detail to focus on the major requirements. Foundation, size, major materials needed. Estimates of cost and risk.

4. Software Architecture
You may have heard of systems as described as having a two-tiered architecture or a layered architecture.
Similar notion: abstraction of detail.
Some questions:
What are the major components of a system and how do they interact?
What are the major properties of the system?

5. Definition
The structure or structures of the system, which comprise software components, the properties of those components, and the relationships among them. The intent is to provide a basis for decision making and risk reduction without having to consider all the detail.
The view from several kilometers up.

6. Why is Architecture Important?
A means of dealing with complexity.
A basis for decision making.
Helps to define the properties and limitations of a system.
Aids long term maintenance. It defines the important components and connections (the load-bearing walls).
Division of effort.
Standard patterns and styles.

7. Components and Connectors
Components: computational components.
Clients, servers
databases
user interface
Connectors: the means by which components interact.
Procedure calls
network protocols

8. Architectural Styles
Systems are often described as having a client-server architecture, or a layered architecture, etc. These are particular styles of architecture.
A style is defined by the components, connectors and constraints for a family of architectures.
Each style has particular properties, and knowing the properties aids in decisions about which style to use. Hybrids are also common.
Examples: pipe and filter, repository, layered.

9. Pipe and Filter
A component (filter) reads a stream of data on its inputs and produces streams of data on its outputs. The streams are the pipes.
Filters are independent and do not know the identity of upstream or downstream filters.
Very flexible, good for batch operations.
Example: Unix pipes.

10. Repository Two distinct components:
a central data repository
independent components that operation on the repository
Components may run sequentially or be triggered by changes in the repository.
Examples: compilers, database systems
Repository

11. Compiler Architecture
Translation
Scanner,
Parser
Optimization
Symbol Table,
Parse Tree
Code
Generation

12. Object-Oriented Organization
Components are objects and connectors are procedure calls.
Objects are responsible for maintaining some amount of data or procedure.
Objects need to know the identity of all objects they interact with. There is no limit placed on the amount of interconnectedness.
Object
Object
Object

13. Layered Systems
A hierarchy with each layer providing services to the layer above it and requesting services from the layer below it.
Support increasing levels of abstraction, which simplifies each layer.
Implementations of the same layer can be used interchangeably.
May have performance problems.

14. Modified Three Tier Arch.
User Interface Manager
Client
Workflow Manager
Generic Services
(Error Handling,
Authentication)
Server
Business Rules Manager
Persistent Object Manager
Database
Database

15. Where Does Architecture Fit?
Architecture is related to design but is at a higher level of abstraction.
When do you define the architecture?
Since the architecture captures important decisions about the structure of the software system, it needs to be defined early on in the analysis and design phase (at the same time subsystems are defined).
Subsystems are components and connectors.
Defines the interfaces between components, and the types of connectors.

16. CelsiusTech Systems
Naval product line (SS2000) for command, control and communication.
Architecture defines one family of application components which support multiple ship classes, platforms and operating systems.
Lower cost and greater reliability comes from fitting requirements into the context of the product line.
70% reuse for million plus line systems.

17. Reuse
The example makes the point for not only reusing code components as reuse is typically thought of, but also reusing a highly configurable architecture and design of a system.

18. Domains
Functionality that is used across a spectrum of applications (or subsystems) within a domain can be packaged into a single framework.
Examples:
MFC in user interfaces
OSEFA in manufacturing process control
Choices in operating systems
SEAF in engineering worksheets
Applications
Abstraction of
common operations.
Framework

19. Object-Oriented Frameworks
Framework: architecture + implementation + hooks.
The framework serves as the basis for many applications. Developers fill in the hooks to produce a new app.
Framework
Hooks
Framework
New Applications

20. Concepts
Applications customize and extend frameworks, much like a class inherits from it’s parent class.
The architecture and implementation of the framework impose restrictions on the application.
Parent
Framework
Subclass
Application

21. Example: GUI Builders
All window systems come with their own set of concepts, implementations, and the means by which those concepts interact.
Buttons and sliders in windows, menus that generate events, etc.
By buying into those concepts, user interfaces can be built quickly.
But it’s not for everything:
embedded systems (e.g. robotic soccer players)
voice control

22. Users and Developers of Frameworks
There are three main roles associated with frameworks:
Framework designers, also called framework developers or framework builders, develop the original framework
Framework users, also called framework clients or application developers, use the framework to develop applications.
Framework maintainers refine and redevelop the framework to fit new requirements.

23. Frameworks and Libraries
Applications call library functions.
Frameworks call application extensions. “Don’t call us, we’ll call you.”
Application
Library
Framework
Application
Framework
Library

24. Frameworks vs. Applications
are complete, executable
apply to a single problem
Frameworks
are incomplete, although they may include sample applications
apply to a range of applications within a domain

25. Ways to use a Framework As is: without any modifications.
Complete: add to the framework by filling in parts left open.
Customize: replacing part of the framework with custom code.

26. Strategies for Use
Appoint a framework expert. One or two people become familiar with the framework and can then be consulted during the project.
Design integration. It is important to fully integrate the design of the application with the design of the framework during the analysis and design phases of development.

27. Learning to Use the Framework
Frameworks can be difficult to learn so a means of lowering the learning curve is needed.
Tutorial sessions can be held to allow the framework builders to show users what can be done with the framework.
Tools can be used to investigate the operation of the framework and to allow the use of the hooks without learning the whole framework.
Documentation can describe the design and intended use of the framework, and provide examples of use.

28. CSF Overview
Java framework that handles communication between client server or peer to peer programs over a TCP/IP network.
Has some persistent storage capabilities.
Subsystem.
Communication
Persistence

29. Framework Concerns
Building a framework requires more resources than building a single application.
When a framework evolves, all applications built from the framework are affected.
A complex framework can take a significant amount of time to learn before it can be used effectively.
It isn’t always easy to determine if the framework is compatible with the desired application.

30. Framework Benefits
Reusable implementation and design that captures the expertise of developers within a domain.
The framework should have a quality design which will be ‘inherited’ by applications.
Decreased development time.
Reduced maintenance costs from maintaining a common code base.

31. Design Patterns
Design patterns can and have been used to design object-oriented frameworks.
A design pattern is a solution to a common software design problem in a given context.
problem: conditions that apply
solution: template of classes and collaborations
consequences: effect on the overall design
The solutions are not new, but ‘tried and tested.’

32. Observer Pattern
Problem: an object needs to monitor the state of another.
Solution: make the object an observer.
Consequences:
simple interface, timely notification, no need for polling
object must be able to receive updates at any time
Inbox
notify
Subject
Client
update
Observer

33. History of Design Patterns
Design patterns were inspired by the work of a real architect, Alexander, and his book A Timeless Way of Building.
Gamma adapted and applied it to software in his Ph.D. thesis.
Gamma and three others, Johnson, Helm, Vlissides, wrote a book called Design Patterns which sparked the patterns movement.

34. Patterns and Frameworks
Design patterns
design level constructs
small and easily implemented
the user must understand the details of the pattern to use it
used to help design frameworks
Frameworks
includes both design and implementation
larger and more complex than design patterns
the user does not need to understand the framework completely

35. Proxy Pattern
Problem: How can data on a server be represented at a client without having to keep a copy of the entire data object at the client.
Solution: create a proxy of the data on the client side.
Consequences:
the remote proxy hides the fact that the data isn’t local
transferring data can occur on demand
Data
Data
Proxy
Client

36. Composite Pattern
Problem: clients should be able to ignore the differences between compositions of objects and individual objects.
Consequences:
makes the client simple
can be overly general
Solution:
Component
Operation()
Add(Component)
Remove(Component)
GetChild(int)
Composite
Leaf
Operation()
Operation()
Add(Component)
Remove(Component)
GetChild(int)

37. Pattern Descriptions A full pattern description gives:
motivation for and applicability of the pattern (the problem in context)
structure, participants and collaborations of the participants
consequences, both good and bad, of using the pattern
an example showing the implementation of the pattern
programs or projects in which it has been used
related patterns

38. Architecture, Frameworks, and Design Patterns
Architectures are the overall high-level structure (components and connectors) of a system.
Frameworks are reusable designs and implementations of all or part of an architecture.
Design patterns can be used to help build architectures and frameworks.
Architecture
Frameworks
Design
Patterns