D-Lab Meeting 2012
Transcrição
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)