SWEN30006
Software Design and Modelling
Architectural Analysis and Logical Architecture
Textbook: Larman Chapter 13, 33 and 38.2
“Error, no keyboard – press F1 to continue.” —early PC BIOS message
Learning Objectives
On completion of this topic you should be able to:
• Create architectural factor tables.
• Create technical memos that record architectural decisions.
• Define a logical architecture using layers.
• Illustrate the logical architecture using UML package diagrams.
4
(Revisited) Software Design
Weeks 3-9: The principles and approaches of the software classes in the application logic layer should be structured and interacting with each other.
• GRASP: Fundamental principles of assigning responsibilities, while concerning the maintainability of the system
• GoF patterns: a set of patterns to address specific problems, while achieving GRASP principles.
This week: A more holistic view of the system.
5
Software Architecture
Definition: Software Architecture is the large-scale organization of elements in a software system.
• A design that concerns whether the system will align with business logic and be easy to maintain and evolve
Software Architecture involves a set of significant decisions which concern:
• Structural elements: How should the software classes/components be in the
system?
• Interfaces: How should each element is composed altogether?
• Collaboration: How should these elements work together according to the business logic?
• Composition: How should these elements be grouped progressively into larger subsystems?
6
Why Software Architecture is important?
Design the system based on partial Design the system without focusing sets of requirements on the business logic
7
Today Topics
• ArchitecturalAnalysis
– Identifying the important factors
• LogicalArchitecture
– Organizing software elements
8
Architectural Analysis
Architectural Analysis
Definition: An activity to identify factors that will influence the architecture, understand their variability and priority, and resolve them
• To identify and resolve system’s non-functional requirements in the context of its functional requirements
Goal: To reduce risk of missing a critical factor in the design of a system, focuses effort on high priority requirements, and aligns the product with business goals
Architectural Analysis includes identifying and analysing:
– Architecturally significant requirement: The requirement that can have a large impact on the design (especially when it was not considered at the beginning)
– Variation points
– Potential evolution points
10
Examples: Architecturally Significant Functional Requirements
Function Description
Auditing Provide audit trails of system execution.
Licensing Provide services for tracking, acquiring, installing, and monitoring license usage.
Localization Provide facilities for supporting multiple human languages.
Mail Provide services that allow applications to send and receive mail.
Online help Provide online help capability.
Printing Provide facilities for printing.
Reporting Provide reporting facilities.
Security Provide services to protect access to certain resources or information.
System management Provide services that facilitate management of applications in a distributed environment.
Workflow Provide support for moving documents and other work items, including review and approval cycles.
Capturing Architectural Requirements
11
Examples: Architecturally Significant Non-Functional Requirements
• Usability
– e.g. aesthetics and consistency in the UI.
• Reliability
– e.g. availability (the amount of system “up time”), accuracy of system calculations,
and the system’s ability to recover from failure.
• Performance
– e.g. throughput, response time, recovery time, start-up time, and shutdown time.
• Supportability
– e.g. testability, adaptability, maintainability, compatibility, configurability, installability, scalability, and localizability.
Capturing Architectural Requirements
12
Effects of requirements on design
Examples of how the requirements can affect the design decision.
• Reliability and fault-tolerance requirements:
– Ex: POS uses remote services (e.g., tax calculator). Will the remote services failover
to local services be allowed?
• Adaptability and configurability requirements:
– Ex: What if we want to sell POS to many retailers but they have variations in
business rules. Can the retailers change the rules? Should POS be configurable?
• Brand name and branding requirements:
– Ex: Retailers want to put their own brand in the POS user interfaces. Can the
branding be changed in POS?
The design can be significantly changed based on the answer of this question.
13
Common Steps in Architectural Analysis
Steps (occurs in early elaboration):
1. Identify/analyse architectural factors: requirements with impact on the architecture
(especially non-functional requirements)
• overlaps with requirements analysis
• some identified/recorded during inception, now investigated in more detail
2. For the architectural factors, analyse alternatives and create solutions: architectural decisions
• e.g. remove requirement; custom solution; stop project; hire expert
16
1. 2.
3.
Priorities
Inflexible constraints
– e.g. safety; security, legal compliance
Business goals
– e.g. demo for clients: tradeshow in 18 months
– e.g. competitor-driven window-of-opportunity
Other goals
– requirements all relate back to higher-level goals, and eventually to business goals
– e.g. extendible → new release every 6 months
17
Architectural Factor Table
A documentation that records the influence of the factors, their priorities, and their variability (immediate need for flexibility and future evolution)
1. Factor
2. Measures and quality scenarios
3. Variability (current flexibility and future evolution)
4. Impact of factor (and its variability) on stakeholders, architecture and other factors
5. Priority for success
6. Difficulty or risk
18
Example: Architecture Factor Table
Reliability—Recoverability of POS
Factor
Measures and quality scenarios
Variability (current flexibility and future evolution)
Impact of factor (and its variability) on stakeholders, architecture and other factors
Priority for Success
Difficulty or Risk
Recovery from remote service (e.g., Tax Calculator) failure
When remote service fails, re-establish connectivity with it within 1 min. of its detected re-availability, under normal store load in a production environment.
current flexibility – our SME says local client-side simplified services are acceptable (and desirable) until reconnection is possible.
evolution – within 2 years, some retailers may be willing to pay for full local replication of remote services (such as the tax calculator). Probability? High.
High impact on large-scale design. Retailers really dislike it when remote services fail, as it prevents them from using a POS to make sales.
High
Medium
19
Technical Memo
A documentation that records alternative solutions, decisions, influential factors, and motivations for the noteworthy issues and decisions
1. Issue
2. Solution Summary
3. Factors
4. Solution
5. Motivation
6. Unresolved Issues
7. Alternatives Considered
20
Example: Technical memo
Technical Memo: Issue: Reliability—Recovery from Remote Service Failure Factors
Robust recovery from remote service failure, e.g., tax calculator, inventory Solution
To satisfy the quality scenarios of reconnection with the remote services ASAP, use smart Proxy objects for the services, that on each service call test for remote service reactivation, and redirect to them when possible.
Where possible, offer local implementations of remote services. For example, implementing a small cache to store data (e.g., tax rates)
Achieve protected variation with respect to location of services using an Adapter created in a ServicesFactory.
21
Example: Technical memo (cont)
Motivation
Retailers really don’t want to stop making sales! Therefore, if the
NextGen POS offers this level of reliability and recovery, it will be a very attractive product, as none of our competitors provide this capability.
The small product cache is motivated by very limited client-side resources. The real third-party tax calculator is not replicated on the client primarily because of the higher licensing costs, and configuration efforts (as each calculator installation requires almost weekly adjustments).
This design (Adapter and ServiceFactory) also supports the evolution point of future customers willing and able to permanently replicate services such as the tax calculator to each client terminal.
Unresolved Issues
none
Alternatives Considered
A “gold level” quality of service agreement with remote credit authorization services to improve reliability. It was available, but much too expensive.
22
Summary of Architectural Analysis
1. Concerns are especially related to non-functional requirements with awareness of business context, but addressing functional requirements and their variability.
2. Concerns involve system-level, large-scale, broad problems, with resolution involving large-scale or fundamental design decisions.
3. Must address interdependencies and trade-offs (e.g. security/performance, or anything/cost)
4. Involves the generation/evaluation of alternatives.
23
Logical Architecture
Logical Architecture
Business Modeling
Require- ments
Domain Model
* *
Use-Case Model
Vision
Supplementary Specification
Glossary
Logical Architecture (LA) – Definition:
The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.
The large-scale organisation of the software classes into packages, subsystems and layers
– Not concerned with networking, physical computers, or operating system processes (such concerns are for the deployment architecture)
LA defines the packages in which software classes are defined.
Design Model
The packages are organized in layers
Design
interaction diagrams (a dynamic view)
enterItem (itemID, quantity)
package diagrams of the logical architecture
(a static view)
Software classes are grouped into a package
UI
Domain
Tech Services
: Register
: ProductCatalog
class diagrams (a static view)
1
1
Register
spec = getProductSpec( itemID )
ProductCatalog
…
…
makeNewSale() enterItem(…)
…
getProductSpec(…) …
26
Layered Architecture
Layers – Definition: Coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major aspect of the system.
•
– –
–
Example layers: User Interface.
Application Logic and Domain Objects—software objects representing domain concepts (Sale class) that fulfill application requirements.
Technical Services—general purpose objects and subsystems that provide supporting technical services (e.g., interfaces with DB)
Strict layered architecture: A layer only calls upon the services of the layer directly below it (e.g., a network protocol stack), not common in information systems
Relaxed layered architecture: A higher layer calls upon several lower layers. Common in IS. 27
Layers and Partitions
UML Package diagram is used to illustrate the Logical Architecture
UI
not the Java
Swing libraries, but our GUI classes based on Swing
Swing
Web
Software elements are organized into layers, i.e., Layered Architecture
Dependency, i.e., UI classes uses Domain classes
Domain
Sales
Payments
Taxes
Technical Services
Logging
Partitions
Relaxed Layered Architecture: A higher layer call upon the lower layer (not the directly below one)
**UML Packages Notation is provided in Workshop supplementary materials
28
Persistence
RulesEngine
Common Layers: IS Logical Architecture
GUI windows
reports
speech interface
HTML, XML, XSLT, JSP, Javascript, …
handles presentation layer requests
workflow
session state
window/page transitions
consolidation/transformation of disparate data for presentation
handles application layer requests
implementation of domain rules
domain services (POS, Inventory)
– services may be used by just one application, but there is also the possibility of multi-application services
very general low-level business services used in many business domains
CurrencyConverter
(relatively) high-level technical services and frameworks
Persistence, Security
low-level technical services, utilities, and frameworks
data structures, threads, math, file, DB, and network I/O
more app specific
UI
(AKA Presentation, View)
Application
(AKA Workflow, Process, Mediation, App Controller)
Domain
(AKA Business, Application Logic, Model)
Business Infrastructure
(AKA Low-level Business Services)
Technical Services
(AKA Technical Infrastructure, High-level Technical Services)
Foundation
(AKA Core Services, Base Services, Low-level Technical Services/Infrastructure)
width implies range of applicability
29
dependency
Guidelines:
• Organise large-scale logical structure of system into distinct cohesive layers from high application specific to low general services
– Maintain separation of concerns, e.g. No application logic in UI objects
• Collaboration and coupling from higher layers to lower layers. Lower to higher layer coupling is avoided.
• Don’t Show External Resources as the Bottom Layer
30
Examples: Logical Architecture
Worse
mixes logical and deployment views
Domain(s)
Technical Services
Foundation
Better
a logical view
Domain(s)
POS
Technical Services
Inventory
a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database.
Web AppFramework
MySQL Inventory
«component» Novell LDAP
Persistence
Foundation
Naming and Directory Services
UML notation: A UML component, or replaceable, modular part of the physical system UML notation: A physical database in the UML.
31
System Operations: SSDs and Layers
: Cashier
UI Actions
: Cashier
Method Calls
Façade
Controller
makeNewSale() enterItem(id, quantity) description, total
endSale()
Swing
UI
makeNewSale() enterItem() endSale()
…
Process Sale Frame
Domain
makeNewSale() enterItem() endSale()
…
Register
makeNewSale() enterItem()
…
System Operations
:Sy stem
the system operations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layer
32
Benefits of Layered Architecture
Using layers helps address the following problems:
• Changes rippling through system due to coupling
• Intertwining of application logic and UI, reducing reuse and restricting distribution options
• Intertwining of general technical services or business logic with application specific logic, reducing reuse, restricting distribution, and complicating replacement
• High coupling across areas of concern, impacting division of development work
33
Implementation View Architecture
• Component is a modular part of a system that encapsulates its contents and replaceable within its environment
• Component Diagram
– Concerns on how to implement the software system in high level
– Provides the initial architecture landscape for the system
– Defines its behaviour in terms of provided and required interfaces
• How is this different from a class?
– It can be a class! External resources (e.g., DB) and services are also considered as a component
34
UML Components
alternate notation to indicate using or requiring an interface.
«component» DB
SQL
JMS
Interface Standards:
• SQL (Structured Query Language) • JMS (Java Message Service)
alternate notation for a component
«system» NextGen
MessagingService
**UML Component Notation is provided in Workshop supplementary materials
35
UML Component Example
http://agilemodeling.com/artifacts/componentDiagram.htm
36
• • •
• •
•
Summary and Remarks
Software Architecture concerns on a high-level organization of software elements in the system and how the element collaborate to address the business logic
Architectural Analysis is an activity of analyzing requirements (especially the non-functional requirements) to identify the factors that can have an impact on the design
Logical Architecture (LA) is the large-scale organisation of the software classes UML Package diagram illustrate the logical architecture
The logical architecture can organize software classes in layers (i.e., Layered Architecture)
UML Component diagram provide a high-level implementation view of the architecture which consider the external services (e.g., databases)
37
Lecture Identification
Lecturer: Philip Dart
Semester 1, 2021
© University of Melbourne 2021
These slides include materials from:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, by Craig Larman, Pearson Education Inc., 2005.