The Process of Architecting for Software / System Engineering
The Process of Software Architecting: Architecture Designwrichter/handouts/ABS 06... ·...
Transcript of The Process of Software Architecting: Architecture Designwrichter/handouts/ABS 06... ·...
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
4 Sandro Schwedler, Wolfram Richter10.02.2013
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
5 Sandro Schwedler, Wolfram Richter10.02.2013
3
6 Sandro Schwedler, Wolfram Richter10.02.2013
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
7 Sandro Schwedler, Wolfram Richter10.02.2013
Architecture DesignSurvey Architecture Assets
� Identify Assets which are helpful in
developing the solution architecture
� Previous projects
� Industry best practises
� Publications
� etc.
4
8 Sandro Schwedler, Wolfram Richter10.02.2013
Survey Architecture Assets
Where do architectures come from?
“The Software Architect”; Philippe Kruchten, TC2 First Working IFIP Conference on SoftwareArchitectures, KLUWER ACADEMIC PUBLISHERS
9 Sandro Schwedler, Wolfram Richter10.02.2013
Survey Architecture Assets
Asset Classification
http://www.ibm.com/developerworks/rational/library/sep07/eeles/
5
10 Sandro Schwedler, Wolfram Richter10.02.2013
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
– ...
11 Sandro Schwedler, Wolfram Richter10.02.2013
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
12 Sandro Schwedler, Wolfram Richter10.02.2013
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
13 Sandro Schwedler, Wolfram Richter10.02.2013
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
14 Sandro Schwedler, Wolfram Richter10.02.2013
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
15 Sandro Schwedler, Wolfram Richter10.02.2013
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
16 Sandro Schwedler, Wolfram Richter10.02.2013
Functional Architecture
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
17 Sandro Schwedler, Wolfram Richter10.02.2013
Functional Architecture
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
18 Sandro Schwedler, Wolfram Richter10.02.2013
Functional Architecture
Component Identification
Component Identification is a creative process.
It can be aided but not automated by the methods suggested on the following slides.
19 Sandro Schwedler, Wolfram Richter10.02.2013
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
20 Sandro Schwedler, Wolfram Richter10.02.2013
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
21 Sandro Schwedler, Wolfram Richter10.02.2013
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
22 Sandro Schwedler, Wolfram Richter10.02.2013
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
– ...
23 Sandro Schwedler, Wolfram Richter10.02.2013
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
24 Sandro Schwedler, Wolfram Richter10.02.2013
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!!
25 Sandro Schwedler, Wolfram Richter10.02.2013
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
26 Sandro Schwedler, Wolfram Richter10.02.2013
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
27 Sandro Schwedler, Wolfram Richter10.02.2013
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
28 Sandro Schwedler, Wolfram Richter10.02.2013
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/
29 Sandro Schwedler, Wolfram Richter10.02.2013
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
30 Sandro Schwedler, Wolfram Richter10.02.2013
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
– ...
31 Sandro Schwedler, Wolfram Richter10.02.2013
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
32 Sandro Schwedler, Wolfram Richter10.02.2013
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
33 Sandro Schwedler, Wolfram Richter10.02.2013
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
34 Sandro Schwedler, Wolfram Richter10.02.2013
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
35 Sandro Schwedler, Wolfram Richter10.02.2013
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
36 Sandro Schwedler, Wolfram Richter10.02.2013
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
37 Sandro Schwedler, Wolfram Richter10.02.2013
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.