CEFET-PR. Pá g.: 1. Centro Federal de Educação Tecnoló gica do Paraná. Departamento Acadêmico de Informá tica. Projeto de Software usando a UML. Versão 2002 ..... A decomposição de um diagrama de casos de uso pode ser feita em UML utilizando o ......
NBR 7229/1993 3 3.33 Vala de filtração Sistema de tratamento biológico do efluente do tanque séptico, que consiste em um conjunto ordenado de caixa
Andrey Ricardo Pimentel. Projeto de Software Usando a UML. Apostila para Curso de Projeto de. Sistemas Orientado a Objetos. Usando a UML. Setembro de 2015
NBR 7187:2003 3 3.5.5 Devem também constar nos desenhos de fôrmas outras informações importantes relativas à obra, principalmente: classe em que se enquadra (com
NBR 9818/1987 3 4.1.6.2 Não há restrição quanto às cores do material de revestimento do tanque. Devem entretanto existir cores contrastantes em pelo menos um
- Lei nº 7.209 de 11/7/1984 Parte Especial ... • Diferença do tipo com a Lei 9.455/97 (intenção) HOMICÍDIO QUALIFICADO III - com emprego de
movimentação de materiais -, ao envolvimento da produção e áreas afetadas e à instalação de máquinas e equipamentos. Ao final, serão apresentadas algumas
por la activación de los receptores de N-metil D-Aspartato (NMDA), produciéndose un mayor influjo de calcio,7,16 por otro lado, activa receptores metabotrópicos
3 Bilanciamento redox in forma molecolare 1. Pb(NO3)2 + Cu +H2SO4 PbSO4 + CuSO4 + NO + H2O (1,3,4 - 1,3,2,4) 2. K2Cr2O7 + SO2 + H2SO4 Cr2(SO4)3 + K2SO4 + H2O
Norma Técnica Sabesp NTS 230 : 2009 17/06/09 1 Projeto de lagoas de estabilização e seu tratamento complementar para esgoto sanitário 1 PRELIMINARES
forme a NBR 9818, de acordo com a classificação es-tabelecida na NBR 9819, as prescrições indicadas a seguir. 4.1 Tempo máximo de recirculação (horas)
APOCALIPSE, CAPÍTULO QUATRO - 1ª PARTE 5 do Céu, os corredores do Céu descerão, uma carruagem de fogo descerá, e
LÉVÊQUE, Pierre. As primeiras civilizações – a Mesopotâmia/os Hititas. Vol. II. Lisboa: Ed. 70, 1987. LÉVÊQUE, Pierre. As primeiras civilizações – os impérios do bronze. Vol. I. Lisboa: Ed. 70, 1987. LÉVÊQUE, Pierre. As primeiras civilizações – os in
1 Parte I Mecanica de Lagrange´ ´Indice I 1 1. Coordenadas generalizadas 1 1.1. Constricciones y coordenadas generalizadas . . . . . . . . . . . . .1
Ezequiel teve visões incríveis e contatos com seres que pilotavam naves aéreas muito estranhas para sua compreensão, naquela época. Segundo as escrituras temos
Projeto de Pesquisa apresentado à coordenação do curso como requisito para elaboração da Monografia da Faculdade de Tecnologia de João Pessoa.
Art. 8º A garantia de padrão de qualidade, com pleno acesso, inclusão e permanência dos sujeitos das aprendizagens na escola e seu sucesso, com redução da
ARGAN, Giulio Carlo. Projeto e destino. São Pauio: Editora Ática, 2a ed., 2001. 336 p. ISBN: 8508075111. BENEVOLO, Leonardo. A arquitetura no novo milénio . São Paulo: Estação. Liberdade, 2007s 496 p. iSBN: 8574481319. BOUTiNET, Jean-Pierre. Antropol
PROJETO VIDAS PLURAIS Enfrentando a Homofobia e o Sexismo em sala de aula Projeto de Intervenção Educação para a diversidade Alunas: Mônica Altair de Oliveira
PROJETO DE MONOGRAFIA ADMINISTRAÇÃO DA QUALIDADE: PERSPECTIVAS DA CERTIFICAÇÃO ... PDF created with pdfFactory trial version www.pdffactory.com. 4 4
5.1.2 Planilha de Custos com Projeto de MDL e Seqüestro de Carbono..... 51 5.1.3 Receitas com Créditos de Carbono
manipulação de informações para um ou mais ... eletrônicos e partes eletromecânicas do computador. É a parte física e ... formado por vários módulos que
P. 02 Sistemas de tratamento de águas residuais de natureza doméstica em conformidade com o exposto na legislação aplicável vigente (Decreto-Lei n.º 152/97 de
2 NBR 8160:1999 Esta Norma não se aplica aos sistemas de esgoto indus-trial ou assemelhado, a não ser para estabelecer as precauções que devem ser observadas
Análise e Projeto de Software Parte I Marcos Dósea [email protected]
Agenda • Apresentação do professor • Apresentação da disciplina • Metodologia e avaliação
Apresentação do professor
Marcos Barbosa Dósea
Currículo Formação: – Formado em Ciência da computação – Mestre em Engenharia de Software e Linguagens de Programação – Certificado Java 5. Experiência: – 1 ano como Analista de Sistemas e suporte à Equipe de Desenvolvimento na Plataforma Java EE na Secretaria de Estado da Fazenda de Sergipe. – 2 anos na Qualiti Software Processes como consultor na área de arquitetura de software, análise e projeto de sistemas e melhoria e implantação de processos de desenvolvimento de software. – Consultor na suíte de ferramentas da IBM Rational. – Professor em Disciplinas de Pós-Graduação em Gerência de Projetos e Engenharia de Software. – Consultor do Centro de Processamento de Dados da Universidade Federal de Sergipe. – Professor da Universidade Federal de Sergipe.
Nome: Análise e Projeto de Software Carga horária: 20 horas/aula Datas: 06/11 e 20/11 Horário: 08:00 às 12:00h e 13:00 às 17:00h Intervalos: 10:00h e 15:00h (15 minutos)
Objetivo da disciplina Proporcionar ao aluno um conhecimento amplo das principais técnicas e ferramentas que podem ser utilizadas para realizar análise e projeto de software Orientado à Objetos.
Ementa • Princípios da Orientação a Objetos. • Classes, Objetos, Encapsulamento, Herança, Agregação e Composição; • Modelagem Orientada a Objetos. • Diagramas UML. • Análise de Software Orientada a Objetos. • Projeto de Arquitetura de Software • Projeto de Software • Projeto de Banco de Dados • Padrões de desenho (Design Patterns).
Divisão da ementa • PARTE I: – Diagrama de Classes; – Diagramas de Interação; – Análise e Projeto de Software; • PARTE II: – Análise de Software Orientado à Objetos; – Projeto da Arquitetura; – Projeto de Software Orientado à Objetos;
Divisão da ementa • PARTE III: – – – –
Arquitetura de Software; Projeto de Software Orientado à Objetos (continuação) Projeto de Banco de Dados Padrões de Projeto Orientado à Objetos
Bibliografia • FILHO, Wilson de Pádua Paula. Engenharia de Software: Fundamentos, Métodos e Padrões. 2. ed. São Paulo: LTC, 2003. • SOMMERVILLE, Ian. Engenharia de Software. 8. ed. São Paulo: Pearson, 2005. • PRESSMAN, R. S. Engenharia de Software. 5. ed. São Paulo: MCGraw-Hill, 2006.
Bibliografia • Rational IBM. RUP (Rational Unified Process). Disponível em: http://www.wthreex.com/rup/smallprojects/index.ht m. Acesso em: 15/09/2009. • FOWLER, Martin. UML Essencial. 3. ed. São Paulo: Bookman, 2005. • LARMAN, Craig. Utilizando UML e Padrões. 3. ed. São Paulo: Bookman, 2007.
Metodologia e avaliação
Metodologia e avaliação • Aulas expositivas; • Dinâmicas e atividades em grupo; • Os alunos serão avaliados da seguinte forma: – Participação em sala de aula (Presença + Participação) – 2,0; – Estudo de caso – 8,0;
Cronograma de aulas Aula
Data
Turno
Assunto
1
6/11
manhã
01 - Apresentação da Disciplina
1
6/11
manhã
02 - Diagrama de Classes
2
6/11
manhã
03 - Diagrama de Interação
2
6/11
manhã
04 - Introdução à Análise e Projeto de Software OO
2
6/11
manhã
Estudo de Caso: Criando diagramas de classe e interação
3
6/11
tarde
05 - Análise de Software OO
4
6/11
tarde
06 - Projeto da Arquitetura
4
6/11
tarde
07 - Projeto de Software OO
4
6/11
tarde
Estudo de Caso: Criando modelo de análise e projeto
Características Classes Interfaces Relacionamentos Esteriótipos Quando construir? • Análise • Projeto
Características • Mais importante e o mais utilizado diagrama da UML. • Exibe as classes que irão compor o sistema com seus respectivos métodos,
atributos e relacionamentos. • Visão estática da organização das classes.
Características • Pode ser utilizado para modelar classes persistentes. • Intencionalmente projetado para ser uma evolução do modelo EntidadeRelacionamento.
Classes • Podem possuir atributos e métodos. • Não se preocupam com os passos que devem ser percorridos pelos métodos. • Possui 3 divisões não obrigatórias: – Nome da Classe – Atributos e seus tipos de dados. – Métodos.
Cliente
-cpf: long #endereco: String ~nome: String +validar(cpf: long): boolean
Classes • Visibilidade dos Atributos e Métodos – – – –
Privada (-) Protegida (#) Pacote (~) Pública (+)
Cliente -cpf: long #endereco: String ~nome: String +validar(cpf: long): boolean
Classes • Podemos visualizar ainda... – Tipo dos atributos e argumentos. – Retorno dos métodos. – Valor padrão dos atributos quando criados. Cliente -cpf: long #endereco: String ~nome: String -emDebito: boolean = false +validar(cpf: long): boolean
Tipo dos atributos Valor padrão Tipo dos argumentos Retorno do método
Classes • Atributos e Operações de Instância e Estáticos – A única diferença na representação é que os estáticos ficam sublinhados. Cliente
Cliente
-cpf: long #endereco: String ~nome: String -emDebito: boolean = false
-cpf: long #endereco: String ~nome: String -emDebito: boolean = false
+validar(cpf: long): boolean
+validar(cpf: long): boolean
Instância
Estático
Classes • Classe Concreta e Abstrata – Única diferença é o estilo da fonte da classe abstrata que fica em itálico. Pessoa
Pessoa
Concreta
Abstrata
Vamos pensar um pouco... • Qual seria o melhor nível de visibilidade para os atributos de uma classe? • Qual o objetivo de uma classe abstrata?
Relacionamentos • Associações – Descreve o vínculo que ocorre entre classes. – Instâncias das classes ligadas às instâncias de outras classes para troca de informações, utilização de métodos, etc. – São representadas por retas ligando as classes envolvidas. • Navegabilidade não é obrigatória e representa o fluxo das informações. • É bom dar um nome para associação quando não estiver implícita.
0..1 : No mínimo 0 no máximo 1 1..1 : Um e somente um. 0..* : No mínimo nenhum e no máximo muitos. 1..* : No mínimo 1 no máximo muitos. 3..5: No mínimo 3 no máximo 5.
Relacionamentos • Associações – Associação Unária ou Reflexiva Associação
Relacionamentos • Associações – Agregação • Objeto-todo é composto por vários objetos-parte. • Objetos-parte podem existir sem um objeto-todo. • Significado contém, faz parte de, é constituído por Eq uip e
0. . 1 * Joga dor
A equipe é constuída por n jogadores. Os objetos-parte (jogadores) podem existir sem o objeto-todo (equipe), por isso a multiplicidade do relacionamento 0..1.
Relacionamentos • Associações – Composição • É uma agregação com uma restrição mais forte. • Objetos-Parte pertencem exclusivamente a um Objeto-Todo. São criados e destruídos juntos. Pedido
1 * ItemPedido
O pedido é constituído por vários itens do pedido. Os objetos-parte (ItemPedido) não podem existir sem o objeto-todo (Pedido), por isso a multiplicidade do relacionamento é 1.
Outros exemplos... • Qual o tipo de associação existente entre as entidades turma e aluno? • Qual o tipo de associação existente entre as entidades filme e atores?
Relacionamentos • Especialização / Generalização – Relação semântica “é um” ou “é uma”. – A subclasse herda atributos e operações da super classe, podendo adicionar outras.
Relacionamentos • Realização – Um elemento (classe) implementa as operações especificadas por outro elemento (interface). A classe String implementa a interface Hashtable
A classe String implementa a interface Comparable
Classes Associativas • São classes que estão ligadas a associações, em vez de estarem ligadas a outras classes. • Também chamadas classes de associação. • Comum entre associações de conectivade muitos para muitos, mas podem aparecer em relacionamentos de qualquer conectividade.
<< en tit y col lectio n> > CadastroContas ex ist eCon ta()
0..n
login senha
Quando construir?
Modelo de Casos de Uso
Modelo de Análise e Projeto
Visão Visão de de Casos Casos de de Uso Uso
Diagramas de Seqüência
Diagramas de Colaboração
Diagramas de Classes de Projeto
Visão Visão Lógica Lógica
Diagrama de Componentes
Diagrama de Distribuição
+
Visão Visão de de Processos Processos
+
Visão Visão de de Distribuição Distribuição
Perspectivas no Projeto • Conceitual – Classe interpretada como um conceito. – Apenas classes e atributos são utilizados.
• Especificação – Principais interfaces e métodos. – Prover maior entendimentos da arquitetura.
• Implementação – Especificação é detalhada. – Visibilidades, parâmetros tipos são adicionados.
Perspectiva Conceitual
Perspectiva de Especificação
Perspectiva de Implementação
Atividade de Sala I Crie o diagrama de classes com suas respectivas associações e cardinalidades contendo as classes que você achar necessário para realizar o caso de uso cadastro de pessoas físicas / jurídicas.
Atividade Sala I Exercite a criação de diagrama de classes usando o StarUML criando alguns dos diagramas exibidos na apresentação. Exercite a geração do código em diferentes linguagens.
Agenda • Aula II – Diagramas de Interação – Introdução à Análise e Projeto de Software
Motivação • Como os diagramas estudados até o momento podem ajudar? – – – –
Auxiliam na definição dos requisitos. Auxiliam o processo de análise do sistema. Definem classes e responsabilidades. Definem associações entre classes.
Motivação • Como determinar a sequência de chamada dos métodos? • Qual classe inicia o encadeamento das chamadas? • Todos os métodos necessários já foram descritos? • Quais as classes que participam numa interação?
Agenda • Diagrama de Seqüência – Características – Componentes Básicos
• Diagrama de Comunicação
Diagrama de Seqüência • Características – Determina a seqüência de eventos que ocorrem num determinado processo. – Para um mesmo processo (caso de uso) existirão vários diagramas de seqüência. – Semelhante ao caso de uso especificado. – Os diagramas de sequência e comunicação são chamados diagramas de interação da UML.
Diagrama de Seqüência • Características – Depende do diagrama de classes e por isso normalmente são construídos em conjunto. – Concentra-se na seqüência temporal dos eventos.
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Atores – São exatamente os mesmo descritos no caso de uso, ou seja, entidades externas que interagem com o sistema e solicitam serviços.
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Objetos – Representam as instâncias das classes envolvidas no processo. Representação através dos dois pontos (:) seguido do nome da classe. O nome do objeto é opcional.
Diagrama de Seqüência • Objetos – Quando o objeto existe desde o início o retângulo aparecerá na parte superior do diagrama. Quando ele é criado no decorrer do processo ele surgirá na mesma altura da mensagem.
Objeto criado após o início do processo.
Mensagem de criação do objeto.
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Linha de Vida – Representa o tempo em que um objeto existiu durante um processo. É interrompida com um “X” quando um objeto é destruído.
Linha da vida.
X
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Foco de Controle ou Ativação – Indica os períodos em que um determinado objeto está participando ativamente do processo.
Foco de controle.
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Mensagens ou Estímulos – Demonstram a ocorrência de eventos que normalmente forçam a chamada de um método de algum objeto envolvido no processo. • • • •
Diagrama de Seqüência • Mensagens ou Estímulos Mensagem de criação.
Auto-Chamadas ou Auto-delegações.
Mensagem para objetos que já existem. Mensagem de retorno.
Método destrutor
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Seqüência • Condições de Guarda – Indica que uma mensagem só poderá ser enviada a um objeto se uma condição for verdadeira.
Condição de guarda.
Diagrama de Sequência • Condicão de Guarda na UML 2.0
Diagrama de Sequência • Condicional Mutuamente Exclusiva
Diagrama de Seqüência • Componentes Básicos – – – – – – –
Atores Objetos Linha de Vida Foco de Controle ou Ativação Mensagens ou Estímulos Condições de guarda Laços
Diagrama de Sequência • Loop
Vamos pensar um pouco... Utilizando as classes criadas para realizar o cadastro de clientes crie o diagrama de sequência para realizar a operação de inserção e remoção de dados no banco de dados.
Roteiro • Diagrama de Seqüência • Diagrama de Comunicação – Características – Componentes Básicos
Diagrama de Comunicação • Características – Possui as mesmas funções do diagrama de seqüência. – Concentra-se na organização estrutural dos objetos. – É possível gerá-lo a partir do diagrama de seqüência e vice-versa.
Diagrama de Comunicação • Componentes Básicos – – – – –
Objetos Atores Vínculos Mensagens Condições
Diagrama de Comunicação • Objetos – São as instâncias da classe que participam de um processo. Semelhante a representação do diagrama de seqüência.
Coleção de dependentes.
Diagrama de Comunicação • Componentes Básicos – – – – –
Objetos Atores Vínculos Mensagens Condições
Diagrama de Comunicação • Atores – São os mesmos do diagrama de seqüência e conseqüentemente os mesmo do diagrama de casos de uso.
Diagrama de Comunicação • Componentes Básicos – – – – –
Objetos Atores Vínculos Mensagens Condições
Diagrama de Comunicação • Vínculos – Indicam as ligações que existem entre os objetos envolvidos em um processo, ou seja, os objetos colaboram entre si.
Diagrama de Comunicação • Componentes Básicos – – – – –
Objetos Atores Vínculos Mensagens Condições
Diagrama de Comunicação • Mensagens – Representam a chamada dos métodos. São as mesmas do diagrama de seqüência. – Não existem mensagens de retorno.
A seta indica a direção para onde a mensagem foi enviada.
Diagrama de Comunicação • Mensagens – Também é possível disparar uma mensagem para si próprio.
Auto-Chamada.
Diagrama de Comunicação • Mensagens – Podem ser enviadas diversas vezes.
Variável de Retorno Mensagem enviada repetidas vezes. Pode-se restringir o número de vezes. Ex: *[i := 1..10]
Coleção de objetos
Diagrama de Comunicação • Componentes Básicos – – – – –
Objetos Atores Vínculos Mensagens Condições
Diagrama de Comunicação • Condições – Mensagem só é enviada se a condição for satisfeita.
Condição.
Diagrama de Comunicação
Atividade Sala II Crie um projeto no StarUML contendo as classes necessárias para realização de um CRUD para os dados de uma Pessoa. Crie diagramas de interação para definir os métodos necessários nessas classes.
Introdução à Análise e Projeto de Software Marcos Dósea [email protected]
Agenda • Introdução • Como fazer Análise? • Fluxo de Análise e Projeto do RUP
Introdução • Onde estamos?
Introdução • O que faremos? – Analisar o Software – Definir a arquitetura – Projetar o Software • Componentes • Banco de Dados
Análise x Projeto Análise Foco no problema Comportamento caixa preta Estrutura geral da arquitetura do sistema Requisitos Funcionais Modelo simples
Projeto Foco na solução Detalha operações e atributos dos objetos Representação próxima do código. Requisitos Funcionais e Não Funcionais Modelo complexo.
Quais os artefatos produzidos?
Modelo de Análise e Projeto Modelo de Casos de Uso
Glossário
Documento de Requisitos
Análise e Projeto
Documento da Arquitetura
Mapeamento das Classes de Análise em Elementos de Projeto
Projeto de Banco de Dados
Quais os artefatos produzidos? • O que é produzido? Modelo de Casos de Uso
Caso de Uso
Modelo de Análise e Projeto
Realização de Caso de Uso
Diagrama de Seqüência
Diagrama de Colaboração
Diagrama de Classes
Quais os artefatos produzidos? • Pode ser um modelo que inicia na atividades de análise (visão abstrata) e é concluído no projeto (visão detalhada). • Podem ser dois modelos – Modelo de Análise – Modelo de Projeto (evoluído do modelo de análise)
• Como escolher? – Documentação x Esforço Manutenção
