The document discusses architectural patterns. It defines what patterns are and provides a taxonomy of patterns including idioms, design patterns, and architectural patterns. Architectural patterns express fundamental structural organizations for software systems and include patterns like layers, pipes and filters, and blackboard. The rest of the document describes various architectural styles and provides examples of architectural patterns within each style.
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)
Protocol Architecture in the HAN (Home Area Network) for Sensor NetworksCisco Service Provider
The objective of this document is to provide technical recommendations for the protocol architecture in the Home Area Network (HAN) for Smart Objects such as sensors and actuators. In particular, these recommendation applies to the Home Energy Controller (HEC) and Multi-Utility Controller (MUC) developed in the context of the Smart Grid initiative for various applications such as metering, Demand Side management (DSM) and Demand-Response (DR).
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)
Protocol Architecture in the HAN (Home Area Network) for Sensor NetworksCisco Service Provider
The objective of this document is to provide technical recommendations for the protocol architecture in the Home Area Network (HAN) for Smart Objects such as sensors and actuators. In particular, these recommendation applies to the Home Energy Controller (HEC) and Multi-Utility Controller (MUC) developed in the context of the Smart Grid initiative for various applications such as metering, Demand Side management (DSM) and Demand-Response (DR).
Can “Feature” be used to Model the Changing Access Control Policies? IJORCS
Access control policies [ACPs] regulate the access to data and resources in information systems. These ACPs are framed from the functional requirements and the Organizational security & privacy policies. It was found to be beneficial, when the ACPs are included in the early phases of the software development leading to secure development of information systems. Many approaches are available for including the ACPs in requirements and design phase. They relied on UML artifacts, Aspects and also Feature for this purpose. But the earlier modeling approaches are limited in expressing the evolving ACPs due to organizational policy changes and business process modifications. In this paper, we analyze, whether “Feature”- defined as an increment in program functionality can be used as a modeling entity to represent the Evolving Access control requirements. We discuss the two prominent approaches that use Feature in modeling ACPs. Also we have a comparative analysis to find the suitability of Features in the context of changing ACPs. We conclude with our findings and provide directions for further research.
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
Can “Feature” be used to Model the Changing Access Control Policies? IJORCS
Access control policies [ACPs] regulate the access to data and resources in information systems. These ACPs are framed from the functional requirements and the Organizational security & privacy policies. It was found to be beneficial, when the ACPs are included in the early phases of the software development leading to secure development of information systems. Many approaches are available for including the ACPs in requirements and design phase. They relied on UML artifacts, Aspects and also Feature for this purpose. But the earlier modeling approaches are limited in expressing the evolving ACPs due to organizational policy changes and business process modifications. In this paper, we analyze, whether “Feature”- defined as an increment in program functionality can be used as a modeling entity to represent the Evolving Access control requirements. We discuss the two prominent approaches that use Feature in modeling ACPs. Also we have a comparative analysis to find the suitability of Features in the context of changing ACPs. We conclude with our findings and provide directions for further research.
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
Architectural Patterns and Software Architectures: Client-Server, Multi-Tier,...Svetlin Nakov
Few days ago I gave a talk about software architectures. My goal was to explain as easy as possible the main ideas behind the most popular software architectures like the client-server model, the 3-tier and multi-tier layered models, the idea behind SOA architecture and cloud computing, and few widely used architectural patterns like MVC (Model-View-Controller), MVP (Model-View-Presenter), PAC (Presentation Abstraction Control), MVVM (Model-View-ViewModel). In my talk I explain that MVC, MVP and MVVM are not necessary bound to any particular architectural model like client-server, 3-tier of SOA. MVC, MVP and MVVM are architectural principles applicable when we need to separate the presentation (UI), the data model and the presentation logic.
Additionally I made an overview of the popular architectural principals IoC (Inversion of Control) and DI (Dependency Injection) and give examples how to build your own Inversion of Control (IoC) container.
Model-Driven Architecture for Cloud Applications Development, A survey Editor IJCATR
Model Driven Architecture and Cloud computing are among the most important paradigms in software service engineering now a days. As cloud computing continues to gain more activities, more issues and challenges for many systems with its dynamic usage are introduced. Model Driven Architecture (MDA) approach for development and maintenance becomes an evident choice for ensuring software solutions that are robust, flexible and agile for developing applications.
This paper aims to survey and analyze the research issues and challenges that have been emerging in cloud computing applications with a focus on using Model Driven architecture (MDA) development. We discuss the open research issues and highlight future research problems.
Developers are faced with a smorgasbord of architecture activities but few models telling them which activities to use. Alternatives include the documentation package model, which advocates a complete architectural description from many perspectives, and the evolutionary design model, which advocates no up-front architectural work.
This talk explains the risk-centric model, inspired by Attribute Driven Design (ADD), Global Analysis, and the Spiral model. In the risk-centric model, risks are central, so developers: (1) prioritize the risks they face, (2) choose appropriate architecture techniques to mitigate those risks, and (3) re-evaluate remaining risks. It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. It makes explicit the mappings between risks and corresponding architecture techniques.
Like ADD and Global Analysis, and unlike the Spiral model, the risk-centric model is not a full software development process and can instead be used inside a process such as XP or RUP.
Speech Recognition Service (SPRS) is a mobile application capable of recognition some of voices. And due to the system compatibility, users can running this application from any mobile devices supported by android system and SPRS is designed especially for deaf people.
Voice recognition service (VRS) recognize voices in our real life especially in our home such that sound of the bell, telephone and door. VRS allows the user to many of the notifications options when you hear a specific sound previously identified where the user can choose one of the available options such as sending a message to mobile number or vibration. VRS requires minimum knowledge of how to use the mobile in order to be able to run it. VRS has Arabic, simple and user-friendly interface.
This document includes a detailed description of system requirements both functional and non-functional, design models and description, functionalities of all system objects, and system testing so it could be used as a user manual for system users.
Attribute Driven Styles: The Good, the Bad, and the Unknown (SassConf 2015 Di...Jonathan Cutrell
Attributes provide us with a high amount of flexibility that we have largely ignored. In this discussion, we'll explore how attributes may help create a more flexible, maintainable, and intentional way of building stylesheets.
This presentation describe the importance of trade-off between software architecture quality attribute (NFR). Explain about Performance, Security, Availability and Scalability in depth and other in briefly.
Presented on tech talk @ DFN Technology.
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)
A Software Factory Integrating Rational Team Concert and WebSphere toolsProlifics
Speakers: Greg Hodgkinson, Prolifics; Andre Tost, IBM
Description: Getting any software development team to effectively scale to meet the needs of a large integration project is actually harder than it sounds. For a large Automotive Retailer based in Florida, this is exactly what they needed to do. They needed a large amount of integration to be built between their brand new Point of Sales system and their new SAP back-end. In this session, you will hear about how tools such as Rational Software Architect and WebSphere Message Broker Toolkit were integrated with a Rational Team Concert-based development environment to set up super efficient software factory employing techniques such as Model-Driven Development and Continuous Integration to help this retailer keep their customers’ wheels on the road.
Thesis presentation: Middleware for Ubicomp - A Model Driven Development Appr...Till Riedel
With computers that will be interwoven into almost every industrial product like its nervous system (Steinbuch, 1966) we are already approaching what Weiser (1991) called Ubiquitous Computing, in terms of quantity, degree of embedding of computing systems in our life and work environment.
This thesis investigates model driven software development (MDSD) approach as a tool for contextual adaption of ubiquitous systems. Ubiquitous Systems (i.e. the embedded devices) are subject to changes that affect the execution of software. The systems are very heterogeneous and and the designer has to take a diverse set of plattforms and ressource constrained hardware into consideration.
By implementing a model driven development techniques for core problems of ubiquitous computing, namely distributed execution and heterogeneous communication in ubiquitous systems the work demonstrates that Model Driven Software Development of Ubiquitous Systems maybe used to solve the inherent contradiction between top-down and bottom-up development of networked embedded systems.
Software Architecture by Reuse, Composition and Customization Ivano Malavolta
Ivano Malavolta.
Research Fellow at the Computer Science Department of the University of L'Aquila (Italy).
PhD thesis presentation, University of L'Aquila, March 2012.
The full PhD thesis is available here:
http:www.di.univaq.it/malavolta/files/IvanoMalavoltaPhDThesis.pdf
Software Factories in the Real World: How an IBM® WebSphere® Integration Fact...Prolifics
“Getting any software development team to effectively scale to meet the needs of a large integration project is actually harder than it sounds. For a large Automotive Retailer based in Florida, this is exactly what they needed to do. They needed a large amount of integration to be built between their brand new Point of Sales system and their new SAP back-end. In this session, you will hear about how tools such as Rational Software Architect and WebSphere Message Broker Toolkit were integrated with a Rational Team Concert-based development environment to set up super efficient software factory employing techniques such as Model-Driven Development and Continuous Integration to help this retailer keep their customers’ wheels on the road.”
Run-time Monitoring-based Evaluation and Communication Integrity Validation o...Ana Nicolaescu
Architecture descriptions greatly contribute to the understanding, evaluation and evolution of software but despite this, up-to-date software architecture views are rarely available. Typically only initial descriptions of the static view are created
but during the development and evolution process the software drifts away from its description. Methods and corresponding tool support for reconstructing and evaluating the current architecture views have been developed and proposed, but they usually
address the reconstruction of static and dynamic views separately. Especially the dynamic views are usually bloated with low-level information (e.g. object interactions) making the understanding and evaluation of the behavior very intricate. To overcome this,
we presented ARAMIS, a general architecture for building toolbased approaches that support the architecture-centric evolution and evaluation of software systems with a strong focus on their behavior. This work presents ARAMIS-CICE, an instantiation
of ARAMIS. Its goal is to automatically test if the run-time interactions between architecture units match the architecture description. Furthermore, ARAMIS-CICE characterizes the intercepted behavior using two newly-defined architecture metrics.
We present the fundamental concepts of ARAMIS-CICE: its meta-model, metrics and implementation. We then discuss the results of a two-folded evaluation. The evaluation shows very promising results.
A framework for distributed control and building performance simulationDaniele Gianni
Presentation delivered at the 3rd IEEE Track on
Collaborative Modeling & Simulation - CoMetS'12.
Please see http://www.sel.uniroma2.it/comets12/ for further details.
Software engineering is a detailed study of engineering to the design, development and maintenance of software. Software engineering was introduced to address the issues of low-quality software projects.
This ppt covers the following topics:
Introduction
Data design
Software architectural styles
Architectural design process
Assessing alternative architectural designs
Thus it covers Architectural Design
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Goodbye Windows 11: Make Way for Nitrux Linux 3.5.0!SOFTTECHHUB
As the digital landscape continually evolves, operating systems play a critical role in shaping user experiences and productivity. The launch of Nitrux Linux 3.5.0 marks a significant milestone, offering a robust alternative to traditional systems such as Windows 11. This article delves into the essence of Nitrux Linux 3.5.0, exploring its unique features, advantages, and how it stands as a compelling choice for both casual users and tech enthusiasts.
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
2. What is a Pattern?
“ Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core of
the solution to that problem, in such a way
that you can use this solution a million times
over, without ever doing it the same way
twice …”
Christopher Alexander
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
3. Taxonomy of Patterns & Idioms
Type Description Examples
Idioms Restricted to a particular language, C++ list and array
system, or tool processing.
Design Capture the static & dynamic roles & Active Object,
patterns relationships in solutions that occur Bridge, Proxy,
repeatedly in a design context. Façade, Visitor,
Factory,…
Architectural Express a fundamental structural Layers, Pipe-
patterns organization for software systems that Filter, Blackboard,
provide a set of predefined subsystems, MVC, Broker,
specify their relationships, & include the Microkernel,
rules & guidelines for organizing the Reflection…
relationships between them
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
4. Architectural Design
From Mud to Structure Layers Design patterns are applicable
Pipes and filters towards the end of coarse-
Blackboard grained design when refining
and extending the fundamental
Broker architecture of a software
Distributed systems Pipes and filters system. Design patterns are
also applicable in the detailed
Microkernel
design stage for specifying
Interactive systems MVC local design aspects (e.g.
PAC multiple implementations of a
component)
Adaptable systems Microkernel
Reflection
Structural decomposition Architectural patterns Whole-part
Organization of work can be used at the Master-Slave
beginning of coarse
Access control grained design, when Proxy
Management specifying the Command processor
fundamental structure of
View handler
an application (cf. first
Communication Informatietechnologie – Onderzoeksgroepof the ADD
Vakgroep iteration(s) IBCN Publisher-subscriberp. 4
method) Forwarder-Receiver
5. What Makes a Architectural Pattern?
Context Problems Solution
Context
A situation giving rise to a problem
Developing software systems with a flexible user interface
Transforming data flows in real time
Processing events in sensornetworks
Specifying the correct context for a pattern is difficult :
• Impossible to determine all situations
• Known context situations for a pattern give valuable guidance
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
6. What Makes a Architectural Pattern?
Context Problems Solution
Problem
The recurring problem arising in that context
Requirements the solution must fulfill
Constraints you must consider : e.g.
Use a particular communication middleware: Corba
Need to run on specific OS: Linux.
Desirable properties the solution should have : e.g. changing
software should be easy
In the context of ADD these are
-Functional requirements
-Quality Requirements.
-Design Constraints
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
7. What Makes a Architectural Pattern?
Context Problems Solution
Solution
Structure with components and relationships
Run-time behavior
Tactics
A pattern is a mental building block.
After applying a pattern, architectures should include a particular
structure that provides for the roles specified by the pattern, but adjusted
and tailored to the specific needs of the problem at hand.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
8. Architectural Style Catalogue
Data Flow Data Centered
Blackboard Repository
Pipes & Batch
Filters Sequential
Call & Return
Independent
Components
Layered Object Oriented
Communicating Event Based Virtual Machines
Processes Systems
Interpreter Rule based
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8
9. Data Flow Architectures
Key feature:
Dominated by motion of data through the system
Data streams
Processing & transformations on the streams
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
10. Architectural Pattern: Pipes and Filters (Data Flow)
Context Problems Solution
• Processing • Future system enhancements should be • Apply the Pipes
data possible and Filters
streams architectural
• Small processing steps
• Motion of pattern: the tasks
• Non-adjacent processing steps do not share
data of a system are
through the information
divided into
system • Different sources of input data exist
several sequential
• Present or store final results in various ways processing steps,
• Explicit storage of intermediate results for further connected by the
processing data flow through
• You may not want to rule out multi-processing the system
the steps
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
11. Example: Compilers
1. Divide the system’s task into a sequence of processing
stages
2. Define the data format to be passed along each pipe
3. Decide how to implement each pipe connection
4. Design and implement the filters
5. Design the error handling
6. Set up the processing pipeline
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11
12. Architectural Style Catalogue
Data Flow Data Centered
Blackboard Repository
Pipes & Batch
Filters Sequential
Call & Return
Independent
Components
Layered Object Oriented
Communicating Event Based Virtual Machines
Processes Systems
Interpreter Rule based
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12
13. Data-Centered Architectures
Key Feature:
Dominated by a complex central data store,
manipulated by independent components.
Repository
Passive data store: file, database
– Data mining, Recommendation Engines,
– Route planner
Blackboard
Active data store: sends events to the
subscribers
– Artificial Intelligence
– Speech and Pattern recognition
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
14. Architectural Pattern: Blackboard (Data Centered)
Context Problems Solution
• Experimental domain in • There are different algorithms • Apply the Blackboard
which no closed that solve partial problems architectural pattern: a
approach to a solution is • Employing disjoint algorithms collection of independent
known or feasible, induces potential parallelism. If programs that work
different approaches for possible you should avoid a cooperatively on a common
the problem are strictly sequential solution data structure
opportune
p. 14
15. Blackboard : Instantiation
1. Define the problem
2. Define the solution space for the
problem
3. Divide the solution process into steps
4. Divide the knowledge into specialized
knowledge sources with certain
subtasks
5. Define the vocabulary of the
blackboard
6. Specify the control of the system
7. Implement the knowledge sources
HEARSAY II used a blackboard architecture to recognize human speech. In
this case the raw data was acoustical data which was to be transformed into a
database query. Contributors/knowledge sources existed for transforming
acoustical data (level 0, wave forms) into phonetic data (level 1, phonemes),
phonetic data into lexical data (level 2, words), lexical data into syntactical data
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15
(level 3, phrases), and syntactical data into queries (level 4).
16. Architectural Pattern: Blackboard
+ -
⇒ Modifiability ⇒ Testability
• Individual knowledge sources, the •Hypotheses are part of the solution
control algorithm and the central process
data structure are strictly separated
• Reusable knowledge sources
⇒ Performance
• Computational overhead
•The blackboard provides tolerance • No support for parallelism
of noisy and uncertain conclusions
• Difficult to establish a good control
as all results are just hypotheses
strategy
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16
17. Architectural Style Catalogue
Data Flow Data Centered
Blackboard Repository
Pipes & Batch
Filters Sequential
Call & Return
Independent
Components
Layered Object Oriented
Communicating Event Based Virtual Machines
Processes Systems
Interpreter Rule based
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17
18. Call and Return Architectures
Key Feature
Dominated by order of computation
Examples
2-Layered or Call based Client/Server
N-Layered
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
19. Architectural Pattern: Layers
Context Problems Solution
• Large system • Parts of the system should be exchangeable • Layered
that requires • Reuse low-level issues architectural
decomposition pattern: structure
• No standard component granularity your system into an
• Group similar responsibilities appropriate number
• System will be build by separated teams of of layers and place
programmers them on top of each
other
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
21. Layers : Instantiation
1. Define the abstraction criterion
2. Determine the number of abstraction levels
3. Name the layers and assign tasks to each of them
4. Specify the services
5. Refine the layering
6. Specify the interfaces for each layer
7. Structure individual layers
8. Specify the communication between adjacent layers
9. Decouple adjacent layers
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
23. Architectural Pattern: Layers
+ -
⇒Modifiability ⇒Performance
• Localize changes • Unnecessary work
• Prevention of ripple effect • Lower efficiency
• Defer binding time
⇒Testability ⇒Modifiability
• Manage input/output • Cascades of changing behavior
⇒Usability •Difficulty of establishing the correct
• Separate user interface granularity of layers
•Reuse of layers
•Support for standardization
•Dependencies are kept local
•Exchangeability
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
24. Model-View-Controller
Context Problems Solution
• Interactive • The same information is presented • Apply the Model-View-
applicatio differently Controller architectural
n with • Display and behavior of the application pattern:
flexible must reflect data manipulations • The Model contains the
human- immediately core functionality and data.
computer
• Changes to the user interface should be • Views display information to
interface
easy, and even possible at run-time the user,
• Supporting different ‘look and feel’ • Controllers handle user
standards or porting the user interface input and control the flow.
should not affect code in the core Views and controllers
application together comprise the user
interface.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
26. MVC for web applications
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 26
27. MVC analysis
+ -
⇒ Modifiability Performance ⇒
•‘Pluggable’ views and controllers •Inefficiency of data access in view
•Exchangeability of ‘look and feel’ •Potential excessive number of
updates
⇒ Usability •Increased complexity, sometimes
•Separate user interface
without gaining much flexibility.
⇒ Modifiability
•‘Pluggable’ views
•Close coupling of views and
•Multiple synchronized views of the
controllers to a model
same model
•Difficulty of using MVC with
•Framework potential
modern user-interface tools
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 27
28. Architectural Style Catalogue
Data Flow Data Centered
Blackboard Repository
Pipes & Batch
Filters Sequential
Call & Return
Independent
Components
Layered Object Oriented
Communicating Event Based Virtual Machines
Processes Systems
Interpreter Rule based
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 28
29. Independent Components
Key Features
Dominated by communication patterns.
Components communicate through messages.
They send data; not control.
Examples
Event systems
Implicit invocation
Announcers of events do not know which
components will be affected by the event
Communicating processes
Shaw and Garlan
Software Architecture in Practice
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 29
30. Broker: Broker Forwarding Pattern
Context Problems Solution
• Distributed • Components should be able to access • Apply the Broker
and possible services provided by others through architectural pattern: an
heterogeneo remote, location-transparent service intermediate component
us system invocations that is responsible for
with • Need to exchange, add, or remove coordination
independent components at run-time communication, such as
cooperating forwarding requests, as
• The architecture should hide system-
components well as for transmitting
and implementation-specific details from results and exceptions
the user of components and services
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 30
32. Broker : Instantiation
1. Define an object model
2. Decide which kind of component-
interoperability the system should offer
3. Specify the API’s the broker component
provides for collaborating with client and
server
4. Use proxy objects to hide implementation
details from clients and servers
5. Design the broker component in parallel with
steps 3 and 4
• Specify protocol, message buffers,
directory service, dynamic method
invocation, IDL compiler…
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 32
33. Architectural Pattern: Broker
+ -
⇒ Modifiability ⇒Performance
•Location transparency •Restricted efficiency
•Changeability and extensibility of
components
•Portability of a broker system (in ⇒Availability
combination with proxy/bridge) •Lower fault tolerance
•Interoperability between different
broker systems
•Reusability
⇒ Testability
⇒Testability •Many components involved
•An application developed from
tested services is more robust and
easier to test
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 33
34. Broker Handle Pattern
Direct
communication: same
protocol or proxy
Here the proxy takes some of the broker’s responsibilities
for handling most of the communication activities
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 34
35. Design Pattern: Proxy
Context Problems Solution
• The configuration • Low-level message passing (e.g., using • Apply the Proxy
of components in sockets) is error-prone & fraught with pattern: provide a
distributed accidental complexity surrogate through
systems is often • Remote components should look like local which clients can
subject to change components from an application perspective access remote
as requirements objects
• i.e., ideally clients & servers should be
evolve
oblivious to communication mechanisms &
locations
Structure Dynamics
p. 35
36. Design Pattern: Proxy
+ -
⇒ Modifiability ⇒ Performance
•Decoupling clients from the •Less efficiency due to indirection
location of server components (additional layer of indirection, usually
negligible compared with the cleaner
•Separation of housekeeping
structure of clients and the gain of
code from functionality efficiency through caching or lazy
construction…)
•Overkill via sophisticated strategies,
they do not always pay
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 36
40. Event Based Systems
Individual components announce data that they wish to
share with other components: Publishers
Other components can register an interest in a class of
data: Subscribers
Typically involves a message manager that controls
communication between components
Example: debuggers, databases, brokers
Subscribe
Message
Manager
Publish
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 40
41. Publisher-Subscriber
Context Problems Solution
• I/O driven message • Hard to schedule • Apply the Publisher-
based application • Expensive to evolve Subscriber pattern to
• Complex distribute periodic, I/O-driven
• Scalability
dependencies data from a single point of
source to a collection of
• Real-time constraints
consumers
Structure Dynamics
p. 41
42. Publisher-Subscriber: Avionics example
Considerations for implementing the Publisher-Subscriber
pattern for mission computing applications include:
• Event notification model
• Push control vs. pull data interactions
• Scheduling & synchronization strategies
e.g., priority-based dispatching & preemption
• Event dependency management
e.g.,filtering & correlation mechanisms
Airforce fighter jet uses the Publisher-Subscriber pattern to
decouple sensor processing from mission computing operations
• Anonymous publisher & subscriber relationships
• Group communication
• Asynchrony
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 42
43. Publisher-Subscriber: example
Subscribers
HUD WTS 5: Subscribers
perform
Air
NAV Frame avionics
operations
push(event)
4: Event Channel
Event pushes events
Channel to subscribers(s)
push(event)
3: Sensor
publishers
Publishers GPS IFF FLIR push events
to event
channel
2: I/O via
Board 1 interrupts
1553
1: Sensors
VME
generate
Board 2
data
p. 43
44. Pattern: Inter-relationships
• Patterns are NOT atomic
• Applying a pattern creates new contexts
• Applying a pattern creates new problems and trade-offs
• Applying a pattern creates new solutions
• Patterns need to collaborate to solve a problem
• E.g. the broker pattern (distributed system) typically leads to the
introduction of the proxy pattern (access control) and bridge
pattern (service variation)
If the ADD method is applied appropriately it should be clear which
pattern to use when and where:
System subsystem module submodule
e.g. Broker proxy/bridge …
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 44
Editor's Notes
Geschreven door Christopher Alexander, maar dan in de context van gebouwen en steden. Wat hij zegt geldt ook voor OO design. Hij wordt min of meer beschouwd als de grondlegger van de design pattern idee … In SE spreken we over objecten en interfaces in plaats van over muren En deuren (zoals C. Alexander). Maar kern van de zaak is dat beide Soorten patterns een oplossingen bieden voor een probleem in een context. Design Patterns in OO
Presentation-abstraction-control (PAC) is a software architectural pattern, somewhat similar to model-view-controller (MVC). PAC is used as a hierarchical structure of agents, each consisting of a triad of presentation, abstraction and control parts. The agents (or triads) communicate with each other only through the control part of each triad. It also differs from MVC in that within each triad, it completely insulates the presentation (view in MVC) and the abstraction (model in MVC), this provides the option to separately multithread the model and view which can give the user experience of very short program start times, as the user interface (presentation) can be shown before the abstraction has fully initialized.
Filters must be independent entities: in particular, they should not share state with other filters. Another important invariant is that filters do not know the identity of their upstream and downstream filters. Their specifications might restrict what appears on the input pipes or make guarantees about what appears on the output pipes, but they may not identify the components at the ends of those pipes. Furthermore, the correctness of the output of a pipe and filter network should not depend on the order in which the filters perform their incremental processing—although fair scheduling can be assumed.
Advantages: First , they allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. Second , they support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them. Third , systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones. Fourth , they permit certain kinds of specialized analysis, such as throughput and deadlock analysis. Finally , they naturally support concurrent execution. Each filter can be implemented as a separate task and potentially executed in parallel with other filters.
In a repository style there are two quite distinct kinds of components: a central data structure represents the current state, and a collection of independent components operate on the central data store. Interactions between the repository and its external components can vary significantly between systems. The choice of control discipline leads to major subcategories. A) Database systems: If the types of transactions in an input stream of transactions trigger selection of processes to execute, the repository can be a traditional database. B) Blackboard: If the current state of the central data structure is the main trigger of selecting processes to execute, the repository can be a blackboard.
This figure illustrates a simple view of a blackboard architecture. The blackboard model is usually presented with three major parts: 1) The knowledge sources: separate, independent parcels of application dependent knowledge. Interaction among knowledge sources takes place solely through the blackboard. 2) The blackboard data structure: problem-solving state data, organized into an application-dependent hierarchy. Knowledge sources make changes to the blackboard that lead incrementally to a solution to the problem. 3) Control: driven entirely by state of blackboard. Knowledge sources respond opportunistically when changes in the blackboard make them applicable. Invocation of a knowledge source is triggered by the state of the blackboard. The actual locus of control, and hence its implementation, can be in the knowledge sources, the blackboard, a separate module, or some combination of these. Blackboard systems have traditionally been used for applications requiring complex interpretations of signal processing, such as speech and pattern recognition. They have also appeared in other kinds of systems that involve shared access to data with loosely coupled agents .
A layered system is organized hierarchically, each layer providing service to the layer above it and serving as a client to the layer below. In some layered systems inner layers are hidden from all except the adjacent outer layer, except for certain functions carefully selected for export. Thus in these systems the components implement a virtual machine at some layer in the hierarchy. (In other layered systems the layers may be only partially opaque.) The connectors are defined by the protocols that determine how the layers will interact. Topological constraints include limiting interactions to adjacent layers. The most widely known examples of this kind of architectural style are layered communication protocols. In this application area each layer provides a substrate for communication at some level of abstraction. Lower levels define lower levels of interaction, the lowest typically being defined by hardware connections. Other application areas for this style include database systems and operating systems
Layered systems have several desirable properties. First , they support design based on increasing levels of abstraction. This allows implementers to partition a complex problem into a sequence of incremental steps. Second , they support enhancement. Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers. Third , they support reuse. Like abstract data types, different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces to which different implementors can build.
Layered systems have several desirable properties. First , they support design based on increasing levels of abstraction. This allows implementers to partition a complex problem into a sequence of incremental steps. Second , they support enhancement. Like pipelines, because each layer interacts with at most the layers below and above, changes to the function of one layer affect at most two other layers. Third , they support reuse. Like abstract data types, different implementations of the same layer can be used interchangeably, provided they support the same interfaces to their adjacent layers. This leads to the possibility of defining standard layer interfaces to which different implementors can build.
But layered systems also have disadvantages : Not all systems are easily structured in a layered fashion. And even if a system can logically be structured as layers, considerations of performance may require closer coupling between logically high-level functions and their lower-level implementations. Additionally, it can be quite difficult to find the right levels of abstraction. This is particularly true for standardized layered models. One notes that the communications community has had some difficulty mapping existing protocols into the ISO framework: many of those protocols bridge several layers.
MVC encompasses more of the architecture of an application than is typical for a design pattern. When considered as a design pattern, MVC is semantically similar to the Observer pattern. The Model is the domain-specific representation of the data on which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items). Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the encapsulated by the model. Example: representations of a table in a database. Java observable class But Java provides the Observable/Observer classes as built-in support for the Observer pattern . The java.util.Observable class is the base Subject class. Any class that wants to be observed extends this class.
Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modeling techniques apply when defining the model. View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data. Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.
The idea behind event based systems is that instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. Other components in the system can register an interest in an event by associating a procedure with the event. When the event is announced the system itself invokes all of the procedures that have been registered for the event. The main invariant of this style is that announcers of events do not know which components will be affected by those events. Thus components cannot make assumptions about order of processing, or even about what processing, will occur as a result of their events.
Example: find the cheapest fight ticket
One important benefit of event based systems is that they provides strong support for reuse. Any component can be introduced into a system simply by registering it for the events of that system. A second benefit is that implicit invocation eases system evolution. Components may be replaced by other components without affecting the interfaces of other components in the system. In contrast, in a system based on explicit invocation, whenever the identity of a that provides some system function is changed, all other modules that import that module must also be changed. The primary disadvantage of implicit invocation is that components relinquish control over the computation performed by the system. When a component announces an event, it has no idea what other components will respond to it. Worse, even if it does know what other components are interested in the events it announces, it cannot rely on the order in which they are invoked.
HUD: Headup display WTS : Weapons target system IFF: Identification friend or foo FLIR: sees through smoke screens -: thermal visioning