Sample Chapter of Practical Unit Testing with TestNG and MockitoTomek Kaczanowski
This is Chapter 10 of "Practical Unit Testing with TestNG and Mockito" book.
This is one of the last chapters which explains how to make your unit tests manageable, so they do not become a burden as the project develops and changes are introduced.
You can learn more about the book on http://practicalunittesting.com.
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
Using Alf with Cameo Simulation Toolkit - Part 1: BasicsEd Seidewitz
Alf is an OMG-standard textual language with a familiar Java-like syntax, but it is designed specifically to be used in the context of graphical, executable UML and SysML models. This language is available for use in No Magic's Cameo Simulation Toolkit (CST) v18.5 to write expressions and behaviors in executable UML. Behind the scenes, Alf is actually compiled into UML activity models, which are then automatically integrated into your overall model, so they can be seamlessly executed using CST. This presentation gives an introduction to the Alf language, a tutorial on how to use it in CST and hands-on exercises to try yourself. You will be amazed at how much quicker and easier it is to write three lines of Alf code, rather than create by hand an equivalent activity model of 20 or more elements!
A presentation on the reasons and techniques for creating prototypes of interactive projects. From the Media Design Practices MFA at Art Center College of Design.
Updated September 2, 2017
Chapter 17: Models of the system
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Le lean canvas démystifié - le Lean Canvas de Running Lean par l'exempleChristopher Parola
Le Lean Canvas est le petit dernier des canvas du Product Management.
Théorisé par Ash Maurya dans Running Lean, il se base sur le Business Model Canvas d'Alex Osterwalder.
Dans cette présentation, j'ai voulu démystifier cet outil essentiel, qui permet de poser ses premières hypothèses avant même de se lancer dans la réalisation d'un produit.
Je suis impatient d'avoir vos retours !
User interface (UI) for mobile applicationsAashish Uppal
The User Interface (UI) is everything designed into an information device with which a human being may interact -- including display screen, keyboard, mouse, light pen, the appearance of a desktop, illuminated characters, help messages, and how an application program or a Web site invites interaction and responds to it.
Visit this link for more info:- http://aashish.livewithbrands.com/
Sample Chapter of Practical Unit Testing with TestNG and MockitoTomek Kaczanowski
This is Chapter 10 of "Practical Unit Testing with TestNG and Mockito" book.
This is one of the last chapters which explains how to make your unit tests manageable, so they do not become a burden as the project develops and changes are introduced.
You can learn more about the book on http://practicalunittesting.com.
Adopter une méthodologie pour développer un système est indéniable au risque de vous planter, cette présentation étale sur ses slides la méthodologie 2TUP, qui fait partie de la famille des Processus unifiés basés sur UML
Using Alf with Cameo Simulation Toolkit - Part 1: BasicsEd Seidewitz
Alf is an OMG-standard textual language with a familiar Java-like syntax, but it is designed specifically to be used in the context of graphical, executable UML and SysML models. This language is available for use in No Magic's Cameo Simulation Toolkit (CST) v18.5 to write expressions and behaviors in executable UML. Behind the scenes, Alf is actually compiled into UML activity models, which are then automatically integrated into your overall model, so they can be seamlessly executed using CST. This presentation gives an introduction to the Alf language, a tutorial on how to use it in CST and hands-on exercises to try yourself. You will be amazed at how much quicker and easier it is to write three lines of Alf code, rather than create by hand an equivalent activity model of 20 or more elements!
A presentation on the reasons and techniques for creating prototypes of interactive projects. From the Media Design Practices MFA at Art Center College of Design.
Updated September 2, 2017
Chapter 17: Models of the system
from
Dix, Finlay, Abowd and Beale (2004).
Human-Computer Interaction, third edition.
Prentice Hall. ISBN 0-13-239864-8.
http://www.hcibook.com/e3/
Le lean canvas démystifié - le Lean Canvas de Running Lean par l'exempleChristopher Parola
Le Lean Canvas est le petit dernier des canvas du Product Management.
Théorisé par Ash Maurya dans Running Lean, il se base sur le Business Model Canvas d'Alex Osterwalder.
Dans cette présentation, j'ai voulu démystifier cet outil essentiel, qui permet de poser ses premières hypothèses avant même de se lancer dans la réalisation d'un produit.
Je suis impatient d'avoir vos retours !
User interface (UI) for mobile applicationsAashish Uppal
The User Interface (UI) is everything designed into an information device with which a human being may interact -- including display screen, keyboard, mouse, light pen, the appearance of a desktop, illuminated characters, help messages, and how an application program or a Web site invites interaction and responds to it.
Visit this link for more info:- http://aashish.livewithbrands.com/
Anything, anytime, anywhere?
'In the twenty-first century the technology revolution will move into the everyday, the small and the invisible.' (Mark D. Weiser, XEROX)
Das 'Graphical User Interface' (GUI) dominiert immer noch unseren digitalen Alltag.
(Touch)Screen, Maus, Tastatur legen die Interaktion fest und sind die haptische Verbindung, aber auch Grenze zur Technologie. Diese Grenze kann durch neue Technologien wie ubiquitäres Computing (UC) jedoch unsichtbar werden, indem Alltagsgegenstände als Interaktionselemente genutzt werden.
Doch wie sieht eine Technik aus, die Menschen unterstützt ohne ihm dabei Aufmerksamkeit zu rauben, indem sie ihn zwingt, zuerst neue Dinge zu erlernen?
Wie sehen UIs im UC heute aus?
Welche Ein-und Ausgabe Alternativen gibt es?
Ist der Einsatz von von UC überall sinnvoll?
Welche Gefahren und Ängste verbergen sich?
Wir möchten mit dem Vortrag einen kleinen Einblick in die Vor - sowie Nachteile von No (G)UI/UC geben und etwas zum Nachdenken anregen.
Zukunftssichere Websites für alle Endgeräte entwickeln
Durch die drastische Veränderung der Medienlandschaft und die Vielfalt der Geräte mit denen heutzutage das Internet genutzt wird, ergeben sich neue Anforderungen an moderne Websites. Um diesen Anforderungen gerecht zu werden, reicht die Entwicklung einer klassischen Webpräsenz nicht mehr aus. Smartphones und Tablet-PCs müssen ebenso bedient werden wie Desktop- Rechner mit Widescreen-Monitoren und internetfähige TV-Geräte.
Responsive Design stellt einen neuen, zukunftssicheren Ansatz dar, bei dem verschiedene Endgeräte gleichermaßen berücksichtigt sowie Entwicklungs- und Pflegeaufwand der Website gering gehalten werden können.
Die Diversifizierung der Endgeräte, auf denen Inhalte im WWW angezeigt werden können, nimmt zu. Konzeptioner und Designer stehen vor der Aufgabe, für multiple Plattformen und "Devices" Inhalte bereit zu stellen.
Responsive Design stellt sich dieser Herausforderung.
Die Präsentation gibt einen ersten Einblick anhand einiger Beispiele. Der jeweils erste Screenshot eines Beispiels verlinkt dabei immer auf die entsprechende Webseite.
Kudos an Luke Wroblewski und Brad Frost für Ihre hochwertigen und unverzichtbaren Insights zu diesem Thema. Die beiden sollte man auf jeden Fall gelesen haben.
Kommentare und Feedback sind ausdrücklich erwünscht.
These are the slides from my talk at the Norwegian Developer conference in Oslo 2013 on why unit testing is not necessarily the best way to test our code.
Domain Driven Design fordert eine gemeinsame Sprache ALLER Beteiligten. Die Datenbank-Verantwortlichen stehen häufig aussen vor, da sie in Relationen und Tupeln denken und somit weit weg sind von den Konstrukten von DDD. Dieser Vortrag zeigt, warum und wie nicht-relationale Datenbanken den Gap schliessen können.
The Single Responsibility Principle (SRP) is one of the 5 SOLID principles. These slides gives you an overview of the principle as well as a refactoring from a non-SRP code to a SRP-code.
Publish & Subscribe to events using an Event AggregatorLars-Erik Kindblad
These slides gives guides you through what the Publish-Subscribe pattern is, how to create an Event Aggregator, how you can use it in the UI and in other layers and 2 code samples that refactors from a non pub-sub architecture to a pub-sub architecture.
This presentation goes through what Inversion of Control is, which IOC patterns that exists, which of the patterns you should use and when you should use them.
AndroMDA - Einführung in eine Open Source Model Driven Architecture LösungEduard Hildebrandt
AndroMDA ist ein freiverfügbarer erweiterbarer Generatorbaukasten in Anlehnung an die Spezifikationen zur Model Driven Architecture (MDA) der Object Management Group (OMG). Aus UML-Modellen wird Code für beliebige Zielplattformen erzeugt. Anders als andere MDA-Toolkits bringt AndroMDA fertige Cartridges für aktuelle Entwicklungsplattformen wie Struts, JSF, Spring, Hibernate, EJB und jBPM mit. Weiterhin besteht zusätzlich die Möglichkeit zur Erstellung eigener Cartridges.
Nach einer kurzen Einführung in MDA gibt der Vortrag einen Überblick über AndroMDA und erläutert die Architektur und Grundprinzipien. Die Möglichkeiten des Toolkits werden anhand einer Web-Anwendung für Pizza-Bestellungen erklärt. Anschließend besteht die Möglichkeit zur Diskussion und zum Erfahrungsaustausch aus Projekten.
Veranstaltung "Confluence & JIRA Community Day 2013" in Frankfurt/M. am 21. November 2013.
Eine Präsentation zum Thema "JIRA goes i18n" von Jan Schulz, Head of Project bei der catWorkX GmbH.
IA/ UX in Scrum Entwicklungs-Prozessen - 2009Wolf Noeding
Presentation auf der Deutschen IA Konferenz 2009 - "IA & Agiler Softwareentwicklungsprozess"
(Presentation for the German IA Conference 2009 in Hamburg - "IA & Agile development process")
Plm Open Hours - Detailkonzepte welcher Art führen zu erfolgreichen Implement...Intelliact AG
Das Detailkonzept ist ein zentrales Dokument, weil es als Schnittstelle zwischen der Projektleitung, den Anwendern und der Umsetzung dient. Für den Projektleiter bietet es einen roten Faden, der durch die Verwendung und die Anpassung des Systems führt. Für die Anwender detailliert es die Anwendungsfälle soweit aus, dass damit bereits der Grundstein für die spätere Schulung gelegt wird. Zudem dient es bei der Implementierung als Grundlage für die Systemspezifikation (Module und Komponenten) und beschreibt bereits die Schranken für testgetriebene Entwicklung.
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und...Marc Bless
Wir erledigen alles sofort - Warum Qualität, Risikomanagement, Usability und Dokumentation nach jeder Iteration fertig sind (Scrum Med 2013) (CONSANIS)
Consanis - die Nr. 1 für Agile Methoden in der Medizintechnik
http://www.consanis.de
PLM Open Hours - Best Practices in der ProdukstrukturierungIntelliact AG
Diese Optimierung basiert auf einer gutstrukturierten generischen Produktdefinition, die transparent alle Zusammenhänge in den Prozessen der Produktlebenszyklus integriert. Um eine solche optimale Situation zu erreichen, bedarf es vieler Analysen und aufwendiger konzeptioneller Arbeiten, um alle Sichten auf das Produkt in allen Phasen des Lebenszyklus zuverlässig abzubilden. In diesem Vortrag sollen Teilschritte der Produktstrukturierung erläutert werden, die ein schnellen Benefit auf dem Weg zum oben genannten Optimum erbringen.
Speaker: Michael Ferber, Head of Consulting
Über 170 Kunden setzen auf Camunda Enterprise zur Automatisierung ihrer Geschäftsprozesse. Die meisten wurden in ihren Projekten durch unsere Berater begleitet. Basierend auf diesem Erfahrungsschatz wird Michael Ferber die folgenden Fragen beantworten:
Wann macht der Einsatz von Camunda überhaupt Sinn? Welche Probleme lassen sich damit lösen?
Welche personellen Ressourcen brauche ich für erfolgreiche Camunda-Projekte?
Wie aufwendig ist die Projektumsetzung mit Camunda? Wie kann ich einen Business Case rechnen?
Automatisierter Software-Test unter JavaGFU Cyrus AG
Dieser Vortrag zeigt die Vorteile moderner Ansätze für den Test von Java-Anwendungen auf. Die für eine erfolgreiche Testautomatisierung einzusetzenden Java-Test-Frameworks und -Werkzeuge werden exemplarisch vorgestellt (z.B. JUnit, Abbot, JETM). Die Verwaltung von Testdaten und der Einsatz von dedizierten Testdatenbanken werden behandelt. Herr Seekamp veranschaulicht den praktischen Einsatz von automatisierten Testverfahren anhand von zwei JavaEE-Projekten. Er geht außerdem auf den Begriff des Testmanagement und das Konzept der testgetriebenen Software-Entwicklung ein. Die für die Durchführung von automatisierten Software-Tests notwendigen Bausteine werden zusammengefasst. Der Ausblick benennt die Problemfelder und das Potenzial der Testautomatisierung.
* Grundlagen und Ziele des Software-Tests
* Manueller Software-Test und dessen Nachteile
* Übergang zu automatisierten Testverfahren und deren Vorteile
* Frameworks und Werkzeuge für die Testautomatisierung
* Verwaltung von Testdaten und Einsatz von Testdatenbanken
* Beispiele für Testautomatisierung in JavaEE-Projekten
* Notwendigkeit des Testmanagement
* Konzept der testgetriebenen Entwicklung und Vorteile für den Entwickler
* Bausteine für automatisierte Software-Tests
* Problemfelder und Potenzial der Testautomatisierung
Vorgehensmodelle - Methoden der WirtschaftsinformatikClaus Brell
Vorgehensmodelle sind fester Bestandteil der Methodik der Softwareentwicklung. Kenntnisse über Vorgehensmodelle gehören zum selbstverständlichen Handwerkszeug des Wirtschaftsinformatikers. An der Hochschule Niederrhein lernen Studierende Vorgehensmodell im zweiten Semester kennen. Wichtig ist, den grundsätzlichen Unterschied von phasenorientierten und nahtlos zu klassischem Projektmanagement passenden Vorgehensmodellen und agilen Vorgehensweisen herauszuarbeiten.
Requirements Engineering in agilen Projekten - Flexibilität ist gefordertGFU Cyrus AG
In agilen Projekten ist funktionierende Software wichtiger als ausufernde Dokumentation. Durch kurze Entwicklungszyklen (Iterationen) werden den Anwendern schon während der Entwicklung Teilpakete der geplanten Softwarelösung mit einem sinnvollen Funktionsumfang bereit gestellt. In agilen Projekten ist die flexible Reaktion auf Änderungen der Anforderungen wichtiger als ein starrer Projektplan. Agilität bei der Entwicklung erfordert aber auch Agilität bei der Beschreibung der funktionalen Anforderungen (Requirements Engineering). Use Case-Modelle eignen sich hervorragend für diese Aufgabe. Durch dieses Vorgehen ist es möglich, Wünsche der Anwender, geänderte Rahmenbedingungen und Erfahrungen aus der bisherigen Entwicklung in der Realisierung zu berücksichtigen. Reinhard Brüggemeyer, Dozent dieses "Treffpunkt Semicolon", zeigt, warum in agilen Projekten der Anwender und seine Aufgaben im Mittelpunkt stehen. Pro und Contra des agilen Vorgehens gegenüber dem klassischen Requirements Engineering werden diskutiert.
Jedes IT-System stirbt irgendwann und muss durch ein neues System abgelöst werden. Solche Systemablösen bergen zahlreise Herausforderungen: Keine Doku, eine Technologie, die niemand mehr gut kennt, wissende Mitarbeiter sind nicht mehr greifbar, hoher Zeitdruck, großes Risiko im Betrieb etc. - oft eher Organtransplantation, als IT-Projekt.
Im Vortrag möchte ich meine Erfahrungen aus großen Systemablöseprojekten teilen. Wir werden uns ansehen, wie man Methoden aus Requirements Engineering und Reverse Engineering so kombiniert, dass alle notwendigen Anforderungen entdeckt werden. Wir werden sehen, dass die Zusammenarbeit zwischen Fachbereich und IT der kritische Erfolgsfaktor ist, wie man das am Besten organisiert und wie man Use Cases und ein Glossar dabei unterstützend einsetzt.
Um agile Entwicklung sinnvoll in einem Projekt zu ermöglichen, spielt die Architektur des Systems eine entscheidende Rolle. In einem agilen Projekt sind Architektureigenschaften wie Installierbarkeit und Prüfbarkeit entscheidend, da die Software in kurzen Abständen regelmäßig geliefert und im besten Fall dem Endnutzer zur Verfügung gestellt wird. Diese kurzen Releasezyklen gelingen nur durch ein hohes Maß an Automatisierung. Agile Projekte benötigen bereits passende Lösungsansätze in der Architektur, die es erlauben eine Continous Delivery Pipeline möglichst einfach zu realisieren; das Architekturmuster „Microservices“ versucht u.A. diesen Anforderungen gerecht zu werden.
Weitere Vorteile des Architekturmusters ergeben sich bei der Skalierung von Projekten. Durch den Einsatz von „Microservices“ können Projekte einfach aufgeteilt und parallel von mehreren Cross-Functional Teams mit agilen Methoden umgesetzt werden.
Die Idee eines Microservice ist nicht neu: das System wird in kleine, losgelöste Anwendungen (sog. Microservices) aufgeteilt. Diese Bausteine stellen Ihre Funktionalität als Service zur Verfügung. Der Vortrag gibt einen Praxiseinblick, auf welche Weise man vom Einsatz des Architekturmusters „Microservice“ in einem agilen Projektumfeld profitieren kann. Es wird aufgezeigt, wo sich in der Praxis Schwierigkeiten ergeben und wie man diesen vorbeugen kann. Der gesamte Vortrag gibt einen grundlegenden Einblick in die agile Entwicklung auf Basis einer Microservice-Architektur.
5. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen
6. Prozess zur Anforderungserfassung
1. Oberfläche skizzieren z.B. Methode Wireframes in einem
Workshop mit dem Kunden
2. Iterativ ein Klick-Modell erstellen z.B. mit HTML und
JavaScript
3. Fachliche Komponenten aus dem Klick-Modell identifizieren
4. Use-Cases und Geschäftsmodell aus dem Klick-Modell
ableiten für die einzelnen fachlichen Komponenten
5. Spezifikation erstellen
7. Notationselemente
• Akteur
- Steht mir Use Case inVerbindung
- Hat immer einen Name
- Darstellung: z.B. als Strichmännchen
• Use Case
- Beschreibt nach außen sichtbares
Verhalten des Systems
- Von Akteur ausgelöst
- Hat Ergebnis, kein internes
Verhalten
- Darstellung: Ellipse
• Assoziationen
- Können gerichtet sein
- Nur binäre Assoziationen
- Darstellung: Linie
• System
- Beschreibt die System grenzen
- Darstellung: Rechteck
11. Use-Case als zentrales Analyseelement
Use-Case
Testbarkeit
Performanz
Sicherheit
Änderbarkeit
Verfügbarkeit
Bedienbarkeit
Architekturziele
UI Anforderungen
UI Design
Business Regeln
Daten Format
...
12. Anwendungsfälle spezifizieren
oder kurz gesagtText schreiben
•Tabellen basiere Beschreibung (Template)
•Domain spezifische Sprache zur Spezifikation
•Textuelle Beschreibung
13. Aufbau eines Anwendungsfalls
• Name und Nummer (z.B. Kunden verwalten / UC-2.01)
• Beschreibung
• Kurze Beschreibung, was im Anwendungsfall passiert.
• Beteiligte Akteure
• Akteure sind beteiligte Personen oder Systeme
• Verwendete Anwendungsfälle
• Aufzählung der verwendeten Anwendungsfälle
• Auslöser
• Vorbedingungen
• Alle Bedingungen, die erfüllt sein müssen, damit dieser Anwendungsfall ausgeführt
werden kann.
• Nachbedingung / Ergebnis
• Der Zustand, der nach einem erfolgreichen Durchlauf des Anwendungsfalls erwartet
wird.
32. Template Gesamtspezifikation
Anforderungsanalyse
1. Einleitung
2. Ausgangssituation und Zielsetzung
3. Funktionale Anforderungen
4. Nicht-funktionale Anforderungen
5. Sicherheitsrelevante Anforderungen, Risikoakzeptanz
und Sicherheitsstufen
6. Lebenszyklusanalyse und Gesamtsystemarchitektur
7. Schnittstellenübersicht
33. Template Anforderungsanalyse
Quelle: http://www.volere.co.uk
PROJECT DRIVERS:
1. The Purpose of the Project
2. Client, Customer, Stakeholders
3. Users of the Product
PROJECT CONSTRAINTS:
4. Mandated Constraints
5. Naming Conventions and Definitions
6. Relevant Facts and Assumptions
FUNCTIONAL REQUIREMENTS:
7. The Scope of the Work
8. The Scope of the Product
9. Functional and Data Requirements
NON-FUNCTIONAL REQUIREMENTS:
10. Look and Feel
11. Usability and Humanity
12. Performance
13. Operational
14. Maintainability and Support
15. Security
16. Cultural and Political
17. Legal
PROJECT ISSUES:
18. Open Issues
19. Off-the-shelf Solutions
20. New Problems
21. Tasks
22. Cutover
23. Risks
24. Costs
25. User Documentation and Training
26. Waiting Room
27. Ideas for Solutions
38. Architekturprinzipien
• Schichten einer Applikation
Jede Schicht (Tier) ist für eine Aufgabe
zuständig. In einer Anwendung fallen
i.d.R. die folgenden Kernaufgaben an:
• Darstellen von Daten
• Verarbeitung der Benutzereingaben
(Interaktionen)
• Verarbeitung Geschäftslogik
• Speichern von Daten
73. Trennung fachliche und technischer
Architektur
• T – Komponenten
• Stellen eine technische Schnittstelle bereit.
• A – Komponenten
• Domain Komponenten z.B. Bestellung Service.
• R – Komponenten
• Komponenten für die Präsentation dürfen technische Komponenten nutzen und auf die A
Komponenten zugreifen.
• 0 – Komponenten
• Komponenten die in der gesamten Anwendung genutzt werden dürfen. Z.B. Logger
Komponente.
• R auf A ist erlaubt,T auf A ist nicht erlaubt
• R auf 0,A auf 0 undT auf 0 ist erlaubt