Variabilidade em Software: Estado da Arte e Direções Futuras

SEGUNDA (30/09/2013) – 09:00 – 10:30
Variabilidade é um aspecto fundamental do software. É a habilidade de criar variantes do sistema para diferentes segmentos de mercado e contextos de uso. Variabilidade vem sendo investigada e explorada no contexto de linhas de produto de software, mas é relevante para outras áreas, tais como, ecosistemas de software e software sensível ao contexto.
Variabilidade introduz complexidade para todas as áreas da engenharia de software, e demanda à criação de métodos e ferramentas baseados em variabilidade que possam lidar de forma efetiva com tal complexidade. A engenharia de um sistema com variabilidades requer a engenharia de um conjunto de sistemas simultaneamente. Como resultado, requisitos, arquitetura, código e testes são inerentemente mais complexas do que na engenharia de software tradicional. Métodos e ferramentas baseados em variabilidade promovem as similaridades entre variantes do sistema, enquanto também permitem a gerência efetiva das suas diferenças.

Esta palestra irá analisar como a variabilidade afeta o ciclo de vida do software, focando em requisitos, arquitetura e verificação/validação, rever o estado-da-arte de métodos e ferramentas baseados em variabilidade, assim como identificar direções futuras.


Krzysztof Czarnecki é professor de Engenharia da Computação e Elétrica da Universidade de Waterloo, Canadá. Ele foi pesquisador na Daimler Chrysler Research (1995-2002), Alemanha, atuando na melhoria de práticas e tecnologias de desenvolvimento de software para os domínios corporativo, automotivo, espacial e aeroespacial. Ele é co-autor do livro “Generative Programming” (Addison- Wesley, 2000), o qual aborda a automação do desenvolvimento componentizado de software baseado em linguagens específicas de domínio. Como pesquisador na Universidade de Waterloo, ele foi Research Chair em Engenharia de Requisitos de Sistemas de Software Orientado a Serviços do NSERC/Bank of Nova Scotia, e trabalhou em vários tópicos em engenharia de software dirigida por modelos, incluindo linhas de produto de software e modelagem de variabilidade, gerenciamento de consistência e transformações bidirecionais, e modelagem dirigida por exemplos. Ele recebeu os seguintes prêmios: Premier’s Research Excellence Award em 2004 e o British Computing Society in Upper Canada Award for Outstanding Contributions to IT Industry em 2008.

Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work

TERÇA (01/10/2013) – 16:30 – 18:00

Abstract. Big Ball of Mud (BBoM) architectures are viewed as the
culmination of many design decisions that, over time, result in a
system that is hodgepodge of steaming, smelly anti-patterns. Yet how
BBoM architectures come into existence and successfully evolve is much
more nuanced. BBoMs often do not result from well-intentioned design
ideas gone wrong. Nor are they simply an accretion of expedient
implementation hacks. Often BBoM systems can be extremely complex,
with unclear and unstable architectural boundaries and requirements.
Because of their complexity, BBoM architectures are likely not
understood by any single mind. They typically are fashioned out of
many parts, which together comprise a sprawling whole. So BBoM systems
can and do have good, as well as bad and ugly parts. Successfully
deployed BBoM systems continue to work well enough, in spite of their
design flaws. How can that be?

Much has happened in our industry since the original discussion and
publication of the Big Ball of Mud paper in 1998. When that paper was
originally published, agile methodologies such as eXtreme Programming
and Scrum were just beginning to gain popularity. The growth and
popularity of agile practices might be partially due to the fact that
the state of the art of software architectures is so muddy. Being
agile, with its focus on extensive testing and frequent integration,
arguably makes it easier to deal with evolving architectures and
keeping systems working while making significant improvements and
adding functionality. However, although Agile has been around for
quite some time, we can see that it still does not prevent Mud.

This talk will examine the paradoxes that underlie Big Balls of Mud,
what causes them, and why they are so prominent. I’ll explore what
agile practices can help us avoid or cope with mud. I’ll also explain
why continuous delivery and TDD with refactoring is not enough to help
ensure clean architecture and why it is important to understand what
is core to the architecture and the problem at hand. Understanding
what changes in the system and at what rates can help you prevent
becoming mired in mud. By first understanding where a system’s
complexities are and where it keeps getting worse, we can then work
hard (and more intelligently) at sustaining the architecture.
Additionally, I’ll talk about some practices and patterns that help
keep the code clean or from getting muddier The original Big Ball of
Mud paper described some best practices such as SHEARING LAYERS and
SWEEPING IT UNDER THE RUG as a way to help deal with muddy
architectures. Additionally there are some other practices such as
make code more habitable.


Joseph Yoder is a founder and principal of The Refactory, Inc., a
company focused on software architecture, design, implementation,
consulting and mentoring on all facets of software development. Joseph
is an international speaker and pattern author, long standing member
of the ACM, and the President of The Hillside Group, a, a group
dedicated to improving the quality of software development. Joseph
specializes in Architecture, Analysis and Design, C#, Java, Smalltalk,
Patterns, Agile Methods, Adaptable Systems, Refactoring, Reuse, and
Frameworks. Joe is the author of many patterns, including being an
author of the Big Ball of Mud pattern, which illuminates many
fallacies in the approach to software architecture.Joe currently
resides in Urbana, Illinois. He teaches Agile Methods, Design
Patterns, Object Design, Refactoring, and Testing in industrial
settings and mentors many developers on these concepts. He currently
oversees a team of developers who have constructed many systems based
on enterprise architecture using the .NET environment. Other projects
involve working in both the Java and .NET environments deploying
Domain-Specific Languages for clients. Joe presents tutorials and
talks, arranges workshops, and organizes leading technical conferences
held throughout the world, including international conferences such as
Agile, Agile Portugal, Encontro ¡gil, AOSD, CBSoft, JAOO, QCon, PLoP,
AsianPLoP, SugarLoafPLoP, OOPSLA, ECOOP, and SPLASH. Joe thinks
software is still too hard to change. He wants do something about this
and believes that with good patterns and by putting the ability to
change software into the hands of the people with the knowledge to
change it seems to be on promising avenue to solve this problem.