Systems and Software Architecture: an introduction to architectural modelling

Ingeniería del Software-Arquitectura de sistemas software
1Jose María Álvarez Rodríguez
An introduction to
architectural modeling
Software Engineering
Jose María Álvarez Rodríguez
Course 2018/2019
Software Engineering-Systems and Software architecture

First questions
What is an architecture?
Any example of architecture?
What is a software architecture?
Who affects a software architecture?
What is the role of a software
architect?
How a software architecture is
described and documented?

Notion of architecture (Oxford dictionary)
Domains:
• Civil architecture
• Military architecture
• Hydraulic architecture
• Naval architecture
• Sacred architecture
• …
3
1
2
The art or practice of designing and
constructing buildings.
The style in which a building is
designed and constructed, especially
with regard to a specific period,
place, or culture.
The complex or carefully designed
structure of something.

Software Engineering-Systems and
Software architecture
Architecture and architects

What is the role of an architect?
Stakeholders
• Person, group or entity
• User, client or affected by
Design an infrastructure
• Needs
• Legal framework
• Security, economical, etc.
restrictions
• Art, Science and Engineering
Use cases
• Exploitation
• Enjoy
• …
Holistic/complete view
• All elements
• All relationships
• All interactions

Definition of software architecture
Software
Architecture
Relationships
Structural (static)
Interactions (Dynamic)
Provision
Products and services to a domain
High-level view of an infrastructure
Subsystems and components
Restrictions
Quality, legal, economical, etc..
Use cases
Reach goals
Stakeholders
Meet needs
“<system> fundamental concepts or properties of a system in its
environment embodied in its elements, relationships, and in the
principles of its design and evolution.”
Source: ISO/IEC/IEEE 42010:2011 Systems and software engineering —Architecture description
Complexity Management

A complex software system: Smart cars
Who are the stakeholders?
Which are their goals?
How goals are reached?

On-going example: Github
Learn more: https://github.com/
Community Social network
Projects Repositories
• Creation of community of
interest
• Groups
• Organizations
• Project management
• Agile techniques
• Documentation
• Toolchain integration
• Social platform to manage
the lifecycle of a software
Project
• Developers
• Repository and source code
management
• Versioning, “commits”,
“issues”, etc.

A software architecture as a System of Systems
System of Systems (SoS)
A system of systems (SoS) brings together a set of systems for a task
that none of the systems can accomplish on its own. Each constituent
system keeps its own management, goals, and resources while
coordinating within the SoS and adapting to meet SoS goals.
Fuente: ISO 15288:2015
Data management
Representation, storage and
access.
Repository management
Git protocl
Authentication
User management
Social network
Relationships
Software distribution
Release management
Graphical user interface
Depending on functionality
and end-user

Agreement
Processes
Organizational Project-
Enabling Processes
Technical Management
Processes
Project Planning Process
(Clause 6.3.1)
Project Assessment and
Control Process (Clause
6.3.2)
Risk Management
Process (Clause 6.3.4)
Decisión Management
Configuration
Management Process
(Clause 6.3.5)
Information Management
Measurement Process
(Clause 6.3.7)
Acquisition Process (Clause
6.1.1)
Supply Process (Clause
6.1.2)
Life Cycle Model
Management Process
(Clause 6.2.1)
Infrastructure
Management Process
(Clause 6.2.2)
Portfolio Management
Technical Processes
Bussiness or Mission
Analysis Process (Clause
6.4.1)
Stakeholder Needs &
Requirements Definition
Architecture Definition
System Requirements
Definition Process
(Clause 6.4.3)
Design Definition Process
(Clause 6.4.5)
System Analysis Process
(Clause 6.4.6)
Implentation Process
(Clause 6.4.7)
System Life Cycle Processes
ISO 15288:2015 10

Principles of a software architecture
Business
• Maximize benefits
• Corporate commitment and business
continuity
• Responsibility, law and ethics
Data management
• Shared and accessible asset
• Common vocabulary
• Security
Applications
• Technological-neutral approach
• Ease to use
Technical
• Requirements and change
management
• Interoperability, performance,
etc.

Definitions
Any software system has an architecture even if it is unknown or not documented...
It is the structure or structures of the
system, which comprise software
elements, the externally visible
properties of those elements, and
the relationships among them.
Software
Architecture
Static
structure
Dynamic
structure
Quality
property
Architectu-
ral
element
Architectural
description
It defines its internal
design-time elements and their
arrangement
It defines its runtime
elements and their interactions.
It is an externally visible,
nonfunctional property of a system
such as performance, security, or
scalability.
It is a fundamental
piece from which a system can be
considered to be constructed.
It is a set of products that
documents an architecture in a way
its stakeholders can understand
and demonstrates that the
architecture has met their concerns
See original definition in [1].

Description of a software architecture
A stakeholder in a software architecture is a person,
group, or entity with an interest in or concerns about
the realization of the architecture.
Stakeholder
A view is a representation of one or more structural aspects of
an architecture that illustrates how the architecture addresses
one or more concerns held by one or more of its stakeholders
View
An abstract representation of a process,
activity o physical reality.
Model
A concern about an architecture is a requirement, an
objective, an intention, or an aspiration a stakeholder has
for that architecture.
Concern
A viewpoint is a collection of patterns, templates, and
conventions for constructing one type of view.
Viewpoint
01
02
03
04
05
See original definitions in [1].

See original model in [1].

Documenting a software architecture: the 4+1 view model by Krutchen [2]
Logical view Development view
Process view Physical view
Scenarios
See original document in [2].

On-going example: Github scenarios
Active user
Create repository
Make login
«uses»

The 4+1 view model by Krutchen: logical view
End-users
Stakeholders
Class and/or component
diagram UML
Notation
Information model
Concern
Functional
Requirements

On-going example: a class diagram for Github
User
Organization TeamRepository
Commit
File
Issue
Comment
1
1..*
1
*
1
*
1
*
1
*
1 *
1
*
1 *
1..*
*

On-going example: a component diagram for Github
Business
Datos
User interface & API
External services
Cross-cutting
services
GUI User GUI Repository API
User Manager Repo Manager
Data manager
Auth GIT protocol
Social Network
Google Auth
Security
...

The 4+1 view model by Krutchen: process view
System integrators
Stakeholders
Sequence diagram in UML
Other UML diagrams: activity,
communication, etc.
Notation
Concurrency,
synchronization
Interaction
Concern
Performance
Availability
Reliability
Concurrency
Distribution
Security
Requirements

Ingeniería del Software-Arquitectura de sistemas software
On-going example: a sequence diagram for Github
:User Manager :Auth
Registered user
login(credentials)
validate(credentials)
user
:Repo Manager
create_repository(user, repo_data)
:Data Manager
Active user
:User Manager
get_info(user)
user_info
validate(user_info,repo_data)
new_repository(user, repo_data)
OK()

The 4+1 view model by Krutchen: physical view
IT engineers
Stakeholders
Deployment diagram
in UML
Notation
Mapping software-
hardware
Concern
Performance
Availability
Reliability
Scalability
Topology
Communications
Requirements

On-going example: a deployment diagram for Github
:jboss
User Manager
Repo Manager Auth
GIT protol
Social Network
:arangodb
Data manager
:tomcat
GUI User
GUI Repository
API
https https

The 4+1 view model by Krutchen: development view
Developers
Stakeholders
Component and/or
package diagram in
UML
Notation
Software
organization in the
development
environment
Concern
Software management
Reuse
Portability
Maintainability
Platform and technological
restrictions
Requirements

The 4+1 view model by Krutchen: summary
Logical
(conceptual)
Process
(runtime)
Development
(implementation)
Physical
(deployment)
Stakholders Information model
Concurrency,
synchronization
Interaction
Software organization in
the development
environment
Mapping software-
hardware
Concern End-users System integrators Developers IT engineers
Requirements Functional
Performance
Availability
Reliability
Concurrency
Distribution
Security
Software management
Reuse
Portability
Maintainability
Platform and technological
restrictions
Performance
Availability
Reliability
Scalability
Topology
Communications
Notation
Class and/or component
diagram in UML
Sequence diagram in UML
Component and/or package
diagram in UML
Deployment diagram in
UML

Other view models: Rozanski & Woods [1]

Main risks of a multiple view model
• It is necessary to make a decision of which view are more adequate
• Dependencies among the different system concerns
• In general, a good architecture depends on experience and skills
Wrong
views
• Kruchten 4-1 and Rozanski-Woods 6
• A view → creation and maintenance costs (consistency)
• Join view for the shake of simplicity
Fragmenta-
tion
• All views must be consistent, they represent the same system
• Maintenance costs to keep consistency
• An scenario → process → components → classes
• Establish the proper dependencies to calculate the impact of a change.
Inconsis-
tency

See original description in [1].

Some questions to think about…
How can I build
relationships between
different views?
Why architecture and
architecture descriptions?
What is the relationship
with reverse
engineering?
What is the relationship
with forward engineering?

Known-problems in a software architecture
Software architecture re-definition
Erosion
Add new design decisions not
included in the initial model
Violate existing models
Drift
Add new design decisions not
included in the initial model
Do not violate existing models

A good enough software architecture…
It shall meet the needs of the
stakeholders.
All functional and non-
functional requirements
cannot be specified in just one
iteration.
It shall communicate the
relevant concerns to the
proper stakeholders.

A good enough software architecture…
Cohesion
A measure of the strength of association of the
elements within a module. (ISO/IEC/IEEE
24765)
-Intra-module functionality
Preferred value: high
Coupling
A measure of the interdependence among
modules in a computer program. (ISO/IEC/IEEE
24765)
-Inter-module dependencies
Preferred value: low

First questions: any answer?
What is an architecture?
Any example of architecture?
What is a software architecture?
Who affects a software architect?
What is the role of a software
architect?
How a software architecture is
described and documented?

•Make a description of an existing software system
•E.g.: Twitter, Instagram, Linkedin, etc.
Objective
• Work in groups
• 2-3 people
• 20 minutes
Method
• Use case, class and component diagramsOutcome
• Presentation and discussion
• 2 groups (volunteers?)
• 10 minutes
Evaluation
Task

1-minute quizz questions (Aulaglobal)
a) Architecture is defined by the recommended practice as the fundamental organization
of a system, embodied in its components, their relationships to each other and the
environment, and the principles governing its design and evolution.
b) Architecture is defined by the recommended practice as the functional organization of
a system.
c) Architecture is defined by the recommended practice as the fundamental organization
of a system.
d) None of the answers is correct.
Q1:A definition of “software architecture”…
a) Represents the system from the developer perspective with a class diagram.
b) Represents the system from the developer perspective with a component or
package diagram.
c) Represents the interactions between system components through a component
diagram.
d) a) and b) are correct.
Q2: In the 4+1 model, the development view…
a) Fragmentation
b) Inconsistencies
c) Too much views
d) All of them are problems.
Q3: Which is an issue of having multiple views
of an system?

Software Engineering-Systems
and Software architecture
Summary

References and specific resources
[1] N. Rozanski and E. Woods, Software systems architecture: working with stakeholders using
viewpoints and perspectives, 2nd ed. Upper Saddle River, NJ: Addison-Wesley, 2012.
[2] P. B. Kruchten, “The 4+1 View Model of architecture,” IEEE Softw., vol. 12, no. 6, pp. 42–50, Nov.
1995.
-Section “6.1 Architectural design decisions” from “Software Engineering 10th Edition”, I.
Sommerville, 2016.
-Section “6.2 Architectural views” from “Software Engineering 10th Edition”, I. Sommerville, 2016.

Systems and Software Architecture: an introduction to architectural modelling

More Related Content

What's hot (20)

Similar to Systems and Software Architecture: an introduction to architectural modelling (20)

More from CARLOS III UNIVERSITY OF MADRID (20)

Recently uploaded (20)

Systems and Software Architecture: an introduction to architectural modelling