UML: seus diagrams e suas abstrações parte II

Saudações terráqueos!

Vimos no post anterior um pouco sobre UML algumas definições e uma breve introdução a diagramas do tipo Caso de Uso.

Hoje vamos analisar a estrutura estática de nosso sistema, e para tal vamos utilizar o diagrama de Classe. Estão prontos? Claro que estão =P então, prontos ou não aí vamos nós!!!

Diagrama de Classe

Um diagrama do tipo Classe captura a estrutura do sistema, suas classes, seus atributos e o relacionamento entre elas. De uma forma bem rústica, poderíamos dizer que classes são os tijolinhos que montam nosso sistema.

Quando usar

Após ter abstraido o comportamento do sistema com os diagramas de Caso de Uso, é hora de reduzir a abstração e modelar as entidades (classes) que compõe o sistema.

Geralmente você realiza esta modelagem analisando a declaração de cada Caso de Uso e idêntificando substântivos como potênciais classes. É aqui que vai entrar sua capacidade de abstração e classificação! Da informação coletada em cada Caso de Uso você vai tomar nota de todos os substântivos sejam eles concretos (como uma pessoa por exemplo) ou abstrato (um anuncio ou conta bancária).

Elementos

Os elementos que encontramos em diagramas de Classe são:

Classe: É uma entidade formada por atributos (suas característcas) e métodos (seu comportamento) podendo representar tanto "coisas" abstratas ou concretas, e quando agrupadas com outras classes formam a estrutura estática do sistema.

Relacionamento: Um aspecto importânte de um Objeto é justamente a interação que este têm com os demais (objetos) do sistema, sua "missão". Abaixo uma breve descrição dos principais relacionamentos entre os objetos (nota: farei um post especialmente sobre Relacionamentos em breve):

Associação: Pode ocorrer entre dois objetos (binária) ou três objetos (ternária)

Composição: Também conhecido como "contém um" define um relacionamento "forte" entre os dois objetos. Imagine um Carro, sabemos que ele é composto por, motor, rodas, portas... certo? É exatamente assim que podemos definir uma Composição, uma Classe é parte de outra, que pode ser composta por uma ou mais classes. Quando a Classe container é destruída, a outra Classe que a compõe é também destruída... (bem que poderiam chamar de relacionamento Romeu e Julieta...).

Agregação: Ao contrário de Composição, Agregação não define um tipo de relacionamento "forte" (ou de dependencia) ou seja, um objeto pode existir mesmo que o Objeto container seja destruído.

Generalização: Ahhh Herança... que relacionamento mais pratico! Aqui a sub parte (Juridica e Fisica) também é parte da super parte (Anunciante). As sub partes possuem todas as definições (características e comportamentos) da super parte, como no exemplo que usamos para montar nosso site de Anuncios.

Cardinalidade: Definem quantas instâncias (ou referências) de A podem aparecer em B.

0..1: Podemos encontrar nenhuma ou no máximo uma referência (também conhecido como relacionamento opcional)
1: Mínimo um, máximo um
0..* ou apenas *: Nenhum ou muitos
1..*: Mínimo um, máximo muitos
1..3,6,9..*: Defini um intervalo conhecido (nota: raramente vi este tipo de relacionamento ser usado)

Conclusão

É isso ae, já temos o básico para podermos entrar em maiores detalhes nos próximos exemplos. Espero que tenham gostado deste post, e não se sintam tímidos! Enviem seus comentários para que juntos possamos melhorar este blog e quem sabe mudar o mundo!!! =D ... hmm apenas postem ^^

Até o próximo post!!!

UML: seus diagrams e suas abstrações parte I

Definição

A UML é uma linguagem de modelagem criada por um esforço conjunto de diversos profissionais a fim de se desenvolver um modelo padronizado para modelagem de sistemas orientados a objetos. A UML possui 14 diagramas, e estes estão classificados de acordo com o tipo de "visão" (ora estático ou dinâmico) do modelo do sistema. Para Maiores detalhes vejam a imagem abaixo.


Imagem retirada de Wikipedia.
















Não precisamos decorar todos os diagramas, então iremos focar nos que vão nos ajudar a modelar sistemas menos complexos. Apertem os cintos que nossa viagem esta apenas começando!

Caso de Uso: Abstraindo os requisitos do sistema

Diagramas de Caso de Uso descrevem o comportamento do Sistema, ele descreve O QUE o Sistema vai fazer e QUEM vai usa-lo não COMO, isto faz com que este diagrama possua um alto grau de abstração. Diagramas de Casos de Uso o mantém focado nos objetivos do seu cliente e não em detalhes de implementação.

Quando usar

É muito comum usarmos este diagrama em reuniões iniciais com as partes envolvidas no sistema (stakeholders) pois os diagramas de Caso de Uso são fáceis de se entender, possibilitando que você consiga identificar as necessidades do cliente ou demais stakeholders de forma simples e objetiva (quando bem usados é claro).

Elementos

Os principais elementos que encontramos em diagramas de Caso de Uso são:

Ator: Pode ser uma pessoa (gerente, atendente, você...), uma entidade (empresa, organização...) até um sistema (uma impressora, web service...) que têm um papel bem definido no sistema, e que também pode estar envolvido em um mais Casos de Uso.

Ator

Caso de Uso: Um Caso de Uso descreve um cenário onde ações são realizadas. Então, temos por definição que um Caso de Uso descreve uma parte do comportamento do sistema, e um monte deles o comportamente geral deste sistema. Ah e não se esqueçam, Casos de Uso podem se associar com outros Casos de Uso.

Caso de Uso

Associações: Descrevem o relacionamento entre Atores e Casos de Uso, ou Atores e Atores e entre Casos de Usos. Para não estender muito o post de hoje, vamos ver apenas os relacionamentos <<extends>> e <<Include>>.

• Extends: A grosso modo este relacionamento cria uma dependência entre o Caso de Uso base e o Caso de Uso que deriva dele. Isto permite que o Caso de Uso que deriva (extends) possa continuar as atividades do Caso de Uso base.
• Includes: Ao contrário do <<extends>> um relacionamento do tipo <<include>> simplesmente pode ser entendido como 'opcional' ou seja, se um Caso de Uso precisar usar o comportamento de outro Caso de Uso ele simplesmente o invoca! Basicamente uma chamada de função.

Limite do Sistema: Como o nome já diz, tudo que estiver dentro deste limite descreve o sistema em si. Lembre-se, Atores não são representados aqui, apenas Casos de Uso!

Limite/Fronteira do Sistema

Exemplo

Este exemplo é bem simples mesmo, afinal ainda estamos assimilando o conteúdo novo certo? Notem a imagem abaixo, temos um Ator, Anunciante, alguns Casos de Uso, relacionamentos e um Ator abstrato, Web Service.

Exemplo de Caso de Uso bem simples



















Aqui o Sistema permite ao Anunciante a Realizar Login e Cadastrar um novo Anuncio. Vejam os relacionamentos, o Caso de Uso Realizar Login têm dependência com Autenticar Usuário! Realizar Login só poderá concluir seu comportamento somente após Autenticar Usuário ter terminado o seu (comportamento).

Já com Cadastrar Anuncio, temos um relacionamento do tipo <<extends>> com um Web Service. Digamos que para este exemplo um Anuncio poderia ter um endereço que não o do Anunciante fazendo com que tivéssemos que acionar (invocar) um serviço de um Web Service (imagine solicitar um CEP para os Correios) desta forma, como poderíamos optar por ou usar o endereço do Anunciante, ou solicitar isto para outro Ator (Web Service).

Conclusão

Bom pessoal, espero que tenham gostado deste post, não está extraordinário mas se tiver ajudado alguém já valeu o esforço =)

Então nos vemos no próximo post? Okie dokie!

Polo Guarulhos / EXATAS: Tabela Verdade sem mistérios

Polo Guarulhos / EXATAS: Tabela Verdade sem mistérios: "Saudações Terráqueos! Neste meu primeiro post vou abordar a tabela verdade com algumas dicas simples, mas que irão facilitar e muito a reso..."

Vocabulário Básico OO

Saudações novamente terráqueos!

Como prometido no post anterior, vamos falar sobre o básico/necessário para montarmos um projeto orientado a objetos.

Antes de entrarmos nos diagramas (até a versão 2.x eram 14) UML vamos aprender as técnicas básicas de OO (Orientação a Objeto).

As cinco principais características do paradigma OO

Objeto/Classe

Um Objeto é uma entidade, ou algo que têm um comportamento (métodos) e atributos (variáveis) definidos por uma Classe. Ou seja, uma Classe define Objetos.

Encapsulamento/Information Hiding

É a capacidade de um Objeto de ocultar seus componentes (comportamentos e/ou atributos) para outros Objetos. Em outras palavras, um Objeto define o que pode ser "visto" pelos demais Objetos que interagem com ele.

Herança

Um dos conceitos mais poderosos de OO é certamente o da Herança. Este mecanismo permite a você criar Classes Base (também Super Classe, Classe Pai e/ou Root) a fim de definir um Objeto genérico para que Sub Classes (também Classe Filha, Classe Derivada e/ou Leaf) possam implementar suas definições ou até mesmo extende-las (overriding).

Lembro que certa vez em um projeto para um site de anuncios tinhamos modelado duas entidades, Pessoa Jurídica e Pessoa Física. Ambos tinham determinados atributos e comportamentos que eram iguais como endereço, indicador de ativação (ativo/inativo) e telefone. Tanto Pessoa Jurídica e Física são Anunciantes! Desta forma Definimos uma Classe Base, Anunciante, para que as demais Classes (Física e Jurídica) pudéssem herdar os atributos acima e adicionar os que eram importântes para suas definições. Okie Dokie!

Polimorfismo

Outro poderoso mecanismo que separa os faixas pretas dos marrons em OO. Com Polimorfismo uma mesma ação (método) pode se comportar de formas diferentes dependendo de quem o implementa.

Pense no seguinte exemplo, temos três profissionais: Um Cabeleireiro, um Cirurgião e um Diretor de cinema.

Se você falar para o Cabeleireiro a ação "corta!", ele entenderia que você quer que ele corte seu cabelo, afinal ele é um Cabeleireiro!

Agora tente dizer a mesma coisa para o Cirurgião, "corta!". O Cirurgião entenderia que ele deve fazer uma incisão! Já para o Diretor se você dizer "corta!", ele entenderá que deverá parar as filmagens do filme, entendeu? A mesma ação executada de formas diferentes!

Interface

Como você definiria o comportamento de um mamífero? Hmmm eles se locomovem, comem, bebem... certo? Porém, nós nos locomovemos sob dois membros enquanto que uma vaca sob quatro, nós (ou pelo menos alguns de nós...) utilizamos nossas mãos para levar o alimento a nossa boca, já as vacas se alimentam diretamente no pasto, sem a necessidade de utilizar suas patas e etc... O ponto é, ambos se: Locomovem, Comem e Bebem. É isto que uma Interface representa, ela diz o comportamento de algo (mamífero no nosso exemplo) mas cabe a cada Objeto (Homem e Vaca) definir como eles implementam seus comportamentos.

É isto ae galera, no próximo post vamos entrar em detalhes no universo UML.

Até mais!

Abstração: A essência da modelagem

Saudações terráqueos!

Neste meu primeiro post aqui no Dr-Objeto vamos falar sobre abstração. A abstração em OO (Orientação a Objeto) é a capacidade de se identificar (ou reduzir, fatorizar...) o que é importânte para seu modelo.
Não existe um modelo ideal para um dado problema, o que existe são diferentes abordagens (abstrações). O sucesso (ou não! conviva com isso...) da implementação do seu projeto se deverá a sua capacidade de identificar o que é importânte.
Existem diferentes niveis de abstração, por exemplo como você descreveria um carro? Para alguns um carro é algo que têm quatro rodas, duas portas e quebra sempre, certo? Se fizéssemos a mesma pergunta para um engenheiro, provavelmente sua abstração seria (bem mais) técnica como circuitos elétricos, mecânismos de tração entre outras coisas... notou?
A UML (Unified Modelling Language) possui diversos diagramas que serão muito ùteis na hora de descrever nossos modelos e lembre-se, cada diagrama representa um nivel de abstração e quando usado no contexto certo lhe proporcionaram implementações menos problemáticas (menos por que sempre descobrimos algo novo a cada refinamento, mas isto é normal).
Estou tentando convencer Jacquie Baker (objectstart.com) para uma breve entrevista no Dr-Objeto sobre o tema dentre outras coisas do universo OO.
Por hoje é só, primeiro post nada tão exepcional =P
Na próxima, UML 2.0.