Capítulo 4 – Engenharia de Software
4.2. Ciclo de Vida do Software
4.4.3. Propostas de extensão da UML
Diante dos benefícios e da representatividade, principalmente dos diagramas de casos de uso, a UML vem sendo também utilizada para representar os conceitos de negócio. O objetivo da extensão do uso da UML é compartilhar uma mesma notação desde a análise do negócio até o desenvolvimento do sistema. Isso porque se acredita que a modelagem de negócio tem como uma de suas finalidades apoiar o desenvolvimento de sistemas. Porém, para alcançar tal objetivo foi preciso ampliar a notação UML para tornar possível a representação de conceitos considerados importantes para o negócio e desnecessários para o aspecto dos sistemas (KNIGHT,
2004). A abordagem da OMG, a de Marshall (1999) e a de Eriksson-Penker Business
Extensions (ERIKSSON e PENKER, 2000) são exemplos de extensões.
A OMG publicou em 1997 um documento, que descreve os mecanismos de extensão para a modelagem de negócios utilizando a UML, intitulado “UML extension
for business modeling”. No entanto, a obra não descreve completamente os novos
conceitos e notações para a modelagem de negócio, mas apenas expõe os chamados estereótipos que adaptam o uso da UML. No entanto, algumas mudanças e inovações podem ser observadas na UML versão 2.0, principalmente no que se refere à modelagem de processos de negócios e aos mecanismos de extensão da UML (AZEVEDO JUNIOR e CAMPOS, 2008).
Outra proposta de extensão da UML para modelagem do negócio é a de Marshall (1999), que sugere um metamodelo para identificação e descrição de conceitos que delineiam os sistemas usando a UML. A proposta tem como base quatro elementos principais: propósito, entidade, processo e organização.
Já a abordagem de Eriksson e Penker (2000) também propõe uma técnica para estender a UML. A abordagem dos autores fundamenta-se nos processos e no paradigma da orientação a objetos para definir as arquiteturas do negócio. As extensões da UML são empregadas para representar processos, recursos, regras e objetivos. A proposta Eriksson-Penker serve como uma espécie de embasamento para realização de adaptações e desenvolvimentos a serem conduzidos pelos chamados arquitetos do negócio durante a modelagem de situações específicas. Assim, o objetivo é formar uma arquitetura que usa a UML para modelar o negócio com possibilidade de adicionar estereótipos (stereotypes), valores (tagged values) e restrições (constraints) adequados a cada aspecto do negócio. A abordagem usa os objetos e seus relacionamentos para conformar o modelo do negócio. A arquitetura do método é composta por vistas compostas por um ou mais tipos de diagramas. As vistas são: (i) Visão do Negócio (Business vision) que modela conceitos e objetivos estratégicos do negócio; (ii) Processo do Negócio (Business process) que contém os processos de negócio e os recursos necessários ao alcance dos objetivos; (iii) Estrutura do Negócio (Business
structure) que apresenta a estrutura dos recursos (físicos, informacionais, humanos), e;
(iv) Comportamento do Negócio (Business behavior) que é a vista responsável pela representação do comportamento e da interação entre recursos e processos. Com essas
outra, observa-se uma sistematização importante na transformação da arquitetura do negócio para a arquitetura de software. A proposta Eriksson-Penker é analisada por alguns autores como Azevedo Junior e Campos (2008) e Knight (2004) que apontam algumas desvantagens ou oportunidades de melhoria. Os primeiros afirmam que a proposta não explora a sistematização da passagem de uma vista para outra no contexto de um processo ou metodologia de desenvolvimento de sistemas. Já a segunda autora afirma que, além de o método proposto não abranger sequencialmente a análise do modelo de negócio e a identificação dos requisitos, ele também propõe que, nos casos em que o modelo de negócio é desenvolvido com o propósito de servir de base para elicitação de requisitos, não se modele detalhes do negócio supérfluos à construção dos sistemas. Segundo Knight (2004) esta delimitação acaba contrariando a visão processual que privilegia a modelagem dos processos de negócios organizacionais com vistas a um entendimento integrado da forma de funcionamento da organização.
4.5. Considerações Finais
Nesse capítulo foram apresentados os principais conceitos afetos à Engenharia de
Software e sua subárea, a Engenharia de Requisitos que, por sua vez, contém a tarefa de
elicitação de requisitos – uma das mais críticas atividades do processo de desenvolvimento de software e foco do presente trabalho. Também foram abordados conceitos sobre o ciclo de vida de software e alguns de seus modelos com o objetivo de esclarecer que o processo de desenvolvimento de sistemas engloba muitas atividades, sendo a elicitação de requisitos, a primeira de todas e uma das mais difíceis por inúmeras razões.
Por fim, esse capítulo abordou conceitos sobre requisitos de sistema, seus tipos (funcionais e não funcionais) e seus níveis de abstração (requisitos de negócio, de usuário e de sistema).
Uma linguagem padronizada para representação dos requisitos de sistema também foi mostrada, a UML, tendo-se como destaque dois diagramas: casos de uso e de atividades. Esses diagramas, dada sua representatividade, têm sido empregados nas propostas de extensão da UML para a modelagem do negócio.
A revisão bibliográfica afeta aos temas da ES e ER torna-se importante para facilitar o entendimento do leitor sobre a “interseção” da EPN com a ER (processos de negócio e elicitação de requisitos de sistema), relacionando-se, assim, ao objeto de pesquisa (definição de requisitos de sistema orientada por processos de negócio). A explicação dos temas e conceitos da EPN, em conjunto com os temas da ES e, conseqüentemente da ER, compõem o arcabouço conceitual necessário ao entendimento dos dois próximos capítulos: apresentação e análise crítica, respectivamente, das abordagens que usam as informações dos processos de negócio na tarefa de elicitação dos requisitos de sistema.