Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

OOStrategiesForEmbedded

No description
by

Roelof Berg

on 24 April 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of OOStrategiesForEmbedded

State Charts
Composite Structure Diagrams
Dependency Injection Frameworks
->
No class diagrams
OO strategies for embedded and realtime systems
Roelof Berg
Software Architect
for medical devices
1997-2001 ~ .com bubble
2001-2013 ~ Freelancer
since 2013 ~ Software Architect

Part time trainer and consultant
Blog: embedded-software-architecture.com
SOLID
DDD
&

Code
Generation

IOT
Typical Method Evolution
___ _____ __ ___
/ | / ___// |/ /
/ /| | \__ \/ /|_/ /
/ ___ |___/ / / / /
/_/ |_/____/_/ /_/
______
/ ____/
/ /
/ /___
\____/
______
/ ____/__ __
/ / __/ /___/ /_
/ /__/_ __/_ __/
\____//_/ /_/
____ ____
/ __ \/ __ \
/ / / / / / /
/ /_/ / /_/ /
\____/\____/
____ ____ ____
/ __ \/ __ \/ __ \
/ / / / / / / / / /
/ /_/ / /_/ / /_/ /
/_____/_____/_____/
______ __ _ __
/ ____/_ ______ _____/ /_(_)___ ____ ____ _/ /
/ /_ / / / / __ \/ ___/ __/ / __ \/ __ \/ __ `/ /
/ __/ / /_/ / / / / /__/ /_/ / /_/ / / / / /_/ / /
/_/ \__,_/_/ /_/\___/\__/_/\____/_/ /_/\__,_/_/
__ __ _ __ ______ __
/ / / /___ (_) /_ /_ __/__ _____/ /______
/ / / / __ \/ / __/ / / / _ \/ ___/ __/ ___/
/ /_/ / / / / / /_ / / / __(__ ) /_(__ )
\____/_/ /_/_/\__/ /_/ \___/____/\__/____/
_____ ____ __ ________
/ ___// __ \/ / / _/ __ \
\__ \/ / / / / / // / / /
___/ / /_/ / /____/ // /_/ /
/____/\____/_____/___/_____/
__ ___ __ ______
/ |/ /___ _____/ /__ / ____/__ ____
/ /|_/ / __ \/ ___/ //_/ / / __/ _ \/ __ \
/ / / / /_/ / /__/ ,< / /_/ / __/ / / /
/_/ /_/\____/\___/_/|_| \____/\___/_/ /_(_)
__ ____ __
/ / / / / / /
/ /_/ / / / /
/ __ / /___/ /___
/_/ /_/_____/_____/
______ __ ______
/ ____/___ ____/ /__ / ____/__ ____
/ / / __ \/ __ / _ \ / / __/ _ \/ __ \
/ /___/ /_/ / /_/ / __/ / /_/ / __/ / / /
\____/\____/\__,_/\___/ \____/\___/_/ /_(_)
____ _ __________ _ __
/ __ \/ | / / _/ __ \/ | / /
/ / / / |/ // // / / / |/ /
/ /_/ / /| // // /_/ / /| /
\____/_/ |_/___/\____/_/ |_/
____ ____ __
/ __ \____ __________ _/ / /__ / /
/ /_/ / __ `/ ___/ __ `/ / / _ \/ /
/ ____/ /_/ / / / /_/ / / / __/ /
/_/ \__,_/_/ \__,_/_/_/\___/_/
___ _ ___ _
/ | ____ ____| | / (_)____(_)___ ____ _
/ /| | / __ \/ __ \ | /| / / / ___/ / __ \/ __ `/
/ ___ |/ /_/ / /_/ / |/ |/ / / / / / / / / /_/ /
/_/ |_/ .___/ .___/|__/|__/_/_/ /_/_/ /_/\__, /
/_/ /_/ /____/
Loose coupling and high cohesion
Historical impact of C
Building blocks (.c and .h files)
Dynamic Libraries (.so, .dll files)
Historical impact of C++
Combine methods and data in instances
Inheritance and polymorphism
Multiple Inheritance
Anti-Pattern
Communication via virtual members
Countless derived members in one class
Rigid for change
Inseparatable (e.g. for Unit Testing)
Solution
Split up into single-responisbility-objects
Small objects provide a service
Objects are plugins (dependency inversion)
Traditional OO
S.O.L.I.D
Caveat: excessive inheritance
S.O.L.I.D.
Loose coupling and high cohesion
Excessive inheritance
Higher level of abstraction
ABSTRACTION IS YOUR FRIEND
Local thinking (e.g. maintenance)
Extractability / Wireability (e.g. Unit-Tests)
Replaceability (e.g. product options)
Favor aggregates and interfaces !
Theory
S
- Single responsibility principle
a class should have only a single responsibility
O
- Open/closed principle
“software entities … should be open for extension, but closed for modification.”
L
- Liskov substitution principle
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
I
- Interface segregation principle
“many client-specific interfaces are better than one general-purpose interface.”
D
- Dependency inversion principle
one should “Depend upon Abstractions.
Do not depend upon concretions.”
https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
That means in practice ...
SOLID and Application Wiring
The full outside word is injected to each class, this makes the full surroundings mockable.

Each class can be run, debugged and unit-tested solely and independently
on the host
.

Ultra fast turnaround times !
Compile only what is needed and execute it on the host system

Lightning speed unit-test times !
Faster tests means more tests (invariants)
More tests means more safety
Besides the class-based unit-tests a few big-clamp tests will still be necessary. A FEW !
Benefits
Am I S.O.L.I.D ?
Rules for SOLID Application Wiring
Details are plugins with an abstract interface

Access to global objects is forbitten
So is the singleton pattern

The main()-code creates and connects all instances

Other code never creates instances
Use factories instead

You may favor a dependency injection framework that automates the App Wiring
Solid and Application Wiring are different ideas.
But Application Wiring leads to SOLID code like magic.
Machine Variants
Common code base
For different models
For license options within a model
Today's challenges
Efficiency
There'll never be the "right time" to invest in efficiency
-> Continuous improvement
Creativity
Markets become overly crowded
Windows of opportunity open and close faster than ever
-> Get rid of boiler-plate code / tasks
-> Less coding overhead means more customer value
LET
ME
SHOW
YOU
HOW
!
Lessen inheritance !
©2016 All Rights Reserved
Roelof Berg
berg-solutions.de

Application Wiring
Plugin architecture
At startup main() interconnects the plugins
according to the given device
according to the particular model
according to software licenses
Loose coupling and
strong cohesion
Use Interfaces !
and Application Wiring
DDD
Domain Driven Design
Source code reflects the domain's
Ubiqutious Language
Communication between domain and software experts
Large systems: Separate
Bounded Contexts
Embedded: Object names reflect sensors and actuators
CoffeeGrinder
Display
PushButtons
Use the wording of the system designer !
Heater
CoffeeOutlet
Aggregate Root
Combine domain objects into
Aggregate Root
objects
The particular objects within the
Aggregate Root
stay hidden
Onion Architecture
Core
Logic
Glue
Logic
HMI
Tests
Sensors
Actuators
Persistency
Connectivity
Onion
Drivers
Middleware
HMI
dependencies
Relies on Dependency Inversion
Outer components are plugins
Core logic remains independent
Classic
Violates Dependency
Inversion
Abstractions (Middleware)
depend on details (Drivers)
dependencies
Protect your crown jevels !
DDD meets Onion Architecture
Glue
Logic
HMI
Tests
Sensors
Actuators
Persistency
Connectivity
dependencies
DDD enhances abstraction
The closer to the core, the more important is the use of DDD
-> Objects reflect problem domain
->
Ubiqutious Language
DDD in the Core Logic
Core
Logic
Information hiding
->
Aggregate Root
interfaces
Component architecture
-> Component:
Bounded Context
-> No Interdependencies
(only via the Glue Logic)
Example
Code Generation
Today's UML modeling
Do not model every single class
Model on component level
If classes, then only a few
->
Write your header files as text !
Today's code generation
Modeling Behavior
State Charts
Concurrency / Messaging
Composite Structure Diagrams
Active Objects
Messaging and Ports
Connected to State Charts
Application Wiring
Dependency Injection Frameworks
Difference between Framework and API
Inversion of Control Container
Internet of Things
Tech Revolution
Most embedded devices will be controlled
remotely via standard networks
Gartner: 26 billion IoT devices by 2020
(phones, tabloids and PCs excluded)
SW Development Challenges
Short term windows of opportunity
Overlapping standards
Test coverage
Countless remote peer variants
Simulate thousands of connections
Solution
DDD & Onion Architecture
-> Abstract protocol translator
SOLID & App. Wiring
-> Plugin design
http://www.gartner.com/newsroom/id/2636073
Plugin Design
Abstract Protocol Translator
Core
Logic
Glue
Logic
HMI
Tests
Sensors
Actuators
Persistency
Connectivity
TRANSLATOR
PROTOCOL
Translates from/to
Ubiqutious Language
Located inside the Glue Logic
Core speaks DDD (object instances)
Outer layer moves data buffers
Can talk
Several IoT standards
Dialects between vendors/variants
DDD & Onion
Test Automation
For testing the Core Logic
(e.g. high concurrent traffic)
-> Replace the Protocol Translator by a mock stimulator
For testing the Protocol Translator itself
-> Surround it by mock objects
Core Logic operates on abstract command objects
TCP
UDP
RS-485
Test Data
SOAP
Tight
Coupling
Loose
Coupling
Complexity
Optimum
Tight
Coupling
Loose
Coupling
Complexity
Tricia
Arthur
Ford
Optimization Problem
Highly Subjective
Architectural gut feeling
Fortune telling
How to determine ?
Everything's in motion
People are developing
Missions change
Still Questions ?
Sinelabore
Code Generation
Validation
Simulation
Support for
IBM RSARTE
Yakindu (in Eclipse)
State machines are common in devices
Hierarchical Statemachines
Reduce code redundancy
Easier to understand
Code Example
www.embedded-software-architecture.com
Zero Coupling
Outside world: ONLY interfaces
All interfaces are in one shared place
-> NO coupling between modules
Remember ?
(Manual Application Wiring)
Pococapsule
Spring.NET
(Uses automatically IDisruptor)
RS-485
SOAP
...
creates
Full transcript