Architectur 2 Architecture Styles

Architecture Styles
ZIT 9.5 Microsoft Competence Center
Catalin George Raicu

ZIT 9.5 Microsoft Competence Center
Frankfurt / February, 2009
2
Agenda
• Introduction to software architecture – review

• Architectural process
• Refined Experience
• Architectural Style
• Q&A
C. G. Raicu, ZIT 9.5, February, 2009

3
Introduction to software architecture – review

(1)
• What is architecture?
- a set of principles and design decisions describing the structure and behavior of a software system
• Managing complexity through architecture
- Conceptual: decomposition, abstraction and simplification.
- Operational: communication enhancement, decreased number of task dependencies and increased
manageability of dependencies.
• The technical dimension of architecture
- The application model
- The system design
- The test plan
- The deployment / provisioning concept
- The operational concept

4
Introduction to software architecture – review

(2)
• From architecture to code:
- Conceptual System Design
- Detailed System Design
- Development (Coding)
- Unit & Integration Testing
- System Testing
- System Delivery
• Documenting the architecture: the “4+1” model
- the logical view,
- the process view,
- the physical view,
- the development view,
- the scenario (use case) view.
• Use case driven modeling and development
- WHAT system are we building, HOW is the system going to be structured, WHO will the system
interact with

5
Agenda

• Q&A

6
Architectural Process
Where do Architectures Come From?
• All software architectures rely on two pillars:
- Creativity:
- Fun, BUT strained with risk
- May be unnecessary, BUT may render the best result
- Method
- Efficient in familiar terrain, BUT not always successful
- Predictable outcome (pros & cons), BUT quality of methods varies

7
Objectives
• Creativity
- Enhance your skill-set
- Provide new tools
• Method
- Focus on highly effective and proven techniques
• Develop judgment:
- when to develop novel solutions
- when to follow established method

8
Design Stages
• Feasibility stage:
- identifying a set of feasible concepts for the design as a whole
• Preliminary design stage:
- selection and development of the best concept.
• Detailed design stage:
- development of engineering descriptions of the concept.
• Refinement stage:
- evaluating and altering the concept to suit the requirements of production,
distribution, consumption and product retirement.

9
Potential Problems
• If the designer is unable to produce a set of feasible concepts, progress stops.
• As problems and products increase in size and complexity, the probability that
any one individual can successfully perform the first steps decreases.
• The standard approach does not directly address the situation where system
design is at stake, i.e. when relationship between a set of products is at issue.
• As complexity increases or the experience of the designer is not sufficient,
alternative approaches to the design process must be adopted.

10
Alternative Design Strategies
• Standard
• Linear model (as above)
• Cyclic
• Process can revert to an earlier stage
• Parallel
• Independent alternatives are explored in parallel
• Adaptive (“lay tracks as you go”)
• The next design strategy of the design activity is decided at the end of a
given stage
• Incremental
• Each stage of development is treated as a task of incrementally improving
the existing design

11
Identifying a Viable Strategy
• Use fundamental design tools:
- Abstraction But
- Modularity how?
• Use:
- Inspiration, where inspiration is needed But where is
- Predictable techniques elsewhere. creativity required?
• Applying own experience or experience of others.

12
The Basic Tools of Software Engineering
• Abstraction, applicable in two different ways:
- Bottom-up: look at details, and abstract “up” to concepts
- Top-down: choose concepts, then add detailed substructure, and move
“down”
• Modularity, applicable in six different ways:
- Splitting a design into two or more modules
- Substituting one design module for another
- Augmenting the system by adding a new module
- Excluding a module from the system
- Inverting a module to create new interfaces (design rules)
- Porting a module to another system
• The key design principles

13
A Few Definitions*
• Abstraction:
- “The act or process of separating in thought, of considering a thing independently of its
associations; or a substance independently of its attributes; or an attribute or quality
independently of the substance to which it belongs.”
• Reification:
- “The mental conversion of … [an] abstract concept into a thing.”
• Deduction:
- “The process of drawing a conclusion from a principle already known or assumed;
spec. in Logic, inference by reasoning from generals to particulars; opposed to
INDUCTION.”
• Induction:
- “The process of inferring a general law or principle from the observation of particular
instances (opposed to DEDUCTION).”
source: Oxford English Dictionary

14
Abstraction and the Fundamental Machines
• What concepts should be chosen at the outset of a design task?
- One technique: Search for a “fundamental machine” that serves as an
abstraction of a potential system that will perform the required task. For
instance:
- Q: what kind of fundamental machine makes a software system
embedded in a washing machine?
- A: at core, it is basically just a little finite state machine.
• Fundamental machines provide a plausible first conception of how an application
might be built.
• Every application domain has its common fundamental machines.

15
Fundamental Machines
Domain Fundamental Machines
Graphics Pixel arrays
Transformation matrices
Widgets
Word processing Structured documents
Layouts
Process control Finite state machines
Web pages Hypertext
Composite documents
Scientific computing Matrices
Mathematical functions
Banking Spreadsheets
Databases
Transactions

16
Choosing the Level and Terms of Discourse
• Any attempt to use abstraction as a tool must choose a level of discourse, and
once that is chosen, must choose the terms of discourse.
- Variant 1: initial level of discourse is one of the application as a whole (step-
wise refinement).
- Variant 2: work, initially, at a level lower than that of the whole application.
- Once several such sub-problems are solved they can be composed
together to form an overall solution
- Variant 3: work, initially, at a level above that of the desired application.
- E.g. handling simple application input with a general parser.

17
The Key Design Principles
• Separation of concerns: Break your application into distinct features that overlap in
functionality as little as possible.
• Single Responsibility Principle: Each component or a module should be responsible for
only a specific feature or functionality.
• Principle of least knowledge: A component or an object should not know about internal
details of other components or objects (also known as the Law of Demeter).
• Don’t Repeat Yourself (DRY): There should be only one component providing a specific
functionality; the functionality should not be duplicated in any other component.
• Avoid doing a big design upfront: If your application requirements are unclear, or if
there is a possibility of the design evolving over time, avoid making a large design effort
prematurely (often abbreviated as BDUF).
• Prefer composition over inheritance: Wherever possible, use composition over
inheritance when reusing functionality because inheritance increases the dependency
between parent and child classes, thereby limiting the reuse of child classes.

18
The Grand Tool: Refined Experience
• Experience must be reflected upon and refined.
• The lessons from prior work include not only the lessons of successes, but also
the lessons arising from failure.
• Learn from success and failure of other engineers
- Literature
- Conferences
- Networking
• Experience can provide that initial feasible set of “alternative arrangements for
the design as a whole”.

19
Agenda

• Q&A

20
Refined Experience
Patterns, Styles, and DSSAs

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc..
21
Refined Experience
Domain-Specific Software Architectures*
• A DSSA is an assemblage of software components
- specialized for a particular type of tasks (domain),
- generalized for effective use across that domain,
- composed in a standardized structure (topology) effective for building
successful applications.
• Since DSSAs are specialized for a particular domain they are only of value if one
exists for the domain wherein the engineer is tasked with building a new
application.
• DSSAs are the pre-eminent means for maximal reuse of knowledge and prior
development and hence for developing a new architectural design.
Source: http://www.sei.cmu.edu/pub/documents/92.reports/pdf/sr09.92.pdf

22
Refined Experience
Architectural Patterns
• An architectural pattern is a set of architectural design decisions that are
applicable to a recurring design problem, and parameterized to account for
different software development contexts in which that problem appears.
• Architectural patterns are similar to DSSAs but applied “at a lower level” and
within a much narrower scope.

23
Refined Experience
State-Logic-Display: Three-Tiered Pattern
• Application Examples
- Business applications
- Multi-player games
- Web-based applications

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc.
24
Refined Experience
Model-View-Controller (MVC)
• Objective: Separation between information, presentation and user interaction.
• When a model object value changes, a notification is sent to the view and to the controller.
- Thus, the view can update itself and the controller can modify the view if its logic so
requires.
• When handling input from the user the windowing system sends the user event to the
controller.
- If a change is required, the controller updates the model object.
View
Graphical (Encapsulation of
display display choices)
Model
(Encapsulation
of information)
Controller
(Encapsulation of
UI events interaction
semantics)

25
Refined Experience
Architectural Styles
• An architectural style is a named collection of architectural design

decisions …
• A primary way of characterizing lessons from experience in software
system design
• Reflect less domain specificity than architectural patterns
• Useful in determining everything from subroutine structure to top-level
application structure
• Many styles exist (and we will discuss them in detail ☺)

26
Agenda

• Q&A

27
Definitions of Architectural Style
• Definition, in two “flavors”:
- An architectural style is a named collection of recurring organizational

patterns & idioms, meaning
- established, shared understanding of common design forms
- mark of mature engineering field. (Shaw & Garlan)
- An architectural style is an abstraction of recurring composition & interaction

characteristics in a set of architectures (Medvidovic & Taylor)

28
Basic Properties of Styles
• A vocabulary of design elements
- Component and connector types; data elements
- e.g., pipes, filters, objects, servers
• A set of configuration rules
- Topological constraints that determine allowed compositions of elements
- e.g., a component may be connected to at most two other components
• A semantic interpretation
- Compositions of design elements have well-defined meanings
• Possible analyses of systems built in a style

29
Benefits of Using Styles
• Design reuse
- Well-understood solutions applied to new problems
• Code reuse
- Shared implementations of invariant aspects of a style
• Understandability of system organization
- A phrase such as “client-server” conveys a lot of information
• Interoperability
- Supported by style standardization
• Style-specific analyses
- Enabled by the constrained design space
• Visualizations
- Style-specific depictions matching engineers’ mental models

30
Style Analysis Dimensions
• What is the design vocabulary (component and connector types)?
• What are the allowable structural patterns?
• What is the underlying computational model?
• What are the essential invariants of the style?
• What are common examples of its use?
• What are the (dis)advantages of using the style?
• What are the style’s specializations?

31
Some Common Styles
• Traditional, language-influenced styles • Interpreter
- Sequential processing - Interpreter
- Object-oriented - Mobile code
• Layered • Implicit invocation
- Virtual machines - Event-based
- Client-server - Publish-subscribe
• Data-flow styles • Peer-to-peer
- Batch sequential • “Derived” styles
- Pipes and filters - REST
• Shared memory
- CORBA
- Blackboard
- COM/DCOM
- Rule based

32
Sequential Processing Style
• Components are programs and libraries
- Main executable and associated dll’s
• Connectors are function invocations and corresponding parameters
• Style invariants
- There is always a main execution and control loop
• Advantages
- Simplicity
• Disadvantages
- Simplicity ☺

33
Sequential Processing Style
Function
library
(dll)
call/return
Function Function
library library
Executable
(dll) call/return call/return (dll)
Main Loop
call/return call/return
Function Function
library library
(dll) (dll)

34
Object-Oriented Style
• Components are objects
- Data and associated operations
• Connectors are messages and method invocations
- Objects are responsible for their internal representation integrity
- Internal representation is hidden from other objects
• Advantages
- “Infinite malleability” of object internals
- System decomposition into sets of interacting agents
• Disadvantages
- Objects must know identities of servers
- Side effects in object method invocations

35
Object-Oriented Style
Interaction & control

object
Procedure
“GET” Procedure Procedure call “PROCESS”
call call “SET”
Processing object
Domain object

36
Layered Style – 1
• Hierarchical system organization
- “Multi-level client-server”
- Each layer exposes an interface (API) to be used by above layers
• Each layer acts as a
- Server: service provider to layers “above”
- Client: service consumer of layer(s) “below”
• Connectors are protocols of layer interaction
• Virtual machine style results from fully opaque layers

37
Layered Style – 2
• Advantages
- Increasing abstraction levels
- Evolvability
- Changes in a layer affect at most the adjacent two layers (reuse)
- Different implementations of layer are allowed as long as interface is
preserved
- Standardized layer interfaces for libraries and frameworks
• Disadvantages
- Not universally applicable
- Performance
• Layers may have to be skipped
- Determining the correct abstraction level

38
Layered Style
breach
L3 bridging
L2.a L2.b L2.c
L1.x L1.y L1.z

breach

39
Virtual Machine Style
Layer 1
Application A
Layer 2
Application B Application C
Layer 3
Application D

40
Client-Server Style
• Components are clients and servers
• Connectors are RPC-based network interaction protocols
• Style invariants:
- Servers do not know number or identities of clients
- Clients know server’s identity
• Advantages
- Explicit support for separation of concerns
• Disadvantages
- Lack of support for single responsibility

41
Client-Server Style
CLIENT 1 CLIENT 2 CLIENT 3

User interaction User interaction User interaction
Procedure
Procedure
Procedure call
call
call
SERVER
Business Logic
State
Process

42
Data-Flow Styles
Batch Sequential
- Separate programs are executed in order; data is passed as an aggregate
from one program to the next.
- Connectors: file system tools, human operators (e.g. ConnectDirect, tapes)
- Data Elements: Explicit, aggregate elements passed from one component to
the next upon completion of the producing program’s execution.
• Typical uses: Transaction processing in financial systems. “The Grandfather of
all Styles”

43
Pipes and Filters Style – 1
• Components are filters
- Transform input data streams into output data streams
- Possibly incremental production of output
• Connectors are pipes
- Conduits for data streams
- Filters are independent (no shared state)
- Filter has no knowledge of up- or down-stream filters
• Variations
- Pipelines — linear sequences of filters
- Bounded pipes — limited amount of data on a pipe
- Typed pipes — data strongly typed

44
Pipes and Filters Style – 2
• Advantages
- System behavior is a succession / composition of component behaviors
- Filter addition, replacement, and reuse (possible to hook any two filters
together)
- Certain analyses (throughput, latency, deadlock)
- Concurrent execution
• Disadvantages
- Batch organization of processing
- Interactive applications
- Lowest common denominator on data transmission

45
Pipes and Filters Style
Data Pipe Pipe

Filter Filter Filter Data
stream stream
Pipe Pipe
Filter
Pipe

46
Blackboard Style
• Two kinds of components
- Central data structure (blackboard)
- Components operating on the blackboard (agents)
• Connectors can be anything from RPC based protocols to shared memory
- System control is entirely driven by the blackboard state
• Advantages
- Excellent separation of concerns and single responsibility
- Explicit process state
• Disadvantages
- Streamlining the processing
- Interactive applications

47
Blackboard Style
Agent 1
Agent n Agent 2
Data structure
(Blackboard)
Agent n-1 Agent 3
Agent …

48
Rule-Based Style
Inference engine parses user input and determines whether it is a fact/rule or a
query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it
queries the knowledge base for applicable rules and attempts to resolve the
query.
• Components are user interface, inference engine, knowledge base
• Connectors are direct procedure calls and/or shared memory.
• Data Elements are facts and queries
• Behavior of the application can be very easily modified through addition or
deletion of rules from the knowledge base.
• Caution: When a large number of rules are involved understanding the
interactions between multiple rules affected by the same facts can become very
difficult.

49
Rule-Based Style
User interaction
facts/rules || queries
Procedure
call
Inference engine
Procedure
call
Knowledge base
(facts/rules)

50
Interpreter Style
Interpreter parses and executes input commands, updating the state
• Components are command interpreter, program/interpreter state, user interface.
• Connectors typically direct procedure calls and shared state.
• Highly dynamic behavior possible, where the set of commands is dynamically
modified. System architecture may remain constant while new capabilities are
created based upon existing primitives.
• Superb for end-user programmability; supports dynamically changing set of
capabilities
• Examples: VBScript, Jscript/ECMAScript

51
Interpreter Style
inputs Pseudo-code
Pseudo-code
To Be
State
Interpreted
outputs Interpretation
Interpretation Selected instructions
Engine
Engine Selected data
Control State

52
Mobile-Code Style
• Summary: a data element (some representation of a program) is dynamically
transformed into a data processing component.
• Components: “Execution dock”, which handles receipt of code and state; code
compiler/interpreter
• Connectors: Network protocols and elements for packaging code and data for
transmission.
• Data Elements: Representations of code as data; program state; data
• Examples: SQL Ad-hoc querying, some Reflection scenarios

53
Mobile-Code Style
Execution Execution Execution

environment environment environment
stream
stream of code
of code stream
of code
SERVER

54
Implicit Invocation Style – 1
• Event announcement instead of method invocation
- “Listeners” register interest in and associate methods with events
- System invokes all registered methods implicitly
• Component interfaces are methods and events
• Two types of connectors
- Invocation is either explicit or implicit in response to events
- “Announcers” are unaware of their events’ effects
- No assumption about processing in response to events

55
Implicit Invocation Style – 2
• Advantages
- Component reuse
- System evolution
- Both at system construction-time & run-time
• Disadvantages
- Counter-intuitive system structure
- Components relinquish computation control to the system
- No knowledge of what components will respond to event
- No knowledge of order of responses

56
Publish-Subscribe
Subscribers register/deregister to receive specific messages or specific content.
Publishers broadcast messages to subscribers either synchronously or
asynchronously.
• Components: Publishers, subscribers, proxies for managing distribution
• Connectors: Typically a network protocol is required. Content-based
subscription requires sophisticated connectors.
• Data Elements: Subscriptions, notifications, published information
• Topology: Subscribers connect to publishers either directly or may receive
notifications via a network protocol from intermediaries
• Qualities yielded: Highly efficient one-way dissemination of information with very
low-coupling of components

57
Publish-Subscribe
Subscriber 1
Subscriber 2
Event
Subscriber 3
Stream
Stream SERVER
(publisher)
Stream

58
Event-Based Style
• Independent components asynchronously emit and receive events
communicated over event buses
• Components: Independent, concurrent event generators and/or consumers
• Connectors: Event buses (at least one)
• Data Elements: Events – data sent as a first-class citizen over the event bus
• Topology: Components communicate with the event buses, not directly to each
other.
• Variants: Component communication with the event bus may either be push or
pull based.
• Highly scalable, easy to evolve, effective for highly distributed applications.

59
Event-Based Style
Business logic User interaction
event event
notifications notifications
Event bus
event event
notifications notifications
Process State

60
Peer-to-Peer Style
• State and behavior are distributed among peers which can act as either clients
or servers.
• Peers: independent components, having their own state and control thread.
• Connectors: Network protocols, often custom.
• Data Elements: Network messages
• Topology: Network (may have redundant connections between peers); can vary
arbitrarily and dynamically
• Supports decentralized computing with flow of control and resources distributed
among peers.
• Highly robust in the face of failure of any given node.
• Scalable in terms of access to resources and computing power.
- But extremely demanding in terms of protocol’s complexity!

61
Peer-to-Peer Style
Application
Application
instance
instance Stream
Stream
Stream
Stream Application
instance
Application
instance Stream
Stream
Application
instance

62
Heterogeneous Styles
• More complex styles created through composition of simpler styles
• REST (REpresentational State Transfer)
- Focus on state transitions instead on method invocation
• Distributed objects
- CORBA, COM/DCOM
• …

63
REST Style
A style where the application state and functionality are abstracted into uniquely
addressable resources.
• Components: resources and clients
• Connectors: network protocol (client-server, stateless, cacheable, layered).
• Data Elements: state.
• Topology: practically every possible meshing topology imaginable.

64
REST Style
Resource server 1
Limited verbs & types

User agent Unlimited nouns
Resource server 2
Resource server n

65
Distributed Objects: CORBA, COM/DCOM
• “Objects” (coarse- or fine-grained) run on various hosts, written in heterogeneous
languages. Objects provide services through well-defined interfaces. Objects invoke
methods across host, process, and language boundaries via remote procedure calls
(RPCs).
• Components: Objects (software components exposing services through well-defined
provided interfaces)
• Connector: (Remote) Method Invocation / (Remote) Procedure Call
• Data Elements: Arguments to methods, return values, and exceptions
• Topology: General graph of objects from callers to callees.
• Additional constraints imposed: Data passed in remote procedure calls must be
serializable. Callers must deal with exceptions that can arise due to network or process
faults.
• Location, platform, and language “transparency”. CAUTION – usually does not works as
advertised! ☺

66
Distributed Objects: CORBA, COM/DCOM
Component server 1
Component Limited types

Component server 2
consumer Unlimited verbs & nouns
Component server n

67
Observations
• Different styles result in
- Different architectures
- Architectures with greatly differing properties
• A style does not fully determine resulting architecture
- A single style can result in different architectures
- Considerable room for
- Individual judgment
- Variations among architects
• A style defines domain of discourse
- About problem (domain)
- About resulting system

68
Style Summary (1/4)
Style Category & Summary Use It When Avoid It When
Name
Language-influenced styles
Main Program and Main program controls program Application is small and simple. Complex data structures needed.
Subroutines execution, calling multiple Future modifications likely.
subroutines.
Object-oriented Objects encapsulate state and Close mapping between external entities and Application is distributed in a heterogeneous
accessing functions internal objects is sensible. network.
Many complex and interrelated data Strong independence between components
structures. necessary.
High performance required.
Layered
Virtual Machines Virtual machine, or a layer, offers Many applications can be based upon a Many levels are required (causes inefficiency).
services to layers above it single, common layer of services. Data structures must be accessed from multiple
Interface service specification resilient when layers.
implementation of a layer must change.
Client-server Clients request service from a server Centralization of computation and data at a Centrality presents a single-point-of-failure risk;
single location (the server) promotes Network bandwidth limited; Client machine
manageability and scalability; end-user capabilities rival or exceed the server’s.
processing limited to data entry and
presentation.

69
Style Summary (2/4)
Data-flow styles
Batch sequential Separate programs executed Problem easily formulated as a set of Interactivity or concurrency between
sequentially, with batched input sequential, severable steps. components necessary or desirable.
Random-access to data required.
Pipes-and-filters Separate programs, a.k.a. filters, [As with batch-sequential] Filters are useful in Interaction between components required.
executed, potentially concurrently. more than one application. Data structures Exchange of complex data structures between
Pipes route data streams between easily serializable. components required.
filters
Shared memory
Blackboard Independent programs, access and All calculation centers on a common, Programs deal with independent parts of the
communicate exclusively through a changing data structure; common data.
global repository known as Order of processing dynamically determined Interface to common data susceptible to
blackboard and data-driven. change. When interactions between the
independent programs require complex
regulation.
Rule-based Use facts or rules entered into the Problem data and queries expressible as Number of rules is large.
knowledge base to resolve a query simple rules over which inference may be Interaction between rules present.
performed. High-performance required.

70
Style Summary (3/4)
Interpreter
Interpreter Interpreter parses and executes the Highly dynamic behavior required. High High performance required.
input stream, updating the state degree of end-user customizability.
maintained by the interpreter
Mobile Code Code is mobile, that is, it is executed When it is more efficient to move processing Security of mobile code cannot be assured, or
in a remote host to a data set than the data set to processing. sandboxed.
When it is desirous to dynamically customize When tight control of versions of deployed
a local processing node through inclusion of software is required.
external code

71
Style Summary (4/4)
Implicit Invocation
Publish-subscribe Publishers broadcast messages to Components are very loosely coupled. When middleware to support high-volume data
subscribers Subscription data is small and efficiently is unavailable.
transported.
Event-based Independent components Components are concurrent and independent. Guarantees on real-time processing of events is
asynchronously emit and receive Components heterogeneous and network- required.
events communicated over event distributed.
buses
Peer-to-peer Peers hold state and behavior and Peers are distributed in a network, can be Trustworthiness of independent peers cannot
can act as both clients and servers heterogeneous, and mutually independent. be assured or managed.
Robust in face of independent failures. Resource discovery inefficient without
Highly scalable. designated nodes.
More complex styles
REST Mesh of components abstracting When extreme scalability in heterogeneous When scenarios are local and rather
state and functionality, uniquely application environments is required. specialized.
addressable over a constrained set When frequent changes are part of the non-
of well-defined operations. functional requirements.
Distributed Objects Objects instantiated on different Objective is to preserve illusion of location- When high overhead of supporting middleware
hosts transparency is excessive. When network properties are
unmaskable, in practical terms.

72
Agenda

• Q&A

73
Resources
• http://portal.acm.org/dl.cfm
• http://msdn.microsoft.com/en-us/architecture/default.aspx
• http://www.sei.cmu.edu/architecture/
• http://ieeexplore.ieee.org/Xplore/guesthome.jsp
• http://www.wwisa.org/
• http://www.iasahome.org/web/home/home

Architectur 2 Architecture Styles

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Architectur 2 Architecture Styles

Caricato da

Copyright:

Formati disponibili

Architecture Styles

ZIT 9.5 Microsoft Competence Center

Catalin George Raicu

• Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

• Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

• Applying own experience or experience of others.

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

source: Oxford English Dictionary

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

• Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

• An architectural style is a named collection of architectural design

C. G. Raicu, ZIT 9.5, February, 2009

• Introduction to software architecture – review

C. G. Raicu, ZIT 9.5, February, 2009

- An architectural style is a named collection of recurring organizational

- An architectural style is an abstraction of recurring composition & interaction

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

Interaction & control

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

L2.a L2.b L2.c

L1.x L1.y L1.z

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

CLIENT 1 CLIENT 2 CLIENT 3

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

C. G. Raicu, ZIT 9.5, February, 2009

Data Pipe Pipe

C. G. Raicu, ZIT 9.5, February, 2009