A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

UML UML (Unified Modeling Language ou Linguagem de modelagem unificada) Linguagem padrão para modelagem orientada a objetos. Permite visualização do.

Apresentações semelhantes


Apresentação em tema: "UML UML (Unified Modeling Language ou Linguagem de modelagem unificada) Linguagem padrão para modelagem orientada a objetos. Permite visualização do."— Transcrição da apresentação:

1

2

3 UML UML (Unified Modeling Language ou Linguagem de modelagem unificada) Linguagem padrão para modelagem orientada a objetos. Permite visualização do trabalho do desenvolvedor através de Diagramas Uma linguagem comum e amplamente utilizável Utiliza-se de um conjunto de técnicas de notação gráfica para criar modelos visuais de software de sistemas intensivos

4 DIAGRAMA DE CASOS DE USO Tem o Objetivo de auxiliar a comunicação entre o cliente e os analistas Descreve um cenário que mostra as funcionalidade do sistema do ponto de vista do usuário Deve conter para o cliente ver as principais funciona- lidades de seu sistema. Representa o conjunto de comportamentos de alto nível que o sistema deve executar para um determinado ator É o diagrama mais simples, e não há necessidade de grandes detalhamentos.

5

6 DIAGRAMA DE CLASSES Representa uma coleção de classes e seus inter- relacionamentos pode oferecer três perspectivas, cada uma para um tipo de observador diferente: - Conceitual: Representa os conceitos do domínio em estudo e perspectiva destinada ao cliente - Especificação: Foco nas principais interfaces da arquitetura e não como eles irão ser implementados - Implementação: A mais utilizada de todas, Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc.

7

8 DIAGRAMA DE PACOTES Descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos mostrando as dependências entre estes Muito utilizado para ilustrar a arquitetura de um sistema mostrando o agrupamento de suas classes Um pacote representa um grupo de classes (ou outros elementos) que se relaciona com outros pacotes através de uma relação de dependência Pode ser utilizado em qualquer fase do processo de modelagem e visa organizar os modelos

9

10 DIAGRAMA DE INTERAÇÃO São modelos que descrevem como grupos de objetos colaboram em algum comportamento. Tipicamente, um diagrama de interação captura o comportamento de um único caso de uso. O diagrama mostra vários objetos e as mensagens que são passadas entre estes objetos em um caso de uso. Existem dois tipos de diagramas de interação: Diagramas de sequencia e diagramas de colaboração.

11 DIAGRAMAS DE SEQUÊNCIA Tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação Linhas verticais representando o tempo de vida de um objeto (lifeline) Estas linhas verticais são preenchidas por barras verticais que indicam exatamente quando um objeto passou a existir. Quando um objeto desaparece, existe um "X" na parte inferior da barra Linhas horizontais ou diagonais representando mensagens trocadas entre objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma Uma condição é representada por uma mensagem cujo rótulo é envolvido por colchetes; Mensagens de retorno são representadas por linhas horizontais tracejadas. Este tipo de mensagem só deve ser mostrada quando for fundamental para a clareza do diagrama.

12

13 DIAGRAMA DE COLABORAÇÃO A grande diferença entre um diagrama de colaboração e um de sequencia consiste no fato de que o tempo não é mais representado por linhas verticais, mas sim através de uma numeração, que pode ser de duas formas: Simples (1,2,3,...) e Composta (1.1, 1.2, 1.2.1,...) Um objeto é representado como um retângulo, contendo no seu interior um rótulo, que informa o nome do objeto e o nome da classe, separados por dois pontos. A troca de mensagens entre os objetos segue o mesmo padrão que o apresentado nos diagramas de sequencia.

14

15 DIAGRAMA DE ESTADO Em um diagrama de estado, um objeto possui um comportamento e um estado O estado de um objeto depende da atividade na qual ele está processando Um diagrama de estado mostra os possíveis estados de um objeto e as transações responsáveis pelas suas mudanças de estado.

16

17 DIAGRAMA DE ATIVIDADES É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra e serão empregados para fazer a modelagem de aspectos dinâmicos do sistema Enquanto os diagramas de sequencia dão ênfase ao fluxo de controle de um objeto para outro, os diagramas de atividades dão ênfase ao fluxo de controle de uma atividade para outra; Uma atividade é uma execução não atômica em andamento em uma máquina de estados e acabam resultando em alguma ação, formada pelas computações atômicas executáveis que resultam em uma mudança de estado do sistema ou o retorno de um valor.

18

19 DIAGRAMA DE OBJETOS Uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes É como se fosse o perfil do sistema em certo momento de sua execução Os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas são muito úteis para exemplificar diagramas complexos de classes ajudando muito em sua compreensão Também são usados como parte dos diagramas de colaboração onde a colaboração dinâmica entre os objetos do sistema são mostrados.

20

21 DIAGRAMA DE COMUNICAÇÃO Era conhecido como Diagrama de Colaboração até a versão 1.5 da UML, o seu nome modificado na versão 2.0 Amplamente associado ao Diagrama de Sequencia, na verdade, um complementa o outro As informações mostradas são, com frequência, praticamente as mesmas apresentadas no Diagrama de Sequencia, porém com um enfoque diferente, visto que este diagrama não se preocupa com a linha de tempo do processo, concentrando-se em como os objetos são vinculados e quais mensagens trocam entre si durante o processo.

22

23 DIAGRAMA DE COMPONENTES Mostra o sistema por um lado funcional, expondo as relações entre seus componentes e a organização de seus módulos Descreve os componentes e as dependências, representando a estrutura do código gerado Os componentes também podem ser uma tabela, documentos, outros sistemas. Todo este conjunto irá compor o sistema Um componente é representado como um retângulo e dois pequenos retângulos do lado esquerdo e o nome do componente pode ser escrito dentro ou abaixo do componente. Os componentes podem ser implementados por meios diferentes de arquivos, linguagens de programação, tabelas, equipamentos. Para determinar o tipo do componente usamos estereótipos.

24

25 DIAGRAMA DE IMPLANTAÇÃO Representa a configuração e a arquitetura do sistema em que estarão ligados os respectivos componentes. Também podemos representar toda a estrutura de hardware e requisitos mínimos onde o sistema será executado. Principais características são: - Pode representar a estrutura da plataforma em que será utilizado; - Pode representar bancos de dados, Componentes de Terceiros; - Pode representar os servidores, a rede; - Pode representar a configuração dos equipamentos; Não é específico do desenvolvedor, mas em uma equipe onde existe o responsável pela implantação do sistema, este deve estar preocupado com o hardware e a configuração em que o sistema deverá ser executado e a compatibilidade entre os dois.

26

27 DIAGRAMA DE ESTRUTURA COMPOSTA É utilizado para modelar Colaborações Colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma operação específica Este diagrama também pode ser utilizado para definir a estrutura interna de um classificador Este é um dos novos diagramas propostos pela UML 2.0

28

29 DIAGRAMA DE TEMPO OU TEMPORIZAÇÃO Este diagrama descreve a mudança no estado ou condição de uma instância de uma classe ou seu papel durante um tempo Tipicamente utilizado para demonstrar a mudança no estado de um objeto no tempo em resposta a eventos externos.

30

31 FERRAMENTAS CASE NA UML O termo CASE (Computer-aided software engineering) significa engenharia de software auxiliada por computador. Ferramenta CASE é um software que auxilia no ciclo de desenvolvimento de um sistema, desde a fase de análise, fase de testes, desenvolvimento e apoiam na manutenção de metodologias Armazenam as informações de uma forma própria, como textos, imagens, gráficos, possibilitando a integração com o usuário.

32 FERRAMENTAS CASE NA UML As ferramentas CASE dividem-se em 3 tipos: Integrated System CASE (I-CASE), que visam desde a análise até a geração do código. Cases de automação de uma fase ou mais do desenvolvimento. São ferramentas que se prendem a uma etapa do projeto, como por exemplo Ferramentas para modelagem de dados., Ferramenta de testes. Ferramentas que seguem uma metodologia específica, como por exemplo ferramentas para Scrum, XP.

33 Algumas vantagens que podemos ver no uso de ferramentas CASE são: Maior qualidade nos produtos finais; Produtividade; Eliminação de retrabalho; Mais tempo para a tomada de decisão; Flexibilidade para mudanças; Melhor documentação; Manutenção mais fácil e ágil; FERRAMENTAS CASE NA UML

34 ANÁLISE OO: MODELAGEM ESTÁTICA São etapas sequencias de passos bem definidos que auxiliam a especificação do modelo de analise de sistema de software a partir dos requisitos estabelecidos Esses requisitos são especificados através dos casos de uso Apesar das ideias apresentadas serem genéricas o suficiente para possibilitar a sua utilização conjunta com outros artefatos de descrição de requisitos

35 ANÁLISE OO X PROJETO OO Uma das partes mais importantes de um processo de desenvolvimento de software é o conjunto de diretrizes que sugere como decompor sistemas grandes e complexos em componentes menores que possam ser manipulados mais facilmente. A aplicação de conceitos de orientação a objetos para o desenvolvimento de software traz novas soluções para velhos problemas, mas também demanda a confecção de novos métodos e processos que adotem uma abordagem completamente nova. Sendo assim, um processo de desenvolvimento de software orientado a objetos difere dos processos tradicionais na maneira particular como decompõe o sistema em partes menores e na natureza dos relacionamentos entre essas partes.

36 Além disso, numa abordagem clássica, as fases de análise, projeto, implementação e testes são geralmente vistas como fases globais e separados a serem executados sequencialmente no ciclo de vida do sistema inteiro. Na abordagem orientada a objetos, essa ideia não se aplica. A sequencia de fases de análise, projeto, implementação e testes pode ser adotada para o ciclo de vida de classes individuais, e não necessariamente para o sistema inteiro como na abordagem clássica. existe uma distinção comum feita entre análise orientada a objetos e projeto orientado a objetos. Em geral, a fase de análise lida com o domínio do problema, enquanto que a fase de projeto lida com o domínio da solução. ANÁLISE OO X PROJETO OO

37 DESCRIÇÃO DOS TERMOS Análise OO. Modela o mundo real de tal modo que ele possa ser compreendido. Durante a análise, a ênfase está em encontrar e descrever as entidades do domínio do problema que sejam relevantes para o sistema que se pretende construir. Projeto OO. Define as entidades de software que fazem parte do domínio da solução e que serão implementa- das em uma linguagem de programação orientada a objetos. ANÁLISE OO X PROJETO OO

38 O modelo de análise é uma abstração do modelo de projeto. Graças á sua abstração, o modelo de análise omite vários detalhes de como o sistema funciona e proporciona um panorama geral da funcionalidade do sistema. Por ser um refinamento do modelo de análise, o modelo de projeto consiste de um conjunto de colaborações que representam a estrutura e o comportamento do sistema, de forma mapeavel a pelo menos uma linguagem de programação orientada a objetos. A maneira como o sistema se comporta é derivada do modelo de casos de uso e dos requisitos não funcionais especificados para ele. ANÁLISE OO X PROJETO OO

39 Modelagem Estática x Modelagem Dinâmica A análise orientada a objetos cria uma especificação que utiliza termos e entidades do domínio do problema para representá-la principalmente os requisitos funcionais do sistema. Durante a análise, são modelados aspectos estáticos e dinâmicos do domínio do problema. Na modelagem estática, conceitos do mundo real relevantes para o sistema a ser construído são incluídos em um dia- grama de classes de análise, também conhecido como modelo de objetos ou modelo conceitual. Basicamente, esse modelo é composto das principais entidades do sistema (classes), os atributos dessas classes e os relacionamentos entre elas.

40 A modelagem dinâmica descreve os aspectos do sistema de software que podem mudar com o tempo devido à ocorrência de eventos e que dizem respeito ao seu fluxo de controle. A modelagem dinâmica usa diagramas dinâmicos de UML, como diagramas de sequencia, de atividades e de colaboração, para modelar as interações entre objetos no sistema. Esses objetos são instancias das classes de análise e estão contidos no domínio do problema. A modelagem dinâmica também afeta o modelo de classes de análise, enriquecendo-o com elementos ligados ao comportamento do sistema, como as operações. Modelagem Estática x Modelagem Dinâmica

41

42 OMT A OMT (OBJECT MODELING TECHNIQUE) é uma metodologia de desenvolvimento de software orienta- da a objetos que abrange desde a etapa de análise, passando pelo projeto, até a implementação. Como qualquer outra metodologia orientada a objetos, a OMT enxerga um software como sendo um conjunto organizado de objetos discretos que possuem estru- turas de dados e um determinado comportamento.

43 A OMT propõe quatro etapas para o desenvolvimento de um software orientado a objetos: ANÁLISE: Parte-se da declaração do problema para se modelar uma situação do mundo real. O modelo produzido nesta etapa deve representar O QUE o sistema desejado deve fazer e não COMO fazer. Nesta etapa, não se deve ficar restrito aos aspectos de implementação em computador e sim enfocar todos os aspectos do domínio da aplicação, independentemente de virem ou não a ser automatizados. DESENHO DO SISTEMA: Nesta etapa, decide-se a arquitetura do sistema e a plataforma onde ele vai rodar. Decompõe-se o sistema em subsistemas, projetam-se aspectos de performance e da interface homem/máquina. ETAPAS DA METODOLOGIA OMT

44 DESENHO DOS OBJETOS: Baseando-se no modelo produzido na etapa de análise, elabora-se um modelo de objetos, contendo detalhes de implementação. Os detalhes adicionados devem estar de acordo com as estratégias de implementação estabelecidas na etapa de desenho do sistema. IMPLEMENTAÇÃO: As classes de objetos e respectivos relacionamentos projetados durante a etapa de desenho dos objetos são finalmente transformados em programas de computador, em uma determinada linguagem de programação, utilizando um determinado gerenciador de bases de dados e para serem processados em um determinado tipo de plataforma computacional. ETAPAS DA METODOLOGIA OMT

45 OS TRÊS MODELOS DA OMT A metodologia OMT faz uso de três tipos de modelos para representar um sistema: O MODELO DE OBJETOS: Descreve a estrutura estática dos objetos e seus relacionamentos em um sistema. É muito parecido, embora com mais riqueza de significantes, com o clássico modelo de entidades-relacionamento. O MODELO DINÂMICO: Descreve a evolução dos componentes do sistema ao longo do tempo, ou seja, busca representar o ciclo de vida dos objetos do sistema. Utiliza-se, como ferramenta de representação do modelo dinâmico, o Diagrama de Transição de Estados. O MODELO FUNCIONAL: Descreve os fluxos de dados de entrada e saída do sistema e os processos que transformam os dados de entrada, produzindo os dados de saída. Utiliza-se o Diagrama de Fluxo de Dados para se construir o modelo funcional.

46 MODELOS DE OBJETOS SIMBOLOGIA Cada componente ou associação pertencente ao modelo de objetos utiliza uma forma de representação gráfica na forma como está resumido abaixo:

47 Cada objeto está em um determinado estado (situação) em um determinado instante do tempo. Muda para outro estado quando ocorre um evento específico. MODELOS DINÂMICOS (SIMBOLOGIA)

48 RUP O RUP (Rational Unified Process) é uma metodologia para desenvolvimento de software criada pela Rational Software, IBM, SofTeam, Unisys, Nihon Unisys, Alcatel e Q-Labs. O RUP pode ser encontrado na forma de um software, fornecido pela Rational Software, e como um conjunto de processos. o RUP é mais do que um softwares para auxiliar no desenvolvimento é uma metodologia de desenvolvimento, com uma estrutura formal e bem definida. Como qualquer metodologia, é composta de conceitos, práticas e regras. Um dos principais pilares do RUP é o conceito de best practices (melhores práticas), que são regras/práticas que visam reduzir o risco (existente em qualquer projeto de software) e tornar o desenvolvimento mais eficiente.

49 RUP O RUP define seis best practices, sendo elas: Desenvolver iterativamente Gerenciar requerimentos Utilizar arquiteturas baseadas em componentes Modelar visualmente Verificação contínua de qualidade Controle de mudanças O RUP, ainda, entrelaça o conceito de best practices em quatro definições, sendo elas: Funções: grupos de atividades executadas. Disciplinas: áreas de esforço na engenharia de software. Atividades: definições de como (objetos/artefatos) é construído e avaliado. Objetos/artefatos: resultado do trabalho, produzido ou modificado durante o processo.

50 RUP Divide o processo de desenvolvimento de software em quatro fases Concepção: definição do escopo do projeto. Elaboração: elaboração básica do software. Construção: desenvolvimento. Transição;

51 BIBLIOGRAFIA SOUZA, Marcelo souza. UML. Disponível em:. Acesso em: 11 de set. de 2013 DESCONHECIDO. Diretrizes: Diagrama de sequência. Disponível em:. Acesso em: 11 de set. de 2013 SAMPAIO, Marcos Costa,UML. Disponivel em:. Acesso em: 11 de set. de 2013

52 INFOESCOLA, UML. Disponível em. Acesso em 11 de set. de 2013 FONSECA, Gabriela, Os principais diagramas da UML- resumo rápido. Disponivél em. Acesso em 11 de set. de 2013 DESCONHECIDO, Diagramas de interação. Disponível em. acesso em 11 de set. de 2013 BIBLIOGRAFIA

53 FISCHER RUBIRA E SILVA BRITO, Cecília mary e Patrick Henrique, Introdução a Análise Orientada a Objetos e Projeto Arquitetural. Instituto de computação – UNICAMP, campinas-SP BIBLIOGRAFIA


Carregar ppt "UML UML (Unified Modeling Language ou Linguagem de modelagem unificada) Linguagem padrão para modelagem orientada a objetos. Permite visualização do."

Apresentações semelhantes


Anúncios Google