Eclipse Finance Day 2012/Session Abstracts
- 1 Why Model When You Can Just Program?
- 2 What makes an application a “good” application
- 3 Gaining traceability in the world of fragmented Agile ALM stacks
- 4 Usage of ECore+OCL for business modeling in the connection with Excel-based model representation and validation in the Life Insurance business domain
- 5 Experiences from Using EJBs in an Eclipse RCP Application
Why Model When You Can Just Program?
Ed Merks, Eclipse Modeling PMC Lead and itemis
As a software developer, programming is as natural as speaking and listening. Java code rolls from your fingertips accelerated by Eclipse's excellent tools. In contrast, modeling is an arcane art focused on strange rituals: rendering diagrams that never scale no matter the monitor size or navigating a maze of menus and dialogs that never yield a comprehensible overview. It's not surprising that there is a strong aversion to modeling: it simply goes against the grain. In this presentation we'll learn that nothing could be further from the truth. Programming and modeling are one and the same.
What makes an application a “good” application
Christian Campo, compeople
There are many aspects of software quality a developer applies when creating “good” software. Examples are maintainability, security, and reliability. However, it is not immediately clear to everyone using the software that these aspects are paramount to “good” software design. Especially end-users tend to judge software by intangible qualities, such as whether they “feel comfortable” using the software.
In this talk we will present the "other side" of software development - usability. What are the aspects that make your software more usable? What should I consider when designing my software? When done right, and considered early on in the software development lifecycle, usability can make your software even better. I will be discussing software usability and its relevance to software engineering. Touching on different topics, answering such questions as: how to structure information, how to visually communicate effectively, how to best support a user’s workflow, and how to make design decisions. This talk should give you a basic understanding of the skills involved in creating more usable software. By doing this, it should supplement your skill-set or at least broaden your horizon.
Gaining traceability in the world of fragmented Agile ALM stacks
Benjamin Muskalla, Tasktop
Over the past decade, many ALM stacks have shifted from vertically integrated silos to tangled and disconnected systems reminiscent of the London tube map. Layer upon layer of legacy, piecemeal Agile deployments and new open source tools have brought traceability to a halt, forcing us into overloaded email inboxes and manual process for tracking delivery in large-scale and regulated environments. The path forward is to either standardize the entire ALM stack, or to embrace heterogeneity. Either way, the ALM architecture must be untangled and the legacy connected for the modernization to happen.
For inspiration, we can look to how ALM strategies have formed bottom-up in the very heterogeneous jungle of open source projects. Open source ALM combines distributed teams, heterogeneous stacks, resource constraints, massive amounts of stakeholder input, and an overload of cross-project dependencies. Despite these challenges, the velocity of many popular open source projects is measurably higher than that of their enterprise counterparts, and what’s even more interesting is that some of the most successful projects provide end-to-end traceability for their constituents. In this talk, we will examine the key lessons learned from the latest developments in open source ALM, and examine how to apply the practices, ALM architecture patterns and strategies for embracing heterogeneity in order to help pave a path for your Agile and ALM modernization efforts.
Usage of ECore+OCL for business modeling in the connection with Excel-based model representation and validation in the Life Insurance business domain
Ilia Louganski, Credit Suisse Trust
In 2012, Credit Suisse Trust (CST) faced significant challenges as it wanted to adapt its life insurance platform to rapidly changing business needs. A backlog of change requests was piling up; turn-around times were increasing and time-to-market for new products had become unacceptable. It became clear that the platform had reached a point of complexity where it could no longer be managed using the IT processes and methodologies in place.
CST management quickly realized what was happening and saw the lack of consistency and clarity of the business requirements as the main root cause of the situation. The tooling put in place to capture and track the requirements used Excel® as deployment vehicle, a tool that was commonly used by the team members. However, the structure of the Excel sheet was designed and managed with Business Object Models developed with the open source XOCL framework, which integrates mainstream ECore and OCL. Such models were also validated by using automatically generated tabular editors.
The presentation will show how the approach helped to systematically work through a large number of requirements and how the business gained control over the situation, thanks to an ECore+OCL based approach in combination with an Excel based methodology for representation and validation.
Experiences from Using EJBs in an Eclipse RCP Application
Markus Hediger (SIX Payment Services) & Philippe Marschall (Netcetera)
Three-layer architectures using EJBs are fairly common in applications in the financial sector. However there does not yet exist a standard for accessing remote EJBs from OSGi applications (RFP 152 has just been published). We have been using remote EJBs in an Eclipse RCP application for several years. We'd like to present our approach, its pros and cons and how it rates on an "OSGi-cleanness" scale. We believe it is generic enough to be applicable to any application server. In addition we will show how we have set up the developers' Eclipse workbenches to increase productivity.