D-Lab Meeting 2012

D-Lab Meeting 2012
UML, novas tendencias e MDE
Os projetos
Academicos
GHENESys
itSIMPLE
Externos
Petrobrás
Satelites - ESA
UML
UML foi criado em 1992 por Jacobson
seguindo uma preocupação básica:
associar o desenvolvimento de software
orientado a objetos ao processo preliminar
de eliciação de requisitos.
Como todo cientista da época, Jacobson
se preocupava muito com os aspectos
funcionais, mas MUITO MAIS com a fase da
Engenharia que primava por desprezar os
anseios dos usuários.
Nos anos 90 estava no auge o
uso de métricas de software
baseados em pontos de
função e novas formas de
analisar a funcionalidade dos
artefatos, especialmente
software.
Mas, a UML sempre esteve
ligada ao desenvolvimento
orientado a objetos. Portanto
vale a pergunta: o que tem a
ver funcionalidade e objetos?
O Uso prático dos Use Cases
Em um artigo muito interessante sobre o Use Cases pesquisadores
oriundos do mercado (Dobing,Everman e Parsons) se referem aos Use
Cases como “Use Case Narratives”. Isto é absolutamente correto
dado que a forma de eliciação dos Use Case (prática) é na forma de
narrativas, isto é, de processos sequenciais composto de tópicos
funcionais.
Em geral esta “narrativa” vem de stakeholders, que pretensamene
“conhecem bem” os processos, “e também sua perspectiva de
mudança”.
Use Cases
Os “diagramas de Use Case” foram inseridos na UML
1.1 pela OMG em 1997, com o firme proposito de servir
como ferramenta de eliciação (para um projeto
orientado a objetos).
Desde então os Use Case parecem ter entrado em
conflito com os demais diagramas (ou terá sido com a
perspectiva da OMG de ter um método realmente
orientado a objetos?) e a versão 2.2 da UML termina
por “questionar” o uso de uma linguagem de eliciação
que não representa os aspectos não-funcionais.
O Uso prático dos Use Case
Apesar de existirem poucos trabalhos sobre o uso
prático da UML temos em Zeichick 2004 que, neste
ano,
•  20% das empresas usavam UML para todos os
projetos
•  58% usavam somente para alguns projetos
•  42% planejavam usar no futuro para todos os
projetos
•  40% planejavam usar para apenas alguns
projetos
Qual a conclusão?
•  O Uso da UML (e do OOA) não é um “consenso” no mercado
•  “Practicioners” parecem de um lado entusiastas no uso futuro,
incluindo novos adeptos, mas outros parecem estar desistindo do
uso da UML
•  Os movimentos da OMG parecem querer “responder” a esta
tendencia ambigua investindo no MDE
• 
Use Case parece ser a parte mais polemica desta discussão
Existe um trabalho de janeiro/fevereiro de 2010 na IEEE software de um grupo Israelense sobre o uso prático da
OOA (Gelbard, Teéeni, Sade)
Use Case e OOA
Além de não capturar todo o universo de requisitos os Use Case:
•  Levam a uma conentração exagerada na interface interativa
•  Levam a uma classificação tardia e inadequada de objetos
•  Admitem representação em linguagens ambiguas e
inadequadas para a documentação de requisitos
•  Estão de fato à margem da OOA & D
•  Admitem uma exagerada ingerencia do stakeholder no projeto
•  Levam a uma falsa noção de aceitação pelo stakeholder
10
Tomada de decisão
Apesar da orientação ser sempre adiar decisões até
que se conheça melhor o artefato (sistema) exatamente
para evita decisões precipitadas que comprometem o
projeto, não é possível evitar totalmente tomada de
decisões.
Assim, é preciso explicar redirecionamentos e a razão
da escolha de algumas medidas.
rationale
11
O significado...
rationale
ra.tion.ale
análise racional, base lógica de um fato, razão física.
Dicionário Houais, www.uol.com.br
12
O Problema dos rationales
Problema da representação de rationales não está inteiramente
resolvido na academia e levanta uma questão do uso da UML na fase
de requisitos associada à documentação convencional (linguagem
natural).
Existem trabalhos recentes que tratam do problema de como
representar rationales e decisões usando já a notação do UML, ou
inserindo já o SysML. Por exemplo:
Zhou, L., Gorton, I.; UML Profiles for Design Decision and Nonfunctional Requirements, ICSE, 2007.
13
Generalizando o problema: rationales
O problema pode ser generalizado da seguinte forma:
•  o que de fato interessa é monitorar as decisões de
projeto, que consistem não apenas do histórico incluído
na documentação mas em aspectos que normalmente
não são guardados para posteridade;
•  estas decisões podem ser tecnológicas, técnicas,
teóricas, ou compatibilização de critérios e requisitos;
•  especialmente os sistemas têm a sua manutenção
bastante dependente destas decisões
14
Definição de rationales
Um design rationale (DR) [e uma decisão tomada durante a fase de design e
as razões que a fundamentam.
Onde estão os rationales de um projeto de sistema?
•  a documentação de projeto reflete sempre as decisões finais,
isto é, as que foram aprovadas;
•  somente são documentadas decisões cujo impacto é avaliado
como decisivo para o projeto (no momento que a documentação
foi elaborada);
•  mudanças no contexto podem ter alterado o impacto, a
importância, a justificativa, o suporte e até a aplicação técnica da
solução antiga;
15
Uma visão estendida
Design rationale (DR) offers more: not only the decisions, but also the
reasons behind each decision, including its justification, other
alternatives considered, and argumentation leading to the decision.
Jintae Lee and Kum-Yew Lai, What is in Design Rationale?, HumanComputers Interaction, vol. 6, pg. 251-280, Lawrence Erlbaum Associates,
Inc., 1991.
O Processo de eliciação
Domínios
acoplados
stakeholder
desenvolve
or
Questions,
feedback
Unformalized
Structured
Knowledge
Expert
World
Requirement
Engineer
Requirements
Base
Domínios disjuntos
stakeholder
Knowledge, concepts,
Application results
desenvolvedo
r
Alguns conceitos gerais
fronteira
sistema
contexto
Não existe nenhum sistema isolado seja natural ou artificial
Divisão e conquista
fronteira
parte
sistema
contexto
component
e
Sub-sistema
Decomposição não-hierárquica
núcleo
interface
encapsulamento
The System metaphor
i
I
i‘
I’
núcleo
interface
encapsulamento
QVT : Query, view, transform
The QVT specification has a hybrid declarative/imperative nature,
with the declarative part being split into a two-level architecture.
Meta Object Facility (MOF)
Sem dúvida, o problema da fase inicial de projeto é a
“negociação” entre informalidade (não permissividade),
abstração, inovação e o fato de estarmos lidando com
conhecimento incompleto.
Isso gera uma situação onde a formalização é inviável, a
completa informalização é desastrosa, a confiança no processo
é temerária, e a excessiva disciplina é estéril.
Versões do QVT
QVT foi criado no inicio do século dentro do esforço do MOF e
teve a sua versão 2.0 liberada em 2007. Uma referencia
interessante é o documento de revisão de 2003
Gardner, T., Griffin, C., Koehler, J. and Hauser, R.; A review of
OMG MOF 2.0: Querry/Views/Tranformations Submissions and
Recommendatios towards the final Standard, July, 2003
e o documento final que é de 2007
Meta Object Facility (MOF) 2.0: Query/View/Transformation
Specification, July, 2007. (OMG)