The Process of Software Architecting: Architecture Designwrichter/handouts/ABS 06... · 2013-02-12 · 1 Architecture of Business Systems The Process of Software Architecting: Architecture

1

Architecture of Business Systems

The Process of Software Architecting: Architecture Design

Sandro Schwedler

Wolfram Richter

3 Sandro Schwedler, Wolfram Richter10.02.2013

Lecture Outline

Building Block: Integration Technologies (W)

Building Blocks: Introduction, Application Server (S)

SOA (W)Building Block: UI Server (S)Architecture Design (W)

Building Block: Content

Management Systems (S)

Process of Software

Architecting, Requirements (W)

Building Block: Security Components (S)

Building Block: Databases (S)

Introduction (W)– Lecture Overview

– Role of the Architect

– Views and Viewpoints

2


Goals of this presentation

� After this presentation, you should...

– Know the approach to design an architecture that meets the stated requirements

– Know the importance of asset reuse

– Know component modeling techniques

• Be able to describe the concept of a software component

• Be able to create and read component structure and

component sequence diagrams

• Understand component quality metrics, to distinguish a

good from a bad component model

– Know deployment modeling techniques

– Know the importance of and how to document architecture decisions


3


Solution Architecture – usually refined iteratively

Create a model complete enough to properly satisfy the concerns of the stakeholders, for example...

– Logical / Functional / Application: describes how the functional requirements are addressed in an

implementation-neutral fashion, without cluttering

it with technical details

– Logical / Functional / Technical: adds the infrastructure aspects and how the application

components relate to them, in an implementation-

neutral fashion

– Physical / Functional / Technical: describes with

which real-world pieces the logical components are implemented (1:N mapping)

– Physical / Deployment / Technical: describes an IT

infrastructure and how the physical components

are mapped to it

Application

requirements

Technical

requirements

Components related to the

business

Elements

that validate

business

requirements

Elements

that validate

constraints

on technical

elements

Components

related to

technology

Deployment

aspects

related to the business

Deployment

aspects

related to

technology

ApplicationManageme

Technical

Application

requirements

Technical

requirements

Systems

management

requirements

Components

related to the

business

Elements

that validate

business

requirements

Elements

that validate

constraints

on technical elements

Elements

that validate

systems

management requirements

Components

related to

technology

Components

related to

systems

management

Deployment

aspects related to the

business

Deployment

aspects

related to

technology

Deployment

aspects

related to

systems

management

Requirements

Validation

Functional

Deployment

Logical

Physical


Architecture DesignSurvey Architecture Assets

� Identify Assets which are helpful in

developing the solution architecture

� Previous projects

� Industry best practises

� Publications

� etc.

4


Survey Architecture Assets

Where do architectures come from?

“The Software Architect”; Philippe Kruchten, TC2 First Working IFIP Conference on SoftwareArchitectures, KLUWER ACADEMIC PUBLISHERS


Survey Architecture Assets

Asset Classification

http://www.ibm.com/developerworks/rational/library/sep07/eeles/

5


Architecture DesignDefine Architecture Overview

� Sketch a draft/high-level description of the target architecture

� Freeform diagram(s): contents are depending on the stakeholders the diagram are discussed with

– Funcational and Deployment view

– Usually structure, not behavior

� Ensure that a consistent diagramming technique is used (use a legend!)

– Line styles and thickness

– Arrow heads, directions

– Colors and shapes

– ...


Architecture DesignFunctional Architecture

� Component-based software engineering

– To decompose the system into parts which can be developed independently

• Allows the project to scale

– To be able to reuse existing components

� Outline: Component Identification

– From Entity Model

– From Functional Requirements

� Detail: Component Specification

– Evaluate and select assets

– Specify interfaces, operations and signatures, pre- and post-conditions

– Assign Business Rules to components

� Detail: Component Implementation

– Decide physical realization

6


Sun-Tzu said...凡治眾如治寡，分數是也﹔鬥眾如鬥寡，形名是也﹔三軍之眾，可使必受敵而無敗，奇正是也﹔兵之所加，如以碫投卵者，虛實是也。The control of a large force is the same

principle as the control of a few men: it is

merely a question of dividing up their

numbers.

-- Sunzi, The Art of War


Functional Architecture

A software component...

... bundles related functionality and data(is modular and cohesive)

... hides its implementation

… defines its behavior in terms of provided and required interfaces

(is encapsulated)

... is interchangeable with other components providing the same interfaces

... enables the re-use of

(previously constructed) components

... is typically of coarse granularity

... can be used to assemble a system(or: a system can be decomposed into components)

... is robust, designed with an awareness that it will be put to unforeseen uses

... can itself be implemented by assembling

finer-grained components

... is (most likely) not a (single) class

http://en.wikipedia.org/wiki/Component_%28UML%29

http://en.wikipedia.org/wiki/Component-based_software_engineering

7


Caution: „Component Model“ is an overloaded term!

� Component Model can mean

– An architectural model detailing which

components a system is composed of, their

relations and their dynamic behavior. This

can be a logical or a physical model.

– A (physical) technology which describes how

components are realized and used, such as

COM, DCOM, EJB, Eclipse Plugins/OSGI, ...

� This lecture refers to the former!

Danger sign photograph by Jan Willem Geertsma


Functional ArchitectureComponent Sequence Diagram depicts behavior in a specific scenario

� Shows the dynamic invocations between actors and components for a specific scenario

– Each component is represented by a life line

– Each message sent between components is

represented by an arrow between life lines

– Whenever a component is active, this is

depicted by a thickened life line

� Allows to understand the flow of control, concurrency, creation and destruction of components

� There are also other diagram types to model behavior

– Collaboration diagram

– Timing diagram

8



Component Structure Diagram shows the static relationships between components

� Can be inferred from (a set of) sequence diagrams

� depicts the superset of all relationships

stemming from all scenarios, or just a subset of it

� Depicts only one

instance of each component



Component and Component Model Quality Metrics

� High Cohesion: the responsibilities assigned to a component must make sense, they should be grouped around the same theme/topic

– Bad (Low) Cohesion sample: Database which also renders end user error messages in HTML.

� Low Coupling: Ensure there are no unnecessary dependencies between components

– Bad (High) Coupling sample: Component „ProductCatalog“ has an unecessary dependency on „AddressManager“.

� Appropriate Granularity: A component should be allocated sufficient responsibilities

– Inappropriate Granularity sample: „Web Shop“ (too coarse), „Image Resizer“ (too fine)

� Good Isolation: Product/technology dependencies must be confined to a few places

– Bad Isolation sample: Every component needs to import javax.swing.* since the interface descriptions are based on UI components.

� Layering: Component Models should be layered according to their generality

– special-purpose components can call general-purpose components but not vice versa!

• Application-specific

• Business-specific

• Business-independent

– Well-layered systems are more loosely coupled, more easily maintained and its components can be reused easily

9



Component Identification

Component Identification is a creative process.

It can be aided but not automated by the methods suggested on the following slides.


Component IdentificationTechnique: CRC ClassComponent, Responsibility, Collaboration and Logical Component Stereotypes

� Describe for each component:

– What the component knows (the data it owns or manages)

– What the component does (the behavior it exhibits), especially which functional and nonfunctional requirements guide its behavior (traceability)

– What the component asks other components to do on its behalf (the components it needs to collaborate with to perform some function)

� Logical Components can be stereotyped into three categories

– «entity» components primary responsiblity is encapsulating information represented in

the system

– «boundary» components represent the boundary between the system and its environment, i.e. human or external system actors

– «control» components primary represent the control and coordination logic of the system

(.... sounds a bit like the „Model-View-Controller“ design pattern...)

10


Component IdentificationIdentifying Logical Components from Business Entities

� If you have a business entity model, assign the responsibility to manage related business entities relevant to the solution to a component

� Add further (e.g. behavioral) responsibilities to the component as the analysis progresses


Component IdentificationIdentifying Logical Components from Use Cases

� Repeat for each use case description:

– Define «boundary» components for

each primary and secondary actors of

use cases

– Define a «control» component with the same name as the use case

– Nouns in the use case description

indicate data. Create «entity»

components for each cluster of

related data elements

� The image on the right depicts the result of one iteration

11


Component IdentificationIdentifying Logical Components from system-wide functional requirements, business rules and non-functional requirements

� Do not forget to review the system-wide functional requirements, business rules

and non-functional requirements to identify components

� Many non-functional requirements primarily impact the deployment model.

Nevertheless there are some non-functional requirements which may result in

additional components to be identified, such as:

– Security: encryption of data -> Key management component

– Constraint: use of an existing system for data storage -> new «boundary» component

– ...


Component Specification

Specify externally visible/relevant aspects

� Develop component interfaces from

– Use Cases: Create a sequence model for each use case. For each component message specify which operation is called and the payload transferred

– Existing interfaces

� „Design by Contract“ makes the component model robust

– Pre- and post-conditions specify the effect of an operation without prescribing an algorithm or implementation.

– The post-condition specifies what the effect of the operation will be (on the components data or state), provided the pre-condition is true

– The pre-condition is the condition under which the operation guarantees that the post-condition will be true

– If the pre-condition is false when the operation is invoked, the result is unspecified (and dealt with by some form of exception handling)

Preconditions: the tour referenced is currently offered

Postconditions:the number of participants of the tour is increased

12


Component RealizationChoosing physical realizations for logical components

� Logical elements can be mapped to physical elements

– 1:1 if a physical component can fulfill all the

responsibilities of the logical component

without sacrifiying the quality metrics

coupling, cohesion and granularity

– 1:M many physical components are required

to realize the logical component. May be a

combination of products and custom

development

– M:1 a single physical component (e.g. a product) encapsulates the responsibilities of

several assigned logical components

� Choices needed to be made

– Technology: runtime environments

– Products: build vs. buy

– Reusable assets: packaged applications, existing components, legacy applications

– Custom development: flexibility vs. cost

� Work products

– Create physical component structure

diagram!

– Not suggested: physical component

sequence diagrams

– Document your architectural decisions!!


Architecture DesignDeployment Architecture

� „Deployment“ = the act of placing (pieces of) the solution on (execution) nodes

– Affects NFRs

– Key input required to operate the system

� Outline Deployment Elements

– Location Model

– Node Model

� Detail Deployment Elements

– Place Nodes in Locations

– Decompose Components into Deployment Units

– Deploy DUs to Nodes

13


Deployment Architecture

Location Model

� The Location model depicts the “geography” over which the target ITsystem will be deployed

– Logical/Physical: „LL_Branch Office“vs. „PL_IBM Herrenberg“, „PL_IBM

Ehningen“

– Actors and Nodes will later be placed

into the various locations

– Actor locations have already been

collected while creating the System

Context

– Hot candidate for asset reuse: Locations don‘t change that

frequently for a company


Deployment ArchitectureNode Model

� Node = Hardware: a server, computer, etc..

� The Node Model represents the execution environment for the target solution

– What servers are there and how

are they connected

– Logical/Physical: „LN_Web Server“ vs. „PN_Web Server HP

Proliant DL 120“

– Also hot candidate for asset reuse

– Can be modeled into the location model, or independently of it

14


Deployment ArchitecturePlacing application components directly onto nodes is too limited to describe the real world

� Example: Which nodes are affected/need to comply with requirements when

deploying the Shopping Cart „VirtueMart“, an extension to Joomla! CMS?

� A component has requirements against/affects multiple nodes

– The node its executable files are copied to

– The node it actually executes on

– The node it displays its UI on

– The node its data resides at

http://virtuemart.net/


Deployment ArchitectureA Deployment Unit...

...specifies details about the organization and runtime behavior of an applicationcomponent

...exists on a physical or logical level, depending on the component it represents

...can hosts additional information. Example: Installation Deployment Unit

– Name/Link of the artifact to be installed

– The component(s) it represents

– Version

– Prerequisites

– ...

� There are other DU types useful for planning

– Data DUs: Describes the storage and growth characteristics of the component‘s data

– Execution DUs: Describes the runtime (CPU, RAM, ...) requirements of the component

– Presentation DUs: Describes the user interface requirements (e.g. Screen resolution) of the component

DU

http://pic.dhe.ibm.com/infocenter/rsahelp/v8r5/index.jsp?topic=%2Fcom.ibm.ccl.soa.deploy.uml.doc%2Ftopics%2Fuml_deployment_units_cpt.html

15


Deployment ArchitectureDeployment Model

� The deployment model depicts how the component DUs are deployed onto the nodes within the backdrop of the location model

� DU placement based on component stereotype or NFR:

– DUs of boundary components are typically placed on edge nodes

– DUs of entity components are typically placed close to the node hosting the database

– DUs of components with high availability requirements are placed on highly available nodes, or multiple redundant nodes with a failover mechanism

– ...


Architecture DesignVerify Architecture

� „Verification“ as defined by the

Carnegie Mellon Software Engineering

Institute (SEI)

� Review step to ensure that the

individual work products are consistent

and address the requirements raised

in the previous step

– Especially when created by different people

� Runs in parallel with the other tasks /

after each significant iteration

http://www.sei.cmu.edu/library/abstracts/reports/89cm013.cfm

16


Architecture DesignBuild Architecture Proof-of-Concept

� Goal is to reduce risk

� Ensure early on that the created

architecture is feasible

� Anything between a very conceptual

work to a physical sample realization

– List of known technologies that seem appropriate

– ....

– Physical prototype

� Depends on the level of

uncertainty/novelty of the system in

question


Architecture DesignDocument Architecture Decisions

� Key work product of architecture process

� Documents major decisions

– The issue to be decided

– Assumptions

– Pros and Cons of Options

– ...

� Allows independent validation of the architecture

� Can be revisited later when reasons for doing things a certain way are forgotten

– Or by new team members

17


Architecture DesignValidate Architecture

� „Validation“ as defined by the

Carnegie Mellon Software Engineering

Institute (SEI)

� Review step to ensure that finished

architecture is free of failures and

addresses all requirements


Traceability

� In a good architecture model, the various model elements are interlinked

� This way, it is possible to determine ...

– which requirements drive which element (Component -> Requirements)

– which test cases need to be rerun for regression testing when a bug is fixed (Component

-> Requirements -> Test Cases)

– which business requirements are impacted, if a piece of technology fails (Node -> Deployment Units -> Components -> Requirements)

– ...

http://en.wikipedia.org/wiki/Requirements_traceability

18


Further Reading

� Understanding architectural assets http://www.ibm.com/developerworks/rational/library/sep07/eeles/

� http://www.agilemodeling.com/artifacts/

� http://de.wikipedia.org/wiki/Fundamental_Modeling_Concepts(alternative architecture modeling approach, e.g. used at SAP)

� Software Engineering Radio http://www.se-radio.net/

– Episode 87: Software Components

– Episode 51: Design by Contract

ISBN 978-0-321-35748-9


Projekt World Domination

Architekturentscheidungen

Kunde: MegaCorp, Inc.

Autoren: Archie Tekt, Susann Specialist

Owner: Archie Tekt

Dokumentenhistorie

Speicherort des Dokuments Dies ist ein Schnappschuss eines on-line Dokuments. Ausdrucke sind nur am Tag des Ausdrucks gültig. Bitte wenden Sie sich an den Autor, wenn Sie die Aktualität dieses Dokuments anzweifeln.

Dieses Dokument ist unter

P:\PFAD\AUF\DEM\FILE\SHARE\ABS 06 Architectural Decisions.doc

abgelegt.

Änderungshistorie Datum dieser Änderung: 29.9.2012 Datum der nächsten Änderung: (date)

Revisions-nummer

Revisions-datum

Autor Zusammenfassung der Änderungen Änderungen markiert?

0.1 20.9.12 Archie Tekt Erste Version N 0.2 29.9.12 Archie Tekt Entscheidung IF1 hinzugefügt und

Kommentiert N

(#) (-) (Describe change) (N)

Freigaben Dieses Dokument erfordert die folgenden Freigaben. Unterzeichnete Freigabeformulare werden in der Sektion “Qualität” des PCB abgelegt.

Name Titel (name) (title)

Verteilung Dieses Dokument wurde an folgende Personen verteilt:

Name Titel (name) (title)

Inhaltsverzeichnis

Architekturentscheidungen .............................................................................................................. 3

IF1: Aufgabenverteilung Datenvalidierung................................................................................... 3

Architekturentscheidungen

IF1: Aufgabenverteilung Datenvalidierung Problembereich Schnittstelle Portal<->Prozess Thema Aufgabenverteilung Design Entscheidung

Aufgabenverteilung Datenvalidierung Id. IF1

Problembe-schreibung

Es geht um die Definition einer einheitlichen Richtlinie, wo die Validierung von Eingabedaten abgebildet wird. Dies hat Einfluß auf die Größe der Arbeitspakete der AP Portal und AP MW/WF.

Annahmen Es gibt eine zentrale Portal- und eine zentrale Prozessengine-Instanz. Technische prüfung = prüfung ob Datentypen richtig eingegeben werden, z.B. Keine Buchstaben bin Zahlenfeldern; Inhaltliche Prüfung = Übermenge von Technischer Prüfung: Prüfen ob die Werte gültig sind (z.B. ist die Kostenstelle zur Bebuchung freigegeben?)

Motivation Dieselbe Logik kann in unterschiedlichen Schichten in der Architektur abgebildet werden.

Alternativen 1. Gar nicht 2. Technische + Inhaltliche Prüfung im Portal, Direktzugriff auf

Stammdaten in den Backendsystemen 3. Technische + Inhaltliche Prüfung Im Portal, Zugriff auf

Stammdaten über Services, die von der Middleware zur Verfügung gestellt haben

4. Technische Prüfung im Portal, Inhaltliche Prüfung als Service, der von der Middleware zur Verfügung gestellt wird.

5. Komplett als Service, der von der Middleware zur Verfügung gestellt wird.

Entscheidung Vorschlag: 4. Technische Prüfung im Portal, Inhaltliche Prüfung als Service, der von der Middleware zur Verfügung gestellt wird.

Bewertung 1. Gar nicht Um die Prozesse so effizient wie möglich zu gestalten, ist es notwendig, die Validierung so früh wie möglich durchzuführen. Daher ist keine Validierung keine Option.

2. Technische + Inhaltliche Prüfung im Portal, Direktzugriff auf Stammdaten in den Backendsystemen Einfachste Variante aus Sicht der Middleware: Integrationsproblematik mit multiplen Backends von Middleware auf Portal verlagert; voraussichtliche Duplikation von Schnittstellen zwischen Portal<->Backend und MW/WF<->Backend (hohe Initial– und Folgekosten); keine Wiederverwendung von Schnittstellen/Logik bei anderen Frontends. Inhaltliche Prüfung auf Feldebene zum Zeitpunkt der Eingabe möglich.

3. Technische + Inhaltliche Prüfung im Portal, Zugriff auf Stammdaten über Services, die von der Middleware zur Verfügung gestellt haben Höherer Aufwand in MW/WF: Integrationsproblematik mit multiplen Backends in Middleware; keine Duplikation von Schnittstellen zwischen Portal und MW/WF; Wiederverwertung von Schnittstellen, aber keine Wiederverwertung von Validierungslogik bei anderen Frontends. Inhaltliche Prüfung auf

Comment [WR1]: Problembereich, Thema und der eigentliche Titel wirken sehr redundant, ermöglicht aber in größeren Projekten, die Übersicht zu behalten.

Comment [WR2]: Titel

Comment [WR3]: ID Kürzel, ändert sich nach Vergabe nicht mehr. Über dieses Kürzel kann schnell aus anderen Entscheidungen auf diese Entscheidung verwiesen werden.

Comment [WR4]: Es gab zwei Subsysteme, das Portal (UI) und Integration/Workflow

Comment [WR5]: Hintergrundinformation, um die Entscheidung nachzuvollziehen

Comment [WR6]: Warum muss eine Entscheidung getroffen werden?

Comment [WR7]: Ausgewählte Alternative

Feldebene zum Zeitpunkt der Eingabe möglich. 4. Technische Prüfung im Portal, Inhaltliche Prüfung als

Service, der von der Middleware zur Verfügung gestellt wird. Höchster Aufwand in MW/WF: Integrationsproblematik und Validierungslogik in MW/WF; keine Duplikation von Schnittstellen; Wiederverwertung von Schnittstellen und Validierungslogik bei anderen Frontends. Nur technische Prüfung auf Feldebene zum Zeitpunkt der Eingabe möglich.

5. Komplett als Service, der von der Middleware zur Verfügung gestellt wird. Höchster Aufwand in MW/WF: Integrationsproblematik und Validierungslogik in MW/WF; keine Duplikation von Schnittstellen; Wiederverwertung von Schnittstellen und Validierungslogik bei anderen Frontends. Keine Prüfung auf Feldebene zum Zeitpunkt der Eingabe möglich.

Implikationen Neuabschätzung der Projektaufwände notwendig Caching von häufig benutzten Stammdaten, um Antwortzeitvorgaben zu erfüllen

Abgeleitete Anforderungen

Verwandte Ent-scheidungen

Comment [WR8]: Was bedeutet das für das Projekt

Comment [WR9]: Entstehen dadurch neue Anforderungen? Caching ist eine Lösungsstrategie für eine einzelne Komponente, keine neue Anforderung an das Projekt daher in der Zeile drüber aufgeführt.

Comment [WR10]: Hier könnte via ID auf andere Entscheidungen verwiesen werden.