Mapa Mental de Engenharia de Software - Diagramas UML

Documentos relacionados
3.1 Definições Uma classe é a descrição de um tipo de objeto.

UML e a Ferramenta Astah. Profa. Reane Franco Goulart

Arquitetura de Aplicações em 2, 3, 4 ou N camadas

Guia de utilização da notação BPMN

CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Uma visão mais clara da UML Sumário

UML: Diagrama de Casos de Uso, Diagrama de Classes

Utilizando os Diagramas da UML (Linguagem Unificada de Modelagem) para desenvolver aplicação em JSF

UML Itens Estruturais - Interface

Modelagem com UML. Fabio Perez Marzullo. IEEE Body of Knowledge on Services Computing Committee on Services Computing, IEEE Computer Society

Casos de uso Objetivo:

Introdução ao Paradigma Orientado a Objetos. Principais conceitos

Análise e Projeto Orientados por Objetos

Micro Mídia Informática Fevereiro/2009

2 Engenharia de Software

Tema 1: Modelo Estático

Modelagem de Processos. Prof.: Fernando Ascani

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Uma visão mais clara da UML Sumário

Wilson Moraes Góes. Novatec

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

QUESTÕES PARA ESTUDO DIAGRAMA DE CLASSE

Itens estruturais/caso de uso. Itens estruturais/classe ativa. Itens estruturais/componente. Itens estruturais/artefatos. Itens comportamentais

Diagramas de Casos de Uso

Análise e Projeto Orientado a Objetos

Modelagem OO com UML. Vítor E. Silva Souza ~ vitorsouza

Manual do Umbrello UML Modeller

Guia para elaboração do Modelo de Domínio Metodologia Celepar

Engenharia de Software Engenharia de Requisitos. Análise Orientada a Objetos Prof. Edison A M Morais prof@edison.eti.

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite

Disciplina Técnicas de Modelagem

Desenvolvimento de uma Etapa

FUNDAMENTOS DA ORIENTAÇÃO A OBJETOS- REVISÃO

Diagrama de Estrutura Composta

4.1. UML Diagramas de casos de uso

Programação Orientada a Objetos. Introdução à Análise Orientada a Objetos (AOO)

Sumário. Uma visão mais clara da UML

UML (Unified Modeling Language) Linguagem de Modelagem Unificada

Resolução da lista de exercícios de casos de uso

MODELAGEM DE SISTEMAS

1. Explicando Roteamento um exemplo prático. Através da análise de uns exemplos simples será possível compreender como o roteamento funciona.

Fundamentos de Banco de Dados e Modelagem de Dados

O QUE É A CENTRAL DE JOGOS?

PROGRAMAÇÃO OO DIAGRAMA DE CLASSES. Engenheiro Anilton S. Fernandes (asfernandes.com) Janeiro 2012

Persistência e Banco de Dados em Jogos Digitais

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Programação Orientada a Objeto

Gestão de projectos na Web

Caixa Postal Avançada - Corporativo

REQUISITOS DE SISTEMAS

Início Rápido para o Templo

O Processo de Engenharia de Requisitos

UML Unified Modeling Language. Professor: André Gustavo Bastos Lima

Entendendo as Permissões de Arquivos no GNU/Linux

Franklin Ramalho Universidade Federal de Campina Grande - UFCG

Introdução ao icare 2

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 16 PROFª BRUNO CALEGARO

MANUAL DA SECRETARIA

Unidade III MODELAGEM DE PROCESSOS. Profa. Gislaine Stachissini

Capítulo 8. Introdução UML

Engenharia de Software III

UML & Padrões. Aula 1 Apresentação. Profª Kelly Christine C. Silva

2 Diagrama de Caso de Uso

Equipe OC- Olimpíadas Científicas

MODELAGEM VISUAL DE OBJETOS COM UML DIAGRAMA DE CLASSES.

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Conceitos Básicos de Rede. Um manual para empresas com até 75 computadores

Bem-vindo ao tópico sobre consultas no SAP Business One.

RELACIONAMENTOS ENTRE CLASSES

UML - Unified Modeling Language

Manual do Desktop Sharing. Brad Hards Tradução: Marcus Gama

Sistemas Operacionais. Prof. André Y. Kusumoto

paradigma WBC Public - compra direta Guia do Fornecedor paradigma WBC Public v6.0 g1.0

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Projeto ECA na Escola - Plataforma de Educação à Distância

Pontifícia Universidade Católica de São Paulo Departamento de Ciência da Computação

Alteração do POC (Decreto de Lei nº. 35/2005) no sispoc

Análise e Projeto Orientados por Objetos

Seu manual do usuário LOGMEIN RESCUE

MAPEAMENTO OBJETO RELACIONAL: UM ESTUDO DE CASO

Exemplo: Na figura 1, abaixo, temos: Clique aqui para continuar, que é a primeira atividade que você precisa realizar para iniciar seus estudos.

Inicialmente, faça seu cadastro, depois, use seu CPF e sua Senha para fazer o Login e entrar no sistema quantas vezes quiser.

Gerenciamento de Projetos Modulo II Clico de Vida e Organização

Acessando o SVN. Soluções em Vendas Ninfa 2

Portal do Projeto Tempo de Ser

ESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE

Programação Orientada a Objetos e Java - Introdução. Carlos Lopes

Metadados. 1. Introdução. 2. O que são Metadados? 3. O Valor dos Metadados

Manual do Teclado de Satisfação Online WebOpinião

DESENVOLVENDO O SISTEMA

Seja muito bem-vinda(o) ao Curso de Gestão em Projetos Sociais - PMD Pro1!

Sistemas Operacionais. Curso Técnico Integrado Profa: Michelle Nery

Engenharia de Software Unidade XI UML Parte 2

Conteúdo. 1. Introdução. 2. Levantamento de Requisitos. 3. Análise Orientada a Objetos. 4. Projeto Orientado a Objetos 5. UML. 6.

Diagrama de classes. Ricardo Roberto de Lima UNIPÊ APS-I

Conectar diferentes pesquisas na internet por um menu

ALGORITMOS E FLUXOGRAMAS

Transcrição:

Mapa Mental Engenharia Software - Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental UML -

Diagramas, Fases e Detalhes Resolvi juntar os mapas mentais que encontrei sobre UML nesse post para ficar mais fácil. Quem tiver mais e quiser contribuir com a coleção, fique a vonta para me enviar. Diagramas Estrutura Diagramas Comportamento Fases do UML Detalhes dos Diagramas UML - Diagramas Estruturais

UML - Diagramas Comportamento UML - Fases

UML - Detalhes dos Diagramas Introdução diagramas a UML e seus A Unified Molling Language (UML) é uma linguagem ou notação diagramas para especificar, visualizar e documentar molos software orientados por objetos. O UML não é um método senvolvimento, o que significa que não lhe diz o que fazer primeiro ou o que fazer pois ou como senhar o seu sistema, mas ajuda-o a visualizar o seu senho e a comunicar com os outros. O UML é controlado pelo Object Management Group (OMG) e é a norma da indústria para screver graficamente o software. O UML está senhado para o senho software orientado por objetos e tem uma utilização limitada para outros paradigmas programação.

A UML é composta por muitos elementos molo que representam as diferentes partes um sistema software. Os elementos UML são usados para criar diagramas, que representam um terminada parte, ou um ponto vista do sistema. Objetivos Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do senvolvimento completo um sistema informação. A UML é um modo padronizar as formas molagem. Para que usar UML? Ajudar a conceber nossas idéias, em relação ao sistema que estivermos projetando Pensar antes codificar; Apresentar nossas idéias ao grupo forma que todos possam interagir e discutir um terminado ponto Aumentar a participação e envolvimento do time; Documentar nossas idéias quando elas já estiverem bem consolidadas para que novos integrantes e novos colaboradores possam acelerar sua compreensão dos sistemas senvolvidos pelo grupo; Tipos Diagramas Diagramas servem para capturar diferentes visões do sistema: Estrutural: estática Diagrama Diagrama Diagrama Diagrama Classes Objetos Componentes Implantação Comportamental: dinâmica Diagrama Casos Uso

Diagrama Diagrama Diagrama Diagrama Seqüência Atividas Estados Colaboração Diagramas Estáticos Diagrama Classes Diagramas classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os diagramas classe são chamados diagramas estáticos porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes conhecem quais classes ou quais classes são parte outras classes, mas não mostram a troca mensagens entre elas. Na UML, atributos são mostrados com pelo menos seu nome, e pom também mostrar seu tipo, valor inicial e outras propriedas. Atributos pom também ser exibidos com sua visibilida: + indica atributos ou métodos públicos (significa que ele po ser acessado qualquer lugar da classe ou sub-classe); # indica atributos ou métodos protegidos (significa que ele só po ser acessado ntro da própria classe ou em suas classes-filha); indica atributos ou métodos privados (significa que ele só po ser acessado ntro da própria classe.); ~ pacote. As operações também são exibidas com pelo menos seu nome, e pom também mostrar seus parâmetros e valores retorno.

Uma observação a ser feita é que quando se tem um atributo ou método estáticos, eles irão aparecer sublinhados no diagrama. Já os métodos abstratos irão aparecer em itálico. Classes pom ter molos, um valor que é usado para uma classe ou tipo não especificado. O tipo molo é especificado quando uma classe é iniciada (isto é um objeto é criado). Molos existem no C ++ morno e foram introduzidos no Java 1.5 on eles são chamados genéricos. Existem alguns tipos relacionamentos no diagrama classes que veremos abaixo: Generalização A herança é um dos conceitos fundamentais da programação orientada por objetos, nos quais uma classe ganha todos os atributos e operações da classe que herda, pondo sobrepor ou modificar algumas las, assim como adicionar mais atributos ou operações próprias. EM UML, uma associação Generalização entre duas classes colocaas numa hierarquia representando o conceito herança uma classe rivada uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base.

Generalização Associação Um associação representa um relacionamento entre classes, e fornece a semântica comum e a estrutura para muitos tipos conexões entre objetos. Associações são o mecanismo que permite objetos comunicarem-se entre si. Elas screvem a conexão entre diferentes classes (a conexão entre os objetos atuais é chamada conexão do objeto, ou link. Associações pom ter um regra que especifica o propósito da associação e po ser uni ou bidirecional (indicando se os dois objetos participantes do relacionamento pom mandar mensagens para o outro, ou se apenas um les sabe sobre o outro). Cada ponta da associação também possui uma valor multiplicida, que dita como muitos objetos neste lado da associação po relacionar-se com o outro lado. Em UML, associações são representadas como linhas conectando as

classes participantes do relacionamento, e pom também mostrar a regra e a multiplicida cada um dos participantes. A multiplicida é exibida como um intervalo [min máx] valores não negativos, com uma estrela (*) no lado máximo representando infinito. Associação Agregação Agregações são um tipo especial associação no qual as duas classes participantes não possuem em nível igual, mas fazem um relacionamento todo-parte. Uma Agregação screve como a classe que possui a regra do todo, é composta (tem) outras classes, que possuem a regra das partes. Para Agregações, a classe que age como o todo sempre tem uma multiplicida um. Em UML, Agregações são representadas por uma associação que mostra um romboi no lado do todo. Agregação Composição Composições são associações que representam agregações muito fortes. Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não po existir inpenntes. Elas existem somente ntro do todo, e se o todo é struído as partes morrem também.

Em UML, Composições são representadas por um romboi sólido no lado do todo. Composição Interfaces Interfaces são classes abstratas que significam instâncias que não pom ser diretamente criadas las. Elas pom conter operações mas não pom conter atributos. Classes pom rivar interfaces (através da realização uma associação) e instâncias pom então ser feitas stes diagramas. Tipos Dados Tipos dados são primitivos uma vez que são tipicamente construídos numa linguagem programação. Exemplos comuns são inteiros e lógicos. Eles não pom ser relacionados à classes mas classes po se relacionar com eles. Enumerações Enumerações são uma lista simples valores. Um exemplo típico é uma enumeração para dias da semana. As opções uma enumeração são chamadas Literais Enumeração. Como tipos dados, elas não pom ter relacionamentos para classes mas classes pom relacionar-se com elas. Pacotes Pacotes representam um espaço nomes numa linguagem programação. Num diagrama eles são usados para representar partes um sistema que contém mais uma classe, talvez centenas classes.

Diagrama Objetos O diagrama objetos é uma variação do diagrama classes e utiliza quase a mesma notação. A diferença é que o diagrama objetos mostra os objetos que foram instanciados das classes. O diagrama objetos é como se fosse o perfil do sistema em um certo momento sua execução. A mesma notação do diagrama classes é utilizada com duas exceções: os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Os diagramas objetos não são tão importantes como os diagramas classes, mas eles são muito úteis para exemplificar diagramas complexos classes ajudando muito em sua compreensão. Diagramas objetos também são usados como parte dos diagramas colaboração(passou a se chamar comunicação na uml 2.0), on a colaboração dinâmica entre os objetos do sistema são mostrados. Diagrama Objetos Diagrama Componentes Diagramas componente mostram os componentes do software (sejam componentes tecnologias como KParts, componentes CORBA ou Java Beans ou apenas seções do sistema que são claramente distintas) e os artefatos que eles são feitos

como arquivos código-fonte, bibliotecas programação ou tabelas bancos dados relacionais. Componentes pom possui interfaces (isto é classes abstratas com operações) que permitem associações entre componentes. Diagrama Componentes Diagrama Implantação O Diagrama instalação/implantação é finido pela Linguagem Molagem Unificada (Unified Moling Language UML), screve os componentes hardware e software e sua interação com outros elementos suporte ao processamento. Representa a configuração e a arquitetura um sistema em que estarão ligados seus respectivos componentes, sendo representado pela arquitetura física hardware, processadores etc. Nó: Representa uma peça física equipamento na qual o sistema será implantado.

Artefatos: Qualquer pedaço físico informação usada ou produzida por um sistema. Especificação implantação: Especifica um conjunto propriedas que termina os parâmetros execução um artefato que está instalado em um nó. Diagrama Implantação Diagramas Dinâmicos Diagrama Casos Uso Diagramas Caso Uso screvem relacionamentos e pendências entre um grupo Caso Uso e os Atores participantes no processo. É importante observar que Diagramas Caso Uso não são aquados para representar o senho, e não pom screver os mecanismos internos um sistema. Diagramas Caso Uso são feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, e são especialmente úteis para terminar os recursos necessários que o sistema ve ter. Diagramas Caso Uso dizem o quê o sistema ve fazer, mas não fazem e não pom especificar como isto

será conseguido. Um Caso Uso screve do ponto vista dos atores um grupo atividas num sistema que produz um resultado concreto e tangível. Casos Uso são scrições interações típicas entre os usuários um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto exigências do que o sistema ve fazer (lembre-se: somente o quê, não como). Quando trabalhar com Casos Uso, é importante lembrar-se algumas regras simples Cada Caso Uso está relacionado com no mínimo um ator; Cada Caso Uso possui um iniciador (isto é um ator); Cada Caso Uso liga-se a um resultado relevante (um resultado com valor negócio ). Casos Uso também pom ter relacionamentos com outros Casos Uso. Os três tipos mais comuns relacionamento entre Casos Uso são: <<inclui-se>> que especifica que um Caso Uso toma lugar ntro outro Caso Uso <<esten>> que especifica que em terminadas situações, ou em algum ponto (chamado um ponto extensão) um Caso Uso será estendido por outro. Generalização especifica que um Caso Uso herda as características do Super Caso Uso, e po sobrepor algumas las ou adicionar novas maneira semelhante a herança entre classes. Ator Um ator é uma entida externa (fora do sistema) que interage com o sistema participando (e frequentemente iniciando) um

Caso Uso. Atores pom ser pessoas reais (por exemplo usuários do sistema), outro sistema computador ou eventos externos. Atores não representam as pessoa física ou sistemas, mas sua regra. Isto significa que quando uma pessoa interage com o sistema diferentes maneiras (assumindo diferentes regras) ela será representada por diversos atores. Por exemplo um pessoa que fornece suporte ao cliente por telefone e recebe orns do cliente para o sistema po ser representado por um ator da Equipe Suporte e um ator Representante Vendas Descrição do Caso Uso Descrição do Caso Uso são narrativas texto do Caso Uso. Elas usualmente tomam a forma uma nota ou um documento que é alguma maneira ligado ao Caso Uso, e explana o processo ou atividas que tomarão lugar no Caso Uso. Caso Uso

Diagrama Sequência É usado para mostrar uma seqüência atividas. Mostra o fluxo trabalho (workflow) a partir um ponto inicial até um ponto final, talhando as cisões do caminho tomado durante a execução das tarefas. Este diagrama possui várias aplicações, s a finição do fluxo básico um programa até a finição um processo com as suas tomadas cisões e ações. Diagramas Sequência mostram a troca mensagens (isto é chamada método) entre diversos Objetos, numa situação específica e limitada no tempo. Objetos são instâncias classes. Diagramas Sequência colocam ênfase especial na orm e nos momentos nos quais mensagens para os objetos são enviadas. Em Diagramas Sequência objetos são representados através linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, modo que as mensagens são enviadas um Objeto para outro na forma setas com a operação e os nomes dos parâmetros. Diagrama Sequência

Diagramas Ativida O Diagrama Ativida screve a sequência atividas num sistema com a ajuda as Atividas. Diagramas Ativida são uma forma especial Diagramas Estado, que somente (ou principalmente) contém Atividas. Os diagramas ativida não são importantes somente para a molagem aspectos dinâmicos um sistema ou um fluxograma, mas também para a construção sistemas executáveis por meio engenharia produção reversa. Alguns conceitos: Atividas: Comportamento a ser realizado. Sub-ativida: Execução uma sequência não atómica atividas. Transição: Fluxo uma ativida para outra. Ação: Transformação. Decisão: Depenndo uma condição, mostra as diferentes transições. Raia: Diferenciação unidas organizacionais. Bifurcação (Fork): Separa uma transição em várias transições executadas ao mesmo tempo. Sincronização (Join): Concatenação transições vindas do Fork. Objecto: O objecto da ativida. Envio sinal: Transição pra um meio externo, por exemplo, um hardware. Recepção sinal: Recepção do envio. Região: Agrupamento uma ou mais atividas. Exceção: Atividas que ocorrerem em corrência uma excepção.

Diagrama Atividas Diagramas Estado Mola o comportamento um objeto individual. Especifica as seqüências estados pelos quais um objeto passa durante seu tempo vida em resposta a eventos. Diagramas Estado mostram os diferentes estados um Objeto durante sua vida, e o estímulo que faz com que o Objeto mu seu estado. Diagramas Estado veem Objetos como máquinas estado automatismos finitos que pom ser um um conjunto estados finitos e que pom mudar seu estado através um um conjunto finito estímulos. Por exemplo um tipo ou

Objeto ServidorRe po estar em um dos seguintes estados durante sua vida: Pronto Ouvindo Trabalhando Parado e os eventos que pom fazer com que o Objeto mu estado são Objeto é criado Objeto recebe mensagem ouvir Um Cliente solicita uma conexão através da re Um Cliente termina um pedido O pedido é executado e terminado Objeto recebe mensagem parar etc Estado Estados são os blocos construídos dos Diagramas Estado. Um Estado pertence a exatamente uma classe e representa um resumo dos valores dos atributos que uma classe po tomar. Um Estado UML screve o estado interno um objeto para uma classe em particular Observe que nem toda mudança em um dos atributos um objeto po ser representada por um Estado mas somente aquelas mudanças que pom afetar significativamente o trabalho do objeto Existem dois tipos especiais Estados: Inicial e Final. Eles são especiais porque nenhum evento po fazer com que um Objeto retorne para seu estado Inicial, e da mesma maneira nenhum evento po tirar um Objeto seu estado Final uma vez que ele já o tenha alcançado.

Diagrama Estados Diagramas Colaboração Diagramas Colaboração mostram as interações que ocorrem entre os objetos participantes numa situação específica. Isto é mais ou menos a mesma informação mostrada pelos Diagramas Sequência, mas neste a ênfase é colocada em como as interações ocorrem no tempo, enquanto os Diagramas Colaboração colocam os relacionamentos entre os objetos e sua topologia em staque. Em Diagramas Colaboração as mensagens enviadas um objeto para outro são representadas por setas, mostrando o nome da mensagem, parâmetros, e a sequência da mensagem. Diagramas Colaboração são especialmente indicados para mostrar um fluxo ou situação específica do programa e são um dos melhores tipos diagrama para rapidamente monstrar ou explanar um processo na lógica do programa.

Diagrama Colaboração Fontes: http://docs.k.org/stable/pt_br/ksdk/umbrello/uml-bas ics.html#about-uml http://www.dpi.inpe.br/~gribeiro/apresentacoes/uml_2008_ 02_29.pdf Handbook TI http://pt.wikipedia.org/wiki/uml