Top Community Contributors
Introducing RepoDoc, a document generator for Enterprise Architect
Written by Archimetes
SysML 1.4 reference card
Written by Guillaume
Enterprise Architect User Group: London 2017
Written by DT_Sam
Enterprise Architect identified for Agile Development and DevOps: SD Times In-depth Feature
Written by sparxsystems
Panorama 360 Insurance and Wealth Management Enterprise Business Framework is available on Amazon
Written by Pierre Gagne
RepoDoc, a call for testing
Written by ArchimetesRead more...
We are Profiling EA Users
Written by sparxsystems
Managing a student project with Enterprise Architect - Part 4
Written by doug rosenberg
Using the metaphor of a jigsaw puzzle from the previous blog, we inferred the necessity of technology to tame the complexity of a system that is in a state of constant change but which nevertheless must be managed and guided such that it meets key objectives at the individual and enterprise level. The major problem is that jigsaws never come with instructions on how to build order out of chaos – and the individual approach is usually random, based on trial and error!
With any project, be it building a house or fixing a washing machine, a manual is essential. To have any chance of arriving at a destination when setting out into unknown territory, it is wise to have a plan or a map. Without these instructions one can lose track or get completely lost. In the enterprise, when teams lose the focus of project objectives, this translates as financial loss or project failure.
Similarly, a Use Case is a documented record that describes a procedure for interaction with a system and when these records are collectively available they stimulate discussion, which generates ideas for improvements and efficiencies. A Use Case approach forces the consideration of users and customers, which can help elicit feedback and create a dialog to help build better systems. The interaction or cooperation generated creates added value. These records provide transparency, agreement and shared awareness, acting as way markers in a broad landscape of procedures that are foreign to many, as individual knowledge is often siloed.
Although Use Cases are valuable and provide a positive return on investment in time and resources, their development is also takes time. For many different teams however, they lay a foundation for future reference. Enterprise Architect is an indispensable, time saving tool in the Use Case development process.
In mid 2013 Sparx Systems conducted a webinar showcasing model driven development of Use Cases. This informative session reviewed the rich features of Enterprise Architect that can assist in the key processes of analysis, development and testing, saving time while replacing random processes with best practice and creating consensus and clarity between stakeholders.
The webinar can be viewed at:
Mr Ben Constable, Senior Analyst at Sparx Systems, explores Enterprise Architect's Structured Scenario Editor for model-driven use case analysis.
In this webinar, you'll learn how to:
- Add structured scenarios to your use case models
- Link scenarios to formal requirements and business rules for improved traceability
- Automatically generate downstream deliverables from scenarios, including reports, test cases and behavioral models
To suit users in different time zones, we will hold two sessions - each 30 minutes in duration.
To register for this webinar, please visit www.sparxsystems.com/webinars.
In "test driven" approaches to development, unit testing often gets most of the attention. However, unit testing is generally most useful in discovering "errors of Commission" (more poetically, "whoops, I coded that wrong"). Unit testing is of much less help in discovering "errors of Omission" (more poetically, "whoops, I didn't think of that"). In general errors of Omission are much trickier to detect, and there is very little automated support for detecting them. We worked very closely with the development team at Sparx as they developed the "use case thread expander", and it brings a very unique and useful capability to the industry.
As you read this chapter, make sure you don't miss the discussion at the end of the chapter called "And the moral of the story is..." where we describe some actual "errors of Omission" that were caught and fixed before the release of our mapping software using these acceptance testing techniques, and how fixing these errors improved the user experience.