Architectural Blueprints-The, P Kruchten

Tags: COMPUTER SCIENCE, WATERLOO, COMPUTER SCIENCE Process View, Software Architecture, processes, Architectural Model, development concerns, Philippe Kruchten WATERLOO CHERITON SCHOOL OF COMPUTER SCIENCE CS, View Model, Architectural Model Definition, abstract data types, nonfunctional requirements, Process View, software modules, COMPUTER SCIENCE Development, COMPUTER SCIENCE Development View, development architecture, CHERITON SCHOOL, View Model Model a model, Logical View, object oriented analysis
Content: IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint "The 4+1 View Model of Software Architecture"
by Philippe Kruchten
WATERLOO CHERITON SCHOOL OF Computer Science
CS 446/646 ECE452 May 30th, 2011
Architectural Model Definition[1] Software architecture = {Elements, Forms, Constraints} Definition [2] "deals with the design and implementation of the highlevel structure of the software.
It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and .... nonfunctional requirements"
[1] D. E. Perry & A. L. Wolf, "Foundations for the Study of Software Architecture," ACM Software Engineering Notes, 17, 4, October 1992, 40-52
[2] P. B. Kruchten. The 4+1 View Model of architecture. IEEE Software, 12(6), Nov. 1995, pp. 42­50.
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
2
COMPUTER SCIENCE
Is this an Architectural Model?
Owners End-Users Sale reps
Software/ System
Managers Designers Developers
Deployment
Build
Test
engineers engineers engineers
Software/System stakeholders Model
What is going on here?
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
3
COMPUTER SCIENCE
Desired Attributes Addresses & captures concerns of various stakeholders ­ stakeholders: end-users, developers, system engineers, Project Management testers, support teams requirements ­ functional ­ non-functional performance, availability, concurrency, distribution, fault tolerance, security, testing, usability, Configuration Management, evolution, monitoring
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
4
COMPUTER SCIENCE
Desired Attributes An abstraction represents the high level view Is robust adaptable scalable iterative Meaningful & maintainable has to be a live document ­ changes with the system
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
5
COMPUTER SCIENCE
Types of Architectural Styles Box & line model Architectural definition language (ADL) View based models 4+1 view model (1995)
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
6
COMPUTER SCIENCE
4+1 View Model Model a model is composed of 5 views ­ a single view is not enough View is catered for a set of corresponding stakeholders ­ addresses the concerns of its stakeholders contains view elements ­ components, connectors, notation generic representation
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
7
COMPUTER SCIENCE
4+1 View Model
Logical View Process View
Scenario View
Development View Physical View
Perhaps it should have been called 1+4 View Model
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
8
COMPUTER SCIENCE
Logical View Intent 'object model' of the design is generally the starting point addresses primarily functional requirements decomposition into 'architectural entities' Style abstract Data Types / OO Stakeholders end-users, architects, designers
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
9
COMPUTER SCIENCE
Logical View View representations 1. OOA (object oriented analysis) ­ entities are analysis classes ­ application of OOA principles abstraction, encapsulation. inheritance association (aggregation, composition) ­ class diagrams, state diagrams 2. data centric analysis ­ entity relationship (ER) diagrams
which is the correct view representation?
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
10
COMPUTER SCIENCE
Example Logical View
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
11
COMPUTER SCIENCE
Logical View design guidelines a single (object) model across the system (why?) avoid premature specialization (of what?) UML diagrams ­ class, communication, sequence diagrams
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
12
COMPUTER SCIENCE
Process View Intent handles the non-functional requirements abstraction of architectural processes
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
13
COMPUTER SCIENCE
Process View Architectural Process grouping of tasks into executable units ­ task: thread of control task hierarchy: major & minor tasks ­ reflects task scope types: atomic & distributed can be replicated ­ to improve performance, availability etc. execute on 'process nodes' (what is a process node?)
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
14
COMPUTER SCIENCE
Process View Communication messaging (synchronous, asynchronous, RPC, broadcast) ­ usually for major tasks shared memory ­ for minor tasks can we estimate the system load form the inter-process communication?
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
15
COMPUTER SCIENCE
Process View Style several styles are applicable ­ pipes & filters ­ layered client / server Stakeholders integrators, architects
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
16
COMPUTER SCIENCE
Example Process View
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
17
COMPUTER SCIENCE
Development View Intent software/system decomposition into software modules software modules ­ name space, packages, libraries, subsystems ­ modules are scoped for small (development) teams Driven by internal requirements
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
18
COMPUTER SCIENCE
Development View
Intent
software/system decomposition into software modules
software modules ­ name space, packages, libraries, subsystems ­ modules are scoped for small (development) teams Driven by internal requirements
management technology resources
cost evaluation
requirement allocation
progress monitoring
management reuse

WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
19
COMPUTER SCIENCE
Development View Style layered style ­ each layer with well defined interface ­ subsystem dependencies on other subsystems in the same layer or lower ­ each layer provides a development abstraction (responsibility) Stakeholders managers, architects, designers, developers, testers
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
20
COMPUTER SCIENCE
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
21
COMPUTER SCIENCE
Development View Observations "complete development architecture can only be described when all the elements of the software have been identified." [1] So what things can we define here?
[1] P. B. Kruchten. The 4+1 View Model of architecture. IEEE Software, 12(6), Nov. 1995, pp. 42­50.
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
22
COMPUTER SCIENCE
Development View Observations "complete development architecture can only be described when all the elements of the software have been identified." [1] So what things can we define here?
code partitioning inter-partition dependencies
module visibility development methodology
work allocation
[1] P. B. Kruchten. The 4+1 View Model of architecture. IEEE Software, 12(6), Nov. 1995, pp. 42­50.
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
23
COMPUTER SCIENCE
Physical View Intent physical manifestation of process view ­ processes are mapped to processing nodes Concerns installation, configuration, deployment & delivery, networking, messaging protocols Stakeholders system engineers, installers, architects, operators
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
24
COMPUTER SCIENCE
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
25
COMPUTER SCIENCE
Physical View Design guidelines mapping to be flexible minimal impact on source code same concerns as process view UML deployment diagram
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
26
COMPUTER SCIENCE
Scenario View Intent "one view to rule them all" capture system functionality in scenarios ­ interaction of objects & processes ­ driven by important scenarios provides architecture validation Stakeholders all stakeholders from the other views
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
27
COMPUTER SCIENCE
Example Scenario View
Components from the logical view Connectors from the process view looks like a collaboration diagrams. what happened to use case diagram?
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
28
COMPUTER SCIENCE
Example Scenario View
Components from the logical view Connectors from the process view
looks like a collaboration diagrams. what happened to use case diagram? use cases & use case realization
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
29
COMPUTER SCIENCE
View Mappings
Logical View Process View
Scenario View
Development View Physical View
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
30
COMPUTER SCIENCE
Logical to Process View Objects are mapped to processes considerations ­ autonomy ­ persistence ­ subordination ­ distribution Strategy inside-out: identify processes for objects outside-in: identify processes (based on system requests) and then allocate objects to these processes
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
31
COMPUTER SCIENCE
Logical to Development View Architectural component decomposition architectural entities are broken down into design components ­ packages, modules ­ classes mapping is governed by development concerns 'distance' between logical and design view ­ an indication of the size of the system
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
32
COMPUTER SCIENCE
Process to Physical View Processes assignment to hardware major and minor tasks are assigned to physical machines various configurations ­ development ­ testing ­ deployment
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
33
COMPUTER SCIENCE
Model an iterative process
Start with a model
In each iteration the architecture is
prototyped
tested: under load if possible
measured & analyzed
refined
­ add more scenarios
­ detect abstractions and optimizations
goal:
­ each iteration should takes us a step closer to a stable architecture
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
34
COMPUTER SCIENCE
Comments Lacks some fundamental views security, user interface, testing upgrade, disaster recovery Are the views ever complete? Change in architectural style? data centric to OO architecture
WATERLOO CHERITON SCHOOL OF
CS446/646 ECE452
35
COMPUTER SCIENCE

P Kruchten

File: architectural-blueprints-the.pdf
Author: P Kruchten
Author: Atif Khan
Published: Mon May 30 07:35:53 2011
Pages: 35
File size: 0.93 Mb


Explorations in Australia, 292 pages, 1.09 Mb

, pages, 0 Mb

The Works, 80 pages, 2.05 Mb

, pages, 0 Mb

Belgium's Energy Market, 14 pages, 0.1 Mb
Copyright © 2018 doc.uments.com