Tags: , , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 25/02/2011 05:39 | Comentários (0)

Olá pessoal!

Hoje eu gostaria de compartilhar com vocês uma dúvida muito simples, porém interessante na minha opinião, que surgiu durante a confecção de um Diagrama de Use Case em UML 2.0. Eu uso o astah, um aplicatico muito bacana, e o que é melhor, free! O astah, assim como qualquer ferramenta de modelagem UML 2.0, possui dois tipos de Use Case: O Use Case de Sistema e o de Negócio, que são representados pelos seguintes objetos:

Pesquisei um pouco sobre e encontrei uma ótima definição:

"Use cases may be described at the abstract level (business use case, sometimes called essential use case), or at the system level (system use case). The differences between these is the scope.

  • A business use case is described in technology-free terminology which treats system as a black box and describes the business process that is used by its business actors (people or systems external to the process) to achieve their goals (e.g., manual payment processing, expense report approval, manage corporate real estate). The business use case will describe a process that provides value to the business actor, and it describes what the process does. Business Process Mapping is another method for this level of business description.
  • A system use case describes a system that automates a business use case or process. It is normally described at the system functionality level (for example, "create voucher") and specifies the function or the service that the system provides for the actor. The system use case details what the system will do in response to an actor's actions. For this reason it is recommended that system use case specification begin with a verb (e.g., create voucher, select payments, exclude payment, cancel voucher). An actor can be a human user or another system/subsystem interacting with the system being defined."

Fonte: http://en.wikipedia.org/wiki/Use_Case#Business_vs._System_Use_Cases

É uma dica muito simples, mas que eu achei interessante compartilhar com vocês.

Até a próxima!

Tags: , , , | Categories: Padrões de Projeto Posted by Rafael on 17/11/2010 00:30 | Comentários (1)

Pessoal, depois de um longo tempo impossibilitado de escrever, venho falar sobre o nosso primeiro dos cinco padrões de criação, o Abstract Factory, também conhecido como Kit.

A definição do padrão Abstract Factory, segundo o livro Padrões de Projeto - Soluções reutilizáveis de software orientado a objetos, escrito pelos integrantes da "Gang of Four" ou "GoF" é a seguinte: "Fornecer uma interface para a criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.". A definição é auto-explicativa. Utilizamos o padrão Abstract Factory quando queremos construir um conjunto de classes e fornecer apenas a interfaces de acessos às mesmas, não as implementações propriamente ditas, principalmente quando um sistema deve ser independente de como seus objetos são criados. Ou então, quando você precisar garantir que um conjunto de objetos deve ser utilizado em conjunto.

Existem diversas maneiras de implementarmos o padrão Abstract Factory. Demonstrarei apenas uma, bem simplificada, para facilitar o entendimento. A seguir está o diagrama de classes e o código gerado na linguagem C# pode ser baixado aqui: AbstractFactory.zip (30,20 kb)

Consideremos que queremos criar uma aplicação que instancia objetos de acordo com o ambiente onde esteja rodando (web, stand-alone ou mobile). Para facilitar o nosso exemplo, essa informação estará no App.config do aplicativo, mas poderia estar em qualquer outro lugar ou ser consumida de qualquer outra forma.

Note que, na classe Cliente, não sabemos qual é o atual ambiente no qual a aplicação está rodando, apenas solicitamos a criação de um TextBox e de um Botão, através da instância retornada pela Factory. Desta maneira, não nos preocupamos com o "como" os objetos são implementados, apenas nos preocupamos em seguir o contrato estabelecido pela interface, mantendo implementação dos objetos restrita.

Se definirmos o valor da chave ambiente no App.config como web, temos a seguinte saída na aplicação Console:

Da mesma maneira, se alterarmos o valor da chave ambiente do App.config para standalone, temos a seguinte saída:

Não diferente, alterando para mobile, temos o seguinte:

Esse é um dos padrões de projeto mais utilizados por arquitetos e desenvolvedores. Seu conhecimento é essencial para quem almeja dominar o mundo dos Padrões de Projeto. O padrão Abstract Factory pode ser combinado com outros padrões, como o padrão Singleton ou Prototype. Abordarei a integração entre esses padrões assim que tivermos uma visão de geral de cada padrão, para facilitar o entendimento.

Padrões de Projeto, como citei anteriormente, não são implementados de uma única maneira. No nosso exemplo, utilizei interfaces no código C#, o que achei mais apropriado, pois não havia implementação, apenas queria estabelecer um contrato entre partes (classes). Porém, nada me impediria de, ao invés de utilizar interfaces, utilizar classes abstratas. Ao invés das classes concretas implementarem as interfaces, elas poderiam herdar o comportamento das classes abstratas. Usualmente, utilizamos interfaces quando não temos implementações padrão, e utilizamos classes abstratas quando temos pelo menos uma implementação padrão, que deve ser herdada pelas classes concretas. Essa abordagem é arquitetural, e foge do nosso foco que é aprender sobre padrões de projeto. O que eu quero deixar claro é que, não importa "o como" implementamos o padrão, desde que a implementação respeite o princípio do padrão, propriamente dito.

No próximo post sobre Padrões de Projeto, abordaremos o padrão Adapter, um padrão estrutural, também muito utilizado, mas não tanto quanto o padrão Abstract Factory.

Espero que esse exemplo simples tenha ajudado vocês de alguma forma.

Até a próxima!

Tags: , , , | Categories: Engenharia de Requisitos, Metodologia Posted by Rafael on 17/10/2010 01:46 | Comentários (6)

Já ouvi diversas vezes as pessoas falarem: “Este é o Modelo de Casos de Uso do sistema XYZ”, ou então, “Este é o Diagrama de Casos de Uso do sistema XPTO”. Mas, afinal de contas, Modelos e Diagramas são a mesma coisa? Na verdade, Modelos e Diagramas não são a mesma coisa.

Quando dizemos que determinado documento é um Modelo, estamos dizendo que ele contém a definição de todo o sistema, ou seja, é um único documento que possui todas as informações de um sistema, relativas àquele artefato (Caso de Uso, Seqüência, Atividades, etc.). Por exemplo, um Modelo de Caso de Uso de um sistema, possui todos os casos de uso de um sistema.

Diagramas são perspectivas de um determinado Modelo. Criamos Diagramas para facilitar o entendimento (e conseqüentemente o desenvolvimento) de um sistema, ou seja, criamos perspectivas de um determinado modelo. Assim, quando dizemos que determinado documento é um Diagrama de Casos de Uso, sabemos que se trata de uma perspectiva do Modelo de Casos de Uso.

Por isso, sistemas possuem apenas um Modelo de Caso de Uso, e diversos Diagramas de Caso de Uso. O mesmo é verdadeiro para os demais artefatos.