CS616 – Software Engineering II

Lecture 11

Larman – Part5 – Elaboration: Iteration 3                                                 

Chapter 30 – Designing the Logical Architecture Patterns

·       Objectives

o      Design a logical architecture in terms of layers and partitions with the Layers pattern

o      Illustrate the logical architecture using UML package diagrams

o      Apply the Façade, Observer and Controller patterns

Software Architecture

·       Software architecture deals with the large scale system

·       Software architecture includes –

o      organization and major structure of the major elements of the system

o      system and subsystem behavior

o      collaborations


Architectural investigation

Identifying those functional and non-functional requirements that should have a significant impact on the system design


Architectural design

Resolution of requirements in the design of the software, the hardware and networking, etc.


Architectural Dimensions and Views in UP


·       Deployment Architecture – allocation of processes to processing units and network configuration


Architectural Patterns and Pattern Categories

Three Levels:

  1. Architectural Patterns - related to large-scale and course-grained design
  2. Design Patterns – related to small and medium scale design of objects and frameworks
  3. Idioms – language oriented low-level design solutions


Architectural Pattern : Layers










The purpose and number of layers varies across applications and application domains. Applied to information systems, typical layers look like this:




Partial layered architecture for NEXGEN application:




Inter-layer and Inter-Package Coupling

·       Include diagram that illustrates noteworthy coupling events between layers and packages

·       e.g. partial coupling between packages



Inter-Layer and Inter-Package Interaction Scenarios



Single Packages vs. Subsystems





System Operations and Layers



Upward Collaboration with Observer



The Model-View Separation Principle

·       What kind of visibility should other packages have to the Presentation Layer?

·       How should non-window classes communicate with windows?

·       Should be no direct coupling from other components to window objects


Model – Domain-Layer objects

View – presentation objects


·       The Model-View Separation principle: model objects should have no direct knowledge of of view objects

·                 e.g. Register object should not directly send message to a GUI window object ProcessSaleFrame asking it to display something


Model-View Separation and “Upward” Communication

·       Windows can obtain information to display by sending messages to domain objects => polling or pull-from-above

·       But polling is insufficient => push-from-below




Chapter 31 – Organizing the Design and Implementation Model Packages

·       Objectives

o      Organize Packages to reduce impact of changes


Package Organization Guidelines

·       GuideLine – Package Functionally Cohesive Vertical and Horizontal Slices

e.g. All NextGen Pricing package types are related to product pricing


·       GuideLine – Package a Family of Interfaces

e.g. Java EJB package javax.ejb has 12 interfaces in separate packages


·       GuideLine – Package by Work and by Cluster of Unstable Classes

e.g. packages are usually the basic unit of development work not classes


·       GuideLine – Most Responsible are most stable

e.g. lowest-level classes are most stable


·       GuideLine – Factor out Independent Types

Organize types that can be used independently or in different contexts into separate packages


·       GuideLine – Use Factories to Reduce Dependency on Concrete Packages

Reduce dependency on concrete classes in other packages


·       GuideLine – No Cycles in Packages

If a group of packages have cyclic dependency they should be treated as one larger package


Chapter 32 – Introduction to Architectural Analysis and SAD


·       Create architectural factor tables

·       Create technical memos that record architectural decisions

·       Know basic principles for architectural design

·       Know resources for learning architectural patterns


·       UP records architectural factors in Supplementary Specification

·       Architectural Decisions recorded in Software Architecture Document (SAD)


Architectural Analysis

1.     Identify and analyze the non-functional requirements that have an impact on the architecture

2.     For requirements with a significant architectural impact, analyze alternatives and create solutions that resolve the impact


The Science: Identification and Analysis of Architectural Factors

·       Architectural Factors

o      Strongest architectural Factors – high level FURPS+ categories:

§       Functionality

§       Reliability

§       Performance

§       Supportability

§       Implementation

§       Interface

·       Quality Scenarios

o      Define measurable or observable responses

o      Quality scenarios are short statements of the form <stimulus> <measurable response>

e.g. When a bug report arrives from the NextGen beta test volunteer, reply with a phone call within 1 working day


Summary of themes in Architectural Analysis

  1. Architectural concerns are related to non-functional requirements and include an awareness of the business context
  2. Architectural concerns involve system-level, large-scale and broad problems whose resolution usually involves large-scale or fundamental design decisions
  3. Interdependencies and trade-offs
  4. Generation and and evaluation of alternative solutions

Architectural Analysis within UP

Six Views:

  1. Logical

Conceptual organization of the software in terms of most important layers, subsystems, packages, frameworks, classes, and interfaces

  1. Process

Process and threads wrt responsibilities, collaborations, and allocation of logical elements

  1. Deployment

Physical deployment of processes and components to processing nodes, and the physical network configuration between nodes

  1. Data

Overview of persistent data schema and their mappings to database objects

  1. Use Case

Summary of most architecturally significant use cases and their non-functional requirements

  1. Implementation

Actual source code and executables


When to Create an Architectural View

·       After the system is built – as a summary

·       At the end of each iteration (e.g. elaboration I, II, III, …)

·       Speculatively, during each iteration, as an aid to creative design


Sample Structure of SAD

·       Architectural Representation

Summary of how the architecture will be described in this document

·       Architectural Factors and Decisions

Reference to the Supplementary Specification

·       Logical View

UML package diagrams and class diagrams of major elements

·       Process View

UML class and interaction diagrams illustrating the processes and threads of the system

·       Use-Case View

Brief summary of most architecturally significant use cases, UML interaction diagrams for some use cas realizations with commentary

·       Deployment View

UML deployment diagrams showing the nodes and allocation of processes and components