Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu 1 - - PowerPoint PPT Presentation

1

Software Architecture

Jay Urbain, Ph.D. urbain@msoe.edu

2

Software Architecture (SA)

• 1. SA: How a software system is structured.

– Consists of software components, their external properties, and their relationships with one another.

• 2. Also refers to documentation of a system's software

architecture. – facilitates communication between stakeholders – documents early decisions about high-level design – facilitates reuse of design components and patterns between projects

3

A little history…

• Computer science has come across problems associated

with complexity since its formation.

• Fundamental principles of SA have been applied

sporadically by software engineers since mid 1980s!

• Early attempts to capture and explain software architecture
• f a system were imprecise and disorganized.
• Problems of complexity were initially solved by choosing the

right data structures, algorithms, and by applying the concept of separation of concerns (SoC).

Separation of concerns (SoC)

• Design principle that comprises the process of

separating a program into distinct features that overlap in functionality as little as possible.

• A concern is any piece of interest or focus in a program.
• Concerns are synonymous with features or behaviors.
• Traditionally achieved through modularity of

programming and encapsulation, i.e., information hiding.

• Layered designs in information systems are often based
• n separation of concerns (e.g., presentation layer,

business logic layer, data access layer, DB layer).

4

5

… a little more history…

• Initial sets of design patterns, styles, best practices,

description languages, and formal logic were developed during the 1990s.

• SA as a discipline is centered on the idea of reducing

complexity through abstraction & separation of concerns.

• To date there is still no agreement on the precise

definition of the term “software architecture”.

• As a maturing discipline with no clear rules on the right

way to architect a system the action of architecting is still a composition of art and science.

6

The Art & Science

• The art and science aspect of SA is due to:

– How a commercial software system supports some aspect of a business or a mission. – How a system supports key business drivers as described via scenarios as non-functional requirements of a system, also known as quality attributes. – Quality attributes determine how a system will behave.

Note: Aspect-oriented programming (AOP)

• Increase modularity by allowing separation of cross-cutting

concerns.

• Cross-cutting concerns are aspects of a program which

affect other concerns.

• These concerns often cannot be cleanly decomposed from

the rest of the system, and can result in either scattering, tangling (dependencies), or both.

• Examples: RT-constraints, memory management,

transaction processing, security, logging.

7

8

The Art pArt

• Every system is unique due to the nature of the business

drivers it supports, as such the degree of quality attributes exhibited by a system will vary:

– Fault-tolerance – Backward compatibility – Extensibility – Reliability – Maintainability – Availability – Security – Usability – Performance – Other utilities will vary with each implementation.

9

User’s Perspective

• Imperative to bring user's perspective into software

architecture design.

• SA is really the amalgamation of the perspectives of

multiple stakeholders into a software system. Embodies:

– developers – software system operational support group – software maintenance specialists – deployer – tester – business end user – Management/strategy

10

History

• The origin of software architecture as a concept was first identified in

the research work of Edsger Dijkstra in 1968 and David Parnas in the early 1970’s.

• The study of the field increased in popularity since the early 1990s with

work concentrating on architectural styles (and later patterns), architecture description languages, architecture documentation, and formal methods.

• Carnegie Mellon University and University of California, Irvine are doing

a significant amount of research in the field of software architecture.

• Research efforts are directed primarily in architectural styles, patterns,

architecture description languages, dynamic architectures, formal verification, and frameworks.

• Architecture in practice is heavily influenced by what is practices by

industry leaders.

11

Architecture examples

• Client-server
• Distributed computing
• Peer-to-peer
• Blackboard
• Implicit invocation
• Pipes and filters
• Plugin
• Monolithic system
• Three-tier (multi-tier) model
• Structured (module-based, but usually monolithic within modules)
• Software componentry
• Service-oriented architecture
• Search-oriented architecture

12

Client Server

• Client/server is a network architecture which separates

a client (often an application that uses a graphical user interface) from a server.

• Each instance of the client software can send requests

to a server.

13

Distributed computing

• Distributed open, scalable, transparent, fault tolerant

systems.

• Distribute computing for application across multiple

computing systems.

• This paradigm is a natural result of the use of computers

to form networks.

• Distributed programming typically falls into one of several

basic architectures or categories:

– Client-server, 3-tier architecture, N-tier architecture, grid computing, cloud computing, distributed objects, loose coupling, or tight coupling.

14

Peer-to-peer

• An architecture where there is no special machine or

machines that provide a distinct service (i.e., they may all provide similar services), or manage network resources.

• Instead all responsibilities are uniformly divided among all

machines, known as peers.

• Think of distributed computing, but not client-server.

15

Blackboard System

• A blackboard system in computer science is composed
• f an area of shared memory.
• The blackboard contains a problem to be solved.
• A collection of software agents or processes, often

referred to as knowledge sources, can access and modify the blackboard.

• Each agent can solve part of the problem or contribute to

the solution.

• Originally developed by the AI research community.
• Used in collaborative filtering.

16

Implicit invocation

• System is structured around event handling, using a

form of callback.

• Closely related to Inversion of control and what is known

informally as the Hollywood Principle, i.e., "don't call us, we'll call you."

• Useful paradigm that assists in the development of code

with high cohesion and low coupling that is easier to debug, maintain, and test.

• Think Observer Pattern

17

Pipes and filters

• Consists of a chain of processes or other data

processing entities, arranged so that the output of each element of the chain is the input of the next.

• Usually some amount of buffer is provided between

consecutive elements.

• The information that flows in these pipelines are often

byte (often characters) or bit streams.

• The concept is also called the pipes and filters design

pattern.

$ sudo ps aux | grep tomcat | grep -v grep | awk '{print $2}' | xargs kill

18

Plug-in

• Plugins interact with a main application (a web browser
• r an email program).
• Utilize a container which defines the interface/

environment (API) for running the plug-in.

• Usually provide a very specific function.

– Read multimedia files – Encrypt or decrypt email – Filter images in graphic programs – Play flash presentations – Browser functionality – Servlets, JSP, EJB – Android Activity

19

Monolithic

• A monolithic architecture is where processing, data,

and the user interface all reside on the same system.

• Why would you ever use a monolithic architecture?

20

Multi-tier

21

Structured Systems Analysis and Design Method (SSADM)

• The SSADM method involves the application of a

sequence of analysis, documentation, and design tasks.

• Structural decomposition of a system into data

processes.

• Dataflow/process oriented.
• Typically follows a waterfall-like design process.

22

Software Componentry

• Purely component (object) based.

23

Service Oriented Architecture

• SOA expresses a perspective of software architecture

that defines the use of loosely coupled software services.

• Support the requirements of the business processes and

software users.

• Resources on a network are made available as

independent services that can be accessed without knowledge of their underlying platform implementation.

24

Search Oriented Architecture

• The use of search engine technology as the main

integration component in an information system.

• Architectural layer usually occupied by a RDBMS is

supplemented or replaced with a search engine.

• Queries for information which would usually be

performed using SQL are replaced by keyword or fielded (or field-enabled) searches for structured, semi- structured, or unstructured data.

• Implication: inexact results