18 documenting 4 plus one notes 3 .pdf

File information


Original filename: 18-documenting-4-plus-one-notes-3.pdf
Title: 18-documenting-4-plus-one-notes-3.ppt
Author: Alf Inge Wang

This PDF 1.3 document has been generated by PowerPoint / Mac OS X 10.9.5 Quartz PDFContext, and has been sent on pdf-archive.com on 23/02/2015 at 12:18, from IP address 78.91.x.x. The current document download page has been viewed 677 times.
File size: 2 MB (7 pages).
Privacy: public file


Download original PDF file


18-documenting-4-plus-one-notes-3.pdf (PDF, 2 MB)


Share on social networks



Link to this file download page



Document preview


Documenting Software Architecture
4+1 view model continue…

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 35 -

4+1 View model

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 36 -

The Physical View: System engineers
√  Focus on non-functional requirements:
–  Availability (Reliability), Performance (Scalability).

√  Software executes on a network
of processing nodes.
–  Networks, processes, tasks and
objects need to be mapped onto nodes.

√  Usual with different physical
configurations:
–  In development phase, in deployment
phase for various sites and customers.
–  Architecture must be highly flexible and minimal impact on source
code.
TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 37 -

Notation for Physical view (UML)
*
Package1

Package

-End1
-End2

Communication

*

Component1

Component

1

-End3
-End4

Composition

*

ComponentInstance1

Node1

TDT4240 Software Architecture,

Component
Instance

Dependence

Node

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 38 -

Notation for Physical View

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 39 -

Example: Physical View of Phone
control

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 40 -

Example (UNAS): Process View mapped on
Physical View of Phone control

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 41 -

Example (UML): Process View mapped
on Physical View of Phone control
C
C

Central

*

F

*

-End17
-End19

F

-End18

F

*

**

Psaudo Central

-End2
-End1

**

Conversation

**

Terminal

-End5
-End7

*

K

K

-End6

K
*

Controller

-End8

*

-End11

*

-End13

*

-End12

*

-End14

Line card

-End10

Controller

Controller

*

Line card

-End9

K

K

*

-End4
-End3

**

Terminal

K

-End2
-End1

Conversation

-End3
-End4

**

TDT4240 Software Architecture,

-End20

F
Psaudo Central

*

*

-End15

-End16

Line card

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 42 -

Scenarios
√  Four views can work together by the use of small set
of scenarios.
√  The scenarios are an abstraction
of most important requirements.
√  Diagrams: Use case / interaction.
√  Scenario view is an add-on,
and serves two main purposes:
–  Driver to discover the architectural
elements during architecture design.
–  Validation and illustration role when
architecture design is complete.
TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 45 -

Example: Scenario view of Phone
control

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 46 -

Example (UML): Scenario view of
Phone control

Joe: Controller

Numbering plan

Joe: Terminal

Conversation

(1) Off-hook
(2) Dial tone
(3) Digit
(4) Digit
(5) Open conversation

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 47 -

Going from one view to another

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 48 -

From the logical to the process view
√  Identify several important characteristics of classes:
– 
– 
– 
– 

Autonomy: Are the objects active, passive, protected?
Persistence: Are the objects transient, permanent?
Subordination: Do an object depend on another object?
Distribution: Are the state or operations of an object
accessible from many nodes in the physical architecture?

√  In logical view: Consider an object as active and
concurrent.
√  In process view: Must determine the “right” amount
of concurrency and define the set of processes needed.

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 49 -

II: From the Logical to the Process View
√ 

√ 

Inside-out:
1.  Define agent tasks which multiplex a single thread of control across
multiple active objects of a class.
2.  Subordinated object to active objects are executed on the same
agent.
3.  Mutual exclusive or light-weight classes share a single agent.
4.  Continue clustering until reasonably small number of processes that
allows distribution and use of physical resources.

Outside-in:
1. 
2. 
3. 
4. 

Identify external stimuli (requests) to the system.
Define client processes to handle the stimuli.
Define server processes that only provide services.
Use data integrity and serialization constraints of the problem to
define the right set of servers.
5.  Allocate objects to the client and server agents.
6.  Identify which objects must be distributed.

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 50 -

Example: From Logical to Process View

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 51 -

From Logical to Development View
√  A Class is usually implemented as a package.
√  Large classes are decomposed into multiple packages.
√  Collections of closely related classes are grouped into
subsystems.
√  Constraints considerations that distinguish the logical
from implementation views:
– 
– 
– 
– 
– 
– 

Team organization.
Expected magnitude of code.
Degree of expected reuse and commonality.
Strict layering principles.
Release policy.
Configuration management.

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 52 -

From Process to Physical View

√  Processes and process
groups are mapped onto
available physical
hardware.
√  Must consider various
configurations for
testing or deployment.

TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 53 -

Process for Architecture Design:
A scenario-driven approach:
√  Start:
– 
– 
– 
– 
– 

Choose small number of scenarios based on risk and criticality.
Create a strawman architecture.
Describe the architectural elements discovered in four views.
Implement, test and measure architecture prototype.
Capture lessons learned.

√  Loop: Start by reassessing risk, adding scenarios.
– 
– 
– 
– 
– 

Discover additional architectural elements or architectural changes.
Update 4 views: Logical, process, development, physical.
Revise existing scenarios based on changes.
Upgrade, test and measure architecture prototype.
Review/revise five views.

–  Design guidelines and rationale are updated.
–  Capture the lessons learned.

√  End loop
TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 54 -

4+1 View Model Summary
View

Logical

Process

Development

Physical

Scenarios

Components

Class

Task

Module,
Subsystem

Node

Connectors

Association,
inheritance,
containment

Redez-vous,
Message,
Broadcast, RPC,
etc.

Compilation
dependency,
“with” clause,
“include”

Communication
medium, LAN,
WAN, bus etc.

Containers

Class category

Process

Subsystem
(library)

Physical
subsystem

Web

Stakeholders

End-user

System designer,
integrator

Developer,
manager

System designer

End-user,
developer

Concerns

Functionality

Performance,
availability, SW
fault-tolerance,
integrity

Organization,
reuse, portability,
line-of-product

Scalability,
performance,
availability

Understandability

TDT4240 Software Architecture,

Step, Scripts

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 55 -

Conclusion
√  Quality attribute of non-trivial systems are
determined by its architecture.
√  Software architecture is
a vehicle for communication
among the stakeholders.
√  Architecture can be
described through
several views.
√  Views represent the position
from where stakeholders
see the architecture.
TDT4240 Software Architecture,

www.idi.ntnu.no/emner/tdt4240 Email: alfw@idi.ntnu.no Slide - 56 -


Related documents


18 documenting 4 plus one notes 3
18 documenting 4 plus one notes 1
18 documenting 4 plus one notes 2
06032351
changelog soen344 team3
05734242

Link to this page


Permanent link

Use the permanent link to the download page to share your document on Facebook, Twitter, LinkedIn, or directly with a contact by e-Mail, Messenger, Whatsapp, Line..

Short link

Use the short link to share your document on Twitter or by text message (SMS)

HTML Code

Copy the following HTML code to share your document on a Website or Blog

QR Code

QR Code link to PDF file 18-documenting-4-plus-one-notes-3.pdf