MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
MTAT.03.094
Software Engineering
Lecture 07: Architecture
and Design – Part II
Dietmar Pfahl
email: [email protected] Fall 2013
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Schedule of Lectures
Week 01: Introduction to SE
Week 02: Requirements Engineering I
Week 03: Requirements Engineering II
Week 04: Analysis
Week 05: Development Infrastructure I
Week 06: Development Infrastructure II
Week 07: Architecture and Design
Week 08: Refactoring
Week 09: Quality Management
Week 10: Verification and Validation
(incl. SW Quality)
Week 11: Agile/Lean Methods
Week 12: Measurement
Week 13: Process Improvement
Week 14: Course wrap-up, review and
exam preparation
Week 15: no lecture
Week 16: no lecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Acknowledgements
Textbooks/Slides:
• Ian Sommerville: Software Engineering, 9th edition, 2010 (http://www.softwareengineering-9.com/)
• Hans van Vliet: Software Architecture, Free University of Amsterdam, Lecture 2008
• Richard Taylor et al.: Software Architecture, University of California at Irvine, Lecture 2011
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Structure of Lecture 07
• What is it, why bother?
• Architecture Design
• Viewpoints and View Models
• Architectural Styles
• Architecture Assessment
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Software Architecture – What is it?
Software architecture
• goes beyond algorithms and data structures that make up an application.
• addresses “structural issues [that] include
• gross organization and global control structure;
• protocols for communication, synchronization, and data access;
• assignment of functionality to design elements; physical distribution;
• composition of design elements;
• scaling and performance; and
• selection among design alternatives.“ (David Garlan & Mary Shaw)
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Patterns, Styles, and DSSAs
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John
Wiley & Sons, Inc. Reprinted with permission.
• Pipes and filters • Data abstraction and
object-oriented organization
• Layered systems • Repositories • Event-based, implicit
invocation • ... and many more
?
?
?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Domain-Specific Software Architectures
• A DSSA is an assemblage of software components
• specialized for a particular type of task (domain),
• generalized for effective use across that domain, and
• composed in a standardized structure (topology) effective for building successful applications.
• DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Examples of Domains
• Compilers for programming languages
• Consumer electronics
• Electronic commerce system/Web stores
• Video game
• Business applications
• Basic/Standard/“Pro”
We can subdivide, too: • Avionics systems -> Boeing Jets -> Boeing 747-400
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Traditional Software Engineering
• One particular problem can be solved in innumerable ways
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Architecture-Based Software Engineering
• Given a single problem, we select from a handful of potential architectural styles or architectures, and go from these into specific implementations
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Domain-Specific Software Engineering (DSSE)
• We map regions of the problem space (domains) into domain-specific software architectures (DSSAs)
• These are specialized into application-specific architectures
• These are implemented
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Domain-Specific Software Architectures
A DSSA comprises:
• A reference architecture, which describes a general computational framework for a significant domain of applications
• A component library, which contains reusable chunks of domain expertise, and
• An application configuration method for selecting and configuring components within the architecture to meet particular application requirements
Examples:
• ADAGE for avionics, AIS for adaptive intelligent systems, and MetaH for missile guidance, navigation, and control systems
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Example Reference Architecture
• Structural view of Lunar Lander DSSA
• Invariant with explicit points of variation
• Satellite relay
• Sensors
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Patterns, Styles, and DSSAs
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John
Wiley & Sons, Inc. Reprinted with permission.
?
?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Patterns – Styles – Patterns
• Architectural patterns <> Architectural styles <> Design patterns.
• While architectural styles define the components and connectors possible within the system (more asking ‘what?’), architectural patterns define the implementation strategies of those same components and connectors (a bit more on ‘how?’).
• Example: Model-View-Controller (MVC) pattern
• At the same time, a good architecture will make use of design patterns (on a more fine-granular level)
• Example: Observer pattern used to implement (active) MVC pattern
• Different architectural styles will find different architectural and design patterns more or less helpful.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Architectural Patterns
• Examples:
• Model-View-Controller (MVC)
• Three-Tier-Model
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Context
• The purpose of many computer systems is to retrieve data from a data store and
display it for the user.
• After the user changes the data, the system stores the updates in the data store.
• Because the key flow of information is between the data store and the user
interface, you might be inclined to tie these two pieces together to reduce the
amount of coding and to improve application performance.
• However, this seemingly natural approach has some significant problems.
• One problem is that the user interface tends to change much more frequently than the
data storage system.
• Another problem with coupling the data and user interface pieces is that business
applications tend to incorporate business logic that goes far beyond data transmission.
Problem
• How do you modularize the user interface functionality of a Web application so that
you can easily modify the individual parts?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 1: User interface may change frequently
• User interface logic tends to change more frequently than business logic, especially
in Web-based applications.
• For example, new user interface pages may be added, or existing page layouts may be
shuffled around.
• After all, one of the advantages of a Web-based thin-client application is the fact
that you can change the user interface at any time without having to redistribute the
application.
• If presentation code and business logic are combined in a single object, you have
to modify an object containing business logic every time you change the user
interface. This is likely to introduce defects (bugs) and require the retesting of all
business logic after every minimal user interface change.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 2: Same data displayed in different ways
• In some cases, the application displays the same data in different ways.
• For example, when an analyst prefers a spreadsheet view of data whereas management
prefers a pie chart of the same data.
• In some rich-client user interfaces, multiple views of the same data are shown at
the same time. If the user changes data in one view, the system must update all
other views of the data automatically.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 3: Assymetric distribution of developer skills
• Designing visually appealing and efficient HTML pages generally requires a
different skill set than does developing complex business logic. Rarely does a
person have both skill sets. Therefore, it is desirable to separate the development
effort of these two parts.
Force 4: User interface activity = Presentation & Update
• User interface activity generally consists of two parts: presentation and update.
• The presentation part retrieves data from a data source and formats the data for display.
• When the user performs an action based on the data, the update part passes
control back to the business logic to update the data.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 5: Presenting data in same format for different actions on the data
• In Web applications, a single page request combines the processing of the action
associated with the link that the user selected with the rendering of the target page.
• In many cases, the target page may not be directly related to the action.
• For example, imagine a simple Web application that shows a list of items.
• The user returns to the main list page after either adding an item to the list or deleting an
item from the list.
• Therefore, the application must render the same page (the list) after executing two
quite different commands (adding or deleting) - all within the same HTTP request.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 6: Dependency of user interface code on type of device used
• User interface code tends to be more device-dependent than business logic.
• If you want to migrate the application from a browser-based application to support
personal digital assistants (PDAs) or Web-enabled cell phones, you must replace
much of the user interface code, whereas the business logic may be unaffected.
• A clean separation of these two parts accelerates the migration and minimizes the
risk of introducing errors into the business logic.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Forces
• The following forces act on a system within this context and must be reconciled as
you consider a solution to the problem:
Force 7: User interface code difficult to test -> reduce it if possible
• Creating automated tests for user interfaces is generally more difficult and time-
consuming than for business logic.
• Therefore, reducing the amount of code that is directly tied to the user interface
enhances the testability of the application.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
• The Model-View-Controller (MVC) pattern separates the modeling of the domain, the presentation, and the actions based on user input into three separate classes:
• Model. The model consists of application data, business rules, logic, and functions.
• The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
• View. The view manages the display of data/information.
• Controller. The controller interprets the mouse and keyboard inputs from the user, informing the model and/or the view to change as appropriate.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
• It is important to note that both the view and the controller depend on the model.
• However, the model depends on neither the view nor the controller.
• This is one of the key benefits of the separation.
• This separation allows the model to be built and tested independent of the visual presentation.
• The separation between view and controller is secondary in many rich-client applications, and, in fact, many user interface frameworks implement the roles as one object.
• In Web applications, on the other hand, the separation between view (the browser) and controller (the server-side components handling the HTTP request) is very well defined.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Variations:
• Passive Model
• Active Model
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Passive Model
• The passive model is employed when one controller manipulates the model exclusively.
• The controller modifies the model and then informs the view that the model has changed and should be refreshed.
• The model in this scenario is completely independent of the view and the controller, which means that there is no means for the model to report changes in its state.
• The HTTP protocol is an example of this. There is no simple way in the browser to get asynchronous updates from the server. The browser displays the view and responds to user input, but it does not detect changes in the data on the server.
• Only when the user explicitly requests a refresh is the server interrogated for changes.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Active Model
• The active model is used when the model changes state without the controller's involvement.
• This can happen when other sources are changing the data and the changes must be reflected in the views.
• Consider a stock-ticker display.
• You receive stock data from an external source and want to update the views (for example, a ticker band and an alert window) when the stock data changes.
• Because only the model detects changes to its internal state when they occur, the model must notify the views to refresh the display.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Active Model
• However, one of the motivations of using the MVC pattern is to make the model independent from of the views.
• If the model had to notify the views of changes, you would reintroduce the dependency you were looking to avoid.
• Fortunately, the Observer pattern [Gamma95] provides a mechanism to alert other objects of state changes without introducing dependencies on them.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Active Model – Observer Pattern
• The individual views implement the Observer interface and register with the model.
• The model tracks the list of all observers that subscribe to changes.
• When a model changes, the model iterates through all registered observers and notifies them of the change. This approach is often called "publish-subscribe."
• The model never requires specific information about any views.
• In fact, in scenarios where the controller needs to be informed of model changes (for example, to enable or disable menu options), all the controller has to do is implement the Observer interface and subscribe to the model changes.
• In situations where there are many views, it makes sense to define multiple subjects, each of which describes a specific type of model change.
• Each view can then subscribe only to types of changes that are relevant to the view.
Figure shows the structure of the active MVC using Observer and how the observer isolates the model from referencing views directly.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Observer Pattern
The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems. The Observer pattern is also a key part in the familiar Model View Controller (MVC) architectural pattern.
Java code example: http://en.wikipedia.org/wiki/Observer_pattern
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Active Model – Observer Pattern
• Figure illustrates how the Observer notifies the views when the model changes.
• Unfortunately, there is no good way to demonstrate the separation of model and view in a Unified Modeling Language (UML) sequence diagram, because the diagram represents instances of objects rather than classes and interfaces.
Example implementation ASP.NET (with refactoring): http://msdn.microsoft.com/en-us/library/ff647462.aspx
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller – Benefits
Supports multiple views
• Because the view is separated from the model and there is no direct dependency from the model to the view, the user interface can display multiple views of the same data at the same time.
• For example, multiple pages in a Web application may use the same model objects.
• Another example is a Web application that allows the user to change the appearance of the pages. These pages display the same data from the shared model, but show it in a different way.
Accommodates change
• User interface requirements tend to change more rapidly than business rules. Users may prefer different colors, fonts, screen layouts, and levels of support for new devices such as cell phones or PDAs.
• Because the model does not depend on the views, adding new types of views to the system generally does not affect the model. As a result, the scope of change is confined to the view.
• This pattern lays the foundation for further specializations of this pattern (e.g., Page Controller and Front Controller).
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller – Liabilities
Complexity
• The MVC pattern introduces new levels of indirection and therefore increases the complexity of the solution slightly.
• It also increases the event-driven nature of the user-interface code, which can become more difficult to debug.
Cost of frequent updates
• Decoupling the model from the view does not mean that developers of the model can ignore the nature of the views.
• For example, if the model undergoes frequent changes, it could flood the views with update requests.
• Some views, such as graphical displays, may take some time to render. As a result, the view may fall behind update requests.
• Therefore, it is important to keep the view in mind when coding the model.
• For example, the model could batch multiple updates into a single notification to the view.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model View Controller
Variants:
• The Document-View variant recognizes all three roles of Model-View-Controller but merges the controller into the view. The document corresponds to the model role in MVC.
• This variant is present in many existing GUI platforms.
• An excellent example of Document-View is the Microsoft Foundation Class Library (MFC) in the Microsoft Visual C++ environment.
• The tradeoff of using this variant is that the view and the controller are more tightly coupled.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three-tier Model
Definitions:
• Generally, the term "tiers" is used to describe physical distribution of components of a system on separate servers, computers, or networks (processing nodes).
• A three-tier architecture then will have three processing nodes.
• Note: The term "layers" refer to a logical grouping of components which may or may not be physically located on one processing node.
• Note: The middle tier may be multi-tiered itself (resulting in an "n-tier architecture").
http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three-tier Model
•Three-tier architecture is a client–server architecture in which
• the user interface,
• functional process logic ("business rules"),
• computer data storage and data access
•are developed and maintained as independent modules,
•most often on separate platforms
http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three-tier Model
Presentation tier
• This is the topmost level of the application. The presentation tier displays information related to such services as browsing merchandise, purchasing and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network. (In simple terms it's a layer which users can access directly such as a web page, or an operating systems GUI)
Application tier (business logic, logic tier, data access tier, or middle tier)
• The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.
Data tier
• This tier consists of database servers. Here information is stored and retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.
http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three-tier Model
Web development usage
In the web development field, three-tier is often used to refer to websites, commonly electronic commerce websites, which are built using three tiers:
• A front-end web server serving static content, and potentially some cached dynamic content. In web based application, Front End is the content rendered by the browser. The content may be static or generated dynamically.
• A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion, Perl platform.
• A back-end database or data store, comprising both data sets and the database management system or RDBMS software that manages and provides access to the data.
http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three-tier Model vs. MVC
• At first glance, the three tiers may seem similar to the model-view-controller (MVC) concept.
• However, topologically they are different.
• A fundamental rule in a three-tier architecture is the client tier never communicates directly with the data tier; in a three-tier model all communication must pass through the middle tier.
• Conceptually the three-tier architecture is linear.
• However, the MVC architecture is triangular: the view sends updates to the controller, the controller updates the model, and the view gets updated directly from the model.
vs
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
More Architectural Styles
Client/Server
Peer-to-Peer
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Client/Server Model
• The client–server model is a distributed application structure in computing that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.
• Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system.
• A server is a host that is running one or more server programs which share their resources (e.g., CPU, storage devices, printer) with clients.
• A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests (request-response messaging).
• The client–server model was developed at Xerox PARC during the 1970s. It is now prevalent in computer networks. Email, the World Wide Web, network printing are typical examples of the model.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Thin- and Fat-Client Architectural Models
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Thin vs. Fat-Client Model
Thin Client:
• Used when legacy systems are migrated to client server architectures.
• The legacy system acts as a server in its own right with a graphical interface implemented on a client.
• A major disadvantage is that it places a heavy processing load on both the server and the network.
Fat Client:
• More processing is delegated to the client as the application processing is locally executed.
• Most suitable for new C/S systems where the capabilities of the client system are known in advance.
• More complex than a thin client model especially for management.
• New versions of the application have to be installed on all clients.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Peer-to-Peer Model
• A peer-to-peer (P2P) network is a type of decentralized and distributed network architecture
• in which individual nodes in the network (called "peers") act as both suppliers and consumers of resources,
• in contrast to the centralized client–server model where client nodes request access to resources provided by central servers.
• In a peer-to-peer network, tasks (such as searching for files or streaming audio/video) are shared amongst multiple interconnected peers who each make a portion of their resources (such as processing power, disk storage or network bandwidth) directly available to other network participants, without the need for centralized coordination by servers.
• Examples: Skype, Instant Messaging systems, Online Chat network, BitCoin
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
C/S Model vs. P2P Model
• In the client-server model, the server is a centralized system:
• Single point of failure risk.
• The more simultaneous clients a server has, the more resources it needs.
• In a peer-to-peer network, two or more computers (the peers) pool their resources and communicate in a decentralized system. Peers are co-equal nodes in a non-hierarchical network.
• Collectively, lesser-powered computers can share the load and provide redundancy.
• Since most peers are personal computers, their shared resources may not be available consistently. Although an individual node may have variable uptime, the resource remains available as long as one or more other nodes offer it. As the availability of nodes changes, an application-layer protocol re-routes requests.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Template for describing architectural patterns/styles
• Problem: type of problem that the style addresses. Characteristics of the reqs’s guide the designer in his choice for a particular style.
• Context: characteristics of the environment that constrain the designer, req’s imposed by the style.
• Solution: in terms of components and connectors (choice not independent), and control structure (order of execution of components)
• Variants
• Examples
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Model-View-Controller (MVC)
• Problem: separation of UI from application is desirable due to expected UI adaptations
• Context: interactive applications with a flexible UI
• Solution:
• system model: UI (View and Controller Component(s)) is decoupled from the application (Model component)
• components: collections of procedures (module)
• connectors: procedure calls
• control structure: single thread
• Variants: Document-View
Model
View Controller
n n
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
More Examples of Styles
Traditional, language-influenced styles
• Main program and subroutines
• Object-oriented
Layered
• Virtual machines
• Client-server
Data-flow styles
• Batch sequential
• Pipe and filter
Shared memory
• Blackboard
• Rule based
Interpreter
• Interpreter
• Mobile code
Implicit invocation
• Event-based
• Publish-subscribe
Peer-to-peer
Styles for distributed systems
• CORBA
Service-oriented architectures (SOAs)
RESTful web services
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Recap: Design Patterns
• A design pattern is a way of reusing abstract knowledge about a problem and its solution.
• A pattern is a description of the problem and the essence of its solution.
• It should be sufficiently abstract to be reused in different settings.
• Pattern descriptions usually make use of object-oriented characteristics such as inheritance and polymorphism.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Pattern Elements
• Name
• A meaningful pattern identifier.
• Problem description.
• Solution description (might have an example)
• Not a concrete design but a template for a design solution that can be instantiated in different ways.
• Benefits and Consequences
• The results and trade-offs of applying the pattern.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
The Observer Pattern Name: Observer
Problem description
• Situations where multiple displays of state are needed.
Solution description
• Separates the display of object state from the object itself.
• See UML description.
Consequences
• Optimisations to enhance display performance are difficult.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Three Types of Patterns
Creational patterns:
• Deal with initializing and configuring classes and objects
Structural patterns:
• Deal with decoupling interface and implementation of classes and objects
• Composition of classes or objects
Behavioral patterns:
• Deal with dynamic interactions among societies of classes and objects
• How they distribute responsibility
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Benefits of Design Patterns
• Design patterns enable large-scale reuse of software architectures and also help document systems
• Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available
• Patterns help improve developer communication
• Pattern names form a common vocabulary
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Structure of Lecture 07
• What is it, why bother?
• Architecture Design
• Viewpoints and View Models
• Architectural Styles
• Architecture Assessment
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Architecture Evaluation/Analysis
• Assess whether architecture allows system to meet certain quality goals
• e.g. regarding maintainability, modifiability, reliability, performance, ...
• Note: the architecture is assessed, while we hope the results will hold for a system yet to be built
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Software Architecture Analysis
Software architecture
System
Properties Qualities
implementation
properties ?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Scenarios in Architecture Analysis
• Different types of scenarios, e.g. use-cases, likely changes, stress situations, risks, far-into-the-future scenarios
• Which stakeholders to ask for scenarios?
• When do you have enough scenarios?
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
List of Analysis Methods
• SAAM (Scenario-based Architecture Analysis Method)
• SAAMER (Software Architecture Analysis Method for Evolution and Reusability)
• ATAM (The Architecture Trade-Off Analysis Method)
• SBAR (Scenario-Based Architecture Reengineering)
• ... and many more ...
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Scenario-based Architecture Analysis Method (SAAM)
• Describe architecture(s)
• Based on desired system qualities, develop scenarios for
• kinds of activities the system must support
• kinds of changes anticipated
• Classify scenarios in direct & indirect
• direct -- execution of scenario requires no change of architecture
• indirect – execution of scenario requires change of architecture
• Evaluate indirect scenarios: list changes and estimate cost
• Reveal scenario interaction
• Overall evaluation
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Scenario-based Architecture Analysis Method (SAAM)
• List of scenarios
• Examples:
• User U1 wants to have added another feature
• Maintainer M1 wants to port the system to platform XYZ
• Maintainer M2 wants to change the look-and-feel of the GUI
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Scenario interaction in SAAM
• Two (indirect) scenarios interact if they require changes to the same component
• Scenario interaction is important:
Allocation of functionality:
• If semantically unrelated scenarios interact, decomposition is not proper. Semantically unrelated things are in the same component.
Level of decomposition of components:
• We may have to decompose the architecture further, to get smaller sub-components that do not interact.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Scenario-based Architecture Analysis Method (SAAM)
Overview: SAAM inputs and activities
Goal: By analysing the extend and difficulty (cost) of required changes (indirect scenarios) as well as the extent of scenario interactions, SAAM allows an insight to the future product capabilities, if the given architecture is chosen.
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Conditions for Successful Architecture Analysis/Evaluation
• Clear goals and defined quality requirements for the architecture
• Controlled scope – focus on most important goals and quality requirements
• Cost-effectiveness
• Key personnel availability – e.g. for scenario dev.
• Competent evaluation team – ideally independent from developers/owners of architecture
• Managed expectations
MTAT.03.094 / Lecture 07 / © Dietmar Pfahl 2013
Further Reading
• Mary Shaw and David Garlan, Software Architecture; Perspectives of an Emerging Discipline, 1995.
• Philippe B. Kruchten, The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November 1995.
• Frank Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, 1996. Part II: 2001.
• Erich Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1995.
• Len Bass et al, Sofware Architecture in Practice, 2008 (3rd edition).
• C. Hofmeister et al., Applied Software Architecture, 1999.
• Jan Bosch, Design & Use of Software Architectures, 2000.