ANÁLISE E PROJETO DE SISTEMAS

Apresentação em tema: "ANÁLISE E PROJETO DE SISTEMAS"— Transcrição da apresentação:

1 ANÁLISE E PROJETO DE SISTEMAS
DIAGRAMA DE PACOTES ANÁLISE E PROJETO DE SISTEMAS

2 Pacotes A idéia de um pacote pode ser aplicada a qualquer elemento do modelo, não somente a classes. Usamos o termo diagrama de pacotes para um diagrama que mostra pacotes de classes e as dependências entre eles. De modo restrito, um diagrama de pacotes é simplesmente um diagrama de classes que mostra apenas pacotes e dependências.

3 PACOTES Existe dependência entre dois elementos se mudanças na definição de um elemento possam causar mudanças ao outro. Nas classes, as dependências existem por várias razões: uma classe manda uma mensagem para outra; uma classe tem outra como parte de seus dados; uma classe menciona uma outra como um parâmetro para uma operação. Se uma classe muda a sua interface, qualquer mensagem que ela mande pode não ser mais válida.

4 PACOTES Há dependência entre dois pacotes se houver qualquer dependência entre quaisquer duas classes nos pacotes. Por exemplo, veja que o pacote “Gerenciador de Conexões com Banco de Dados” é um pacote muito utilizado pelos demais, todos os outros pacotes dependem dele. Desta forma uma alteração em classes deste pacote deve ser feito com muito cuidado pois pode prejudicar as classes nos demais pacotes.

5 PACOTES Imagine o exemplo onde temos um pacote com classes para conectar com o banco de dados, todas as classes que estavam naquele pacote eram abstratas e nós precisamos especializar as mesmas e criar classes para fazer aquilo que nós de fato queremos fazer: conectar com oracle, postgreSQl, etc. Veja como ficaria graficamente:

6

7 Colaborações Além de conter classes, um pacote pode conter colaborações. Uma colaboração é um nome dado à interação entre duas ou mais classes. Tipicamente, isso é uma interação, como descrito no diagrama de interação.

8 Colaborações Como você pode estar notando a UML é um conjunto de diagramas que deve ser escolhido de acordo com a situação que você deseja documentar ou passar a informação

9 Dicas Os pacotes são ferramentas vitais para projetos grandes. Utilize pacotes sempre que um diagrama de classes que compreenda todo o sistema não for mais legível numa única folha de papel tamanho A4.

10 Multiplicidade Indica uma faixa de cardinalidade permitida a um elemento, isto é, a quantidade de instâncias possíveis em um relacionamento. Por exemplo: Numa classe Pessoa com o atributo cônjuge podemos afirmar (na nossa atual legislação) que sua multiplicidade é de no mínimo zero e no máximo um cônjuge (levando em conta o cônjuge atual).

11 Multiplicaidade Considerando uma classe Curso que se relacione com uma classe Aluno, podemos afirmar que para cada instância de Curso há um relacionamento com no mínimo zero e no máximo vários alunos; e para cada instância de Aluno há um relacionamento com no mínimo zero (aluno está com a matrícula trancada) e no máximo vários cursos.

12 limite-inferior.. limite-superior
Se a multiplicidade contiver um asterisco (*), significa que temos uma faixa infinita de números inteiros não-negativos. É equivalente a 0..* (zero ou mais). As multiplicidades mais comuns são: • 0..1 (valor opcional) • 1 ou 1..1 (exatamente um) • * ou 0..* (qualquer valor inteiro não-negativo) • 1..* (qualquer valor inteiro positivo)

13 Exemplos de multiplicidades: "1", ". ", "0. 1", "1. ", "1. 5", "3, 5
Exemplos de multiplicidades: "1", "*", "0..1", "1..*", "1..5", "3, 5..7, “ Algumas normas de estilo devem ser usadas para multiplicidade, como: os intervalos devem ser mostrados em ordem crescente. Exemplo: Adequado: 2..5, 8, Inadequado: , 2..5, 8

14

15 Escopo Vamos supor o objeto Funcionário com o atributo salário. Agora vejamos a seguinte situação: na empresa Unilagos, instanciamos dois objetos a partir de uma classe Funcionário identificando-os como objetoP e objetoA, os quais representarão os funcionários Alex e Alexandre, respectivamente. Alex recebe 500,00 de salário enquanto que Alexandre recebe 2000,00. Se quisermos saber os salários desses funcionários, podemos nos referenciar da seguinte forma:

16 Escopo objetoP.salario e objetoA.salario Veja que dependemos da individualidade do objeto para obtermos os salários corretos. Estamos diante do conceito de escopo de instância, que também pode ocorrer com as operações. Vamos levar em conta a operação gerarContraCheque. O resultado dessa operação será diferente para as seguintes chamadas:

17 Escopo objetoP. gerarContraCheque() e objetoA.gerarContraCheque() A diferença será dada em função dos objetos terem salários diferentes, um possui 500,00 e o outro 2000,00. O contra-cheque gerado na primeira chamada apresentará os dados funcionais do funcionário Alex, incluindo a demonstração de seus proventos e descontos. Já na segunda chamada, o contra-cheque apresentará os dados funcionais e demonstração de proventos e descontos do funcionário Alexandre.

18 Escopo Vamos agora citar um outro exemplo com uma operação chamada emitirFolhaPagamento. O resultado dessa operação é a folha de pagamento mensal contendo todos os funcionários. Desta forma não importa chamá-la a partir de um único funcionário, pois seu processamento será sempre sobre o conjunto de funcionários, independente de quem ou quantos sejam. Funcionario.emitirFolhaPagamento()

19 A UML determina que o escopo de classe seja representado sublinhando-se o elemento.

20 Associação Xor (ou exclusiva)
Uma restrição Xor (ou exclusiva) indica que, dentre as várias associações envolvidas nessa restrição, somente uma delas pode ocorrer por vez. Por exemplo: suponha a classe Contrato que se relacione com a Classe Contratante. Podemos ter um contratante do tipo Pessoa Física, assim como um contratante do tipo Pessoa Jurídica, gerando duas associações:

21 Associação Xor (ou exclusiva)
Classe Contrato com a classe Pessoa Física Classe Contrato com a classe Pessoa Jurídica Entretanto, não podemos permitir que ambas as associações ocorram ao mesmo tempo. Não seria possível num mesmo contrato termos um contratante que fosse ao mesmo tempo Pessoas Física e Jurídica.

22

23 Notas É um símbolo gráfico contendo informação textual. É utilizado para especificar vários tipos de informações sobre os modelos, como: restrições, comentários, corpos de métodos e valores de etiquetas.

24 Objetos de Referência e Objetos de Valor
São coisas como Clientes, geralmente as classes das linguagens. Aqui, a identidade é muito importante, porque você geralmente quer que somente um objeto de software designe um cliente no mundo real. Um objeto que faz referência a um objeto- Cliente fará isso através de uma referência ou ponteiro; todos os objetos que se referem a este Cliente vão se referir ao mesmo objeto de software. Desta forma, modificações em um Cliente ficam disponíveis para todos os usuários do Cliente.

25 Objetos de Referência e Objetos de Valor
Se você tem duas referências para um Cliente e quer ver se são as mesmas, você, normalmente, compara suas identidades. Cópias podem ser proibidas; se são permitidas, elas tendem a ser feitas raramente, talvez para propósitos de arquivamento ou para replicação na rede. Se cópias forem feitas, você necessita decidir como sincronizar as atualizações do objeto.

26 Objetos de Referência e Objetos de Valor
Objeto de Valor São coisas como datas, ou tipos primitivos das linguagens. Você tem, geralmente, múltiplos objetos de valor representando o mesmo objeto do mundo real. Por exemplo, é normal ter centenas de objetos que designam 01-Jul Estas são todas cópias intercambiáveis. Novas datas são freqüentemente criadas e destruídas.

27 Objetos de Referência e Objetos de Valor
Objeto de Valor Se você tem duas datas e quer ver se elas são a mesma, você não examina as suas identidades, mas sim os valores que elas armazenam. Isso significa, geralmente, que você tem que escrever um operador de teste de igualdade, que para datas fará testes no ano, mês e dia (ou qualquer outra forma de representação interna). Normalmente, cada objeto que faz referência a 01-Jul tem o seu próprio objeto data dedicado a isso, mas você também pode compartilhar datas.

28 Objetos de Referência e Objetos de Valor
Objeto de Valor Objetos de valor devem ser imutáveis. Em outras palavras, você não deve ser capaz de pegar um objeto data de 01-Jul-9999 e mudá-lo para ser 31-Jul Em vez disso, você deve criar um novo objeto 31-Jul-9999 e ligá-lo ao primeiro objeto. A razão é que se a data fosse compartilhada, você atualizaria a data de outro objeto de um modo imprevisível.

29 Objetos de Referência e Objetos de Valor
Objeto de Valor A distinção entre objetos de valor e de referência seja útil para modelos conceituais. Isso pode causar confusão com multiplicidades. Se representar uma ligação para um objeto de valor com uma associação, normalmente marcamos a multiplicidade da ponta do usuário de um dado valor como "*", a não ser que exista uma regra de unicidade, tal como um número de seqüência.

30 Visibilidade A visibilidade é um daqueles assuntos que é simples em princípio, mas tem complexas sutilezas. A idéia básica é que qualquer classe tem elementos públicos e elementos particulares. Os elementos públicos podem ser usados por qualquer outra classe; os elementos particulares podem ser usados somente pela classe proprietária. Entretanto, cada linguagem tem suas próprias regras. Embora muitas linguagens usem termos como public ("público"), private ("particular") e protected ("protegido"), eles têm significados diferentes em linguagens diferentes.

31 Visibilidade UML tenta abordar o tema sem entrar em terrível confusão. Essencialmente, dentro de UML, você pode rotular qualquer atributo ou operação com um indicador de visibilidade. Você pode usar qualquer marcador que quiser, e seu significado é dependente da linguagem. Entretanto, UML fornece quatro abreviações para visibilidade; + (público), - (privado), # (protegido) e ~ (pacote)

32 Visibilidade Considere uma classe Cliente que tem uma subclasse Cliente Pessoa-Física. Considere também o objeto Martin, que é uma instância de Cliente Pessoa-Física. Martin pode usar qualquer membro público de qualquer objeto no sistema. Martin também pode usar qualquer membro particular da classe Cliente Pessoa-Física. Martin não pode usar membros particulares definidos dentro de Clientes; pode, entretanto, usar membros protegidos de Cliente e membros protegidos de Cliente Pessoa-Física.

33 Visibilidade As visibilidades geralmente mudam quando você começa a trabalhar com código. Então, não fique amarrado a elas no início do projeto. Veja abaixo uma classe com a visibilidade para seus atributos:

34 Dicas Diagramas de classes são a base de quase todas as metodologias OO, portanto você irá utilizá-los o tempo todo. O problema com diagramas de classes é que eles são muito ricos e podem ser complexos de se usar. Você tem aqui algumas dicas. Não tente utilizar todas as notações que você dispõe. Comece com os recursos mais simples: classes, associações, atributos, generalização e restrições.

35 Dicas Ajuste a perspectiva na qual você está desenhando os modelos para o estágio do projeto, Não desenhe modelos para tudo; em vez disso, concentre-se nas áreas principais. É melhor ter poucos diagramas que você usa e mantém atualizados do que ter muitos modelos esquecidos e obsoletos. O maior perigo com diagrama de classes é que você pode ficar detido em detalhes de implementação muito facilmente. Para combater isso, concentre-se nas perspectivas conceituais e de especificação.