Software Architecture

Dr. Prasad M. Jayaweera

prasad@dsv.su.se
 What is important to think about when
making a domain model.

To make models which show how the system should

consider the reality in terms of concepts and
relations among concepts. The concepts should be
taken from the problem domain. One should not use
class name and attribute of software classes not
included in problem domain. Of course, a concept
might become a software class in the design (this is
one of the ideas behind using domain models.) The
multiplicity has to constrain the domain model in a
way which corresponds to the reality.
 Shift in Focus

• The requirements and object-oriented analysis

focus on learning to “do the right thing”
(understanding the goals)
• Design work stresses to “do the thing right”; that
is, skilfully designing a solution to satisfy the
requirements for an iteration
• In iterative development a transition from
requirements/analysis focus to
design/implementation focus will occur in each
iteration
 Software Architecture

An architecture is the set of significant decisions

about the organization of a software system, the
selection of the structural elements and their
interfaces by which the system is composed,
together with their behavior as specified in the
collaborations among those elements, the
composition of these structural and behavioral
elements into progressively larger subsystems,
and the architectural style that guides this
organization
 Architecture Simplified

• Software Architecture has to do with the large

scale
• It describes the “Big Ideas” in the organization,
motivation, constraints, patterns,
responsibilities, and connections of a system
 Focus: Logical Architecture

• The large-scale organization of the software

classes into packages, subsystems and layers
• Logical, because there is no decision yet about
how these elements are deployed across
different operating system processes or across
physical computers in a network (see
Deployment Architecture)
 Layers

• A layer is a course-grained grouping of classes,

packages or subsystems that has cohesive
responsibility for a major aspect of the system.
• Layers are organized such that “higher” layers
call upon the services of “lower” layers, but not
normally vice versa.
 Typical Layers
• The User Interface
– Graphical Interfaces, Windows
• Application Logic and Domain Objects
– Software objects representing domain concepts that fulfill
application requirements, such as calculating a sale total
• Technical Services
– General purpose objects and subsystems that provide
supporting technical services, such as interfacing with a
database or error logging.
– These services are usually application independent and
reusable across several systems
 Strict or Relaxed

• In a strict layered architecture a layer only calls

upon the services of the layer directly below it
– Common in network protocol stacks
– Not so common in information systems
• In a relaxed layered architecture a layer may
call upon several lower layers.
 UML Package Diagrams

• Often used to illustrate the logical architecture of

a system. A layer can be modeled as a UML
package
• A UML package diagram provides a way to
group elements (classes, other packages, …)
• It is common to show dependency between
packages so that developers can see the large-
scale coupling in the system
A UML Package Diagram
 Design with Layers

• Organize the large scale logical structure of a system

into discrete layers of distinct, related responsibilities.
• Have a clean cohesive separation of concerns:
– Lower layers – low level, general services
– Higher layers – more application specific
• Collaboration and coupling from higher to lower layers;
avoid the other way around
• The purpose and number of layers varies across
applications and application domains
 ommon Layers in an
nformation System Architecture
 Without Layers…

• Source code changes are rippling throughout the

system since many parts of system are highly coupled
• Application Logic is intertwined with UI, so it cannot be
reused with a different interface
• General technical services are intertwined with more
application specific logic, so they cannot be reused or
easily replaced with a different implementation
• It is difficult to divide work along clear boundaries for
different developers.
 With Layers …

• Reduced coupling and dependencies

• Improved cohesion, clarity and reuse potential
• Higher Layers can be replaced with new
implementations (e.g. UI)
• Lower layers contain reusable functions
• Team development is aided by segmentation
Domain Model and Domain Layer
Relationship
 Partitions within a Layer

• Partitions represent a horizontal division of

relatively parallel subsystems of a layer
• Layers of an architecture represent the vertical
slices.
Layers and Partitions
 Model-View Separation Principle

• Model (domain) objects should not have direct

knowledge of view (UI) objects
– Do not connect or couple non-UI objects directly to
UI objects
• Domain classes encapsulate the information
and behavior related to application logic
– Do not put application logic in the UI objects’
methods.
– UI objects should delegate requests for application
logic to non-UI objects
 We M-V Separate to…

• Allow separate development of the model and UI

layers.
• Minimize impact of requirements changes in the
interface upon the domain layer
• Allow new views to be easily connected to an existing
domain layer (without affecting it)
• Allow multiple simultaneous views on the same model
object
• Allow easy porting of the model layer to another UI
 SSDs, System Events, Layers

• SSDs illustrate system events, but hide the

specific UI objects
• In praxis, UI objects will capture these system
operation requests - usually with a rich client
GUI or Web page
• The UI layer objects will then forward (delegate)
the request from the UI layer onto the domain
layer for handling
System Operations
 On to Object Design

• How should we design objects?

– Code
From mental model to code. Design-while coding (rather
discouraged)
– Draw, then code
Draw some UML, then switch to coding (our approach)
– Only draw
The tool generates everything from the diagrams
(wishful thinking?)
Static vs. Dynamic Modeling
 Dynamic Object Modeling

• Most of the challenging, interesting and useful

design work happens while drawing UML
interaction diagrams
– We think through the exact details of what objects
need to exist and how they collaborate via
messages and methods
• Often we will be drawing interaction and class
diagrams concurrently
 Other Techniques: CRC Cards

• Class Responsibility Collaboration cards

• Paper index cards on which one writes the
responsibilities and collaborators of classes
• Each card represents one class
• A CRC modeling session involves a group sitting
around a table, discussing and writing on the cards as
they play “what if” scenarios with the objects
– What the objects must do
– What other objects they must collaborate with
CRC Cards
Sample CRC Cards