This is an introductory lecture to Software Architecture, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
Software architecture and software design are two aspects of the same topic. Both are about how software is structured in order to perform its tasks. The term "software architecture" typically refers to the bigger structures of a software system, whereas "software design" typically refers to the smaller structures.
Unified Modeling Language (UML) is a modeling language, used for design. Designed based on OMG Standard, Object this helps to express and design documents, software. This is particularly useful for OO design. Here is a brief tutorial that talks about UML usage.
Software architecture and software design are two aspects of the same topic. Both are about how software is structured in order to perform its tasks. The term "software architecture" typically refers to the bigger structures of a software system, whereas "software design" typically refers to the smaller structures.
Unified Modeling Language (UML) is a modeling language, used for design. Designed based on OMG Standard, Object this helps to express and design documents, software. This is particularly useful for OO design. Here is a brief tutorial that talks about UML usage.
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
Describes the basic activities of software engineering - specification, design and implementation, validation and evolution.
Accompanies video:
https://www.youtube.com/watch?v=Z2no7DxDWRI
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
[2015/2016] Introduction to software architectureIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
Software Architecture: views and viewpointsHenry Muccini
This is an introductory lecture to Software Architecture Views and Viewpoints, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)
Describes the basic activities of software engineering - specification, design and implementation, validation and evolution.
Accompanies video:
https://www.youtube.com/watch?v=Z2no7DxDWRI
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
[2015/2016] Introduction to software architectureIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
[2016/2017] Introduction to Software ArchitectureIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
[2017/2018] Introduction to Software ArchitectureIvano Malavolta
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
I translate Framework Design Guideline to Korean.
This Book is very impressed to me.
So I want to share Krzysztof Cwalina's Knowledge.
I re-edit his presentation and add my opinion.
Slides for my architectural session at the event: Docker From Zero To Hero.
We talked about what kind of expertises are need in order to build a true Microservices Solution; you'll need to understand some of the fundamentals on which Microservices is built upon: SOA, EDA and DDD just to name a few, then you can move to the container world.
Original event link: https://www.eventbrite.it/e/biglietti-docker-from-zero-to-hero-83372825365#
Ask 5 Software Architects for a definition of Software Architecture and you'll get 10 definitions. However definition important to understand responsibilities, skills requirements and activities. Furthermore, separation of Software Architecture and Application Design has many practical benefits.
This presentation covers both the Cloud Foundry Elastic Runtime (known by many as just "Cloud Foundry") as well as the Operations Manager (known by many as BOSH). For each, the main components are covered with interactions between them.
These slides have been presented at the ICSE 2020 conference, SEIS (software engineering in society) track. It reports on our experience within the Uffizi Project, and how we had to take into account human behaiour to design our IoT-based solution.
How cultural heritage, cyber-physical spaces, and software engineering can wo...Henry Muccini
This is a seminar provided to a PhD school on Cultural Heritage Conservation and Valorization.
The focus has been on the interdisciplinarity among cultural heritage, cyber-physical spaces, and software engineering.
Turismo 4.0: l'ICT a supporto del turismo sostenibileHenry Muccini
The importance of sustainable tourism is today very clear, as also highlighted by some national and international organizations. This presentation highlights the role of ICT in the context of sustainable tourism. Some ongoing projects are presented as well.
Sustainable Tourism - IoT and crowd managementHenry Muccini
What is Sustainable Tourism and how IoT may help to reduce crowd management. This material reports on our experience within the Uffizi Galleries project and the CAPS IoT modeling and simulation framework.
Software Engineering at the age of the Internet of ThingsHenry Muccini
This is an overview on Sw Engineering the IoT, created for the FOI, Faculty of Organization and Informatics of the University of Zagreb, and presented during their International Days.
The influence of Group Decision Making on Architecture Design DecisionsHenry Muccini
Group Decision Making influcencs Architecture Design Decisions. This presentation, given as a keynote at the MARCH 2019 workshop (https://is.ieis.tue.nl/research/bpm/MARCH/index.php/keynote/), tries to identifies GDM factors that influence architecture design decisions.
Web Engineering L8: User-centered Design (8/8)Henry Muccini
This lecture focusses on User-centered Design (UCD). It covers the "The Elements of User Experience" book by Garrett.
The topics covered are:
- the UCD process
- Personas
- Scope
- Information Architecture
- Sitemaps
- Wireframes
- Prototypes
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications. The list is availabe at https://trello.com/b/z49P8z3b
Web Engineering L7: Sequence Diagrams and Design Decisions (7/8)Henry Muccini
This lecture covers Sequence diagrams and Design decision models. It covers:
- sequence diagrams in UML 2.x
- the QOC model for design decisions
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications. They are listed at https://trello.com/b/z49P8z3b
Web Engineering L6: Software Architecture for the Web (6/8)Henry Muccini
This lecture discusses Architectural aspects of Web engineering.
It covers:
- software architecture design
- software architecture for the web
- component model for software architecture description
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Web Engineering L5: Content Model (5/8)Henry Muccini
This lecture focusses on Content Design.
It presents the UWE approach for producing the:
- Conceptual Model
- Navigation Space Model
- Navigational Structure Model
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Web Engineering L3: Project Planning (3/8)Henry Muccini
This lecture focusses on project planning.
It focuses on:
- work breakdown
- project planning
- PERT
- Critical Path
- Project Tracking and Estimation
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Web Engineering L2: Requirements Elicitation for the Web (2/8)Henry Muccini
This lecture focusses on requirements elicitation.
It covers:
- Requirements discovery
- Requirements classification
- Requirements Prioritization
- Requirements Specifications
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Web Engineering L1: introduction to Web Engineering (1/8)Henry Muccini
This lecture makes an introduction to Web Engineering.
- Why web engineering
- Quality
- Issues to avoid
- Web architectures
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Web Engineering L4: Requirements and Planning in concrete (4/8)Henry Muccini
This lecture summarizes and extends L3, with a focus on:
- Critical Path
- Agile for Planning
- Convergence and divergence
The output of this course consists in a list of artifacts and principles to be used when engineering Web applications is listed at https://trello.com/b/z49P8z3b
Collaborative aspects of Decision Making and its impact on SustainabilityHenry Muccini
In this talk I made an effort to link together sustainability, architecture design decision, and group decision making. Take a look and contact me for questions.
This presentation proposes CAPS, an architecture-driven
modeling framework for the development of Situational Aware
Cyber-Physical Systems.
Situational Awareness involves being aware of what is
happening in the surroundings, and using this information
to decide and act. It has been recognized as a critical,
yet often elusive, foundation for successful decision-making
in complex systems. With the advent of cyber-physical systems
(CPS), situational awareness is playing an increasingly
important role especially in crowd and fleets management,
infrastructure monitoring, and smart city applications. While
specializing cyber physical systems, Situational Aware CPS
requires the continuous monitoring of environmental conditions
and events with respect to time and space. New architectural
concerns arise, especially related to the sense , compute &
communication paradigm, the use of domain-specific hardware
components, and the cyber-physical space dimension.
This work illustrates the CAPS modeling languages used
to describe the software architecture, hardware configuration,
and physical space views for a situational aware CPS.
I progetti UnivAq-UFFIZI, INCIPICT, e CUSPISHenry Muccini
Alcuni progetti dell'Universita' degli Studi dell'Aquila volti al supporto dei beni culturali. Tale presentazione e' stata fornita nel contesto dell'evento Le Gallerie degli Uffizi incontrano UnivAq
Exploring the Temporal Aspects of Software ArchitectureHenry Muccini
The keynote lecture video is now available at http://www.icsoft.org/KeynoteSpeakers.aspx?y=2016
This presentation covers the main topics discussed by the software architecture conferences in the past 15+ years. It provides a systematic, unbiased view on research trends with reflections on the future challenges.
This speech has been provided as a keynote at ICSOFT 2016.
Exploring the Temporal Aspects of Software Architecture
Software Architecture: Introduction
1. L01: Intro to Software Architecture
Vittorio Cortellessa & Henry Muccini
DISIM Department, University of L’Aquila
vittorio.cortellessa@univaq.it;henry.muccini@univaq.it
2. The material in these slides may be freely reproduced
and distributed, partially or totally, as far as an explicit
reference or acknowledge to the material author is
preserved.
SEA Group
3. Intro to SA Intro to Software Testing
Lab Structural Testing
SA style Model-based Testing
ADLs Architecture-based Testing
Design Decisions
Lab
Views/Viewpoints
UML Non Functional S.E.
UML Profiling Performance modeling
Lab Performance analysis
SEA Group
9. Software Architecture
The Software Architecture is the earliest model
of the whole software system created along the
software lifecycle
“Traditional” definition:
→A set of components and connectors communicating through
interfaces
“Recent/Future” understanding:
→A set of architecture design decisions taken to generate the
architecture artifact
→Focus on set of Views and Viewpoints, looking at
stakeholders and their concern
SEA Group
10. Software Architecture definitions
Perry and Wolf, ’92 (aspects):
→“Architecture is concerned with the selection of architectural elements, their
interactions, and the constraints on those elements and their interactions necessary
to provide a framework in which to satisfy the requirements and serve as a basis for
the design.”
→Elements are divided into processing elements, data elements and connection
elements
Garlan and Shaw, ’93 (elements):
→ Architecture for a specific system may be captured as “a collection of
computational components - or simply components - together with a description of
the interactions between these components - the connectors -”
Sommerville, 7th edition, ’04 (process):
→ The design process for identifying the sub-systems making up a system and the
framework for sub-system control and communication is architectural design. The output
of this design process is a description of the SA.
SEA Group
11. Application Example
“We want to build a software system that allows
people to vote electronically.
→ The citizen goes to the electoral place, and she votes using
a hw/sw device.
→ The vote is stored locally and automatically sent to other
computers.
→ The citizen identity must be validated by the system
→ …”
SEA Group
12. Basic Requirement Example
The voting system must satisfy the following
requirements:
→ One voter – one vote (no more than one vote for voter)
→ The voter can vote in only one previous designated voting
place
→ The voter must be identified by the election officials at the
voting place
─ The citizen identity must be validated by the system
→ It is not possible to trace the votes back to the voters
→ The election officials can’t read the results, guarantying that
the results are unknown until the end of the voting process
SEA Group
14. Process
Requirements
A modeling language
Drives modeled in (e.g. UML)
Software
Architecture modeled in
Analysis
Implementation
Traceability
SEA Group
15. Advantages of explicit architecture
System analysis
→Analysisof whether the system can meet its functional and
non-functional requirements is possible.
Large-scale reuse
→The architecture (or part of it) may be reusable across a
range of systems.
Stakeholder communication
→Architecture may be used as a focus of discussion by system
stakeholders.
SEA Group
16. SA History
1992 and 1993: SA is recognized as an independent area of research;
→ What is SA
1993-1995: SA described through box and line (i.e. informal) diagrams;
1995-1997: Architectural Description Languages (ADLs) are introduced to formally
describe SA;
→ SA and Specification (with ADLs)
1997-2003:
→ more interest on dynamic aspects of SA;
→ SA recognized as a valid tool to deal with various aspects of complex,
concurrent, real systems;
→ SA and UML
→ SA and Analysis
2003-today:
→ SA vs CBSE, AOP, SOA, etc…
→ Design Decisions, Viewpoints
SEA Group
17. Civil Architecture vs Software
Architecture
Civil : » Software :
Bricks - Three types of
Roof components
Chimney top - Multiple instances
of the type “brick”
» Civil : » Software :
- Concrete - Connectors
- Construction Rules - Assembly constraints
SEA Group
18. In general terms…
SA describes (in a more or less “formal” notation) how a system is
structured into components and connectors…
→Components
→Connectors SA Structure (topology)
→Channels and Ports
… and how these components interact
→Scenarios
→State Diagrams SA Dynamics (behavior)
→…
SEA Group
21. Components
A component is a building block that is …
→A unit of computation or a data store, with an interface
specifying the services it provides and requires
→A unit of deployment
→A unit of reuse
─ e.g., client, server, database, filters, ...
required S’x S1 provided
services S’Y C1 S2
S3 services
SEA Group
22. Components vs Objects
The level of abstraction is usually different
Size
→Objects tend to be small
→Components can be small (one object) or large (a library of
objects or a complete application)
An architectural component may be implemented by
several objects
Lifecycle
→Objects
are created and destroyed constantly
→Components are created and destroyed infrequently
SEA Group
23. Connectors
A connector is a building block that enables interaction among
components
→Events
→Client/server middleware
→Messages and message buses
→Shared variables
→Procedure calls (local or remote)
→Pipes
Connectors may be implicit or explicit
→Connectors sometimes are just channels
→Connectors sometimes have their own logic and complexity
Connectors may be endogenous or exogenous
SEA Group
24. Components and Connectors
A component is (or should be) independent of the
context in which it is used to provide services
A connector is (or should be) dependent on the
context in which it is used to connect components
Connectors sometimes are modeled as special kinds of
components
SEA Group
25. Interfaces
An interface is the external connection of a
component (or connector) that describes how to
interact with it
Provided and required interfaces are important
Spectrum of interface specification
→ Loosely specified (events go in, events go out)
→ API style (list of functions)
→ Very highly specified (event protocols across the interface
in CSP)
SEA Group
26. Architecting: example
GUI
Admin
NewsFeeder Action
Action
Transfer
Object DATABASE
FeedService
Common FeedService
Trasformation Action
Validation
ValidatorService
Browser Validation
(html Service
javascript)
NewsFeederDelegate
FeedDelegate
NewsFeeder FeedDelegate
DelegatePOJOs POJOs NewsFeederDAO
NewsFeeder
Web DAO
Services
BusinessFactory Factory FeedDAO
FeedDAO
SEA Group
29. SA dynamics
The SA dynamics is expressed in terms of component
interactions via connectors
•Labeled Transition Systems
•Automata
•UML StateCharts, Sequence Diagrams, Activity Diagrams
•State Diagrams
•Message Sequence Charts
•…
SEA Group
30. AN EXAMPLE : E-COMMERCE SYSTEM
Customer Interface
Web Server
Cart Server Customer Process
Delivery Order
Catalog Server
Process
Customer Server
Order Server
SA Static Description
SEA Group
31. AN EXAMPLE : E-COMMERCE SYSTEM
CustomerInterface CustomerProcess CatalogServer
Registered Customer
BrowseCatalog
BrowseCatalog
ReadStatus
Catalog DB
Catalog Info Involved
Catalog Page
Output Page
SA Dynamic Description :
Browse Catalogue Sequence Diagram
SEA Group
32. AN EXAMPLE : E-COMMERCE SYSTEM
SA Dynamic Description :
Place Order Sequence Diagram (success)
SEA Group
33. AN EXAMPLE : E-COMMERCE SYSTEM
SA Dynamic Description :
Place Order Sequence Diagram (empty cart)
SEA Group
34. Architectural Elements vs Design Elements
“Architecture is concerned with the selection of
architectural elements, their interactions, and the
constraints on those elements and their interactions
necessary to provide a framework in which to satisfy
the requirements and serve as a basis for the
design.”
“Design is concerned with the modularization and
detailed interfaces of the design elements, their
algorithms and procedures, and the data types
needed to support the architecture and to satisfy the
requirements.”
(Perry & Wolf 92)
SEA Group
35. Architectural Elements vs Design Elements
“The architecture of a software system defines that
system in terms of computational components and
interactions among those components. … In addition
to specifying the structure and topology of the
system, the architecture shows the correspondence
between the requirements and elements of the
constructed system, thereby providing some
rationale for the design decisions.”
(Shaw & Garlan 96)
SEA Group
36. Architecture and NF characteristics…
Performance
→Localise critical operations and minimise communications.
Security
→Use a layered architecture with critical assets in the inner layers.
Safety
→Localise safety-critical features in a small number of sub-systems.
Availability
→Include redundant components and mechanisms for fault tolerance.
Maintainability
→Use fine-grain, replaceable components.
SEA Group
37. … may originate architectural conflicts
Using large-grain components improves performance
but reduces maintainability.
Introducing redundant data improves availability but
makes security more difficult.
Localising safety-related features usually means more
communication so degraded performance.
SEA Group
38. Architectural styles
The architectural model of a system may conform to a
generic architectural model or style.
The awareness of these styles can simplify the problem
of defining system architectures.
There is a strict relation between the ADLs and the
style adopted.
However, most large systems are heterogeneous and
do not follow a single architectural style.
SEA Group