SlideShare une entreprise Scribd logo
1  sur  50
Télécharger pour lire hors ligne
1
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
2
 The software architecture of a program or computing
system is the structure (or structures) of the system,
including:
 Dividing software into subsystems.
 Deciding how these will interact.
 Determining their interfaces.
• The architecture is the core of the design, so all software
engineers need to understand it.
• The architecture will often constrain the overall efficiency,
reusability and maintainability of the system
3
 Why you need to develop an architectural model:
 To enable everyone to better understand the system
 To allow people to work on individual pieces of the system
in isolation
 To prepare for extension of the system
 To facilitate reuse and reusability
4
 An architecture is an abstraction of a system that
suppresses details of components that do not affect how
they:
 Use other components
 Are used by other components
 Relate to other components
 Interact with other components
5
 To ensure the maintainability and reliability of a system,
an architectural model must be designed to be stable.
 Being stable means that the new features can be easily
added with only small changes to the architecture.
6
aTruck aShip aAirplane theWarehouseCollecti on
theVehicleCollection
UML-A Generated Dependency Class:theRouter Dependency (1.0)
theStorage
aVehicle
UML-A Generated Dependency Class:theRouter Dependency (0.5)
availableVehicleCollection
UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated As sociationC lass:theVehicleC ollec tion Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati onCl ass:theVehi cleCollection Generali zation (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)
UML-A Generated Dependency Class:theRouter Dependency (1.0)
availableGoods
aPort
aPortC ollec tion
aSurplus aDifficiency
theTimeNeeded
theGoods
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:availableGoods Association (0.5)
aRouteCollection
UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)
UML-A Generated Association Class:aRoute Association (0.25)
UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0)
UML-A Generated Dependency Class:theRouter Dependency (1.0)
theAWT
aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog
aWarehouse
UML-A Generated AssUML-A Generated Association Class:aDifficiency Associ
UML-A Generated Association Class:aDifficiency AssociatioUML-A Generated Association Class:aDifficiency Association (1.0
UML-A Generated Association Class:aDifficiency AU ML-A Generated AssociationClaUML-A Generated AssociatioUML-A Generated Association Class:aDifficieU ML-A Generated AssociationClass:aDUML-A Generat
UML-A GeneraUML-A Generated As
aLocation
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
aNavPoint
UML-A Generated Association Class:aWarehouse Association (1.0)
UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aWarehouse Association (0.5)
UML-A Generated Association Class:aRoute Association (0.5)
aRoute
UML-A Generated Dependency C lass :aRouteCol lection Ass ociation (0.25)
UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (0.5)
UML-A Generated Association Class:aWarehouse Association (1.0)
UML-A Generated Dependency Class:aRouteCollection Association (0.5)
UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Dependency Class:theRouter Association (0.25)
UML-A Generated Association Class:aNavPoint Association (0.25)
theCargoRouter
UML-A Generated As sociationC lass:theWarehouseCollection Dependency ( 0.25)
UML-A Generated Association Class:theRouter Association (0.25)
UML-A Generated Association Class:theRouter A
theRouter
UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)
UML-A Generated Dependency Class :aRoUML-A Generated Association Clas s:theWarehouseC
UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5)
UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0)
UML-A Generated Dependency Class:theRouter Association (0.25)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Dependency Class:theRouter Association (1.0)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)
UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0)
This is a simple
software system!
7
8
Independent Components
Communicating
Processes
Event Systems
Client/Server Peer-to-Peer
Implicit
Invocation
Explicit
Invocation
Data Flow
Batch Sequential Pipe & Filter
Virtual Machine
Interpreter Rule-Based
System
Data-Centered
Repository Blackboard
Call and Return
Main Program
and Subroutine
Object
OrientedLayered
Remote Procedure Call
9
Shared Data
Client A Client B Client C
Client D Client E Client F
10
 Has goal of achieving the quality of integrability of data.
 The term refers to systems in which the access and update
of a widely accessed data store is their primary goal.
 Basically, it is nothing more than a centralized data store
that communicates with a number of clients.
 Important for this styles are three protocols:
communication, data definition and data manipulation
protocol
 A client runs on an independent thread of control.
 The means of communication distinguishes the two
subtypes: repository and blackboard
 Repository: a client sends a request to the system to perform
a necessary action (e.g. insert data)
 Blackboard: the system sends notification and data to
subscribers when data of interest changes, and is thus active
11
 Ensures data integrity
 Reliable, secure, easy to Backup, testability guaranteed
 Clients independent on the system: performance and
usability on the client side is good
 Problems with scalability
 Solutions: shared repositories, replication but this
increases complexity
12
 One of the most well-known examples of the data-
centered architecture, is a database architecture
 E.g. in RDBMS a set of related tables with fields, data
types, keys, ...
 Clients use data manipulation protocol to work with the
data
 E.g. SQL for inserting, selecting, deleting data, ...
 Depending on where clients are situated communication
protocol might be
 An inner-process communication
 Communication between components on the same machine
 Communication over network, e.g. LAN, Internet, etc.
13
 Has the goal of achieving the quality of reuse and
modifiability.
 The data-flow style is characterized by viewing the system
as a series of transformations on successive pieces of input
data.
 Data enter the system and then flows through the
components one at a time until
 Finally, the data is assigned to some final destination
(output or a data store).
 The architecture is very flexible.
 Almost all the components could be removed.
 Components could be replaced.
 New components could be inserted.
 Certain components could be reordered.
14
Validate Sort Update Report
15
 Batch sequential style
 The processing steps are independent components
 Each step runs to completion before the next step begins
 Pipe-and-filter style
 Emphasizes the incremental transformation of data by
successive components
 The filters incrementally transform the data (entering and
exiting via streams)
 The pipes are stateless and simply exist to move data
between filters
 Note That: It is easily made into a parallel or distributed
execution in order to enhance system performance
16
 Data flows through pipes: communication channels
between filters
 Processing units: filters
 Filters do not know anything about other filters
 Modularity, maintainability is good
 Data flows in streams: good for processing of images,
audio, video, ...
 Depending on where the filters reside different
execution architectures
 E.g. same process: filters run within threads
 E.g. same machine: filters run within own processes
 E.g. network: pipes use the networking architecture
17
 Pipe and Filter Example:
 Traditional Compilers: Compilation phases are pipelined,
though the phases are not always incremental. The phases
in the pipeline include
• lexical analysis + parsing + semantic analysis + code
generation
18
Main module
Subroutine A
Subroutine B
Subroutine A-1 Subroutine A-2
Physical layer
Data layer
Network layer
Transport layer
Application layer Class WClass V
Class X
Class Z
Class Y
19
 Has the goal of modifiability and scalability
 Has been the dominant architecture since the start of
software development
 Main program and subroutine style
 Decomposes a program hierarchically into small pieces (i.e.,
modules)
 Typically has a single thread of control that travels through
various components in the hierarchy
 Remote procedure call style
 Consists of main program and subroutine style of system that is
decomposed into parts that are resident on computers
connected via a network
 Strives to increase performance by distributing the computations
and taking advantage of multiple processors
 Incurs a finite communication time between subroutine call and
response.
20
 Object-oriented or abstract data type system
 Emphasizes the bundling of data and how to manipulate and
access data
 Keeps the internal data representation hidden and allows access
to the object only through provided operations
 Permits inheritance and polymorphism
 Layered system
 Assigns components to layers in order to control inter-
component interaction
 Only allows a layer to communicate with its immediate neighbor
21
 Layering: the structure of the system is organized into
set of layers
 Each layer in on the top of another layer, each layer
communicates only with the layer immediately below it.
 The higher layer sees the lower layer as a set of services.
 Well-defined interfaces between layers
 Reduces complexity,
 improves modularity,
 reusability,
 maintainability
22
 Typically organized into layers
 Successive layers provide more sophisticated services to
the layers above them
 Hardware services, kernel services, system services, UI
services
23
 A virtual machine implements an
instruction set for an imaginary
machine
 Often virtual machines are the
underplaying mechanism by which
a programming language is
executed
 E.g. Java virtual machine, different
interpreters
• Specifies an interface between
compiler and a real machine
 From conceptual point of view very
similar to OS
 Improves portability
24
 A common example of layered architecture is a network
protocol stack
 E.g. TCP/IP protocol stack - Four layers
 The lowest layer: handles communication between two
computers
 The internet layer: handles routing of packets across the
network
 The transport layer: guarantees that packets are error-
free and received in the same order as sent
 The application layer: supports application-specific
protocols
• E.g. HTTP, SMTP, FTP, ...
25
26
 Basic concept:
 The client uses a service
 The server provides a service
 Typically connected via a network
 Clients are independent from each other
 There is at least one component that has the role of
client, initiating connections in order to obtain some
service.
27
 Conceptually simple
 Clear separation of responsibilities, help testability
 Good scalability (if stateless)
 Excellent scalability (if server can be scaled out)
 Good for security, as data can be held at the server with
restricted access
 Risk of bad performance, if the communication between
client and server is slow, or has a high latency
 Need to develop/agree on a protocol between client and
server
 For stateful, centralized servers scalability is limited
28
 The server is no longer in the organizations network, but
somewhere in the Internet
 Example: cloud services by Salesforce, Google,
Microsoft
 Scalability, security, reliability is expected to be
handled by a specialized team
 Needs a working Internet connection
29
 Separation between client and server is removed
 Each client is a server at the same time, called peer
 The goal is to distribute the processing or data among many
peers
 No central administration or coordination
29
30
 Example: Skype uses a peer-to-peer protocol, but also
uses super-nodes and a central login servers
 Adv.
 Good for scalability
 Good for reliability, as data can be replicated over peer
 No single point of failure
 Disadv.
 Quality of service is not deterministic, cannot be guaranteed
 Very complex, hard to maintain and test
31
 The N-tier architecture is the modern client-server
architecture
 Originated with business applications
 Through the popularity of the Web today typically
related with Web applications
 Conceptually separate architecture into:
 Presentation,
 Application, and
 Data storage layers.
32
 Clients are typically rich
(ui + app-logic + communication)
 Servers store data
 Each client runs a complete application
 Drawbacks: each client has to know how to
communicate with all data servers
 Scalability is compromised because client are tightly
coupled with servers
33
 Evolved from 2-tier architectures to solve
their drawbacks
 A third tier is inserted between clients
and data servers
 Application or business logic tier: middle
tier.
 Typically middle tier is on the server side
(but recently might be split between the
server and the client)
 Scalability improved because clients are
thinner.
 Thin clients have no knowledge on
application
 A rich client contains full knowledge of
application
34
 Suitable for applications in which a central issue is
identifying and protecting related bodies of data.
 Data representations and their associated operations are
encapsulated in an abstract data type.
 Components: are objects.
 Connectors: are function and procedure invocations
(methods).
35
 Object-Oriented Invariants
 The data representation is hidden from other objects.
 Advantages
 it is possible to change the implementation without
affecting those clients.
 Can design systems as collections of autonomous
interacting agents.
 Disadvantages
 In order for one object to interact with another object (via
a method invocation) the first object must know the
identity of the second object
 Objects cause side effect problems:
• E.g., A and B both use object C, then B’s effects on C look
like unexpected side effects to A.
36
37
 Suitable for applications that involve loosely-coupled
collection of components, each of which carries out
some operation and may in the process enable other
operations.
 Instead of invoking a procedure directly ...
 A component can announce (or broadcast) one or more
events.
 Other components in the system can register an interest in
an event by associating a procedure with the event.
 When an event is announced, the broadcasting system
(connector) itself invokes all of the procedures that have
been registered for the event.
38
 Advantages:
 Provides strong support for reuse.
 Eases system evolution
 Disadvantages:
 When a component announces an event:
• it has no idea what other components will respond to it,
• it cannot rely on the order in which the responses are
invoked
• it cannot know when responses are finished
 Twitter, Google+
39
 Remote invocation architectures involve distributed
processing components
 Typically, a client component invokes a method
(function) on a remote component
 E.g. Web services
 Advantages:
 increased performance through distributed computation
 Disadvantages:
 tightly coupling of components
 increases communication overhead
40
 Transparently distribute
aspects of the software
system to different nodes
 An object can call
methods of another
object without knowing
that this object is
remotely located.
41
 Systems are seldom built from a single architectural
style
 Three kinds of heterogeneity:
 Locationally heterogeneous
• The drawing of the architecture reveals different styles in
different areas (e.g., a branch of a call-and-return system
may have a shared repository)
 Hierarchically heterogeneous
• A component of one style, when decomposed, is structured
according to the rules of a different style
 Simultaneously heterogeneous
• Two or more architectural styles may both be appropriate
descriptions for the style used by a computer-based system
42
‫ر‬َ‫ـد‬ْ‫ق‬‫ِـ‬‫ن‬،،،‫لما‬‫اننا‬ ‫نصدق‬ْْ‫ق‬ِ‫ن‬‫ر‬َ‫د‬
43
 Are concerned with the control flow between sub-
systems.
 Centralized control
 One sub-system has overall responsibility for control and
starts and stops other sub-systems
 Event-based control
 Each sub-system can respond to externally generated
events from other sub-systems or the system’s
environment
44
 A control sub-system takes responsibility for managing
the execution of other sub-systems
 Call-return model
 Top-down subroutine model
 Control starts at the top of a subroutine hierarchy and
moves downwards.
 Applicable to sequential systems
 Manager model
 One system component controls the stopping, starting
and coordination of other system processes.
 Applicable to concurrent systems.
45
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Main
program
46
System
controller
User
interface
Fault
handler
Computation
processes
Actuator
processes
Sensor
processes
47
 Driven by externally generated events where the
timing of the event is outside the control of the sub-
systems which process the event
 Two principal event-driven models:
 Broadcast models. An event is broadcast to all sub-
systems. Any sub-system which can handle the event
may do so
 Interrupt-driven models. Used in real-time systems
where interrupts are detected by an interrupt handler
and passed to some other component for processing
48
Sub-system
1
Event and message handler
Sub-system
2
Sub-system
3
Sub-system
4
49
Handler
1
Handler
2
Handler
3
Handler
4
Process
1
Process
2
Process
3
Process
4
Interrupts
Interrupt
vector
50

Contenu connexe

Tendances

Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10
koolkampus
 
Ch10-Software Engineering 9
Ch10-Software Engineering 9Ch10-Software Engineering 9
Ch10-Software Engineering 9
Ian Sommerville
 
Ch7-Software Engineering 9
Ch7-Software Engineering 9Ch7-Software Engineering 9
Ch7-Software Engineering 9
Ian Sommerville
 
Chapter 4 software design
Chapter 4  software designChapter 4  software design
Chapter 4 software design
Cliftone Mullah
 
Depandability in Software Engineering SE16
Depandability in Software Engineering SE16Depandability in Software Engineering SE16
Depandability in Software Engineering SE16
koolkampus
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9
Ian Sommerville
 
Ch15-Software Engineering 9
Ch15-Software Engineering 9Ch15-Software Engineering 9
Ch15-Software Engineering 9
Ian Sommerville
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
Ian Sommerville
 
System Models in Software Engineering SE7
System Models in Software Engineering SE7System Models in Software Engineering SE7
System Models in Software Engineering SE7
koolkampus
 
Defect Testing in Software Engineering SE20
Defect Testing in Software Engineering SE20Defect Testing in Software Engineering SE20
Defect Testing in Software Engineering SE20
koolkampus
 
Socio Technical Systems in Software Engineering SE2
Socio Technical Systems in Software Engineering SE2Socio Technical Systems in Software Engineering SE2
Socio Technical Systems in Software Engineering SE2
koolkampus
 
Ch16-Software Engineering 9
Ch16-Software Engineering 9Ch16-Software Engineering 9
Ch16-Software Engineering 9
Ian Sommerville
 
Ch20-Software Engineering 9
Ch20-Software Engineering 9Ch20-Software Engineering 9
Ch20-Software Engineering 9
Ian Sommerville
 
Software engg. pressman_ch-8
Software engg. pressman_ch-8Software engg. pressman_ch-8
Software engg. pressman_ch-8
Dhairya Joshi
 

Tendances (20)

Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10Architectural Design in Software Engineering SE10
Architectural Design in Software Engineering SE10
 
Ch10-Software Engineering 9
Ch10-Software Engineering 9Ch10-Software Engineering 9
Ch10-Software Engineering 9
 
Software Engineering
 Software Engineering  Software Engineering
Software Engineering
 
Ch5 system modeling
Ch5 system modelingCh5 system modeling
Ch5 system modeling
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)
 
Ch7-Software Engineering 9
Ch7-Software Engineering 9Ch7-Software Engineering 9
Ch7-Software Engineering 9
 
Chapter 4 software design
Chapter 4  software designChapter 4  software design
Chapter 4 software design
 
Depandability in Software Engineering SE16
Depandability in Software Engineering SE16Depandability in Software Engineering SE16
Depandability in Software Engineering SE16
 
Requirements modeling
Requirements modelingRequirements modeling
Requirements modeling
 
Ch6-Software Engineering 9
Ch6-Software Engineering 9Ch6-Software Engineering 9
Ch6-Software Engineering 9
 
Ch15-Software Engineering 9
Ch15-Software Engineering 9Ch15-Software Engineering 9
Ch15-Software Engineering 9
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
 
System Models in Software Engineering SE7
System Models in Software Engineering SE7System Models in Software Engineering SE7
System Models in Software Engineering SE7
 
Defect Testing in Software Engineering SE20
Defect Testing in Software Engineering SE20Defect Testing in Software Engineering SE20
Defect Testing in Software Engineering SE20
 
Socio Technical Systems in Software Engineering SE2
Socio Technical Systems in Software Engineering SE2Socio Technical Systems in Software Engineering SE2
Socio Technical Systems in Software Engineering SE2
 
Ch16-Software Engineering 9
Ch16-Software Engineering 9Ch16-Software Engineering 9
Ch16-Software Engineering 9
 
Ch20-Software Engineering 9
Ch20-Software Engineering 9Ch20-Software Engineering 9
Ch20-Software Engineering 9
 
10. Software testing overview
10. Software testing overview10. Software testing overview
10. Software testing overview
 
SE18_Lec 03_ RUP
SE18_Lec 03_ RUPSE18_Lec 03_ RUP
SE18_Lec 03_ RUP
 
Software engg. pressman_ch-8
Software engg. pressman_ch-8Software engg. pressman_ch-8
Software engg. pressman_ch-8
 

En vedette

En vedette (20)

SE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design PatternsSE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design Patterns
 
SE2_Lec 18_ Coding
SE2_Lec 18_ CodingSE2_Lec 18_ Coding
SE2_Lec 18_ Coding
 
SE2_Lec 16_ Software Design
SE2_Lec 16_ Software DesignSE2_Lec 16_ Software Design
SE2_Lec 16_ Software Design
 
Se2 lec 13 uml state machines
Se2 lec 13  uml state machinesSe2 lec 13  uml state machines
Se2 lec 13 uml state machines
 
DSP_FOEHU - Lec 02 - Frequency Domain Analysis of Signals and Systems
DSP_FOEHU - Lec 02 - Frequency Domain Analysis of Signals and SystemsDSP_FOEHU - Lec 02 - Frequency Domain Analysis of Signals and Systems
DSP_FOEHU - Lec 02 - Frequency Domain Analysis of Signals and Systems
 
SE2_Lec 15_ UML Activity Diagram
SE2_Lec 15_ UML Activity DiagramSE2_Lec 15_ UML Activity Diagram
SE2_Lec 15_ UML Activity Diagram
 
Dsp foehu lec 00 - digital signal processing
Dsp foehu   lec 00 - digital signal processingDsp foehu   lec 00 - digital signal processing
Dsp foehu lec 00 - digital signal processing
 
SE_Lec 00_ Software Engineering 1
SE_Lec 00_ Software Engineering 1SE_Lec 00_ Software Engineering 1
SE_Lec 00_ Software Engineering 1
 
DSP_FOEHU - Lec 05 - Frequency-Domain Representation of Discrete Time Signals
DSP_FOEHU - Lec 05 - Frequency-Domain Representation of Discrete Time SignalsDSP_FOEHU - Lec 05 - Frequency-Domain Representation of Discrete Time Signals
DSP_FOEHU - Lec 05 - Frequency-Domain Representation of Discrete Time Signals
 
Dsp foehu lec 01 - signals and systems
Dsp foehu   lec 01 - signals and systemsDsp foehu   lec 01 - signals and systems
Dsp foehu lec 01 - signals and systems
 
DSP 05 _ Sheet Five
DSP 05 _ Sheet FiveDSP 05 _ Sheet Five
DSP 05 _ Sheet Five
 
SE2_Lec 14_ Process Modeling and Data Flow Diagram
SE2_Lec 14_ Process Modeling and Data Flow DiagramSE2_Lec 14_ Process Modeling and Data Flow Diagram
SE2_Lec 14_ Process Modeling and Data Flow Diagram
 
DSP_FOEHU - Lec 04 - Discrete-Time Signals and Systems
DSP_FOEHU - Lec 04 - Discrete-Time Signals and SystemsDSP_FOEHU - Lec 04 - Discrete-Time Signals and Systems
DSP_FOEHU - Lec 04 - Discrete-Time Signals and Systems
 
SE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software DevelopmentSE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software Development
 
DSP_FOEHU - MATLAB 01 - Discrete Time Signals and Systems
DSP_FOEHU - MATLAB 01 - Discrete Time Signals and SystemsDSP_FOEHU - MATLAB 01 - Discrete Time Signals and Systems
DSP_FOEHU - MATLAB 01 - Discrete Time Signals and Systems
 
SE_Lec 10_ Software Code of Ethics
SE_Lec 10_ Software Code of EthicsSE_Lec 10_ Software Code of Ethics
SE_Lec 10_ Software Code of Ethics
 
SE_Lec 12_ Project Planning
SE_Lec 12_ Project PlanningSE_Lec 12_ Project Planning
SE_Lec 12_ Project Planning
 
DSP_FOEHU - MATLAB 02 - The Discrete-time Fourier Analysis
DSP_FOEHU - MATLAB 02 - The Discrete-time Fourier AnalysisDSP_FOEHU - MATLAB 02 - The Discrete-time Fourier Analysis
DSP_FOEHU - MATLAB 02 - The Discrete-time Fourier Analysis
 
Sheet Five – UML State Diagram
Sheet Five – UML State DiagramSheet Five – UML State Diagram
Sheet Five – UML State Diagram
 
SE_Lec 02_Software Life Cycle Models
SE_Lec 02_Software Life Cycle ModelsSE_Lec 02_Software Life Cycle Models
SE_Lec 02_Software Life Cycle Models
 

Similaire à SE2018_Lec 16_ Architectural Design

Topic1 Understanding Distributed Information Systems
Topic1 Understanding Distributed Information SystemsTopic1 Understanding Distributed Information Systems
Topic1 Understanding Distributed Information Systems
sanjoysanyal
 
Distributed Systems Architecture in Software Engineering SE11
Distributed Systems Architecture in Software Engineering SE11Distributed Systems Architecture in Software Engineering SE11
Distributed Systems Architecture in Software Engineering SE11
koolkampus
 
A Model of Local Area Network Based Application for Inter-office Communication
A Model of Local Area Network Based Application for Inter-office CommunicationA Model of Local Area Network Based Application for Inter-office Communication
A Model of Local Area Network Based Application for Inter-office Communication
theijes
 
A3: application-aware acceleration for wireless data networks
A3: application-aware acceleration for wireless data networksA3: application-aware acceleration for wireless data networks
A3: application-aware acceleration for wireless data networks
Zhenyun Zhuang
 
Running Head WINDOWS AND LINUX 1WINDOWS AND LINUX12.docx
Running Head WINDOWS AND LINUX     1WINDOWS AND LINUX12.docxRunning Head WINDOWS AND LINUX     1WINDOWS AND LINUX12.docx
Running Head WINDOWS AND LINUX 1WINDOWS AND LINUX12.docx
jeffsrosalyn
 

Similaire à SE2018_Lec 16_ Architectural Design (20)

Software Architecture Styles
Software Architecture StylesSoftware Architecture Styles
Software Architecture Styles
 
Software architecture unit 4
Software architecture unit 4Software architecture unit 4
Software architecture unit 4
 
Topic1 Understanding Distributed Information Systems
Topic1 Understanding Distributed Information SystemsTopic1 Understanding Distributed Information Systems
Topic1 Understanding Distributed Information Systems
 
5 architecture
5 architecture5 architecture
5 architecture
 
5-Architecture.ppt
5-Architecture.ppt5-Architecture.ppt
5-Architecture.ppt
 
Lec 4.ppt
Lec 4.pptLec 4.ppt
Lec 4.ppt
 
Distributed Systems Architecture in Software Engineering SE11
Distributed Systems Architecture in Software Engineering SE11Distributed Systems Architecture in Software Engineering SE11
Distributed Systems Architecture in Software Engineering SE11
 
Presentation on Behavioral Synthesis & SystemC
Presentation on Behavioral Synthesis & SystemCPresentation on Behavioral Synthesis & SystemC
Presentation on Behavioral Synthesis & SystemC
 
Chapter 01
Chapter 01Chapter 01
Chapter 01
 
Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering
 
Architectural patterns part 1
Architectural patterns part 1Architectural patterns part 1
Architectural patterns part 1
 
Unit 1_Operating system
Unit 1_Operating system Unit 1_Operating system
Unit 1_Operating system
 
Unified Modeling Language
Unified Modeling LanguageUnified Modeling Language
Unified Modeling Language
 
M azhar
M azharM azhar
M azhar
 
R12 d49656 gc10-apps dba 08
R12 d49656 gc10-apps dba 08R12 d49656 gc10-apps dba 08
R12 d49656 gc10-apps dba 08
 
Software Architecture in Architecture design .ppt
Software Architecture in Architecture design .pptSoftware Architecture in Architecture design .ppt
Software Architecture in Architecture design .ppt
 
Lecture-12-Architecture Design.pptx
Lecture-12-Architecture Design.pptxLecture-12-Architecture Design.pptx
Lecture-12-Architecture Design.pptx
 
A Model of Local Area Network Based Application for Inter-office Communication
A Model of Local Area Network Based Application for Inter-office CommunicationA Model of Local Area Network Based Application for Inter-office Communication
A Model of Local Area Network Based Application for Inter-office Communication
 
A3: application-aware acceleration for wireless data networks
A3: application-aware acceleration for wireless data networksA3: application-aware acceleration for wireless data networks
A3: application-aware acceleration for wireless data networks
 
Running Head WINDOWS AND LINUX 1WINDOWS AND LINUX12.docx
Running Head WINDOWS AND LINUX     1WINDOWS AND LINUX12.docxRunning Head WINDOWS AND LINUX     1WINDOWS AND LINUX12.docx
Running Head WINDOWS AND LINUX 1WINDOWS AND LINUX12.docx
 

Plus de Amr E. Mohamed

Plus de Amr E. Mohamed (20)

Dsp 2018 foehu - lec 10 - multi-rate digital signal processing
Dsp 2018 foehu - lec 10 - multi-rate digital signal processingDsp 2018 foehu - lec 10 - multi-rate digital signal processing
Dsp 2018 foehu - lec 10 - multi-rate digital signal processing
 
Dcs lec03 - z-analysis of discrete time control systems
Dcs   lec03 - z-analysis of discrete time control systemsDcs   lec03 - z-analysis of discrete time control systems
Dcs lec03 - z-analysis of discrete time control systems
 
Dcs lec02 - z-transform
Dcs   lec02 - z-transformDcs   lec02 - z-transform
Dcs lec02 - z-transform
 
Dcs lec01 - introduction to discrete-time control systems
Dcs   lec01 - introduction to discrete-time control systemsDcs   lec01 - introduction to discrete-time control systems
Dcs lec01 - introduction to discrete-time control systems
 
DDSP_2018_FOEHU - Lec 10 - Digital Signal Processing Applications
DDSP_2018_FOEHU - Lec 10 - Digital Signal Processing ApplicationsDDSP_2018_FOEHU - Lec 10 - Digital Signal Processing Applications
DDSP_2018_FOEHU - Lec 10 - Digital Signal Processing Applications
 
DSP_2018_FOEHU - Lec 07 - IIR Filter Design
DSP_2018_FOEHU - Lec 07 - IIR Filter DesignDSP_2018_FOEHU - Lec 07 - IIR Filter Design
DSP_2018_FOEHU - Lec 07 - IIR Filter Design
 
DSP_2018_FOEHU - Lec 06 - FIR Filter Design
DSP_2018_FOEHU - Lec 06 - FIR Filter DesignDSP_2018_FOEHU - Lec 06 - FIR Filter Design
DSP_2018_FOEHU - Lec 06 - FIR Filter Design
 
SE2018_Lec 17_ Coding
SE2018_Lec 17_ CodingSE2018_Lec 17_ Coding
SE2018_Lec 17_ Coding
 
SE2018_Lec-22_-Continuous-Integration-Tools
SE2018_Lec-22_-Continuous-Integration-ToolsSE2018_Lec-22_-Continuous-Integration-Tools
SE2018_Lec-22_-Continuous-Integration-Tools
 
SE2018_Lec 21_ Software Configuration Management (SCM)
SE2018_Lec 21_ Software Configuration Management (SCM)SE2018_Lec 21_ Software Configuration Management (SCM)
SE2018_Lec 21_ Software Configuration Management (SCM)
 
SE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design PatternsSE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design Patterns
 
Selenium - Introduction
Selenium - IntroductionSelenium - Introduction
Selenium - Introduction
 
SE2018_Lec 20_ Test-Driven Development (TDD)
SE2018_Lec 20_ Test-Driven Development (TDD)SE2018_Lec 20_ Test-Driven Development (TDD)
SE2018_Lec 20_ Test-Driven Development (TDD)
 
SE2018_Lec 19_ Software Testing
SE2018_Lec 19_ Software TestingSE2018_Lec 19_ Software Testing
SE2018_Lec 19_ Software Testing
 
DSP_2018_FOEHU - Lec 08 - The Discrete Fourier Transform
DSP_2018_FOEHU - Lec 08 - The Discrete Fourier TransformDSP_2018_FOEHU - Lec 08 - The Discrete Fourier Transform
DSP_2018_FOEHU - Lec 08 - The Discrete Fourier Transform
 
DSP_2018_FOEHU - Lec 05 - Digital Filters
DSP_2018_FOEHU - Lec 05 - Digital FiltersDSP_2018_FOEHU - Lec 05 - Digital Filters
DSP_2018_FOEHU - Lec 05 - Digital Filters
 
DSP_2018_FOEHU - Lec 04 - The z-Transform
DSP_2018_FOEHU - Lec 04 - The z-TransformDSP_2018_FOEHU - Lec 04 - The z-Transform
DSP_2018_FOEHU - Lec 04 - The z-Transform
 
DSP_2018_FOEHU - Lec 03 - Discrete-Time Signals and Systems
DSP_2018_FOEHU - Lec 03 - Discrete-Time Signals and SystemsDSP_2018_FOEHU - Lec 03 - Discrete-Time Signals and Systems
DSP_2018_FOEHU - Lec 03 - Discrete-Time Signals and Systems
 
DSP_2018_FOEHU - Lec 02 - Sampling of Continuous Time Signals
DSP_2018_FOEHU - Lec 02 - Sampling of Continuous Time SignalsDSP_2018_FOEHU - Lec 02 - Sampling of Continuous Time Signals
DSP_2018_FOEHU - Lec 02 - Sampling of Continuous Time Signals
 
SE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software DesignSE2018_Lec 15_ Software Design
SE2018_Lec 15_ Software Design
 

Dernier

Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night StandCall Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
amitlee9823
 
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
dollysharma2066
 
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoorTop Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
dharasingh5698
 
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
dharasingh5698
 
Integrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - NeometrixIntegrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - Neometrix
Neometrix_Engineering_Pvt_Ltd
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power Play
Epec Engineered Technologies
 
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
dharasingh5698
 
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak HamilCara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Kandungan 087776558899
 

Dernier (20)

Design For Accessibility: Getting it right from the start
Design For Accessibility: Getting it right from the startDesign For Accessibility: Getting it right from the start
Design For Accessibility: Getting it right from the start
 
Call Girls Wakad Call Me 7737669865 Budget Friendly No Advance Booking
Call Girls Wakad Call Me 7737669865 Budget Friendly No Advance BookingCall Girls Wakad Call Me 7737669865 Budget Friendly No Advance Booking
Call Girls Wakad Call Me 7737669865 Budget Friendly No Advance Booking
 
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
Hazard Identification (HAZID) vs. Hazard and Operability (HAZOP): A Comparati...
 
UNIT - IV - Air Compressors and its Performance
UNIT - IV - Air Compressors and its PerformanceUNIT - IV - Air Compressors and its Performance
UNIT - IV - Air Compressors and its Performance
 
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night StandCall Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
Call Girls In Bangalore ☎ 7737669865 🥵 Book Your One night Stand
 
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
VIP Model Call Girls Kothrud ( Pune ) Call ON 8005736733 Starting From 5K to ...
 
Double Revolving field theory-how the rotor develops torque
Double Revolving field theory-how the rotor develops torqueDouble Revolving field theory-how the rotor develops torque
Double Revolving field theory-how the rotor develops torque
 
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
FULL ENJOY Call Girls In Mahipalpur Delhi Contact Us 8377877756
 
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
(INDIRA) Call Girl Bhosari Call Now 8617697112 Bhosari Escorts 24x7
 
Unit 1 - Soil Classification and Compaction.pdf
Unit 1 - Soil Classification and Compaction.pdfUnit 1 - Soil Classification and Compaction.pdf
Unit 1 - Soil Classification and Compaction.pdf
 
KubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghlyKubeKraft presentation @CloudNativeHooghly
KubeKraft presentation @CloudNativeHooghly
 
2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects2016EF22_0 solar project report rooftop projects
2016EF22_0 solar project report rooftop projects
 
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoorTop Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
Top Rated Call Girls In chittoor 📱 {7001035870} VIP Escorts chittoor
 
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Ankleshwar 7001035870 Whatsapp Number, 24/07 Booking
 
Integrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - NeometrixIntegrated Test Rig For HTFE-25 - Neometrix
Integrated Test Rig For HTFE-25 - Neometrix
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power Play
 
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 BookingVIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
VIP Call Girls Palanpur 7001035870 Whatsapp Number, 24/07 Booking
 
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak HamilCara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
Cara Menggugurkan Sperma Yang Masuk Rahim Biyar Tidak Hamil
 
Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086Minimum and Maximum Modes of microprocessor 8086
Minimum and Maximum Modes of microprocessor 8086
 
Navigating Complexity: The Role of Trusted Partners and VIAS3D in Dassault Sy...
Navigating Complexity: The Role of Trusted Partners and VIAS3D in Dassault Sy...Navigating Complexity: The Role of Trusted Partners and VIAS3D in Dassault Sy...
Navigating Complexity: The Role of Trusted Partners and VIAS3D in Dassault Sy...
 

SE2018_Lec 16_ Architectural Design

  • 2. 2  The software architecture of a program or computing system is the structure (or structures) of the system, including:  Dividing software into subsystems.  Deciding how these will interact.  Determining their interfaces. • The architecture is the core of the design, so all software engineers need to understand it. • The architecture will often constrain the overall efficiency, reusability and maintainability of the system
  • 3. 3  Why you need to develop an architectural model:  To enable everyone to better understand the system  To allow people to work on individual pieces of the system in isolation  To prepare for extension of the system  To facilitate reuse and reusability
  • 4. 4  An architecture is an abstraction of a system that suppresses details of components that do not affect how they:  Use other components  Are used by other components  Relate to other components  Interact with other components
  • 5. 5  To ensure the maintainability and reliability of a system, an architectural model must be designed to be stable.  Being stable means that the new features can be easily added with only small changes to the architecture.
  • 6. 6 aTruck aShip aAirplane theWarehouseCollecti on theVehicleCollection UML-A Generated Dependency Class:theRouter Dependency (1.0) theStorage aVehicle UML-A Generated Dependency Class:theRouter Dependency (0.5) availableVehicleCollection UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated As sociationC lass:theVehicleC ollec tion Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati onCl ass:theVehi cleCollection Generali zation (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0) UML-A Generated Dependency Class:theRouter Dependency (1.0) availableGoods aPort aPortC ollec tion aSurplus aDifficiency theTimeNeeded theGoods UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:availableGoods Association (0.5) aRouteCollection UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25) UML-A Generated Association Class:aRoute Association (0.25) UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0) UML-A Generated Dependency Class:theRouter Dependency (1.0) theAWT aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog aWarehouse UML-A Generated AssUML-A Generated Association Class:aDifficiency Associ UML-A Generated Association Class:aDifficiency AssociatioUML-A Generated Association Class:aDifficiency Association (1.0 UML-A Generated Association Class:aDifficiency AU ML-A Generated AssociationClaUML-A Generated AssociatioUML-A Generated Association Class:aDifficieU ML-A Generated AssociationClass:aDUML-A Generat UML-A GeneraUML-A Generated As aLocation UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:aNavPoint Association (0.5) UML-A Generated Association Class:aNavPoint Association (0.5) UML-A Generated Association Class:aNavPoint Association (0.5) UML-A Generated Association Class:aWarehouse Association (0.5) aNavPoint UML-A Generated Association Class:aWarehouse Association (1.0) UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:aWarehouse Association (0.5) UML-A Generated Association Class:aRoute Association (0.5) aRoute UML-A Generated Dependency C lass :aRouteCol lection Ass ociation (0.25) UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (0.5) UML-A Generated Association Class:aWarehouse Association (1.0) UML-A Generated Dependency Class:aRouteCollection Association (0.5) UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1 UML-A Generated Association Class:aNavPoint Association (0.25) UML-A Generated Association Class:aNavPoint Association (0.25) UML-A Generated Association Class:aNavPoint Association (0.25) UML-A Generated Dependency Class:theRouter Association (0.25) UML-A Generated Association Class:aNavPoint Association (0.25) theCargoRouter UML-A Generated As sociationC lass:theWarehouseCollection Dependency ( 0.25) UML-A Generated Association Class:theRouter Association (0.25) UML-A Generated Association Class:theRouter A theRouter UML-A Generated Association Class:theWarehouseCollection Dependency (0.5) UML-A Generated Dependency Class :aRoUML-A Generated Association Clas s:theWarehouseC UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5) UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0) UML-A Generated Dependency Class:theRouter Association (0.25) UML-A Generated Dependency Class:theRouter Association (0.5) UML-A Generated Dependency Class:theRouter Association (1.0) UML-A Generated Dependency Class:theRouter Association (0.5) UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0) UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0) This is a simple software system!
  • 7. 7
  • 8. 8 Independent Components Communicating Processes Event Systems Client/Server Peer-to-Peer Implicit Invocation Explicit Invocation Data Flow Batch Sequential Pipe & Filter Virtual Machine Interpreter Rule-Based System Data-Centered Repository Blackboard Call and Return Main Program and Subroutine Object OrientedLayered Remote Procedure Call
  • 9. 9 Shared Data Client A Client B Client C Client D Client E Client F
  • 10. 10  Has goal of achieving the quality of integrability of data.  The term refers to systems in which the access and update of a widely accessed data store is their primary goal.  Basically, it is nothing more than a centralized data store that communicates with a number of clients.  Important for this styles are three protocols: communication, data definition and data manipulation protocol  A client runs on an independent thread of control.  The means of communication distinguishes the two subtypes: repository and blackboard  Repository: a client sends a request to the system to perform a necessary action (e.g. insert data)  Blackboard: the system sends notification and data to subscribers when data of interest changes, and is thus active
  • 11. 11  Ensures data integrity  Reliable, secure, easy to Backup, testability guaranteed  Clients independent on the system: performance and usability on the client side is good  Problems with scalability  Solutions: shared repositories, replication but this increases complexity
  • 12. 12  One of the most well-known examples of the data- centered architecture, is a database architecture  E.g. in RDBMS a set of related tables with fields, data types, keys, ...  Clients use data manipulation protocol to work with the data  E.g. SQL for inserting, selecting, deleting data, ...  Depending on where clients are situated communication protocol might be  An inner-process communication  Communication between components on the same machine  Communication over network, e.g. LAN, Internet, etc.
  • 13. 13  Has the goal of achieving the quality of reuse and modifiability.  The data-flow style is characterized by viewing the system as a series of transformations on successive pieces of input data.  Data enter the system and then flows through the components one at a time until  Finally, the data is assigned to some final destination (output or a data store).  The architecture is very flexible.  Almost all the components could be removed.  Components could be replaced.  New components could be inserted.  Certain components could be reordered.
  • 15. 15  Batch sequential style  The processing steps are independent components  Each step runs to completion before the next step begins  Pipe-and-filter style  Emphasizes the incremental transformation of data by successive components  The filters incrementally transform the data (entering and exiting via streams)  The pipes are stateless and simply exist to move data between filters  Note That: It is easily made into a parallel or distributed execution in order to enhance system performance
  • 16. 16  Data flows through pipes: communication channels between filters  Processing units: filters  Filters do not know anything about other filters  Modularity, maintainability is good  Data flows in streams: good for processing of images, audio, video, ...  Depending on where the filters reside different execution architectures  E.g. same process: filters run within threads  E.g. same machine: filters run within own processes  E.g. network: pipes use the networking architecture
  • 17. 17  Pipe and Filter Example:  Traditional Compilers: Compilation phases are pipelined, though the phases are not always incremental. The phases in the pipeline include • lexical analysis + parsing + semantic analysis + code generation
  • 18. 18 Main module Subroutine A Subroutine B Subroutine A-1 Subroutine A-2 Physical layer Data layer Network layer Transport layer Application layer Class WClass V Class X Class Z Class Y
  • 19. 19  Has the goal of modifiability and scalability  Has been the dominant architecture since the start of software development  Main program and subroutine style  Decomposes a program hierarchically into small pieces (i.e., modules)  Typically has a single thread of control that travels through various components in the hierarchy  Remote procedure call style  Consists of main program and subroutine style of system that is decomposed into parts that are resident on computers connected via a network  Strives to increase performance by distributing the computations and taking advantage of multiple processors  Incurs a finite communication time between subroutine call and response.
  • 20. 20  Object-oriented or abstract data type system  Emphasizes the bundling of data and how to manipulate and access data  Keeps the internal data representation hidden and allows access to the object only through provided operations  Permits inheritance and polymorphism  Layered system  Assigns components to layers in order to control inter- component interaction  Only allows a layer to communicate with its immediate neighbor
  • 21. 21  Layering: the structure of the system is organized into set of layers  Each layer in on the top of another layer, each layer communicates only with the layer immediately below it.  The higher layer sees the lower layer as a set of services.  Well-defined interfaces between layers  Reduces complexity,  improves modularity,  reusability,  maintainability
  • 22. 22  Typically organized into layers  Successive layers provide more sophisticated services to the layers above them  Hardware services, kernel services, system services, UI services
  • 23. 23  A virtual machine implements an instruction set for an imaginary machine  Often virtual machines are the underplaying mechanism by which a programming language is executed  E.g. Java virtual machine, different interpreters • Specifies an interface between compiler and a real machine  From conceptual point of view very similar to OS  Improves portability
  • 24. 24  A common example of layered architecture is a network protocol stack  E.g. TCP/IP protocol stack - Four layers  The lowest layer: handles communication between two computers  The internet layer: handles routing of packets across the network  The transport layer: guarantees that packets are error- free and received in the same order as sent  The application layer: supports application-specific protocols • E.g. HTTP, SMTP, FTP, ...
  • 25. 25
  • 26. 26  Basic concept:  The client uses a service  The server provides a service  Typically connected via a network  Clients are independent from each other  There is at least one component that has the role of client, initiating connections in order to obtain some service.
  • 27. 27  Conceptually simple  Clear separation of responsibilities, help testability  Good scalability (if stateless)  Excellent scalability (if server can be scaled out)  Good for security, as data can be held at the server with restricted access  Risk of bad performance, if the communication between client and server is slow, or has a high latency  Need to develop/agree on a protocol between client and server  For stateful, centralized servers scalability is limited
  • 28. 28  The server is no longer in the organizations network, but somewhere in the Internet  Example: cloud services by Salesforce, Google, Microsoft  Scalability, security, reliability is expected to be handled by a specialized team  Needs a working Internet connection
  • 29. 29  Separation between client and server is removed  Each client is a server at the same time, called peer  The goal is to distribute the processing or data among many peers  No central administration or coordination 29
  • 30. 30  Example: Skype uses a peer-to-peer protocol, but also uses super-nodes and a central login servers  Adv.  Good for scalability  Good for reliability, as data can be replicated over peer  No single point of failure  Disadv.  Quality of service is not deterministic, cannot be guaranteed  Very complex, hard to maintain and test
  • 31. 31  The N-tier architecture is the modern client-server architecture  Originated with business applications  Through the popularity of the Web today typically related with Web applications  Conceptually separate architecture into:  Presentation,  Application, and  Data storage layers.
  • 32. 32  Clients are typically rich (ui + app-logic + communication)  Servers store data  Each client runs a complete application  Drawbacks: each client has to know how to communicate with all data servers  Scalability is compromised because client are tightly coupled with servers
  • 33. 33  Evolved from 2-tier architectures to solve their drawbacks  A third tier is inserted between clients and data servers  Application or business logic tier: middle tier.  Typically middle tier is on the server side (but recently might be split between the server and the client)  Scalability improved because clients are thinner.  Thin clients have no knowledge on application  A rich client contains full knowledge of application
  • 34. 34  Suitable for applications in which a central issue is identifying and protecting related bodies of data.  Data representations and their associated operations are encapsulated in an abstract data type.  Components: are objects.  Connectors: are function and procedure invocations (methods).
  • 35. 35  Object-Oriented Invariants  The data representation is hidden from other objects.  Advantages  it is possible to change the implementation without affecting those clients.  Can design systems as collections of autonomous interacting agents.  Disadvantages  In order for one object to interact with another object (via a method invocation) the first object must know the identity of the second object  Objects cause side effect problems: • E.g., A and B both use object C, then B’s effects on C look like unexpected side effects to A.
  • 36. 36
  • 37. 37  Suitable for applications that involve loosely-coupled collection of components, each of which carries out some operation and may in the process enable other operations.  Instead of invoking a procedure directly ...  A component can announce (or broadcast) one or more events.  Other components in the system can register an interest in an event by associating a procedure with the event.  When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event.
  • 38. 38  Advantages:  Provides strong support for reuse.  Eases system evolution  Disadvantages:  When a component announces an event: • it has no idea what other components will respond to it, • it cannot rely on the order in which the responses are invoked • it cannot know when responses are finished  Twitter, Google+
  • 39. 39  Remote invocation architectures involve distributed processing components  Typically, a client component invokes a method (function) on a remote component  E.g. Web services  Advantages:  increased performance through distributed computation  Disadvantages:  tightly coupling of components  increases communication overhead
  • 40. 40  Transparently distribute aspects of the software system to different nodes  An object can call methods of another object without knowing that this object is remotely located.
  • 41. 41  Systems are seldom built from a single architectural style  Three kinds of heterogeneity:  Locationally heterogeneous • The drawing of the architecture reveals different styles in different areas (e.g., a branch of a call-and-return system may have a shared repository)  Hierarchically heterogeneous • A component of one style, when decomposed, is structured according to the rules of a different style  Simultaneously heterogeneous • Two or more architectural styles may both be appropriate descriptions for the style used by a computer-based system
  • 43. 43  Are concerned with the control flow between sub- systems.  Centralized control  One sub-system has overall responsibility for control and starts and stops other sub-systems  Event-based control  Each sub-system can respond to externally generated events from other sub-systems or the system’s environment
  • 44. 44  A control sub-system takes responsibility for managing the execution of other sub-systems  Call-return model  Top-down subroutine model  Control starts at the top of a subroutine hierarchy and moves downwards.  Applicable to sequential systems  Manager model  One system component controls the stopping, starting and coordination of other system processes.  Applicable to concurrent systems.
  • 45. 45 Routine 1.2Routine 1.1 Routine 3.2Routine 3.1 Routine 2 Routine 3Routine 1 Main program
  • 47. 47  Driven by externally generated events where the timing of the event is outside the control of the sub- systems which process the event  Two principal event-driven models:  Broadcast models. An event is broadcast to all sub- systems. Any sub-system which can handle the event may do so  Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing
  • 48. 48 Sub-system 1 Event and message handler Sub-system 2 Sub-system 3 Sub-system 4
  • 50. 50