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

Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu 1

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 2

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 of 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 ). 3

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 on separation of concerns (e.g., presentation layer, business logic layer, data access layer, DB layer). 4

… 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 . 5

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. 6

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

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. 8

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 9

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 10 industry leaders.

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 11

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. 12

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. 13

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. 14

Blackboard System • A blackboard system in computer science is composed of 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. 15

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 16

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 17

Plug-in • Plugins interact with a main application (a web browser or 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 18

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? 19

Multi-tier 20

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. 21

Software Componentry • Purely component (object) based . 22

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. 23

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 24