UML – Unified Modeling Language

Este ano eu terei uma matéria chamada: “Engenharia de Software”. Nesta matéria terei a oportunidade de estudar UML e inspirado neste tópico, irei postar um pouco sobre UML. Espero que gostem :)

UML – Unified Modeling Language

UML é uma linguagem de modelagem e não uma metodologia de desenvolvimento.
A linguagem UML é usada para realizar especificação, documentação, vizualização e desenvolvimento de sistemas orientados a objetos.

A especificação da UML consiste de duas partes:

Semântica – especifica a sintaxe abstrata e a semântica dos conceitos de modelagem estática e dinâmica de objetos;
Notação – especifica a notação gráfica para a representação visual da semântica.

A UML suporta o desenvolvimento iterativo e incremental. Desenvolvimento iterativo e incremental é o processo de desenvolvimento de sistemas em pequenos passos. Uma iteração é um laço de desenvolvimento que resulta na liberação de um subconjunto de produtos que evolui até o produto final percorrendo as seguintes atividades:

• Análise de requisitos
• Análise
• Projeto
• Implementação
• Teste

UML, basicamente, possuí os seguintes elementos (importantes em orientação à objetos!):

Classe

Definição dos atributos e funções de um tipo de objeto; ela descreve um conjunto de objetos individuais em qualquer contexto. Ela é obtida pela classificação de objetos com a mesma estrutura de dados e o mesmo comportamento.

Atributos

São recursos de uma classe ou qualquer outro elemento que represente propriedades ou elementos de dados. Em algumas linguagens, os atributos são denominados variável de instância de classe ou membro de dado.

Uma variável de atributo pode ser:

• pública – o atributo é acessível por outras classes – a visibilidade pública é representada no modelo por “+”
• privada – o atributo é acessível somente pela própria classe – é representada no modelo por “-”
• protegida – o atributo é acessível somente pela classe e suas subclasses – é representada por “▬”
• de pacote – o atributo é acessível somente pelas classes de pacotes que a contém – é representada no modelo pelo til (~) e disponível em algumas linguagens, como Java.

Operações

Depois de modelados os objetos, as operações são recursos de uma classe que representam comportamentos ou serviços que ele suporta. Os métodos implementam as operações de uma determinada classe.

Herança

Herança serve para criar objetos que incorporem propriedades e métodos de outros objetos. Assim, poderemos construir uns objetos a partir de outros sem ter que reescrevê-lo todo.

Polimorfismo

Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura) mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da superclasse.

Análise de requisitos

Esta etapa se caracteriza pela definição do comportamento do sistema, ou seja, como o sistema age ou reage, descrevendo o relacionamento entre o ambiente e o sistema. Deve ser uma definição de necessidades do usuário e não uma proposta de solução. O usuário deve indicar os requisitos prioritários para o sistema.

O grupo de análise deve identificar as necessidades do usuário. Decisões do projeto impostas não são características essenciais do domínio do problema.

A análise de requisitos compõe-se dos seguintes diagramas:

• Diagrama de caso de uso;
• Diagrama de seqüência;
• Diagrama de colaboração;

Para realizar a análise de requisitos, primeiramente deve-se:

• Identificar objetivo e características do sistema;
• Identificar os requisitos essenciais;
• Descrever as necessidades do usuário;
• Elaborar diagrama de caso de uso;
• Elaborar diagrama de seqüência;
• Elaborar diagrama de colaboração

Isto é uma das características principais e importantes que se têm sobre UML.

Caso você queira saber mais, existem diversos livros por aí!
Um dos que mais gostei foi o “UML 2.0. Do Requisito à Solução”, Adilson da Silva Lima, Ed. Érica.

Caso queira saber um pouco mais sobre o que coloquei, clique neste link

Dicas de ferramentas de modelagem!

Enterprise Architect (Esta ferramenta é a melhor :D Ela gera até as classes para você, em qualquer linguagem!)

Jude Community

Alan Machado

Anúncios

Domanin-Driven Design

De alguns anos para cá, surgiu uma nova metodologia, esta chama DDD (Domain-Driven Design).
Esta metodologia é a metodologia do futuro de acordo com alguns analistas de sistemas que já utilizam da mesma.

DDD: Domain-Driven Design

DDD

O que é a metodologia DDD?

DDD é uma metodologia desenvolvida por Eric Evans. Trata-se de uma metodologia de desenvolvimento que prega que todo o material feito pela equipe durante o desenvolvimento de um software deve estar diretamente relacionado com a “linguagem” dita pelo cliente (sub entende-se que o cliente seja especialista na área ou ramo da qual o software será aplicado). Entre outras palavras, o DDD visa o desenvolvimento a partir de um domínio. O que deixa em destaque a complexidade no desenvolvimento de software.

Esta metodologia implica nas alterações de dados. Ao invés de receber entidades inteiras no novo estado para salvar, eles recebem objetos que representam as alterações de estado das entidades. Além disso, permitem salvamentos em ordem aleatória, permitindo que o sistema tenha seus dados ligeiramente inconsistentes em certos momentos, enquanto parte das alterações ainda não foram salvas. À grosso modo: O desenvolvedor programa em cima de camadas de abstração :)

Antes de mais nada, vamos definir o que é um Domínio!

Domínio é um conjunto de objetos que, de forma abstrata, descreve aspectos (problemas) de um determinado domínio complexo.

O DDD possuí alguns enfoques interessantes, como por exemplo:
– Focalizar no modelo: Elaborar uma representação abstrata do domínio que nos ajude em cumprir o propósito;
– Linguagens onipresente: Os programadores partilham de uma linguagem comum;
– É Orientado à Objeto e combina com outras metodologias ágeis, como TDD, BDD

Um dos itens que pesquisei sobre o DDD, é o chamado “linguagem comum”. Vamos abordar mais sobre logo a baixo:

Linguagens Comuns
As vezes quando eu estou conversando com algum amigo sobre programação ou patterns e minha esposa está por perto ela fica muito perdida e diz que não consegue compreender nada do que estamos falando. O fato é que nós desenvolvedores possuímos uma linguagem muito específica que somente outro integrante de nossa “tribo” consegue compreender bem. Da mesma forma um profissional da área de risco financeiro por exemplo (falo isso por experiência própria) consegue falar um dialeto que pode ser completamente incompreensível para a maioria de nós desenvolvedores. Tente imaginar o que acontece quando estes especialistas do ramos de análise de risco financeiro contratam nós desenvolvedores para desenvolver um software? Em muitas situações como esta (e eu já tive a oportunidade de viver algumas) o software acaba não tendo sucesso por falta de uma comunicação clara entre os desenvolvedores e o cliente.
O DDD tenta acabar com este problema de comunicação diminuindo a dissonância entre o que é falado pelo time de desenvolvimento e pelo time de especialistas e para isso apresenta varias técnicas interessantes.
O design de um software (forma com que o mesmo é arquitetado) é aperfeiçoado a medida que o entendimento sobre o domínio aumenta. A cada refatoração o nosso design passa a expressar mais o domínio. Para isso tentamos fazer com que o modelo seja a linguagem falada pelo time de desenvolvedores de especialistas.
Diullei Gomes

Isto é uma das poucas coisas que li até agora sobre DDD.
A medida que vou lendo mais e mais, fico de postar no blog :)

Para quem quiser saber mais sobre DDD, só clicar neste link.

Agradecimentos à Diullei Gomes e ao fórum .NET Ponto

Alan Machado