Architectural Requirements Phase

prunelimitNetworking and Communications

Oct 23, 2013 (3 years and 11 months ago)

76 views

Architectural Requirements

Phase

See
Sommerville


Chapters 11, 12, 13, 14, 18.2

1

Architectural Requirements Phase


S
oftware requirements concerned
construction of a
logical model



Architectural requirements concern
construction of a
physical model



Architecture


bible
” : M. Shaw & D.
Garlan
,


Software
Architecture
,
Prentice

Hall, 1996.





2

Architectural Design Concerns


physical system partitioning


allocation of tasks to components


h
igh cohesion and low coupling = good / robust


l
ow cohesion and high coupling = bad / fragile


high cohesion

(high element dependence inside
components)


low coupling

(low component interdependence, so design
is robust against change)


component interface design


component reuse


choice of architecture to meet performance and other non
-
functional requirements


problem solution by divide and conquer

3

Architecture Design Process

Mostly, we will instantiate a well known
global


architecture
, as well as
sub
-
architectures
and


design patterns




… by
top
-
down refinement



all the way down to
unit level
.

4

Architecture Selection Criteria

(1)
Is there a generic architecture or pattern that
can be a
template

for the system or
component? (Otherwise ad
-
hoc.)

(2)
How will the system be
distributed

across
hardware to achieve performance, security,
reliability etc?

(3)
Which generic architectures provide different
alternatives, and what are the tradeoffs?
(
t
radeoff analysis
)

5

Architecture Selection (cont.)

(4) How can each component be
decomposed

into
sub
-
components


(divide
-
and
-
conquer,
maximise

reuse, cohesion vs. coupling)

(5) How to implement
control

and co
-
operation

(6) How to
evaluate

the design? (predict
performance?)

(7) How to
document

the design (static, dynamic,
UML?) especially
component interfaces
so that
coders can
work to an interface specification
.

6

System Models

Documentation depends on which kinds of


system models
we use:


(1)
Static structural model (class or package diagram)

(2)
Dynamic process model


run time behavior
(sequence diagram,
statechart
)

(3)
Interface model (class diagram, OCL, JML)

(4)
Relationship model (data flow diagram)

(5)
Distribution model


across hardware (package
diagram)

(6)
Testing model


define integration tests (
JUnit
,
JBehave
, TTCN)

7

Architecture

1:
Client
-
Server



Client

Server


service1()

service2()



serviceN
()

*

*

requester

provider

Request

for service
using

RPC or CORBA, Java RMI,

HTTP, etc.

8

Architecture

2:
Three
-
Tier

Database

Architecture



1. Storage layer

2. Application logic layer

3. Interface layer

Interface layer
: objects dealing with user, windows, forms,

Web pages, etc

Application logic layer
: control and entity objects for processing,

Rule checking and notification

Storage layer
: implements storage, retrieval and query of persistent

objects

9

Architecture

3:
Four
-
Tier

Database

Architecture



1. Storage layer

2. Application logic layer

3. Presentation Server

4. Presentation Client

Interface

l
ayer

of 3
-
tiered

Presentation Client sits on user machine.

Presentation Server sits on server machine

Different kinds of clients and servers possible

Compare with MVC!

10

1. SQL Query

2. DB Connection

3. Server Side Form

4. WebBrowser

Interface

layer

Possible Instantiation of 4 tiers

11

Architecture 4: Layered


S
ubsystems
hierarchically
organized
, each


layer (1) depending only on layer below, (2)


supplying services to layers
above

(iterated client
-
server?)

12

1. Physical (thinnet, thicknet, UTP)

2. Data Link (Ethernet)

3. Network (IP)

4. Transport (TCP, UDP)

5. Session (RPC)

6. Presentation (XDR)

7. Application (mail, telnet, ftp )

Hardware

level

Possible Instantiation

ISO/OSI 7

layer communication hierarchy


13

Architecture 5:
Data
Centered


Centralise

around a large data collection,


aka
repository

App1

App2

App3

14

Architecture 6 :
Independent
components


E
xecuting
in parallel, with communication,

aka
object
-
oriented architectures
.

e.g. simple OOP, peer to peer (2
-
way client
-

server
)

15

Architecture 7:
Model
-
View
-
Controller

(MVC)

An
architectural

model

that
solves

many


user

interface (UI) problems,
e.g
.


shared

data,


multiple
users
,


different
views

of the same data,


updating

information
across

all
users
,


changes

to
underlying

data,


changes

to
representation,


c
hanging

UI technology.

16

Model

coreData

setOfObservers


attach(Observer
)

detach(Observer
)

notify
()

getData
()

modifyData
()

MyView

viewData



initialize
()

displayData
()

update
()

MyController

viewData



initialize
()

changeData
()

update
()

depends on

updates

*

*

1

1

1

1

updates

17

Architecture 8:
Data Flow

Data flows between static functional


elements which
transform

it, aka
pipeline


architecture
e.g. compiler

C code

parse

tree

assembler

Machine

code

procedure

calls

assembler

Parse

Translate

Library

Link &

Assemble

Design
Patterns


Are the answer to a question that commonly


arises “
How can I … ?”


Patterns record
successful solutions

in software
development for sharing between projects.


Gang of Four

(
GoF
) Gamma, Helm, Johnson,
Vlissides
,
-

founders of movement.


Gamma et al,
Design Patterns: Elements of Reusable
Object
-
Oriented Software
, Addison Wesley, 1995
.


Literally thousands of patterns … !

Types

of
Pattern

B
asically
3
types

of pattern …


Creational
: address problems of creating an
object in a flexible way. Separate creation, from
operation/use.


Structural
: address problems of using O
-
O
constructs like inheritance to organize classes
and objects


Behavioral
: address problems of assigning
responsibilities to classes. Suggest both static
relationships and patterns of communication



Example Pattern
:


Mediator

(Behavioral)

Problem:

How can we deal with two or more classes

which sometimes interact, but can also be used

separately?

Solution:
Mediator

promotes loose coupling

by keeping objects from referring to one another

explicitly. Put each interaction between objects

in a separate (
Mediator
) class. This class

should have references to the objects.


A pattern for two objects which
exist
independently
but have some
coupling
. This
coupling is placed in its own class
.



Used by e.g.
ActionListener

in

Java
which couples
together two graphical objects, e.g.
window

&
button.



Colleagues send and receive requests from a
Mediator object. The mediator implements the
cooperative behavior by routing requests between
appropriate colleagues.


Mediator Structure

Mediator

ConcreteMediator

mediator

1

*

*

Colleague

Concrete

Colleague1

Concrete

Colleague2

Comments


Façade
, unlike
Mediator
, abstracts a
subsystem of objects to provide a convenient
interface.
Unidirectional
.
Façade

objects
make requests of the subsystem, but not vice
-
versa.


Mediator

enables cooperative behaviour, that
colleagues don’t or can’t provide.
Multidirectional
.

PSS
-
05 ARD Template

Sections 1 and 2 are similar to SRD template.


3. System
Context
. Gives a detailed description
of the system context, with relevant diagrams.
Defines the external interfaces of the product
under development

for
these other
systems

3
.
n.
External interface definition
. Provides an
interface definition to each separate external
component type or physical component.

25

4 System
Design
.
Provides an overview of the
design techniques used, especially any in
-
house
or non
-
standard notations,
project specific
methods, or non
-
standard interpretation of
standard languages/methods such as
UML/Waterfall.

4.1
Design method
. Describes and references the
design method
. “
Why we did what we did
.”

4.2
Decomposition description
. Gives the top level
view of the systems design, preferably with
diagrams. Shows the major components which
will be described in detail
in Section 5. Identifies
control and data flow between components.

26

5 Component
Description.
Gives
detailed component
information according to a fixed template. Components
may be top level components, identified
in Section 4.2,
or
subcomponents of these. Preferably use a component
identification scheme which is easy to
read/follow/remember
.

5
.n [Component identifier]
Fill in name here
.

5
.n.1 Type
. Could be a module, an input/output/temporary
file, a program, a class, a script, a web page, etc
.

5
.n.2 Purpose
. Describe the purpose of the component, and
relate this to a numbered software requirement in the SRD
.

5
.n.3 Function
. Describe the functionality of the component,
including its interface properties (call and return types) and
logical
behaviour
.

5
.n.4 Subordinates
. List the immediate subcomponents of the
component, using defined component identifiers
.

27

5.n.5 Dependencies.
Describe the logical preconditions for using this
component, e.g. files and/or objects which must exist.

5.n.6 Interfaces
. Define the control and data flow to and from the object.
Gives a detailed picture of its context in the overall system
architecture.

5.n.7 Resources.
List any resources required by the component, such as
external components external subsystems, hardware, etc.

5.n.8 References
. reference any documents needed to understand the
component.

5.n.9 Processing
. Describe the control and data flow
betwen

immediate
subcomponents of this component. If the component has no
immediate subcomponents (i.e. it is fully decomposed) then outline
the method of processing used by the component to perform its task
(e.g. with pseudo
-
code, state diagrams, etc).

5.n.10 Data
. Describe in detail (where possible) the local data values and
data structures belonging to (local in scope) this component.
Otherwise give an outline description.


28

6 Feasibility and Resource Estimates.
Summarize
the conclusions of
a


feasibility study
around
the
architectural model.



Prioritize

all components

using
a priority model (e.g. economy,
standard, deluxe versions)
.


Identify
and describe all future
project tasks
. Identify
task


dependencies
in terms of commencement and completion,
preferably


with a task flow chart.



Estimate
the
effort

required for each project task
.



Produce a
task allocation plan
and schedule for each project
staff


member for the remainder of the project. This information
should


preferably be presented in a table
.

29

Identify
possible risks
going forward, and for each risk, give a risk


management proposal.


Estimate the
overall schedule
fo
r

making a detailed design,


coding this design, testing and delivering the final product and


documentation according to the project deadlines.



Identify the
critical path
in the project, and analyze possible


project slippage along this path.


7 Software Requirements
vs

Components Traceability

Matrix
.
Gives a table
cross referencing
architectural components
(based on defined component
identifers
).

30